Re: Botnet attack? [was: Re: Declining traffic]
On Tue, 27 Apr 2010 13:07:24 +0200 Hans Schnehl wrote: >On Tue, Apr 27, 2010 at 01:35:20AM -0500, Scott Bennett wrote: >> On Mon, 26 Apr 2010 13:36:17 -0400 Flamsmark >> wrote: >> >On 26 April 2010 09:59, Timo Schoeler 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. > Yes, yes, I understood all that. That wasn't my point. My point was that on the morning in question, I was getting scans similar to that example, each batch from a different IP address, as frequently as a couple of scans in two or three seconds, and that that kind of thing went on almost continuously for about three hours. That was the first time I had seen a protracted onslaught of such stuff on my system. There are probably many culprits that escaped getting added to my block list because after three hours of trying to add each address by hand, scrolling back and forth through the intermingled addresses in messages in an xterm, I was worn out and gave up. By the time I gave up, I had added over 220 addresses or address ranges. Then the onslaught stopped very abruptly and has not recurred. I still get several scans per day of varying sets of ports, just as I did before, but no further deluges of scans and individual port attempts coming from lots of different IP addresses. The event that morning was intense, but of finite duration. While we're on the subject of illicit TCP connection attempts, I'd like to mention something that I've noticed begin only in the last two months or so and seems to be becoming more frequent as time passes. At first, it was the occasional attempt to connect to port 9030, which became more frequent over the last few weeks. Then 9001 was added to that and has also been getting more frequent. In the last day or so, I've begun seeing 8118 in addition to those. Hmmm... Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Botnet attack? [was: Re: Declining traffic]
On Tue, Apr 27, 2010 at 01:35:20AM -0500, Scott Bennett wrote:
> On Mon, 26 Apr 2010 13:36:17 -0400 Flamsmark
> wrote:
> >On 26 April 2010 09:59, Timo Schoeler 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-talkin the body. http://archives.seul.org/or/talk/
Re: Botnet attack? [was: Re: Declining traffic]
On Mon, 26 Apr 2010 13:36:17 -0400 Flamsmark wrote: >On 26 April 2010 09:59, Timo Schoeler wrote: > >> When running tor, I see >> >> i) CPU cycles being eaten up by tor almost entirely; >> >> ii) my machine experiences things like those: >> >> One is a chinese dialup, the other ones are from a big German ISP >> (Deutsche Telekom AG). For me it really seems as there's some kind of >> botnet attack going on. >> >> Timo > > >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 >there are only a few IP addresses, wouldn't that contraindicate botnet >involvement? I agree with your implication that the symptoms Timo described do not look like a botnet attack, although they may well be an attack by those individual systems. 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: 2010-04-26 23:38:02.029282 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3400 > 24.1.225.89.80: [|tcp] 2010-04-26 23:38:04.997727 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3400 > 24.1.225.89.80: [|tcp] So far, so good. A simple web crawler, unaware that I don't run a web server at present, could have done the above. If those were the only attempts, then I would not have added 81.64.6.141 to my permanent block list for all protocols. However, those two log entries were immediately followed by the entries below. 2010-04-26 23:38:07.153421 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3409 > 24.1.225.89.1081: [|tcp] 2010-04-26 23:38:07.449861 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3412 > 24.1.225.89.3121: [|tcp] 2010-04-26 23:38:09.253588 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3413 > 24.1.225.89.3128: [|tcp] 2010-04-26 23:38:10.125382 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3409 > 24.1.225.89.1081: [|tcp] 2010-04-26 23:38:10.429712 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3412 > 24.1.225.89.3121: tcp 16 [bad hdr length 12 - too short, < 20] 2010-04-26 23:38:11.033624 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3400 > 24.1.225.89.80: [|tcp] 2010-04-26 23:38:12.063644 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:12.238059 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3413 > 24.1.225.89.3128: [|tcp] 2010-04-26 23:38:15.058113 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:16.161729 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3409 > 24.1.225.89.1081: tcp 16 [bad hdr length 12 - too short, < 20] 2010-04-26 23:38:16.241858 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3419 > 24.1.225.89.8001: [|tcp] 2010-04-26 23:38:16.466181 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3412 > 24.1.225.89.3121: tcp 16 [bad hdr length 12 - too short, < 20] 2010-04-26 23:38:17.193809 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3422 > 24.1.225.89.8080: [|tcp] 2010-04-26 23:38:18.274265 rule 5.logscanners.0/0(match): block in on bge0: 81.64.6.141.3413 > 24.1.225.89.3128: tcp 16 [bad hdr length 12 - too short, < 20] 2010-04-26 23:38:19.178169 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: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] As you can see, 81.64.6.141 has earned a well deserved line in my block list. FWIW, since I started maintaining a block list, it has grown to 2682 entries, each of which is either a single IP address or is an IP address range. The largest range that I've had to insert so far is 85.176.128.0/17, which is the upper half of a /16 held by hansenet.de. Before removing the long list of individual offenders in that range, I
Re: Botnet attack? [was: Re: Declining traffic]
On 26 April 2010 09:59, Timo Schoeler wrote: > When running tor, I see > > i) CPU cycles being eaten up by tor almost entirely; > > ii) my machine experiences things like those: > > One is a chinese dialup, the other ones are from a big German ISP > (Deutsche Telekom AG). For me it really seems as there's some kind of > botnet attack going on. > > Timo 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 there are only a few IP addresses, wouldn't that contraindicate botnet involvement? On a loosely related note, it would generally be a good idea to mask IP addresses on public mailing lists.
