We have wide range of Public IP addresses, I tried to assign public ip directly to a server behined firewall( in DMZ), but I have been resisted.
Security guy told me is not correct to assign public ip to a server, it should have private ip for security reasons.
Is it true that NAT can provide more security?
Thanks,
Tarig Yassin Ahmed
No.
Your security person is probably confusing NAT with firewalling, as NAT devices will intrinsically do firewalling of various forms, sometimes stateful, sometimes not. Stateful firewalling _may_ provide more security in some situations for low bandwidth applications, at least before you're hit by a DoS attack; for high bandwidth applications, stateful firewalling is usually a complete waste of time.
Your security guy will probably say that a private IP address will give better protection because it's not reachable on the internet. But the reality is if you have 1:1 NAT to a server port, then you have reachability and his argument becomes substantially invalid. Most security problems are going to be related to poor coding anyway (XSS, improper data validation, etc), rather than port reachability, which is easy to fix.
Unfortunately, many security people from large organisations do not appreciate these arguments, but instead write their own and other peoples' opinions down and call them "policy". Changing policy can be difficult.
Nick
In fact our firewall is stateful.
This is why I thought, we no need to Nat at least our servers.
Tarig Yassin Ahmed
Tarig is sending email from the past. Spooky.
This setup will provide *less* security. Apart from the DoS scenario,
should your public facing server get compromised, you have given easy
access to your private infrastructure.
-Lorand Jakab
+1 on Nick's comment. If you're doing 1:1 NAT or port forwarding your server is still public facing.
If your firewall is merely stateful and not deep packet inspecting all it's doing is seeing is that the statefulness of the connection meets it's requirements. You could have that and still have all kinds of naughtiness going on.
Greg
Is it true that NAT can provide more security?
Thanks,
Tarig Yassin Ahmed
You are going to get different answers from different people. In and of
itself it doesn't provide security but it does place one more layer of
difficulty in getting at your internal machines. On the other hand, NAT
makes many things a lot more difficult than they need to be in many
cases and outright breaks some protocols (SCTP, for example).
On one hand, yes, it can make direct addressing of your servers more
difficult but doesn't guarantee anything. RFC1918 routes should not be
routed over the internet but sometimes people "leak" them and sometimes
people accept such leaked routes. So there is the possibility that
someone could "see" a route to your RFC1918 space. But on the other
hand, even if you did "leak" the route, the odds of someone being able
to reliably connect to your network is pretty low because if they are
accepting such leaked routes from you, they might be accepting them from
others, too. And your upstream's peers are probably filtering 1918
space and most likely route traffic destined to rfc1918 space they
aren't using to a black hole.
But your security person needs to shift their thinking because the
purpose of NAT and private addressing is to conserve IP address, not to
provide security. With IPv6, the concept of NAT goes away. You servers
will need public IP addresses if they are going to transact information
across the Internet. So the "security" concerns of public IP space are
moot when it comes to IPv6.
You have heard about NAT66, right?
Thanks,
Tell your security guy he should be looking for another job.
Oh, yeah. But NAT66 does not provide the "security" aspect of PAT with
V4. It is just a straight static NAT. So each of your machines is
still directly addressable from the Internet. With v4 PAT, you can not
be sure which address/port on the external IP maps to which address/port
on the inside IP at any given moment and PAT is stateful in that an
outbound packet is required to start the mapping. NAT66 is just
straight static NAT that maps one prefix to a different prefix.
Hi Tarig,
Yes NAT can provide more security, but not in the particular scenario
you described.
In your scenario, the firewall knows how to map incoming connections
for the public address to your server's private address, so you won't
see any benefit from NAT versus a merely stateful firewall -- a
connection request will either get through the filter or it won't. If
it gets through, the firewall knows where to send it. On the other
hand, the use of any kind of stateful firewall (most of what we refer
to as NAT firewalls keep per-connection state) increases your
vulnerability to denial of services attacks: folks DOSing you can
target both the server and the firewall's state table. So the use of
NAT there is potentially counterproductive.
In a client (rather than server) scenario, the picture is different.
Depending on the specific "NAT" technology in use, the firewall may be
incapable of selecting a target for unsolicited communications inbound
from the public Internet. In fact, it may be theoretically impossible
for it to do so. In those scenarios, the presence of NAT in the
equation makes a large class of direct attacks on the interior host
impractical, requiring the attacker to fall back on other methods like
attempting to breach the firewall itself or indirectly polluting the
responses to communication initiated by the internal host.
In both cases there's a larger question: security value. The value of
a security measure is the damage it prevents (risk times impact) minus
the damage it causes (system usability, capability). NAT generally
causes more damage than packet filters and other lighter-duty security
measures. Look for an appropriate improvement in system security to
counterbalance that damage. If you don't find it then don't use NAT.
Regards,
Bill Herrin
I'd eat a hat if a vendor didn't implement a PAT equivalent. It's demanded too much. There is money for it, so it will be there.
Jack
No.
However, some things like PCI compliance require NAT, likely because of
the "NAT = super hacker firewall" concept.
~Seth
If a public server behind a NAT gets whacked via a php vulnerability, you've
*still* given away access to everything behind the NAT that server can reach.
Note that the presence of a firewall with a 'default deny' rule for inbound
packets provides the same level of impracticality. And given the fact that
Windows has had a reasonably sane host-based firewall since XP SP2, and the
truly huge number of compromised PC's that sit behind a NAT on a DSL or
cablemodem, it's pretty obvious that the presence of NAT is doing approximately
*zero* to actually slow down the miscreants.
140 million compromised PC's, most of them behind a NAT, can't be wrong. 
I'd eat a hat if a vendor didn't implement a PAT equivalent. It's
demanded too much. There is money for it, so it will be there.Jack
Yeah, I think you are right. But in really thinking about it, I wonder
why. The whole point of PAT was address conservation. You don't need
that with v6. All you need to do with v6 is basically have what amounts
to a firewall in transparent mode in the line and doesn't let a packet
in (except where explicitly configure to) unless it is associated with a
packet that went out.
PAT makes little sense to me for v6, but I suspect you are correct. In
addition, we are putting the "fire suit" on each host in addition to the
firewall. Kernel firewall rules on each host for the *nix boxen.
And yet blaster type worms are less common now, and I still get the occasional reinfection reported where a computer shop installs XP pre-patch with a public IP. A simple stateful firewall or NAT router would stop that and allow them to finish patching the OS. There is always a new attack vector.
Jack
As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function. Given that the internal is exclusively PAT, the DMZ is public with stateful/proxy, this provides protection for the internal network while limiting the dmz exposure.
The argument everyone makes is that a stateful firewall defaults to deny. However, a single mistake prior to the deny allows traffic in. The only equivalent in a PAT scenario is to screw up port forwarding which would cause a single host to expose a single port unknowingly per mistake (which said port/host combo may not be vulnerable). In a stateful firewall, a screw up could expose all ports on a host or multiple hosts in a single mistake.
Then there are the firewall software bugs. In PAT, such bugs don't suddenly expose all your hosts behind the firewall for direct communication from the outside world. In v6 stateful firewall, such a bug could allow circumvention of the entire firewall ruleset and the hosts would be directly addressable from the outside.
PAT offers the smallest of security safeguards. However, many corp IT personnel feel more secure having that small safeguard in place along with the many other safeguards they deploy. In a corporate environment where they often love to break everything and anything, I don't blame them.
Then we go to the educational sector, where the admins often prefer as much openness as possible. In their case, they will prefer to do away with PAT.
Jack
And yet blaster type worms are less common now, and I still get the
occasional reinfection reported where a computer shop installs XP pre-patch
with a public IP. A simple stateful firewall or NAT router would stop that and
allow them to finish patching the OS. There is always a new attack vector.Jack
I'd argue that the above has everything to do with firewalling, and nothing to do with NAT.
Slightly OT: It boggles the mind a bit when I find desktop shops -not- using imaging. I would think most people would prefer not to stare at OS install screens - and when you can blast out a fully patched XP image easily in sub-10 minutes, the ROI is staggering.
Nathan
But that's not true. If you have NAT, without a firewall, I can
access your internal hosts (by addressing their RFC 1918 address)
because you'll be leaking your RFC 1918 addresses in and out.
Granted, I might have to be in your immediate upstream, but it can be
done.
So at best, all it does is limit how many hops away I need to be from
you to attack you.
Some benefit? Yes. Enough benefit to be worth the trouble? I
personally am not convinced.
Considering the amount of people who mistake the amount of security
NAT provides, we're probably better off without it to remove that
false sense of security.