Bekijk de volledige versie : Bogus ASUS firewall?
First of all, I'm not 100% sure of this, but I thougt I'll post it, so maybe someone can say whether I'm right or wrong.
What I'm talking about is the iptables rules the ASUS firmware generates. It's about this part of the rc/firewall_ex.c file:
if (nvram_match("fw_enable_x", "1"))
{
// DoS attacks
// sync-flood protection
fprintf(fp, "-A FORWARD -i %s -p tcp --syn -m limit --limit 1/s -j %s\n", wan_if, logaccept);
// furtive port scanner
fprintf(fp, "-A FORWARD -i %s -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j %s\n", wan_if, logaccept);
// ping of death
fprintf(fp, "-A FORWARD -i %s -p icmp --icmp-type echo-request -m limit --limit 1/s -j %s\n", wan_if, logaccept);
}
This results in:
2 96 ACCEPT tcp -- ppp0 any anywhere anywhere tcp flags:SYN,RST,ACK/SYN limit: avg 1/sec burst 5
0 0 ACCEPT tcp -- ppp0 any anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5
0 0 ACCEPT icmp -- ppp0 any anywhere anywhere limit: avg 1/sec burst 5 icmp echo-request
After these lines, there are the lines that are responsible for accepting connections set on the Virtual Server page of the web-interface. Basically, these so-called DDoS attack protection lines, just allow all connections. Take the first one (sync-flood protection). This line accepts 1 connection each second, with a certain burst rate. If new connections arrive to fast (which is actually what a sync-protected should protect against), the new packets won't match anymore. However, they aren't dropped, but instead travel further through the FORWARD chain, where, for example, they match a line that accepts incoming TCP-connections to port 6667. Still, the connection is accepted.
Basically, this line says: I will allow ANY new connection from the Internet, as long as there are not too much new connections in a short time period.
Besides this, I don't think sync-flood protection should be done in the filter table at all, as the connection tracker of the kernel already allocated a table entry for this new connection. Therefore, sync-flooding the router will certainly fill the table and disallow new connections to be handled at all (even outgoing connections). Proper sync-flooding should therefore be done in de mangle table, at a place even before packets arrive at the connection tracker code.
First of all, I'm not 100% sure of this, but I thougt I'll post it, so maybe someone can say whether I'm right or wrong.
However, they aren't dropped,
The last time I was trying to read the rules and my conclusion was this :-
All those rules in the FORWARD chain is a waste of time. Nothing is drop and the default policy is to accept.
Cheers.
The last time I was trying to read the rules and my conclusion was this :-
All those rules in the FORWARD chain is a waste of time. Nothing is drop and the default policy is to accept.
Cheers.
Indeed -- only INVALID packets are dropped and they occur seldom and normally only when there are configuration or transmission problems :)
So eventually, we can just say, the ASUS firewall rules are garbage :)
I've let my laptop with WinXP SP2 on for a week and the windows firewall has logged over 500k of blocked incoming connections while the WL-500g firewall was enabled.
Just a snippet:
#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2005-02-18 00:21:57 DROP TCP 207.81.68.24 192.168.1.90 5891 2168 40 AR 0 1718074882 0 - - - RECEIVE
2005-02-18 00:22:00 DROP TCP 70.109.1.197 192.168.1.90 23619 2170 48 SA 1575185243 1810092225 65535 - - - RECEIVE
2005-02-18 00:22:03 DROP TCP 70.109.1.197 192.168.1.90 23619 2170 48 SA 1575185243 1810092225 65535 - - - RECEIVE
2005-02-18 00:22:09 DROP TCP 70.109.1.197 192.168.1.90 23619 2170 48 SA 1575185243 1810092225 65535 - - - RECEIVE
2005-02-18 00:44:34 DROP TCP 66.65.91.122 192.168.1.90 6346 2184 48 SA 3302170736 1863137105 65535 - - - RECEIVE
2005-02-18 00:44:35 DROP TCP 81.100.242.235 192.168.1.90 6346 2181 40 FA 419733874 1160802317 16837 - - - RECEIVE
2005-02-18 00:44:37 DROP TCP 68.186.254.100 192.168.1.90 6346 2183 48 SA 1072419194 3694513561 65535 - - - RECEIVE
2005-02-18 00:44:38 DROP TCP 66.65.91.122 192.168.1.90 6346 2184 48 SA 3302170736 1863137105 65535 - - - RECEIVE
2005-02-18 00:44:43 DROP TCP 68.186.254.100 192.168.1.90 6346 2183 48 SA 1072419194 3694513561 65535 - - - RECEIVE
2005-02-18 00:44:43 DROP TCP 66.65.91.122 192.168.1.90 6346 2184 48 SA 3302170736 1863137105 65535 - - - RECEIVE
2005-02-18 01:23:11 DROP TCP 81.229.169.146 192.168.1.90 49980 2227 40 R 167764212 167764212 0 - - - RECEIVE
2005-02-18 01:35:41 DROP TCP 156.34.185.230 192.168.1.90 6346 2182 40 A 3651209476 4161902225 16875 - - - RECEIVE
2005-02-18 01:35:42 DROP TCP 67.183.43.71 192.168.1.90 6346 2237 48 SA 2384223315 4092772696 17520 - - - RECEIVE
2005-02-18 01:35:45 DROP TCP 67.183.43.71 192.168.1.90 6346 2237 48 SA 2384223315 4092772696 17520 - - - RECEIVE
2005-02-18 01:35:51 DROP TCP 67.183.43.71 192.168.1.90 6346 2237 48 SA 2384223315 4092772696 17520 - - - RECEIVE
2005-02-18 01:53:34 DROP TCP 80.186.215.89 192.168.1.90 48881 2245 74 AP 3274820336 3191917589 65223 - - - RECEIVE
2005-02-18 01:53:35 DROP TCP 80.186.215.89 192.168.1.90 48881 2245 40 A 3274820404 3191917595 65218 - - - RECEIVE
2005-02-18 01:53:35 DROP TCP 80.186.215.89 192.168.1.90 48881 2245 40 FA 3274820404 3191917595 65218 - - - RECEIVE
2005-02-18 02:13:28 DROP TCP 81.229.169.146 192.168.1.90 49980 2275 40 R 48746694 48746694 0 - - - RECEIVE
2005-02-18 02:24:00 DROP TCP 81.229.169.146 192.168.1.90 49980 2284 40 R 440706805 440706805 0 - - - RECEIVE
2005-02-18 04:04:51 DROP TCP 209.102.173.97 192.168.1.90 10613 2385 40 R 387321825 387321825 0 - - - RECEIVE
2005-02-18 04:04:51 DROP TCP 220.77.189.160 192.168.1.90 6346 2384 40 FA 3754737858 432272820 16837 - - - RECEIVE
2005-02-18 04:04:51 DROP TCP 209.102.173.97 192.168.1.90 10613 2385 40 R 387321825 387321825 0 - - - RECEIVE
2005-02-18 04:04:53 DROP TCP 83.89.10.119 192.168.1.90 3400 2389 48 SA 2711927576 3441903239 65535 - - - RECEIVE
2005-02-18 04:04:54 DROP TCP 83.197.194.40 192.168.1.90 10539 2390 40 AR 0 4172527399 0 - - - RECEIVE
2005-02-18 04:04:55 DROP TCP 83.89.10.119 192.168.1.90 3400 2389 48 SA 2711927576 3441903239 65535 - - - RECEIVE
2005-02-18 04:05:01 DROP TCP 83.89.10.119 192.168.1.90 3400 2389 48 SA 2711927576 3441903239 65535 - - - RECEIVE
2005-02-18 04:17:12 DROP TCP 70.178.155.60 192.168.1.90 1208 2404 48 SA 2761190018 674861942 65535 - - - RECEIVE
2005-02-18 04:17:14 DROP TCP 60.25.111.24 192.168.1.90 42495 2400 40 FA 3527931590 2722550123 64853 - - - RECEIVE
2005-02-18 04:17:15 DROP TCP 70.178.155.60 192.168.1.90 1208 2404 48 SA 2761190018 674861942 65535 - - - RECEIVE
2005-02-18 04:17:21 DROP TCP 70.178.155.60 192.168.1.90 1208 2404 48 SA 2761190018 674861942 65535 - - - RECEIVE
2005-02-18 04:43:50 DROP TCP 80.186.215.89 192.168.1.90 48881 2361 40 A 1901623407 4099211210 65458 - - - RECEIVE
2005-02-18 05:21:22 DROP TCP 69.241.52.206 192.168.1.90 6346 2446 40 FA 3943486285 2732136440 64855 - - - RECEIVE
tomilius
26-02-2005, 18:40
Yes... Same... How does this stuff get through?
I noticed something odd, by the way. I have port 20080 forwarded to port 80 on my computer. I don't know if this is the reason this occurs (the port forwarding section in Status says nothing about port 80 itself being forwarded to me) but unless I have my own firewall running, I get port 80 as closed and not blocked in Sygate's security scan (http://scan.sygatetech.com/quickscan.html).
My computer is not the DMZ host (and yes, I checked). At least, I didn't set it up that way. Even when I try the scan from another computer, the result from port 80 depends on whether or not the firewall is open on my computer (Outpost Firewall Pro/WinXP). Kind of strange... or is it?
I've let my laptop with WinXP SP2 on for a week and the windows firewall has logged over 500k of blocked incoming connections while the WL-500g firewall was enabled.
Hmmm interesting observation and it is something serious enough which warrants serious attention. Even though I said the FORWARD chain of the Asus is bloody useless, however, I am of the opionion that typical connections can't reach internal LAN. This is because there is no DNAT rules which bring them into the LAN. Or unless it was brought inside by uPnP ? If it is not too confidential perhaps one of you would like to show the iptables rules, especially the nat PREROUTING chain ?
Cheers
tomilius
27-02-2005, 01:02
Hmmm interesting observation and it is something serious enough which warrants serious attention. Even though I said the FORWARD chain of the Asus is bloody useless, however, I am of the opionion that typical connections can't reach internal LAN. This is because there is no DNAT rules which bring them into the LAN. Or unless it was brought inside by uPnP ? If it is not too confidential perhaps one of you would like to show the iptables rules, especially the nat PREROUTING chain ?
Cheers
Forums a little slow so I feel obligated to respond... Is this what you wanted, mctiew? This is my /tmp/nat_rules with the WAN IP replaced. Some rules related to my own settings, of course...
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp -d (WAN_IP) --dport 33770 -j DNAT --to-destination 192.168.1.1:80
... (Virtual Servers) ...
-A POSTROUTING -p udp -s 192.168.1.0/24 --dport 6112 -j NETMAP --to (WAN_IP)
-A POSTROUTING -o eth1 -j MASQUERADE
-A POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE
COMMIT
Indeed -- only INVALID packets are dropped and they occur seldom and normally only when there are configuration or transmission problems :)
So eventually, we can just say, the ASUS firewall rules are garbage :)
Invalid packets are in fact packets, which are out sequence (i.e. tcp fin/tcp ack/... etc scans) or completely unrelated. This rule make sense in the Router operation mode.
Hmmm interesting observation and it is something serious enough which warrants serious attention. Even though I said the FORWARD chain of the Asus is bloody useless, however, I am of the opionion that typical connections can't reach internal LAN. This is because there is no DNAT rules which bring them into the LAN. Or unless it was brought inside by uPnP ? If it is not too confidential perhaps one of you would like to show the iptables rules, especially the nat PREROUTING chain ?
Cheers
Hm... If you mean replies from WAN hosts, then everything is done by NAT - addresses are get translated automatically, as soon as initial packet added NAT entry to the kernel (i.e. MASQUERADE and SNAT rules).
-A PREROUTING -p tcp -m tcp -d (WAN_IP) --dport 33770 -j DNAT --to-destination 192.168.1.1:80
... (Virtual Servers) ...
I don't see anything unusual in the rules. But I suggest you append these rules in the FORWARD chain to investigate the outside connections :-
Firstly you add forward rules to all those incoming port forwarding virtual servers ( corresponding to each of your nat PREROUTING rule ) :-
iptables -A FORWARD -p tcp --dport 80 -d 192.168.1.0/24 -i eth1 -j ACCEPT
.... ( so these are legitimate ones, which you intentionally accepted it )
Now verify if anybody else creating new connections from outside device :-
iptables -A FORWARD -m state --state NEW -i eth1
This rule does not have any target ( or if you like you can target it to logaccept ). Then you log in from time to time to view if there is any packets in that rule :-
iptables -nvL FORWARD
Each iptables rule has a counter to it. So if there are packets passing through the rule, you can see it. If indeed there are packets, it means the firewall is screwed !
Cheers.
Hm... If you mean replies from WAN hosts, then everything is done by NAT - addresses are get translated automatically, as soon as initial packet added NAT entry to the kernel (i.e. MASQUERADE and SNAT rules).
Not too clear about your comments. If you are referrring to
inside-initiated outgoing connections, yes ! Outgoing connection are accepted and the stateful behaviour will allow the same connection to come back in.
With respect to outside initiated connections, what I meant to say is this :-
Outside initiated connections contact the firewall via the public IP. So without any NAT prerouting rules, all packets are actually INPUT to the firewall. If I remember correctly, the last rule of the INPUT chain is to drop everything, so nothing should gets to the LAN.
When there is prerouting DNAT, destination address is altered and the packets instead of becoming INPUT, they will go to the FORWARD chain. The FORWARD chain accepts anything, so they will appear in the LAN.
Cheers
tomilius
27-02-2005, 10:10
Eeeeeeeeeerrrrrraaaah. Uh. Too tired. Not enough resources to really test that. Don't have a web server set up since I reinstalled Windows all because of router troubles which weren't even resolved after I did that...
But I've gotten stuff in my software firewall logs about ports being connected to that are definitely not forwarded to my computer, even when I look at what's forwarded with UPNP... Ugh. Yawn. Even after setting INPUT packets to dropped by default in the filter table. When I try to block FORWARD packets by default I can't really get on the internet. Err... see my thread (http://wl500g.info/showthread.php?p=11482#post11482) on Port 80 in the Q&A for more info.
UPDATE: Near the end of my thread is my firewall setup. It works great, and I see no more entries from outsiders to unforwarded ports anymore.