J.A.C.M. (Jos) van de Ven wrote: > Hi Nelson, > > We had this discussion in october last year. > This is the snort IDS rule that causes the problem: > alert udp $EXTERNAL_NET any -> $HOME_NET 123 (msg:"EXPLOIT > ntpdx overflow attempt"; dsize:>128; reference:arachnids,492; > reference:cve,2001-0414; classtype:attempted-admin; sid:312; > rev:6; fwsam: src, 1 day;) > > As you can see just a size >128 triggers the rule and in my case the IP gets > blocked by fwsam for 1 day. > I can disable the rule, but the problem is that the rule sets are updated > automatically.
http://oinkmaster.sourceforge.net/ > > You are right that it is kind of stupid and the rule should be left out in > the future. DISCLAIMER: http://www.snort.org/users/jbrvenik == me I beg to differ on that rule. The vulnerability is such that any packet > 128 bytes has the potential to exploit the vulnerability. Content, state, etc is irrelevant. http://marc.info/?l=bugtraq&m=98642418618512&w=2 If you are _sure_ that no ntpd <= 4.0.99 is running then you can perhaps justify disabling it entirely. While I would like to say it is a no brainier to drop, it has value for many corporations. The packets generally handled by clients _should not_ be > 128 bytes and thusly it should not be observed at the borders of these orgs/personal networks, especially on internet pipes. There are certainly reasons it can happen but as admins we should be able to control responses much better. I'm happy to recommend it be disabled by default though I cannot make any guarantees it will be met with agreement. I might also make sense to suggest changes to the documentation for that rule. If there is a page that the pool wants to put up explaining why a pool server could cause the event _and_ allow for the easy checking of a given source is in the pool ( of limited value, udp being stateless and easily spoofed ) it could be very useful to clueless users getting these events and help reduce the reports. Getting a link in the false positives section to this faq page would be easily justified. > > My English and knowledge of ntp is not good enough but maybe someone can > make a false positive report at: > > http://www.snort.org/pub-bin/sigs.cgi?sid=312 I'll happily make a report to the team directly. > > Jos van de Ven > >> -----Oorspronkelijk bericht----- >> Van: [EMAIL PROTECTED] [mailto:timekeepers- >> [EMAIL PROTECTED] Namens Nelson Minar >> Verzonden: vrijdag 4 januari 2008 21:45 >> Aan: Tim Shoppa >> CC: [email protected] >> Onderwerp: Re: [time] NTP replies accused of being abusive >> >> I had this problem with my Colo recently, although in my case the >> abuse report was in response to sysind requests I was sending out on >> my own initiative. My response was to stop doing my survey. Haven't >> gotten a report for just serving time yet. That sucks; a busy ISP is >> likely to just assume the worst. >> >> I got a copy of the intrusion report btw, it seemed to be treating any >> unexpected sysinfo request as an exploit. Kind of stupid. We could try >> to notify the security vendor of the false positive problem but I'm >> not optimistic. >> > > > _______________________________________________ > timekeepers mailing list > [email protected] > https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers > _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
