Robing66066
asked on
Is NAT between the Internal network and the DMZ useful as a security measure?
We're having a bit of a debate here regarding network security. What we currently have is this
Internal --> DMZ
Internal --> Internet
DMZ --> Internet
We're doing NAT between the Internal network and the Internet. That's fairly straightforward and no one disputes there is value there.
The question is whether there is value doing NAT between the Internal network and the DMZ. And if so, is that value enough to compensate for what NAT breaks (like end-to-end connectivity and easy IPSEC setups...)
I'd love to hear from folks who are doing one or the other and why.
Thanks.
Internal --> DMZ
Internal --> Internet
DMZ --> Internet
We're doing NAT between the Internal network and the Internet. That's fairly straightforward and no one disputes there is value there.
The question is whether there is value doing NAT between the Internal network and the DMZ. And if so, is that value enough to compensate for what NAT breaks (like end-to-end connectivity and easy IPSEC setups...)
I'd love to hear from folks who are doing one or the other and why.
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi guys. Nice to see one person on each side of the argument.
I tend to agree with you Davor. I wish you could find that article.
The truth (at least as I see it) is that when you use NAT between the inside and the DMZ, you lose the ability to confirm an end-to-end communication. Doing that means that you can't positively identify the source of packets to a service. All you know is that they are supposed to come from the NAT outside address. It could be anyone on the inside sending. That opens you up for a spoofed attack to any service that is stateless. (like a web server, for instance...)
Ed, I hear what you are saying, but if you have an ACL between the inside and DMZ (which you should, of course), then the attacker would have no more ability to scan the inside than with NAT. (I would put an ACL in either case.)
I guess I'm thinking about what would happen if I were to get into a DMZ where the inside network was NAT'ted and comparing to a DMZ with no NAT.
NAT'ted
1. Scan all available addresses.
results: All the NATted IP's allowed by the ACL would return their open ports. ACL blocks the rest.
2. Attack those ports looking for vulnerabilities.
results: Find a vulnerability.
3. Send exploit / Compromise machine.
results: I'm in the inside, I now scan the entire inside.
Not NAT'ted.
1. Scan all available addresses.
results: All the IP's allowed by the ACL would return their open ports. ACL blocks the rest.
2. Attack those ports looking for vulnerabilities.
results: Find a vulnerability.
3. Send exploit / Compromise machine.
results: I'm in the inside, I now scan the entire inside.
No real difference. (That I can see).
Did I miss it? It seems like this is the case, but I have to admit that there's not a lot of talk about this out there...
I tend to agree with you Davor. I wish you could find that article.
The truth (at least as I see it) is that when you use NAT between the inside and the DMZ, you lose the ability to confirm an end-to-end communication. Doing that means that you can't positively identify the source of packets to a service. All you know is that they are supposed to come from the NAT outside address. It could be anyone on the inside sending. That opens you up for a spoofed attack to any service that is stateless. (like a web server, for instance...)
Ed, I hear what you are saying, but if you have an ACL between the inside and DMZ (which you should, of course), then the attacker would have no more ability to scan the inside than with NAT. (I would put an ACL in either case.)
I guess I'm thinking about what would happen if I were to get into a DMZ where the inside network was NAT'ted and comparing to a DMZ with no NAT.
NAT'ted
1. Scan all available addresses.
results: All the NATted IP's allowed by the ACL would return their open ports. ACL blocks the rest.
2. Attack those ports looking for vulnerabilities.
results: Find a vulnerability.
3. Send exploit / Compromise machine.
results: I'm in the inside, I now scan the entire inside.
Not NAT'ted.
1. Scan all available addresses.
results: All the IP's allowed by the ACL would return their open ports. ACL blocks the rest.
2. Attack those ports looking for vulnerabilities.
results: Find a vulnerability.
3. Send exploit / Compromise machine.
results: I'm in the inside, I now scan the entire inside.
No real difference. (That I can see).
Did I miss it? It seems like this is the case, but I have to admit that there's not a lot of talk about this out there...
I wasn't saying use NAT instead of firewall is it can be circumnavigated.
It is certainly not as good as firewall technology.
I was saying to use both. Then if someone does bypass the firewall they still have limited access.
To secure your house you use a wall AND a front door.
It is certainly not as good as firewall technology.
I was saying to use both. Then if someone does bypass the firewall they still have limited access.
To secure your house you use a wall AND a front door.
ASKER
Hi Ed. Thanks for replying again.:
I understood what you meant, but since NAT breaks end-to-end communication, I think using both NAT and an ACL actually makes you less secure, not more. Here is why I think so:
Because you can't see any internal addresses, you can now no longer secure your servers in the DMZ by source ip address. So, for example, if you have a web server that has a control port on 8080, you would obviously not open that port to the Internet side, but for internal workstations you would want to open it up to a management workstation on the inside. So it would look like this:
Management PC (internal network) --> (8080) Web Server (80) --> Outside customer (Internet).
In this scenario, your outside customers can reach your web server on port 80, but not on the control channel of 8080. You, on the internal network can reach the control port of 8080, allowing you to manage the device. It could just as easily be a port that's been opened to allow your server to talk to an internal database or application server of some kind. In any event, it would be a port that is opened where you want to have your DMZ server talk to an internal box and vice versa. A common solution.
But, for additional security, it would be nice if your web server discriminated port 8080 by source ip address, so only *your* workstation could be used to manage it and not just anyone on the internal network.
In the NAT scenario, all the internal traffic would appear to come from the NAT address, so from the DMZ servers perspective he has no way of knowing who on the inside was trying to talk to him. It would all look like the 1 NAT ip address. So, if you put an ACL on the server that lists the NAT address, you don't accomplish anything with respect to ensuring that you're talking to the right person on the inside. This leaves you open to attacks against services that are stateless (such as a web server could be.)
Based on that, you couldn't put the ACL right on the server (where it belongs - closest to the source of the device you want to secure). You'd have to put it on the ACL of the firewall. That works great for protecting port 8080 from your internal folks, but if the hacker you speak of gets into the DMZ, he can attack port 8080 all he likes because he doesn't go through the ACL on the NAT firewall, he's connected directly via a box in the DMZ. That would be true of all the servers in the DMZ, leaving you unable to secure backchannel ports to your internal network by source IP address, making you more vulnerable to a hacker in the DMZ, not less.
Does that track? I think it does and that's the current argument over here as to why not to do NAT.
BTW, points for this question are being awarded based on participation, not correct answer or agreement with me.
Thanks.
I understood what you meant, but since NAT breaks end-to-end communication, I think using both NAT and an ACL actually makes you less secure, not more. Here is why I think so:
Because you can't see any internal addresses, you can now no longer secure your servers in the DMZ by source ip address. So, for example, if you have a web server that has a control port on 8080, you would obviously not open that port to the Internet side, but for internal workstations you would want to open it up to a management workstation on the inside. So it would look like this:
Management PC (internal network) --> (8080) Web Server (80) --> Outside customer (Internet).
In this scenario, your outside customers can reach your web server on port 80, but not on the control channel of 8080. You, on the internal network can reach the control port of 8080, allowing you to manage the device. It could just as easily be a port that's been opened to allow your server to talk to an internal database or application server of some kind. In any event, it would be a port that is opened where you want to have your DMZ server talk to an internal box and vice versa. A common solution.
But, for additional security, it would be nice if your web server discriminated port 8080 by source ip address, so only *your* workstation could be used to manage it and not just anyone on the internal network.
In the NAT scenario, all the internal traffic would appear to come from the NAT address, so from the DMZ servers perspective he has no way of knowing who on the inside was trying to talk to him. It would all look like the 1 NAT ip address. So, if you put an ACL on the server that lists the NAT address, you don't accomplish anything with respect to ensuring that you're talking to the right person on the inside. This leaves you open to attacks against services that are stateless (such as a web server could be.)
Based on that, you couldn't put the ACL right on the server (where it belongs - closest to the source of the device you want to secure). You'd have to put it on the ACL of the firewall. That works great for protecting port 8080 from your internal folks, but if the hacker you speak of gets into the DMZ, he can attack port 8080 all he likes because he doesn't go through the ACL on the NAT firewall, he's connected directly via a box in the DMZ. That would be true of all the servers in the DMZ, leaving you unable to secure backchannel ports to your internal network by source IP address, making you more vulnerable to a hacker in the DMZ, not less.
Does that track? I think it does and that's the current argument over here as to why not to do NAT.
BTW, points for this question are being awarded based on participation, not correct answer or agreement with me.
Thanks.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi Ed. Good reply.
I'd have to disagree with you on your first point. To the best of my knowledge, there's no way to find out what the real address of a machine is if it has been NATted. (Unless you have access to the xlate table on the firewall/router doing the NATting, of course). So I'm not sure that you could ever restrict by IP address in a NAT environment. If you know of a way, please post a link. I've looked and can't find one. As far as I can tell, the packet is changed in both the source MAC and IP to match the NAT address and the only trace left behind is the translation table on the NAT device.
You are right that it is easy to fake an address so that you can pretend to be the restricted address. Despite that, I think that there's real value in restricting that list. Consider this:
Imagine you have several servers in your DMZ. A mail server, 3 web servers, a Citrix Server and FTP server. Each with an inward connection as well as an outward connection.
Now, a hacker gains access to one of the web servers. He has complete control. What's the first thing he'll do? Well, most likely install a packet sniffer, an exploit tool (like MetaSploit) and a port scanner.
If you've set up your switch properly, all he'll get from the sniffer is broadcast traffic (plus any traffic destined for that web server...). From that he learns the local IP address scheme plus the IP addresses of other servers in the DMZ. Of course, he also learns that you are NATting from the inside (many connections, all from the same IP but with different sequence numbers gives you that information.)
So, now he turns to the port scanner and scans all internal addresses. There are two lists of devices he'll get from that. The first are any servers on the inside that you've set up reverse NAT (conduits) for. So, if you have an internal mail server that allows mail to come in from your DMZ relay, he'll pick that up on whatever NAT address you've set up for it. Same thing goes with the Citrix server. He'll not get the true IP address, but he'll not care - the reverse NAT gives him the same access anyway. He'll immediately go to work with his exploit tool on these devices.
The second list are the internal DMZ servers open ports. If you've not restricted who can use the internal ports on each of your DMZ servers, then the port scanner will pick up the control ports on each DMZ box.
If, on the other hand, you have limited which IP addresses can access those ports, then the port scanner won't pick up any of them. He's scanning from a denied IP address. Since he doesn't have access to those boxes, and all he's seeing on the sniffer is broadcast traffic, he'll not know what IP addresses on the inside do have permission to see those ports. He's fairly well shut down.
Now, you could restrict those servers based on the NAT IP, but since he knows you're doing NAT, and, as you point out, it's easy to spoof an address, after he finds no open ports on the other DMZ boxes, he'll likely try spoofing the NAT address to see if that gets him anywhere. (I know I would...) If you've NAT'ted, then your in trouble here. He now appears to be coming from a trusted network.
I admit, this is a very targeted scenario. This would not be a casual attack. This would be someone who has skill and motivation to perform this sort of an attack. But, if you are concerned about this sort of scenario (which I am), then I'm not sure you can avoid this issue using NAT.
Thoughts?
I'd have to disagree with you on your first point. To the best of my knowledge, there's no way to find out what the real address of a machine is if it has been NATted. (Unless you have access to the xlate table on the firewall/router doing the NATting, of course). So I'm not sure that you could ever restrict by IP address in a NAT environment. If you know of a way, please post a link. I've looked and can't find one. As far as I can tell, the packet is changed in both the source MAC and IP to match the NAT address and the only trace left behind is the translation table on the NAT device.
You are right that it is easy to fake an address so that you can pretend to be the restricted address. Despite that, I think that there's real value in restricting that list. Consider this:
Imagine you have several servers in your DMZ. A mail server, 3 web servers, a Citrix Server and FTP server. Each with an inward connection as well as an outward connection.
Now, a hacker gains access to one of the web servers. He has complete control. What's the first thing he'll do? Well, most likely install a packet sniffer, an exploit tool (like MetaSploit) and a port scanner.
If you've set up your switch properly, all he'll get from the sniffer is broadcast traffic (plus any traffic destined for that web server...). From that he learns the local IP address scheme plus the IP addresses of other servers in the DMZ. Of course, he also learns that you are NATting from the inside (many connections, all from the same IP but with different sequence numbers gives you that information.)
So, now he turns to the port scanner and scans all internal addresses. There are two lists of devices he'll get from that. The first are any servers on the inside that you've set up reverse NAT (conduits) for. So, if you have an internal mail server that allows mail to come in from your DMZ relay, he'll pick that up on whatever NAT address you've set up for it. Same thing goes with the Citrix server. He'll not get the true IP address, but he'll not care - the reverse NAT gives him the same access anyway. He'll immediately go to work with his exploit tool on these devices.
The second list are the internal DMZ servers open ports. If you've not restricted who can use the internal ports on each of your DMZ servers, then the port scanner will pick up the control ports on each DMZ box.
If, on the other hand, you have limited which IP addresses can access those ports, then the port scanner won't pick up any of them. He's scanning from a denied IP address. Since he doesn't have access to those boxes, and all he's seeing on the sniffer is broadcast traffic, he'll not know what IP addresses on the inside do have permission to see those ports. He's fairly well shut down.
Now, you could restrict those servers based on the NAT IP, but since he knows you're doing NAT, and, as you point out, it's easy to spoof an address, after he finds no open ports on the other DMZ boxes, he'll likely try spoofing the NAT address to see if that gets him anywhere. (I know I would...) If you've NAT'ted, then your in trouble here. He now appears to be coming from a trusted network.
I admit, this is a very targeted scenario. This would not be a casual attack. This would be someone who has skill and motivation to perform this sort of an attack. But, if you are concerned about this sort of scenario (which I am), then I'm not sure you can avoid this issue using NAT.
Thoughts?
ASKER
I'm going to award even points here. Davorin's answer is, I believe, the correct one, but Ed certainly put in a good effort to defend his view.
Thanks folks.
Thanks folks.
I have a debt with you - I have found that article, but it is not in english, so there is no point of posting it.
You have acctualy answered to yourself that with NAT you have more disadvantages then advantages. You should deploy security measures at every part of the network to be as safe as possible and NAT brings you problems.
The article I have mentioned was written by person who does part of IPv6 implementation iniciative.
As the transition to IPv6 is going slowly, there are some alternatives (CGN large scale NAT) that would prolong IPv4 slow dying. Here are three links that are mentioned in artice. They are not only (directly) talking about NAT security, but more about NAT drawbacks.
http://msmvps.com/blogs/alunj/archive/2007/12/29/1425918.aspx
http://www.cs.utk.edu/~moore/what-nats-break.html
http://tools.ietf.org/html/draft-ymbk-aplusp-05#section-1.1
I hope I have not gone too far from the question point.
From security point of view it would be better to move toward level 7 deep packet (payload) inspection.
Thx for points.
You have acctualy answered to yourself that with NAT you have more disadvantages then advantages. You should deploy security measures at every part of the network to be as safe as possible and NAT brings you problems.
The article I have mentioned was written by person who does part of IPv6 implementation iniciative.
As the transition to IPv6 is going slowly, there are some alternatives (CGN large scale NAT) that would prolong IPv4 slow dying. Here are three links that are mentioned in artice. They are not only (directly) talking about NAT security, but more about NAT drawbacks.
http://msmvps.com/blogs/alunj/archive/2007/12/29/1425918.aspx
http://www.cs.utk.edu/~moore/what-nats-break.html
http://tools.ietf.org/html/draft-ymbk-aplusp-05#section-1.1
I hope I have not gone too far from the question point.
From security point of view it would be better to move toward level 7 deep packet (payload) inspection.
Thx for points.
ASKER
Excellent! Thanks!!
If someone takes over control of a DMZ machine - maybe a security issue allows them to get control of a web server or Name server out in that network, do you want them to have the power to scan pcs on your internal network.
I would say a NAT and a Firewall are needed. The firewall - 100%. You should not have a public DMZ without firewalling it from your internal network (and the other way too). The NAT is less important but helps.
So I say yes - do it