L-Class Box in a DMZ?

[Ross Zubritski]

We are about to purchase an L class server to use as an application server to issue calls to a db server on an internal network.

The 100BT interface will be connect through a firewall to the internal network as well as the net. My question is can I add a 1000BT "backbone" connection on the production network as well and disallow routing between the 100 and 1000 base interfaces.

Comments?

Thanks in advance.

RZ

[Jeff Schussele · Accepted solution]

Hi RZ,

Certainly - that's do-able.
But I'd strongly urge you NOT to bypass your firewall with that backbone connection.
Create a new ruleset at the least - maybe even use a dedicated FW that can handle that connection type & speed.
If by chance someone was able to gain access to that system - by whatever means - they'd be straight on your network and that's not a good thing.

My $0.02,
Jeff

[Michael Steele_2]

Been involved with two DMZ's where there were public facing servers and the application and network guys took care of everything except the following (* and web console access *):

...ip_ire_gw_prob...

...which had to be set to 0 else the LAN would shut down. The explanation I got from the network admin was specific to a ping being sent out from the server to the default router. Upon failure a timeout would occur and the LAN would shutdown. I believe the timeout is 3 minutes. Here is the command line syntax:

??????ndd -set /dev/ip ip_ire_gw_probe 0??????

And in /etc/rc.config.d/nddconf:

TRANSPORT_NAME[2]=ICMP
NDD_NAME[2]=IP_IRE_GW_PROBE
NDD_VALUE[2]=0

The LAN or WEB console meant having a separate switch on a different private LAN for the obvious reasons. On the A500 it???s a 10BaseT connection with FD and the auto sense turned off for us to make it work. Use the linkloop command for this to test for connectivity to the switch's MAC. :-)

[Chris Vail]

One thing that worked for us was to connect the database server (inside the firewall) to the app server (outside the firewall) on its own private network (hubs are cheap these days) or just use a crossover cable. Basically, disable all services on the app server except Apache or whatever web service you need. The data came from the DB server via a directory mounted to the app server via NFS (I'd use CIFS nowdays). With every other network service turned off (including telnet, ftp, rlogin, etc) the server was relatively secure. The only communication between the client and the server was NFS and rpc's, which are relatively secure. Even if an intruder did get control of the app server, there was nothing there except the application. This means that the only way to maintain the app server is via the console, but the Secure Web Console is a very cool piece of hardware, so little is lost.


Chris

[Bill Hassell]

Most company policies would forbid this type of connection. A machine that bridges the internal net and the Internet is now a firewall whether you like it or not, and as such, a massive amount of work needs to be done to harden that machine. Out of the box, HP-UX is ready for internal networks only and even then, needs serious patching and service modifications. To simply disallow routing will not guarentee any security at all. This box needs the Bastille product to help with tightening things up plus IDS/9000 (Intruder Dection System) among other security tasks, and need 24x7 monitoring.

[rick jones]

Bastille is a good idea - disabling ip_forwarding is likely a very good idea.

As for allowing the connection in the first place, I've no idea if that is wise or not.

The ip_ire_gw_probe stuff - when the ICMP echos (pings) are not answered, it is the _route_ that is marked as dead, not the LAN itself. Sometimes that may have the same net effect (if all the comms are off-LAN) but it is still an important distinction.