0

In the case of a firewall device seperate from a server host, I believe there is a clear benefit to using a stateful firewall.

But in the case of a host firewall, where the services in scope are well defined, what specific scenarios would be prevented by a stateful firewall that would not be blocked by a stateless firewall?

Consider a policy for a web and ssh server, connecting to a database...

  • allow any source IP/port to local IP address on ports 80 and 22 (local as server)
  • allow ports 80 and 22 on local IP to any destination IP/port (local as server)
  • allow local IP/port to mydbserver.example.com, port 3306 (local as client)
  • allow mydbserver.example.com, port 3306 to any local IP/port (local as client)

A stateless firewall configured as a above, could in theory be subverted. A spammer might bind a mailgun client to port 80 on a local IP and fire SMTP traffic out across the firewall. However the privilege required to achieve this would, in all cases I've come across, also give him the rights to change a stateful firewall config on the host. Hence for this threat mode, there is no advantage.

Improve this question
5
  • First of all: It's not going to be easy in the year 2016 to find a firewall appliance that doesn't do stateful TCP firewalling. Then: You should probably add your definition of stateless/stateful to the question, so it'll be easier to discuss that.
    – Marcus Müller
    Commented Nov 30, 2016 at 14:33
  • I am specifically not talking about firewall appliances. I'm talking about host firewalls, e.g. the MSWindows Firewall, netfilter etc. on devices which host servers and do not forward packets.
    – symcbean
    Commented Nov 30, 2016 at 15:00
  • ah, sorry, but I actually just brainfarted – I meant "host firewall", in the sense of "TCP/UDP/ICMP IP stack with firewall that doesn't implement state tracking"
    – Marcus Müller
    Commented Nov 30, 2016 at 15:03
  • Perhaps I should have explained that the reason I'm asking us there are considerations around performance and resource usage resulting in the two approaches having different operational characteristics, not to mention the question of attack surface.
    – symcbean
    Commented Nov 30, 2016 at 15:20
  • you should definitely edit your question and add that, maybe even highlight it!
    – Marcus Müller
    Commented Nov 30, 2016 at 15:23

1 Answer 1

Reset to default
1

Let me take a stab at this question...

The term Stateful is often associated with both "Deep Packet Inspection" and "Stateful Packet Inspection":

  1. Deep Packet Inspection: The ability to look into a packet and see what command is being used. So, for example, I'll allow incoming FTP request, but not allow the PUT and DELETE commands from FTP. This would make my FTP essentially read only.
  2. Stateful Packet Inspection: The ability to remember a connection. Many protocols (like HTTP) have a well-known port (like port 80) for the outgoing "request", but use a "public" port (>1024) for the incoming reply. SPI can remember the return port number and specifically allow it. Without the ability to remember the connection, you'd have to allow all incoming IP addresses on all port number >1024 in order to get the reply

So, as Marcus has pointed out... these are very common features of most "personal firewalls". Although Microsoft's personal firewall does SPI a little differently than a perimeter-based firewall would. That's because at the host, you can include the application or service that the connection is associated with (something that a perimeter firewall wouldn't know about). So, for example, I wouldn't have to allow for all incoming IPs and ports >1024 for all packets... just only those packets associated with IE. Yeah, that's not quite as good as the more formal approach, but it's something.

So, yes... the Microsoft software-based "personal" firewall that appears in modern versions of Windows is (just barely) a Stateful firewall.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .