Hi, Jow
I attached version 2 of my patch, option limit 1000 is kept.
1. Following "deny by default" principle, change the default section
policy to DROP. The firewall package already add rules to allow all
lo traffic, there should be no impact to user.
NACK. If at all it should be reject, not drop - to at least give users a
chance to see that the firewall is swallowing traffic.
Not all traffic can be rejected by default e.g. invalid ICMP, invalid
source address
Besides, the default policy will be overrided by policy at various
"config zone" section. (http://wiki.openwrt.org/doc/uci/firewall#zones)
2. harden the allow dhcp renew rule, source port should always be 67
ACK.
3. Refer to rfc4890 ICMPv6 Filtering Recommendations, Appendix B.
(http://www.ietf.org/rfc/rfc4890.txt) The sample ICMPv6 filter rules
indicates ip6tables can keep track most icmpv6 traffic as "RELATED".
The icmpv6 filter can be hardened.
I'm not sure about that. In theory DHCP response traffic should be kept
as related as well, in practise the idle times are too high so the
connections fall out of the conntrack table. I prefer to keep explicit
ICMP whitelists, relying on related state tracking with varying timeouts
will lead to unpredictable behaviour.
The default conntrack timeout in /etc/sysctl.conf
net.netfilter.nf_conntrack_tcp_timeout_established=3600
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeout_stream=180
The minimum timeout is 60s, not many client will tolerate a 60s idle
connection.
4. Allow most icmpv6 neighbour discovery traffic as kernel will
enforce "hop-limit=255" rule (packet is not forwarded)
Any reason why you remove ICMP failure notifications like "too-big" from
the whitelist?
Refer to rfc4890 ICMPv6 Filtering Recommendations, Appendix B., page 32
(http://www.ietf.org/rfc/rfc4890.txt)
# PACKET TOO BIG ERROR MESSAGES
# =============================
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming Packet Too Big messages
# only for existing sessions
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED \
--icmpv6-type packet-too-big \
-j ACCEPT
done
Similar rules exist for other ICMP packet.
5. remove limit 1000 to avoid possible denial of service (attacker
can stop all ICMP traffic by sending more than 1000 ICMP packet/s)
As I already mentioned in the ticket, instead of removing the limit, I'd
rather see hashlimits implemented, that rate-limit the traffic per host
or prefix.
~ Jow
ching
Index: trunk/package/firewall/files/firewall.config
===================================================================
--- trunk/package/firewall/files/firewall.config (revision 31216)
+++ trunk/package/firewall/files/firewall.config (working copy)
@@ -1,8 +1,8 @@
config defaults
option syn_flood 1
- option input ACCEPT
- option output ACCEPT
- option forward REJECT
+ option input DROP
+ option output DROP
+ option forward DROP
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
@@ -31,6 +31,7 @@
config rule
option name Allow-DHCP-Renew
option src wan
+ option src_port 67
option proto udp
option dest_port 68
option target ACCEPT
@@ -64,14 +65,11 @@
option src wan
option proto icmp
list icmp_type echo-request
- list icmp_type echo-reply
- list icmp_type destination-unreachable
- list icmp_type packet-too-big
- list icmp_type time-exceeded
- list icmp_type bad-header
- list icmp_type unknown-header-type
list icmp_type router-solicitation
+ list icmp_type router-advertisement
list icmp_type neighbour-solicitation
+ list icmp_type neighbour-advertisement
+ list icmp_type redirect
option limit 1000/sec
option family ipv6
option target ACCEPT
@@ -83,12 +81,6 @@
option dest *
option proto icmp
list icmp_type echo-request
- list icmp_type echo-reply
- list icmp_type destination-unreachable
- list icmp_type packet-too-big
- list icmp_type time-exceeded
- list icmp_type bad-header
- list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
