How to report a bot-net

Sat Jan 16 05:37:52 PST 2010

On Thu, Jan 14, 2010 at 03:24:08PM -0800, Guy B. Purcell wrote:
> Hi All,
> 
> Been too long since we had real posts here & this is an interesting problem, so I'm hoping for some good discussion, if not resolution.

Well, in fairness, I brought up a closely-related topic not too long
ago....  :-}

> I have an SSH portal at home that gets a remarkable amount of traffic--almost all of which is brute-force attacks either from individuals or from bot-net(s). 

As do I, though usually I wouldn't call the amount of activity all that
remarkable -- not until the number of probes/day gets measured in the
thousands, I suppose. :-}

> Here's an example individual (I'm showing logged timestamp, source IP address, and username attempted):
> Jan 7 12:30:01 89.140.94.122 ke
> Jan 7 12:30:03 89.140.94.122 ke
> Jan 7 12:30:05 89.140.94.122 ke
> ....
> Here's an example bot-net:
> 
> Jan 7 13:43:01 211.115.234.143 petang
> Jan 7 13:48:29 84.246.69.21 peter
> Jan 7 13:53:33 90.182.211.25 petkuo
> ...
> 
> This host is running ipfw, and I could write a script that couples
> that with the log to block the unwanted attention (easy for the
> individual attacks, non-trivial for the bot-nets--at least AFAICT),
> but that just kicks the can down the road to someone else's IP
> address.

As Louis (and others, in other lists) have pointed out, this is
generally a fairly effective way to commit a self-inflicted DoS attack
on yourself.  There may be circumstances where the risk is justified;
you would likely know those circumstances (for yourself) better than
most.

> I could use the log info to attempt to notify the various
> ISPs' of the abuse, but they would just see it as a bunch of
> individual complaints.

Perhaps.

I actually do this (generally); the boiler-plate message I send makes it
clear that my purpose is to provide a "heads up" that there is something
going on on the network in question that bears investigation, and that
the information I'm providing may be helpful in providing direction to
that investigation.

Fundamentally, I try to treat the folks running the other nets as I
would like them to treat me were our roles reversed.

That said, once those allegedly "responsible" for a given netblock have
repeatedly demonstrated that they are unwilling or unable to address
such issues, I give up.  (A trivial case is when my attempts to notify
them get rejected.)

And in this case, that does not mean that I merely stop sending the
notifications to them.  Rather, it means that I add the netblock in
question to a particular IPFW table for which I block all incoming and
outgoing traffic of any kind.  And If I find other netblocks that have
equivalent contact information, I add those, as well.

That is how I came to add all CHINANET*, CNCGROUP*, and UNICOM*
netblocks to that table, for example.

Note: I do this for my "firewall" (packet filter, actually -- though it
does a bit more than that) box at home; I also do it for my laptop, as
it is also exposed to the Outside World -- recall that when we met at
Apple, Apple's DHCP server handed out routable 17/8 addresses.

> What I think would be better would be to
> use blocking & notification tactics (as automated as possible; I
> believe David kicked off a small discussion thread here about that)

:-}

> for the individual attackers, but to be able to treat the whole
> bot-net as a single-source attack & have it shut down.

> But how to go about that?  The Internet is a global confederation
> with no real central authority over such a broad attack base (I
> have IP addresses from China, Korea, Australia, Isreal, Brazil,
> Italy, & the US--to name just the handful I happened to look up).
> Who would you turn to?  If there's no authority with the ability
> or responsibility to shut bot-nets down, what do you think could
> be done to improve matters?
> ...

I don't really attempt to address the issue in that way, as I don't know
of a way to trace back where the "control point" is.

Rather, I concentrate on what I can verify: I have pretty good evidence
that the source IP addresses I'm seeing actually correspond to the
traffic in question and try to help the folks responsible for the resources
in question be aware that there may be a problem -- but ultimately, I
will take whatever steps I deem necessary to protect my network, up to
the point of effectively dyking the offending netblocks out of the part
of the Internet with which I can directly interact.

Mind, I probably wouldn't have quite that much flexibility were I
performing this activity on behalf of someone else -- especially a large
global corporation, for example.

For amusement, Here are some log entries I see this morning.  Note that
in addition to the log entries generated by sshd(8), I also have IPFW
configured to log all incoming session-establishment requests for SSH,
so:

Jan 15 07:42:51 bunrab sshd[86724]: Did not receive identification string from 59.76.81.109
Jan 15 07:48:41 bunrab sshd[86734]: Illegal user marine from 59.76.81.109
Jan 15 07:48:41 bunrab sshd[86736]: Illegal user cadi from 59.76.81.109
Jan 15 07:49:38 bunrab sshd[86732]: fatal: Timeout before authentication for 59.76.81.109

Jan 15 07:42:51 janus kernel: ipfw: 10000 Accept TCP 59.76.81.109:36589 172.16.8.11:22 out via dc0
Jan 15 07:47:38 janus kernel: ipfw: 10000 Accept TCP 59.76.81.109:51504 172.16.8.11:22 out via dc0
Jan 15 07:47:41 janus kernel: ipfw: 10000 Accept TCP 59.76.81.109:51719 172.16.8.11:22 out via dc0
Jan 15 07:47:45 janus kernel: ipfw: 10000 Accept TCP 59.76.81.109:51942 172.16.8.11:22 out via dc0
Jan 15 07:47:51 janus kernel: ipfw: 10000 Accept TCP 59.76.81.109:52318 172.16.8.11:22 out via dc0

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20100116/8aea6805/attachment.bin>