Date: Tue, 29 Dec 2009 03:20:37 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: freebsd-stable@freebsd.org Subject: Re: Hacked - FreeBSD 7.1-Release Message-ID: <20091229112037.GA34719@icarus.home.lan> In-Reply-To: <6201873e0912281550w34937b9eg3498547722739aee@mail.gmail.com> References: <bd52e0bd614fbaffcf8c9ff9da35286e@mail.isot.com> <4B20B509.4050501@yahoo.it> <600C0C33850FFE49B76BDD81AED4D25801371D8056@IMCMBX3.MITRE.ORG> <ce92ed41260c438977298c2cf9dd1e3f.HRCIM@webmail.1command.com> <600C0C33850FFE49B76BDD81AED4D25801371D8737@IMCMBX3.MITRE.ORG> <8bdcbc5f08e9b762c3d2dcfe2fd00558.HRCIM@webmail.1command.com> <6201873e0912281550w34937b9eg3498547722739aee@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091229112037.GA34719>