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 (http://www.wl500g.info/showthread.php?t=3199) 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..

[HanseHouse]

Hi,

I would like to test the new FORWARD rules and the SECURITY chain and play around with it a little bit.

Can you please post the new /tmp/filter_rules or an 'iptables -L -v -n" output so I can have a look at the new rules?

And perhaps the complete rc-firewall file with the patch applied? It's because I don't have the orig source installed...

I set the default policy of the FORWARD chain to DROP but now I still have these ACCEPTs you mentioned in the chain:

-A FORWARD -i ppp0 -p tcp --syn -m limit --limit 1/s -j ACCEPT
-A FORWARD -i ppp0 -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
-A FORWARD -i ppp0 -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT


I definetly don't like the lines because I don't see any use for them and want to remove them and I'm looking forward to see how you solved it...

Thanks,

Matthias