Hacked - FreeBSD 7.1-Release
Jeremy Chadwick
freebsd at jdc.parodius.com
Tue Dec 29 11:20:39 UTC 2009
On Mon, Dec 28, 2009 at 05:50:23PM -0600, Adam Vande More wrote:
> On Mon, Dec 28, 2009 at 4:59 PM, Chris H <chris#@1command.com> wrote:
>
> >
> > My point here was that by increasing the verbosity, you will more easily be
> > able
> > to grep against login /failures/, and more easily discover dictionary/
> > brute-force
> > attacks. It's certainly made my job easier, and hasn't required any
> > modifications
> > to our current policies. You /have/ considered PF(4), haven't you? It's
> > /really/
> > an excellent strategy for securing your network.
> >
> > --Chris H
> >
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> >
>
> I use security/denyhosts for this, very simple to setup like 5 minutes if
> you're a fast reader. There are other options as well that offer similar
> functionality.
I haven't used this software, but based on this page:
http://denyhosts.sourceforge.net/features.html
It implies that it blocks access to services using /etc/hosts.deny,
which means the attackers are still able to obtain TCP connections to
your box; e.g. you're still wasting sockets on these attackers, which
ultimately means they're still wasting your resources. hosts.deny does
not stop the establishment of the socket; only a firewall can do that.
If the software can be tuned to add entries to a firewall (e.g. to a
pf.conf-included file), rather than hosts.deny, then that would be
advised.
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
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.
Relevant pf.conf entries:
# SSH brute-force attacks, with overrides
table <ssh-allow> persist file "/conf/ME/pf.conf.ssh-allow"
table <ssh-deny> persist file "/conf/ME/pf.conf.ssh-deny"
# Block traffic from SSH brute-force attackers, with overrides
pass in quick on $ext_if proto tcp from <ssh-allow> to any port ssh
block in quick on $ext_if proto tcp from <ssh-deny> to any port ssh
Contents of the pf.conf.ssh-deny file resemble this:
#
# Network blocks which we don't want to allow SSH traffic
# from. These are predominantly netblocks or IPs which have shown
# signs of brute-force SSH attacks (usually dictionary-based).
#
# LACNIC (Latin America)
#
132.247.0.0/16
132.248.0.0/16
...
# APNIC (Asia-Pacific)
#
...
# JNIC (Japan)
#
...
# RIPE (European)
#
...
# AFRINIC (Africa)
#
...
# Other (miscellaneous attackers)
#
...
Then I simply do /etc/rc.d/pf check && /etc/rc.d/pf reload.
I also have a script that pushes out the pf.conf.ssh-deny machines
to other hosts on our network and executes the above commands.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-stable
mailing list