HP3000-L Archives

December 1998, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Thu, 3 Dec 1998 19:55:57 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (55 lines)
OK, I posted a bit of this to Wirt, but let me bring up a few other
items:

* Filtering by specific IP address to DENY is a bad idea, as has been
  pointed out, since ISPs and many sites have dynamic address
assignment.
  With some firewalls the address can change with every TCP connection,
  not just a DHCP assignment.

* If you have a "protected" service like telnet, NS/VT, ftp, etc., why
do
  you give the public a chance to get there in the first place?
inetd.sec
  does a fine job of this for inetd services and should be duplicated
for
  the NS services in some form (can DSDAD/SOCKREG/etc be enhanced to
look
  for inetdsec.net.sys?)  Specifying a list of 'acceptable' networks is
  much easier than 'allow the world except x, y, and z'.

* The primary risk is brute force attack, which at internet speeds can
be
  a viable option.  So consider a few things available in *cough* HP-UX:

  - for each failed login attempt, there is a configurable delay before
    you prompt for another login (i.e., after 'invalid password' it
delays
    for this interval of time before another prompt appears).

  - dropping the telnet connection after some number of invalid
attempts.

  - after a configurable number of successive invalid login attempts,
the
    login is "locked" and can only be released by root; if root is the
one
    locked you can only unlock from the console.  In MPE terms, the
login
    procedure would "lock" the user.account, only to be freed up by the
    MANAGER.SYS login; if MANAGER.SYS is the one locked, you can only
free
    it from the console.

This whole discussion presumes someone is trying to break in (which they
will do indeed, but has not scratched the surface of malicious denial of
service or crash attacks, such as the 'ping of death' or the 'smurf'
(ping flood), or countless other things that script kiddies seem to just
love to play with.  IP address blocking?  These kids fake their
origins.  Imagine
a connection request sent to your 'chargen' socket being faked as if
from your 'echo' or 'discard' socket (you did disable these, didn't
you?).

Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2