Nmap Development mailing list archives
Re: [NSE] NTP Peer Listing
From: jah <jah () zadkiel plus com>
Date: Wed, 19 May 2010 23:55:36 +0100
On 15/05/2010 03:50, David Fifield wrote:
PORT STATE SERVICE REASON 123/udp open ntp udp-response | ntp-monlist: discovered internal addresses: | 127/8 (1) | and discovered 1 alternative address for the target: | 192.168.0.21 | and collected 4 IPv4 addresses: |_66.79.152.35 69.36.241.112 169.229.70.64 208.77.19.5 | ntp-peers: | Private Peers (1) | 127.0.0.1:56189 | Public Peers (4) | 66.79.152.35:123 | 69.36.241.112:123 | 169.229.70.64:123 |_ 208.77.19.5:123 I like how both scripts separate out the private and public addresses. I really like the bit "discovered 1 alternative address for the target" in ntp-monlist. Do you get the netmask back from the NTP server in "127/8" or is that inferred?
We don't get the netmask back; "127/8" is just shorthand for 127.0.0.0/8 loopback assignment and is one of the strings returned as the second value from ipOps.isPrivate when the first return value is true. The 'internal address' summary was intended to summarise the different private (or special use) addresses revealed by the monlist data and thus avoid printing them out - my reasoning was that these addresses are only slightly interesting when the target is somewhere across the internet. I wasn't really thinking about scanning your internal ntp servers where this information might be more useful longhand and I think I underestimated the interestingness of private addresses for a target across the internet. So this summary would be better replaced with the full listing of private and special use addresses as in Mak's script output.
Here's the result from running against the first of the public peers above (the only one that produced any output). I also included the output of the Metasploit script. PORT STATE SERVICE REASON 123/udp open ntp udp-response | ntp-monlist: collected 600 IPv4 addresses: | 4.78.155.130 66.151.63.26 72.184.160.70 140.182.214.208 | 12.21.127.78 66.152.137.15 72.203.133.69 141.156.191.175 ... 146 lines ... | 66.151.63.14 72.159.219.194 137.113.118.26 217.114.222.89 |_66.151.63.17 72.169.122.140 137.113.118.28 222.66.126.163 | ntp-peers: | Private Peers (0) | Public Peers (474) | 4.78.155.130:11308 | 12.21.127.78:123 ... 470 lines ... | 217.114.222.89:123 |_ 222.66.126.163:60514 msf auxiliary(ntp_monlist) > set RHOSTS 66.79.152.35 RHOSTS => 66.79.152.35 msf auxiliary(ntp_monlist) > run [*] Sending probes to 66.79.152.35->66.79.152.35 (1 hosts) [*] 66.79.152.35:123 96.245.144.224:123 (66.79.152.35) [*] 66.79.152.35:123 66.83.13.6:123 (66.79.152.35) ... 596 lines ... [*] 66.79.152.35:123 206.169.68.114:62582 (66.79.152.35) [*] 66.79.152.35:123 69.7.96.116:6634 (66.79.152.35) [*] Scanned 1 of 1 hosts (100% complete) The first thing I see is that ntp-peers gets less than 600 records. This is reproducible. But when I run it by itself, it gets the maximum of 600. About the source port numbers: is it possible that these distinguish between downstream (port 123) and upstream servers (not 123)?
I've been looking into host classification because monlist records also contain the NTP mode and version fields from datagrams received. I thought it might be possible to classify discovered hosts into clients, peers and servers and that this might be useful information. Here's the information we can infer about a discovered host from the ntp mode field: Mode 1 - Host is associated with the target as a symmetric active Peer. Mode 2 - Host is associated with the target as a symmetric passive Peer. Mode 3 - Host is a Client of the target. Mode 4 - Host is a Server for the target (the target is configured to poll the host in client mode). Mode 5 - Broadcast/Multicast - the value of the source address field of Mode 5 records is the broad/multicasting interface of the host and the value of the destination address field is the broadcast address from which the target accepts broad/multicasted messages. Mode 6 - Host has sent requests to the target in Control Mode (e.g. ntpq -np <our_target> ) Mode 7 - Host has sent requests to the target in Private Mode (e.g. ntpdc -n -c monlist <our_target>) To muddy the waters a little, the windows time service (W32Time) (by default on stand-alone workstations and servers) syncs with configured time servers in symmetric active mode (i.e. NTP Mode 1) in exactly the same way as Peers. This prevents us from assuming that discovered hosts who sent a Mode 1 packet to the target are all Peers. We could request a peer list from the target at this point; the peer list contains records of configured ntp associations (which excluded clients) and this would allow us to distinguish between Peers and Clients. The value of the version field tells us the version of the last NTP message sent by a host to our target. I don't think this is important information. The source port isn't greatly interesting either: messages with a source port of 123 could be from a client, server or peer; messages with a source port of something other than 123 are very often clients sending Mode 3 to the target (perhaps ntpd started with --unprivileged), but also the target could have been queried (locally or remotely) using tools such as ntpq and ntpdc. There's one other vaguely interesting field in the monlist records: flags - which shows whether a host sent a message to the target Unicast, Broadcast or Multicast. This allows us to distinguish between Mode 5 broadcast and Mode 5 multicast associations and to interpret the destination address as either a broadcast or multicast address to which the target listens. To summarise then: By sending a monlist request and parsing the response we can classify hosts associated with the target into 4 groups which can be divided into public and private hosts: Servers Peers or Clients Clients Others (possibly administrative hosts and probably including the external address of the Nmap user) We can also discover alternative addresses for the target (other interfaces - be they public or private), broadcast and multicast addresses the target listens to. By sending an additional peerlist request and parsing the response we can divide the 'Peers or Clients' group into Peers and Clients. We can also discover which of the peers or servers the target was synchronised to at the time the peer list response was generated. The question is how to organise this information and I'm leaning toward something like the following: PORT STATE SERVICE REASON 123/udp open ntp udp-response | ntp-monlist: | Target is Synchronised with: | 72.159.219.194 | Alternative Target Interfaces (2) | 192.168.0.21 | 2e0e::1 | Private Servers (0) | Public Servers (4) | 66.151.63.14 72*159*219*194 137.113.118.26 217.114.222.89 | Private Peers or Clients(1) | 10.0.0.1 | Public Peers or Clients(4) | 4.78.155.130 66.151.63.26 72.184.160.70 140.182.214.208 | Private Clients (1) | 127.0.0.1 | Public Clients (590) | 66.79.152.35 69.36.241.112 169.229.70.64 208.77.19.5 ... more lines ... | 66.151.63.17 72.169.122.140 137.113.118.28 222.66.126.163 | 2e0f::1 2e0f:76af:f0c3:2e0f:76af:f0c3:2e0f:76af 2e10::1 |_ 2e10:76af:f0c3:2e0f:76af:f0c3:2e0f:76af which is the output seen if we didn't follow-up with a peers list request - the following is with the peer list information: PORT STATE SERVICE REASON 123/udp open ntp udp-response | ntp-monlist: | Target is Synchronised with: | 72.159.219.194 | Alternative Target Interfaces (2) | 192.168.0.21 | 2e0e::1 | Target listens to Broadcast Addresses (1) | 192.168.0.255 | Private Servers (0) | Public Servers (4) | 66.151.63.14 72.159.219.194 137.113.118.26 217.114.222.89 | Private Peers (1) | 10.0.0.1 | Public Peers (0) | Private Clients (1) | 127.0.0.1 | Public Clients (594) | 66.79.152.35 69.36.241.112 169.229.70.64 208.77.19.5 ... more lines ... | 66.151.63.17 72.169.122.140 207.113.118.28 222.66.126.163 | 2e0f::1 2e0f:76af:f0c3:2e0f:76af:f0c3:2e0f:76af 2e10::1 |_ 2e10:76af:f0c3:2e0f:76af:f0c3:2e0f:76af Note that broadcast/multicast output would only appear if we get such information, but Server, Client and Peer output would be shown even if there are zero such records to ensure there's no room to misinterpret the results - perhaps in the interest of compact output any section without values should be suppressed. Also, while IPv4 addresses are tabulated, IPv6 addresses are crammed into separate lines such that they don't break across a 70 char width limit. I see this output having two uses, everything before 'Public Clients' is information about the target environment. The Public Clients is simply a list of hosts that are interesting only in so far as they are associated with the target as clients, but, as a collection of hosts, may be useful in host discovery - IPv6 hosts especially. One thing I've not addressed in these examples is the hosts which cannot be classified as having a server, client or peer association with the client. It might be worth outputting everything we know about such hosts: Address Port Version Mode TXType 127.0.0.1 49876 2 6 Uni 212.159.95.110 32154 2 7 Uni In this contrived example, we can see that someone or something on the target requested Control Mode data from ntpd - could have been an admin running ntpq! We can also see ourselves in the list with our version 2 mode 7 request - this is interesting because we have been added to the target's monitor data - it might be prudent to finish the script by sending an innocuous looking mode 3 packet to the target, thus overwriting the version 2 mode 7 entry and covering our tracks.
In terms of payload, ntp-monlist's is much shorter than ntp-peer's or Metasploit's. ntp-monlist: 17 00 03 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ntp-peers, ntp_monlist.rb: 17 00 03 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I prefer that the first commit of this script not write to a file. With four addresses per row, we're looking at about 150 lines of output max, which is big not but not that big.
Do you mean we should omit write-to-file functionality even as currently implemented in ntp-monlist (as an option requiring a script arg)?
jah, you mentioned that you had trouble with Nsock and decided to use raw sockets and pcap to do the sending and receiving. Can you tell more about that? Were you getting Nsock TIMEOUT errors? It should not be necessary to use raw sockets for this script. It might be a bug in Nsock that has to be fixed.
I didn't pay much attention at the time - I quickly decided to use dnet and pcap and blundered onwards. I'll look into this and get back to you on the specifics - I have a feeling, now, that it could be I didn't tell Nsock to set a long enough timeout.
Overall I prefer the clarity of ntp-peers over ntp-monlist, but I much appreciate the protocol documentation in ntp-monlist.
I think the proposal (above) for output addresses output clarity?
This is what I would like to see: A combination of these two scripts, with the name ntp-monlist, using plain Nsock if possible, with the shorter payload, not writing to a file, with columnar output.
Thanks for the guidance! jah _______________________________________________ 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)