Nmap Development mailing list archives
Re: [NSE] NTP Peer Listing
From: jah <jah () zadkiel plus com>
Date: Sun, 11 Apr 2010 18:54:52 +0100
On 11/04/2010 02:14, Mak Kolybabi wrote:
Attached is an el-cheapo straight-up rip-off of the Metasploit plugin that lists the most recent hosts that have connected to an NTP server. Some additional features that I'm considering are: - Sorting the list of addresses. - Separating the list between RFC1918 addresses and non-RFC1918 addresses. Suggestions and testing would be appreciated.
Hi Mak, All, Maybe we should join forces on this script - I've written a similar script which is not quite finished. The current version is in an experimental svn branch at: nmap-exp/jah/scripts/ntp-monlist.nse There are some differences between our scripts: I found quite early-on that, whilst using nsock to receive the monlist data, I wasn't getting all of the replies - that is, the target sent more data than the script received. So I decided to use pcap to listen for the replies and then decided to use dnet to send the query so that I could control the source port and use it in the capture filter. I decided the four hundred plus IP addresses is too much output from a script and so it dumps them to file. It prints a summary instead: PORT STATE SERVICE REASON 123/udp open ntp udp-response | ntp-monlist: dumped 426 discovered IPv4 addresses to file: | scripts/data/ntp-monlist-10.10.10.123.list | and discovered internal addresses: | 172.16/12 (71), 192.168/16 (5) | and discovered 1 ntp server: |_10.10.187.123 This output has changed a bit in my working copy: PORT STATE SERVICE REASON 123/udp open ntp udp-response ... as above ... | 172.16/12 (71), 192.168/16 (5) | and discovered 1 alternative address for the target: |_10.10.187.123 to better reflect what the discovered ntp server actually means. My working copy also collects IPv6 adresses: PORT STATE SERVICE REASON 123/udp open ntp udp-response | ntp-monlist: dumped 5 IPv4 and 1 IPv6 address to file: | scripts/data/ntp-monlist-192.168.1.21.list | and discovered internal addresses: | 192.168/16 (1) | and discovered 1 alternative address for the target: |_2a01:348:1a6:0:0:0:0:253a It doesn't sort the address list as yours does, but it does comment-out IPv6 and private IPv4 addresses so that the list can be passed to nmap -iL (with a caveat that your external address may appear in the results). It doesn't output port numbers - I didn't consider them particularly useful and I'm also not clear on whether they're source or destination ports (I think they might be destination ports, but in the context of client-server, server-client and peer-peer communications). The query my version sends contains a 40 byte data section as described in ntp_request.h [1] and the total query length is way smaller than those sent in the metasploit and sensepost scripts. There are some things I still want to do to the script: There are two data structures that can be returned by an ntp server for a monlist query in addition to the info_monitor_1 that we handle: info_monitor and old_info_monitor. I haven't determined under what circumstances these are returned, but it might turn-out to be useful to support them. Our scripts queries are version 2 and I'd like to look at version 3 and 4 too. The monitor data can contain addresses for ntp servers, peers, clients and the local host (e.g. an entry for 127.0.0.1 if 'ntpdc -C monlist' is executed at the console of the ntp server itself). It may be possible and useful to differentiate between hosts based on the Mode field of the returned data structures - the mode field apparently is the mode of the last seen communication with a host. Query IPv6 targets - this won't work until Nmap can perform ipv6 udp scans (unless some trickery is involved), but it might be more likely to yield IPv6 hosts than querying an IPv4 server and a useful way of discovering IPv6 hosts to scan. Better file handling - at the moment the script appends to an existing file and it may be a better idea to do one of the following: a) read an existing file and only write unique addresses to it or b) version the file so that comparisons may be made between them or c) clobber the file. Also, there probably ought to be script options for: a) sorting the file (an expensive operation which I don't think is necessary all of the time, but nice to have) b) the filepath to write to. As I said, my working copy isn't sync'ed with the nmap-exp branch at the moment and I need to a bit of tidying, but I'll get that done and check it in later on - you can, if you wish, have a look either now or later (either way, you'll need the latest version of packet.lua). I'd love to hear opinions on which output style would be most useful, whether any of my proposed enhancements would (or not) be useful and any other changes/enhancements. Regards, jah [1] -[first google result] - http://src.opensolaris.org/source/xref/brussels/brussels-gate/usr/src/cmd/xntpd/include/ntp_request.h _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- [NSE] NTP Peer Listing Mak Kolybabi (Apr 10)
- Re: [NSE] NTP Peer Listing Ron (Apr 10)
- Re: [NSE] NTP Peer Listing Mak Kolybabi (Apr 10)
- Re: [NSE] NTP Peer Listing jah (Apr 11)
- Re: [NSE] NTP Peer Listing Fyodor (Apr 11)
- Re: [NSE] NTP Peer Listing jah (Apr 11)
- Re: [NSE] NTP Peer Listing David Fifield (May 14)
- Re: [NSE] NTP Peer Listing jah (May 19)
- Re: [NSE] NTP Peer Listing David Fifield (May 20)
- Re: [NSE] NTP Peer Listing jah (May 20)
- Re: [NSE] NTP Peer Listing Fyodor (Apr 11)
- Re: [NSE] NTP Peer Listing jah (May 20)
- Re: [NSE] NTP Peer Listing Ron (Apr 10)