Hmm..the idea about locking an account is okay, but in my opinion can be really nasty too. A real easy way to issue a denial of service attack would be to find out which user id is used for the main application and then lock it.
-------------------------------
Gary L. Paveza, Jr.
Technical Support Specialist
All opinions are mine and not those of my employer
-----Original Message-----
From: Jeff Kell [SMTP:[log in to unmask]]
Sent: Thursday, December 03, 1998 7:56 PM
To: [log in to unmask]
Subject: Re: HP3000/Internet Security Was: Dialup to a 3000
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]>