Jan 25 2012

Securing a server with Artillery

Artillery is project started by Dave (ReL1K) Kennedy with the aim to secure a linux web server.

Its description reads:

Artillery is a honeypot/monitoring/prevention tool used to protect Linux-based systems. Artillery will setup multiple ports on the nix system and if anything touches it will automatically blacklist them. In addition, it monitors the filesystem for changes and emails the changes back to you. It also detects SSH brute force attacks and automatically blocks them as well.

It can’t be really categorized as a honeypot since it doesn’t allow any interaction with the system, but I wanted to give it a try as an intrusion prevention tool and secure a VPS that I use for project hosting. Artillery essentially does three things: 1) it opens up various ports on the system and checks for connections. If someone abuses them it automatically adds a DROP iptables rule for that IP. 2) It checks SSH logs for brute force attempts and bans the abusing IP as well, 3) it can monitor some folders for changes, for example /var/www/.

Let’s use Artillery and see it in action. I’m using Debian 6 but the same would apply to any other distribution.

Installation is pretty straightforward:

1. First of all you will need SVN:

apt-get install subversion

2. Download the latest version of Artillery:

svn co http://svn.secmaniac.com/artillery artillery/

3. Run the installer (as root). Select no when asked to start Artillery now:

python install.py

This will install Artillery at /var/artillery. Take note of this, because the downloaded files are no longer useful (you can delete them) and any configuration has to be made in the new directory.

Take a look at the /var/artillery/config file where you can set various options. Read the comments above each choice and it should be pretty straightforward. The PORTS variable is the most interesting one since these are the ports Artillery will bind to and listen for connections. One thing to notice here is that Artillery has MySQL’s port 3306 included in the list, so if you run a MySQL server be sure to remove it. The same thing applies for some other common ports like 21 (FTP), 22 (SSH), 53 (DNS). Something for SSH: in order not to mess with Artillery at all and accidentally lock yourself out of the system, I recommend changing your SSH port anyway (for example to 2222). Generally be careful with the automatic lockout feature (don’t test it by logging into dummy ports on your system because you will be banned).

4. Reboot your system (if possible) or run the restart_server.py script. That’s it, you are ready. You can check that Artillery works correctly using:

netstat -antp

where you should see something like this (sample):

One thing you will notice is that Artillery will get results very quickly. I think this is mostly due to port 445 (SMB) because from my experience with Dionaea honeypot it gets a big amount of traffic from infected Windows computers.

While writing this post it had already banned some hosts:

5. You can check for banned IPs using:

iptables -L

and you will get a list of all the IPs (or hostnames as they are auto-resolved) with their DROP rules. For a text-based list of all the IP addresses you can view the banlist.txt file where every banned IP is written to.

Artillery is being developed and hopefully new versions will include even more functionality. I think it is a simple-to-understand and promising tool to enhance the security of a server. More results from its operation will be published in the future!

Status update

I got a message about Kippo-Geo page displaying a warning, telling you that you need a valid Google Maps API key. This started rather randomly some days ago. There are two solutions: 1) You do nothing. Yes, the Google Map is working as expected, and you can just ignore the warning. 2) Get a Google Maps API key by following the instructions on the warning link. You then need to enter your key into /kippo-graph/include/qgooglevisualapi/QApikeyGoogleGraph.class.php.

Jan 19 2012

Some Kojoney results

I had my Kojoney SSH Honeypot running for about a week or so. The operation was smooth, I didn’t experience any crashes and the logging function keeps enough interesting data. Since I’ll be moving on to other systems/projects soon, I thought I should share some data before ending its operation.

The honeypot.log file has grown to 121.447 lines and 9.0M in size.

Kojoney Statistics:

Total successful logins: 698
Total failed logins: 7818
Total number of different credentials used: 8516
Total logins with null password: 12
Total logins with or without password: 8883
Number of times a remote shell was opened: 687

Total number of distinct IP addresses: 55
Most prominent countries (by number of appearances): China (CN), Russian Federation (RU), Italy (IT), United States (US), Spain (ES).

Some interesting/funny credentials I spotted include: vagelis, slayer, sims, sims2, reebok, lammer, harrypoter, ferrari, counterstrike, adidas.

Interesting commands executed: unset HISTFILE HISTSIZE HISTSAVE
Interesting files downloaded: http://anonym.to/?http://publick11.110mb.com/tomo/gma.tgz

I’m attaching 4 graphs: top 15 successful logins, top 15 failed logins, top 15 IPs (by number of connections) along with their country of origin, top 10 commands executed by attackers.

All in all, I can recommend Kojoney as an alternative to Kippo (which is easier to setup and has better logging capabilities ie MySQL, plus you can use Kippo-Graph of course! 🙂 )

Jan 10 2012

Kojoney SSH Honeypot, installation (CentOS) and configuration

I decided to give the second well-known SSH honeypot a try, the software that Kippo was inspired by: Kojoney. It is a low interaction honeypot that emulates the SSH service, and it’s written in Python like Kippo.

I’m using a system with CentOS 5 32-bit installed, but the following should work for higher versions as well. Login as root and let’s start…

1. First of all, since we’ll still want to be able to connect to our own machine, we must change the default SSH port 22 to something else:

vi /etc/ssh/sshd_config

You need to uncomment the “#Port 22” line and change “22” to whatever you want (take note of it), let’s say 2222.

Restart the ssh server for the change to take effect:

/etc/init.d/sshd restart

At this stage you might want to logout of the system and connect again using the new port.

2. Let’s update the system and install required software:

yum update

Kojoney requires the following packages that can be installed through yum:

yum install gcc python python-devel

3. Download Kojoney itself:

cd /tmp
wget http://dfn.dl.sourceforge.net/project/kojoney/kojoney-
tar -xvf kojoney-

4. (OPTIONAL) The Iran Honeynet Project has created some updated packages to use with Kojoney making its geolocation feature better and also adding new sections to the report file. It would be good to install them:

cd /tmp
wget http://www.honeynet.ir/software/kojoney-update/TwisteConch-0.6.0.tar.gz
wget http://www.honeynet.ir/software/kojoney-update/IP-Country-2.27.tar.gz
wget http://www.honeynet.ir/software/kojoney-update/Geography-Countries-2009041301.tar.gz
wget http://www.honeynet.ir/software/kojoney-update/kojreport
/bin/cp -vf /tmp/TwisteConch-0.6.0.tar.gz /tmp/kojoney/libs/
/bin/cp -vf /tmp/kojreport /tmp/kojoney/reports/
rm -rfv /tmp/kojoney/reports/ip_country/*
/bin/cp -vf /tmp/IP-Country-2.27.tar.gz /tmp/kojoney/reports/ip_country/
/bin/cp -vf /tmp/Geography-Countries-2009041301.tar.gz /tmp/kojoney/reports/ip_country/

The above files are also stored here for backup purposes: kojoney-update-files

5. Let’s install Kojoney and run it:

cd /tmp/kojoney

I got an error here because the script wasn’t able to locate the man directory. Hopefully it asks for it so type the following: /usr/share/man/man1 (“1” is not a typo) if required.

echo "/etc/init.d/kojoney start" >> /etc/rc.local
/etc/init.d/kojoney start

You can check that everything is working alright by using

ps aux | grep kojoney

where you should see something like:

root  1573  0.0  1.4  14904  7748 ?  S  Jan09  0:33 python /usr/bin/kojoneyd

and also:

netstat -antp

where you should see something like this:

Proto Recv-Q Send-Q Local Address  Foreign Address  State   PID/Program name
tcp        0      0*       LISTEN   1573/python

6. Where is what? Kojoney itself is installed at “/usr/share/kojoney/” by default. You can go there to have a look at its source files. The log file it creates is located at “/var/log/honeypot.log“. Kojoney already has a built-in list of common username and password combinations, stored at “/etc/kojoney/fake_users“. If somebody enters a combo found in this file, he’s got access. Finally, the binary is stored at “/usr/bin/kojoneyd“.

7. There is a script distributed with it to make log parsing and statistics display easy. It is called kojreport and you can test it like this:

/usr/share/kojoney/kojreport /var/log/honeypot.log 0 0 1 > /tmp/report.txt
cat /tmp/report.txt

8. Kojoney has some problems like Kippo. The responses for various commands are hardcoded and you might need to change them. You can alter the existing ones or create your own as well.

There are specifically two files you need to pay attention to. Both of them are located at the base directory (/usr/share/kojoney/) and are called coret_fake.py and coret_honey.py.

“coret_fake.py” includes all the responses to various commands. I would suggest changing at least the following: FAKE_SSH_SERVER_VERSION, FAKE_OS (your own or uncomment and edit another one from the list), FAKE_SHELL and FAKE_W.

The second file, “coret_honey.py” is used when you want to add responses for new commands. You first write your response constant variable into “coret_fake.py” and then add it to “coret_honey.py”. For example, if I was to create a response for the “uptime” command:

a) I would write something like:

FAKE_UPTIME = " 02:32:28 up 1 day, 21:20,  1 user,  load average: 0.00, 0.00, 0.06"

into “coret_fake.py” and

b) I would add it to “coret_honey.py” file (lines 6 & 7 below):

if uname_re.match(data):
    elif ls_re.match(data):
        for line in FAKE_LS:
            transport.write(line + '\r\n')
    elif data == "uptime":

And of course we need to restart the Kojoney service for the changes to take effect:

/etc/init.d/kojoney stop
/etc/init.d/kojoney start

9. Trying out Kojoney was not really in my plans (since I have invested time and effort in Kippo) until I found these two excellent resources that inspired me to give it a try: How To Set Up Kojoney SSH Honeypot On CentOS 5.5, Using and Extending Kojoney SSH Honeypot

Sample results will be published soon!

Jan 08 2012

Some Dionaea statistics

I thought I should share some statistics from the Dionaea honeypot, after ~4 days of operation.

My dionaea.log file is around 135MB, the SQLite database is around 68MB, and the system downloaded 45MB of malware. Automatic uploading to VirusTotal did not work for some reason though.

Using Infosanity’s script , here is the output:

python mimic-nepstats.py

Statistics engine written by Andrew Waite - www.infosanity.co.uk

Number of submissions: 21923
Number of unique samples: 205
Number of unique source IPs: 473

First sample seen: 2012-01-04 22:50:12.268572
Last sample seen: 2012-01-08 23:18:50.717549
System Uptime: 4 days, 0:28:38.448977
Average daily submissions: 5480

Most recent submissions:
2012-01-08 23:18:50.717549,,, 78c9042bbcefd65beaa0d40386da9f89
2012-01-08 23:18:40.942690,,, 0c059b0d1d5a03f69a21185987c17d5c
2012-01-08 23:18:27.638438,,, 393e2e61ff08a8f7439e3d2cfcb8056f
2012-01-08 23:18:10.518064,,, 9500da313ac9708847c5f920325027e3
2012-01-08 23:17:23.842580,,, 78c9042bbcefd65beaa0d40386da9f89

And here are the results of the gnuplotsql script:

./python3.2 gnuplotsql -d /opt/dionaea/var/dionaea/logsql.sqlite -p smbd -p epmapper -p mssqld -p httpd -p ftpd

Jan 07 2012

Kippo-Graph note

Two quick notes about Kippo-Graph: 1st, even if it doesn’t take any user input etc, I have scanned it with RIPS and Websecurify Scanner and it’s a secure web app to have in your server, just in case someone wondered. 2nd, you don’t actually have to upload it to your remote server. If you set up remote MySQL access you can get the data from your honeypot while having Kippo-Graph installed in your local machine.

Jan 05 2012

Starting with Dionaea malware honeypot

Since Kippo is doing fine and there are some other interesting things out there apart from SSH dictionary attacks, I decided to run Dionaea as well in order to get a better understanding of malware distribution.

So, I found myself on the official Dionaea website ready to proceed. The amount of information there and the manual compilations made me think that I will surely run into much trouble but hopefully this was not the case. If you follow the instructions (and you deploy the honeypot on a Ubuntu machine) you will have no problem with the installation. I still encountered some problems later though.

My first and only trouble during install was with libnl which doesn’t seem to be located at git.kernel.org anymore as written on the guide but rather at: git://git.infradead.org/users/tgr/libnl.git. Another thing to note is that Ubuntu doesn’t need udns, so don’t install it and remove the two related parameters when running ./configure for Dionaea itself. Other than that installation was fine.

I started Dionaea with:

./dionaea -D -r /opt/dionaea -w /opt/dionaea -p /opt/dionaea/var/dionaea.pid -l all,-debug -L '*'

-D makes it run as a daemon in the background. Dionaea has a rather detailed configuration file and there are a lot of options to play with. I left the default values and just changed the logging function to automatically exclude debugging information (same with the -l all,-debug parameter above). I still need to make use of the privilege dropping feature for better security, if you have any tips on that let me know.

The honeypot was running and in only a matter of minutes I got my first connections! Dionaea keeps text-based logs but saves the data in a SQLite database as well (thank god). Roughly all of them were on port 445. One thing I noticed though was that connections were being dropped constantly by my system. Thanks to the #Nepenthes IRC channel where I had to resort, I realised that my system was not actually recheable and I had to change the listen configuration to manual mode and choose my “public” network interface as Dionaea was binding only on loopback addresses. Something like addrs = { eth0 = [“”] } did the trick.

As always, I took a look at the related Infosanity’s posts for various updates and tips. I saw that Andrew has already written a script to generate some statistics. Here is what I got after ~4 hours:

python mimic-nepstats.py

Statistics engine written by Andrew Waite - www.infosanity.co.uk

Number of submissions: 20
Number of unique samples: 18
Number of unique source IPs: 18

First sample seen: 2012-01-04 22:50:12.268572
Last sample seen: 2012-01-05 02:51:15.270853
System Uptime: 4:01:03.002281

Most recent submissions:
2012-01-05 02:51:15.270853,,, d987a9af709bfd188071aa3f5e027aac
2012-01-05 02:40:36.996795,,, 628209663f62c35b996ca17850ed7862
2012-01-05 02:29:58.125629,,, a61bb611ab77e5bb2d3cab672392a928
2012-01-05 02:27:21.690987,,, 1892721678e9b975c66a8cbb6ed1f340
2012-01-05 02:21:40.608644,,, e1855fbe6cf64738bffb9dc195e38ed1

I don’t know what else to expect at this stage. For time being I will let the system run and collect some interesting (hopefully) data. I haven’t studied everything related to Dionaea yet, and I’m sure there are a lot of useful configurations and add-ons since it’s being actively developed as I’m told. If you know something that I can add to Dionaea or teach me something new about it let me know, I would appreciate it alot.

Page 27 of 30« First...1020...2526272829...Last »