Arguing against using public IP space

Mon Nov 14 03:48:01 UTC 2011

On Sun, Nov 13, 2011 at 3:03 PM, David Walker <davidianwalker at gmail.com> wrote:
> On 14/11/2011, Jimmy Hess <mysidia at 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 --
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