Date: Wed, 28 Nov 2001 15:48:08 +0000 From: "WebSec WebSec" <secure21st@hotmail.com> To: freebsd-security@FreeBSD.ORG Subject: Best security topology for FreeBSD Message-ID: <F140NsokLQ8aZRhQdOg00016fa1@hotmail.com>
next in thread | raw e-mail | index | archive | help
NOT TO START A BIG DISCUSSION BUT I THINK THESE RESPONSES ARE REALLY OFF THE TARGET. I do not have much time and will not be able to respond to more comments but did want to give myself a chance to explain.... >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?" This is an ignorant response. To "smash a stack" you need at a minimum a connection to the machine. The most you can do without a connection is to run a DOS. I do not see how it is possible to smash the stack by playing with queuing. Do a little reading sir or at least show how it can be done in theory... we will take to the next step :) Your phrase is equivalent to saying something like this: If you have not heard about GMC SUBURBAN ( A really big car) transporting 700 people cross-Atlantic - it does not mean it cannot be done. I agree that things are a bit more complicated in our world but com'mn... show me how you would approach executing a stack on any non-trojaned packet filtering device... at least in theory... I thought you couldn't :) >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. This is just silly.... I hope you understand what it means to not allow outbound connections. IT would take time to poke around and figure out how and what to do on a machine that does not produce an output. Most likely the machine will crash....soon... And your "IDS" as in " monitoring - analysis - incidence response on network and host levels" not as in " a product" WILL TELL YOU ABOUT. THIS IS TIME. Clearly, you are not sure what you are saying here. IN YOUR SINGLE FIREWALL DESIGN - IF A FIREWALL IS COMPROMISED YOUR ENTIRE SECURITY MODEL IS BLOWN OUT OF THE WATER! >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. THE EXTRA TIME IS THE KEY SECURITY CONCEPT. IF YOU HAVE UNLIMITED TIME - YOU CAN GET TO ANYTHING... WELL ALMOST :) Ever wondered why "Important" Banks and other installations are not to far from police stations? Your phrase that time is not important goes beyond technical incompetence right into security ignorance. No offense. >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> Well actually "ass" is not a very professional term - I would personally try to avoid it on the Net - but yes a TCP WRAPPER is a firewall and it is recommended to use the as much as possible... More so, IPSec is a firewall "concept" because it "authenticates" source and, again, it is recommended. So you are right </sarcasm> it would be nice to do firewalling everywhere... Except that these firewalls will not help to mitigate application layer problems.... And, therefore, in many cases are not very helpful. For example, putting many firewalls in a chain that do the same thing (such as filtering the same) does not help with security. This is not what I meant. >>>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 backbends 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. If you would like, we could demonstrate to you that a VPN connection from a WEB server that can execute "arbitrary" code will not help you to keep credit cards secure...but I guess you know that see below. 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. I agree with the webserver concept - it is really smart (no sarcasm) (*) 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. Agreed - but we are talking about a firewall compromise here :) This is where time and 3-tripple firewall architecture and IDS process comes to play... Hope you see this now. >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. The point is "WHAT-IF" you did have a proxy compromise (internal or external). If we were to imagine a single SUPER-SECURE firewall out there would be no need to do anytnhing else... Thank you it was a pleasure. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp 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?F140NsokLQ8aZRhQdOg00016fa1>