Speaking of security and intrusion attempts... :-}

Fri Sep 19 06:54:39 PDT 2008

Caveat Lector:  Although I used to be a sysadmin, that's not what I'm
paid to do any more.  Nevertheless, I do act in that role for my one
networks at home; while there's no plausible way I could think of my
home as a "large installation" for a sysadmin, there are a few things
here & there that might be of interest.

Also (Caveat continued), my "exposed" machines all run FreeBSD.  While
some approaches I use may well be usable (possibly with appropriate
modifications) in oher environments, those other environments are not my
focus, and I don't pretend to know how to go about it.

Ref. Jennifer's comments last night about checking logs: given the
relatively low profile -- and relatively low exposure -- I don't use
real time IDS.  I do, however, try to examine the logs every morning
(for the previous day), checking for specific things:

* /var/log/access.log
  Among other things, sshd logs here for each attempt to login via ssh,
  successful or otherwise. 

* /var/log/security
  If ipfw(8) is configured to log anything as a result of seeing
  traffic, this is where it's logged.

Now, I have things set up so that sshd on one of my internal machines
on the "trusted" network may be reached from machines on other networks
(including the "guest" network at home).  Authentication is only via
SSHv2 public key.

I also run ipfw(8) (a packet filter that has been part of FreeBSD for
over a decade) on the "firewall" machine (a triply-homed FreeBSD
box).  Among the things I have it configured to do:

* Log every attempt to initiate an SSH connection.
* Use ipfw(8) "tables" (accessed internally in a way very similar to
  routing tables) to block certain types of traffic.  In particular:
  * Table 1: there are a couple of ipfw(8) rules for this one.  One
    blocks all incoming traffic from any netblock cited in table 1.  The
    other blocks all outgoing traffic to any netblock cited in table 1.
  * Table 2: An ipfw(8) rule blocks all incoming 22/tcp traffic from any
    netblock cited in table 2.
  * Table 3: An ipfw(8) rule blocks all incoming 80/tcp and 443/tcp
    traffic from any netblock cited in table 3.
  (I've been thinking of setting up a table of netblocks that would be
  subject to DUMMYNET "traffic shaping" -- this would provide a somewhat
  slow, lossy connection for certain especially "deserving" netblocks.
  I may also create a table to block 25/tcp from certain netblocks,
  rather than using sendmail(1)'s access database: the ipfw(8) table
  would certainly be more efficient and less resource-intensive.)

So I use a fairly simple shell script in the morning to show me the
appropriate log entries from the beginning of yesterday to the present
time; a quick scan is usually enough to determine if more attention is
warranted.

This morning was one of the time that "more attention was warranted."
There were well over 1K SSH login attempts from 6 different IP
addresses yesterday.

For each of the source IP addresses, I checked WHOIS, then sent off a
note to the listed contact for the netblock.  (I make no attempt to
correlate the IP address with a domain, nor to contact whoever is
allegedly responsible for the domain.)  I have a "boilerplate" template
set up, and I make the appropriate changes, then read in the appropirate
log entries.  The message provides information about what the log
entries are showing, as well as specifying  the current offset from UTC.
The message is also not accusatory: it is a message that I would
appreciate receiving, were any of my systems implicated in such
activity.

The template also includes a Bcc: to myself and a Reply-To: for
<hostmaster at catwhisker.org> (which, like postmaster@, bypasses several
anti-spam checks).

I admit that response to this varies.  And I have responses for some of
those (non-)responses:

* Silence.  Most often, there's no response to my notification.  That's
  not entirely a Bad Thing, if the abuse ceases.  But if I get no
  response and the abuse continues, the netblock gets added to Table 1.
  At that point, the abuse stops -- for my network, at least.  Further,
  if I encounter another netblock for which the contact information is
  the same as one I've added to Table 1, I add the new netblock to Table
  1 as well.  Case in point: CHINANET-*.

* Auto-response.  Thanks; I kinda knew that my message was Very
  Important to you.  Right.  I treat this as I do the above "Silence":
  if the abuse stops; fine.  If not, I make it stop.

* Semi-canned response.  This tends to be from RIPE nets -- a note
  saying that they've chastised the person(s) responsible for the network
  in question.  Same as Silence. :-}

* Thanks.  Yeah, sometimes I actually am lucky enough to send one of
  these to someone who is both clueful and professional enough to
  appreciate the notification, take constructive action, and thank me
  for it.  That alone nearly makes the exercise worthwhile.  And unless
  I perceive egregious attempts from such netblocks, I won't block them:
  I have reason to believe that someone is actively trying to do the
  right thing.

* Message non-delivery notification.  This could be from any of several
  reasons:  for example, the contact address from WHOIS might be no
  longer current.  (In that case, if I have reason to believe that my
  message did not get through to anyone -- I will use all salient
  contacts from WHOIS on the original message -- the netblock is added
  to Table 1 (on the grounds that no one appears to be "minding the
  store").  Another reason: Some MTAs are configured to reject mail from
  what appear to be residential customers' machines (vs. the residential
  customers going through their ISPs).  Those get added to Table 1.

So far, I don't recall getting any responses questioning what I reported
or denying the attempts.  :-}

I add a netblock to Table 2 if I see many more log entries from the
packet filter for a given source address than I see from sshd(8).  I
don't know exactly what they're doing except that for whatever reason,
sshd(8) isn't logging most of the activity.  I don't like it; it makes
me nervous.  Table 2 tends to make me ... a bit less nervous.

I've also cobbled up some scripts & Makefiles to make messing about with
these ipfw(8) tables less labor-intensive than it might otherwise be.

For example, one of the scripts runs whois(1) against a token and amkes
a reasonable attempt to extract the CIDR block specification from it.

There's a somewhat-hackish directory structure associated with this:  at
the top level, there's one directory for each ipfw(8) table.  Within
each of these, there's a Makefile and there is one subdirectory for each
registry; the name for the subdirectory is the same as the argument to
(FreeBSD's) whois(1) client (without the leading hyphen) -- e.g., RIPE
netblocks will be in the "r" subdirectory; ARIN netblocks in "a"; APNIC
in "A", LACNIC in "l"...).  Each of these is populated with files; the
name of a file is the name of the netblock (except for LACNIC netblocks,
as they have "inetnum"s insteadof "netname"s); the content of each file
is a list, one per line, of CIDR blocks associated with that token.

The Makefile runs the above-mentiond whois-parsing script on any file
that is newer than its subdirectory.  So I merely need to touch(1) an
appropriate filename (twice, if it didn't already exist) and run
make(1); that will populate the file with the CIDR blocks and update a
file that is a concatenation of all of them for a given table.  I have
another script that adds lines from specified file(s) to the appropriate
table.

And I actually maintain this structure both on my home firewall and on
my laptop (since the laptop is sometimes exposed to the Internet, after
all).

To quote Alastor "Mad-Eye" Moody (from the "Harry Potter" books):
CONSTANT VIGILANCE!

Anyway, that's enough rambling: I need to do other things today.

Peace,
david
-- 
David H. Wolfskill				david at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20080919/9cbc8cea/attachment.bin>