Re: ipchains FW, monitoring for scans, & how to react to them

[Crispin Cowan <crispin () cse ogi edu>]

Danny Rathjens wrote:

> My conjecture was that disallowing any access to port 80
> from an address that has in the near past attempted to connect to a
> port such as 1(indicitave of a port scan) would increase the
> security of my web server.

This is:

   * simple intrusion detection (if they port scanned me, it's an intrusion
     attempt)
   * simple reaction to intrusion (deny *all* access to the offending IP)

> I don't think this point is very debatable(although, as someone pointed
> out, the DOS possibiities could be significant if I implement it
> improperly)

Yes, the DoS implications are significant.  If an attacker were to detect this
behavior, they could easily trash your web server by spoofing source addresses
on lots of port scans.

It seems to be a violation of one of Andy Tanenbaum's great pithy quotes:
"Never check for an error condition you don't know how to handle :-)"  Since
the attacker is (obviously) poorly authenticated, a reaction that denies
service to the attacer's putative identity seems ill-advised.

Running a port scan detector is certainly a reasonable intrusion detection
plan.  The problem is in the adaptive response.


> As to responding to ports other than 80, I don't believe either of my
> two implementation suggestions fall in that category since the ipchains
> DENY rule drops the packet(e.g. headed for port 1) on the ground and
> portsentry configured properly remains mute as well.

So you're detecting intrusions that won't actually affect you.  Not only do we
not know how to handle this error condition, we also don't care :-)  Why scan
for intrusions that won't affect the web server, if it doesn't matter *and* you
can't do anything effective about it?

If you really want to persue this line of investigation, I think it would be
effective to:

  1. Purchase a commercial intrusion detection system, which will be much more
     effective than a hand-crafted hack like some ipchains rules and a log
     sniffer.
  2. Formulate a policy for what your site will do when intrusion attempts are
     detected.  Cutting off all service to the offending source IP address is
     problematic :-)  Robo-e-mail to the offending source is probably less
     intrusive.

Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc.    http://wirex.com
Free Hardened Linux Distribution:                 http://immunix.org