Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I've signed on to help a department move buildings and upgrade their dated infrastructure. This department has about 40 employees, 25 desktops, an old Novell server, and a handful of laboratory processing machines with attached systems. At the old location, this department had two networks - a LAN with no outside access whatsoever on an entirely separate switch, and a few machines with outside access.

We are trying to modernize this setup a bit as pretty much every user needs to access email and the time tracking system.

The parent organization (~10k employees) has a large IT department that is in charge of the connection and phone system at the new offsite location. The IT dept. had uverse dropped in and setup a VPN to their central network. Each desktop needs to be registered in the IT dept's system/website to get a (static) IP Address. Each IP Address given is outside accessible on any port that has a service listening on the client machine.

The server has confidential (HIPPA) data on it, the desktops have mapped network drives to access (some) of this data. There is also a client/server LIS in place.

My question is this: Is it worth making a stink that all of these machines are outside accessible?

Should we:

  • Request NAT to abstract the outside from the inside, as well as a firewall that blocks all traffic not explicitly defined as allowed? If so, what argument's can I make for NAT/firewall that outweigh the benefits of them having each machine registered in their system? I would be relaying all IT related requests from the end users to the IT department in either case - so it doesn't seem very necessary to have them tied down to specific addresses in their system. Most importantly, it sounds like a nightmare to manage separate firewalls on every desktop (varying platforms/generations) and on the server.
  • Request the IT dept. block all incoming traffic to each wan accessible IP on whatever existing firewalls they have in place
  • Keep the departments LAN completely isolated from the internet. Users must share dedicated machines for accessing email, internet, and time tracking system.

Thanks in advance for any comments or advice on this.

share|improve this question

migrated from serverfault.com Nov 9 '11 at 3:40

This question came from our site for professional system and network administrators.

This is a good question that people usually get confused on. I personally like NAT just for organizational purposes, not so much security. If you look at IPv6, there really is no NAT. You just need to set the default to deny on the firewall and go from there. –  Matt Nov 9 '11 at 8:37

6 Answers 6

up vote 20 down vote accepted

NAT and firewalling are completely orthogonal concepts that have nothing to do with each other. Because some NAT implementations accidentally provide some firewalling, there is a persistent myth that NAT provides security. It provides no security whatsoever. None. Zero.

For example, a perfectly reasonable NAT implementation might, if it only had one client, forward all inbound TCP and UDP packets to that one client. The net effect would be precisely the same as if the client had the outside address of the NAT device.

Don't think that because most NAT devices have some firewalling built in by design or do some by accident that this means NAT itself provides any security. It is the firewalling that provides the security, not the NAT. The purpose of NAT is to make things work.

You must not assume a machine is not outside accessible just because it's behind a NAT device. It's not outside accessible if some device is specifically configured not to permit it to be accessed from the outside, whether that device does NAT or not.

Every machine having an outside address but with a stateful firewall that's properly configured, managed, and monitored is vastly superior to a cheap SoHo NAT box.

Many actual SoHo NAT boxes forward traffic to inside hosts despite no inside host having ever sent traffic to the source of the forwarded traffic. Permissive NAT does really exist.

share|improve this answer
@DavidSchwarts "You must not assume a machine is not outside accessible just becausse it's behind a NAT device." yet sysadmin1148 says in his linked answer "The one big security gain you get with NAT is that it forces you into a default-deny configuration. In order to get any service through it, you have to explicitly punch holes." So is it safe to assume, unless I punch a hole in the default NAT configuration enabling the exact thing I want to prevent, NAT does provide some measure of security? –  iainlbc Nov 9 '11 at 4:03
@iainlbc: If by "NAT" you mean "NAT itself", then no. NAT provides no security at all. Again, read the second paragraph of my answer. If by "NAT" you mean a box that provides NAT and also some firewalling, then yes. Firewalls provide security. The bit about "default deny" is technically true, but meaningless. Everything provides default deny in this silly, vacuous sense since it is shipped to you unplugged. –  David Schwartz Nov 9 '11 at 4:16
@iainlbc: I'll hit port 1433 on the NAT box's public IP address, and it will forward it to the SQL server (since the SQL server is its only client, it knows that must be the intended recipient). If not, it's because it's also a firewall, in which case it will filter/drop it. But that's not because of NAT, that's because of its firewall that rejects inbound packets that don't match an existing reflexive rule even though it could NAT them. In other words, because it's also a firewall, it provides some security. A plain firewall that dropped the traffic would provide the same security - right? –  David Schwartz Nov 9 '11 at 5:11
The purpose of NAT is to make machines "just work" even if there are insufficient public IP addresses for them. As an accident of the way NAT is typically implemented, NAT boxes tend to also implement some firewalling. But a firewall would do the same thing and provide the same benefits. The NAT is superfluous to the security. If you disabled the NAT but kept the reflexive, stateful firewall, you'd get the same security. And a NAT box without a reflextive, stateful firewall would provide no security at all. (And there are definitely some 'permissive' NAT devices that provide very little!) –  David Schwartz Nov 9 '11 at 5:14
@symcbean: That's like arguing that a router is secure unless you plug it in. It's pure sophistry. The point is, you can have NAT (private IP addresses, Internet access) but basically no security whatsoever (if, for example, the NAT is permissive). –  David Schwartz Nov 10 '11 at 15:33

Having just spent 7 years at a University with a /16 netblock and put everything on that netblock that wasn't specifically prohibited to be on such (PCI-DSS used to require this, until they fixed it), I have some experience with networks of this nature.

NAT is not required. All NAT does is make it a bit harder to reconnoiter a network, and forces an entity into a more-secure-by-default posture. That said, it is perfectly possible to build a secure network on public IP addresses. There were a couple of subnets that we had that were technically routeable, but nothing outside the perimeter firewall could get there.

Now for your other points:

Request the IT dept. block all incoming traffic to each wan accessible IP on whatever existing firewalls they have in place

This should be done by default. In my old University, the Student Computer Lab stations had no need to be addressable from the Internet and they weren't. The same went for the subnets that held the Student Health Center data. If a machine needed to be externally visible for some reason, there was an electronic document that had to be passed around and signed before it could be granted; even for servers in the centralized IT stack.

Keep the departments LAN completely isolated from the internet. Users must share dedicated machines for accessing email, internet, and time tracking system.

You don't have to go this far. The reason to go this far is if your fear of malware-related information-exposure is higher than the need for connectivity to network-based resources. Things are increasingly cloud/network based these days, so such air-gapped networks are getting harder and harder to maintain. If you truly do need to go to this extent, you may want to look into some of the Application Virtualization options out there, as that can limit the exposure of breaches should they occur.

share|improve this answer
Exactly. I manage a network that uses publicly routable addresses and it's no less secure because of the lack of NAT. It's the firewall that provides the security, not the NAT. –  joeqwerty Nov 9 '11 at 4:01
Thanks to both of you, reading through all of this now. Extremely glad I asked the experts instead of exposing to the IT dept how ill informed I am on the topic... –  iainlbc Nov 9 '11 at 4:04
The org. is allowing traffic on all ports to these addresses based on my rudimentary testing (RDP, SSH, FTP, SQL, 80) , and has been the culture for some time now. I much prefer explicitly filling out firewall request forms. In fact if this was in place I probably wouldn't even have considered NAT or posting this, It just feels like the configuration is lacking something. It's clear now that its firewall rules - not NAT. –  iainlbc Nov 9 '11 at 4:11
"Having just spent 7 years at a University with a /16 netblock and put everything on that netblock that wasn't specifically prohibited to be on such (PCI-DSS used to require this, until they fixed it), I have some experience with networks of this nature.", I'm so, so sorry. –  StrangeWill Dec 14 '11 at 19:14

Even though I know a bit about NATs and port forwardings I disagree most of what David Schwartz wrote. It might be because he was a bit unpolite Read the second paragraph of my answer.

NAT is not the answer to everything. It just makes it difficult for external parties to connect to your services. Most NAT implementations do conversion port-by-port basis and if the host in incoming packet is not recognized there will be no NAT rules to follow, therefore denied connection. This still leaves some holes with the server client just connected to connecting back.

More important is to secure yourself from inside connections as well as outside connections. NAT provides false security in this way. You only need one bug from an USB stick and there could be connection forwarding letting everyone in.

Regardless of your IP space you should limit connections to those allowed. Workstations usually should be not allowed to connect to SQL service. I personally do not like stateful firewalls but each to his own. I'm more the router type kind of guy drop all packets.

share|improve this answer
Of course it isn't an answer to everything - especially not security, as it's not a security layer (and if so, it's somewhat accidental). I agree with you that a good firewall with proper rules is necessary, NAT or no NAT. (I don't think you're actually in disagreement with that other answer :)) –  Piskvor Nov 9 '11 at 14:20

As others have pointed out, NAT is not a security feature. However, it does offer some level of security as a byproduct: a side-effect of NAT is that none of the inner machine is accessible "from the outside". The same effect can be achieved by a firewall which blocks all incoming connections. This is not fine-grained, but rather effective in practice, and if NAT did not come with that "automatic" protection, a lot more existing networks would be attacked and zombified into spam relays (that's the scary point about IPv6, by the way: IPv6, when [if] widely deployed, will have a tendency of nullifying the protection effect of NAT, and one can expect an average increase of attack success).

Now having a well-configured firewall assumes that whoever configures the firewall does his job correctly, and, unfortunately, that's not a given (I do not want to presume on the abilities of your specific IT department, but the average quality of the work of IT departments around the World, especially in large organization, is less than thrilling). The alternative being to ensure that every single machine which is publicly accessible should resist all kinds of attacks related to incoming connections: close all unneeded services, make sure that the services which remain open are properly up-to-date and well configured. Fancy applying security updates on every single workstation ? And on the firmware of network-able printers ?

My advice would be to install your own filter box, through which all communications between your network and the outside world will go. That box should then filter out incoming connections; NAT and/or firewall, that's your call. NAT may be easier, especially if the IT department is "uncooperative".

share|improve this answer

NAT is not important as a security layer and shouldn't be thought of as providing any security (even when it inadvertently makes it more secure).

I don't know HIPPA compliance, but PCI compliance requires very specific setups for computers having access to credit card information. You should design around first meeting the HIPPA requirements and then design additional security measures. The joke of PCI compliance being that compliance reduces the risk of fines, but not necessarily reducing the risk of security exploits.

HIPPA rules might inform you of how you have to treat the computers that have access to HIPPA data.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.