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