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]>