Hi Nelson, Thanks for the explanation. Before I went to bed (it was 2.00 am locally, after I sent my mail) I was reading your recent posts and I guessed it had something to do with the research you were doing. #ntpdc -c sysinfo has a length of 192 bytes. This Snort rule must be very basic, because I think xntpd was not vulnerable to a buffer overflow just by querying it, or was it? It is not that important now, but I will not disable the rule, so I can see who is querying my server ;) Maybe I can refine it to > 48. I did not make use of the noquery option, but apparently you did. Shouldn't you change that if you want information from other servers?
Greetings, Jos van de Ven > -----Oorspronkelijk bericht----- > Van: Nelson Minar [mailto:[EMAIL PROTECTED] > Verzonden: donderdag 18 oktober 2007 4:14 > Aan: J.A.C.M. (Jos) van de Ven > CC: [email protected] > Onderwerp: Re: packets triggering ntpdx overflow > > Wow, that's quite some sleuthing! Sorry for causing the confusion. > > I'm not asking you for the time, I'm running regular ntpdc sysinfo > requests to all servers in the NTP pool. About one request per hour > from > my own NTP server host at 72.36.170.170. I've never looked at a sysinfo > request packet, but presumably it's longer than the usual NTP request / > response packets. I imagine snort is remembering an old security breach > that was found in ntpd a few years ago. > > Why am I doing all these sysinfos? Getting a few weeks data to see if > there's anything interesting to learn from monitoring pool servers' > dispersion, distance to root, etc. So far the data seems pretty random, > but I haven't done much analysis yet. About half the hosts I'm making > requests to answer them. > > Again, my apologies for the confusion. There is a whois record for my > IP > but I'm glad you didn't find it, because it would have pointed you to > the abuse address for my hosting services provider :-) This all reminds > me of the alarm bells I set off in my 1999 survey. I'm not following my > own advice about creating PTR records partly because this was a quick > hack and partly because I don't have any control over them anyway. _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
