HOW TO

Honeypot role-playing for the Pi; protect your identity; master Chrome’s malware tool; create a pop-art portrait; tighten security.

EARLY WARNING SYSTEMS provide alerts to pending issues, so immediate action can be taken to prevent or reduce further damage. “Honeypot” is a term assigned to a computer system designed to detect unauthorized access to the resources it makes available. Honeypots are configured to look like legitimate computer resources on a network; the computer can be posed to look like a fileserver containing data that would appeal to an attacker. A honeypot webserver, a honeypot database, or a honeypot application server would have resources staged as bait to attract the adversary. When the attacker tries to gain access to a specific resource, it is blocked, because the resource is fake. However, the attempt triggers an alert, and can be logged for analysis.

If an attacker has entered your network, depending on its configuration, it may be fairly easy for them to move around undetected. Using a simple Raspberry Pi, we can build a juicy-looking resource, which generates an alert revealing the attacker’s presence when it detects them trying to access the system. The extensive list from the Awesome Honeypot resource ( https://

github.com/paralax/awesome-honeypots) details the multiple flavors of honeypots available. Let’s install and test the open-source offering of OpenCanary (OC).

1 BASELINE BUILD

The bill of materials for this exercise is simple. Any version of Pi 2/3 hardware is acceptable. Even Pi Zero hardware with a wired or wireless network will work. The hardware required is minimal, because the device will be configured to simulate a service, not provide it. The operating system used in this project is 2018-03-13-raspbian-stretch-lite. The OpenCanary application software didn’t have a version number, but can be downloaded from https://github.com/thinkst/opencanary.

>> A network-supported Pi 3 running Raspbian Stretch Lite was deployed for this project. Not all the software and application bells and whistles offered in the full Raspbian install are needed for this build. The project doesn’t need a GUI, so there is no need to load the software. The Raspbian Lite version is acceptable for use in this project.

>> The configuration changes are done from the console command-line interface (CLI). The console is accessed using an SSH connection. The details to instantiate the Pi and establish the connection aren’t covered here, but there’s a number of resources that describe how to accomplish these prerequisites ( www.raspberrypi.org/documentation/remote-access/ssh/).

>> This device will be hosting fake services. To ensure the device is secure, we are going to baseline what service ports are available, and then apply some service hardening. The

CLI command netstat -plutn is an ideal command to remember for listing which service ports are available [ Image A].

>> If you are not familiar with the naming convention for port services, drop the “n” from the command

netstat -plut . This removes the port number to service lookup translation. Now you don’t have to remember that SSH is port 22.

>> Start the exercise of baselining the system by issuing the netstat command to get an idea of what ports are currently open. When the services reconfiguration below is completed, run the command again to see the results of the cleanup: sudo service --status-all sudo systemctl disable avahi-daemon sudo systemctl disable bluetooth sudo systemctl service rsync disable sudo systemctl disable motion

>> Retain this port knowledge as the baseline for the system. Any port additions that appear in the list from this point forward are a result of something changing. When making software changes, it is best practice to do a port check to confirm nothing has been added as a result of the change. Because this honeypot is being

configured as bait, we don’t want to leave any ports exposed that we don’t want to make available.

2 CAGING THE CANARY

Let’s add some software prerequisites for the OC installation. Countless times, software installs fail due to local repository content being stale. It is best practice—or let’s just say it will save you some headaches—if you make it a habit to perform a software update before any software additions. sudo apt-get update sudo apt-get install git python-virtualenv python-pip pythondev libssl-dev libffi-dev samba

Not all the Potemkin village (a construction, literal or figurative, built solely to deceive others into thinking that a situation is better than it really is) built of the services supported through OC is available in the application. Samba, for example, must be fully installed and set to “autostart” for it to be used by OC. The Samba configuration file provided in the OC installation must be installed in Samba to enable the service.

The documentation indicates that OC is to be installed in a Python virtual environment. Some systems require different versions of the same software library. The separation provided by virtual environments makes managing multiple software libraries easier. Creating the honeypot in a virtual environment enables the device to keep the honeypot service separate from other services. However, trying to use a honeypot to provide additional services should raise security concerns, if you think about it. We won’t argue with the design to use a virtual environment. Create the Python environment, then enter (or source) the environment. Clone the Github software installation directory, change to the directory, and start the OC installation: virtualenv -p python2 canary-env source ./canary-env/ bin/activate git clone https://github.com/thinkst/opencanary cd opencanary/ python setup.py install

OC ships with a default configuration file. The installation

docs indicate the opencanaryd –copyconfig command can be used to position the configuration file correctly in order for the app to start. The command failed to work. Reading the error message displayed on the screen, and a quick cull of Internet search results, suggested copying the OC configuration file to the proper location manually to establish a working config file: sudo mkdir /etc/opencanaryd sudo cp ~/opencanary/opencanary/data/settings.json /etc/ opencanaryd/opencanary.conf

Before giving in to the immediate impulse to issue the command to start the application, let’s make some OC configuration changes, to give us an idea of what OC is actually starting. Using your favorite text editor, modify the “/etc/opencanaryd/opencanary.conf” file. Replace all true values with false , with the exception of “telnet.

enabled”: true, 23 . This true value leaves us one service for testing. Be extra careful when modifying the contents of this configuration file; syntax errors cause a failure in the startup of the OC application.

>> A main page call from the CLI for opencanaryd provides a list of the operations the command supports. The start options worked from the CLI, and gave the appearance of working ( the log files indicated that the application started) when used in the autostart configuration. The impression was different from what was actually happening. The OC application went into a loop of continuous restarts when the start option was used. The stop option appeared to have worked from the CLI. As mentioned, –copyconfig didn’t deliver what it promised. Proven through testing, the following command was used to fire up the application:

opencanaryd --dev

>> The application generates output to the screen, eventually reaching stasis. Recall that the OC configuration was modified to initiate one service: Telnet. The following lines appear in the text outputted to screen: Added service from class Telnet in opencanary. modules.telnet to fake.... ServerFactory starting on 23, as an indication OC is now supporting telnet . >> Open a second console window to the OC device. Then issue the netstat command flavored -plutn to check which ports are open—see annotation “B” [ Image B]. TCP port 23 should have taken residence in your port scan. Recall that we installed the Samba after we baselined the open ports. That installation added port 137, shown in the screenshot. To test the configuration, initiate a Telnet session from a separate host machine to the OpenCanary device (annotation “A”). Login fails, but each attempt generates output from OpenCanary (annotation “C”).

3 CONFIGURING EMAIL ALERTS

Return to the screen that is outputting the log information, and press Ctrl–C to stop the OC

application, and return a CLI prompt. Now open the working “opencanary.conf,” and make the following changes to have the alert messages sent to an email account.

>> Insert the mail configuration details into the script using the screenshot above [ Image C] to determine where the information should be positioned in the file. Remember: Syntax errors cause an OC startup to fail. “SMTP”: {

“class”: “logging.handlers.SMTPHandler”, “mailhost”: [“authenticated.mail.server”, 25], “fromaddr”: “canary@yourdomain.com”, “toaddrs” : [“youraddress@yourdomain.com”], “subject” : “OpenCanary Alert”, “credentials” : [“myusername”, “password1”] },

>> You need to substitute the email configuration values from your provider with the placeholder values in the configuration. Email providers may make these details available on their website or in documentation. Without accurate mail server setting, establishing email support in OC is near impossible.

>> Port 25, shown in the script, is the standard port value for the SMTP protocol. Do not assume your provider uses this value. In addition, the email configuration provided from the OC site and in the documentation doesn’t reflect secure mail services. We’ve provided the secret sauce (the attribute to support secure mail services) required in the OC configuration in order for the service to function. The values used in our configuration are grayed-out, but the secret-sauce text dependencies are there.

>> Fire up the OC application again, and the email account defined in the configuration should receive messages. Once email is confirmed to be working, disable email alerts. With all the services OC supports enabled, 12 email messages are delivered as part of the startup. To avoid the message rush, it is recommended that email support be disabled during development.

4

ADD A LITTLE SAMBA

The Samba OpenCanary module monitors a log file produced by the Samba full_ audit VFS module. The process to have OpenCanary support Samba has more overhead than we have encountered for services so far. OpenCanary requires Samba to be installed and functioning on startup. The Samba app must be configured to have its events written to “syslog LOCAL7.” The syslogger application must be configured to log to the “/var/log/samba-audit.log” file.

>> Let’s preserve the default configuration file for the Samba install in the Samba configuration directory, by making a backup before copying the Samba configuration file “smb.conf.”

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

>> The default Samba configuration file is wonderfully documented; the OC Samba configuration file not so much. The OC file only contains the needed configuration details, and no supporting commentary.

>> The “smb.conf” file enables Samba to distribute specific information. The purpose of this configuration detail is to make Samba a part of the Potemkin village. If you modify the file’s contents, avoid providing details that can help the bad guys uncover the ruse. Using a server string such as “SAMBACANARY” is less than ideal if you are trying not to disclose the server’s true purpose.

>> Using your favorite text editor, create the file “/etc/ rsyslog.d/samba.rsyslog.conf” containing the following configuration entries on separate lines: $FileCreateMode 0644 local7.* /var/ log/samba-audit.log

this establishes syslog support for samba.

5

WRAP UP TESTING

For this final round of testing, let’s expand the OC configuration to enable all services supported by OpenCanary, including Samba. Using a text editor, modify the working “opencanary.conf” file to replace all the false values with true . In addition, restore the configuration that provided email support in the application. We are now ready to test. Stop and start the OC application to establish the OC configuration.

>> Run the netstat command replacement ss to discover the service ports supported by OC when configured. There should be a raft of ports available. Service/port(s) “ftp.enabled”: 21

“http.enabled”: 80 “smb.enabled”: 137, 138, 139, 445 “mysql.enabled”: 3306 “ssh.enabled”: 8022 “rdp.enabled”: “sip.enabled”: 5060 “snmp.enabled”: “ntp.enabled”:123 “tftp.enabled”: 69 “telnet.enabled”: 23 “mssql.enabled”: 1433

“vnc.enabled”: 5900

>> Scapy and Pcapy are two additional software installs found in the OC support pages. Few details are provided on what they are required for. We speculate that they may be part of the additional configuration work required to enable rdp and snmp, similar to establishing Samba support in OC.

>> From an external computer, access the file shared by Samba. If the OC configuration is correct, an email message, marked “A” [ Image D], is sent, which can be correlated to the message in the Samba audit log, marked “B.”

>> The other services can be tested by trying to access them using normal tools to make connections. A MySQL connection call or a TFTP request should be enough to generate an alert. Of course, if this device was going to be deployed in a production environment, the documentation would include all the confirmation tests we’ve conducted, to determine whether the honeypot we have created is providing the services required.

>> Let’s expand the testing by using the Nmap: Network Mapper tool on a separate host machine, and have it examine the OpenCanary device [ Image E]. Nmap is an open-source tool for examining networks. It is simple (belly laugh) to use and is ideal for security auditing—it’s simple in the sense of providing a command to generate results; extrapolating those results is a whole other exercise.

>> Nmap can be used to determine which hosts are available on the network, which services those hosts are offering, which operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and more.

>> We can’t say we recognize the “oa-system” service shown in the screenshot. A check of the OC configuration shows this was established as an alternate SSH service, because port 22 was in service providing SSH support to deliver the console.

>> If this was a production OpenCanary implementation, having port 22 and port 8022 being supported on a device sends up red flares, raising questions to those sniffing around. It might be more prudent to enable SSH support to the serial port on the device through a terminal server, make port 22 available as a fake SSH offering, and remove the obscure port 8022 reference to make the device appear more normal. Honeypot design considerations are beyond the scope of this article, however.

>> Try the command sudo nmap -A with the IP address of the device to have Nmap do some operating system analysis. Don’t be surprised if the command takes a few minutes to produce results—it is probing all the ports discovered, and trying to determine information about the service. The output is pretty extensive, so in the interest of space, it has been omitted here.

6 THIS IS A DEAD CANARY

One of the limitations of OpenCanary is that it doesn’t generate any alerts from the poking and prodding done through Nmap. If you think about it, that might be a limitation to consider if you are deploying a honeypot. If there is a bad guy in your network, one of his reconnaissance tools will be Nmap. It would be ideal if the honeypot alerted you to the scans done by Nmap, because this is not normal activity on your network.

There you have it, folks: OpenCanary configured on a Raspberry Pi, sending alerts to an email address. There are companies offering honeypot services using Pis. You now have an inside scope on the open-source version of one product. Hopefully, this tutorial gives you some idea of the technology and design considerations needed if you had thoughts of deploying such devices. Glad we could help!