Importance of Stateful Firewalls. . .

As the title suggests, this thread is concerning the importance of stateful firewalls in regards to securing one's computer. I admittedly have a limited understanding of how stateful packet inspection (SPI) works, but I think it is sufficient enough to start a thread aimed at determining the importance of it. At the bottom of this post I've listed some of the sites that I've used to gain a better understanding of this technology. As for what I'm actually seeking with this thread, I have several topic-related questions that I will break down below:

1. Is SPI essential to securing one's computer? Please elaborate on why it is or is not essential.

2. If so, are there different types of SPI or varying implementations of SPI that might render the SPI of one firewall more effective than the SPI of another?

3. Can someone provide a comprehensive list of software firewalls that incorporate an effective SPI?

I know that having a hardware firewall with SPI is recommended, and that having one would likely eliminate the necessity of a software firewall with SPI, even though it might still be recommeneded. However, assuming a stateful firewall is essential, than in some instances such as mine, having a software firewall with SPI might still be a necessity even if one has a stateful hardware firewall. In my case, even though I will be getting a router with a hardware firewall, I will not be behind it at all times as I often take my laptop to school and use their WiFi. Given that, it would seem that having a software firewall with SPI is essential for me, right?



http://www.securityfocus.com/infocus/1716

http://en.wikipedia.org/wiki/Stateful_firewall

http://www.samspublishing.com/articles/article.asp?p=373120&seqNum=1&rl=1

 

1. its not completely essential but its better to have it. click here for a post explaining SPI

2. firewalls can vary in the protocols for which SPI is enabled. Look N Stop for example only has TCP SPI, but CHX-I offers TCP, UDP, and ICMP SPI.

3. not a complete list, but heres a starter:

CHX-I Packet Filter
Outpost Pro
Jetico
Look N Stop
Comodo Firewall
Kerio
Kaspersky (Internet Security)

 

Even the windows firewall does this...

 

some routers also have SPI i know the netgear DG834G has NAT and SPI firewalls built in

 

I'm suprised by the limited feedback and input I'm getting from the Wilders community. I would have expected alot of discussion about this as it seems to be a significant aspect of computer security, while at the same time not clearly understood by many. There also seems to be some contention as to the actual importance or necessity of it in securing ones computer. Why is that?

From what I've gathered about SPI, it seems it is necessary in order to block unsolicited packets, is that right?

If so, than how could one construe SPI as not being essential to securing one's computer?

If not, then what else does it do that makes it 'better to have'? In other words, what additional layer of protection does SPI provide, if not blocking unsolicited packets, that would leave one vulnerable without it?

So is having SPI on every protocol important or objectively better then having SPI on only some of the protocols? Which protocols is it most important to have SPI on?

So does windows firewall have an equally effective SPI as the other ('third party') firewalls, like the ones mentioned by WSFuser? Which protocols does the windows firewall have SPI on?

 

TCP
UDP is a stateless protocol, so a "fake" SPI is applied to it.
Maybe Stem could give you more information.

 

Only TCP (connection-oriented protocol) is stateful, UDP (much like ICMP) is a connectionless protocol, there is no "state" when dealing with UDP - it would be wrong to call it stateful inspection. UDP and ICMP do not themselves contain any connection information (such as sequence numbers). However, at the very minimum, they contain an IP address pair. UDP also contains port pairs, and ICMP has type and code information. All of these data can be analyzed in order to build "virtual connections" in the cache, hence the term "pseudo" stateful over connectionless protocols.

The small handful of Windows firewalls that do "pseudo" stateful are usually over the two commonly used connectionless protocols … UDP and ICMP.


Connection-oriented protocol - http://en.wikipedia.org/wiki/Connection-oriented_protocol
Connectionless protocol - http://en.wikipedia.org/wiki/Connectionless_protocol

 

Hi lucas1985,

As "Phant0m" as mentioned the workings of SPI. Yes all good and well, but as most, from the description to actual, can differ greatly.

I look at various firewalls (well just about all) I do check on the the filtering abilities........

OK, SPI (Stateful Packet inspection). SPI is about the ability of a firewall to know who you have connected to (from a view of you connecting out with your browser). The firewall keeps info on the the IP you have connected to, the info kept varies on the firewall, this can be as little as the IP/port, up to the flags/sequence for TCP, but it also depends on how the firewall acts on this info. For example, if a firewall is SPI, does this need to have rules to block invalid packets, or are these blocked with internal rules, or a need for user rules to block these. From L`n`S, I see "Phant0m" makes rules to block all invalid TCP packets, this would infer that the SPI within L`n`S is unable to block/drop these, if this is correct then L`n`s SPI is possibly lacking.
Looking at Outpost SPI, this is not enabled on rules by default. If it is, then any outbound connection you make will allow that IP to make inbound connection on you,.. really quite scary.
The list goes on,... but I think the question should not be "Importance of Stateful Firewalls", but, "correct implimentation"

 

Hi! Stem,

This sentence is what TypicallyOffbeat is looking for:

 

YES

 

I suppose this presupposes that SPI is in fact important, and that when implemented properly it is effective at securing ones computer, or at least effective in doing its part in securing ones computer.

So what is the correct implemenation of SPI?

Also, which software firewalls or packet filters by default correctly implement SPI so as to make them effective?


Also, if someone could address the following unanswered questions from in my previous post:

 

Propably the problem is that we cannot tell how SPI is implemented, but I think it is safe to say that software like browsers connecting out get the returned TCP packets accepted by SPI. Cannot really tell which one is better than the other, since all software firewalls I have used have SPI. Windows XP SP2 one sure is as good as any other.

For UDP, it is a connectionless protocol. Some never FW's have implemented a pseudo SPI for it it. But as an example kerio 2.1.5 or Sygate don't. How much is it a risk? I don't consider it a risk. It means only that firewall like kerio 2.1.5 will block every incoming unknown packet that does not match a rule. So one has to make a rule to allow incoming UDP packets explicit for those applications that will receive incoming data. An pseudo SPI UDP firewall like Sunbelt Kerio would pass packets belonging to a solicited connection in unless outgoing traffic is blocked, whereas kerio 2.1.5 would block all unknown by default. Which is better approach? I don't know. Comodo would be able to block too if the user is smart since there is udp spi only in network rules, so it matters how that pseudo spi is implemented. There are many considerations and impossible without testing to tell what is the best approach that works also in praxis best. One should not make such an assumption that incoming solicited traffic is for a good purpose.

It is that specific application listening, how it is made and how it handles the incoming data that is responsible most for the protection.

Typical example in kerio 2.1.5 is my netphone program. I allow it the whole UDP 1024-65535 local port range from any remote port. But it does not open all those ports, only a few, as one can see in connection view. And the application handles all the packets passed in and kerio 2.1.5 does not allow those ports to pass packets in to any other running applications that don't have allowed incoming rules made for these open ports. In a sense it is passing packets both solicited/unsolicited in, since no pseudo udp spi exists, but that listening netphone program handles them all. Notice also that some applications need unsolicited connections, an example is torrent file sharing programs. In practice there is not much difference in firewalls's security, whether no/yes "spi" in udp. What matters is how they are implemented.

 

Stateful-filter implementation can vary among various product vendors; also the time that passes seems to give way for further development of the definition.

If you have done already some research you see that stateful packet inspection is a term originally coined by Check Point, it uses Layer 4–type information as well as the tracking of application-level commands. Stateful packet filtering best describes the so-called SPI implements that track at Layer 4 and lower.


As for Look ‘n’ Stop SPI implementation, it isn’t among advanced forms of stateful filtering which tracks stuff such as sequence and acknowledgment numbers, and it works at Layer 4 and lower. Also it’s the Ruleset that gets examined firstly, and in addition there are several reasons for the rules that block different TCP flag combinations and other invalid TCP packets.

 

But this would only be a basic check to see if the packet is allowed. The SPI should then check if the packet is valid.

This would infer that an SPI firewall that does not give the user the ability to set such rules (as invalid flags etc) that the packets would simply be allowed through.



Lets look at an outbound TCP attempt as example. For the start of a connection a TCP SYN packet is sent. Now as you mention, the user rules are looked at first to see if a rule to allow the outbound is in place, if not, then the packet is dropped, as the packet would not be further processed. If there is a rule in place to allow this outbound, then the packet would be passed to the SPI and allowed (as start of connection), and further packets for that connection would be processed by the SPI, first to confirm the 3 way handshake, then to check all packets are valid, any invalid packets during the connection should be dropped/filtered out by the SPI. If a packet was sent out of this connection (different IP/port etc) then the packet would go through the user rules, if no rule to allow, again the the packet should be dropped.
If for example, there was no current connection, and a SYN ACK packet was sent as outbound from a port with a rule to allow outbound, then the user rule would allow this, but the SPI should drop the packet as invalid (at the minimal, out of sequence/connection). The same should be for any packet (inbound/outbound), be it all flags set, whatever.

I currently have CHX installed, I did run tests on this to check on the SPI filtering, this only confirms what I have said. Example. Making an outbound connection is allowed by the user rules, and processed by the SPI. Now if I attempt to make an initial outbound with say a "SYN ACK" packet then the packet is dropped by the SPI as out of connection. This is the same for any invalid packet (such as all flags set). The SPI will filter the same on inbound.

Again, I only see the need to make manual rules to filter invalid/illigal packets if the SPI is unable to do this.
It does now make me interested to check the ability of the SPI within L`n`S. To see if invalid packets are allowed through.

 

so, what about your research?

 

Look ‘n’ Stop SPI implementation would then only be stateful-like aka pseudo stateful and not true-stateful mechanism if it didn’t do stuff like TCP flags, simply doing IP address and port pairs would not be enough to make a firewall fall under the class of a true-stateful firewall.


The rules exists for some reasons, like …, labelling for better informing the user of what they are experiencing, the SPI loggings can be confusion and seem far from informative. TCP Stateful packet inspection also isn’t activated by default on install, for this, many thinks it’s RECOMMENDED to leave it disabled. And since the Look ‘n’ Stop SPI implementation hasn’t been maintained to address some annoyances / problems, the users who do explore this feature in the firewall are quick to disable it.


And to confirm; if you were to run your tests on the Look ‘n’ Stop SPI implementation, you’ll quickly find that the firewall stateful mechanism doesn’t lack in this area…

 

So are you saying the rules you put in place to filter out invalid flag packets are only for logging?

So L`n`S SPI is buggy?

 

No.

Yes, however they do not make Look ‘n’ Stop SPI any less secure.

 

CHX-I seems to have one of the more robust SPI for a software firewall out there. Tracking sequence numbers, acknowledgment numbers, and flags. Also offering timeout values in which the user can adjust. Along with pseduo UDP/ICMP. Then to round it all out a state table viewer in which you can watch it all.

Most firewalls out there today, it doesn't seem like they really care enough about improving there packet filtering and SPI. Instead all they seem to really want to do is pass those silly leaktests and create anti-malware apps. Its unfortunate.

 

dukebluedevil; I agree with all what you have said.

 

Phant0m,

Great minds think alike.

 

Outpost does do SPI by default (checking packets to see if they are part of an existing connection or not) but offers an extra "Stateful Inspection" option (disabled by default) - this would allow all further connections with an address as long as the connection triggering the rule is active. So it is useful for protocols that use multiple connections (like FTP) but should not otherwise be enabled.

There is certainly some variation on how firewalls implement SPI but as long as they do the basic level (i.e. enough to identify whether a packet is part of an existing connection or not) then anything more is largely irrelevant for personal users. Application filtering and leaktest performance is then more important since current malware is taking the route of hijacking existing applications, not trying to craft packets to appear "SPI-valid".

 

I'm assuming by basic level of SPI you're talking about on the TCP protocol, right? Also, could you and/or others provide a comprehensive list of software firewalls that incorporate this basic level of SPI? So far in this thread, the following have been said to include SPI:

Windows Firewall
CHX-I Packet Filter
Outpost Pro
Jetico
Look N Stop
Comodo Firewall
Kerio
Kaspersky (Internet Security)

Now do all these firewalls, and others that include SPI, have an equally effective SPI on the basic level Paranoid2k is referring to? Also, unless it ends up being that virtually all software firewalls have SPI, and given the importance of SPI, then it might be a good idea for a Mod to create a sticky with a comprehensive list of firewalls that incorporate SPI.

 

I did look at this a while ago, and found it was the "Attack plugin" that was filtering out some of the invalid TCP packets.

As from the post by PhantOm

So is it the SPI or the "Attack plugin" that filters the invalid flagged TCP?

 

By "basic SPI" I mean identifying whether a network packet belongs to an existing connection or not. This is easy with TCP but can also be done (to varying degrees of accuracy) with UDP and ICMP also. Most applications don't use UDP to a large extent though and ICMP can be just as securely handled by filtering on type and direction since it tends to involve single message/response transactions rather than extended connections.

As for a firewall list, it would actually be easier to list those firewalls not providing SPI since there are so few (the only major one I know of is Look'n'Stop where SPI is an option which, when enabled, sets a limit on the number of concurrent network connections).

An easy way to check is to see what rules are required to allow webpage access. If allowing outgoing TCP only (optionally to remote port 80) works, then the firewall supports basic SPI since it is automatically detecting (and allowing) the response back. If an extra rule is required to allow incoming TCP (optionally from remote port 80) before web browsing works, then the firewall is not detecting the response and is very likely not doing SPI.

Outpost's Attack Detection plugin acts independently of the rules engine so it doesn't handle SPI at all. It will, by default, discard packets that meet certain criteria (overlapping fragments, short fragments, oversized IP options - the full list can be viewed in Attack Detection Properties/Advanced/Attacks List/Edit) but this is via pattern matching, nothing exotic AFAIK.