Date: Wed, 2 Dec 2009 06:00:05 -0800 From: David Wolfskill <david@catwhisker.org> To: freebsd-security@freebsd.org Subject: Re: Increase in SSH attacks as of announcement of rtld bug Message-ID: <20091202140005.GE1441@albert.catwhisker.org> In-Reply-To: <200912021324.nB2DOc58001138@lava.sentex.ca> References: <200912010120.nB11Kjm9087476@freefall.freebsd.org> <200912010522.WAA03022@lariat.net> <200912011724.KAA10851@lariat.net> <200912011909.nB1J9JRM070879@lava.sentex.ca> <200912020145.SAA17523@lariat.net> <200912020150.nB21ossm072930@lava.sentex.ca> <4B1662BB.8000908@gmail.com> <200912021324.nB2DOc58001138@lava.sentex.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--ZInfyf7laFu/Kiw7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It appears that folks are tending to focus on events logged by sshd(8) (in /var/log/auth.log). While that is certainly of interest, over the last few years, I have seen a pattern that's likely to be unnoticed by this approach: Apparent "probes" (22/tcp SYN packets that do not cause sshd(8) to log anything). I use IPFW on my border machine, and have things configured so it logs every attempted SSH "session-establishment" packet. For example, examining yesterday's logs, I see the following (after filtering out the usual expected entries): [Extract from /var/log/auth.log] Dec 1 19:31:22 albert sshd[3425]: Did not receive identification string fr= om 190.198.167.71 Dec 2 04:21:08 albert sshd[6178]: Did not receive identification string fr= om 66.234.187.17 [Extract from /var/log/security] Dec 1 19:31:21 janus kernel: ipfw: 10000 Accept TCP 190.198.167.71:54754 1= 72.16.8.13:22 out via dc0 Dec 2 04:21:08 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:39854 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:03 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:45562 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:05 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46050 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:06 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46081 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:07 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46128 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:09 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46574 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:10 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46619 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:11 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46662 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:12 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46708 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:14 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47152 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:15 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47194 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:16 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47238 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:17 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47273 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:19 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47717 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:20 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47758 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:21 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47805 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:22 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47846 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:24 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48289 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:25 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48329 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:26 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48372 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:28 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48410 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:29 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48850 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:30 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48889 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:32 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48932 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:33 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48976 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:34 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49417 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:36 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49466 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:37 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49512 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:39 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49954 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:40 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49996 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:41 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50039 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:42 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50080 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:44 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50520 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:45 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50562 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:46 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50597 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:47 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50639 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:49 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:51064 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:50 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:51089 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:51 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:51113 17= 2.16.8.13:22 out via dc0 Dec 2 04:28:52 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:51141 17= 2.16.8.13:22 out via dc0 One of the ways I address this is to also use IPFW to disallow 22/tcp from certain sources -- quite early in the ruleset. I use IPFW "tables" for this purpose; the unit of granularity I nearly always use is "network name" -- that is, I do the following: * Examine output of "whois 66.234.187.17" [in the case in point]. * Note that the NetName is "PNG-TELECOM". * Add a/PNG-TELECOM to the list of networks from which I do not care to receive SSH connection requests. (The directory structure is a bit of a hack: the "a" in this case is a registry identifier; it corresponds with a flag for whois(1), as NetNames only designate an entity within a registry -- well, except for LACNIC, which doesn't appear to use them, so I use "inetnum" for LACNIC-registered networks.) The process is manually-invoked, but I have some scripts & a hack of a Makefile to reduce the pain (and probability of clerical error). (I have another IPFW table for Seriously Annoying netblocks -- for that one, I have IPFW rules to block all traffic in either direction. This isn't something I do lightly, but I will protect my network.) I use this on all of my machines that are (or may be) exposed to networks not under my control -- thus, in addition to the above-cited border machine at home, I also do the same on my laptop. And as my laptop is used to track stable/6, stable/7, stable/8, and head on a daily basis, I think it's fair to say that the approach gets at least some exposure to what's changing in FreeBSD & IPFW fairly regularly. In any case: please do not assume(!) that sshd(8) is logging all 22/tcp SYN traffic. You may want to adjust things so you can see such traffic. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ZInfyf7laFu/Kiw7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksWcuQACgkQmprOCmdXAD3vcwCeN+1bHFtVwkKgYp/Kvzt2u7GF BCYAniWTxXwAChcvn7How0HGI1xRzVxE =b4bo -----END PGP SIGNATURE----- --ZInfyf7laFu/Kiw7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091202140005.GE1441>