On Tue, 29 Dec 2009, David Wolfskill wrote:
> On Tue, Dec 29, 2009 at 03:20:37AM -0800, Jeremy Chadwick wrote:
> > ...
> > I've written my own script to do all of this. It parses periodic
> > security mails (on a daily basis), and does WHOIS lookups + parses the
> > results to tell me what netblocks/CIDRs I should consider blocking. For
> > example, for a security mail that contains this:
> >
> > horus.sc1.parodius.com login failures:
> > Dec 28 15:54:49 horus sshd[74684]: Failed password for root from
> > 199.71.214.240 port 51197 ssh2
> > Dec 28 15:54:49 horus sshd[74686]: Invalid user test from 199.71.214.240
> > Dec 28 18:39:24 horus sshd[84742]: Failed password for root from
> > 208.94.235.248 port 42979 ssh2
> > Dec 28 18:39:25 horus sshd[84744]: Failed password for root from
> > 208.94.235.248 port 43056 ssh2
> > Dec 28 18:39:25 horus sshd[84746]: Failed password for root from
> > 208.94.235.248 port 43156 ssh2
> > Dec 28 18:39:26 horus sshd[84749]: Failed password for root from
> > 208.94.235.248 port 43265 ssh2
> > Dec 28 18:39:27 horus sshd[84751]: Failed password for root from
> > 208.94.235.248 port 43356 ssh2
> >
> > The script would output the following:
> >
> > 199.71.214.240
> > 199.71.212.0/22 Psychz Networks, Walnut, CA, US
> > 208.94.235.248
> > 208.94.232.0/22 WZ Communications Inc., Madison, WI, US
> > 208.94.235.0/24 Soft-Com.biz, Inc., Panama, NA, PA
Jeremy, care to share your whois lookup / parsing script for this?
> > Then manually (this is intentional) I go and add the entries I feel
> > are relevant to a file called pf.conf.ssh-deny which our systems use to
> > block SSH access.
> > ...
>
> I do something somewhat similar, though the implementation is rather
> different. Like Jeremy, I choose to make the actual actions intentionally
> manual.
Me too, apart from one script that tails named.run looking for victims
of DNS attacks using our system as a reflector (common here last Jan-Feb
for a while) that popped IPs straight into a block table within minutes.
> Among salient points:
>
> * Because I'm fairly familiar with it, I (still) use IPFW.
No need to apologise, Luigi's beavering away on it again as we speak,
and I'm hoping to try out ipfw+dummynet on Debian fairly soon.
> * I received a bit of a "prod" (thanks, Julian!) to use IPFW tables;
> that's been quite helpful.
>
> * I use a moderately quaint (and probably embarrassing) mixture of Perl
> & Bourne shell scripts, as well as make, to extract the netblock
> information from WHOIS, and to construct a persistent store that's
> referenced at boot time.
Again, I'm interested in how to query and parse whois info; I've been
mostly using iptools.com and such for manual netblock lookups so far.
> * As a general rule, I try to report activity such as the above (to the
> listed contact(s) from WHOIS). (When I do, I Bcc: myself and keep a
> opy of all salient correspondence. Or bounce-o-grams.)
Apart from stuff originating in .au I've about given up on doing that.
> * For SSH (in particular), I do not rely only on the /var/log/security
> entries created by sshd. Rather, I also configure IPFW to log all SSH
> session-establishment requests. If I report the unwanted ativity, I
> provide both sets of log excerpts. (I often find probes logged by
> IPFW that sshd does not log. And yes, I check the "block" list before
> IPFW logs a "sucessful" SSH session-establishment request packet.)
I'm fortunate to be able to only allow SSH access to known hosts; users
on dynamic IPs have to successfully POP their mailbox first which a cron
script notices, adding their current IP to the SSH allow table.
> * I use one table to block access to SSH. I have another for extreme
> cases of abuse, where I block all traffic in either direction, and a
> third for access to my Web server. I suppose I could also do something
> similar for SMTP....
Here table 1 blocks all IP access (repetitive portscanners and such),
table 25 drops heavier mailserver abusers (apart from those denied by
/etc/mail/access), table 53 for DNS abuse, table 80 for port 80,443
abuse (apart from hosts/browsers/referers declined apache access), and
table 22 for those allowed SSH access, saving much spurious logging.
> * I use this for machines that (may) connect directly to the Internet;
> thus, my "firewall" machine certainly qualifies -- but so does my laptop.
> * I have no mechanism in place to identify, let alone prune, stale
> entries.
Maybe this can help, thanks to clues Michael Butler posted last year.
#!/bin/sh
# addr_to_table 24/11/8 smithi + 31/12/9 CIDR matching for updates
# add ipaddr[/masklen|32] and date (seconds from epoch) to table N
usage() {
[ "$1" ] && echo $1
echo "usage: `basename $0` table address [masklen]"
exit 1
}
[ "$2" ] || usage
table=$1
[ $table -ge 1 -a $table -le 127 ] || usage "table '$table' not 1..127"
mlen=32; [ "$3" ] && mlen=$3
[ $mlen -ge 8 -a $mlen -le 32 ] || usage "masklen '$mlen' not 8..32"
address=$2/$mlen
if [ $mlen -lt 32 ]; then # calc CIDR netblock using table 0
ipfw -q table 0 flush; ipfw -q table 0 add $address
address=`ipfw table 0 list | awk '{print $1}'`
fi
for i in `ipfw table $table list | awk '{print $1}'`; do
if [ "$i" = "$address" ]; then
# echo "found existing $address - updating timestamp"
ipfw -q table $table delete $address
break
fi
done
ipfw -q table $table add $address `date "+%s"`
exit 0
Which is used manually or scripted to add IPs or netblocks to tables.
Then to list tables with their timestamps and local date/time:
#!/bin/sh
# tabledates 7/12/9 smithi upd 31/12/9
usage() {
echo "usage: `basename $0` tablenumber (0-127)"
exit 1
}
[ "$1" ] || usage; [ $1 -ge 0 -a $1 -le 127 ] || usage
tab=' '
ipfw table $1 list | while read addr stamp; do
[ $stamp -ge 65536 ] && date=`date -r $stamp` || date=''
echo "$addr $tab $stamp $tab $date"
done
exit 0
eg:
sola# tabledates 80 | sort -nk2 | tail
82.213.28.0/24 1258876629 Sun Nov 22 18:57:09 EST 2009
193.238.231.0/24 1259076672 Wed Nov 25 02:31:12 EST 2009
95.24.0.0/13 1259632087 Tue Dec 1 12:48:07 EST 2009
82.111.231.0/26 1259850310 Fri Dec 4 01:25:10 EST 2009
203.198.128.0/24 1261153705 Sat Dec 19 03:28:25 EST 2009
203.12.2.160/32 1261301176 Sun Dec 20 20:26:16 EST 2009
8.21.4.254/32 1261301189 Sun Dec 20 20:26:29 EST 2009
61.130.246.0/23 1261302926 Sun Dec 20 20:55:26 EST 2009
74.222.2.0/23 1261811025 Sat Dec 26 18:03:45 EST 2009
212.108.5.60/32 1262107458 Wed Dec 30 04:24:18 EST 2009
Removing entries greater than n seconds old? You can do the maths ..
cheers, Ian
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
