AZ Nomad wrote:
> On Fri, 19 Sep 2008 15:24:45 +0000 (UTC), Peter Van Epp
> <vanepp@sfu.ca> wrote:
>>Anon E. Muss <anonymous@example.org> writes:
>
>>>I recently noticed excessive acitivity on my router's activity LED
>>>and
>>>did a little investigating. As immediate action, I used a big hammer
>>>and firewalled off 218/8 until I can figure out what is going on
>>>here. Yesterday, it was 201/8.
>
>>>Below is most of output of netstat. Can someone let me know what is
>>>going on here? SynFlood?? Also, any suggestions??
>
>>>===== BEGIN =====
>>>Active Internet connections (w/o servers)
>>>Proto Recv-Q Send-Q Local Address Foreign Address State
>>>tcp 0 0 x-xx-x-xx-xx.xxxxxxxx:37775 218.25.160.246:ssh
>>>TIME_WAIT
>><snip>
>
>>As several folks have noted standard ssh scan (we take between 4 and
>>5 a day down our entire class B). As this looks to be a unix host try
>>fail2ban which will block the IP for 5 minutes or so after a number of
>>failures:
>
>>fail2ban: http://www.fail2ban.org/ which blocks via a local firewall
>
> denyhosts is also cool in that it reports crackers to a central
> database. If a cracker attacks too many denyhosts protected sites,
> all of them will block the cracker.
>
> Unfortunately, I started to be attacked by a botnet, getting 10-20
> attacks a day
> all from different hosts. I finally decided to disable password
> logins, only allowing predefined keys with passcode to log on which I
> keep on a memory stick for when I connect remotely from a new
> computer.
You can also consider using something like iptables and implement rate
limiting (different limits per port/service), which can help prevent it
getting too far out of control initially, without having to add a rule
or keep a database, though you can do both and include logging for
different reasons and future prevention or reporting. Ultimately,
people seem to leave too many services open to the world when it can be
disabled or can be more limited (not that I assume that was your issue,
but the topic just compels me to make mention of that fact -- I suppose
that's obvious though).
Often, people will just configure SSH to only listen on specific IPs,
rather than binding to all of them and configure it to a unique, non
default port. Add firewalls to that, rate limiting and a good
configuration, then if you keep up to date on the versions/patches,
have a secure configuration of the service, don't allow direct root
logins and use keys, along with a few other basic things, and you
should really not need to worry about incoming SSH attacks, at least.
Additional things can be chrooting/jailing the shell, adding security
policy limits, ulimit, etc., but again, that all goes without saying.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!