is there any real use for stateful firewalls?

[mariuszp]

I have previously talked here about how UDP holepunching can be performed without the use of external servers thanks to the lack of NAT in IPv6. If each side knows each other's IPv6 address and port, they can begin sending UDP packets to each other and we have a situation like:

1) Side A sends packet to B; the packet is discarded, but port A is now open.
2) Side B sends packet to A; the port is open so the packet is let through, and port B is now open.
3) Side A sends another packet to B; the packet arrives and we have full communication.

There's no security flaw here, because obviously both sides have to explicitly initiate the connection.

However, it is also really easy to do this assymetrically:

1) Server sends ICMP Echo Request, with well-know payload, to a well-know black hole address. The "black hole" never replies.
2) Client sends ICMP Hop Limit Exceeded message to server, quoting the ICMP Echo Request that was sent to the black hole. The firewall lets the packet in as it looks like a response from a router (and is required for "traceroute" to work).
3) Now the server and client can perform the process above, since they know each other's IPv6 address.

This is equivalent to a TCP accept()/connect() and then send()/recv(). And it penetrates the standard stateful firewall.
Yes, I did try this.

Now, you might argue that this means the vulnerability is on the server's side and has nothing to do with the firewall, because the server admin chose to run this software.

But in this case, what even is the point of a stateful firewall? Why does it block incoming connections, if it's just the user's fault that they run software which accepts such connections? As I've explained above, it is easy to replace accept()/connect() with the protocol I described and it punches through firewalls perfectly, blindly accepting inbound connections anyway.

Maybe I'm missing something, but it seems to me like this defeats the point of using stateful firewalls.

[onlyonemac]

Personally I prefer port and address firewalls, and application firewalls where they're not a PITA to configure.

[mariuszp]

that would work, but most residential routers have IPv6 stateful firewalls, and as I described, breaking through them is trivial, so what do they protect you from exactly?

[FallenAvatar]

Stateful firewalls are good for noticing and block port scanning and other various things. (Keeping track of failed connections)

- Monk

[Combuster]

Unmodified software still won't accept connections through the firewall (so the firewall will still block samba traffic that you do want on a local network, but certainly not across the entire internet). Having no stateful firewall leaves practically every windows machine's default configuration at risk.

In addition, you won't have a different firewall for IPv4, and that certainly is required to be stateful in order to do the mandatory NAT.

[mariuszp]

Yes, I know a stateful firewall is implicit in NAT. Holepunching like this is not usually possible without external servers (and sometimes even WITH external servers) when address translation is going on though, so I saw that as a possible security benefit.

So the point of a stateful firewall is to basically protect the default windows configuration?

[embryo2]

So the point of a stateful firewall is to basically protect the default windows configuration?

When an admin has to setup an application server it's often not a task every admin should master, so the admin just reads an installation guide and performs the required steps. Now we have a potentially dangerous system with most options set to default values. But the system is not a malware because the soft was acquired from a well know vendor. And here the firewall plays it's game perfectly - no connections from outside are possible despite the fact that some application server's ports are open and can be used maliciously. The second firewall from the intranet side makes the ports invisible to the organization's employees.

So, it's really useful layer of the security shield every organization should have.

[onlyonemac]

And here the firewall plays it's game perfectly - no connections from outside are possible despite the fact that some application server's ports are open and can be used maliciously. The second firewall from the intranet side makes the ports invisible to the organization's employees.

Except that none of that requires a stateful firewall.

[bluemoon]

1) Server sends ICMP Echo Request, with well-know payload, to a well-know black hole address. The "black hole" never replies.

It should stop here. A secured zone won't let any server do random outgoing activity.

[onlyonemac]

1) Server sends ICMP Echo Request, with well-know payload, to a well-know black hole address. The "black hole" never replies.

It should stop here. A secured zone won't let any server do random outgoing activity.

Did anyone say that the server was inside a "secured zone"? What's to say that the server isn't malicious?

[bluemoon]

1) Server sends ICMP Echo Request, with well-know payload, to a well-know black hole address. The "black hole" never replies.

It should stop here. A secured zone won't let any server do random outgoing activity.

Did anyone say that the server was inside a "secured zone"? What's to say that the server isn't malicious?

Stateful or not, you need some layer 3 rules to prevent the machine doing random outgoing activity to non trusted peer, failing that means insecure. There is less point talking about security of insecure system.

[onlyonemac]

Stateful or not, you need some layer 3 rules to prevent the machine doing random outgoing activity to non trusted peer, failing that means insecure. There is less point talking about security of insecure system.

In a traditional setup it's considered secure to have a system with no outgoing rules, sorry. Usually you want to block malicious traffic coming into a local server process, not blocking a local client from sending outgoing traffic. (This of course works on the assumption that all local clients are trustworthy and are not going to send malicious outgoing traffic - an assumption which, if you're not comfortable with, you're welcome to set up an outgoing firewall rule, except that the correct way to deal with local malicious software isn't with a firewall rule but with preventing the installation of/removing the malicious software in the first place.)

[bluemoon]

Stateful or not, you need some layer 3 rules to prevent the machine doing random outgoing activity to non trusted peer, failing that means insecure. There is less point talking about security of insecure system.

In a traditional setup it's considered secure to have a system with no outgoing rules, sorry. Usually you want to block malicious traffic coming into a local server process, not blocking a local client from sending outgoing traffic. (This of course works on the assumption that all local clients are trustworthy and are not going to send malicious outgoing traffic - an assumption which, if you're not comfortable with, you're welcome to set up an outgoing firewall rule, except that the correct way to deal with local malicious software isn't with a firewall rule but with preventing the installation of/removing the malicious software in the first place.)

With all the reverse proxy and similar technique, there is not much technical difference with incoming and outgoing traffic as a (malicious) server. When we take about security, yet there is no fully secured system as long as it's attached to internet, but one would push toward more secure affordable by the budget. For small company and home user, it's sufficient to have zero outgoing rule, but then you take the risk of running a trojan with reverse proxy over onion network.

Also note that practically you can't prevent installation of malicious software, the user is dumb enough to run email attachments, or the OS itself has more unpublished exploits than you would expected. While it's correct to examine the network and remove any malicious asap, there is no conflict to also have outgoing rules.

Last, I consider the hole punching things proposed by the OP is malicious, it is doing something not intended, and it happens to pass thru the firewall due to not having enough rules.


EDIT: IIRC, You can also limit the remote address for hole punching, so that when A punch a hole to the blackhole, B can't get in since he can't easily spoof with the black hole address without breaking into your ISP.

[onlyonemac]

While it's correct to examine the network and remove any malicious asap, there is no conflict to also have outgoing rules.

In my experience, outgoing rules cause more problems for users than they solve. You wouldn't believe how many people ask me "why can't xxx application access the internet?" and it's because their network is blocking outgoing traffic from the application/on whatever port the application is using. By contrast, I've dealt with maybe two or three virus infections and none of them would have been prevented/reduced by outgoing firewall rules.

Last, I consider the hole punching things proposed by the OP is malicious, it is doing something not intended, and it happens to pass thru the firewall due to not having enough rules.

Correct me if I'm wrong, but I believe that some applications/protocols, specifically Skype, SIP, and BitTorrent, can use hole punching as a form of NAT traversal if required. I wouldn't consider these malicious.

[bluemoon]

Hole punching is defined behavior, whereas ABUSE of hole punching to emulate an open listening port is not.

A malicious software do things not intended by its user, it has less to do with the protocol. A good software may use HTTP, and it doesn't mean a malicious software using the same protocol is fine.

What OP described is toke advantage of mis-configured (default) firewall to archive otherwise not allowed(not expected) activity.

To summerize:

OP said that the default firewall allow abuse of hole punching to emulate an open listening port, and that's a security risk.

I agree with that, and to enhance security he can consider:
1. setup outgoing rule to only allow trust communications.
2. configure the SPI to also check remote address, thus prevent B from get in without break into his ISP and spoof address.