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 from 190.198.167.71 Dec 2 04:21:08 albert sshd[6178]: Did not receive identification string from 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 172.16.8.13:22 out via dc0 Dec 2 04:21:08 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:39854 172.16.8.13:22 out via dc0 Dec 2 04:28:03 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:45562 172.16.8.13:22 out via dc0 Dec 2 04:28:05 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46050 172.16.8.13:22 out via dc0 Dec 2 04:28:06 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46081 172.16.8.13:22 out via dc0 Dec 2 04:28:07 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46128 172.16.8.13:22 out via dc0 Dec 2 04:28:09 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46574 172.16.8.13:22 out via dc0 Dec 2 04:28:10 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46619 172.16.8.13:22 out via dc0 Dec 2 04:28:11 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46662 172.16.8.13:22 out via dc0 Dec 2 04:28:12 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:46708 172.16.8.13:22 out via dc0 Dec 2 04:28:14 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47152 172.16.8.13:22 out via dc0 Dec 2 04:28:15 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47194 172.16.8.13:22 out via dc0 Dec 2 04:28:16 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47238 172.16.8.13:22 out via dc0 Dec 2 04:28:17 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47273 172.16.8.13:22 out via dc0 Dec 2 04:28:19 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47717 172.16.8.13:22 out via dc0 Dec 2 04:28:20 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47758 172.16.8.13:22 out via dc0 Dec 2 04:28:21 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47805 172.16.8.13:22 out via dc0 Dec 2 04:28:22 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:47846 172.16.8.13:22 out via dc0 Dec 2 04:28:24 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48289 172.16.8.13:22 out via dc0 Dec 2 04:28:25 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48329 172.16.8.13:22 out via dc0 Dec 2 04:28:26 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48372 172.16.8.13:22 out via dc0 Dec 2 04:28:28 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48410 172.16.8.13:22 out via dc0 Dec 2 04:28:29 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48850 172.16.8.13:22 out via dc0 Dec 2 04:28:30 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48889 172.16.8.13:22 out via dc0 Dec 2 04:28:32 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48932 172.16.8.13:22 out via dc0 Dec 2 04:28:33 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:48976 172.16.8.13:22 out via dc0 Dec 2 04:28:34 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49417 172.16.8.13:22 out via dc0 Dec 2 04:28:36 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49466 172.16.8.13:22 out via dc0 Dec 2 04:28:37 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49512 172.16.8.13:22 out via dc0 Dec 2 04:28:39 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49954 172.16.8.13:22 out via dc0 Dec 2 04:28:40 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:49996 172.16.8.13:22 out via dc0 Dec 2 04:28:41 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50039 172.16.8.13:22 out via dc0 Dec 2 04:28:42 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50080 172.16.8.13:22 out via dc0 Dec 2 04:28:44 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50520 172.16.8.13:22 out via dc0 Dec 2 04:28:45 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50562 172.16.8.13:22 out via dc0 Dec 2 04:28:46 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50597 172.16.8.13:22 out via dc0 Dec 2 04:28:47 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:50639 172.16.8.13:22 out via dc0 Dec 2 04:28:49 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:51064 172.16.8.13:22 out via dc0 Dec 2 04:28:50 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:51089 172.16.8.13:22 out via dc0 Dec 2 04:28:51 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:51113 172.16.8.13:22 out via dc0 Dec 2 04:28:52 janus kernel: ipfw: 10000 Accept TCP 66.234.187.17:51141 172.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 -- David H. Wolfskill da...@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.
pgpjloYOUkD8M.pgp
Description: PGP signature
