Re: [NSE] NTP Peer Listing

[jah <jah () zadkiel plus com>]

On 20/05/2010 19:58, David Fifield wrote:
> > 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
> >     
> This output is outstanding. I think I understand the distinctions you've
> outlined. I'd be very happy with either of these examples.
>
> Is "72*159*219*194" with the *s supposed to mean something?
>   
I messed-up, a bit, with the output - it should have looked like this:
PORT    STATE SERVICE REASON
123/udp open  ntp     udp-response
| ntp-monlist:
|   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 addition of 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:76a

The difference between them is that in the second, we learned which
associated host the target is currently synchronised with (the *s were
an alternative method of displaying this information, but I decided to
output it longhand) and we separated Mode 1 Peers from Mode 1 "Clients".

> > > 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)?
> >     
> Yes. I kind of want to see that as a separate commit, even if it's right
> away. The reason being that we might want to do this sort of thing with
> other scripts and I want to see how much code it is.
>   
Yep, I'm OK with that - I'll remove it and work on it after the first
commit.
> > > 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?
> >     
> No, I mean in the source code. 200 lines versus 500 lines matter, and I
> find ntp-peers easier to understand than ntp-monlist. This is another
> reason I want the file output left out of the initial commit and for you
> to check out the pcap issue, to better compare these in terms of similar
> features.
>   

I'll keep that in mind.

Cheers,

jah
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/