Date: Tue, 27 Nov 2001 19:16:48 -0500 From: Allen Landsidel <all@biosys.net> To: freebsd-security@freebsd.org Subject: Re: Best security topology for FreeBSD Message-ID: <5.1.0.14.0.20011127185418.00af0828@rfnj.org> In-Reply-To: <F136r0qUasw83tnJz0L000178a5@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:31 PM 11/27/2001 +0000, you wrote: >Can someone show me an example of "a packet" that can execute arbitrary >code on a firewall that only does filtering... :) I don't imagine they can. If they could, chances are it would be patched before you ever even heard of it. So what you're saying is security based on "I haven't seen such a thing, so I'm safe from it?" >Clearly, either I am too far behind or someone is too far ahead.... If you >are implying a compromise of a proxy server, this same proxy should not be >moving "outbound" traffic and the filtering firewall should be configured >as such. This would prevent someone getting a shell access, at least >immediately. Note that you created "one" more hop and, therefore, have >extra time for your IDS to detect the attack. Mission accomplished! You figure a less than one ms hop (that has already taken place) gives your IDS "more time" to respond? Please. Any IDS worth it's salt is going to get the packets, examine them, and then pass them on. I'm talking wrappers or firewall type stuff here, not something like snort that just puts the thing in promiscuous mode and listens to traffic that it can't stop. >In case you have a single firewall..... you did not get that extra time. It doesn't matter anyway, the "extra time" is a silly concept. It's not going to matter. Even a 486 has the processing power and bandwidth to handle a T1 and a reasonable set of firewall rules.. it's getting out there into the really expensive part of the bandwidth world where even a mediocre machine can't keep up. >To make it even more interesting, a "triple" firewall set-up help to >mitigate many of the risk. IT is, however, an overkill in many-many-many >cases except where security really matters. :) > >Now, a quad system will probably not be practical or at least I have not >seen a situation where it would be practical :) Now, you're just talking out of, for lack of a better term, your ass. Maybe we should imagine ourselves up a network where there is a double firewall system like has been discussed here, and then another one on each and every port for each and every hub and switch! Wouldn't that bad boy sure be secure!! </sarcasm> >>>Yes. But a single firewall design is also vulnerable to this >>>attack. >>The same way. > >No it is not if it is properly configured and is not doing proxying... This is a reply to something someone else said, so I'll let them respond to it. >Whoever put this together have not ever set-up web - sql architecture... >Your web server should be on "DMZ".. but what do you do with SQL if it >does not accept connections...? :) Keep it on DMZ also? You have a SQL that doesn't accept connections? Doesn't sound like any firewall configuration is going to affect that piece of junk in any way, shape or form. FYI, I have set up SQL backends for webservers in a DMZ exactly as described above, and there are plenty of ways to enhance their security. The most basic is an encrypted VPN connection between the webserver and the SQL server. In reality however, this sort of thing isn't really needed. If your router is set up to stop as many spoofed packets as it can detect(*) which it should be no matter what your goals are, then your only real problem here is something flawed I see implied in your design : You code your database passwords into the web frontend for access to the DB. If your DB data is critical enough that you can't risk bogus records being inserted, and sensitive enough that you can't risk the wrong person on the outside seeing it, at the very least it should be https access only, and use a user supplied password. In reality, it probably shouldn't be a webserver at all. (*) Basically this is only three rules. #1 deny all packets from inside your network that don't come from your netblock(s), #2 deny all packets from outside your network that do come from your netblock(s), #3 deny all packets that have a source or destination address on a private IP subnet with very specific allow rules only if you really need them. >In other words, dual firewalls are "a lot" better in many (NOT ALL) cases >(if one uses different products). But you do need to match products carefully. You didn't make an argument to this point; Nothing constructive was offered that bolsters the credibility of a two firewall design. I'll cover the simple facts once again. 1. One firewall can easily do the job of the two described if the rulesets are merged. 2. Two firewalls does not for the most part provide two "layers" for an attacker to work through; it simply provides two different targets for an attacker to attempt to compromise. I am not against the previous definition of a single firewall with three interfaces; one for outside, one for inside, and one for the dmz.. but it's usually not required. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.0.20011127185418.00af0828>