Bad forwarding rules at the firewall

[unaiur]

I'm pretty sure that the firewall FORWARD'ing rules are incorrect. Near top, the rule 4 allows any connection, given that don't exceed the 1/connection per seccond rate:

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0          state INVALID
3        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
4       14   672 ACCEPT     tcp  --  vlan1  *       0.0.0.0/0            0.0.0.0/0          tcp flags:0x16/0x02 limit: avg 1/sec burst 5
5        0     0 ACCEPT     tcp  --  vlan1  *       0.0.0.0/0            0.0.0.0/0          tcp flags:0x17/0x04 limit: avg 1/sec burst 5
6        0     0 ACCEPT     icmp --  vlan1  *       0.0.0.0/0            0.0.0.0/0          limit: avg 1/sec burst 5 icmp type 8
7        0     0 ACCEPT     udp  --  vlan1  br0     0.0.0.0/0            0.0.0.0/0          udp dpts:25500:25599
8        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.2.1.21          tcp dpts:25600:25699
9        0     0 DROP       all  --  vlan1  br0     0.0.0.0/0            0.0.0.0/0

Following that rule, there are other rules that allows the forwarding for the "virtual hosts" feature, but they are almost useless that the previous rule allows that traffic.

I suppose that the original intention of the programmers was to limit the number of connections allowed, but not to explicitly allow them.

I think that the best way to solve this bug is to create a new chain called when the limit isn't reached, and put the "virtual hosts" rules in this new chain:

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0          state INVALID
3        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
4       14   672 VHOSTS     tcp  --  vlan1  *       0.0.0.0/0            0.0.0.0/0          tcp flags:0x16/0x02 limit: avg 1/sec burst 5
5        0     0 VHOSTS     tcp  --  vlan1  *       0.0.0.0/0            0.0.0.0/0          tcp flags:0x17/0x04 limit: avg 1/sec burst 5
6        0     0 ACCEPT     icmp --  vlan1  *       0.0.0.0/0            0.0.0.0/0          limit: avg 1/sec burst 5 icmp type 8
7        0     0 ACCEPT     udp  --  vlan1  br0     0.0.0.0/0            0.0.0.0/0          udp dpts:25500:25599
8        0     0 DROP       all  --  vlan1  br0     0.0.0.0/0            0.0.0.0/0

Chain VHOSTS (2 references)
1        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.2.1.21          tcp dpts:25600:25699

Do you see any flaw?

[unaiur]

I've rewritten the firewall rule generator. With this patch:
- The rules that protects against DOS attacks no longer allows to forward all incoming connections.
- If you activate MAC filtering, white listed MACs are affected by the remaining rules (with the asus code, white listed MACs runs the special chain MACS instead of FORWARD)

This patch puts the rules to filter by MAC into the MACS chain. This chain returns if the MAC is allowed, and drops the packet otherwise. This way, MAC filtering is encapsulated and doesn't affect any other rule.

Also, it creates a new chain called SECURITY, that implements the anti-DOS rules. If a violation is detected, the packet is dropped; otherwise the chain returns. The SECURITY chain is called on every new incoming packet.

Finally, all the compiler warnings are fixed.

Reviews of the patch are wellcomed.

[Oleg]

Nice. Have you checked, that everything from the web settings are working correctly?

[unaiur]

I've played with several elemental settings (the MAC list, the virtual host lists, incoming forwards). I've posted the patch to let other people to play with it before including it in any firmware.

I will be on holidays until 19th and although I will have internet connection, I can't help much, since my router remains here in Madrid.

Good bye.

[techno]

Reviews of the patch are wellcomed.

Your fix seems somehow reasonable to me. Unfortunately I am currently not able to try it out, because I have the build system and all this stuff on my notebook, which just got broken and will not be repaired until tomorrow.

May I kindly suggest that you put the NAT issue fix in your diff aswell?

[techno]

I just tried to apply the patch to oleg's 1.9.2.7-6b and it says:

Hunk #9 FAILED at 710.

Which version have you used for the diff?

[Oleg]

I'm having problems applying this patch too. Could you please compress it (using zip or gzip) and repost here? Perhaps this is a CR/LF problem...

[WVR]

I'm having problems applying this patch too. Could you please compress it (using zip or gzip) and repost here? Perhaps this is a CR/LF problem...

The posted file WAS in PC format. converted version attached

[Oleg]

in fact asus firewall_ex.c is partially in the DOS format, the patch does not. So, unair, please report the original patch compressed.

[unaiur]

I've remade the patch and compressed it as you suggested.

cd broadcom/src
gzcat rc-firewall.diff.gz | patch -p0

[Oleg]

Thanks, I will check it.

[Oleg]

Just a few questions. It appears that with this patch applied, SECURITY chain would seriously impact wl500g behaviour, i.e. the this rule -

-A SECURITY -p tcp --syn -m limit --limit 1/s -j RETURN

would allow only one connection attempt to _all_ services per second. So if you run web server on the wl500g which has graphics on the page, then your client would stuck on every picture, as the page loads much faster than one second. If you run ftp server, then you will serve one file per second for all users. Is not it?
The same applies to other limit rules...
Comments?

[Oleg]

P.S. Actually there is a burst limit of 5 by default, but there is still a problem...

[unaiur]

If you run an HTTP server you can disable the connection limit at port tcp/80 with this post-firewall command:

iptables -I SECURITY -p tcp --dport 80 -j RETURN

But I agree, 1 connection per second isn't sufficient. At least, 4/s raw limit and 10/s burst limit are needed. Should this be configurable from the web interface?

[Oleg]

Yes, perhaps. Well, I would think about this... Perhaps, we should just allow users to enable or disable attacks detection..