Hon­ey­pot role-play­ing for the Pi; pro­tect your iden­tity; master Chrome’s mal­ware tool; cre­ate a pop-art por­trait; tighten se­cu­rity.

EARLY WARN­ING SYS­TEMS pro­vide alerts to pend­ing is­sues, so im­me­di­ate ac­tion can be taken to pre­vent or re­duce fur­ther dam­age. “Hon­ey­pot” is a term as­signed to a com­puter sys­tem de­signed to de­tect unau­tho­rized ac­cess to the re­sources it makes avail­able. Honey­pots are con­fig­ured to look like le­git­i­mate com­puter re­sources on a net­work; the com­puter can be posed to look like a file­server con­tain­ing data that would ap­peal to an at­tacker. A hon­ey­pot web­server, a hon­ey­pot database, or a hon­ey­pot ap­pli­ca­tion server would have re­sources staged as bait to at­tract the ad­ver­sary. When the at­tacker tries to gain ac­cess to a spe­cific re­source, it is blocked, be­cause the re­source is fake. How­ever, the at­tempt trig­gers an alert, and can be logged for anal­y­sis.

If an at­tacker has en­tered your net­work, de­pend­ing on its con­fig­u­ra­tion, it may be fairly easy for them to move around un­de­tected. Us­ing a sim­ple Rasp­berry Pi, we can build a juicy-look­ing re­source, which gen­er­ates an alert re­veal­ing the at­tacker’s pres­ence when it de­tects them try­ing to ac­cess the sys­tem. The ex­ten­sive list from the Awe­some Hon­ey­pot re­source ( https://­alax/awe­some-honey­pots) de­tails the mul­ti­ple fla­vors of honey­pots avail­able. Let’s in­stall and test the open-source of­fer­ing of OpenCa­nary (OC).


The bill of ma­te­ri­als for this ex­er­cise is sim­ple. Any ver­sion of Pi 2/3 hard­ware is ac­cept­able. Even Pi Zero hard­ware with a wired or wire­less net­work will work. The hard­ware re­quired is min­i­mal, be­cause the de­vice will be con­fig­ured to sim­u­late a ser­vice, not pro­vide it. The op­er­at­ing sys­tem used in this project is 2018-03-13-rasp­bian-stretch-lite. The OpenCa­nary ap­pli­ca­tion soft­ware didn’t have a ver­sion num­ber, but can be downloaded from­nary.

>> A net­work-sup­ported Pi 3 run­ning Rasp­bian Stretch Lite was de­ployed for this project. Not all the soft­ware and ap­pli­ca­tion bells and whis­tles of­fered in the full Rasp­bian in­stall are needed for this build. The project doesn’t need a GUI, so there is no need to load the soft­ware. The Rasp­bian Lite ver­sion is ac­cept­able for use in this project.

>> The con­fig­u­ra­tion changes are done from the con­sole com­mand-line in­ter­face (CLI). The con­sole is accessed us­ing an SSH con­nec­tion. The de­tails to in­stan­ti­ate the Pi and es­tab­lish the con­nec­tion aren’t cov­ered here, but there’s a num­ber of re­sources that de­scribe how to ac­com­plish th­ese pre­req­ui­sites ( www.rasp­ber­­u­men­ta­tion/re­mote-ac­cess/ssh/).

>> This de­vice will be host­ing fake ser­vices. To en­sure the de­vice is se­cure, we are go­ing to base­line what ser­vice ports are avail­able, and then ap­ply some ser­vice hard­en­ing. The

CLI com­mand net­stat -plutn is an ideal com­mand to re­mem­ber for list­ing which ser­vice ports are avail­able [ Image A].

>> If you are not fa­mil­iar with the nam­ing con­ven­tion for port ser­vices, drop the “n” from the com­mand

net­stat -plut . This re­moves the port num­ber to ser­vice lookup trans­la­tion. Now you don’t have to re­mem­ber that SSH is port 22.

>> Start the ex­er­cise of baselin­ing the sys­tem by is­su­ing the net­stat com­mand to get an idea of what ports are cur­rently open. When the ser­vices re­con­fig­u­ra­tion below is com­pleted, run the com­mand again to see the re­sults of the cleanup: sudo ser­vice --sta­tus-all sudo sys­tem­ctl dis­able avahi-dae­mon sudo sys­tem­ctl dis­able blue­tooth sudo sys­tem­ctl ser­vice rsync dis­able sudo sys­tem­ctl dis­able mo­tion

>> Re­tain this port knowl­edge as the base­line for the sys­tem. Any port ad­di­tions that ap­pear in the list from this point for­ward are a re­sult of some­thing chang­ing. When mak­ing soft­ware changes, it is best prac­tice to do a port check to con­firm noth­ing has been added as a re­sult of the change. Be­cause this hon­ey­pot is be­ing

con­fig­ured as bait, we don’t want to leave any ports ex­posed that we don’t want to make avail­able.


Let’s add some soft­ware pre­req­ui­sites for the OC in­stal­la­tion. Countless times, soft­ware in­stalls fail due to lo­cal repos­i­tory con­tent be­ing stale. It is best prac­tice—or let’s just say it will save you some headaches—if you make it a habit to per­form a soft­ware up­date be­fore any soft­ware ad­di­tions. sudo apt-get up­date sudo apt-get in­stall git python-vir­tualenv python-pip python­dev lib­ssl-dev libffi-dev samba

Not all the Potemkin vil­lage (a con­struc­tion, lit­eral or fig­u­ra­tive, built solely to de­ceive oth­ers into think­ing that a sit­u­a­tion is bet­ter than it re­ally is) built of the ser­vices sup­ported through OC is avail­able in the ap­pli­ca­tion. Samba, for ex­am­ple, must be fully in­stalled and set to “au­tostart” for it to be used by OC. The Samba con­fig­u­ra­tion file pro­vided in the OC in­stal­la­tion must be in­stalled in Samba to en­able the ser­vice.

The doc­u­men­ta­tion indi­cates that OC is to be in­stalled in a Python vir­tual en­vi­ron­ment. Some sys­tems re­quire dif­fer­ent ver­sions of the same soft­ware li­brary. The sep­a­ra­tion pro­vided by vir­tual en­vi­ron­ments makes man­ag­ing mul­ti­ple soft­ware li­braries eas­ier. Cre­at­ing the hon­ey­pot in a vir­tual en­vi­ron­ment en­ables the de­vice to keep the hon­ey­pot ser­vice sep­a­rate from other ser­vices. How­ever, try­ing to use a hon­ey­pot to pro­vide ad­di­tional ser­vices should raise se­cu­rity con­cerns, if you think about it. We won’t ar­gue with the de­sign to use a vir­tual en­vi­ron­ment. Cre­ate the Python en­vi­ron­ment, then en­ter (or source) the en­vi­ron­ment. Clone the Github soft­ware in­stal­la­tion direc­tory, change to the direc­tory, and start the OC in­stal­la­tion: vir­tualenv -p python2 ca­nary-env source ./ca­nary-env/ bin/ac­ti­vate git clone­nary cd openca­nary/ python in­stall

OC ships with a de­fault con­fig­u­ra­tion file. The in­stal­la­tion

docs in­di­cate the open­ca­naryd –copy­con­fig com­mand can be used to po­si­tion the con­fig­u­ra­tion file cor­rectly in order for the app to start. The com­mand failed to work. Read­ing the er­ror mes­sage dis­played on the screen, and a quick cull of In­ter­net search re­sults, sug­gested copy­ing the OC con­fig­u­ra­tion file to the proper lo­ca­tion man­u­ally to es­tab­lish a work­ing con­fig file: sudo mkdir /etc/open­ca­naryd sudo cp ~/openca­nary/openca­nary/data/set­tings.json /etc/ open­ca­naryd/openca­nary.conf

Be­fore giv­ing in to the im­me­di­ate im­pulse to is­sue the com­mand to start the ap­pli­ca­tion, let’s make some OC con­fig­u­ra­tion changes, to give us an idea of what OC is ac­tu­ally start­ing. Us­ing your fa­vorite text ed­i­tor, mod­ify the “/etc/open­ca­naryd/openca­nary.conf” file. Re­place all true val­ues with false , with the ex­cep­tion of “tel­net.

en­abled”: true, 23 . This true value leaves us one ser­vice for test­ing. Be ex­tra care­ful when mod­i­fy­ing the con­tents of this con­fig­u­ra­tion file; syn­tax er­rors cause a fail­ure in the startup of the OC ap­pli­ca­tion.

>> A main page call from the CLI for open­ca­naryd pro­vides a list of the op­er­a­tions the com­mand sup­ports. The start op­tions worked from the CLI, and gave the ap­pear­ance of work­ing ( the log files in­di­cated that the ap­pli­ca­tion started) when used in the au­tostart con­fig­u­ra­tion. The im­pres­sion was dif­fer­ent from what was ac­tu­ally hap­pen­ing. The OC ap­pli­ca­tion went into a loop of con­tin­u­ous restarts when the start op­tion was used. The stop op­tion ap­peared to have worked from the CLI. As men­tioned, –copy­con­fig didn’t de­liver what it promised. Proven through test­ing, the fol­low­ing com­mand was used to fire up the ap­pli­ca­tion:

open­ca­naryd --dev

>> The ap­pli­ca­tion gen­er­ates out­put to the screen, even­tu­ally reach­ing sta­sis. Re­call that the OC con­fig­u­ra­tion was mod­i­fied to ini­ti­ate one ser­vice: Tel­net. The fol­low­ing lines ap­pear in the text out­putted to screen: Added ser­vice from class Tel­net in openca­nary. mod­­net to fake.... ServerFac­tory start­ing on 23, as an in­di­ca­tion OC is now sup­port­ing tel­net . >> Open a se­cond con­sole win­dow to the OC de­vice. Then is­sue the net­stat com­mand fla­vored -plutn to check which ports are open—see an­no­ta­tion “B” [ Image B]. TCP port 23 should have taken res­i­dence in your port scan. Re­call that we in­stalled the Samba af­ter we base­lined the open ports. That in­stal­la­tion added port 137, shown in the screen­shot. To test the con­fig­u­ra­tion, ini­ti­ate a Tel­net ses­sion from a sep­a­rate host ma­chine to the OpenCa­nary de­vice (an­no­ta­tion “A”). Lo­gin fails, but each at­tempt gen­er­ates out­put from OpenCa­nary (an­no­ta­tion “C”).


Re­turn to the screen that is out­putting the log in­for­ma­tion, and press Ctrl–C to stop the OC

ap­pli­ca­tion, and re­turn a CLI prompt. Now open the work­ing “openca­nary.conf,” and make the fol­low­ing changes to have the alert mes­sages sent to an email ac­count.

>> In­sert the mail con­fig­u­ra­tion de­tails into the script us­ing the screen­shot above [ Image C] to de­ter­mine where the in­for­ma­tion should be po­si­tioned in the file. Re­mem­ber: Syn­tax er­rors cause an OC startup to fail. “SMTP”: {

“class”: “log­ging.han­dlers.SMTPHan­dler”, “mail­host”: [“au­then­ti­cated.mail.server”, 25], “fro­maddr”: “ca­[email protected]­do­”, “toad­drs” : [“yourad­[email protected]­do­”], “sub­ject” : “OpenCa­nary Alert”, “cre­den­tials” : [“myuser­name”, “pass­word1”] },

>> You need to sub­sti­tute the email con­fig­u­ra­tion val­ues from your provider with the place­holder val­ues in the con­fig­u­ra­tion. Email providers may make th­ese de­tails avail­able on their web­site or in doc­u­men­ta­tion. With­out ac­cu­rate mail server set­ting, es­tab­lish­ing email sup­port in OC is near im­pos­si­ble.

>> Port 25, shown in the script, is the stan­dard port value for the SMTP pro­to­col. Do not as­sume your provider uses this value. In ad­di­tion, the email con­fig­u­ra­tion pro­vided from the OC site and in the doc­u­men­ta­tion doesn’t re­flect se­cure mail ser­vices. We’ve pro­vided the se­cret sauce (the at­tribute to sup­port se­cure mail ser­vices) re­quired in the OC con­fig­u­ra­tion in order for the ser­vice to func­tion. The val­ues used in our con­fig­u­ra­tion are grayed-out, but the se­cret-sauce text de­pen­den­cies are there.

>> Fire up the OC ap­pli­ca­tion again, and the email ac­count de­fined in the con­fig­u­ra­tion should re­ceive mes­sages. Once email is con­firmed to be work­ing, dis­able email alerts. With all the ser­vices OC sup­ports en­abled, 12 email mes­sages are de­liv­ered as part of the startup. To avoid the mes­sage rush, it is rec­om­mended that email sup­port be dis­abled dur­ing de­vel­op­ment.



The Samba OpenCa­nary mod­ule mon­i­tors a log file pro­duced by the Samba full_ au­dit VFS mod­ule. The process to have OpenCa­nary sup­port Samba has more over­head than we have en­coun­tered for ser­vices so far. OpenCa­nary re­quires Samba to be in­stalled and func­tion­ing on startup. The Samba app must be con­fig­ured to have its events writ­ten to “sys­log LOCAL7.” The sys­log­ger ap­pli­ca­tion must be con­fig­ured to log to the “/var/log/samba-au­dit.log” file.

>> Let’s pre­serve the de­fault con­fig­u­ra­tion file for the Samba in­stall in the Samba con­fig­u­ra­tion direc­tory, by mak­ing a backup be­fore copy­ing the Samba con­fig­u­ra­tion file “smb.conf.”

cp /etc/samba/smb.conf /etc/samba/smb.conf.bak

>> The de­fault Samba con­fig­u­ra­tion file is won­der­fully doc­u­mented; the OC Samba con­fig­u­ra­tion file not so much. The OC file only con­tains the needed con­fig­u­ra­tion de­tails, and no sup­port­ing com­men­tary.

>> The “smb.conf” file en­ables Samba to dis­trib­ute spe­cific in­for­ma­tion. The pur­pose of this con­fig­u­ra­tion de­tail is to make Samba a part of the Potemkin vil­lage. If you mod­ify the file’s con­tents, avoid pro­vid­ing de­tails that can help the bad guys un­cover the ruse. Us­ing a server string such as “SAMBACANARY” is less than ideal if you are try­ing not to dis­close the server’s true pur­pose.

>> Us­ing your fa­vorite text ed­i­tor, cre­ate the file “/etc/ rsys­log.d/samba.rsys­log.conf” con­tain­ing the fol­low­ing con­fig­u­ra­tion en­tries on sep­a­rate lines: $FileCreateMode 0644 local7.* /var/ log/samba-au­dit.log

this es­tab­lishes sys­log sup­port for samba.



For this fi­nal round of test­ing, let’s ex­pand the OC con­fig­u­ra­tion to en­able all ser­vices sup­ported by OpenCa­nary, in­clud­ing Samba. Us­ing a text ed­i­tor, mod­ify the work­ing “openca­nary.conf” file to re­place all the false val­ues with true . In ad­di­tion, re­store the con­fig­u­ra­tion that pro­vided email sup­port in the ap­pli­ca­tion. We are now ready to test. Stop and start the OC ap­pli­ca­tion to es­tab­lish the OC con­fig­u­ra­tion.

>> Run the net­stat com­mand re­place­ment ss to dis­cover the ser­vice ports sup­ported by OC when con­fig­ured. There should be a raft of ports avail­able. Ser­vice/port(s) “ftp.en­abled”: 21

“http.en­abled”: 80 “smb.en­abled”: 137, 138, 139, 445 “mysql.en­abled”: 3306 “ssh.en­abled”: 8022 “rdp.en­abled”: “sip.en­abled”: 5060 “snmp.en­abled”: “ntp.en­abled”:123 “tftp.en­abled”: 69 “tel­net.en­abled”: 23 “mssql.en­abled”: 1433

“vnc.en­abled”: 5900

>> Scapy and Pcapy are two ad­di­tional soft­ware in­stalls found in the OC sup­port pages. Few de­tails are pro­vided on what they are re­quired for. We spec­u­late that they may be part of the ad­di­tional con­fig­u­ra­tion work re­quired to en­able rdp and snmp, sim­i­lar to es­tab­lish­ing Samba sup­port in OC.

>> From an ex­ter­nal com­puter, ac­cess the file shared by Samba. If the OC con­fig­u­ra­tion is cor­rect, an email mes­sage, marked “A” [ Image D], is sent, which can be cor­re­lated to the mes­sage in the Samba au­dit log, marked “B.”

>> The other ser­vices can be tested by try­ing to ac­cess them us­ing nor­mal tools to make con­nec­tions. A MySQL con­nec­tion call or a TFTP re­quest should be enough to gen­er­ate an alert. Of course, if this de­vice was go­ing to be de­ployed in a pro­duc­tion en­vi­ron­ment, the doc­u­men­ta­tion would in­clude all the con­fir­ma­tion tests we’ve con­ducted, to de­ter­mine whether the hon­ey­pot we have cre­ated is pro­vid­ing the ser­vices re­quired.

>> Let’s ex­pand the test­ing by us­ing the Nmap: Net­work Map­per tool on a sep­a­rate host ma­chine, and have it ex­am­ine the OpenCa­nary de­vice [ Image E]. Nmap is an open-source tool for ex­am­in­ing net­works. It is sim­ple (belly laugh) to use and is ideal for se­cu­rity au­dit­ing—it’s sim­ple in the sense of pro­vid­ing a com­mand to gen­er­ate re­sults; ex­trap­o­lat­ing those re­sults is a whole other ex­er­cise.

>> Nmap can be used to de­ter­mine which hosts are avail­able on the net­work, which ser­vices those hosts are of­fer­ing, which op­er­at­ing sys­tems (and OS ver­sions) they are run­ning, what type of packet fil­ters/fire­walls are in use, and more.

>> We can’t say we rec­og­nize the “oa-sys­tem” ser­vice shown in the screen­shot. A check of the OC con­fig­u­ra­tion shows this was es­tab­lished as an al­ter­nate SSH ser­vice, be­cause port 22 was in ser­vice pro­vid­ing SSH sup­port to de­liver the con­sole.

>> If this was a pro­duc­tion OpenCa­nary im­ple­men­ta­tion, hav­ing port 22 and port 8022 be­ing sup­ported on a de­vice sends up red flares, rais­ing ques­tions to those sniff­ing around. It might be more pru­dent to en­able SSH sup­port to the se­rial port on the de­vice through a ter­mi­nal server, make port 22 avail­able as a fake SSH of­fer­ing, and re­move the ob­scure port 8022 ref­er­ence to make the de­vice ap­pear more nor­mal. Hon­ey­pot de­sign con­sid­er­a­tions are beyond the scope of this ar­ti­cle, how­ever.

>> Try the com­mand sudo nmap -A with the IP ad­dress of the de­vice to have Nmap do some op­er­at­ing sys­tem anal­y­sis. Don’t be sur­prised if the com­mand takes a few min­utes to pro­duce re­sults—it is prob­ing all the ports dis­cov­ered, and try­ing to de­ter­mine in­for­ma­tion about the ser­vice. The out­put is pretty ex­ten­sive, so in the in­ter­est of space, it has been omit­ted here.


One of the lim­i­ta­tions of OpenCa­nary is that it doesn’t gen­er­ate any alerts from the pok­ing and prod­ding done through Nmap. If you think about it, that might be a lim­i­ta­tion to con­sider if you are de­ploy­ing a hon­ey­pot. If there is a bad guy in your net­work, one of his re­con­nais­sance tools will be Nmap. It would be ideal if the hon­ey­pot alerted you to the scans done by Nmap, be­cause this is not nor­mal ac­tiv­ity on your net­work.

There you have it, folks: OpenCa­nary con­fig­ured on a Rasp­berry Pi, send­ing alerts to an email ad­dress. There are com­pa­nies of­fer­ing hon­ey­pot ser­vices us­ing Pis. You now have an in­side scope on the open-source ver­sion of one prod­uct. Hope­fully, this tu­to­rial gives you some idea of the tech­nol­ogy and de­sign con­sid­er­a­tions needed if you had thoughts of de­ploy­ing such de­vices. Glad we could help!

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.