Posted: Tue Jul 10, 2007 6:53 pm Post subject: honeyd and nmap - the solution?
A number of people have posted about problems with honeyd and nmap, usually along the lines of "It doesnt work". Well honeyd works fine with nmap in most cases. There is one configuration which does cause problems, where the nmap scanner and the honeypot are on the same network and you're using arpd (farpd) to direct traffic to the honeypot.
If you're short of time, here's the quick answer:
By default nmap will use an arp scan to determine if a host on the local network is up. Arpd is too slow to respond to the arp request, so nmap thinks the host is down and wont perform a scan. You need to patch arpd - the patch is below.
Here's the long answer, and a solution:
From the nmap manpage:
Quote:
If no host discovery options are given, Nmap sends a TCP ACK packet destined for port 80 and an ICMP Echo Request query to each target machine. An exception to this is that an ARP scan is used for any targets which are on a local ethernet network.
Note that ARP scans are performed even if the -P0 option is used. ARP discovery can be disabled using the --scan-ip option. So if you are scanning a honeypot on the local network use "nmap --scan-ip" to get the scan running.
Of course, what most people want is for their honeypots to respond to malicious nmap scans. To get that working you will need to patch arpd.
By default arpd works like this: if it sees an ARP request arpd will send its own ARP request to see if the IP address is already allocated. Two ARP requests are sent, and if arpd doesnt get a reply it will claim the IP address by sending a fake ARP reply. If another ARP request is seen before this process has completed the request is logged as "still discovering". If an ARP reply is received the reply is logged and no fake reply will be sent.
nmap runs an aggressive ARP discovery, and it cant be configured: the source code contains this fragment in targets.cc:
Code:
/* Default timout should be much lower for arp */
hostbatch[targetno]->to.timeout = MIN(o.initialRttTimeout(), 100) * 1000;
The most obvious way of speeding up the arpd response is to drop one of the ARP requests:
This patch does the trick:
- if (req->cnt < 2) {
+ if (req->cnt < 1) {
arpd_send(arpd_eth, ARP_OP_REQUEST,
@@ -406,3 +406,3 @@
- if (req->cnt >= 3) {
+ if (req->cnt >= 1) {
arpd_send(arpd_eth, ARP_OP_REPLY,
The result of this is that arpd only sends ONE ARP request before its ready to send the fake ARP reply. THIS HAS THE POTENTIAL TO BREAK YOUR NETWORK. It increases the likelihood that arpd will send a fake reply for an IP address that is already allocated.
This doesnt, however, solve the problem in itself.
Running nmap in debug mode against a patched arpd shows why:
Quote:
The max # of sockets we are using is: 0
--------------- Timing report ---------------
hostgroups: min 1, max 100000
rtt-timeouts: init 1000, min 100, max 10000
msx-scan-delay: TCP 1000, UDP 1000
parallelism: min 0, max 0
max-retries: 10, host-timeout: 0
---------------------------------------------
Initiating ARP Ping Scan at 23:44
Scanning 172.16.1.100 [1 port]
Pcap filter: arp and ether dst host FE:FD:00:00:00:04
Packet capture filter (device eth0): arp and ether dst host FE:FD:00:00:00:04
SENT (0.1070s) ARP who-has 172.16.1.100 tell 172.16.1.5
(FE:FD:00:00:00:04 is the MAC address of the nmap host)
nmap is looking for an ARP reply. But arpd sends the fake ARP reply as a broadcast - you can see this by sniffing the traffic -
That ffffffffffff is a broadcast address - nmap simply doesnt see this reply.
The answer is to patch arpd so that it sends ARP replies to the host which issued the initial ARP request - the relevant code is in arpd.c in arpd_recv_cb function:
If we replace the reference to ETH_ADDR_BROADCAST with the MAC address from the initial ARP request, then we get a directed fake ARP reply. The full patch look like this:
- if (req->cnt >= 3) {
+ if (req->cnt >= 1) {
arpd_send(arpd_eth, ARP_OP_REPLY,
And now nmap works:
Quote:
The max # of sockets we are using is: 0
--------------- Timing report ---------------
hostgroups: min 1, max 100000
rtt-timeouts: init 1000, min 100, max 10000
msx-scan-delay: TCP 1000, UDP 1000
parallelism: min 0, max 0
max-retries: 10, host-timeout: 0
---------------------------------------------
Initiating ARP Ping Scan at 23:24
Scanning 172.16.1.100 [1 port]
Pcap filter: arp and ether dst host FE:FD:00:00:00:04
Packet capture filter (device eth0): arp and ether dst host FE:FD:00:00:00:04
SENT (0.0820s) ARP who-has 172.16.1.100 tell 172.16.1.5
**TIMING STATS**: IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ccthresh/delay, timeout/srtt/rttvar/
Groupstats (1/1 incomplete): 1/*/*/*/*/* 10.00/50/* 100000/-1/-1
172.16.1.100: 1/0/0/1/0/0 10.00/50/0 100000/-1/-1
RCVD (0.0850s) ARP reply 172.16.1.100 is-at FE:FD:00:00:00:02
Timeout vals: srtt: -1 rttvar: -1 to: 100000 delta 3401 ==> srtt: 3401 rttvar: 5000 to: 100000
Timeout vals: srtt: -1 rttvar: -1 to: 100000 delta 3401 ==> srtt: 3401 rttvar: 5000 to: 100000
Completed ARP Ping Scan at 23:24, 0.06s elapsed (1 total hosts)
mass_rdns: Using DNS server 194.72.0.98
Initiating SYN Stealth Scan at 23:24
Scanning target (172.16.1.100) [1697 ports]
Pcap filter: dst host 172.16.1.5 and (icmp or (tcp and (src host 172.16.1.100)))
Packet capture filter (device eth0): dst host 172.16.1.5 and (icmp or (tcp and (src host 172.16.1.100)))
Packet capture filter (device eth0): dst host 172.16.1.5 and (icmp or (tcp and (src host 172.16.1.100)))
SENT (0.1690s) TCP 172.16.1.5:56115 > 172.16.1.100:389 S ttl=59 id=42796 iplen=44 seq=1381261536 win=4096 <mss 1460>
SENT (0.1980s) TCP 172.16.1.5:56115 > 172.16.1.100:443 S ttl=42 id=47474 iplen=44 seq=1381261536 win=3072 <mss 1460>
SENT (0.1980s) TCP 172.16.1.5:56115 > 172.16.1.100:113 S ttl=54 id=42001 iplen=44 seq=1381261536 win=3072 <mss 1460>
SENT (0.1980s) TCP 172.16.1.5:56115 > 172.16.1.100:554 S ttl=38 id=11066 iplen=44 seq=1381261536 win=3072 <mss 1460>
This has the benefit of minimising the potential for network damage, since the fake ARP reply is directed at the querying host.
Its only a quick hack, and not perfect. Since the fake ARP isnt being broadcast its limited in potential, but it is a quick way to have your honeypots responding to nmap scans from the local network.
EDIT : dam*, i only find sources 0.2 for farpd. I tried to apply the patch to 0.2-8 it doesn't seem to work. When i configure i have missing libraries (which are installed of course, farpd was working before)
EDIT2 : problem solved.
jons you're a genious
Hmmm but a strange thing, maybe because I compiled and installed (make, make install) over an existing installation... Doesn't work when i launch farpd, but when i launch arpd it works...
It's a diff file - it shows the differences between files. To save manual editing you can apply the diff file by using the patch command.
Have a look at the manpages for diff and patch.
Exactly what I needed. Thanks, I got it patched and OS fingerprinting works perfectly.
Quote:
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-07-19 15:39 PDT
Interesting ports on [snip] (192.168.101.137):
Not shown: 1675 closed ports
PORT STATE SERVICE
21/tcp open ftp
137/tcp open netbios-ns
139/tcp open netbios-ssn
1080/tcp open socks
3128/tcp open squid-http
MAC Address: 00:03:47:C1:1A:38 (Intel)
Device type: general purpose
Running: Microsoft Windows NT/2K/XP
OS details: Microsoft Windows XP Pro SP1
Nmap finished: 1 IP address (1 host up) scanned in 2.350 seconds
PS - Sorry it took me so long to respond. I got busy and had to put the honeyd box aside for a bit.
The arp support in honeyd works fine (nice work ), and doesnt generate any problems with nmap. I guess it's because most people use arpd to get traffic to their honeypots that we see the posts about nmap not working. The note was specific to one common scenario, and I tried to make this clear in the posting:
Quote:
Well honeyd works fine with nmap in most cases. There is one configuration which does cause problems, where the nmap scanner and the honeypot are on the same network and you're using arpd (farpd) to direct traffic to the honeypot.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
