### Greek Honeynet Project ###
Status report for October 2005 - March 2006
1.1 Current technologies deployed
Describe anything that you have deployed that is collecting information, including honeynets, client honeypots, honeyd, mwcollect, or anything else honeypot related.
No changes in the topology but a large scale migration to Roo for both the production and the experimental deployments took place.
Previous reports document our deployments: http://www.honeynet.org.gr/reports/apr2005-sept2005.html
Migration took place at the honeynet infrastructure level, at the data management system level and also on our internal server platform (cms based), which unifies all running systems, stored data, knowledge communication for the team. Moving from RH to Debian and upgrading all software components (postnuke, mySQL, wiki, scripts, etc) as well as the hardware. This has been a very time consuming and resource-absorbing task. Notable problems:
Migration has been almost completed and it is working now. Solutions to the problems above have been found (more detail further on section 3.2). All changes logged to our internal tracking system as well as to the internal wiki.
1) Honey-1: production Platform
2) Honey-2: Non-production Platform
1.2 Activity timeline: Highlight attacks, compromises, and interesting information collected.
2.1 Highlight any unique findings, attacks, tools, or methods.
As most of our work this period has been the migration to Gen III there have not been any findings except a defacement of a lab’s poorely supported site, still investigating whether the php, ptrace/kmod based attack was due to us being involved with Honeynets.
2.2 Any trends seen in the past six months.
4.0 NEW TOOLS
4.1 What new tools or technology are you working on?
A) Internal server (cms based) developments, not reported here
B) HoneyStats improvement
HoneyStas has been further developed. It has now a “package form”, will be hosted on sourceForge for public communication this month, it has a “safe” interface for viewing access logs, more flexible implementation set-up allowed (data base part, statistical processing part, web server part) and wrote documentation to fully support it.
C) Honeywall customization, data management incompatibility
1) The goal is to have PCAP files in a daily basis
The new Roo CDROM does not run snort in sniffing mode. Instead of Snort, Roo runs a tcpdump process which captures raw packets in a per hour basis and stores them in several directories inside the /var/log/pcap directory. These directories have a name pattern pcap_<Linux Timestamp>. Because we wanted to get the whole previous day's binary traffic the above impementation was not adequate at all because at first we should identify which directories belong to the previous day and then merge all the hourly log files into one.
The solution we came up with was to run another separate Snort process in sniffing mode. This process is controled by our /etc/init.d/snort-pcap.sh script. This script is executed via cron every day at 00:06. Its job is to restart the new snort process and make it log into a directory named after the current date. This directory resides inside the /var/log/snort directory and is also used by the snort-plain process (honeywall's snort process in IDS mode) which logs the snort alerts.
In this way, all the logs produced by snort IDS (snort-plain) and Sniffer(snort-pcap) are stored in a per day basis in the same directory.
2) the goal is to have Portscan Logs from Snort
snort-plain is the snort process in the Roo CDROM that runs in IDS mode. We enabled the portscan preprocessor because we also needed to log the portscans taking place in our honeynet.
The portscan logs are also stored inside the per day named directories in /var/log/snort.
3) the goal is to have IPTABLES logs in a daily basis
In the new Roo CDROM the iptables logs are logged inside the /var/log/iptables file via syslogd. This file does not seem to be rotated at all and we wanted to store iptables logs in a daily basis for the needs of our HoneyStats package.
Just adding some directives inside the /etc/logrotate.conf file or /etc/logrotate.d was not a solution because logrotate is executed via cron every day at 04:00 and we needed this rotation to take place at about 00:00.
A new logrotate process is executed via cron at 00:04 every day which reads a different configuration file /etc/logrotate_iptables.conf. This configuration file instructs logrotate to daily rotate /var/log/iptables and to keep as much as 30 log files (almost one month). It also tells logrotate to restart swatch and syslog process so that the former will inspect the new iptables log file and the later will log into this new file.
4.2 Would you like to integrate this with any other tools, or you looking for help or collaboration with others in testing or developing the tool?
We are interested for other honeynets to test and/or develop honeyStats. We have the sourceForge site almost ready.
5.1 Are you working any papers to be published, such as KYE or academic papers?
Not at the moment
5.2 Are you looking for any data or people to help with your papers?
Not at the moment
5.3 Where did you publish/present honeypot-related material?
6.1 Changes in the structure of your organization.
6.2 Your feedback on Alliance activities.
We have provided feedback on testing Roo (bugs reported related to sebek 3 and data capture on Roo, had very positive comments from the developing team)
Snort In IDS mode bug
In the Roo CDROM, snort-plain is the Snort process that runs in IDS mode. This process is controlled by the /etc/init.d/hflow_snort-plain script.
Inside /etc/init.d there is also another script called snortd which also starts a snort process in IDS mode. This script does not seem to be executed when the honeywall boots up and it must be a left over from the eeyore CDROM. The problem appears when the logrotate deamon is executed at 04:00 every day in cron.daily. This logrotate process reads the configuration file /etc/logrotate.conf which also includes several other configuration files inside the /etc/logrotate.d directory.
One of these files is /etc/logrotate.d/snort. This instructs logrotate to rotate several log files inside /var/log/snort/ which at first do not exist. Furthermore, it restarts snort by invoking the /etc/init.d/snort.d script. By invoking "/etc/init.d/snortd restart", the snort-plain process is mistakenly stopped and a new snort process is started. This is a bug of the Roo CDROM and is posted in the Honeynet bugs list.
The /etc/logrotate.d/snort file was removed and snort.d is no longer executed via logrotate.
Sebek 3 Testing
For 2.4 and 2.6 kernels, sebek 3 does not hide its packets amongst the honeypots, reported to the list firstname.lastname@example.org. Fixed source communicating with E.Balas
6.3 Any suggestions for improving the Alliance?
7.1 Which of your goals did you meet for the last six months?
We had set the following goals.
- Install Sebek in the 2.6 kernel honeypots.
- Put more stuff in the web site. PARTIALLY DONE
- Write documentation for the HoneyStats package and other related tasks.
- Fully migrate to Roo.
- Continue testing / evaluating Roo.
- Enlist new active members from Universities exploiting the positive experience of the Honeyd experiment. Influence the establishment of a new university group).
- migrate to vmware honeypots. We are almost there but hit disk problems in addition to migration problems.
7.2 Which of your goals did you not meet for the last six months?
- Obtain Gen III operational experience. This goal was not achieved due to the size of the problems we faced on several fronts. Infrastructure problems, bug problems and customization problems.
- Submit our papers for the individual's whitepapers area.
- Apply the VMware 5.0 patch written by the French Honeynet Project.
7.3 Goals for the next six months
- obtain Gen III experience
- project promotion and (people) network activities
- We observe a lot of interest on the www for our greek honeynet oriented papers so uploading them to the central site will give them much wider visibility.
8.0 MISC ACTIVITIES
8.1 Anything else not covered you would like to share.