Honeypot Networks

源文章地址：点击打开链接

Honeypot Networks

On this post we are going to talk about honeypots and honeypot networks, how they can be used to protect your systems. We are going to talk specifically about MHN (Modern Honey Network) a great tool to collect data from sensors and a great tool to deploy honeypots fast and easy.

What is a Honeypot?

A honeypot is a fake production machine, configured with vulnerable services that are placed outside or inside your network with specific goals:

• One of the goals is to deploy a fake server, where the attacker could waste time performing attacks. This time is used by the system administrator to block the attacker and secure the rest of the real production servers
• Another goal is to learn the techniques used by the attackers to gain and exploit the services.
• Some honeypots are capable to capture malware, exploits, etc… that helps to catch zero-day attacks and to reverse engineer them to create the protection.
• The honeypots used internally on your network could help you to catch security breaches that are using your platform to launch other attacks.

The honeypots could be a double edge tool, because if they are not used correctly could be attract more attacks to your network and if the server is compromised for any reason then your network could be vulnerable to other attacks.

There are different types of Honeypots, for example:

• Low Interaction: Low interaction Honeypots emulates the most common services, giving the impression that are vulnerable but as the service is emulated can not be exploited. The deployment and maintenance of this type of honeypots are very easy
• High Interaction: This type of Honeypots uses the real services exposing their vulnerabilities, that could help to identify new vulnerabilities on the services and could log all the process of the attack, the problem is that the deployment is difficult, the maintenance is very high and once the service is exploited successfully by the attacker could be used as a new attack vector against your network.
• Sticky Honeypots (Tarpits): This type of honeypots use unused IPs to create virtual machine emulating vulnerable services that gives the attacker a width field for attack, so the attacker could spend very long times on fake machines giving the security system time to react and block the attacker.

Then there are other types specifically designed to catch malware, database exploitations, spammers, etc…. When two or more honeypots are deployed then it is called a honeynet, there is plenty of information on the internet about Honeypots:

• What is a Honeypot?, SANS Institute
• Honeynet
• Project HoneyPot, IP Data and statistics of attacks and attackers
• Honeypot, Wikipedia

Modern Honey Network (MHN)

MHN is an open source software that simplifies the deployment of honeypot sensors and the statistic gathering at any scale to create a honeynet. It is developed by ThreatStream and has a great support and maintenance. MHN uses open source software to gather the information, sort it out and save it in a Mongo Database, that information could be accessed through a Web interface or through an API developed by them.

MHN can deploy several open source honeypots, and could be easily added others through the web interface, the deployment process of a honey pot is as simple as copy and paste on the sensor machine some commands that the server gives you, once the installation is done in the sensor then it begins to gather information through an open source protocol called hpfeeds. The actually supported honeypots are:

• Snort: Snort is not a honeypot per se but an IDS/IPS very helpful to detect attacks on your network, Sourcefire (the creator of Snort) was a acquired by Cisco but the product Snort remains OpenSource
• Suricata: Suricata is also an IDS/IPS, it has not been as longer as Snort but has a great community and is fast.
• Dionaea: Dionaea is a low interaction honeypot it exposes services like MSSQL, SIP, HTTP, FTP, TFTP, etc….
• Conpot: Conpot is a low interaction Industrial Control Systems honeypot and basically emulates some protocols used in industrial environments.
• Kippo: Kippo is a medium interaction ssh honeypot, has the ability to upload and download files and other nice features
• Amun: Amun is another low interaction Honeypot but it is not actively maintained, there are no updates since 2012.
• Glastopf: Glastopf is a very popular Honeypot that has the ability to emulate thousands of web vulnerabilities, it is actively maintained
• Wordpot: Wordpot is a WordPress emulator honeypot it is still maintained and could be expanded using plugins
• ShockPot: ShockPot is a webapp honeypot that expose the vulnerability CVE-2014-6271
• p0f: p0f is a tool that that uses passive fingerprinting to identify the OS behind a TCP connection

MHN Hardware Requirements

On the MHN Wiki Page the hardware recommendations are:

MHN Server

• 4 GB Ram
• Dual Core Processor
• 40 Gb Drive

Honeypots

• 512 Mb – 1 Gb
• Dual Core CPU
• 20 Gb Drive

Obviously that would also depend where the system is deployed, behind a firewall or directly on Internet, the placement will determine the number of attacks that you will receive and hence the quantity of resources that you will need.

MHN Installation

The installation of MHN is very simple thanks to the wonderful scripts of ThreatStream, we tested it on a Virtual Machine running Ubuntu 14.04 LTS (64 bits) with only OpenSSH installed, the installation is very easy, first install git in order to clone the MHN repository, to do that issue the following commands:

sudo apt-get update && sudo apt-get upgrade

sudo apt-get install git

Then clone the repository with:

cd /opt

sudo git clone https://github.com/threatstream/mhn

First lets add support for one honeypot that it is not configured, to do that edit the install_mnemosyne script by issuing the following commands:

cd /opt/mhn/scripts

sudo vim install_mnemosyne.sh

Edit the line CHANNELS and add at the end of the line and inside the single quote:

shockpot.events

The line should look like this:

CHANNELS=’amun.events,conpot.events,thug.events,beeswarm.hive,dionaea.capture,dionaea.connections,thug.files,beeswarn.feeder,cuckoo.analysis,kippo.sessions,glastopf.events,glastopf.files,mwbinary.dionaea.sensorunique,snort.alerts,wordpot.events,p0f.events,suricata.events,shockpot.events’

For the final installation go to /opt/mhn/scripts and install the mhm components:

cd /opt/mhn/scripts

sudo ./install_hpfeeds.sh ; sudo ./install_mnemosyne.sh ; sudo ./install_honeymap.sh

After a long time and a lot of output text you will have all the MHN components installed, to verify them issue the command:

sudo supervisorctl status

You should see the following output:

If you want to install all the sensors on the Internet (public addresses) then you should skip this step, but if you have sensors installed on a private network, then you should edit the mnemosyne configuration, to do this issue the following commands:

sudo vim /opt/mnemosyne/mnemosyne.cfg

and edit the section [normalizer] to:

ignore_rfc1918 = False

This configuration will allow that sensors with private address could communicate with the server, to accept the configuration just restart the service with:

sudo supervisorctl restart mnemosyne

To finish the installation run the last script by issuing the command:

sudo ./install_mhnserver.sh

At one point you will be prompted to enter some configuration, just configure it with your own preferences and let the script do his job:

===========================================================

  MHN Configuration

===========================================================

Do you wish to run in Debug mode?: y/n n

Superuser email: name@example.com

Superuser password: 

Superuser password: (again): 

Server base url [“http://1.2.3.4”%5D: http://192.168.1.10

Honeymap url [“http://1.2.3.4:3000”%5D: http://192.168.1.10:3000

Mail server address [“localhost”]: 

Mail server port [25]: 

Use TLS for email?: y/n y

Use SSL for email?: y/n y

Mail server username [“”]:  

Mail server password [“”]: 

Mail default sender [“”]: 

Path for log file [“mhn.log”]: 

it will take some time to finish because the script needs to initialise the database and insert the Snort/Suricata rules, but once finished you could go to the server base url configured and login with the credentials of the superuser created in the previous step.

MHN Server Installation

Once installed basically everything is done from the point of view of the server, you can deploy sensors, you could visit the website, etc… There are some tweaks that you could do, the first of them is that the server send anonymous data about the attacks to ThreatStream, if you want to disable it, run the following command:

cd /opt/mhn/scripts

sudo ./ disable_collector.sh

To enable it again run the script enable_collector.sh. If you need to change the smtp settings you need to edit the config.py located at /opt/mhn/server/config.py the procedure should be:

cd /opt/mhn/server

sudo vim config.py #Edit the SMTP settings

sudo supervisorctl restart mhn-uwsgi

Also try not to mess with the superuser configuration, you could add other users from Settings in the web application menu, but all the users are superusers there is no distinction between them, also when you delete an user it is not removed from the Database it is marked as “not active” and it cannot be reused again, unless you modify manually the database. One thing that you can do is to change manually the password of an user from the console, to do that, issue the following commands:

sudo su

cd /opt/mhn/

source env/bin/activate

cd server

python manual_password_reset.py

deactivate

exit

Troubleshooting MHN Server

If you found problems with the server you could use some commands and logs to see what is happening, the first command is supervisorctl with this command you could see the process that are running and which process has problems.

supervisorctl status #List all the processes and their statuses

supervisorctl restart [process | all] #You could restart the process or all processes

supervisorctl start [process | all] #You could start the process or all processes

supervisorctl stop [process | all] #You could stop the process or all processes

If you find that the status of one of this processes is ERROR or FATAL then you could see the errors and log of the process, you could find where the errors and logs are located by seeing the process configuration file on the directory /etc/supervisor/conf.d/ normally this files are located on /opt/mhn/server/

You could also visit the Troubleshooting page of MHN on the wiki of the git repository, here.

MHN Web Interface

The MHN Web Server is very clean and easy to understand, when first connected to the mhm server base url you will be presented with a login form, where you could login with your superuser email and password, Then you will presented with a Summary Page with some Attack Statistics, where you could see:

• How many attacks you received in the last 24 hours
• Top 5 Attackers IP Address
• Top 5 Attacked Ports
• Top 5 Attacks signature

At the top there is a Menu where you could perform some configuration and get more details about attackers, honeypots and attacks, this menu is conformed by:

• Map —> Here you could see in real time from where you are receiving he attack, if the sensor is deployed internally on your  network this information is not shown.
• Deploy —> Add, Edit and Use of the Honeypot Deployment scripts 
• Attacks —> All the attacks listed
• Payloads —> All the payloads captured by the honeypots, there are only three honeypots that could save payloads (Snort, Dionaea, Glastopf)
• Rules —> All the Snort/Suricata Rules
  • Manage
  • Download
• Sensors —> All the sensors that report to the MHN Server
  • View
  • Add
• Settings —> Settings of the MHN Server

 

Honeypots

On this section we are going to talk about the honeypots, we are going to install them to see how easy it is, to see if there are some errors in the installation or it is necessary to configure it differently. We will also perform some easy tests, to see what an attacker could expect from them, and how the honeypot react to an attack. at last we will see how the MHN server gather the information and what you could see on the Web Interface.

How install honeypot sensors

The installation of the honeypot sensors are easy and is basically the same procedure for all of them, MHN has a script for each honeypot that renders the installation very easy, you only need a server to install it, we are going to use Ubuntu 14.04 LTS with the base installation, it is recommended to access the server via console if it is not possible then install openssh, change the port and protect it through a Firewall.

To install openssh issue the following command:

sudo apt-get update && sudo apt-get upgrade && sudo apt-get install openssh-server

The configuration file for sshd is located at /etc/ssh/sshd_config, search for the port directive and change it to the port you want for example 2222, then restart the service by issuing the command:

sudo service ssh restart

To install the honeypot sensors you could go to the MHN Server web application as you configured on the previous section, once logged in successfully go to the menu Deploy, here you will find a deploy form, select the script from the dropdown menu and you will see the deploy command, use that command on the sensor to retrieve the script and execute it, obviously the sensor should reach the MHN server and should have internet access in order to install the components needed.

Once installed you could run the following commands to see if everything is installed as supposed to:

sudo netstat -tunlp #Command that list all the ports that are listening for tcp connections

supervisorctl status #Command to see the process running on the sensor

Wordpot Honeypot

As we said earlier Wordpot is a WordPress honeypot, the installation on an Ubuntu 14.04 LTS server is flawless, below you could see the results of the commands once installed:

sudo netstat -tunlp #You could see the process listening on port 80 (http)

sudo supervisorctl status

Connecting to the port 80 through a browser to the ip address of the Honeypot sensor you could see a typical fresh installed wordpress page.

In case you need to expand the functionality of the WordPress site using plugins or change the title, you could use the configuration located at: /opt/wordpot/wordpot.conf

Performing an Nmap scan to only the port 80 from an attacking machine with this command:

nmap -A -Pn -p80 192.168.10.21 

We see this response:

As you could see nmap detect the port 80 as open and identify the server as a WordPress 2.8 and running on a httpd server version 0.9.6 the one thing that could give away that it is not a real web server is that also identify that the Python 2.7.6 in the Version, nmap also could retrieve the Title of the wordpress site. This scan does not generate any type of alert on the MHN server and you could not see any attacks generated by the sensor.

If we do a simple scan using wpscan that is a wordpress site scanner using the following command:

wpscan –url http://192.168.10.21

Part of the results are shown below, on that screenshot you could see that 12 vulnerabilities are listed and also you could see that this simple scan generated entries on the MHN server.

Passive OS Fingerprinting p0f

p0f is a passive OS fingerprinting tool, that is used to identify the type of Operating System a host is running and other informations, the deployment is also very easy from MHN, p0f has an algorithm for fingerprinting based on the match of certain parameters against a database, obviously it is not an exact science, but it works very well. Once installed you could check the ports open and processes running as in Wordpot with the following commands:

sudo supervisorctl status

sudo netstat -tunlp

You could see form the output of the netstat command that p0f does not install new listening processes, and if you are protecting the ssh port behind a firewall limiting connections or behind an IPS/IDS you could have trouble getting any data, that is why normally is installed with some honeypots that expose some services that an attacker could interact with in order to get packets and hence a try for a fingerprinting.

If we combine p0f with wordpot, a connection to the webpage it does not set an alarm for wordpot but it will set an alarm for p0f, MHN only register an attack attempt to a port but it does not report anything about the type of OS, uptime and other information, also the logs of the p0f sensor are in plain text rendering very difficult the statistics and the search of information, p0f has an API and some tools have been developed to make the job easier.

If you need information about a host that is attacking the system, you could search the logs that are located on /var/log/p0f.out. you could use any method you want to do this, python script, bash script, sed, grep, etc… as an example to look for the os of a particular ip address you could use the following code:

grep -n “\[ 192.168.10.151.*\(syn\)\|os\s*=” /var/log/p0f.out

If you need more information about how p0f works you could visit this link and if you need information about the api take a look to the README file. It is important to say that the p0f attacks are saved on the Mongo DB on the MHN Server, inspecting the entries, the data about the os and the ip address is saved but is not presented to the user, maybe it is matter of time to get the information in another version of MHN.

Kippo Honeypot

As we said earlier Kippo is a medium interactive ssh honeypot, the installation on the sensor does not have any problem but you should consider some things before proceed with it.

1. Be sure that ssh server is listening on the port 22, check in the ssh configuration file in /etc/ssh/sshd_config, this is necessary because the script change the port from 22 to 2222.
2. Once the script finished the installation restart the server
3. Supervisor works without any problem to start the kippo process but does not work stopping it, to resolve this you should change the deploy script

To resolve the deployment script just go to the menu Deploy, select from the dropdown menu Kippo and at the end of the file modify the following:

command=/opt/kippo/start.sh #modify this command for the line below

command=su kippo -c “authbind –deep twistd -n -y /opt/kippo/kippo.tac -l /opt/kippo/log/kippo.log –pidfile /opt/kippo/kippo.pid”

stopsignal=QUIT #Modify this line for the line below

stopasgroup=true

Once finished modifying the script press the Update button to save it to the Server, then the installation goes without problem, as you could see that the process is running and that there are two processes listening in port 22 and port 2222.

Normally kippo will listen in the port 2222, because the port 22 need root privileges, but the deployment script invert this, kippo is listening in port 22 and sshd is listening in port 2222, that means that to manage your server you should connect to the port 2222.

There are some important things to know about Kippo, about its configuration and the form how it works, the most important things are:

• The default login and password to connect to kippo via ssh are root/123456, but you could change this behaviour editing the file /opt/kippo/data/userdb.txt, also when the attacker login into the system and use the commands useradd, and passwd the newly created user is written to this file.
• When the attacker download files using the command wget, all the files are saved on the directory /opt/kippo/dl
• You can modify the return values for different types of commands and also add new commands, for example to change the value return of the command ifconfig that the attacker issue on the honeypot you should modify the textfile located in /opt/kippo/txtcmds/sbin/ifconfig
• A neat feature is that once the attacker is done with the honeypot he usually uses the command exit to close the connection, but on Kippo the command exit does not close the connection but gives the attacker a fake prompt that simulate the close connection, that permits kippo to log commands that the attacker thinks he is issuing on his own system
• You could change the filesystem on /opt/kippo/honeyfs, editing the files here and adding more will give kippo a more realistic look
• The logs are located on /opt/kippo/log/kippo.log, you could also configure kippo to use a mysql database to do the logging you just need to change the configuration file, the sql files to create the database and tables are located in /opt/kippo/doc/sql
• Kiipo log the tty activity of the attacker in the directory /opt/kippo/log/tty, this files are saved in an uml compatibility format, to reproduce them you could use the utility playlog.py located in /opt/kippo/utils

Once installed and configured kippo will log every attempt to log to the honeypot, logging the username and password used to try to login, if the attack is successfull then it will log all the session. Doing a nmap scan (nmap -A -p22 192.168.10.21) we could see the following:

From the output we could see that it recognize the port 22 as an ssh server, the output of the version is the version that we configured on the kippo.cfg, this simple scan does not generate any kind of alarm on the MHN server.

If we use hydra to perform a brute force attack (hydra -l root -P darkc0de.lst ssh://192.168.10.21) on the server, hydra have some problems to conect to the server, but changing the tool from hydra to medusa, and performing a brute force attack as the one below:

medusa -u root -P darkc0de.lst -M ssh -h 192.168.10.21

It find the password for the root user. Obviously each time the password tried was not correct MHN logged an attack.

If you need more information about how configure kippo please visit this link.

Suricata

The installation of the Suricata deployment script on the sensor runs without problems, once the deployment script is finished you should restart the server. The suricata was configured as an IDS, listening on the interface eth0, the rules updates daily from the MHN server (where you could activate and deactivate rules) through a script located at /etc/cron.daily/update_suricata_rules.sh

As you could see there is only one process that supervisor show, and does not create any services, as expected because is an IDS. If we perform an nmap scan we found that the only port found is the ssh port, the attempts are logged into the MHN server and in the sensor as the following pictures show.

Nmap scan (nmap -A 192.168.10.21)

Sensor Log:

MHN Server:

Obviously the sensor will send attack reports to the MHN Server but the detail of this attacks are on the suricate logs that are divided like this:

• /var/log/suricata.log —> On this file you could see logs of the suricate process, start error, errors processing rules, etc… it is created and maintained by supervisor
• /var/log/suricata/ —> All the files related to outputs from suricata operation, alert logs, http request logs, dns request logs, etc…..
• /var/log/suricata/http.log —> File for http requests, not alerts.
• /var/log/suricata/fast.log —> Contain alerts consisting of a single line
• /var/log/suricata/eve.json —> Contain alerts and events in a json format for third party integration
• /var/log/suricata/unified2.alert —> Alert files in Barnyard2 format
• /var/log/suricata/stats.log —> Statistic file

The configuration files for suricata are located in /opt/suricata/etc/suricata/ and the most important files are:

• /opt/suricata/etc/suricata/classification.config —> How the alerts are prioritized
• /opt/suricata/etc/suricata/reference.config —> References to vulnerabilities databases
• /opt/suricata/etc/suricata/suricata.yaml —> Configuration file of suricata, here you could configure how suricata should behave
• /opt/suricata/etc/suricata/reference.config —> Used to reduce the number of alerts, for example I do not want to log all the icmp alerts from the same source just some of them.

IDS/IPS Configuration is a very extensive topic that we do not want to cover on this post, if you need more information about how to configure suricata please visit the project documentation.

Snort

Snort is an IDS/IPS software as Suricata, both uses the same rules and snort works identically as Suricata. The deployment script does not have any problem, this script create the same program for updating the rules in crontab.daily and does not create other services that listen for connections.

The configuration files are the same as suricata except for suricata.yaml that changes to snort.conf while the log files are located on /var/log/snort/alert. As in Suricata, the IDS/IPS operation and configuration is very extensive and we are not going to cover it on this post, if you want more information about the snort configuration, please visit the web site https://www.snort.org  were you will find more information.

Amun Honeypot

As we said earlier Amun is not actually developed anymore, so we are not going to go deep with this honeypot

Shockpot Honeypot

Shockpot is a web honeypot that expose the ShellShock Vulnerability CVE-2014-6271, ShellShock is a very complex vulnerability that affects almost every Mac OsX, Linux and Unix system, this vulnerability affect the GNU Bash (shell) of this systems that allows for a remote code execution, there has been some patches but when a patch is applied another vulnerability correlated raises, it is a very big problem and with this honeypot you could capture the scripts used to exploit this type of vulnerability. If you want to know more about this vulnerability visit this link.

The deployment script has an error that could be easily resolved, go to Deploy and select from the dropdown menu Shockpot, scroll to the finish and before the line “#Config for supervisor.” and before the “EOF” above that line insert the following:

[fetch_public_ip]
enabled = false
urls = [“http://api.ipify.org”,”http://bot.whatismyipaddress.com/”%5D

That will allow to insert on the configuration file the “fetch_public_ip” section that is used if you deploy the server with a public address, once that modification is done the installation proceed without problems, once installed you should restart the server and after the restart you could see that the process is up and running and a new service is listening on port 80:

If you connect from a browser to http://sensor_ip_address you should see the default “It Works!” default welcome page of Apache, also if you grab the response header with the following commands:

telnet sensor_ip_address 80

GET / HTTP/1.0

You will see the following header:

Where an attacker could infer that is a Debian server, with PHP and OpenSSL, as we will see this is configurable, if we do an nmap scan we will find the following:

nmap -A -p80 192.168.10.21

It is important to mention that none of this steps caused any type of attack warning on MHN, now if we try to attack the honeypot using a crafted header requested like this:

curl -H “User-Agent: () { :; }; /bin/ping -c 1 TARGET_HOST_IP” http://SHOCKPOT_IP            #Type this on a terminal window, insert the IP addresses that match your case

 We could see that the log located at /var/log/shockpot/shockpot.log report this:

While on MHN you could see the attacks:

 Learn more about the shellshock attacks against websites here.

Conpot Honeypot

Conpot is an Industrial Control System and Scada honeypot, the attacks against these types of systems are increasing rapidly in the last few years, where the security in industrial environments were relaxed, that is changing nowadays, and the security professionals are taking measures in order to protect those systems.

The installation of the conpot honeypot is easy with the deployment script, once installed you should restart your sensor. If you issue the supervisorctl status command you will see that there is only one process created, but if you issue a netstat command (netstat -tunlp) you will see that there are a few listening ports:

Conpot simulates a Siemens S7-200 PLC with some modules installed, that will expose the following services:

• MODBUS TCP —> tcp/502
• HTTP —> tcp/80
• SNMP —> udp/161
• S7COMM —> tcp/102

Doing a nmap scanning on the honeypot we have the following result:

nmap -A -p1-1000 192.168.10.21

nmap -sU -p161–script snmp-sysdescr 192.168.10.21

All this scans raised attack alarms on the honeypot and mhn:

Glastopf Honeypot

Glastopf is the best honeypot web server that it is out there, It emulates a lot of vulnerabilities and in particular the remote file injection vulnerabilities that allow you to capture the files inserted in your system by the attacker, the installation is very easy from mhm through the deploy script. Once installed restart your server, you will see that one process is controlled by supervisor.

And the netstat command gives us the following output:

As you could see the only new process exposed to the public is the http port, the mongoldb is listening only for local connections. If you perform a nmap scan targeting the server you will find the following:

nmap -A -p80 192.168.10.21

As you could see the emulated server is Apache, If we target the sensor with a web vulnerability scanner like nikto (nikto is a very noisy scanner, probably not the tool that an attacker would use, but it is a very good web scanner) we will find the following:

nikto -h 192.168.10.21

As you could see nikto reported 5536 items, obviously the honeypot it is an attractive target to an attacker, if we go to the MHN server we will see all this attacks reported, but if we click on Payload and select from the dropdown menu glastopf.events, we will be presented with a lot of entries, if on the “Regex term” we type “rfi” and filter the results we will see something like this:

On the filename we will see the md5 hash of the file downloaded, on the sensor you could find this files on the directory /opt/glastopf/data, just type:

cd /opt/glastopf/data/file

sudo ls -la #will list all the files to analyze

Glastopf is very configurable, the configuration file is located in /opt/glastopf/glastopf.cfg, while the logs are located on /opt/glastopf/log/glastopf.log. If you want to learn more about glastopf visit this link.

Dionaea Honeypot

Dionaea exposes a few services, and permit to catch and save any file sent by the attacker, the installation from MHN server is very easy and goes smooth, without any problem. Once installed you need to reboot the server. Diaonea create only one process monitored by supervisor as you could see below:

Exposing the following services:

As you could see there are 10 services exposed listed below:

tcp/5060 —> SIP Protocol

tcp/5061 —> SIP Protocol over TLS

tcp/135 —>  Remote procedure Call RPC

tcp/3306 —> MySQL Database

tcp/42 —>  WINS Protocol

tcp/21 —> FTP Protocol

tcp/1433 —> MSSQL

tcp/445 —> SMB over TCP

udp/5060 —> SIP Protocol

udp/69 —> TFTP

Let’s try to do a NMAP scan to see how the system react and what information we could get:

nmap -sS -sV -p1-65535 192.168.10.21

As you could see for the tcp ports the nmap is very effective and you could see that it recognise the ftp and smb services as a Dionaea Honeypot, this scan generate a lot of logs in the honeypot that are reported back to the MHN Server, if we do also a scan for the udp ports we have:

nmap -sU -sV -p69,5060 192.168.10.21

Sadly there is no form to configure the banner that dionaea send for the services and that nmap uses to identify the service, the only option is to modify the python scripts that emulates the service in /usr/lib/dionaea/python/dionaea, if you need more information about this, please visit this link. The configuration file of the honeypot is located in /etc/dionaea/dionaea.conf, where you could change some of the features of the honeypot. The logs are located in /var/dionaea/log/dionaea.log.

 By doing a Vulnerability Scan using Nessus, we could see that it reports 53 issues, which 45 are only Info and 3 are Critical.

 Lets concentrate on the vulnerability MS04-007, This vulnerability states that it is possible to execute arbitrary code on this host sending specially crafted ASN.1 encoded packet, if we get the details of this vulnerability it says that it could be exploited with Metasploit using the “MS04-007 Microsoft ASN.1 Library Bitstring Heap Overflow” module. With metasploit we launch the attack and it failed with the error “The SMB server did not reply to our request”, this attempt however create an entry on the mhm server as an attack and also it created an entry with details of the attack on /var/dionaea/bistreams/.

Conclusions

We saw a quick overview of the mhm server, how to install it and how the honeypot deployment on a sensor was, we cover a little bit about how the sensors behave what are the good and the bad things that almost each sensor have. We think that the implementation on a honeynet it is very useful if you know what you are doing, this type of deployments could give you a more accurate info about how to fight the attackers and could give you a real sense of the threat level against your systems, the information gathered on the mhm server could be used when mixed with other tools to block attacks, or to prevent attacks to your systems. We also think that the sensor should be deployed exposing various services and should be masked well so the attacker waste a lot of time attacking it, so you can gather more information from it. That means that it is recommended not install one honeypot in a sensor but a mix of them that can complements between them, for example Snort, Glastopf, Dionaea and Kippo. We encourage you to try this on a lab before run it on your system.