|
|
To understand how Honeyd works and how it can be used, we first need to understand its basic design. To meet your desire for technical details, we talk about some specalized features and implementation details in Chapter 5 but restrict ourselves to the core features here. You can see a basic overview of Honeyd's architecture in Figure 4.3. Although every aspect of Honeyd can be controlled by configuration, there are three important characteristics that are responsible for Honeyd's overall behavior: (1) adversaries interact with Honeyd only from the network, (2) Honeyd simulates as many IP addresses as you configure; and (3) it deceives fingerprinting tools by changing each output packet to match the characteristics of the configured operating system. By understanding the limitations that result from this design, you can make an educated choice about whether Honeyd is the right tool for your problems. In the following, we provide a detailed overview for each of these design choices.
|
Code View: $ sudo ./honeyd -d -f config.sample Password: Honeyd V1.0 Copyright (c) 2002-2004 Niels Provos honeyd[8222]: started with -d -f config.sample Warning: Impossible SI range in Class fingerprint "IBM OS/400 V4R2M0" Warning: Impossible SI range in Class fingerprint "Microsoft Windows NT 4.0" honeyd[8222]: listening promiscuously on fxp0: (arp or ip proto 47 or (udp and src port 67 and dst port 68) or (ip )) honeyd[8222]: HTTP server listening on port 80 honeyd[8222]: HTTP server root at /usr/local/share/honeyd/webserver/htdocs honeyd[8222]: Demoting process privileges to uid 32767, gid 32767 |
Our primary assumption is that an adversary can interact with our honeypots only at the network level. That means that he or she cannot walk up to a computer and log in via the keyboard because there is no physical computer corresponding to any honeypot simulated by Honeyd. Instead of simulating every aspect of an operating system, we choose to simulate only its network stack. The main drawback of this approach is that an adversary never gains access to a complete system even if he compromises a simulated service. On the other hand, we are still able to capture connection and compromise attempts. We can mitigate these drawbacks by combining Honeyd with a virtual machine like VMware [94]. We will discuss how to combine different honeypots into a hybdrid system in Chapter 7. For now, it is important to understand that Honeyd is a low-interaction virtual honeypot that simulates TCP and UDP services. It also understands and responds correctly to ICMP messages.
To be a powerful and flexible solution, Honeyd can handle virtual honeypots on multiple IP addresses simultaneously. This allows it to populate the network with numerous virtual honeypots simulating different operating systems and services. To be even more realistic, Honeyd can also simulate arbitrary network topologies. To simulate address spaces that are topologically dispersed and for load sharing, Honeyd supports network tunneling.
Remember the fingerprinting tools we discussed in Section 1.3. To present realistic honeypots to the attacker, we need to deceive fingerprint tools and have them report whatever operating system we fancy. Honeyd achieves this by reversing the databases used by the fingerprinting tools. When a honeypot needs to send a network packet, it is modified by Honeyd to match the fingerprint that corresponds to the configured operating system in the database (see Section 5.1).
|
|