I'm setting up a IIS, TS, and Exchange Server. What are the pros and cons of placing that server into a DMZ? I'm a lil lost, please help me find my way home, thx 
why would I want to place my server in a DMZ?
- Thread starter PeeluckyDuckee
- Start date
so all the ports on that server would basically be opened to anybody from the outside...that's not good.
<< You would want to use the dmz if you have too many ports that need to be forwarded otherwise, for security reasons, it's not a good idea to use it. >>
I beg to differ. I can't think on any serious network that isn't setup in a DMZ configuration. There are lots of reasons to use it: security, managability, security (yes I said it twice, its that important), etc. It all depends on how you want your network set up and where you are going to focus your services.
Scottmac and Spidey, help me out here...
Ok, I am going to assume you mean a DMZ as far as networks and not the SOHO linksys router DMZ stuff. They are kinda different, unfortunately.
For a real DMZ keeping the servers seperate is important. You can more easily restrict inbound and outbound traffic to *ONLY* the services you offer. ie, for a DNS server allow *UDP* 53 in and out. TCP 53 can be allowed in and out to SPECIFIC hosts and no more. Its usually not necessary for someone on the net to do tcp dns lookups so why keep it open. The only ports that should be allowed to web servers are 80 and 443. 443 should be turned off unless you need ssl encryption. With ssl, someone can perform encrypted attacks on your webserver, which is bad for IDS systems. Those ports should be the only ones allowed to the web server and from the webserver. There is most likely no reason for the webserver to be sending mail, so why allow it that port out?
For a real DMZ keeping the servers seperate is important. You can more easily restrict inbound and outbound traffic to *ONLY* the services you offer. ie, for a DNS server allow *UDP* 53 in and out. TCP 53 can be allowed in and out to SPECIFIC hosts and no more. Its usually not necessary for someone on the net to do tcp dns lookups so why keep it open. The only ports that should be allowed to web servers are 80 and 443. 443 should be turned off unless you need ssl encryption. With ssl, someone can perform encrypted attacks on your webserver, which is bad for IDS systems. Those ports should be the only ones allowed to the web server and from the webserver. There is most likely no reason for the webserver to be sending mail, so why allow it that port out?
ivwshane
Lifer
- May 15, 2000
- 33,214
- 16,504
- 136
Sorry I was thinking of a home setup not a true corprate type network. With that being said there are lots of good reasons to set one up. Keeping it seprate from your internal network in of itself is a good security measure. I would definitly put the IIS server there (as long as it's for external use). As for the exchange and Terminal service servers go, I'd probably leave them internally (since I'm assuming it will be for the internal network) but some might differ. Other advantages are the ones stated by n0cmonkey.
And please disregard my first reply because it only relates to home networks.
And please disregard my first reply because it only relates to home networks.
To expand on the answers given so far, I'll hop in here. You put machines in the DMZ that must be accessible to the outside world. Since these machines must accept some type of connection initiated from the outside, you want to put them in a position where a vulnerability discovered for whatever service you are running doesn't cause a loss of the entire network. Once a machine is placed in the DMZ, you tightly control who is allowed access, and only allow traffic on the ports needed for that server to function.
For example, say you have an Apache server running, and a remote root vulnerability is discovered. If you don't find out about it the same day as attackers do, they might successfully attack and compromise that server. You must allow port 80 traffic to the server, because that's the server's job. If your server is in the DMZ, can take over the machine, but they cannot use that machine as a path to attack other machines in your internal network (since you should have extremely tight restrictions on what DMZ machines can access the internal network - usually no DMZ to internal network traffic is permitted at all). If that server was on the internal network instead, once they got control of the machine the attackers would have unlimited access to all machines on the internal network. You wouldn't be able to ferret them out by the time you got to work the next morning.
The downside to putting a machine on a DMZ is that you must physically access the machine to work on it, if you are following widely accepted firewalling standards. I don't see this as a disadvantage, but many do.
Now, if you have a home/SOHO "router" (SMC/Linksys/whatever), you don't have the controls that a standard firewall and router setup would give you. All home/SOHO routers with which I am familiar define the DMZ as the port where all externally initiated traffic goes if there isn't a rule already in place directing it to another machine, or something close to those lines. The problem with this is that you must make all ports on a server accessible when you hook it up to the DMZ port. Furthermore, most home/SOHO routers that do this don't actually stop that machine from accessing the internal network, so you really don't get any protection by using that port.
Hope that is clear and helps, but I had trouble writing it where I felt it was understandable, so I may have made things cloudier or left something out. Let me know if you have any more questions.
RagManX
For example, say you have an Apache server running, and a remote root vulnerability is discovered. If you don't find out about it the same day as attackers do, they might successfully attack and compromise that server. You must allow port 80 traffic to the server, because that's the server's job. If your server is in the DMZ, can take over the machine, but they cannot use that machine as a path to attack other machines in your internal network (since you should have extremely tight restrictions on what DMZ machines can access the internal network - usually no DMZ to internal network traffic is permitted at all). If that server was on the internal network instead, once they got control of the machine the attackers would have unlimited access to all machines on the internal network. You wouldn't be able to ferret them out by the time you got to work the next morning.
The downside to putting a machine on a DMZ is that you must physically access the machine to work on it, if you are following widely accepted firewalling standards. I don't see this as a disadvantage, but many do.
Now, if you have a home/SOHO "router" (SMC/Linksys/whatever), you don't have the controls that a standard firewall and router setup would give you. All home/SOHO routers with which I am familiar define the DMZ as the port where all externally initiated traffic goes if there isn't a rule already in place directing it to another machine, or something close to those lines. The problem with this is that you must make all ports on a server accessible when you hook it up to the DMZ port. Furthermore, most home/SOHO routers that do this don't actually stop that machine from accessing the internal network, so you really don't get any protection by using that port.
Hope that is clear and helps, but I had trouble writing it where I felt it was understandable, so I may have made things cloudier or left something out. Let me know if you have any more questions.
RagManX
ragmanX really drove it home there.
http://whatis.techtarget.com/definition/0,,sid9_gci213891,00.html
http://whatis.techtarget.com/definition/0,,sid9_gci213891,00.html
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 19K
-
-
-
Facebook
Twitter