An easy way into a MPE box is when the default passwords are left
unchanged, like the TELESUP account and a few more third party accounts
that are well known. 


Securing your HP3000 is simple, 


     1. Set unique passwords on all user/accounts, and maybe even
        groups.
        
     2. Use PASSEXEMPT to avoid keeping passwords in job streams,
        enabling you to change passwords frequently.
        
     3. Make sure ACCESS= & CAPABILTIES are set properly to avoid the
        use of the RELEASE command.
        
     4. Programatically Audit, Audit, and then Audit some more!
        


When anyone does logon, there are more options as well......

Write a simple script/program to check the remote IP address at logon,
and if it is from the outside you can add additional security
requirements, keep a table of allowed addresses, log these events ,track
outside sessions more rigorously, or simply not allow it.


I don't have my HP3000 plugged directly into the Internet. However, if
it wasn't behind a Firewall, I believe it would take the beating and
keep on ticking. 

I've configured my Firewall to forward all telnet traffic to the HP3000
directly, and I do see attempts to hack it everyday, but none are
successful. On the other hand, I've had my *nix machines hacked using
buffer-overflows, and brute force attacks several times.


--
Mike.



On Tue, 2012-03-13 at 09:08 -0400, James B. Byrne wrote:
> On:    Mon, 12 Mar 2012 15:45:32 +0000, "Johnson, Tracy"
> <[log in to unmask]> wrote:
> >
> > I take a rather simpler approach.  Whenever these pop-up
> > on the EMPIRE game machine.  I add the first three IP
> > octets into the INETDSEC telnet and ftp deny portion of
> > the file (nnn.nnn.nnn.* \).  I understand this may exclude
> > entire small (and rather innocent) internet providers, but
> > I think  that's a small price to be paid for hosting a
> > hacker.
> >
> > If attempts on the first three octets grouped together
> > start to get closely related to the first two.  I'll even
> > start blocking the first two octets (nnn.nnn.*.* \).  I
> > haven't had to block an entire first octet yet.
> >
> > I understand this is just an old fashioned block list.
> > But in the interest of keeping the Empire game open to as
> > many as I can, this is  probably the best I can do.
> >
> 
> For information on how to hack into an HP3000 see :
> 
> http://bak.spc.org/dms/archive/hp3000.html
> 
> or
> 
> http://www.textfiles.com/hacking/hp3000.txt
> 
> Both dated and yet still applicable. There are many more
> similar sources of information.
> 
> The approach that I have taken with respect to our HP3000s
> and the internet is to place a dual homed Linux box in
> front of the HP3000 and use that to provide firewall, ssh,
> and proxy services.  The setup is fairly primitive:
> 
> Internet->> GW/FW <<--->> Eth0:Linux:Eth1 <<--->> HP3000
> 
> The network connection to the gateway/firewall provides
> the public routable access.  The link between the Linux
> front-end host and the HP3000 is a x-over cable using a
> 192.168.0.0 block address.  Direct network connections to
> the HP3000 nic are physically impossible.  This insures
> physical network security over the non-encrypted portion
> of the network (for SSH access).
> 
> There are a wide assortment of Linux based firewall
> appliance distributions which may simplify set up somewhat
> for novice users. Alternatively, one can simply use a main
> stream distribution or derivative like RHEL/CentOS or
> Debian/Ubuntu and add and configure the packages desired.
> 
> We use a CentOS-5 based host running IPTables, Squid,
> OpenSSH, VSftpd, and Denyhosts as the front-end to the
> HP3000.  IPTables is configured to log and drop for 7 days
> all addresses performing obvious port scans. IPTables
> similarly counts, logs and blocks IP having excessive
> failed connection attempts on visible ports.
> 
> Denyhosts scans the logs for other issues and really does
> not add much to our setup.  However, Denyhosts can be used
> to do itself everything I have chosen to do in IPTables.
> Therefore one may concentrate on learning the
> configuration of just Denyhosts and leave IPTables
> configuration to the minimum necessary to allow access.
> 
> The proxy server handles ftp but we do not allow ftp
> access to the HP3000 at all so I could not tell you if we
> have that set up correctly or not.  We have it there in
> case the need ever arises.
> 
> The intellectual load of dealing with these things is non
> trivial.  However, the price of freedom is eternal
> vigilance.  Once the front-end is setup we run logwatch to
> send daily reports on connections and consider whether
> further configuration changes are necessary.
> 

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *