From: Ben Nagy [bnagy@cpms.com.au] Sent: Wednesday, August 11, 1999 8:59 PM To: 'Bradley'; ntsecurity@iss.net Subject: RE: [NTSEC] Firewall - 1 by check point and Proxy 2.0 TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net Contact ntsecurity-owner@iss.net for help with any problems! --------------------------------------------------------------------------- Well, to my mind, the main security problem with this setup would be webserver and mailserver integrity. I guess these are the only services you offer to the outside world, right? It seems to be that the best way to attack this configuration would be to compromise the webserver that allows connectivity to the input database. If this then puts you inside the trusted domain, then away you go. Even if it doesn't, you can still launch general TCP/IP based attacks to subvert the whole domain model. Do you have filters on which IP ranges etc can access this WWW server? Is the WWW server trusted from a domain point of view? (there doesn't seem to be any reason for it to be...) I guess basically, this is where a DMZ would normally be used, and the WWW server that can be accessed externally would be in it. Maybe a third NIC in the proxy server would do it. Your mailserver is also an attack point, so make sure there are no bugs in the way it handles incoming email (buffer stuff, sendmail bugs, crash exploits etc). HOWEVER, getting to the point, the stuff above is icing on your existing cake (which seems pretty sound). Simply putting in a state-based firewall (eg Checkpoint) isn't going to do anything to further restrict the access to that target webserver / mailserver. Therefore, IMO, it's not going to measurably improve your security. If the consultant knew what they were about they might have recommended an application level gateway instead, and claimed that the HTTP sanity checking would make it harder to hack the target webserver. Maybe. Personally I would take even that with a pinch of salt. HTTP is so gross now that many people feel that it's no longer feasible to sanitise it with a smart proxy. An application proxy probably would improve the security of your mailserver, but it's pretty marginal. Now, back to rambling. If you're prepared to deal with a significant level of manual operation (which it seems you are), then how about this? Run your external access WWW server on a third NIC. Put the holding DB on this DMZ. Don't have any internal machines connected to the DMZ LAN. When you want to input the data, switch the box hosting the taintable DB onto the internal LAN (they make hardware AB switch boxes that do this), run your checks, import the data, then switch it back. Note that this is bad if the taintable DB and the master DB are on the same box. -- Ben Nagy Network Consultant, CPM&S Group of Companies Direct: +61 8 8422 8319 Mobile +61 414 411 520 -----Original Message----- From: Bradley [mailto:brad@capecod.net] Sent: Wednesday, August 11, 1999 12:33 AM To: ntsecurity@iss.net Subject: [NTSEC] Firewall - 1 by check point and Proxy 2.0 TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net Contact ntsecurity-owner@iss.net for help with any problems! --------------------------------------------------------------------------- My client has a windows network with the 10.x.x.x internal LAT setup. They use Proxy 2.0 on a Windows NT Server to access the web. All the clients use basic WWW services, Pop3, and SMTP when accessing the web (hardly anything else). A remote user will view WWW services on the Proxy 2.0 server (through a dial up ISP). Security, in this situation, is controlled by referencing a MS Access 7.0 database. The .asp forms are for input only on a separate database from the main one. Another application is run every night to import this data to the main database. It is only imported if an internal operator has manually approved each record. The Proxy is set on its own domain, with IP routing disabled. It has two network cards; one goes to the T1 and the other to the internal network (the LAT table is correctly set). Filtering is enabled. In fact, physically at the console, the proxy server can't even see the internal domain shares, since it is not trusted. Now a consultant for this client is pushing Firewall -1. Is there a case where this is even needed? They have been running proxy for about 2 years, connectivity is good, and all port scans and Exploits seen to have been properly detected. I have been testing allot of situations, and only some exploits can effect this situation, with minor performance degradation but proper logging. I see no reason to add any Firewall, and no one has yet to properly countered me on this technical issue. Why should the client pay the big price for a Firewall?