1.0 DEPLOYMENTS
1.1 Current technologies deployed
We are running two Honeynets: the first one is our production Honeynet, while the second one is used as a platform for testing new technologies.
1) Honey-1: Production Platform
We are deploying a new production Honeynet which will be shortly on-line.
Honeywall: eeyore 0.69
Honeypots:
1 Fedora Core 3 (on VMware 4.5)
1 Debian 3.0r0 (on VMware 4.5)
1 Slackware 10.0
1 WinXP Pro SP2
1 Win2003 Enterprise Server (on VMware 4.5)
Topology: http://www.honeynet.org.gr/honey1/topol1.png
2) Honey-2: Non-production Platform
Honeywall: roo 1.0a-43 (24/03/2005)
Honeypots:
1 RH 9 fully patched (Syslog, SSH)
4 honeyd virtual hosts (WinXP Pro SP1, Linux 2.4.20, Solaris 9 as a spam trap, Cisco 1601R IOS 12.1.5)
Topology: http://www.honeynet.org.gr/honey2/topol2.png
1.2 Lessons learned from the technology, what we like about it
Sharing collected Honeynet data with other members of the Alliance is an exciting capability. Also, Kanga proved to be a means for additional remote storage (see paragraph 5.1).
1.3 Lessons learned from the technology, what is lacking / needs improvement
It would be very useful if Kanga was equipped with some tools for central processing of the uploaded data. For example statistics scripts, acid on aggregated data etc.
2.0 FINDINGS
2.1 Number and type of systems compromised during six month period
Unfortunately, we haven't seen any interesting compromise. All our compromised systems were Windows honeypots exploited by several worms (Sasser, Dabber, Netsky). Unpatched Windows machines were compromised many times per day.
2.2 Unique findings, attacks, tools, or methods
-
2.3 Trends seen in the past six months
The last 4 months we have seen increased malicious traffic towards Windows machines. This is illustrated on the graph on [1] where 5 out of the 10 top scanned ports are Windows related (ports 1027/tcp, 1026/tcp, 1025/tcp, 445/tcp, 135/tcp). For more statistics see [1].
[1] http://www.honeynet.org.gr/topten-ports4.htm
[2] http://www.honeynet.org.gr/general_statistics.htm
2.4 Data analysis tools and methods being used
Our favorite analysis tools are: Snort, tcpdump, argus, acid, demarc, ethereal, tcpslice, and some custom scripts.
2.5 What analysis tools work well and what still needs to be developed
The traffic summary scripts on eeyore are extremely helpful.
3.0 MISC ACTIVITIES
3.1 Presenting at conferences
1. Presented Honeynets to NTUA (National Technical University of Athens) in a three-sessions talk:
2. NETTIES 2004 Conference [1], “Establishing new techniques to prevent
buffer overflow network intrusions” [2]:
Presented a technique in identifying and preventing buffer overflow attacks
and how Honeynet collected data tuned the SNORT preprocessor for than purpose.
[1] http://www.netties2004.hik.hu
[2] http://vod.niif.hu/netties2004/sect-techICT.html
3.2 Developing, testing or releasing code
Further tested and optimized statistics generation scripts (HoneyStats package) [1]. We are exploring ways to apply the package to Kanga uploaded data.
[1] http://www.honeynet.org.gr/nrtm.htm
3.3 Publication of papers
-
3.4 Involvement in SotM challenges
-
3.5 Other
1. Guidance of a Aegean University undergraduate dissertation on Honeyd.
2. Deploying code for Honeyd to fight Sasser worm.
3. Discussions with University of Patras and Economics University of Athens were opened about the Honeynet Project, promoting the Project's recent book.
4. We are working on some new ideas on deploying Honeynets, which are targeted at making Honeynets more attractive. Based on context from this experimental area, we participated in the New Concepts Challenge that was announced on 02/12/2005.
5. Testing and debugging ROO Honeywall. Several bugs have been submitted.
4.0 ORGANIZATIONAL
4.1 Changes in your structure of your organization.
-
5.0 LESSONS LEARNED
5.1 Positive things we would like to share with the community
1. On middle September we experienced
a major crash to our central file server due to a combination of failed hardware
(namely, hard disks) and failed UPS. The server was holding our repository
of honeynet data and findings. We managed to recover after a horrifying
two-months period. Now, wiser than before, we are ready to share our experience:
a) recent backups, recent backups, recent backups!
b) tested data recovery procedures
c) UPSs need maintenance
2. We have a VMware image of Fedore Core 3 that we would be more than happy to share with the community. The thing about Fedora Core 3 is that it needs some kernel tweaking so as to load in acceptable timings on VMware Workstation 4.5.
3. Our involvement with Honeyd (see 3.5) produced some conclusions on its usage.
i. Honeyd is an excellent educational tool.
ii. Honeyd (combined with a honeywall) can be used inside a big campus to identify worm infections. This actually works better than Snort, because all connections received on a Windows Honeyd virtual host are worm-related and Snort signatures are not always up to date with the latest worms.
iii. Strike back is an interesting feature
iv. A collection of Honeyd virtual hosts is an effective way of testing ROO!
4. Realistic client honeypots are difficult to implement. By definition a client
machine, such as a desktop computer, requires real usage associated with the
execution of certain daily/routine manual tasks. This is not possible when deploying
a Honeynet, as every day local tampering is simply too much. On the other hand,
remote access is out of the question since we are dealing with a client honeypot
and client machines are not administered remotely. Consequently, adding client
honeypots to a Honeynet could reveal the true identity of the network. A Windows
XP machine just sitting around waiting to be whacked for too long, is raising
many suspicions.
However, a standalone client honeypot located outside the production Honeynet could be useful in exploring spam and virus techniques.
5.2 Mistakes we would like to share with the community
1. Unpatched honeypots (especially Windows) are of limited value.
2. Honeynet deployments should have an End-Of-Life (EOL) date (i.e. fixed duration of operation), to avoid an idle Honeynet (possible because your cover is blown away). Based on our experience, a 3 to 4 months period is long enough to catch something interesting.
3. Status and changes recording in Honeynets deployments is important.
4. Evaluation of resources is critical. Do not commit to something you cannot support, do not deploy more Honeynets that you can administer and analyze.
5. Established procedures for Honeynet administration can save a lot of time.
6.0 FUTURE GOALS
6.1 Plans/Goals for next six months
- Evaluate results from our newly deployed Honeynet.
- Bring in more vocational students to help on practical matters.
- Support University Honeynet deployments.
- Continue testing / evaluating ROO.
- Improve HoneyStats package, write documentation, make it installable.