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