Re: Why is this secure??

[Mikael Olsson <mikael.olsson () enternet se>]

Hi Steve,

My reply ended up being... well.. not as thought-through as one
might like, but I'm sure you'll be able to glean atleast some
good points out of it...

Here goes.

Steve Meeters wrote:
> I'm not a security expert 

You sound a whole lot more like a security expert than a lot of 
people calling themselves security experts :-)

> I have been reading and following discussions on this list for a while and
> have come up with a plan to put an external web server on the third leg of
> the firewall and have customers go to this web server, fill out a request
> form and submit it. Using cgi scripting, the web server will send the
> request through the firewall to the internal server which will then send the
> requested information back to the web server, which will forward it to the
> customer.

This sounds more or less a highly specialized proxy, which is pretty much
the best way to get good security: small compartmentalized components
whose integrity is easy to check. There are a couple of caveats however.

You need your public web server to also be small and simple, to keep
it at the same level of manageability. You also need to make certain
that your CGI is well written, especially taking buffer overruns in mind.
Never use calls that operate on buffers that do not accept maximum
length arguments. In other words: No strcpy(), sprintf(), strcat().
Instead use things like strncpy(), _snprintf()

One thing I'd like to know is what request are you sending from the
web server to the internal server? Your message doesn't say.

> Like I said, I'm not an expert at this and have come up with this plan based
> on what I've read here and in some books. What I need to know is why is this
> more secure than letting Internet traffic through the firewall directly to a
> web server on this internal system? Putting up an external server is going
> to cost more, we'll need another system, web software, and another interface
> for the firewall.

Web servers in general are large and complex and therefore prone to security
related bugs. You really want to place your publicly accessible web servers
somewhere else than on the internal network.

The primary attack vector would be to get your web server (or poorly written
CGIs, perl scripts, ASP pages, etc etc ...) to execute commands sent from
the outside. If this happens in the internal network... ouch.
If this happens in the DMZ, it isn't too much of a problem. HOWEVER since
you're drilling a hole between the DMZ and the internal network, this hole
needs to be as small as possible. Preferably it wouldn't have anything to do
with HTTP, which is a wee bit too complex for my taste.

> What threats am I specifically opening our network up to by creating a rule
> that allows all traffic to the internal server? I read this is a bad idea
> but why can't the firewall protect against this? Assume for the sake of
> argument the firewall is secure.

That allows ALL traffic to the internal server? As in "opening HTTP
from everyone", I take it?

You're opening yourself up to lots and lots of data driven attacks.
Do a search on, for instance, www.securityfocus.com and look for
"CGI" and "xploit". Also look for things related to your web server
make and model. The net result will be that people are able to
execute any command / machine code on your web server. Not a good
idea.

This ofcourse applies to machines in the DMZ aswell, but smaller
is usually safer, and we're thinking limiting the possible damages here.

> What protection does this type firewall still provide to our network if this
> rule is in place? At what OSI levels?

Welpz, it'll most likely protect you from harm at the IP and TCP levels.
It will analyze your HTTP data somewhat, but probably not completely.
Your web server could, for instance, be vulnerable to buffer overruns
in some HTTP parameters.
It will NOT look at querystring parameters nor POSTed parameters.
This is where the problem mainly lies when it comes to poorly written 
server scripts. Any parameters get passed through.

> If the external server is compromised doesn't the attacker now have a open
> path to the internal server, the same as if the external server wasn't there
> at all?

Yup, this is why you want to make your external server very manageable,
and the hole through the firewall as small as possible (as I said, non
HTTP based if possible).

Having the hole through the firewall being non-HTTP based doesn't add 
security in and of itself.
I just mean that it should involve something small and manageable,
providing a minimum set of features for the external web server
to use.
It's really all the "cool and user friendly stuff" that is screwing
us over royally. Too much code to be secure.

That's about it :-)

Regards,
/Mike


-- 
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46-(0)660-105 50           Fax: +46-(0)660-122 50
Mobile: +46-(0)70-248 00 33
WWW: http://www.enternet.se        E-mail: mikael.olsson () enternet se