I don't want to start a flame war, but this article seems flawed to
me. It seems an IP is an IP.
http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
I think I could announce private IP space, so doesn't that make this
argume
On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis wrote;
>
> I don't want to start a flame war, but this article seems flawed to
> me.
Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is
DEFINITELY 'flawed'.
> It seems an IP is an IP.
True. *BUT*, "some IP's are mo
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. I
On 14/11/2011, Jason Lewis wrote:
> I don't want to start a flame war,
If you didn't write it I wouldn't stress about that.
> but this article seems flawed to
> me.
Me too.
> It seems an IP is an IP.
Yes but in IPv4 land there is a difference although probably not in
the way the author "sugg
On Sun, Nov 13, 2011 at 10:38 AM, Robert Bonomi
wrote:
> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis
> wrote;
> In addition, virtually _every_ ASN operator has ingress filters on their
> border routers to block almost all traffic to RFC-1918 destinations.
Well, when we are talking about sel
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
On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
wrote:
> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis
> wrote;
>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> Any article that claims a /12 is a 'class B', and a
Hey.
On 14/11/2011, Jimmy Hess wrote:
> In other words, your use of RFC1918 address space alone does not
> create security.
I had this crazy idea that somewhere in the rfcs was a "should" that
manufacturers block private address space (i.e. hard coded) but it's
not (in fact the opposite).
Obviou
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 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
On Sun, Nov 13, 2011 at 12:13 PM, William Herrin wrote:
> On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
> wrote:
>> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis
>> wrote;
>>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-defa
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' t
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
> >
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 translatio
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
- Original Message -
> From: "Roland Dobbins"
> The real issue is interconnecting SCADA systems to publicly-routed
> networks, not the choice of potentially routable space vs. RFC1918
> space for SCADA networks, per se. If I've an RFC1918-addressed SCADA
> network which is interconnected
Original Message -
> From: "Doug Barton"
> On 11/13/2011 13:27, Phil Regnauld wrote:
> > That's not exactly correct. NAT doesn't imply
> > firewalling/filtering.
> > To illustrate this to customers, I've mounted attacks/scans on
> > hosts behind NAT devices, from the inte
On 11/13/11 7:36 AM, Jason Lewis wrote:
I don't want to start a flame war, but this article seems flawed to
me. It seems an IP is an IP.
http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
I think I could announce private
-Original Message-
From: Phil Regnauld [mailto:regna...@nsrc.org]
>PAT (overload) will have ports open listening for return traffic,
>on the external IP that's being "overloaded".
>What happens if you initiate traffic directed at the RFC1918
>network itself, and send tha
>> 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
> From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Sun Nov 13 14:15:38
> 2011
> From: William Herrin
> Date: Sun, 13 Nov 2011 15:13:37 -0500
> Subject: Re: Arguing against using public IP space
> To: nanog@nanog.org
>
> On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
> wrote:
> > On Sun, 1
- Original Message -
> From: "Robert Bonomi"
> In the 'classful' world, neither the /12 or the /16 spaces were referencible
> as a single object. Correct 'classful descriptions' would have been:
> "16 contiguous Class 'B's" "256 contiguous Class 'C's"
Fine. But I think you're going to f
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.
;>
--
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
- Original Message -
> From: "Brett Frankenberger"
> What if you air-gap the SCADA network of which you are in
> administrative control, and then there's a failure on it, and the
> people responsible for troubleshooting it can't do it remotely (because of
> the air gap), so the trouble co
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 o
On 11/13/11 3:58 PM, Jason Lewis wrote:
People keep pointing to this as unlikely. I argue that spammers are
currently doing this all over the world, maybe not as widespread wiith
1918 space. If I can announce 1918 space to an ISP where my target
is...it doesn't matter if everyone else ignores
> 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 a
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 co
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
On Sun, Nov 13, 2011 at 3:03 PM, David Walker wrote:
> On 14/11/2011, Jimmy Hess wrote:
> A packet addressed to an endpoint that doesn't serve anything or have
> a client listening will be ignered (whatever) as a matter of course.
> Firewall or no firewall.
It will not go to a listening applicati
On Nov 13, 2011, at 7:36 AM, Jason Lewis wrote:
> I don't want to start a flame war, but this article seems flawed to
> me. It seems an IP is an IP.
>
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> I think I cou
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
communica
33 matches
Mail list logo
