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-u... 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.
http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-u...
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.
On Sun, Nov 13, 2011 at 10:38 AM, Robert Bonomi <bonomi@mail.r-bonomi.com> wrote:
On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis@packetnexus.com> 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
Hey. On 14/11/2011, Jimmy Hess <mysidia@gmail.com> 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.
On 14/11/2011, Jimmy Hess <mysidia@gmail.com> 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 --
On Sun, Nov 13, 2011 at 3:03 PM, David Walker <davidianwalker@gmail.com> wrote: 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
On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi <bonomi@mail.r-bonomi.com> wrote:
On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis@packetnexus.com> wrote;
http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-u...
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 <jlewis@packetnexus.com> 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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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
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/
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:dougb@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/
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...
-----Original Message----- From: Phil Regnauld [mailto:regnauld@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 .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.
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
Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. The fact that consumer cpe's typically do both nat and stateful firewalling does not mean that those functions are inseparable. -----Original message----- From: Chuck Church <chuckchurch@gmail.com> To: 'Phil Regnauld' <regnauld@nsrc.org> Cc: "nanog@nanog.org" <nanog@nanog.org> Sent: Sun, Nov 13, 2011 23:53:19 GMT+00:00 Subject: RE: Arguing against using public IP space -----Original Message----- From: Phil Regnauld [mailto:regnauld@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 .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.
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
On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel <Gabriel.McCall@thyssenkrupp.com> wrote:
Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
The fact that consumer cpe's typically do both nat and stateful firewalling does not mean that those functions are inseparable.
Gabriel, This is not accurate. First, many:1 NAT (sometimes also called PAT) is not separable from a stateful firewall. You can build a stateful firewall without many-to-one NAT but the reverse is not possible. Second, while a security benefit from RFC 1918 addressing combined with 1:1 NAT is dubious at best, the same is not true for the much more commonly implemented many:1 NAT. With RFC1918 plus many:1 NAT, most if not all functions of the interior of the network are not addressable from far locations outside the network, regardless of the correct or incorrect operation of the security apparatus. This is an additional boundary which must be bypassed in order to gain access to the network interior. While there are a variety of techniques for circumventing this boundary no combination of them guarantees successful breach. Hence it provides a security benefit all on its own. You would not rely on NAT+RFC1918 alone to secure a network and neither would I. However, that's far from meaning that the use of RFC1918 is never (or even rarely) operative in a network's security process. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Nov 14, 2011, at 11:32 AM, William Herrin wrote:
On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel <Gabriel.McCall@thyssenkrupp.com> wrote:
Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
The fact that consumer cpe's typically do both nat and stateful firewalling does not mean that those functions are inseparable.
Gabriel,
This is not accurate.
First, many:1 NAT (sometimes also called PAT) is not separable from a stateful firewall. You can build a stateful firewall without many-to-one NAT but the reverse is not possible.
Actually, you can. You need a state machine, but, several recent incidents have proven that the state machine in many of the lower-end consumer appliances is not, in fact, a firewall. This has been explained earlier in the thread, so I won't repeat it here.
Second, while a security benefit from RFC 1918 addressing combined with 1:1 NAT is dubious at best, the same is not true for the much more commonly implemented many:1 NAT.
Repeating this fallacy still doesn't make it true.
With RFC1918 plus many:1 NAT, most if not all functions of the interior of the network are not addressable from far locations outside the network, regardless of the correct or incorrect operation of the security apparatus. This is an additional boundary which must be bypassed in order to gain access to the network interior. While there are a variety of techniques for circumventing this boundary no combination of them guarantees successful breach. Hence it provides a security benefit all on its own.
If the security apparatus malfunctions, nothing prevents it from malfunctioning in a way that passes packets to the RFC-1918 addressed hosts.
You would not rely on NAT+RFC1918 alone to secure a network and neither would I. However, that's far from meaning that the use of RFC1918 is never (or even rarely) operative in a network's security process.
RFC-1918 and NAT as a security measure is, at best, a locking screen door deployed in front of a vault door. If you take away the vault door, the screen door really doesn't do much. If the vault door is still there, the presence or absence of the screen door is largely irrelevant. Owen
On 14 Nov 2011, at 18:52, "McCall, Gabriel" <Gabriel.McCall@thyssenkrupp.com> wrote:
Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Tue, 15 Nov 2011 10:57:32 GMT, Leigh Porter said:
Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure!
By the same token, if your firewall fails closed rather than fails open, you're more secure. And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows Firewall has been shipping with inbound "default deny" since XP SP2 or so. How many years ago was that? And what *real* security over and above that host-based firewall are you getting from that appliance? Or as Dr Phil would say "FIrewalls - how is that working out for you?"
And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys > and similar things
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Tuesday, November 15, 2011 9:17 AM To: Leigh Porter Cc: nanog@nanog.org; McCall, Gabriel Subject: Re: Arguing against using public IP space that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides > any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows > Firewall has been shipping with inbound "default deny" since XP SP2 or so. How many years ago was that? Simple explanation is that most firewall rules are written to trust traffic initiated by 'inside' (your users), and the return traffic gets trusted as well. This applies to both Window's own FW, and most hardware based firewalls. And NAT/PAT devices too. There's nothing more dangerous than a user with a web browser. Honestly, FWs will keep out attacks initiated from outside. But for traffic permitted or initiated by the inside, IPS is only way to go. Chuck
Quite right.. I bet all Iran's nuclear facilities have air gaps but they let people in with laptops and USB sticks. -- Leigh On 15 Nov 2011, at 14:48, "Chuck Church" <chuckchurch@gmail.com> wrote:
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Tuesday, November 15, 2011 9:17 AM To: Leigh Porter Cc: nanog@nanog.org; McCall, Gabriel Subject: Re: Arguing against using public IP space
And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys > and similar things that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides > any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows > Firewall has been shipping with inbound "default deny" since XP SP2 or so. How many years ago was that?
Simple explanation is that most firewall rules are written to trust traffic initiated by 'inside' (your users), and the return traffic gets trusted as well. This applies to both Window's own FW, and most hardware based firewalls. And NAT/PAT devices too. There's nothing more dangerous than a user with a web browser. Honestly, FWs will keep out attacks initiated from outside. But for traffic permitted or initiated by the inside, IPS is only way to go.
Chuck
______________________________________________________________________ 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 ______________________________________________________________________
On Tue, 15 Nov 2011 17:16:23 GMT, Leigh Porter said:
Quite right.. I bet all Iran's nuclear facilities have air gaps but they let people in with laptops and USB sticks.
And that's the point - *most* networks have so many bigger issues that the whole "NAT makes us secure" mantra is dangerous self-delusion. If you have machines in the NAT area where you're actually concerned that "ZOMG the firewall might fail and expose them", why aren't they airgapped? As the Iranians discovered, if the attacker gets a foothold inside the NAT you're screwed anyhow, and *that* is probably a lot more likely scenario than a fail-open firewall..
On Tue, Nov 15, 2011 at 9:17 AM, <Valdis.Kletnieks@vt.edu> wrote:
And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through.
Valdis, A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Guys, Everyone is complaining about whether a FW serves its purpose or not. Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise. I don't think in a large environment you can avoid "complexity" these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof. -Hammer- "I was a normal American nerd" -Jack Herer On 11/15/2011 08:56 AM, William Herrin wrote:
On Tue, Nov 15, 2011 at 9:17 AM,<Valdis.Kletnieks@vt.edu> wrote:
And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through.
Valdis,
A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently.
Regards, Bill Herrin
On Nov 15, 2011 7:09 AM, "-Hammer-" <bhmccie@gmail.com> wrote:
Guys, Everyone is complaining about whether a FW serves its purpose or not.
Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise.
I would say security is about stopping threats , not layering in technology and tools. Granted, layer is a good idea, throwing everything including the kitchen sink at a problem will result in just a larger problem.
I don't think in a large environment you can avoid "complexity" these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof.
Large environments have to force simplicity to combat the natural ebb of complexity. The largest operators live by one rule , KISS. L3 network fw are an attack vector and single point of failure. But, I think this thread is not changing anyone's mind at this point.
-Hammer-
"I was a normal American nerd" -Jack Herer
On 11/15/2011 08:56 AM, William Herrin wrote:
On Tue, Nov 15, 2011 at 9:17 AM,<Valdis.Kletnieks@vt.edu> wrote:
And this is totally overlooking the fact that the vast majority of
*actual*
attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through.
Valdis,
A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently.
Regards, Bill Herrin
I see your side Cameron. -Hammer- "I was a normal American nerd" -Jack Herer On 11/15/2011 09:20 AM, Cameron Byrne wrote:
On Nov 15, 2011 7:09 AM, "-Hammer-" <bhmccie@gmail.com <mailto:bhmccie@gmail.com>> wrote:
Guys, Everyone is complaining about whether a FW serves its purpose or
not. Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise.
I would say security is about stopping threats , not layering in technology and tools. Granted, layer is a good idea, throwing everything including the kitchen sink at a problem will result in just a larger problem.
I don't think in a large environment you can avoid "complexity" these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof.
Large environments have to force simplicity to combat the natural ebb of complexity. The largest operators live by one rule , KISS.
L3 network fw are an attack vector and single point of failure.
But, I think this thread is not changing anyone's mind at this point.
-Hammer-
"I was a normal American nerd" -Jack Herer
On 11/15/2011 08:56 AM, William Herrin wrote:
On Tue, Nov 15, 2011 at 9:17 AM,<Valdis.Kletnieks@vt.edu
<mailto:Valdis.Kletnieks@vt.edu>> wrote:
And this is totally overlooking the fact that the vast majority of
*actual*
attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through.
Valdis,
A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently.
Regards, Bill Herrin
On Tue, 15 Nov 2011 09:56:38 EST, William Herrin said:
A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently.
You missed the point - in the greater scheme of things, the threat model has moved on, so the entire "ZOMG We can't deploy IPv6 because there's no NAT for security" is a total crock of bovine manure. There are *so many* lower-hanging fruit these days that if you're trying to *actually* improve your site's security, you'd just punt worrying about the NAT stuff and focus on doing a better job defending against the threats that are actually succeeding in breaking into systems. In another year or two, lack of IPv6 deployment is going to start impacting the "availability" part of the security triad. I'd worry about *that* more than "how many NATs can dance on the head of a pin".
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows Firewall has been shipping with inbound "default deny" since XP SP2 or so. How many years ago was that? And what *real* security over and above that host-based firewall are you getting from that appliance?
Or as Dr Phil would say "FIrewalls - how is that working out for you?"
Do you have actual honest-to-ghod numbers, Valdis? And aren't you making here the same assumption for which we chastise people who run DNS resolvers that wildcard to advertising pages for NXDOMAIN: That all the world's a workstation? Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote:
On 14 Nov 2011, at 18:52, "McCall, Gabriel" <Gabriel.McCall@thyssenkrupp.com> wrote:
Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure!
This is not true. If your firewall is not working, it should not be passing packets. If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a failure of the network implementor and the address space will not have any impact whatsoever on your lack of security.
As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.
So does a firewall. Owen
If you put a router where you needed a firewall, then, this is not a = failure of the firewall, but, a failure of the network implementor and the address space will not have = any impact whatsoever on your lack of security.
And the difference between a router and a firewall is ...? Apparently, one bit. ... 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.
On Nov 15, 2011, at 7:54 AM, Joe Greco wrote:
If you put a router where you needed a firewall, then, this is not a = failure of the firewall, but, a failure of the network implementor and the address space will not have = any impact whatsoever on your lack of security.
And the difference between a router and a firewall is ...?
Apparently, one bit.
IMHO, a firewall does not route packets by default, but, rather only forwards those packets which match configured policies. A router, OTOH, routes packets by default, but, may be configured with some policy about which packets to forward. The difference functionally is what happens when the configuration is lost or corrupted. Essentially fail open vs. fail closed. Owen
On Nov 15, 2011, at 7:54 AM, Joe Greco wrote:
If you put a router where you needed a firewall, then, this is not a = failure of the firewall, but, a failure of the network implementor and the address space will not have = any impact whatsoever on your lack of security.
And the difference between a router and a firewall is ...?
Apparently, one bit.
IMHO, a firewall does not route packets by default, but, rather only forwards those packets which match configured policies.
A router, OTOH, routes packets by default, but, may be configured with some policy about which packets to forward.
The difference functionally is what happens when the configuration is lost or corrupted. Essentially fail open vs. fail closed.
1 vs 0. As I said... one bit. Understanding this fundamental truth is helpful in understanding why people use "routers" as "firewalls" and "firewalls" as "routers". Because they're basically the same thing, with a one bit difference. And some products, say like FreeBSD (which forms the heart of things like pfSense, so let's not even begin to argue that it "isn't a firewall") can actually be configured to default either way. So basically, while we would all prefer that firewalls default to deny, it probably isn't as important a distinction as this thread is making it out to be, because even a "default to deny" firewall fails when a naive admin makes a typo and allows all traffic from 0/0 inadvertently. It's just a matter of statistical likelihood. Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already. ... 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.
On Tue, 15 Nov 2011, Joe Greco wrote:
Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already.
er. you've forgotten "en; conf t; ip routing" to turn off the default "no ip routing" (or "no ip forwarding" is my memory, but my config archive says otherwise) so we had default to deny in routers for a long time.... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On Tue, 15 Nov 2011, Joe Greco wrote:
Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already.
er. you've forgotten "en; conf t; ip routing" to turn off the default "no ip routing" (or "no ip forwarding" is my memory, but my config archive says otherwise)
so we had default to deny in routers for a long time....
My bad. But seriously, now, I'm going to wander a bit far to make a point that I hope people get. In the '90's, during the rapid ISP growth era, one of the local policies here was that all boxes should be protected by a competent on-box firewall. The problem with this was that it was tough to implement in practice, since for the most part, boxes varied in interface configuration, etc., etc. Writing a custom ruleset for each box was nearly prohibitive. I also had clients where I saw similar problems. You'd see all sorts of pseudo-strange rulesets being written, and wildly differing policies about things like ssh, etc., which made administration a challenge too. But a large percentage seemed to go firewall-free. Bleh. So as part of the standard build, I designed an automatic firewall script that basically looked at the system IP configuration, derived reasonable defaults, and then allowed an abstract policy to be specified, such as TCP_ALLOW="80 443" and the rest was automatic. This may seem trivial to many of you, and I will even concede that it *should* be, but the point is that by having this installed by default, it made it MORE annoying to disable the firewall than it was to create a simple configuration for it. So suddenly all servers built through the build scripts reliably had firewall rules in place. I know some readers here may still be using variations on those scripts, and they've served us well over the years too. Now I want to stress the point here: It wasn't that there was this magic firewall script, because to be sure some engs still rolled their own for various reasons. The point is that SOME firewall was going to be running. And that's the desired result. In any case, to bring the discussion home, I suspect that part of the problem with routers and fw rules is that there's a lack of a "default to being firewalled". Because it's hard to do that and do it right without also being so painful that an admin just installs a "pass all" rule to get things working, and then forgets about it all. Those of you who work for large service providers or enterprises and have this all worked out - well, I'm not talking about you, of course. You have incentive and motivation to get this kind of thing working on your fleets of a thousand routers. Great. But it's still a problem for many others. ... 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.
----- Original Message -----
From: "Joe Greco" <jgreco@ns.sol.net>
And some products, say like FreeBSD (which forms the heart of things like pfSense, so let's not even begin to argue that it "isn't a firewall") can actually be configured to default either way.
By Owen's definition, it's not.
So basically, while we would all prefer that firewalls default to deny, it probably isn't as important a distinction as this thread is making it out to be, because even a "default to deny" firewall fails when a naive admin makes a typo and allows all traffic from 0/0 inadvertently. It's just a matter of statistical likelihood.
Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already.
But you're missing an important point here, Joe: we're not talking about default configuration... we're talking about *failure modes*, which are by definition unpredictable. All you can really do there is figure the probabilities... and the probability is that a *router-based* firewall (which as you and I agree, is a helluva lot of firewalls) will *be more likely* to fail into pass traffic mode than into don't pass traffic mode. Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
----- Original Message -----
From: "Joe Greco" <jgreco@ns.sol.net>
And some products, say like FreeBSD (which forms the heart of things like pfSense, so let's not even begin to argue that it "isn't a firewall") can actually be configured to default either way.
By Owen's definition, it's not.
Then Owen's definition is wrong, because the vast majority of "firewall" devices out there are software-based devices.
So basically, while we would all prefer that firewalls default to deny, it probably isn't as important a distinction as this thread is making it out to be, because even a "default to deny" firewall fails when a naive admin makes a typo and allows all traffic from 0/0 inadvertently. It's just a matter of statistical likelihood.
Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already.
But you're missing an important point here, Joe: we're not talking about default configuration... we're talking about *failure modes*, which are by definition unpredictable.
But I'm *not* missing the point. You missed mine. The fact of the matter is that routers don't come with firewall-by-default, we've failed to find ways to make it easier for people to firewall things properly than it is to open the gates. Or even notice that their gates are wide open. That's a problem.
All you can really do there is figure the probabilities... and the probability is that a *router-based* firewall (which as you and I agree, is a helluva lot of firewalls) will *be more likely* to fail into pass traffic mode than into don't pass traffic mode.
That depends on too many factors to really be able to make that call. On the equally cutting side for NAT proponents, there are some attacks against NAT devices that often succeed that shouldn't. I'm not trying to defend the firewall thing. That discussion is boring and dull, it's about the state of one bit, as I pointed out, which is the NANOG equivalent of how many angels can dance on the head of a pin. I was merely taking what seemed to be a good opportunity to point out that there's a more abstract failing here, which is that we have failed to make it easy to firewall by default. I don't mean "default to blocking packets." I mean that we've failed to make it easy for router owners to do abstract things like say "this network's a bunch of clients, and should be statefully firewalled for outbound connections only" and make it as easy (or easier) to do that than it is to open the connection wide open. Failing to put roadblocks in place where you could have roadblocks makes a network easier to penetrate. But I think I've made my point. The obvious, real, clear problem with many SCADA networks is that they're built out of garbage, with garbage software stacks, with no apparent thought given to security. On the Internet, we've typically dealt with that sort of stuff by beating it senseless (open SMTP relay, etc) and then replacing it. Adding layers to protect the "soft gooey center", as someone put it, helps, of course, but is only a band-aid solution. Who here would go passwordless on their OOB management network? ... 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.
On 15 Nov 2011, at 15:36, "Owen DeLong" <owen@delong.com> wrote:
On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote:
On 14 Nov 2011, at 18:52, "McCall, Gabriel" <Gabriel.McCall@thyssenkrupp.com> wrote:
Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure!
This is not true.
If your firewall is not working, it should not be passing packets.
And of course, things always fail just the way we want them to.
If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a failure of the network implementor and the address space will not have any impact whatsoever on your lack of security.
This is not really a well made point, sorry. It's about a firewall failing, perhaps due to software error or hardware issue or because somebody failed to correctly configure a firewall rule. The point about private space is that is forces security in a way in which public space and a firewall does not. With private space, you are forces to explicitly configure NAT holes or VPN connections whereas with public space your boxes by default are accessible by the whole Internet. By default, on a private space network, nothing can get to it.
As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.
So does a firewall.
If it fails just how you want it to. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Nov 15, 2011, at 9:14 AM, Leigh Porter wrote:
On 15 Nov 2011, at 15:36, "Owen DeLong" <owen@delong.com> wrote:
On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote:
On 14 Nov 2011, at 18:52, "McCall, Gabriel" <Gabriel.McCall@thyssenkrupp.com> wrote:
Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure!
This is not true.
If your firewall is not working, it should not be passing packets.
And of course, things always fail just the way we want them to.
Your stateful firewall is no more likely to fail open than your header-mutilating device.
If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a failure of the network implementor and the address space will not have any impact whatsoever on your lack of security.
This is not really a well made point, sorry. It's about a firewall failing, perhaps due to software error or hardware issue or because somebody failed to correctly configure a firewall rule.
The assertion I was countering is that a header-mangling device is inherently more secure than a stateful firewall that does not mangle headers. I believe that the above paragraph addresses the fact that both are equally likely to fail in an open manner. The problem I was primarily attempting to convey is that many people confuse packet filtering routers for firewalls. Routers have many ways in which they tend to fail open. Their default unconfigured mode is to pass all traffic. This is not the case with a properly designed stateful firewall.
The point about private space is that is forces security in a way in which public space and a firewall does not.
And my point is that it does not actually do so. If your header-mutilating device breaks or is badly designed or misconfigured, it is just as likely to pass traffic to your private-addressed internal hosts as a badly designed or misconfigured firewall. The only difference is the trivial difference in what it takes to get said traffic to the appliance in question.
With private space, you are forces to explicitly configure NAT holes or VPN connections whereas with public space your boxes by default are accessible by the whole Internet. By default, on a private space network, nothing can get to it.
Or deliver packets already addressed to the internal host to the external mac address of the header-mutilating device, or own the internal host through other means and have it create a tunnel which the header-mutilating device happily mistakes for a permitted stateful outbound flow, or... I realize you like to live in this fantasy land where private space makes things more secure because it allows you to be lazy about your security posture in other areas. This is a common fallacy that is well liked by many an IT department in the world. It's still a fallacy, and, arguably one that has systematically reduced security overall.
As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.
So does a firewall.
If it fails just how you want it to.
If the firewall's default state is don't forward anything, the likelihood of it failing closed is just as high as the theoretical likelihood that a header-mutilating device will do so. In fact, arguably more so. Owen
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
If your firewall is not working, it should not be passing packets.
And of course, things always fail just the way we want them to.
Your stateful firewall is no more likely to fail open than your header-mutilating device.
Please show your work. Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
In message <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
If your firewall is not working, it should not be passing packets.
And of course, things always fail just the way we want them to.
Your stateful firewall is no more likely to fail open than your header-mutilating device.
Please show your work.
Prove to me that all NAT won't pass packets not addressed directly to it. Show your work. You are making assumptions about how the NAT is designed. Many NATs only take packets addressed to particular address ranges and process them though the state tables. All the rest of the packets are treated as normal traffic which may or may not be forwarded depending apon the way the base platform is configured which is usually as a router. Many NAT's will honour LSR. Unless you know the internals of a NAT you cannot say whether it fails open or closed. Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit but if it is a targeted attack then yes you can expect to see LSR based attacks which depending apon how the NAT is built may pass through it without even being noticed. Now can we put to bed that NAT provides any real security. If you want security add and configure a firewall. That firewall can be in the same box as the NAT. It can use the same state tables as the NAT but it is the firewall, not the NAT functionality, that provides the protection. Mark
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.co m Designer The Things I Think RFC 210 0 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI I St Petersburg FL USA http://photo.imageinc.us +1 727 647 127 4
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, 2011-11-16 at 12:20 +1100, Mark Andrews wrote:
You are making assumptions about how the NAT is designed. [...] Unless you know the internals of a NAT you cannot say whether it fails open or closed.
Indeed not! From 2010, during an identical discussion: http://seclists.org/nanog/2010/Apr/1166 To me, "fail" means that a system stops doing what it was designed to do. The results are by definition undefined. Others seem to think that "fail" means a kind of default.
it is actually feasible to probe through a NAT using LSR.
What's LSR in this context? Loose source routing, I'm guessing. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
On Nov 15, 2011, at 6:07 PM, Karl Auer wrote:
On Wed, 2011-11-16 at 12:20 +1100, Mark Andrews wrote:
You are making assumptions about how the NAT is designed. [...] Unless you know the internals of a NAT you cannot say whether it fails open or closed.
Indeed not!
From 2010, during an identical discussion:
http://seclists.org/nanog/2010/Apr/1166
To me, "fail" means that a system stops doing what it was designed to do. The results are by definition undefined. Others seem to think that "fail" means a kind of default.
Red herring alert. Fact, any given system has failure modes that are more common and failure modes that are less common. Sure, your car can fail by having the engine explode. However, this is nowhere near as common as having your car fail due to a flat tire or a clogged fuel filter. Arguing that flat tires and clogged fuel filters are some form of default is absurd, but, when discussing automotive failures, the discussion will naturally focus more on these failures than on engine explosions. Such has been the case here. The most common failure modes for firewalls are failures due to misconfiguration and/or failures due to loss of configuration information. Some misconfigurations are more common than others. A proper firewall will address most of these failures by no longer forwarding packets. In this case, a router with NAT is slightly more likely to fail closed than a router without NAT. However, a firewall without NAT is more likely to fail closed than a router with or without NAT and equally likely to a firewall with NAT. In other words, NAT doesn't really improve anything, but, the difference between the common failure modes of a firewall vs. a router are worthy of consideration. The infinitesimal advantage of NAT if you use a router instead of a firewall to perform the duties of a firewall is dramatically overshadowed by the costs and damage done by NAT. OTOH, routers, being designed primarily to forward packets and having security appliance features added as a secondary capability will, in many cases, address most of these failures by passing packets which would not be permitted if properly configured and/or functioning. Yes, they are identical and NAT makes no meaningful difference to the chances that undesired packets will be forwarded in the event of a catastrophic failure outside of these more common failure modes. Owen
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
In this case, a router with NAT is slightly more likely to fail closed than a router without NAT.
"Slightly"? Continuing to assume here, as we have been, that the network behind a NAT is *unroutable*, then a NAT router has, IME, *many* more obvious possible failure modes which will make the internal network inaccessible from outside than modes which cause the opposite. If you're an attacker, targeting a behind-NAT box from the outside, then if the NAT's working, you can hit directly any ports that are forwarded to it. If not, then you have to a) know the private IP of the box and b) be able to get packets to the last upstream hop with source routing on them and c) the box has to have failed (or been configured or built) in such a way as to *listen* to source-routing. Those layers may have varying thicknesses, but there *are* at least 3 more of them, *on top of* "did it fail in a way where it's listening at all?".
However, a firewall without NAT is more likely to fail closed than a router with or without NAT and equally likely to a firewall with NAT.
If it's a firewall that meets your definition of the word, as opposed to, say, a shorewall box, a smoothwall box, a pf box, or any of the other 3 or 4 dozen packaged linux based firewall routers of which there are *lots* out there. Probably the most common failure more on those is "iptables accidentally cleared; box routes all packets". That's one failure to get to that point, insted of 2, 3 or 4. And since it's human-based a lot of the time, it's probably even more likely.
In other words, NAT doesn't really improve anything, but, the difference between the common failure modes of a firewall vs. a router are worthy of consideration. The infinitesimal advantage of NAT if you use a router instead of a firewall to perform the duties of a firewall is dramatically overshadowed by the costs and damage done by NAT.
Costs already sunk, IME. Damage is a question-begging term here.
OTOH, routers, being designed primarily to forward packets and having security appliance features added as a secondary capability will, in many cases, address most of these failures by passing packets which would not be permitted if properly configured and/or functioning.
Yup. What I've been saying (or implying) right along. So, in networks, or in seats, take your pick, does anyone have any deployment numbers on router-based firewalls vs the other sort, whatever we're calling them?
Yes, they are identical and NAT makes no meaningful difference to the chances that undesired packets will be forwarded in the event of a catastrophic failure outside of these more common failure modes.
I guess we're going to have to agree to disagree here; our respective clients will decide what their opinions on that are. Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
Can't believe this is still going on. ;-) NAT does not provide security; it provides utility. It is useful in many situations, though. If you are limited in the amount of public IP space you have, then NAT is one solution to that. If you want to have a backup connection to the Internet, but don't want to involve your ISP, or your ISP won't let you talk BGP with them (often for good reason), then NAT can be a solution to that as well. IPv6 doesn't have NAT yet, because NAT has a lot of issues. We think we can do better. The current momentum is behind Network Prefix Translation (NPT); which rather than re-writing addresses and ports, rewrites only the network segment of an address, leaving the host segment unchanged. This is stateless translation and can be implemented very efficiently to provide utility without limiting performance in a meaningful way. It will likely be the way that most small networks get service from more than one provider as IPv6 adoption grows (predictable internal addresses, independent from provide addressing changes, etc.) Like NAT, though, it doesn't provide security. Stateful Packet Inspection (SPI) provides some level of security; and most NAT devices include an SPI firewall, as state tracking is already a requirement for NAT to function. There is no requirement that SPI to use NAT, though. For the majority of scenarios the failure mode for a firewall running NAT with private IP address space, and the failure mode for a firewall not performing NAT, are identical; except that the extra overhead and complexity required by NAT can actually mean a higher failure rate in some cases. It's an absurd generalization (which is not based in fact) that a NAT firewall will fail closed, and a firewall not using NAT will fail open. The problem with the article in the OP -- the thing that rubs most of this list in the wrong way -- is that it's yet another self-proclaimed expert telling people that private IP addresses provide security. They do not. Most on this list have seen time and time again compromised networks that sit behind NAT. Almost every time it turns out to be that the user though they were protected by NAT, and proceeded to not address security concerns internally. Examples included disabling host firewalls, not updating systems, and not monitoring activity. Worse they then proceed to ask you how to find out which host is compromise because the report only mentioned the IP of their firewall. I would go as far as to argue that the false sense of security provided by NAT is more dangerous than any current threat that NAT alone would prevent. Firewalls are still a necessary tool; but they don't really provide the security that people associate with them. It isn't a magic box; and short of blocking all traffic, they really don't provide comprehensive security. The article in the OP not only makes it sound like a magic box; but goes on to say that the magic box isn't what keeps you safe -- it's the fact that your IP is "private". So the idea that the answer for a nuclear power plant is to use private IP addresses and that will address all their security concerns is just frustrating and ridiculous. The author tried to simplify things so much that the information become incorrect somewhere along the way. I for one hope that our nuclear power plants are protected by more than NAT. I don't care if they don't use NAT. Just as long as they address security. On Wed, Nov 16, 2011 at 1:58 PM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
In this case, a router with NAT is slightly more likely to fail closed than a router without NAT.
"Slightly"? Continuing to assume here, as we have been, that the network behind a NAT is *unroutable*, then a NAT router has, IME, *many* more obvious possible failure modes which will make the internal network inaccessible from outside than modes which cause the opposite.
If you're an attacker, targeting a behind-NAT box from the outside, then if the NAT's working, you can hit directly any ports that are forwarded to it.
If not, then you have to a) know the private IP of the box and b) be able to get packets to the last upstream hop with source routing on them and c) the box has to have failed (or been configured or built) in such a way as to *listen* to source-routing. Those layers may have varying thicknesses, but there *are* at least 3 more of them, *on top of* "did it fail in a way where it's listening at all?".
However, a firewall without NAT is more likely to fail closed than a router with or without NAT and equally likely to a firewall with NAT.
If it's a firewall that meets your definition of the word, as opposed to, say, a shorewall box, a smoothwall box, a pf box, or any of the other 3 or 4 dozen packaged linux based firewall routers of which there are *lots* out there. Probably the most common failure more on those is "iptables accidentally cleared; box routes all packets".
That's one failure to get to that point, insted of 2, 3 or 4. And since it's human-based a lot of the time, it's probably even more likely.
In other words, NAT doesn't really improve anything, but, the difference between the common failure modes of a firewall vs. a router are worthy of consideration. The infinitesimal advantage of NAT if you use a router instead of a firewall to perform the duties of a firewall is dramatically overshadowed by the costs and damage done by NAT.
Costs already sunk, IME. Damage is a question-begging term here.
OTOH, routers, being designed primarily to forward packets and having security appliance features added as a secondary capability will, in many cases, address most of these failures by passing packets which would not be permitted if properly configured and/or functioning.
Yup. What I've been saying (or implying) right along. So, in networks, or in seats, take your pick, does anyone have any deployment numbers on router-based firewalls vs the other sort, whatever we're calling them?
Yes, they are identical and NAT makes no meaningful difference to the chances that undesired packets will be forwarded in the event of a catastrophic failure outside of these more common failure modes.
I guess we're going to have to agree to disagree here; our respective clients will decide what their opinions on that are.
Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Wed, Nov 16, 2011 at 20:38, Ray Soucy <rps@maine.edu> wrote:
I would go as far as to argue that the false sense of security provided by NAT is more dangerous than any current threat that NAT alone would prevent.
Agreed, and I don't think that's going far at all. My opinion is _both_ stateful firewalls and NATs have been responsible for providing cover for those who fail to secure their endpoints. Yes, dropping a choke point in front of X hosts is X times easier than securing the X hosts. No, it didn't secure X hosts. "Outside is dangerous, inside is trusted" is the root of much current evil. Breaking end-to-end and encouraging everything that needs it to jump through ugly hoops such as UDP NAT traversal or carrying all sorts of non-HTTP over 80 and 443 has made it harder to secure networks, not easier. Cheers, Dave Hart
On Nov 16, 2011, at 10:58 AM, Jay Ashworth wrote:
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
In this case, a router with NAT is slightly more likely to fail closed than a router without NAT.
"Slightly"? Continuing to assume here, as we have been, that the network behind a NAT is *unroutable*, then a NAT router has, IME, *many* more obvious possible failure modes which will make the internal network inaccessible from outside than modes which cause the opposite.
What matters is not the number of failure modes, but, the probability of occurrence. Additionally, I have no reason to assume as you have been that private addresses behind the NAT are for some reason "unroutable". I would argue that this (sometimes) fallacious assumption may be one of the key dependencies in your argument.
If you're an attacker, targeting a behind-NAT box from the outside, then if the NAT's working, you can hit directly any ports that are forwarded to it.
Correct.
If not, then you have to a) know the private IP of the box and b) be able to get packets to the last upstream hop with source routing on them and c) the box has to have failed (or been configured or built) in such a way as to *listen* to source-routing. Those layers may have varying thicknesses, but there *are* at least 3 more of them, *on top of* "did it fail in a way where it's listening at all?".
Incorrect. a) I have to either know, detect, or guess at the private IP of the box (maybe). b) I have to get packets to the last upstream hop. Source routing is just one tool that could be used to do so. There are other possibilities. c) The box doesn't have to listen to source routing. It has to accept packets destined to it's exterior MAC address with an interior IP address (or other address that causes it to meaningfully forward things inside).
However, a firewall without NAT is more likely to fail closed than a router with or without NAT and equally likely to a firewall with NAT.
If it's a firewall that meets your definition of the word, as opposed to, say, a shorewall box, a smoothwall box, a pf box, or any of the other 3 or 4 dozen packaged linux based firewall routers of which there are *lots* out there. Probably the most common failure more on those is "iptables accidentally cleared; box routes all packets".
Actually, if you configure iptables on those boxes correctly and turn off ip forwarding (requiring instead that iptables actually do the forwarding, which is possible), clearing iptables does not cause it to forward all packets.
That's one failure to get to that point, insted of 2, 3 or 4. And since it's human-based a lot of the time, it's probably even more likely.
I would argue it's at least two. First you had to configure iptables and/or the OS incorrectly in order for clearing iptables to cause that problem. Then you had to clear iptables.
In other words, NAT doesn't really improve anything, but, the difference between the common failure modes of a firewall vs. a router are worthy of consideration. The infinitesimal advantage of NAT if you use a router instead of a firewall to perform the duties of a firewall is dramatically overshadowed by the costs and damage done by NAT.
Costs already sunk, IME. Damage is a question-begging term here.
For IPv4, that argument can perhaps be made. Since the question was originally about the desirability of bringing NAT forward into IPv6, I don't think that argument actually holds water.
OTOH, routers, being designed primarily to forward packets and having security appliance features added as a secondary capability will, in many cases, address most of these failures by passing packets which would not be permitted if properly configured and/or functioning.
Yup. What I've been saying (or implying) right along. So, in networks, or in seats, take your pick, does anyone have any deployment numbers on router-based firewalls vs the other sort, whatever we're calling them?
I have no idea. I think based on my observations at a variety of companies it is a relatively even split, but, I will point out that the companies that pay any attention to security at all do, by and large, use firewalls (my definition) rather than attempt to press routers into that role. In fact, many use both a router with ACLs and/or stateful inspection at the ISP handoff in addition to a firewall behind it before you get to anything not intended to be on the public internet.
Yes, they are identical and NAT makes no meaningful difference to the chances that undesired packets will be forwarded in the event of a catastrophic failure outside of these more common failure modes.
I guess we're going to have to agree to disagree here; our respective clients will decide what their opinions on that are.
I suspect so. Owen
On Tue, Nov 15, 2011 at 8:20 PM, Mark Andrews <marka@isc.org> wrote:
Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit
Mark, My car can be slim-jimmed. Yet the lock is sufficiently operative in the security process that the two times the vehicle has been broken in to the vagrant put a rock through the window instead of jimmying the lock. That's what it MEANS when you say that there's lower hanging fruit to be found elsewhere. It means that the feature you're describing is operative in the process of obstructing an attacker. As an aside to the debate, I boldly suggest that any firewall vendor which actually implements LSR or any of the IP source route functionality anywhere in their code deserves to be tarred and feathered. The security implications of source routing have been long understood. Code which implements source routing has no business existing in a commercial firewall product where it could accidentally be called. Please, by all means, take this opportunity to out any such errors which you can document. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In message <CAP-guGXXM_Dci6QrzR2AQmFOnKh0AFs2XdVVY-H-MPDXcRrLBw@mail.gmail.com> , William Herrin writes:
On Tue, Nov 15, 2011 at 8:20 PM, Mark Andrews <marka@isc.org> wrote:
Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit
Mark,
My car can be slim-jimmed. Yet the lock is sufficiently operative in the security process that the two times the vehicle has been broken in to the vagrant put a rock through the window instead of jimmying the lock.
That's what it MEANS when you say that there's lower hanging fruit to be found elsewhere. It means that the feature you're describing is operative in the process of obstructing an attacker.
As an aside to the debate, I boldly suggest that any firewall vendor which actually implements LSR or any of the IP source route functionality anywhere in their code deserves to be tarred and feathered. The security implications of source routing have been long understood. Code which implements source routing has no business existing in a commercial firewall product where it could accidentally be called. Please, by all means, take this opportunity to out any such errors which you can document.
Indeed. A NAT mangles packets. A firewall provides protection. You can combine the two but expecting one to do the job of the other is just wrong and doesn't work.
Regards, Bill Herrin
--=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
In message <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
If your firewall is not working, it should not be passing packets.
And of course, things always fail just the way we want them to.
Your stateful firewall is no more likely to fail open than your header-mutilating device.
Please show your work.
Prove to me that all NAT won't pass packets not addressed directly to it. Show your work.
I did not *assert* that. So I don't have to prove that. What I *asserted* was that inbound 1:N DNAT *reduces the probability of an attacker being able to target a specific inbound attack to a specific computer*. QED.
You are making assumptions about how the NAT is designed. Many NATs only take packets addressed to particular address ranges and process them though the state tables. All the rest of the packets are treated as normal traffic which may or may not be forwarded depending apon the way the base platform is configured which is usually as a router. Many NAT's will honour LSR.
As someone pointed out elsewhere, that's bad, but it's bad whether the box does NAT or not; even if the internal network is unrouted public space, that would be troublesome.
Unless you know the internals of a NAT you cannot say whether it fails open or closed.
It's probably impossible to determine whether any box's response to any failure will be pass or drop, with any reliability. All you can figure is probabilities.
Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit but if it is a targeted attack then yes you can expect to see LSR based attacks which depending apon how the NAT is built may pass through it without even being noticed.
Someone else has already addressed "low-hanging fruit", so I won't. I do concur, though: if you have specific examples of boxes which, as you allege, respect LSR to 1918 internal addresses, please, name and shame.
Now can we put to bed that NAT provides any real security. If you want security add and configure a firewall. That firewall can be in the same box as the NAT. It can use the same state tables as the NAT but it is the firewall, not the NAT functionality, that provides the protection.
Nope; I'm afraid we still can't. As long as you continue to strawman that I/we are even *alleging* that NAT "provides" security (rather than "contributing" to it, we're just going to keep talking past each other, Mark. As long as you keep defining protection as "one thing in one place", I'll keep assuming you're flapping your jaws to dry your teeth. ("provides *the* protection") Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
In message <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
In message <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
If your firewall is not working, it should not be passing packets.
And of course, things always fail just the way we want them to.
Your stateful firewall is no more likely to fail open than your header-mutilating device.
Please show your work.
Prove to me that all NAT won't pass packets not addressed directly to it. Show your work.
I did not *assert* that. So I don't have to prove that.
What I *asserted* was that inbound 1:N DNAT *reduces the probability of an attacker being able to target a specific inbound attack to a specific computer*. QED.
You are making assumptions about how the NAT is designed. Many NATs only take packets addressed to particular address ranges and process them though the state tables. All the rest of the packets are treated as normal traffic which may or may not be forwarded depending apon the way the base platform is configured which is usually as a router. Many NAT's will honour LSR.
As someone pointed out elsewhere, that's bad, but it's bad whether the box does NAT or not; even if the internal network is unrouted public space, that would be troublesome.
Actually LSR is not bad in and of itself. The actual problem was badly designed firewall code that failed properly examine the LSR option. Rather than fix the firewall code people choose to drop packets with LSR options.
Unless you know the internals of a NAT you cannot say whether it fails open or closed.
It's probably impossible to determine whether any box's response to any failure will be pass or drop, with any reliability. All you can figure is probabilities.
Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit but if it is a targeted attack then yes you can expect to see LSR based attacks which depending apon how the NAT is built may pass through it without even being noticed.
Someone else has already addressed "low-hanging fruit", so I won't. I do concur, though: if you have specific examples of boxes which, as you allege, respect LSR to 1918 internal addresses, please, name and shame.
Why do they need to be "named and shamed"? They are NOT firewalls. It is not their job to block LSR traffic. The fact that you think NATs should be doing this is yet another indication that you don't understand the difference between a NAT and a firewall.
Now can we put to bed that NAT provides any real security. If you want security add and configure a firewall. That firewall can be in the same box as the NAT. It can use the same state tables as the NAT but it is the firewall, not the NAT functionality, that provides the protection.
Nope; I'm afraid we still can't. As long as you continue to strawman that I/we are even *alleging* that NAT "provides" security (rather than "contributing" to it, we're just going to keep talking past each other, Mark.
As long as you keep defining protection as "one thing in one place", I'll keep assuming you're flapping your jaws to dry your teeth. ("provides *the* protection")
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.co m Designer The Things I Think RFC 210 0 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI I St Petersburg FL USA http://photo.imageinc.us +1 727 647 127 4
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Nov 15, 2011, at 7:08 PM, Jay Ashworth wrote:
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
In message <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
If your firewall is not working, it should not be passing packets.
And of course, things always fail just the way we want them to.
Your stateful firewall is no more likely to fail open than your header-mutilating device.
Please show your work.
Prove to me that all NAT won't pass packets not addressed directly to it. Show your work.
I did not *assert* that. So I don't have to prove that.
What I *asserted* was that inbound 1:N DNAT *reduces the probability of an attacker being able to target a specific inbound attack to a specific computer*. QED.
No, it is not QED... You have not proven that it reduces said probability vs. a stateful firewall without header mutilation. So, again, please show your work and prove your assertion or accept that your assertion is no more or less credible than the assertion that it does not.
Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit but if it is a targeted attack then yes you can expect to see LSR based attacks which depending apon how the NAT is built may pass through it without even being noticed.
Someone else has already addressed "low-hanging fruit", so I won't. I do concur, though: if you have specific examples of boxes which, as you allege, respect LSR to 1918 internal addresses, please, name and shame.
He probably likes his job too much to do that. I don't know the specifics or the internals of specific boxes, so, I can't point you at one, but, I will point out that Mark works for a manufacturer of MANY of the worlds cheapest NAT gateways and given the other code quality issues observed in these brand-L products in the wild, universal lack of such NAT vulnerabilities in them would truly come as a surprise.
Now can we put to bed that NAT provides any real security. If you want security add and configure a firewall. That firewall can be in the same box as the NAT. It can use the same state tables as the NAT but it is the firewall, not the NAT functionality, that provides the protection.
Nope; I'm afraid we still can't. As long as you continue to strawman that I/we are even *alleging* that NAT "provides" security (rather than "contributing" to it, we're just going to keep talking past each other, Mark.
NAT neither provides nor contributes to security. NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc. Owen
"NAT neither provides nor contributes to security. NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc." Respectfully, I'm really struggling with this. Sentence one is an opinion. It's all a matter of the designers viewpoint. Step 1 in most security books is to not reveal ANYTHING to ANYONE that you don't have to. Taken to the extreme, that could include your network layout and native addressing schema. Sentence two is wrong. If employing NAT breaks your audit trail or interferes with your forensics then you need to address your audit/forensics method. We have correlation engines that track the "state" of a conversation (defined as multiple TCP sessions in series) thru our secure architecture. We can 100% tell you the public IP of a session whether it's the destination or source and whether it's been NATted once or three or four times. We have cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow the application layer to manage the proper source of the client as well. These are proven technologies that have been around for a decade. They have stood up in court and been used against bad guys w/o question. While I agree that this is an extra layer of complexity, the focus is to make in manageable. I'm not saying you are flat out wrong Owen. I am saying that it's all a matter of your viewpoint. -Hammer- "I was a normal American nerd" -Jack Herer On 11/16/2011 10:44 AM, Owen DeLong wrote:
NAT neither provides nor contributes to security.
NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc.
On Nov 16, 2011, at 9:13 AM, -Hammer- wrote:
"NAT neither provides nor contributes to security. NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc."
Respectfully, I'm really struggling with this. Sentence one is an opinion. It's all a matter of the designers viewpoint. Step 1 in most security books is to not reveal ANYTHING to ANYONE that you don't have to. Taken to the extreme, that could include your network layout and native addressing schema.
Actually, the first rule of security in many texts I have read is "Security through obscurity is no security.". While you don't reveal anything to anyone that you don't have to, it is arguable that you need to reveal enough for security threats (abusers, attackers, etc.) to be identified as part of being a good network citizen. As with most things, taken to extreme, you reach a point of reductio ad absurdum.
Sentence two is wrong. If employing NAT breaks your audit trail or interferes with your forensics then you need to address your audit/forensics method. We have correlation engines that track the "state" of a conversation (defined as multiple TCP sessions in series) thru our secure architecture. We can 100% tell you the public IP of a session whether it's the destination or source and whether it's been NATted once or three or four times. We have cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow the application layer to manage the proper source of the client as well. These are proven technologies that have been around for a decade. They have stood up in court and been used against bad guys w/o question. While I agree that this is an extra layer of complexity, the focus is to make in manageable.
It may not break your own, but, it certainly breaks that of your user's victims. Most people don't store port information in their webserver logs, for example. They may not have that data to come back at you to identify the internal host in question. All they have is the public IP address of your NAT box and the date/time the event occurred. Ignoring for a moment the fact that if your clocks aren't perfectly synchronized, that may not necessarily provide the needed identification, even if they do have the port number, without the source port number from your side, they don't have enough for you to find the attacker.
I'm not saying you are flat out wrong Owen. I am saying that it's all a matter of your viewpoint.
I think in considering this in general, all viewpoints must be considered. From the global viewpoint, overall, I think that the case is well made that the security negatives associated with NAT and the cost/impact imposed on everyone, including those outside of the NAT- using organization far outweigh the (very minuscule) possible positives that have been argued so far. This leaves one and only one key benefit to NAT, which is address sharing (conservation). Since we don't have a shortage of IPv6 addresses, bringing a technology forward into IPv6 solely for the purpose of address sharing (conservation) makes little sense. Owen
On Wed, Nov 16, 2011 at 3:44 PM, Owen DeLong <owen@delong.com> wrote:
Actually, the first rule of security in many texts I have read is "Security through obscurity is no security."
Relevant: http://penny-arcade.com/comic/2003/03/21 :-) -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Well argued Owen. I can see both sides. -Hammer- "I was a normal American nerd" -Jack Herer On 11/16/2011 02:44 PM, Owen DeLong wrote:
On Nov 16, 2011, at 9:13 AM, -Hammer- wrote:
"NAT neither provides nor contributes to security. NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc."
Respectfully, I'm really struggling with this. Sentence one is an opinion. It's all a matter of the designers viewpoint. Step 1 in most security books is to not reveal ANYTHING to ANYONE that you don't have to. Taken to the extreme, that could include your network layout and native addressing schema.
Actually, the first rule of security in many texts I have read is "Security through obscurity is no security.". While you don't reveal anything to anyone that you don't have to, it is arguable that you need to reveal enough for security threats (abusers, attackers, etc.) to be identified as part of being a good network citizen. As with most things, taken to extreme, you reach a point of reductio ad absurdum.
Sentence two is wrong. If employing NAT breaks your audit trail or interferes with your forensics then you need to address your audit/forensics method. We have correlation engines that track the "state" of a conversation (defined as multiple TCP sessions in series) thru our secure architecture. We can 100% tell you the public IP of a session whether it's the destination or source and whether it's been NATted once or three or four times. We have cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow the application layer to manage the proper source of the client as well. These are proven technologies that have been around for a decade. They have stood up in court and been used against bad guys w/o question. While I agree that this is an extra layer of complexity, the focus is to make in manageable.
It may not break your own, but, it certainly breaks that of your user's victims.
Most people don't store port information in their webserver logs, for example. They may not have that data to come back at you to identify the internal host in question. All they have is the public IP address of your NAT box and the date/time the event occurred.
Ignoring for a moment the fact that if your clocks aren't perfectly synchronized, that may not necessarily provide the needed identification, even if they do have the port number, without the source port number from your side, they don't have enough for you to find the attacker.
I'm not saying you are flat out wrong Owen. I am saying that it's all a matter of your viewpoint.
I think in considering this in general, all viewpoints must be considered. From the global viewpoint, overall, I think that the case is well made that the security negatives associated with NAT and the cost/impact imposed on everyone, including those outside of the NAT- using organization far outweigh the (very minuscule) possible positives that have been argued so far.
This leaves one and only one key benefit to NAT, which is address sharing (conservation). Since we don't have a shortage of IPv6 addresses, bringing a technology forward into IPv6 solely for the purpose of address sharing (conservation) makes little sense.
Owen
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
If your firewall is not working, it should not be passing packets.
Yes; your arguments all seem to depend on that property being true. But we call it a *failure* for a reason, Owen. What the probability is of a firewall failing in such a fashion as to *stop filtering, but still pass packets* depends -- as you have pointed out -- entirely on its design. As *I* have pointed out, not all firewalls are created equal, and there are a helluva a lot of them out there for which this desirable property *simply is not true*. Sticking your head in the sand on this point is not especially productive. Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
Sent from my iPad On Nov 15, 2011, at 4:10 PM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
If your firewall is not working, it should not be passing packets.
Yes; your arguments all seem to depend on that property being true.
But we call it a *failure* for a reason, Owen.
If your firewall has failed to such an extent, all bets are off about what it does or does not pas regardless of whether or not it mutilates the headers.
What the probability is of a firewall failing in such a fashion as to *stop filtering, but still pass packets* depends -- as you have pointed out -- entirely on its design.
As *I* have pointed out, not all firewalls are created equal, and there are a helluva a lot of them out there for which this desirable property *simply is not true*.
Then I would, by definition call them routers, not firewalls.
Sticking your head in the sand on this point is not especially productive.
I'm not sticking my head in the sand about anything. I am pointing out that mutilating the packet header only reduces security. It does not improve it. Owen
On Tue, Nov 15, 2011 at 5:57 AM, Leigh Porter <leigh.porter@ukbroadband.com> wrote:
As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.
This is a myth; just like NAT provides security is a myth. It doesn't matter if your firewall performs NAT or not; if it fails, traffic will more than likely stop flowing. The conditions for a non-NAT firewall to fail open are very specific. You often need to engineer it to have that functionality. Either type of firewall system can be designed to fail open or fail closed. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
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.
---- Original Message -----
From: "Doug Barton" <dougb@dougbarton.us>
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 jra@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
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
On Sun, Nov 13, 2011 at 12:13 PM, William Herrin <bill@herrin.us> wrote:
On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi <bonomi@mail.r-bonomi.com> wrote:
On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis@packetnexus.com> wrote;
http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-u...
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 <jlewis@packetnexus.com> 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 ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Sun Nov 13 14:15:38 2011 From: William Herrin <bill@herrin.us> 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 <bonomi@mail.r-bonomi.com> wrote:
On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis@packetnexus.com> wrote;
http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-u...
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"
----- Original Message -----
From: "Robert Bonomi" <bonomi@mail.r-bonomi.com>
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 jra@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
William Herrin wrote:
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
Isn't that the case with IPv6? That the IP is addressable from any host in the entire (IPv6) world? And isn't that considered a good thing? I don't think that being addressable from anywhere is a security hole in and of itself. It's how you implement and (mis)configure your firewall and related things that is the (potential) security hole. Whether the IP is world addressable or not
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.
Personally I prefer car analogies when it comes to explaining (complex) computer matters. ;-) Greetings, Jeroen -- Earthquake Magnitude: 5.2 Date: Monday, November 14, 2011 22:08:15 UTC Location: eastern Turkey Latitude: 38.6644; Longitude: 43.0993 Depth: 10.00 km
On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
William Herrin wrote:
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
Isn't that the case with IPv6? That the IP is addressable from any host in the entire (IPv6) world? And isn't that considered a good thing?
Hi Jeroen, Yes, according to almost every application developer asked it's a good thing. Me? I'm not so sure. Historically, enterprises moved away from global addressability even when IP addresses were free, *before* address scarcity became an issue. There's a lesson in there somewhere and I'm not convinced it's that "they were dumb."
I don't think that being addressable from anywhere is a security hole in and of itself. It's how you implement and (mis)configure your firewall and related things that is the (potential) security hole. Whether the IP is world addressable or not
I agree. That your computer is globally addressable is NOT a security hole. It does not directly or indirectly make you vulnerable to attack. But the inverse doesn't follow. That your computer is not globally addressable ADDS one layer of security in a process you hope has enough layers to prevent an attack from penetrating. And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 11/15/11 09:15, William Herrin wrote:
On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart<jeroen@mompl.net> wrote:
William Herrin wrote:
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
Isn't that the case with IPv6? That the IP is addressable from any host in the entire (IPv6) world? And isn't that considered a good thing?
Hi Jeroen,
Yes, according to almost every application developer asked it's a good thing.
Me? I'm not so sure. Historically, enterprises moved away from global addressability even when IP addresses were free, *before* address scarcity became an issue. There's a lesson in there somewhere and I'm not convinced it's that "they were dumb."
And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached.
Hi Bill: I am not sure if the enterprises were dumb for doing private address space, but I have a few hints that they might have been. (E.g. there's a *lot* of RFC1918 space out there. Why does the overwhelming majority use 192.168.0.0/24 or 192.168.1.0/24 or 10.0.0.0/24?) But what definitely *is* dumb is are the following two axioms, at least one of which is expressed in the article: 1. You need NAT/private ip address space to have security. 2. Once you have NAT/private ip address space, you have security. On the surface those axioms clearly violate your notion of security layers and they clearly violate common sense. Yet we find them lurking just beneath the surface, including in the debate about the utility of IPv6 ULAs, as well as in the article. michael
On Nov 15, 2011, at 9:15 AM, William Herrin wrote:
On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
William Herrin wrote:
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
Isn't that the case with IPv6? That the IP is addressable from any host in the entire (IPv6) world? And isn't that considered a good thing?
Hi Jeroen,
Yes, according to almost every application developer asked it's a good thing.
Me? I'm not so sure. Historically, enterprises moved away from global addressability even when IP addresses were free, *before* address scarcity became an issue. There's a lesson in there somewhere and I'm not convinced it's that "they were dumb."
I'm not sure how you can make that case since RFC-1918 and it's predecessors RFC-1597 and RFC-1627 came after address scarcity was already a known problem. The oldest of these three (RFC 1597 is dated March, 1994. IPv6 development (spurred by the fact that IPv4 addresses were becoming scarce) started in earnest somewhere between 1990-1992 depending on who you ask). If your initial assertion were true, then, there might be some sort of lesson from your follow-on statement. In this case, however, since the assertion is false, the follow-on lesson is likely just that some enterprises jumped on the NAT bandwagon sooner than others in pursuit of certain coolness or other convenience factors unrelated to delivering a good internet experience to their end users. Also, since the internet was such a radically different thing back then as compared to what it is now, I'm not sure that any such lesson would inherently be useful in the modern age.
I don't think that being addressable from anywhere is a security hole in and of itself. It's how you implement and (mis)configure your firewall and related things that is the (potential) security hole. Whether the IP is world addressable or not
I agree. That your computer is globally addressable is NOT a security hole. It does not directly or indirectly make you vulnerable to attack. But the inverse doesn't follow.
That your computer is not globally addressable ADDS one layer of security in a process you hope has enough layers to prevent an attack from penetrating.
This statement is absurd. I can have a globally unique address on a system that does not have any external connectivity. The fact that the address is global in scope does not in any way make that system any less secure than a system which uses an address that is not globally unique. Addressability is not reachability. Addressability has nothing to do with security. Reachability has a little bit to do with security, but, in any sane modern implementation, not a lot.
And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached.
This is the only thing you've said here that I can actually agree with. Given the penalties associated with non-global addressing and the rewards available from global addressing combined with the absolutely minimal protection afforded by non-global addressing, I find it hard to imagine a scenario in which the benefits would ever outweigh the costs. Owen
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
That your computer is not globally addressable ADDS one layer of security in a process you hope has enough layers to prevent an attack from penetrating.
And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached.
This is precisely the point I've been trying to make, and it ties in to my observations in response in the SCADA thread: not only does the number of layers matter, so does their "thickness". Certainly, if you're trying to "air-gap" a SCADA network to protect it from attack, then you are admitting a certain degree of vulnerability if your circuit passes through any sort of transport multiplexer, like a DACS, as that's a place an attacker could reconfigure to take control of your traffic. But mounting *that* attack requires insider knowledge of 4 or 5 layers of extra information which will be necessary to exploit such an attack. My estimation is that that makes that layer of your defense in depth "thicker" than some other layers might be. Those who think NAT provides no security seem still to be mounting the strawman that we think it *provides* security, rather than merely contributing some bits thereto... Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
In message <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com>, Jay Ashworth write s:
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
That your computer is not globally addressable ADDS one layer of security in a process you hope has enough layers to prevent an attack from penetrating.
And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached.
This is precisely the point I've been trying to make, and it ties in to my observations in response in the SCADA thread: not only does the number of layers matter, so does their "thickness". Certainly, if you're trying to "air-gap" a SCADA network to protect it from attack, then you are admitting a certain degree of vulnerability if your circuit passes through any sort of transport multiplexer, like a DACS, as that's a place an attacker could reconfigure to take control of your traffic.
But mounting *that* attack requires insider knowledge of 4 or 5 layers of extra information which will be necessary to exploit such an attack.
My estimation is that that makes that layer of your defense in depth "thicker" than some other layers might be.
Those who think NAT provides no security seem still to be mounting the strawman that we think it *provides* security, rather than merely contributing some bits thereto...
Most of us actually think that what ever benefit it adds over a firewall is miniscule compared to its negative consequences and once the cost benefit analysis is done that it is not worth it. Remember the cost of NAT is not solely borne by the entity deploying the NAT. If it was there would be little debate here. The cost of you deploying NAT is borne by everyone of us. It add a little bit to the cost of every router. If you want to use unroutable addresses then use a bastion host / proxy. Don't expect to be able to open a TCP socket and have it connect to something on the outside. Do it right or don't do it at all. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews <marka@isc.org> wrote:
If you want to use unroutable addresses then use a bastion host / proxy. Don't expect to be able to open a TCP socket and have it connect to something on the outside. Do it right or don't do it at all.
Mark, What is a modern NAT but a bastion host proxy for which application compatibility has been maximized? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Nov 15, 2011, at 2:01 PM, William Herrin wrote:
On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews <marka@isc.org> wrote:
If you want to use unroutable addresses then use a bastion host / proxy. Don't expect to be able to open a TCP socket and have it connect to something on the outside. Do it right or don't do it at all.
Mark,
What is a modern NAT but a bastion host proxy for which application compatibility has been maximized?
It is a mechanism for header mutilation which creates additional costs in hardware (cost of routers), software (development of NAT traversal code in various applications, NAT software in some cases), security (NAT obfuscates audit trails and increases the difficulty and cost of event correlation, forensics, abuser identification, and attack source identification and mitigation, etc.). Owen
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, November 16, 2011 11:11 AM To: William Herrin Cc: NANOG Subject: Re: Have they stopped teaching Defense in Depth?
On Nov 15, 2011, at 2:01 PM, William Herrin wrote:
On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews <marka@isc.org> wrote:
If you want to use unroutable addresses then use a bastion host / proxy. Don't expect to be able to open a TCP socket and have it connect to something on the outside. Do it right or don't do it at all.
Mark,
What is a modern NAT but a bastion host proxy for which application compatibility has been maximized?
It is a mechanism for header mutilation which creates additional costs in hardware (cost of routers), software (development of NAT traversal code in various applications, NAT software in some cases), security (NAT obfuscates audit trails and increases the difficulty and cost of event correlation, forensics, abuser identification, and attack source identification and mitigation, etc.).
How is that any different than a proxy server, really? From the inside, your apps are either NAT aware or proxy aware, but either way, you're not directly exposed to the world and all your traffic comes from one place as far as the world is concerned. I live behind both (NAT at home; all external traffic of any type (assuming it's even allowed) is proxied at work), and both suck in different and exciting ways. Jamie
On Nov 16, 2011, at 8:20 AM, Jamie Bowden wrote:
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Wednesday, November 16, 2011 11:11 AM To: William Herrin Cc: NANOG Subject: Re: Have they stopped teaching Defense in Depth?
On Nov 15, 2011, at 2:01 PM, William Herrin wrote:
On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews <marka@isc.org> wrote:
If you want to use unroutable addresses then use a bastion host / proxy. Don't expect to be able to open a TCP socket and have it connect to something on the outside. Do it right or don't do it at all.
Mark,
What is a modern NAT but a bastion host proxy for which application compatibility has been maximized?
It is a mechanism for header mutilation which creates additional costs in hardware (cost of routers), software (development of NAT traversal code in various applications, NAT software in some cases), security (NAT obfuscates audit trails and increases the difficulty and cost of event correlation, forensics, abuser identification, and attack source identification and mitigation, etc.).
How is that any different than a proxy server, really? From the inside, your apps are either NAT aware or proxy aware, but either way, you're not directly exposed to the world and all your traffic comes from one place as far as the world is concerned. I live behind both (NAT at home; all external traffic of any type (assuming it's even allowed) is proxied at work), and both suck in different and exciting ways.
Jamie
You answered your own question... They suck in different ways. Owen
On Wed, Nov 16, 2011 at 11:11 AM, Owen DeLong <owen@delong.com> wrote:
On Nov 15, 2011, at 2:01 PM, William Herrin wrote:
On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews <marka@isc.org> wrote:
If you want to use unroutable addresses then use a bastion host / proxy.
What is a modern NAT but a bastion host proxy for which application compatibility has been maximized?
It is a mechanism for header mutilation which creates additional costs in hardware (cost of routers), software (development of NAT traversal code in various applications, NAT software in some cases), security (NAT obfuscates audit trails and increases the difficulty and cost of event correlation, forensics, abuser identification, and attack source identification and mitigation, etc.).
In other words, all of the things a proxy does but without sacrificing as many applications. -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Nov 16, 2011, at 8:43 AM, William Herrin wrote:
On Wed, Nov 16, 2011 at 11:11 AM, Owen DeLong <owen@delong.com> wrote:
On Nov 15, 2011, at 2:01 PM, William Herrin wrote:
On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews <marka@isc.org> wrote:
If you want to use unroutable addresses then use a bastion host / proxy.
What is a modern NAT but a bastion host proxy for which application compatibility has been maximized?
It is a mechanism for header mutilation which creates additional costs in hardware (cost of routers), software (development of NAT traversal code in various applications, NAT software in some cases), security (NAT obfuscates audit trails and increases the difficulty and cost of event correlation, forensics, abuser identification, and attack source identification and mitigation, etc.).
In other words, all of the things a proxy does but without sacrificing as many applications.
No, in the proxy case, the sessions internal and sessions external are separate and the proxy software ties them together. In the NAT case, the internal and external sessions are one and the same, but, the header is mutilated as part of the IP forwarding process. However, yes, as someone else pointed out, the key difference is that they suck in different ways. Owen
On Tue, Nov 15, 2011 at 3:16 PM, Jay Ashworth <jra@baylink.com> wrote:
You can seek layers from other sources but a shallow security process will tend to be easily breached. But mounting *that* attack requires insider knowledge of 4 or 5 layers of extra information which will be necessary to exploit such an attack.
My estimation is that that makes that layer of your defense in depth "thicker" than some other layers might be.
Security in depth is a proper approach, but NAT is not a security control, and NAT does not make the firewall defense "thicker" The maginot line was "thick". Before you can properly consider your layers of defense to have a certain thickness, you have to consider types of attack, and whether your changes actually make the layers they defeat any thicker. Now... what would you say is the most common way of defeating a properly implemented firewall? (1) The attack follows _allowed_ paths through the firewall, for example, the attack comes through a port forward that has been configured on the firewall with an ACL that is open too wide. Or, the attack is against a legitimate user's outbound connection, for example: a user behind the firewall connects to a web site, a vulnerability in their browser is exploited to install a trojan -- the trojan tunnels to the attacker over an outgoing port that is allowed on the firewall. And (2) The intruder compromises the firewall and gains control of it. In the case of (1), NAT does not add any "thickness" to the security model, the workstation behind the firewall has full knowledge of its own private IP addressing. The only way you will use NAT to effectively hide information is if the compromised machine is not privvy to the IP network addressing of the sensitive resources. In the case of (2), NAT does not add any thickness to the security model, because the attacker gains knowledge of the Firewall's entire configuration. This is a reason a network with truly sensitive resources where integrity is the greatest security objective should often have multiple separate Firewall units made by different manufacturers administered independently by different groups of security admins; an outer firewall in between the Internet and the DMZ, a second firewall in between the DMZ and the Internal network, and a third firewall in between the Internal network and say the SCADA control network. -- -JH
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
Or, the attack is against a legitimate user's outbound connection, for example: a user behind the firewall connects to a web site, a vulnerability in their browser is exploited to install a trojan -- the trojan tunnels to the attacker over an outgoing port that is allowed on the firewall.
Oh, certainly; I have lots of web browsers running on my servers. All The World Is Not A Workstation, guys. Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
-----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: 16 November 2011 13:38 To: NANOG Subject: Re: Have they stopped teaching Defense in Depth?
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
Or, the attack is against a legitimate user's outbound connection, for example: a user behind the firewall connects to a web site, a vulnerability in their browser is exploited to install a trojan -- the trojan tunnels to the attacker over an outgoing port that is allowed on the firewall.
Oh, certainly; I have lots of web browsers running on my servers.
All The World Is Not A Workstation, guys.
I think the point is that you access your servers from your work station and so if the workstation you use to access the network is compromised then your whole network is potentially compromised. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Wed, 16 Nov 2011 08:36:21 EST, Jay Ashworth said:
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
Or, the attack is against a legitimate user's outbound connection, for example: a user behind the firewall connects to a web site, a vulnerability in their browser is exploited to install a trojan -- the trojan tunnels to the attacker over an outgoing port that is allowed on the firewall.
Oh, certainly; I have lots of web browsers running on my servers.
All The World Is Not A Workstation, guys.
Is there *anything* on the allegedly protected subnet that has a web browser running on it? Maybe that laptop on the crash cart that you use for downloading firmware and installing it on storage appliances? If it's a corporate-sized NAT, do you have any desktops that have network reachability to the servers (probably do - if the desktops can't reach the servers, the servers aren't useful are they?) and also have web browsers that go to the outside world? I compromise an ad server someplace. Bob over in Accounting visits the CPA forum on the accountants-r-us.com website looking for suggestion on how to handle a tax issue. I now have control of Bob's workstation, and the question of whether your firewall does NAT or not just became totally moot. Defense in depth doesn't mean building a second Maginot Line behind the first is a good idea - it means you *also* have a capable army that will stop a German invasion coming in via Belgium.
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, November 16, 2011 9:02 AM To: Jay Ashworth Cc: NANOG Subject: Re: Have they stopped teaching Defense in Depth?
On Wed, 16 Nov 2011 08:36:21 EST, Jay Ashworth said:
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
Or, the attack is against a legitimate user's outbound connection, for example: a user behind the firewall connects to a web site, a vulnerability in their browser is exploited to install a trojan -- the trojan tunnels to the attacker over an outgoing port that is allowed on the firewall.
Oh, certainly; I have lots of web browsers running on my servers.
All The World Is Not A Workstation, guys.
Is there *anything* on the allegedly protected subnet that has a web browser running on it? Maybe that laptop on the crash cart that you use for downloading firmware and installing it on storage appliances? If it's a corporate-sized NAT, do you have any desktops that have network reachability to the servers (probably do - if the desktops can't reach the servers,
servers aren't useful are they?) and also have web browsers that go to the outside world?
I compromise an ad server someplace. Bob over in Accounting visits
CPA forum on the accountants-r-us.com website looking for suggestion on how to handle a tax issue. I now have control of Bob's workstation, and the question of whether your firewall does NAT or not just became totally moot.
Defense in depth doesn't mean building a second Maginot Line behind
the the the
first is a good idea - it means you *also* have a capable army that will stop a German invasion coming in via Belgium.
That's absurd, no one could get an army across that terrain... Jamie
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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde
----- Original Message -----
From: "Roland Dobbins" <rdobbins@arbor.net>
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 jra@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
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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde
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
----- Original Message -----
From: "Brett Frankenberger" <rbf+nanog@panix.com>
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 based on the industry stuff I have seen from out here, security isn't anywhere in the same *county* with where it needs to be, and -- just as with RMS and the GPL -- maybe if some extremists knees jerk, the end result, while more moderate, will be more salutary. If you were that chief, and you knew the result of you screwing up might be the loss of your liberty, not just your job... you don't think you'd fight budget battles with your utility harder? (That's often the reason for such regulations: to give middle to upper management more bullets to fire at the (greedy) owners.) Thanks for doing some of my math for me, though, Brett. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@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
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.
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
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.
That's basically the case for so many things. I was reading, recently, two articles on Ars Technica ("Die, VPN" and "Live, VPN") which made it exceedingly clear that these sorts of designs are still the rule for most companies. I mean, I already knew that, but it was *depressing* to read. We've been very successful for many years designing things as though they were going to be deployed on the public Internet, even if we do still put them behind a firewall. That's just belt-and-suspenders common sense. We do run a VPN service, which I use heavily, but it really has little to do with granting magical access to resources - the VPN endpoint is actually outside any firewall. I've so frequently found, over the years, that some "free" Internet connection offering is crippled in some stupid manner (transparent proxying with ad injection!), that the value added is mostly just that of getting an Internet connection with no interference by third parties. The fact that third parties cannot do any meaningful snooping is nice too. I also recall a fairly surreal discussion with a NANOG'er who was absolutely convinced that SSH key based access to other servers was more secure than password based access along with some ACL's and something like sshguard; my point was that compromise of the magic host with the magic key would tend to be worse (because you've suddenly got access to all the other servers) while having different secure passwords for each host, along with some ACL's and sshguard, allow you to retain some isolation within the network from an infected node. It's dependent on design and forethought, of course... Basically, getting access to some point in the network shouldn't really allow you to go on a rampage through the rest of the network. ... 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.
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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde
On Nov 14, 2011, at 9:24 AM, Joe Greco wrote:
Getting fixated on air-gapping is unrealistically ignoring the other thre= ats out there.
I don't think anyone in this thread is 'fixated' on the idea of airgapping;=
No, but it's clear that there are many designers out there who feel this is the way to go. That's why it's a good idea to cover the ground anyways.
but it's generally a good idea whenever possible, and as restrictive a com= munications policy as is possible is definitely called for, amongst all the= other things one ought to be doing.
I think the part people forget about is that last part, "amongst all the other things one ought to be doing."
It's also important to note that it's often impossible to *completely* airg= ap things, these days, due to various interdependencies, admin requirements= (mentioned before), and so forth; perhaps bastioning is a more apt term.
If it didn't turn into a situation where everyone's bastardizing^Wbastioning your network in insecure ways. ... 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.
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.
On 14/11/2011, Jason Lewis <jlewis@packetnexus.com> 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.
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" <jlewis@packetnexus.com> 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-u...
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 ______________________________________________________________________
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 <jlewis@packetnexus.com> To: "nanog@nanog.org" <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-u... 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 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-u...
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 - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
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
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-u...
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
As far as I can see Red Tiger Security is Jonathan Pollet; and even though they list Houston, Dubai, Milan, and Sydney as offices it looks like Houston is the only one. Is that right? Seems a little misleading. It actually reminds me of a 16 year old kid I know who runs a web hosting "company" that you'd think was a Fortune 500 by the way the website reads, and he's more than happy to take your credit card information and store it without being PCI compliant. Credibility of the company aside, At first I wanted to cut Jonathan some slack. If he was going to point to the use of public IPs as evidence that a firewall may not be in use and then went on to discuss the potential risks of not having any security, then that would have been appropriate. But instead he goes on about explaining what a public vs. private address is (poorly) and proceeds to associate the security of the system with the use of private IPs. I just don't see him as credible in the security field after reading it. Then again, he does have that interview on Fox News posted on his website where he talks about terrorist plots to compromise the integrity of nuclear power plants... Honestly, people post stuff like this time and time again. It's been debunked so many times that a quick Google will probably give you what you need to figure it out on your own. On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis <jlewis@packetnexus.com> 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-u...
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.
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On 11/13/11 07:36, 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-u...
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.
Really, the article doesn't make much sense. The claim is that SCADA systems come with "public IP addresses by default" and that SCADA engineers are too ignorant of Internet security practices to know to re-configure them. First, the ignorance factor goes right back to the two axioms I mentioned in my reply to Bill. If you aren't paying attention, then you don't have security, regardless of which IP address space you use. Second, there's the point that the SCADA systems come with public IP addresses by default. So what? The article incorrectly confuses "public" IP addresses with "routable" IP addresses. As an example, when I worked in the College of Chemistry at UC Berkeley, there was a lab with NMR machines that all came with public IP addresses by default--those of the manufacturer. Of course, since the manufacturer was in Germany, and we were in the US those IP addresses weren't routable in our network. Are SCADA systems similarly configured? The article doesn't say if the manufacturers pre-configure addresses within the client's IP blocks or their own, or even 1.2.3.0/24. If the manufacturer went to the trouble of configuring the system on routable IP addresses, then the SCADA engineer can easily specify which set of addresses. If the manufacturer really does configure "public" IP addresses "by default" then it's unlikely that those "public" IP addresses are actually _routable_ on the network which is using the SCADA system. Oh, and the article treats RFC1918 and RFC4193 is equivalent, which is WRONG WRONG WRONG! michael
participants (29)
-
-Hammer- -
Brett Frankenberger -
Cameron Byrne -
Chuck Church -
Dave Hart -
david raistrick -
David Walker -
Dobbins, Roland -
Doug Barton -
Jamie Bowden -
Jason Lewis -
Jay Ashworth -
Jay Hennigan -
Jeff Kell -
Jeroen van Aart -
Jimmy Hess -
Joe Greco -
Joel jaeggli -
Karl Auer -
Leigh Porter -
Mark Andrews -
McCall, Gabriel -
Michael Sinatra -
Owen DeLong -
Phil Regnauld -
Ray Soucy -
Robert Bonomi -
Valdis.Kletnieks＠vt.edu -
William Herrin