Botnet attack? [was: Re: Declining traffic]

[Scott Bennett]

     On Mon, 26 Apr 2010 13:36:17 -0400 Flamsmark <flamsmark at gmail.com>
wrote:
>On 26 April 2010 09:59, Timo Schoeler <timo.schoeler at riscworks.net> 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 checked the tor directory on several
occasions and found that there were as many as three relays operating at
varying times with addresses in that range.  As of that time, none of the
relays' addresses appeared in my block list, so I first added a list of tor
relay IP addresses from which connections to my relay's ORPort are passed
before the block list gets applied.  That list is updated every 30 minutes
to match the current tor consensus most recently fetched by my relay.
     The upshot of all of this is that anybody mucking around with making
illicit attempts to connect to my system gets their system added to the block
list.  From that moment forward, regardless of whether I someday have
applications listening on other ports and regardless of what protocol or
port number a packet is received from an address or address range appearing
in my block list, will *never* get any response whatsoever from my system,
except in the case of a tor relay running on such a system and appearing in
the most recently fetched tor consensus.  Such exceptions will be allowed
to connect to the ORPort (and DirPort, too, if I am ever in a position to
offer directory services again) for as long as their addresses appear in
the consensus.  An additional note I should make is that if an address
appears in a /24 that already has one address in the block list, I replace
that original entry with a large enough IP address range mask to cover both
the original and the newcomer.  I draw the line at /27, though, and don't
make entries that are smaller than a /27 but larger than a single IP address.

>On a loosely related note, it would generally be a good idea to mask IP
>addresses on public mailing lists.
>
     That is a good idea for client IP addresses, to be sure.  However,
any relay already has its IP address made public in the consensus and the
directory.  And I have no qualms at all about making crackers' addresses
as public as possible.


                                  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 majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/