I don't want to start a flame war, but this article seems flawed to
me. It seems an IP is an IP.
I think I could announce private IP space, so doesn't that make this
argument invalid? I've always looked at private IP space as more of a
resource and management choice and not a security feature.
On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis@packetnexus.com> wrote;
I don't want to start a flame war, but this article seems flawed to
me.
Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is
DEFINITELY 'flawed'.
It seems an IP is an IP.
True. *BUT*, "some IP's are more equal than others", as Orwell would say.
I think I could announce private IP space, so doesn't that make this
argument invalid?
You likely would have a 'rude surprise' if you actually tried it.
It is an express violation of RFCs to announce routing for RFC-1918 space
-outside- of your own network.
In addition, virtually _every_ ASN operator has ingress filters on their
border routers to block almost all traffic to RFC-1918 destinations.
"Good net neighbor" operators also run egress filters that block almost all
outbound traffic with RFC-1918 _source_ addresses -- things like icmp 'un-
reachables' are an exception.
I don't want to start a flame war, but this article seems flawed to me.
The real issue is interconnecting SCADA systems to publicly-routed networks, not the choice of potentially routable space vs. RFC1918 space for SCADA networks, per se. If I've an RFC1918-addressed SCADA network which is interconnected to a publicly-routed- and -accessible network, then an attacker can work to compromise a host on the publicly-accessible network and then jump from there to the RFC1918 SCADA network.
I think I could announce private IP space, so doesn't that make this argument invalid?
Most networks, except those which haven't implemented the most basic BCPs, wouldn't accept your announcements of RFC1918 or otherwise-reserved space. It's likely that your peers/upstreams wouldn't accept them in the first place, much less propagate them.
I don't want to start a flame war,
If you didn't write it I wouldn't stress about that.
but this article seems flawed to
me.
Me too.
It seems an IP is an IP.
Yes but in IPv4 land there is a difference although probably not in
the way the author "suggests".
The non-routability of the private address space is dependent on the
good sense of router manufacturers and although these days that's
probably guaranteed the impression I get is some dumb SCADA network
guy is expected to go "oh, private address, intrinsically secure" or
"oh, public address, intrinsically insecure, hmm, all my edge devices
are owned and beyond help".
Hehe.
I think I could announce private IP space,
Exactly but it would never get legs.
so doesn't that make this
argument invalid?
I think there are much better reasons why the article is invalid and
ultimately irrelevant and weird.
I know this is contentious so I'll clarify it ...
NAT is not a security feature.
Any perceived benefit is from the state table ... which any packet
filter can duplicate.
NATting is not the issue but the allow/deny situation based on the state table.
More importantly though, other than DOS (presuming less bandwidth
inside than out) or attacks on a host's TCP/IP stack (maybe SCADA
suffers here), what's important is services hanging on ports and any
vulnerabilities they have - which, by design are passed whether you
NAT or not (we want people to talk to our web server).
Has any one ever been cracked on their web browser or email client or
whatever by something that was preventable at the lower layers with a
default deny all in rule ...
Never.
The only issue for clients in that respect is spoofing and so on ...
which NAT passes as well as (or more openly than) any packet filter
...
Any good packet filter can help there but that's strictly a packet
filtering feature and nothing to do with NAT.
By definition alone, NAT is useless here.
Some of the finer points argue against NAT entirely.
http://www.ietf.org/rfc/rfc4966.txt (security considerations)
Extending that, there could be some filtering somewhere.
On the host, on the edge.
A packet filter (ipso facto more relevant than a network address
translator) is the tool of choice.
Regardless, all that matters is vulnerability in services.
I could never imagine writing an article about NAT (or translation) in
a security context other than to say "focus on the real issues".
It's all kind of backward too.
IPv6 anyone?
Surely SCADA is the prima facie example of "everyone's light bulb
connected to the internet".
Where's Vint Cerf when you need him ...
Besides ...
... who uses Classes any more?
:]
I've always looked at private IP space as more of a
resource and management choice and not a security feature.
Right on ...
... and those SCADA guys have got important issues to worry about.
Best wishes.
Well, when we are talking about selection of IP addresses as a
supposed security feature...
the view that "your ASN operator probably has ingress filters" is an
optimistic one.
The relevant question if you expect "private IP" to be a security
feature is: "Can you legitimately rely on your ASN operator having
ingress filters on border routers to block your RFC1918 destinations
from remote access" ?
And the proper answer is NO, you cannot rely on that; if your
network design relies on this assumption, then it is not secure. If
your router is compromised, an intruder can announce your private
RFC1918 IP address space through a tunnel.
If an intruder is a conspirator with one of your peer networks, they
can conspire with your peer to allow an RFC1918 announcement from your
network.
Or create a static route for a RFC1918 subnet on your network.
In other words, your use of RFC1918 address space alone does not
create security. Your RFC1918 network actually _does_ need
isolation separate and apart from the address space, for you to have
reliable security, you still need a firewall, proxy, or NAT device
of some form, with the private network isolated from the public one,
even when using private IPs.
I was involved in a security review of a SCADA system a couple of years ago. Their guy was very impressed with himself and his "Internet air-gap" but managed to leave all their ops consoles on both the SCADA network and their internal corp LAN.
Their corp LAN was a mess with holes through their NAT gateway all over the place to let external support people rdesktop to the SCADA network machines.
Of course it was all on private address space internally.
So you see, when you put idiots in charge, your screwed whatever you do and private address space and NAT and whatever else will be no more then security by nice stickers and marketing.
On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis@packetnexus.com> wrote;
Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is
DEFINITELY 'flawed'.
Hi Robert,
Give the chart a second look. 192.168.0.0/16 (one of the three RFC1918
spaces) is, in fact, a /16 of IPv4 address space and it is, in fact,
found in the old "class C" range. Ditto 172.16.0.0/12. If there's a
nitpick, the author should have labeled the column something like
"classful area" instead of "classful description."
I've always looked at private IP space as more of a
resource and management choice and not a security feature.
Hi Jason,
If your machine is addressed with a globally routable IP, a trivial
failure of your security apparatus leaves your machine addressable
from any other host in the entire world which wishes to send it
packets. In the parlance, it tends to "fail open." Machines using
RFC1918 or RFC4193 space often have the opposite property: a failure
of the security apparatus is prone to leave them unable to interact
with the rest of the world at all. They tend to "fail closed."
Think of this way: Your firewall is a deadbolt and RFC1918 is the lock
on the doorknob. The knob lock doesn't stop anyone from entering an
unlatched window, opening the door from the inside and walking out
with all your stuff. Yet when you forget to throw the deadbolt, it
does stop an intruder from simply turning the knob and wandering in.
Regards,
Bill Herrin
Hey.
In other words, your use of RFC1918 address space alone does not
create security.
I had this crazy idea that somewhere in the rfcs was a "should" that
manufacturers block private address space (i.e. hard coded) but it's
not (in fact the opposite).
Obviously there's shoulds for nocs and isps.
Regardless, you're exactly correct.
Your RFC1918 network actually _does_ need
isolation separate and apart from the address space, for you to have
reliable security, you still need a firewall, proxy, or NAT device
of some form,
Pardon me but that's not axiomatic.
This is where the flames come right?
Between me and you there's X machines that route packets (and have
layer four services - yes I'm a TCP/IP model guy).
There's no separate firewall machines, no security postured proxies, no NATting.
These routers pass packets happily and don't influence my security or
the security of the other routers at all.
Obviously there are plenty of other critical machines that don't have
proxies or NATting (DNS).
Pertinently, they are publicly addressable yet don't have security
issues resulting from not having intermediate firewalls or proxies or
NAT.
The only issues they do have are what all endpoint machines face -
poor application (protocol) design (lack of encryption and so on),
poor administration, bugs.
Of those three, the methodology most readily associated to security is
firewalling (packet filtering).
A packet addressed to an endpoint that doesn't serve anything or have
a client listening will be ignered (whatever) as a matter of course.
Firewall or no firewall.
If I have a client application open on a port and get incoming from an
unsolicited IP then again it will be ignored as a matter of course.
Incoming to bogus ports are of course dropped (whatever). Firewall or
no firewall.
If I do have a port mapped to a service (serving not clienting) then
I'm open for business.
That's fundamental to TCP/IP and secure.
All other security considerations are appropriately handled at layer four.
The only reason we firewall (packet filter) is to provide access
control (for whatever reason).
Access control is a good enough reason to have something called a
firewall but everything else is a failure in design.
Again though, access control is a failure at protocol design (hence
DNS and BGP issues). Firewalling here is a kludge.
The only issue that depends on firewalling is ... DoS to preserve
bandwidth and that's not an end in and of itself.
I posit to you that in the current state of affairs, firewalling a
host or network is incredibly useful but entirely superfluous to
defending a machine.
I think you'd be hard pressed to find any convincing reason to suggest
that proxies are any more useful (given good layer four design) from
a security perspective.
NAT?
No.
Fundamentally, it's not required or every machine that was publicly
addressable would have a NAT machine shoved in front of it and another
one shoved in front of that ...
Prima facie examples are every publicly addressable machine on the internet.
If there was a reason other than address space management then our
critical infrastructure would be NATted. The history of NAT tells me
I'm right.
... you still need ...
... the private network isolated from the public one ...
No.
I apologize in advance if this is too pedestrian (you might know this
but not agree with it) but I want to make a point:
I've got homework to do (read some of that stuff and re-evaluate my
position) but NAT has caused nothing but trouble for security
practioners and allowed developers to get away with whatever they can
...
NAT saved us ... or at least all the moms and dads who don't have good
product or good administration.
... you still need ...
... the private network isolated from the public one ...
If this were true then IPv6 was fail.
Apart from any push to bring NAT along for the ride, we have a newer
IP with the deliberate choice made to make every machine publicly
addressable ... and to turn every NAT box into a router only ... and
let them route packets (like every other intermediate router) freeing
up hosts ... to do host security.
To me that was a breath of very fresh air.
The only reason to be concerned about this is vendors who make bad
choices and for that there's always other vendors. :]
--
-JH
Best wishes.
William Herrin (bill) writes:
If your machine is addressed with a globally routable IP, a trivial
failure of your security apparatus leaves your machine addressable
from any other host in the entire world which wishes to send it
packets. In the parlance, it tends to "fail open." Machines using
RFC1918 or RFC4193 space often have the opposite property: a failure
of the security apparatus is prone to leave them unable to interact
with the rest of the world at all. They tend to "fail closed."Think of this way: Your firewall is a deadbolt and RFC1918 is the lock
on the doorknob. The knob lock doesn't stop anyone from entering an
unlatched window, opening the door from the inside and walking out
with all your stuff. Yet when you forget to throw the deadbolt, it
does stop an intruder from simply turning the knob and wandering in.
That's not exactly correct. NAT doesn't imply firewalling/filtering.
To illustrate this to customers, I've mounted attacks/scans on
hosts behind NAT devices, from the interconnect network immediately
outside: if you can point a route with the ext ip of the NAT device
as the next hop, it usually just forwards the packets...
Phil
Have you written this up anywhere? It would be absolutely awesome to be
able to point the "NAT IS A SECURITY FEATURE!!!" crowd to an actual
demonstration of why it isn't.
Doug
On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis@packetnexus.com> wrote;
Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is
DEFINITELY 'flawed'.Hi Robert,
Give the chart a second look. 192.168.0.0/16 (one of the three RFC1918
spaces) is, in fact, a /16 of IPv4 address space and it is, in fact,
found in the old "class C" range. Ditto 172.16.0.0/12. If there's a
nitpick, the author should have labeled the column something like
"classful area" instead of "classful description."I've always looked at private IP space as more of a
resource and management choice and not a security feature.Hi Jason,
If your machine is addressed with a globally routable IP, a trivial
failure of your security apparatus leaves your machine addressable
from any other host in the entire world which wishes to send it
packets. In the parlance, it tends to "fail open." Machines using
RFC1918 or RFC4193 space often have the opposite property: a failure
of the security apparatus is prone to leave them unable to interact
with the rest of the world at all. They tend to "fail closed."
This "fail open" vs "fail closed" is a very good characterization of
the situation. While many IPv4 situations requires RFC1918 addresses
due to scarcity, so it is a moot point, this fail open vs closed
argument applies very well to why one should consider IPv6 ULA
addresses in certain specific scenarios. If the system does not need
to speak to the outside world, a ULA is frequently the right choice to
leverage this "fail closed" benefits, which IMHO outstrip any
advantages due to "not having to renumber when requirements change" or
whatever else the religiously anti-ULA folks have to say.
CB
When you all say NAT, are you implying PAT as well? 1 to 1 NAT really
provides no security. But with PAT, different story. Are there poor
implementations of PAT that don't enforce an exact port/address match for
the translation table? If the translation table isn't at fault, are the
'helpers' that allow ftp to work passively to blame?
Chuck
Doug Barton (dougb) writes:
Chuck Church (chuckchurch) writes:
When you all say NAT, are you implying PAT as well? 1 to 1 NAT really
provides no security. But with PAT, different story. Are there poor
implementations of PAT that don't enforce an exact port/address match for
the translation table? If the translation table isn't at fault, are the
'helpers' that allow ftp to work passively to blame?
PAT (overload) will have ports open listening for return traffic,
on the external IP that's being "overloaded".
What happens if you initiate traffic directed at the RFC1918
network itself, and send that to the MAC address of the NAT device ?
In many cases, it just works. That's how IP forwarding works, after
all 
inside net ----------[NAT]-----------{ext net}----[attacker]
192.168.0.0/24 .254 1.2.3.4 1.2.3.5
S:1.2.3.5 D:192.168.0.1 next hop: 1.2.3.4
Now, on the way back *out* from the inside net, traffic from
192.168.0.1 back to 1.2.3.4 might get translated - it depends if
what the NAT is programmed to do if it sees, say, a S/A packet
with no corresponding SYN, on its way out. It might just get
dropped. UDP would in some cases get natted, but since you
know your destination port on 1.2.3.5, you know what to expect,
and you can build an asymmetric connection since you control the
attacking host.
Either way, you've still injected traffic into the inside net.
Etc...
Google for "NAT is not a security feature" and review all the discussions and unnecessary panic over a lack of NAT support in IPv6. If your SCADA network can reach the public internet then your security is only as good as your firewall, whether you NAT or not. If your SCADA network is completely isolated then it doesn't make a bit of difference what addresses you use.
SCADA networks should be hard air-gapped from any other network.
In case you're in charge of one, and you didn't hear that, let me say it again:
*SCADA networks should he hard air-gapped from any other network.*
If you're in administrative control of one, and it's attacked because you
didn't follow this rule, and someone dies because of it, I heartily, and
perfectly seriously, encourage that you be charged with homicide.
We do it with Professional Engineers; I see no reason we shouldn't expect
the same level of responsibility from other types.
Cheers,
-- jra
Accepting strict source routing from a public interface is certainly in the
top 10 Worst Common Practices, is it not? (IE: I would be surprised if *any*
current router actually let you do that.)
Cheers,
-- jra
I don't want to start a flame war, but this article seems flawed to
me. It seems an IP is an IP.I think I could announce private IP space, so doesn't that make this
argument invalid?
You could announce it. I wouldn't expect anyone else to listen to those announcements other than for the purpose of ridiculing you.
I've always looked at private IP space as more of a
resource and management choice and not a security feature.
It depends.
Case 1: If the SCADA vendors are configuring units with non-RFC1918 IP space in live customer installations, and these installations aren't ever in any way connected to the public Internet, then there isn't any real operational problem. It smacks of carelessness/cluelessness on the part of both the vendor and the IT staff of the customer who accepted the configuration, but nothing is operationally broken.
Case 2: Same as above, but the SCADA network is connected to the Internet behind a NAT at the customer location. Again careless and clueless. And should anything on that network need to access resources on the Internet within the space configured on the SCADA system it won't work. The vendor/customer have broken reachability to some part of the public Internet for that system. Whether there is a security risk depends on the configuration of the NAT firewall and whether and how how the SCADA system opens connections outbound and what vulnerabilities exist in its systems if it does. No more security risk than the same situation using RFC1918 space.
Case 3: Same as case 2 but without the NAT. Pretty much the same result. The SCADA system won't be reachable from the outside because the customer's provider won't route those addresses to the customer. Packets sourced to the Internet from the SCADA aren't likely to get very far. Even more broken/stupid than the other scenarios but not likely to be much of a security risk in terms of exposure to the Internet.
Case 4: SCADA vendor asks customer for a subnet of public IP space allocated to the customer and installs the SCADA system directly on the Internet. From an RFC standpoint, nothing is broken. From a security standpoint, without appropriate firewalls, a very bad idea.
So, yes, it's a dumb idea. The degree of dumbness depends.
That makes sense, but I'm wondering if that should be considered correct
behavior. Obviously a non-consumer grade router can have rules defining
what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
everything coming from the outside in to either a) match up with something
in the translation table, b) be a service the router itself is hosting
(http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be
dropped. Routing without translating ports and addresses seems like the
root of the issue.
Chuck
I think I could announce private IP space, so doesn't that make this
argument invalid?You could announce it. I wouldn't expect anyone else to listen to those
announcements other than for the purpose of ridiculing you.
People keep pointing to this as unlikely. I argue that spammers are
currently doing this all over the world, maybe not as widespread wiith
1918 space. If I can announce 1918 space to an ISP where my target
is...it doesn't matter if everyone else ignores or drops it. The ISP
allowed it, so all their customers will route the traffic. I still
think it's a valid attack vector, discounting it because people would
laugh at me, seems like a poor security posture.
jas