[sf-lug] how to whack crackers

[Tom Haddon]

On Mon, 2009-01-05 at 09:34 -0800, jim wrote:
> hoping for suggestions to defend against hackers: 
> 
> 
>    we've got a box on the internet using a speakeasy 
> IP address. a linksys home router sees the front end 
> and NATs traffic for ssh and http to the box, which 
> is a node on the LAN running ubuntu server 8.10. 
>    crackers regularly knock on the door. we've 
> implemented IP tables, though they don't work as we 
> think they should. for example: 
> 
> we have a rule (one of many similar) 
> -A INPUT -p tcp -m iprange \
> --src-range 110.0.0.0-126.255.255.255 \
> --dport 22 -j DROP 
> 
> iptables -L shows 
> DROP  tcp  --  anywhere  anywhere  source IP range \
> 110.0.0.0-126.255.255.255 tcp dpt:ssh 
> 
> and yet /var/log/auth.log shows ssh login attempts 
> for a variety of user names from 
> 124.93.200.34 
> 

Two things to mention here:

1) fail2ban - I haven't actually used it myself, but have heard good
things, and this automates what you're talking about (and is available
as a package from the Ubuntu repos).
Description: bans IPs that cause multiple authentication errors
 Monitors log files (e.g. /var/log/auth.log, /var/log/apache/access.log)
and temporarily or persistently bans failure-prone
 addresses by updating existing firewall rules. The software was
completely rewritten at version 0.7.0 and now allows easy
 specification of different actions to be taken such as to ban an IP
using iptables or hostsdeny rules, or simply to send a
 notification email. Currently, by default, supports ssh/apache/vsftpd
but configuration can be easily extended for monitoring
 any other ASCII file. All filters and actions are given in the config
files, thus fail2ban can be adopted to be used with a
 variety of files and firewalls.
Homepage: http://www.fail2ban.org

2) ufw - Uncomplicated firewall - kind of a nice frontend for iptables.
Only really of use if you're not intimately familiar with iptables, but
thought I'd mention it anyway.

Cheers, Tom


>    the box has been cracked once already, we fixed 
> that vulnerability (i didn't think about a well-known 
> default user, ubuntu: someone guessed that user and 
> password, which was probably a well-known default). 
> 
>    ideas we have include 
> * mount most filesystems in read-only mode (excepting 
> /var/log/, which is a separate mount point)
> * have sshd listen on some upper port rather than 22 
> (and change iptables rules accordingly) 
> * have a cron job run every five minutes to monitor 
> the box, mainly checking for weird user activity and 
> probably shutting down the box upon discovering such. 
> * /etc/hosts.deny has ALL=PARANOID and some ip addresses 
> that crackers have used on us. 
> 
>    we're not happy with our ideas as a complete defense 
> and hope some of you will chime in with opinions about 
> our ideas as well as ideas we haven't thought of. 
> 
> 
> 
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20090105/44a17636/attachment.pgp>