RE: [suse-security] AW: Squid on Firewall?
Huh? Get real, man, with that attitude you shouldn't connect anything to an untrusted network, as any application could be susceptible to buffer overflows. And check out the literature on firewalls whenever you have a bit of spare time, I recommend the 2nd edition of 'Building Internet Firewalls' by Chapman, Cooper and Zwicky. Most, if not all, of the firewall people prefer application layer gateways, aka application proxies, over packet filters when constructing firewalls. And I'd much rather have only one application, the proxy, to watch for a compromise than the entire number of client applications.. Cheers, Tobias
hey tobias, yes, your are right! getting compromised by a client applications isn't good indeed...;-) but that wasn't my hint about this topic. my idea is to separate your system into two ones: first you have a hardened firewall-system without any programm running on it. second there is a proxy-server behind the wall with "your" application proxies. and that's all...;-) greets, daniel "Reckhard, Tobias" schrieb:
-- Daniel Quappe Dienstag, der 27. März 2001 Systemadministrator E-Mail: quappe@erster.de Fon +49 (0)202 252 15 99 Fax +49 (0)202 52 20 99 Didn't take a look at http://www.erster.de yet ?!
Hi, On 27 Mar 2001, at 7:44, Reckhard, Tobias wrote:
Huh? Get real, man, with that attitude you shouldn't connect anything to an untrusted network
the point is that even if someone exploits a firewall and got root permissions this person must be the smallest possible threat to the protected network. If you are logged in as root on a computer that acts as a firewall, you must not find any way to exploit the internal network: 1) there must not be a ftp client or other tools to download files to that computer, 2) there must not be access to a dns server mapping the protected network thus one must browse the log files to get an idea of the members of the internal network and make it as hard as possible to browse files (no editor), 3) all files should be read only or append only in multiuser mode so the boot structure cannot be manipulated 4) the firewall computer should not do anything but filter and forward traffic I do not know about squid, but I would put it on a computer behind the firewall. Even for a 100Mbit network connection any old pentium 100 (or mac, or sparc, or whatever) with some ram should be able to handle maximum possible load without problems. Given the fact, that such a computer will cost less than USD 100,-- so cost should not be the reason not to have it! mike
I'm still learning. Can you clearify for me about dns on your packet filter? What I gather from your ideal here is this: - no nameserver runs on the filter. - the resolver on the filter does not point to internal (or DMZ even) nameservers. - /etc/hosts on filter lists localhost only. Does the packet filter need access to any nameservice at all? On Tue, Mar 27, 2001 at 04:44:16PM +0200, Thomas Michael Wanka wrote:
-- -ashley One of these days I'm going to completely organize my life.
Hi, On 28 Mar 2001, at 7:32, Ashley wrote:
I'm still learning. Can you clearify for me about dns on your packet filter? What I gather from your ideal here is this:
There are three different scenarios: the first one is the (probably more common) situation where a private network behind a firewall has workstations that need to be connected to the internet. The second is one or more servers that need to be accessible from the internet. The third one is the server that needs to be accessible from the internet and the private network. All three scenarios have different requirements to the firewall.
That is right for the first scenario.
Does the packet filter need access to any nameservice at all?
I cannot see any reason why the packet filter needed DNS access from the security point of view. It might be convenient to resolve IP adresses of the log files, but that reduces security if it is done on the packet filter. There are even other things to be considered. Like for some installations it may be a requirement that the access to or from the internet must not be interrupted. In such cases an intruder with root rights must not have access to commands like rm, umount, shutdown, etc. This may not be too difficult for an installation with 24x7 onsite service as such commands can be kept on a removable medium that is only plugged in and mounted when needed, but to remotely adminstrate such a system requires intensive preparations like a remote controlled medium loader. In other installations it may be convenient at a trace of a breakin to automatically shutdown the firewall computer as the integrity of the internal data may be more valuable as the permanent internet access. mike
I am administering a system that needs access to certain ports, but I do not want to restrict access to these ports for these programs. The ports are 5555 and 7000. How do I do this do that it is still secure and won't create any security holes. thank you, michael
participants (5)
-
Ashley -
Daniel Quappe -
Michael Chletsos -
Reckhard, Tobias -
Thomas Michael Wanka