Arguing against using public IP space

[Jason Lewis]

I don't want to start a flame war, but this article seems flawed to
me.  It seems an IP is an IP.

http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html

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.

Re: Arguing against using public IP space

[Robert Bonomi]

On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis  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.
>
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> 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've always looked at private IP space as more of a
> resource and management choice and not a security feature.
>

Re: Arguing against using public IP space

[Dobbins, Roland]

On Nov 13, 2011, at 10:36 PM, Jason Lewis wrote:

> 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.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: Arguing against using public IP space

[David Walker]

On 14/11/2011, Jason Lewis  wrote:
> 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.

Re: Arguing against using public IP space

[Jimmy Hess]

On Sun, Nov 13, 2011 at 10:38 AM, Robert Bonomi
 wrote:
> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis  
> wrote;
> In addition, virtually _every_ ASN operator has ingress filters on their
> border routers to block almost all traffic to RFC-1918 destinations.

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.

--
-JH

Re: Arguing against using public IP space

[Leigh Porter]

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.

-- 
Leigh


On 13 Nov 2011, at 15:38, "Jason Lewis"  wrote:

> I don't want to start a flame war, but this article seems flawed to
> me.  It seems an IP is an IP.
> 
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
> 
> 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.
> 
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> __

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: Arguing against using public IP space

[William Herrin]

On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
 wrote:
> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis  
> wrote;
>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> 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."


On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis  wrote:
> 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


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Arguing against using public IP space

[David Walker]

Hey.

On 14/11/2011, Jimmy Hess  wrote:
> 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:
http://en.wikipedia.org/wiki/End-to-end_connectivity
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.

Re: Arguing against using public IP space

[Phil Regnauld]

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

Re: Arguing against using public IP space

[Doug Barton]

On 11/13/2011 13:27, Phil Regnauld wrote:
>   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...

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

-- 

"We could put the whole Internet into a book."
"Too practical."

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

Re: Arguing against using public IP space

[Cameron Byrne]

On Sun, Nov 13, 2011 at 12:13 PM, William Herrin  wrote:
> On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
>  wrote:
>> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis  
>> wrote;
>>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>>
>> 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."
>
>
> On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis  wrote:
>> 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

> 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
>
>
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
>
>

RE: Arguing against using public IP space

[Chuck Church]

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

-Original Message-
From: Doug Barton [mailto:do...@dougbarton.us] 
Sent: Sunday, November 13, 2011 4:49 PM
To: Phil Regnauld
Cc: nanog@nanog.org
Subject: Re: Arguing against using public IP space

On 11/13/2011 13:27, Phil Regnauld wrote:
>   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...

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

-- 

"We could put the whole Internet into a book."
"Too practical."

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

Re: Arguing against using public IP space

[Phil Regnauld]

Doug Barton (dougb) writes:
> On 11/13/2011 13:27, Phil Regnauld wrote:
> > 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...
> 
> 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.

Nope, but I could do a quick tut on how to do this against a natd/pf/
iptables or IOS with IP overload.

Arguably in *most* cases your CPE or whatever is NATing is behind
some upstream device doing ingress filtering, so you still need to
be compromising a device fairly close to the target network.

P.

Re: Arguing against using public IP space

[Phil Regnauld]

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.2541.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...

Re: Arguing against using public IP space

[McCall, Gabriel]

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.

-Original message-
From: Jason Lewis 
To: "nanog@nanog.org" 
Sent: Sun, Nov 13, 2011 15:36:43 GMT+00:00
Subject: Arguing against using public IP space

I don't want to start a flame war, but this article seems flawed to
me. It seems an IP is an IP.

http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html

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.

Re: Arguing against using public IP space

[Jay Ashworth]

- Original Message -
> From: "Roland Dobbins" 

> 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.

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
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Arguing against using public IP space

[Jay Ashworth]

 Original Message -
> From: "Doug Barton" 

> On 11/13/2011 13:27, Phil Regnauld wrote:
> > 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...
> 
> 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.

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
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Arguing against using public IP space

[Jay Hennigan]

On 11/13/11 7:36 AM, Jason Lewis wrote:

I don't want to start a flame war, but this article seems flawed to
me.  It seems an IP is an IP.

http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html

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.

--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

RE: Arguing against using public IP space

[Chuck Church]

-Original Message-
From: Phil Regnauld [mailto:regna...@nsrc.org] 


>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.2541.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.
>

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

Re: Arguing against using public IP space

[Jason Lewis]

>> 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

Re: Arguing against using public IP space

[Robert Bonomi]

> From nanog-bounces+bonomi=mail.r-bonomi@nanog.org  Sun Nov 13 14:15:38 
> 2011
> From: William Herrin 
> Date: Sun, 13 Nov 2011 15:13:37 -0500
> Subject: Re: Arguing against using public IP space
> To: nanog@nanog.org
>
> On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
>  wrote:
> > On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis  
> > wrote;
> >> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
> >
> > 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."

In the 'classful' world, neither the /12 or the /16 spaces were referencble
as a single object.  Correct 'classful descriptions' would have been:
"16 contiguous Class 'B's"
   "256 contiguous Class 'C's"

Re: Arguing against using public IP space

[Jay Ashworth]

- Original Message -
> From: "Robert Bonomi" 

> In the 'classful' world, neither the /12 or the /16 spaces were referencible
> as a single object. Correct 'classful descriptions' would have been:
> "16 contiguous Class 'B's" "256 contiguous Class 'C's"

Fine.  But I think you're going to fine that synechdoche triumphs here, and
a Class-C *Sized* network is going to be called that, even if it's first 
octet is 191 or lower, Robert.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Arguing against using public IP space

[Dobbins, Roland]

On Nov 14, 2011, at 6:29 AM, Jay Ashworth wrote:

> SCADA networks should be hard air-gapped from any other network.

Concur, GMTA.  My point is that without an airgap, the attacker can jump from a 
production network to the SCADA network, so we're in violent agreement.

;>

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: Arguing against using public IP space

[Brett Frankenberger]

On Sun, Nov 13, 2011 at 06:29:39PM -0500, Jay Ashworth wrote:
> 
> 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.

What if you air-gap the SCADA network of which you are in
administrative control, and then there's a failure on it, and the people
responsible for troubleshooting it can't do it remotely (because of the
air gap), so the trouble continues for an extra hour while they drive
to the office, and that extra hour of failure causes someone to die. 
Should that result in a homicide charge?

What if you air-gap the SCADA network of which you are in
administrative control, but, having done so, you can't afford the level
of redundancy you could when it wasn't air-gapped, and a transport
failure leaves you without remote control of a system at a time when
it's needed to prevent a cascading failure, and that leads to someone
dieing.  Should that result in a homicide charge?

Air-gap means you have to build your own facilities for the entire
SCADA network.  No MPLS-VPN service from providers.  Can't even use
point-to-point TDM circuits (T1, for example) from providers, since
those are typically mixed in with other circuits in the carrier's DACS,
so it's only logical separation.  And even if you want to redefine
"air-gap" to be "air-gap, or at least no co-mingling in any packet
switching equipment", you've ruled out any use of commercial wireless
service (i.e. cellular) for backup paths.

A good engineer weighs all the tradeoffs and makes a judgement.  In
some systems, there's might be a safety component of availability that
justifies accepting some very small increase in the risk of outside
compromise.

You can argue that safety is paramount -- that the system needs to be
designed to never get into an unsafe condition because of a
communications failure (which, in fact is a good argument) -- that
there must always be sufficient local control to keep the system in a
safe state.  Then you can implement the air-gap policy, knowing that
while it might make remote control less reliable, there's no chance of,
say, the plant blowing up because of loss of remote control.  (Except,
of course, that that's only true if you have complete faith in the local
control system.  Sometimes remote monitoring can allow a human to see
and correct a developing unsafe condition that the control system was
never programmed to deal with.)

But even if the local control is completely safe in the loss-of-comm
failure case, it's still not as cut and dried as it sounds.  The plant
might not blow up.  But it might trip offline with there being no way
to restart it because of a comm failure.  Ok, fine, you say, it's still
in a safe condition.  Except, of course, that power outages, especially
widespread ones, can kill people.  Remote control of the power grid
might not be necessarily to keep plants from blowing up, but it's
certainly necessary in certain cases to keep it online.  (And in this
paragraph, I'm using the power grid as an example.  But the point I'm
making in this post is more general case.)

Sure, anytime there's an attack or failure on a SCADA network that
wouldn't have occurred had it been air-gapped, it's easy for people to
knee-jerk a "SCADA networks should be airgapped" response.  But that's
not really intelligent commentary unless you carefully consider what
risks are associated with air-gapping the network.

Practically speaking, non-trivial SCADA networks are almost never
completely air-gapped.  Have you talked to people who run them?

 -- Brett

Re: Arguing against using public IP space

[Jay Ashworth]

- Original Message -
> From: "Brett Frankenberger" 

> What if you air-gap the SCADA network of which you are in
> administrative control, and then there's a failure on it, and the
> people responsible for troubleshooting it can't do it remotely (because of
> the air gap), so the trouble continues for an extra hour while they drive
> to the office, and that extra hour of failure causes someone to die.
> Should that result in a homicide charge?

I should think it would be your responsibility, as the chief engineer, to
make sure *you have filled all such possible holes in your operations plan*.

> What if you air-gap the SCADA network of which you are in
> administrative control, but, having done so, you can't afford the
> level of redundancy you could when it wasn't air-gapped, and a transport
> failure leaves you without remote control of a system at a time when
> it's needed to prevent a cascading failure, and that leads to someone
> dieing. Should that result in a homicide charge?

If it costs more to run, then it *costs more to run*.

> Air-gap means you have to build your own facilities for the entire
> SCADA network. No MPLS-VPN service from providers. Can't even use
> point-to-point TDM circuits (T1, for example) from providers, since
> those are typically mixed in with other circuits in the carrier's
> DACS, so it's only logical separation. And even if you want to redefine
> "air-gap" to be "air-gap, or at least no co-mingling in any packet
> switching equipment", you've ruled out any use of commercial wireless
> service (i.e. cellular) for backup paths.

*I* define "air gap" as "no way to move packets from the outside world
into the network.  I didn't say "100% dedicated facilities", though your
implication that that still leaves an attacker a way to reconfigure things
such that they could get in is absolutely correct.

> A good engineer weighs all the tradeoffs and makes a judgement. In
> some systems, there's might be a safety component of availability that
> justifies accepting some very small increase in the risk of outside
> compromise.

The line is pretty bright, I think, but you're correct in asserting that the
price difference goes up as the square of the number of nines.  But that's not
important now; we're talking about cases that aren't even *99%*, much less 4 or
5 nines of unlikelihood that an outsider can find a way to break in.
 
> You can argue that safety is paramount -- that the system needs to be
> designed to never get into an unsafe condition because of a
> communications failure (which, in fact is a good argument) -- that
> there must always be sufficient local control to keep the system in a
> safe state. Then you can implement the air-gap policy, knowing that
> while it might make remote control less reliable, there's no chance
> of, say, the plant blowing up because of loss of remote control. (Except,
> of course, that that's only true if you have complete faith in the
> local control system. Sometimes remote monitoring can allow a human to see
> and correct a developing unsafe condition that the control system was
> never programmed to deal with.)

Yes, but that's enablement for loss of locally staffed control, all by itself.

Even power utilities have a pretty good real rate of return these days; I have
no problem with them spending a little more of their revenue on safety, instead 
of profit.  If that takes regulators pointing guns at them, I'm fine with that.

> But even if the local control is completely safe in the loss-of-comm
> failure case, it's still not as cut and dried as it sounds. The plant
> might not blow up. But it might trip offline with there being no way
> to restart it because of a comm failure. Ok, fine, you say, it's still
> in a safe condition. Except, of course, that power outages, especially
> widespread ones, can kill people. Remote control of the power grid
> might not be necessarily to keep plants from blowing up, but it's
> certainly necessary in certain cases to keep it online. (And in this
> paragraph, I'm using the power grid as an example. But the point I'm
> making in this post is more general case.)

And I just read the Cracked piece talking about the 77 NYC blackout, which is
sort of weird, actually.  :-)  But the general case point *I* was making was
not that I expected a conviction.

It was that I expected a charge, and a trial.

If a bridge collapses, are we going to charge the Professional Engineer who 
signed off on it?
 
> Sure, anytime there's an attack or failure on a SCADA network that
> wouldn't have occurred had it been air-gapped, it's easy for people to
> knee-jerk a "SCADA networks should be airgapped" response. But that's
> not really intelligent commentary unless you carefully consider what
> risks are associated with air-gapping the network.
> 
> Practically speaking, non-trivial SCADA networks are almost never
> completely air-gapped. Have you talked to people who run them?

No, and yes my knee was jerking.  But 

Re: Arguing against using public IP space

[Jeff Kell]

On 11/13/2011 4:27 PM, Phil Regnauld wrote:
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 


"It depends" on your NAT model.  If you take a default Cisco PIX or ASA 
device...


(a) There is an option to "permit non-NAT traffic through the 
firewall".  If not selected (nat-control) then there must be a covering 
NAT rule for any inside host to communicate with the outside interface, 
let alone outside-to-inside.


(b) By default all inbound traffic is default-deny, only "return" 
traffic for inside-initiated connections is allowed.


Yes, it's stateful (which is another argument altogether for placing a 
stateful device in the chain) but by all means, it does not allow 
outside traffic into the inside, regardless of the addressing scheme on 
the inside.


Beyond that, using 1918 space decreases the possibility that a "new, 
unexpected" path to the inside network will result in exposure.  If you 
are using public space on the inside, and some path develops that 
bypasses the firewall, the routing information is already in place, you 
only need to affect the last hop.  You can then get end-to-end routing 
of inside hosts to an outside party.  Using 1918 space, with even 
nominal BCP adherence of the intermediate transit providers, you can't 
leak routing naturally.  (Yes, it's certainly possible, but it raises 
the bar).


If the added protection were trivial, I would think the PCI requirement 
1.3.8 requiring it would have been rejected long ago.


Jeff

Re: Arguing against using public IP space

[Jay Hennigan]

On 11/13/11 3:58 PM, Jason Lewis wrote:


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.


It would be your target announcing the RFC1918 space, so the security
risk would be if his ISP, your ISP and all of the intermediate
peering/transit links were to honor those announcements and route the
traffic to the target.  Possible, and it has probably happened at some
point, but not likely.  The closer your logically to your target the
more likely such an attack would succeed.

I certainly don't recommend announcing RFC1918 space to the public
Internet.  Doing so is a bad thing.  If you do so there is indeed a
non-zero chance that someone close enough to you could connect to your
network and do damage.

Announcing RFC1918 space is less likely to route very far than
announcing public space that isn't allocated to you, however.  That's
what the spammers all over the world are doing.

In terms of security, most every SCADA system, as others have pointed
out, should not be connected to the public Internet AT ALL.  In this
case it really doesn't matter what addressing scheme is used.  Use
Novell IPX or Appletalk if you want.  Or MODBUS.

If, however, it is using IPv4, RFC1918 space in a different subnet than
anything used internally within the organization is a better choice than
any public space or subnets of RFC1918 space in use within the
organization.  This offers a degree of protection against mis-cabling
and other accidental or malicious vectors that could allow other
networks to communicate with the SCADA network.

It would probably be best if the SCADA hardware vendors were to ship
their gear with no IP addresses pre-programmed at all, as well as
preventing them from being configured until any default passwords are
changed.  Similarly, they should educate their installation contractors
about such things.

--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: Arguing against using public IP space

[Joe Greco]

> Sure, anytime there's an attack or failure on a SCADA network that
> wouldn't have occurred had it been air-gapped, it's easy for people to
> knee-jerk a "SCADA networks should be airgapped" response.  But that's
> not really intelligent commentary unless you carefully consider what
> risks are associated with air-gapping the network.

Not to mention that it's not the only way for these things to get
infected.  Getting fixated on air-gapping is unrealistically ignoring
the other threats out there.

There needs to be a whole lot more security work done on SCADA nets.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Arguing against using public IP space

[Valdis . Kletnieks]

On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said:

> What if you air-gap the SCADA network of which you are in
> administrative control, and then there's a failure on it, and the people
> responsible for troubleshooting it can't do it remotely (because of the
> air gap), so the trouble continues for an extra hour while they drive
> to the office, and that extra hour of failure causes someone to die. 
> Should that result in a homicide charge?

If you designed a life-critical airgapped network that didn't have a trained
warm body at the NOC 24/7 with an airgapped management console, and hot (or at
least warm) spares for both console and console monkey, yes, you *do* deserve
that negligent homicide charge.




pgpkevpyDqpU9.pgp
Description: PGP signature

Re: Arguing against using public IP space

[Joel jaeggli]

On 11/14/11 10:24 , Joe Greco wrote:
>> Sure, anytime there's an attack or failure on a SCADA network that
>> wouldn't have occurred had it been air-gapped, it's easy for people to
>> knee-jerk a "SCADA networks should be airgapped" response.  But that's
>> not really intelligent commentary unless you carefully consider what
>> risks are associated with air-gapping the network.
> 
> Not to mention that it's not the only way for these things to get
> infected.  Getting fixated on air-gapping is unrealistically ignoring
> the other threats out there.
> 
> There needs to be a whole lot more security work done on SCADA nets.

Stuxnet should provide a fairly illustrative example.

It doesn't really matter how well isolated from direct access it is if
it has a soft gooey center and a willing attacker.

> ... JG

Re: Arguing against using public IP space

[Jimmy Hess]

On Sun, Nov 13, 2011 at 3:03 PM, David Walker  wrote:
> On 14/11/2011, Jimmy Hess  wrote:
> 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.
It will not go to a listening application,  neither will it be
completely ignored --
the receiving machine's  TCP stack will have a look at the packet.
On common operating systems there  are frequently unsafe applications
listening on ports;  on certain OSes, there will be no way to turn off
system applications,  or human error will leave them in place.

> That's fundamental to TCP/IP and secure.
It's fundamental to TCP/IP,  but not fundamentally secure.  TCP/IP
implementations have flaws.
If a host is meant solely as an endpoint, then it is exposed to undue
risk, if arbitrary packets can be addressed to its TCP/IP stack that
might have remotely exploitable bugs.

> The only reason we firewall (packet filter) is to provide access
> control (for whatever reason).
No, we also firewall to block access entirely to applications
attempting to establish a service on unapproved ports.We also use
firewalls in certain forms to ensure that communications over a TCP/IP
socket comply with a protocol,  for example,  that a session
terminated on port 25 is actually a SMTP session.

The firewall might restrict the set of allowed SMTP commands, validate
the syntax of certain commands,  hide server version information,
prevent use of ESMTP pipelining from outside, etc.

> 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:
> http://en.wikipedia.org/wiki/End-to-end_connectivity

End to end connectivity principal's purpose is not to provide
security.It is to facilitate communications with other hosts and
networks. When a private system _really_ has to be secure,  end to
end connectivity is inherently incompatible  with security objectives.

There is always a tradeoff involving sacrificing a level of security
against remote attack
when connecting a computer to a network,  and then again,  when
connecting the network to the internet.

A computer that is not connected to a network is perfectly secure
against network-based attacks.
A computer that is connected to LAN is at risk of potential
network-based attack from that LAN.

If that LAN is then connected through a firewall  through many to 1
NAT,  there is another layer of risk added.

If the NAT'ing firewall is then replaced with a simple many to 1 NAT
router,  there is another layer of risk added; there are new attacks
possible that still succeed in a NAT environment,  that the firewall
would have stopped.

Finally, if that that same computer is then given end to end
connectivity with no firewall,  there is a much   less encumbered
communications path available to that computer for launching
network-based attack;  the attack surface is greatly increased in such
a design.

If we are talking about nodes that interface with a SCADA network;
the concept of unfirewalled end-to-end connectivity approaches the
level of insanity.

Those are not systems where end-to-end public connectivity should be a
priority over security.

--
-JH

Re: Arguing against using public IP space

[Owen DeLong]

On Nov 13, 2011, at 7:36 AM, Jason Lewis wrote:

> I don't want to start a flame war, but this article seems flawed to
> me.  It seems an IP is an IP.
> 
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
> 
> 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.

Yes, the author of this article is sadly mistaken and woefully void
of clue on the issues he attempts to address.

You are completely correct.

Owen

Re: Arguing against using public IP space

[Dobbins, Roland]

On Nov 14, 2011, at 9:24 AM, Joe Greco wrote:

> Getting fixated on air-gapping is unrealistically ignoring the other threats 
> out there.

I don't think anyone in this thread is 'fixated' on the idea of airgapping; but 
it's generally a good idea whenever possible, and as restrictive a 
communications policy as is possible is definitely called for, amongst all the 
other things one ought to be doing.

It's also important to note that it's often impossible to *completely* airgap 
things, these days, due to various interdependencies, admin requirements 
(mentioned before), and so forth; perhaps bastioning is a more apt term.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde