- About us
- Code of Conduct
- Google SoC
- Recent posts
- Security Workshops
The honeynet deployed and analysed by the German Honeynet Project in the first incident formed part of a diploma thesis ("Planung und Realisierung eines Honeynet zur Analyse realer Angriffe aus dem Internet") by a graduate student at MAGELLAN Netzwerke GmbH in Cologne, Germany. The honeynet was a high interaction research honeynet deployed by the German Honeynet Project during November 2004. The honeynet topology is depicted below:
The honeynet deployed was a typical GenII honeynet based on the three basic principles defined by the Honeynet Project: data capture, data control and data analysis.
Data capture was performed by recording all inbound and outgoing network traffic for later analysis, using packet sniffing tools such as tethereal. All network traffic to and from a RedHat Linux honeypot was mirrored via the monitor port of a network switch and logged using the popular open source Intrusion Detection System snort running in binary capture mode (as daily pcap files). To allow keystroke logging after a successful system compromise, version 2.1.7 of the Honeynet Projects Sebek kernel module was installed on the honeypot. The Redhat syslog daemon was also modified to output syslog information to the serial port for capture by the honeynet gateway.
For data control, all network traffic from the Internet was routed through a transparent bridging honeynet gateway running the FreeBSD release 4.10 operating system that limited outgoing network connections from the honeypot. Outgoing connections were identified by SYN packets, differentiated and logged by TCP connection types (such as IRC-connections), and the number of connections limited to 15 IRC-connections and 10 other TCP-connections with a 24 hour period. Connection limiting is designed to allow attackers to successfully compromise the honeypot and download a limited amount of rootkits or other malware from external servers, but to then limit their potential to attack further hosts from the compromised honeypot. It also helps to hide the presence of the honeynet gateway by not totally blocking all outbound traffic, along with preventing denial of service attacks.
For data analysis, all network traffic to or from the honeypot was mirrored to a snort IDS for pattern matching against the current signature rulebase. Manual and automated analysis of logged data was performed regularly, along with real time monitoring and alerting.
The honeynet gateway was connected to a central network switch which was used to separate network traffic from the honeypot system network and the administrative network using VLANs, a common method to logically segmented network on the same physical hardware. The honeypot itself was a standard installation of RedHat Linux version 7.1 on Intel hardware running the latest version 2.4.20 kernel with several network services such as FTP (wu-2.6.1-16), HTTP (Apache 1.3.19, OpenSSL/0.9.6) and a database (MySQL 3.23.36) server enabled. All services were left in their default configuration, except for the MySQL database which had a random secure password set for the root user. To make the system more realistic and more closely simulate a production system, a mocked up web site for an imaginary sales company was installed and reverse DNS added for the web server.
The following table depicts the timeline of the incident:
|Date / Time||Event|
|12/11/04||First data from honeypot|
|Honeypot WU-FTPd compromised by autorooter|
|Attacker manually installs rootkit, IRC bot and Ebay phishing attack content|
|Attacker returns to install and run mass scanning tool|
|Attacker returns to install proxy server|
|Attacker returns to install additional rootkit|
|Attacker returns to set up phishing web sites and sends out spam mails (blocked by Honeywall)|
|Honeypot disconnected for forensic analysis|
A more detailed incident timeline, including an analysis of the tools and techniques the attackers used, is available here.