On Tue, Apr 27, 2010 at 01:35:20AM -0500, Scott Bennett wrote: > On Mon, 26 Apr 2010 13:36:17 -0400 Flamsmark <flamsm...@gmail.com> > wrote: > >On 26 April 2010 09:59, Timo Schoeler <timo.schoe...@riscworks.net> wrote: > > > >> (Deutsche Telekom AG). For me it really seems as there's some kind of > >> botnet attack going on. > >> > > > > > >What makes you think that this is a botnet attack? What are the > >characteristics of a botnet attack, and how do these logs exhibit them? If > someone playing around, it's rather background noise... relax, guys ;)
> What my system logged over a two- to three-hour period was a very high > rate of illicit connection attempts being logged, a rate much higher that > usual and for an extended period of time. Some of the connection attempts > involved only one or two tries for a single port number. However, consider > another type that also occurred frequently during that time span. That > other type looked more like an individual attack that came in this evening: [snip] > > 2010-04-26 23:38:20.086026 rule 5.logscanners.0/0(match): block in on bge0: > 81.64.6.141.3422 > 24.1.225.89.8080: tcp 16 [bad hdr length 12 - too short, > < 20] > 2010-04-26 23:38:20.990386 rule 5.logscanners.0/0(match): block in on bge0: > 81.64.6.141.3416 > 24.1.225.89.8000: tcp 16 [bad hdr length 12 - too short, > < 20] > 2010-04-26 23:38:25.214087 rule 5.logscanners.0/0(match): block in on bge0: > 81.64.6.141.3419 > 24.1.225.89.8001: tcp 16 [bad hdr length 12 - too short, > < 20] > 2010-04-26 23:38:26.122380 rule 5.logscanners.0/0(match): block in on bge0: > 81.64.6.141.3422 > 24.1.225.89.8080: tcp 16 [bad hdr length 12 - too short, > < 20] > [lot's of snip] There was a scan. yes. Happens. But these -> [bad hdr length 12 - too short, < 20] <- are *NOT* a maliciuos attempt of something but rather a matte ofr tcpdump running against a pflog* interface. There are different expectations about the snaplen , so if increasse the snaplen to sth. higher than 68 bytes the message will disappear, it is rather harmless. PLease see man tcpdump [quote] TCP Packets [snip] If the snapshot was small enough that tcpdump didn't capture the full TCP header, it interprets as much of the header as it can and then reports ``[|tcp]'' to indicate the remainder could not be interpreted. If the header contains a bogus option (one with a length that's either too small or beyond the end of the header), tcpdump reports it as ``[bad opt]'' and does not interpret any further options (since it's impossible to tell where they start). If the header length indicates options are present but the IP datagram length is not long enough for the options to actually be there, tcpdump reports it as ``[bad hdr length]''. [/quote] on my bsd's a snaplen on 104 is sufficient, but you might try 256 or find the appropriate value by checking it. tcpdump ${wtf} -s 104 -i pflog* *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/