Bob Feighner wrote:
>
> We are looking at the vulnerability of our HP 3000 to access from
> unauthorized sources.  What approaches are you using to this?
> Firewalls and nsconfig come to mind, of course.
>
> Are you using any log file analysis or other software for
> assistance?

This is a very broad and encompassing question, but let me try to
localize it a bit to 3000-specific items.

First, there are provisions you can make on the 3000 itself which are
clearly platform (and in some cases, release) specific.  I am assuming
your system is directly connected to the Internet, but for the more
paranoid manager, you may wish to consider these even if you are behind
an established firewall.

* Under 5.5, if you are running inetd (typically JINETD.NET.SYS job)
  then you have available to you the file INETDSEC.NET.SYS which
  should have a symlink to /usr/adm/inetd.sec (or vice versa).  This
  file can be used to provide explicit control of who can access the
  various services provided by inetd (telnet in particular).  You can
  setup 'permit' lists for your trusted internal hosts/networks and
  other access will be denied.  On 6.0, this protection is extended
  to ftp (not true of 5.5).

* Option logon UDCs can check for bound variables HPREMIPADDR and
  other related variables to validate origins of telnet sessions.

* If you are running a Telnet Access Card (TAC) in a DTC, the above
  telnet protections do not apply; TAC-based telnet sessions look like
  serial DTC connections, but you can check HPDTCPORTID for the MAC
  address of the DTC and the slot number of the TAC card and be able
  to at least know if this is a telnet session from "somewhere" as
  opposed to a real serial connection.  There is no way known to me
  or any HP engineer I've spoken with to determine the origin address
  of a TAC login from the 3000 (from a PC-based DTC Manager machine
  yes, but otherwise no).

* Create an SNMPCONF.NET.SYS file from the supplied SNMPSAMP.NET.SYS
  example file, and change the community name to something other than
  the default of 'public' to prevent SNMP MIB discovery on your 3000
  by outside intruders.

* If you have multiple network interface cards, you might have a setup
  with one NIC on the internet, and the other on your internal network
  only.  If that is the case, be sure you have IP forwarding disabled
  (in NMMGR, set "store and forward buffers" to zero) and don't you
  dare try to use the 3000 as a gateway.  This can create a backdoor
  to your internal LAN.

* Disable inetd services you don't use (echo, discard, chargen,
  daytime, etc) - they are often DOS attack targets.

* Encourage the response center/HP in general to change the way that
  TCP sequences are generated.  They are currently very predictable
  which leaves you open to spoofing attacks.

* If you have DTCs and more than one NIC, run your DTCs on one NIC
  (typically the MIO card interface) and if you don't need IP traffic,
  don't configure IP on it, and/or don't enable Ethernet (DTCs and
  the DTSLINK NI operate with 802.3 framing).

Other details which should be applied to firewalls and any other traffic
filtering points in your network that are specific to the HP3000:

* NS/3000 services are on nonstandard, "unusual" ports.  For example,
  NS/VT sessions use ports 1537 and 1570; if you don't want outside
  VT sessions then block these ports which might otherwise be enabled
  since they are "ephemeral" ports (anything > 1023).

* If you have Allbase/NET it uses port 7489.

* If you have IMAGE/SQL with ODBC enabled, it is on another port
  (the number escapes me at the moment)

* If you have the full NS/3000 services product installed, you have
  other exposed ports in the range of 1536-1542, plus 2560 for remote
  DB access (old NS remote Image access method).

* If you are running freeware Samba, Sendmail, Bind, NTP, etc., you
  must provision for those services as you would with any linux/un*x
  platform with the provision that you have inetd.sec available for
  those services under inetd control (like HPUX, but otherwise fairly
  unique/proprietary) but not for those that run outside of inetd.

That should give you a start to those items "above and beyond" the
standard firewall and host recommendations.  That part is best left as
an exercise for the reader :-)

Jeff Kell <[log in to unmask]>