3 ms·

What's the point of using a stateful firewall in front of a server ? The concept of stateful firewall was created to protect clients: 1. Clients initiate flow

What's the point of using a stateful firewall in front of a server ? The concept of stateful firewall was created to protect clients: 1. Clients initiate flow toward the dangerous wild Internet; 2. The stateful firewall check that returning traffic from dangerous-Internet belongs to a flow initiated by an inside-client. => So it consumes CPU and RAM (session tables) in exchange of protecting inside-clients from dangerous-Internet. But using a stateful firewall in front of a server seems useless to me: 1. The inside-server behind the firewall MUST reply to all clients, so the stateful firewall must allow all Internet initiated-sessions to reach the server (no usage of a state table here). 2. When the inside-server replies to the outside-clients, the firewall will then consume CPU and RAM to check its state table. So it will consume resources to guarantee that our inside-serve is correctly replying to the outside-clients.. which is pointless. This could be useful in rare case when you have a very big firewall able to limit the number of sessions toward your small inside-server. But in case of a DNS server, that are natively able to generate a large number of packets-per-second UDP traffic, this seems to waste firewall CPU and RAM for this useless state table.

mrkeen 3y ago
> 1. The inside-server behind the firewall MUST reply to all clients, so the stateful firewall must allow all Internet initiated-sessions to reach the server (no usage of a state table here). I don't understand this requirement, (more specifically the second half of it). Isn't a firewall literally a device which allows in some connections, rather than all connections? (And state plays a role in letting the firewall remember which external clients are acting DOSy?)
- fulafel 3y ago
  (not the GP poster) By my reading the rate-limiting case was covered as the exception in a latter part of the comment ("This could be useful in rare case when you have a very big firewall able to limit the number of sessions toward your small inside-server.") But in the usual case you'll block connection attempts to the wrong port statelessly, and there's no benefit in tracking the served sessions in an external firewall.
toast0 3y ago
I'm not in favor of doing it, but you pick up some benefits in some cases. For TCP, if your server doesn't deal well with bogus packets, having a stateful firewall allows dropping data packets without an associated connection. Stateful firewalls may have syncookies where your server os doesn't, in case you're running 20 year old servers or macos servers. For UDP servers, it could be potentially useful if the rate limiting in the firewall is more flexible than in the server application. But for DNS, usually you're looking at one request -> one response, I don't know why you would want a state for that. Of course, it is useful to mix stateful and stateless: allow all the service related traffic without state, but allow for incidental outbound traffic with state. Drop everything else. But that's really more about having a clear access control layer than protecting a host from network abuse.

mrkeen 3y ago

> 1. The inside-server behind the firewall MUST reply to all clients, so the stateful firewall must allow all Internet initiated-sessions to reach the server (no usage of a state table here). I don't understand this requirement, (more specifically the second half of it). Isn't a firewall literally a device which allows in some connections, rather than all connections? (And state plays a role in letting the firewall remember which external clients are acting DOSy?)

fulafel 3y ago
(not the GP poster) By my reading the rate-limiting case was covered as the exception in a latter part of the comment ("This could be useful in rare case when you have a very big firewall able to limit the number of sessions toward your small inside-server.") But in the usual case you'll block connection attempts to the wrong port statelessly, and there's no benefit in tracking the served sessions in an external firewall.

toast0 3y ago

I'm not in favor of doing it, but you pick up some benefits in some cases. For TCP, if your server doesn't deal well with bogus packets, having a stateful firewall allows dropping data packets without an associated connection. Stateful firewalls may have syncookies where your server os doesn't, in case you're running 20 year old servers or macos servers. For UDP servers, it could be potentially useful if the rate limiting in the firewall is more flexible than in the server application. But for DNS, usually you're looking at one request -> one response, I don't know why you would want a state for that. Of course, it is useful to mix stateful and stateless: allow all the service related traffic without state, but allow for incidental outbound traffic with state. Drop everything else. But that's really more about having a clear access control layer than protecting a host from network abuse.