Printable View
My company utilizes a Cisco PIX 506. The PIX only has 1 ethernet port which goes to our main switch. We currently have an Exchange server that is accessible via the Internet based on NAT and port forwarding. I have opened up ports for PC Anywhere and some other services etc. We are going to be setting up some web servers and I was wondering if this would be a good time to setup a DMZ or should I just leave things the way they are?
If it was me, I wouldn't fool with a DMZ, I'd just leave everything behind the Cisco Pix, and port forward it.
More security that way than what it would be if you put it in a DMZ.
actually if it were me id leave the webserver outside, hardened with a software firewall unless your planning ecommerce or webapps. why compromise the security of your network for a web presences.
true trie tedob, I didn't think of that.
I guess I was thinking more of a multip purpose web server. i.e. Web/file server for the network, or something like that.
Yeah I think as long as you keep some sort of a software firewall on there, then you should be ok that way.
Its always been my understanding that if you have a public server, you want that outside your network. If that box is compromized then you don't want them to have access to your internal network too. If you port forward.. that is the same as saying exploit this box... exploit my network.
Please correct me if I'm wrong.. because I've always stuck HTTP and SMTP servers in the DMZ... thats what the DMZ is there for... right? Just be sure to secure it as much as possible... and keep all sensitive material off of it.
My company has hosts that have our servers off our network... so we don't have to worry about it as much. But I run a small ftp and I've setup HTTP and SMTP for a few friends... secured... I've never had any problems.
Yeah, it can be used for that. However, there's no protection in that from the router as you already know. DMZ should only be used when absolutely necessary. If NAT is causing problems with an application/process etc. If you're using NAT then placing a host in the DMZ will strip it's NAT status and will (usually) strip all of it's firewall support from the router it's self. So no NAT and no SPI support. If it were me I wouldn't go this route. I'd stay with the virtual server's port-forwarding for inbound traffic. Disable remote administation if you're worried that your network could be compromised internally from the outside WAN. As you know everytime you open up a port to forward you're allowing unsolicited inbound traffic to reach your internal network.Quote:
Please correct me if I'm wrong.. because I've always stuck HTTP and SMTP servers in the DMZ... thats what the DMZ is there for... right?
This is always a security risk so keep your allowed ports to a minimum... only open what are necessary and nothing extra. This is what many soho router mfg's say about DMZ. "Use this feature on a temporary basis." It's not a long term solution imo. You're getting maximum compatibility for little to no protection against the outside WAN. Atleast with port-forwarding you can still be firewalled and using NAT to close the rest of the ports that would normally be "seen" on hosts that are in the DMZ. Putting a host running a webserver only or whatever in the DMZ just to allow the webservice is kind of pointless if you ask me since you're opening up the host completely and not just for that one specific service that needs to be provided. Do what you think is best I guess.
Note: As was mentioned earlier, you'll want to run a good software firewall on that individual host running the service in the DMZ. Since it won't have the router's firewall to protect it at the network-layer your only choice is a good application-layer software SPI firewall with some custom rules of your choosing. Imo it's best to have both a network-layer SPI firewall (like a router that has this support) as well as a good software SPI firewall. You get the best of both worlds as network-layer firewalls can only do so much.. where application-layer can do it all from data-link up to their application layer. The higher the layer up the "smarter" it will be and the more "customizable" it'll be.
Not if you put a correct accesslist on your DMZ. A DMZ on a PIX is not the same kind of DMZ as some of those DSL routers have.Quote:
Putting a host running a webserver only or whatever in the DMZ just to allow the webservice is kind of pointless if you ask me since you're opening up the host completely
It's a very bad idea to put your externaly accessable servers inside your LAN. Because you're punching holes in your firewall these servers could be exploited (they're accessable!). Imagine what happens if one of your mail or webservers gets 0wn3d. If these servers are inside your LAN the bad guys will have immidiate access to your internal network.
Put your mail, web and proxy servers inside a DMZ and put decent access lists on your PIX. Functionally you'll get a layout like this:
[Internet]<-->[firewall]<-->;[DMZ; web; mail; proxy]<---[firewall]<--[LAN]<--[servers; clients]
Now if someone hacks into your web or mailserver they'll run into the firewall when trying to access your LAN.
Your point basically is to isolate the host offering that specific service(s) to the outside WAN by means of DMZ so that if it becomes compromised more or less the hosts inside the LAN won't be affected. Usually true, however...Put decent ACL's on them? ACL's are only as good as the person's knowledge about network security when applied to an interface manually. Pre-applied ACL's, like those found in the soho router market, seem to do decent. If you're not a good ACL writer and/or don't have the time, knowledge, or patience to append entry after entry in the lists then this is not exactly a good path to pursue.Quote:
Put your mail, web and proxy servers inside a DMZ and put decent access lists on your PIX.
Applying ACL's means that you have to keep up with not only net security in general but the new breed of attacks and exploits that surface every other day. A host in the DMZ could be compromised and, being isolated properly, wouldn't affect the LAN. But, the host would still be compromised. Using your own custom ACL's will also degrade performance as there is more overhead than pre-applied ones. There's pros and cons to everything.
If a host on the LAN running a service that's using port-forwarding becomes compromised the hosts inside the LAN aren't ALWAYS able to be compromised. That's a generalization that is true in some cases but not always true. That depends on the situation and the level of access granted to the rest of the LAN by the attacker's successful exploitation of that specific port-forwarded service. BOF's are pretty much worthless unless the service/application being exploited is actually running as root. This is something that can be contained even if a host inside the LAN is compromised. It doesn't just stop there and read "Yeah, we're owned... our whole LAN is compromised now!" Hosts inside the LAN can be limited in what they're allowed to access etc. You could still use port-forwarding and semi-isolate a host running a service that could potentially be compromisable from the WAN.
IMO if you don't know how to put decent ACLs on a PIX you have no business in using it. Hire someone or get a third party involved that does know is my advice.Quote:
Put decent ACL's on them? ACL's are only as good as the person's knowledge about network security when applied to an interface manually. Pre-applied ACL's, like those found in the soho router market, seem to do decent. If you're not a good ACL writer and/or don't have the time, knowledge, or patience to append entry after entry in the lists then this is not exactly a good path to pursue.
You're either a security professional or not. I don't see the point. If you claim to be a security professional you're sopposed to be doing this anyway. Again hire someone or a third party that takes care of this if you don't have the time or knowledge.Quote:
Applying ACL's means that you have to keep up with not only net security in general but the new breed of attacks and exploits that surface every other day.
Correct. But you'll add another layer of difficulty for your attacker. It's all about security layers and containment.Quote:
A host in the DMZ could be compromised and, being isolated properly, wouldn't affect the LAN. But, the host would still be compromised.
A rule is a rule. It doesn't matter if it's pre-defined or not. They both take as much processing power as needed. But what do you think will happen to my performance if I remove 20 pre-defined rules and replace them by 5 custom ones? Also using pre-defined ones (there are none in a PIX; except the securitylevels) could also mean something is accessable that you don't want to be. I say write your own. That way you know exactly what's accessable and what not.Quote:
Using your own custom ACL's will also degrade performance as there is more overhead than pre-applied ones.
My experience is that this is true in most cases and only in some cases not (just the other way around).Quote:
If a host on the LAN running a service that's using port-forwarding becomes compromised the hosts inside the LAN aren't ALWAYS able to be compromised. That's a generalization that is true in some cases but not always true.
Not quite. Once they get access they could launch a local exploit to elevate their privileges, they could even include the local exploit in the payload of the BOF.Quote:
BOF's are pretty much worthless unless the service/application being exploited is actually running as root.
Yes but they usually aren't.Quote:
Hosts inside the LAN can be limited in what they're allowed to access etc.
Quote:
BOF's are pretty much worthless unless the service/application being exploited is actually running as root.
Yes, I said pretty much worthless but I meant generally speaking. Most novice shellcoders wouldn't bother with something like this. I could've taken privilege escalation into account but my point wasn't geared towards that possibility. If there was a vulnerability that was exploited remotely and a local vuln was also present on that machine and was exploitable, then yes, sure that could take place. Assuming you were able to exploit both of those hitting the right offsets for both vulns and assuming you took the time to construct a 1,000 Byte+ shellcode given you had the time and knowledge. I call this a "what if". Possible yes. Probable? Not all too likely to happen unless the attacker knew of something on the victim's box that he really needed or wanted and infact could pull these 2 off together without any error somewhere in between.Quote:
Not quite. Once they get access they could launch a local exploit to elevate their privileges, they could even include the local exploit in the payload of the BOF.
So far good information. It looks like the best thing would be to get my mail server and web servers in a DMZ. My problem with the PIX 506 is that it only has 1 ethernet port. I've checked with the documentation and a DMZ on this model is not possible. Am I missing something? Should I upgrade to a larger PIX or maybe put something like a SmoothWall in front to create the DMZ and have the PIX behind protecting my lan?
The thing is I'm not really trying to protect our assets against scriptkiddies or the odd worm. That's easy. All it takes is a bit of common sence and up2date and hardened systems to thwart them.
I'm trying to protect our assets against people that are determined to get in. Those are the ones that pose a real threat. Those are the ones that can really take you down. It may not be likely but we fear the one that succeeds. We could end up with a couple of huge headlines in the papers. That's bad for the company I work for (marketshares plummeting, customers leaving) and that in turn is bad for my job security ;)
The 506 is already marked end-of-sale/end-of-life so you'll need to get a new one anyway if you want support from Cisco. If you like the PIX (it's a good firewall anyway!) buy a bigger one but it doesn't hurt if you shop around abit. There are lots of other good alternatives.
Think about what you want or where you need it for. If you're going to buy a new one, think about the future too. You don't want to be stuck next year with an expensive firewall that doesn't have the features you need.