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