In my last post I left you with a question: Given what we have seen in the decode file with tshark, what impact (if any) would there be if we place a stateful inspection firewall between the attacker and the Web server? In other words, if the attacker is running a packet sniffer, would they still see the Web server leaking out 404 errors?
And the answer is…
Maybe.
Not all stateful inspection firewalls are equal. Some handle packets slightly differently than others. For example some (like Checkpoint, Netscreen and others) let non-SYN packets to permit rules generate new state table entries. Some (Cisco, Netfilter and others) will only generate a state table with proper session establishment (must see TCP three packet handshake).
The NIPS sent a valid reset packet to the attacker on the Internet. Each of the above firewalls would see the reset packet and remove it’s entry from the state table. When the Web server continued to communicate however, only the first set of firewalls would let the packets leak out to the attacker. The second set of firewalls would simply drop the traffic. In fact if we set them up with a deny rule instead of a drop rule, they would kill the session on the Web server thus fixing the problem created by the NIPS.
Why do some vendors let acknowledgement packets generate new state table entries? This seems a bit counterintuitive as a legitimate session is always going to start with a SYN packet. There are two reasons this makes good functional sense:
- Updating the firewall rules does not kill active sessions
- Active-active setup will pass traffic prior to state table sync
Of course we’ve increased functionality at the cost of security. Unfortunately that is the typical trade off.
Hope you had fun with this challenge. If there is interest I will post more in the future.
Related posts:


Hey Chris..
enjoyed this challenge alot. I didn’t get the answer, but was enlightened. Now, how would one know to go looking for that sort of suspicious traffic in the first place? Look for RSTs? Or that plus something else? curious. Looking for more vignettes like this going forward!
ed
Hey Ed,
Personally, I like to start by looking for error packets. So TCP resets and ICMP type 3′s, 4′s, 5′s and 11′s are a great way to start. What I love about error packets is that they are relatively low noise. If you see them, “something” is wrong. Might be security related or it might be functional, but either way they will indicate a situation that needs some attention.
HTH,
Chris