Difference between revisions of "Talk:Simple stateful firewall"

From ArchWiki
Jump to: navigation, search
m (IPv6 icmp replies: typo)
(ICMP blocking)
 
(38 intermediate revisions by 9 users not shown)
Line 1: Line 1:
== <s>Clarification on syn scan rules </s>==
+
== Question about section "Protection against spoofing attacks" ==
Maybe I misunderstood some of the instructions but I found that I needed to insert the rules into the chains TCP and UDP rather than OPEN-TCP and OPEN-UDP as the latter didn't exist:
+
The rule when rp_filter is 0 checks the source address.
 +
Previously I only read about checking the destination address with the comment "Reject external connections '''for''' internal networks".<br />
 +
As I'm still a network/firewall newbie I cannot distinguish what is correct or if both are needed?
 +
  -I INPUT ! -i lo '''-d''' 127.0.0.0/8 -j DROP
 +
Same for the "IPv6" section.
  
# iptables -I TCP -p tcp -m recent --update --seconds 60 --name TCP-PORTSCAN -j REJECT --reject-with tcp-rst
+
[[User:Maddes.b|Maddes.b]] ([[User talk:Maddes.b|talk]]) 16:39, 26 August 2014 (UTC)
# iptables -I UDP -p udp -m recent --update --seconds 60 --name UDP-PORTSCAN -j REJECT --reject-with port-unreach
+
  
I also found that I needed to add an --update:
+
== ICMP rate limiting considered harmful ==
 +
I'd say that the ping rate limiter has little value. Processing those takes little effort for the kernel, especially compared to TCP. Anyhow, if you want to do proper traffic control, use tc, and look at queuing disciplines instead of arbitrary rate limits which may only be ephemerally valid and not applicable to most people.
  
# iptables -A INPUT -p icmp --icmp-type echo-request -m recent --name ping_limiter --hitcount 6 --seconds 4 -j DROP
+
I'm considering removing it soon.
  
I believe an --rcheck would also have worked. I'm not sure which would be correct. In general, I found this very helpful in conjunction with the man page for iptables. --[[User:Margali|Margali]] 21:57, 29 December 2011 (EST)
+
[[User:Alp|Alp]] ([[User talk:Alp|talk]]) 16:26, 18 February 2015 (UTC)
: I just checked, the above suggestions are in the rules now. closing --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:45, 11 September 2013 (UTC)
+
== IPv6 icmp replies ==
+
For ipv6 adaptation.
+
As '''--reject-with icmp6-proto-unreachable''' does not exist in ipv6, as told in the page, and according to the error messages description in the RFC [[https://tools.ietf.org/html/rfc4443#section-3.1]].
+
I think the '''icmp6-adm-prohibited''' which means "Communication with destination administratively prohibited" may be the message to send. It is only by reading the RFC, I am not a network expert and I have no idea of what is generally done in this case.--[[User:Cladmi|Cladmi]] 07:28, 15 February 2012 (EST)
+
  
:: Other articles have suggested a vanilla reject, thus:
+
:I guess you refer to [[Simple_stateful_firewall#Block_ping_request]]? I agree, but instead of removing it I would find it more useful if you would rephrase the intro of the section to account for your arguments (it already says "You should only do this for education purposes."). tc easily is overkill/off-track for most readers of this article. What do you think? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:22, 18 February 2015 (UTC)
  
  -A INPUT -p tcp -j REJECT --reject-with tcp-reset
+
:I have reread it and changed my mind. Added [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=368993&oldid=368980] to this item. The one part we should take care it is covered elsewhere appropriately before deleting is the paragraph that explains where to put the rule (before or after RELATED,ESTABLISHED). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:04, 8 April 2015 (UTC)
  -A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable
+
  -A INPUT -j REJECT
+
  
--[[User:Steve-o|Steve-o]] ([[User talk:Steve-o|talk]]) 13:44, 13 September 2013 (UTC)
+
== ICMP blocking ==
:::I'd say it depends what you want to do and the link to the RFC above by Cladmi is perfectly correct. I would change your last rule to
+
  -A INPUT -j REJECT --reject-with  icmp6-adm-prohibited
+
:::I would argue there is no big harm done complying with it anyway (more the contrary: the connecting system learns there is an IPv6 capable fw). Do you see reasons not to do it like that? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:15, 15 September 2013 (UTC)
+
  
== <s>References to OPEN chain(s)</s> ==
+
I am not an expert, but for example according to [http://serverfault.com/questions/84963/why-not-block-icmp#answer-84981 this post on Serverfault] blocking ICMP in general is not a good idea. Especially for IPv6 it, ICMP, is quite important.
 +
Unfortunately I have no IPv6 address at home (and am too lazy to set up my own router, with 6to4), but my Debian VPS was unable to get proper ping-replies on IPv6 with the provided rule.
  
I've re-read the guide once again and noticed multiple references to a now non-existent OPEN chain. A few years ago the OPEN chain was split into OPEN-TCP and OPEN-UDP, now simply TCP and UDP. See the relevant edits: [https://wiki.archlinux.org/index.php?title=Simple_Stateful_Firewall&diff=99829&oldid=99828], [https://wiki.archlinux.org/index.php?title=Simple_Stateful_Firewall&diff=119618&oldid=119609].
+
Hence, I would suggest the following rules:
 +
-A INPUT -p {,ipv6-}icmp -j ACCEPT
  
There are two solutions, either drop the references to the OPEN chain(s) completely, or undo those very old edits. If there are no objections, I'll go with the former.
+
[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 13:01, 30 March 2016 (UTC)
  
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 8 September 2013 (UTC)
+
:I think you have a point there. We should at least need an additional rule like
:+1 for the former. The first talk item shows as well that the old refs should be removed completely. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:45, 11 September 2013 (UTC)
+
: # ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT
 +
:since ipv6 has a separate type (129) for echo-replies. Can you test, if your VPS gets the replies if you add this one?
 +
:Maybe some more are useful (should not be related to your problem though), e.g.
 +
:# ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
 +
:# ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
 +
:# ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
 +
:# ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
 +
:([https://www.cert.org/downloads/IPv6/ip6tables_rules.txt source]) --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 15:56, 30 March 2016 (UTC)
  
:: Done, see if I missed something or if anything needs better wording: [https://wiki.archlinux.org/index.php?title=Simple_Stateful_Firewall&diff=275132&oldid=274755] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:17, 12 September 2013 (UTC)
+
::IPv4 does also have a separate echo-reply type, see `iptables -p icmp -h'. I initially thought the reply should be accepted as ESTABLISHED,RELATED by the first rule, however this appears to be wrong.
::: Fine with me. One could really add other examples to those INPUT chains, e.g. the logdrop from the main iptables article instead of opening port after port, but that's another matter. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:32, 12 September 2013 (UTC)
+
::I have experimented a little, which was not simplified by the fact that the rules are apparently not immediately applied by `ip6tables-restore', and found out that allowing type 128, 129 and the ones you specified above, without state restriction, does not help, however the followig does (with no other ICMP rule in effect):
 +
::{{bc|<nowiki>-A INPUT -p ipv6-icmp -m state --state UNTRACKED -j ACCEPT</nowiki>}}
 +
::I might try to narrow it down further, however I still do not think that one should block ICMP at all. Are there any serious security concerns?
 +
::[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 17:13, 30 March 2016 (UTC)
  
:::: OK, I'll close this in the meantime. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:07, 13 September 2013 (UTC)
+
:::Thanks for the quick feedback. I share your 'technical position' with respect to ipv6 unavailability at current. In general I am strongly in favour of allowing icmp in general; it's a backbone of efficient packet handling. Thing for ipv6 is, though, that a lot more is handled with it. See the limits for router-solicitation etc in the source file I linked for example. I.e. an "untracked" remote system can learn a lot more about your network topology with ipv6-icmp than ever was the case for ipv4 pings. If you get certain by looking into it, please share references and go ahead to add to the existing right away. Otherwise I suggest we take our time to look into it, perhaps other replies come, or direct edits which bring the section further. I have added [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&type=revision&diff=428750&oldid=422671] for that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:08, 30 March 2016 (UTC)
 +
 
 +
::::Just to add some information, the corresponding RFC can be found [https://tools.ietf.org/html/rfc4443 here]. I will hopefully find the time to look into it and possibly other documents.
 +
::::In general, if we intend to add more specific rules, I would suggest creating a separate ICMP chain for it. -- [[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 18:44, 30 March 2016 (UTC)

Latest revision as of 18:46, 30 March 2016

Question about section "Protection against spoofing attacks"

The rule when rp_filter is 0 checks the source address. Previously I only read about checking the destination address with the comment "Reject external connections for internal networks".
As I'm still a network/firewall newbie I cannot distinguish what is correct or if both are needed?

 -I INPUT ! -i lo -d 127.0.0.0/8 -j DROP

Same for the "IPv6" section.

Maddes.b (talk) 16:39, 26 August 2014 (UTC)

ICMP rate limiting considered harmful

I'd say that the ping rate limiter has little value. Processing those takes little effort for the kernel, especially compared to TCP. Anyhow, if you want to do proper traffic control, use tc, and look at queuing disciplines instead of arbitrary rate limits which may only be ephemerally valid and not applicable to most people.

I'm considering removing it soon.

Alp (talk) 16:26, 18 February 2015 (UTC)

I guess you refer to Simple_stateful_firewall#Block_ping_request? I agree, but instead of removing it I would find it more useful if you would rephrase the intro of the section to account for your arguments (it already says "You should only do this for education purposes."). tc easily is overkill/off-track for most readers of this article. What do you think? --Indigo (talk) 17:22, 18 February 2015 (UTC)
I have reread it and changed my mind. Added [1] to this item. The one part we should take care it is covered elsewhere appropriately before deleting is the paragraph that explains where to put the rule (before or after RELATED,ESTABLISHED). --Indigo (talk) 11:04, 8 April 2015 (UTC)

ICMP blocking

I am not an expert, but for example according to this post on Serverfault blocking ICMP in general is not a good idea. Especially for IPv6 it, ICMP, is quite important. Unfortunately I have no IPv6 address at home (and am too lazy to set up my own router, with 6to4), but my Debian VPS was unable to get proper ping-replies on IPv6 with the provided rule.

Hence, I would suggest the following rules:

-A INPUT -p {,ipv6-}icmp -j ACCEPT

Respiranto (talk) 13:01, 30 March 2016 (UTC)

I think you have a point there. We should at least need an additional rule like
# ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT
since ipv6 has a separate type (129) for echo-replies. Can you test, if your VPS gets the replies if you add this one?
Maybe some more are useful (should not be related to your problem though), e.g.
  1. ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
  2. ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
  3. ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
  4. ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
(source) --Indigo (talk) 15:56, 30 March 2016 (UTC)
IPv4 does also have a separate echo-reply type, see `iptables -p icmp -h'. I initially thought the reply should be accepted as ESTABLISHED,RELATED by the first rule, however this appears to be wrong.
I have experimented a little, which was not simplified by the fact that the rules are apparently not immediately applied by `ip6tables-restore', and found out that allowing type 128, 129 and the ones you specified above, without state restriction, does not help, however the followig does (with no other ICMP rule in effect):
-A INPUT -p ipv6-icmp -m state --state UNTRACKED -j ACCEPT
I might try to narrow it down further, however I still do not think that one should block ICMP at all. Are there any serious security concerns?
Respiranto (talk) 17:13, 30 March 2016 (UTC)
Thanks for the quick feedback. I share your 'technical position' with respect to ipv6 unavailability at current. In general I am strongly in favour of allowing icmp in general; it's a backbone of efficient packet handling. Thing for ipv6 is, though, that a lot more is handled with it. See the limits for router-solicitation etc in the source file I linked for example. I.e. an "untracked" remote system can learn a lot more about your network topology with ipv6-icmp than ever was the case for ipv4 pings. If you get certain by looking into it, please share references and go ahead to add to the existing right away. Otherwise I suggest we take our time to look into it, perhaps other replies come, or direct edits which bring the section further. I have added [2] for that. --Indigo (talk) 18:08, 30 March 2016 (UTC)
Just to add some information, the corresponding RFC can be found here. I will hopefully find the time to look into it and possibly other documents.
In general, if we intend to add more specific rules, I would suggest creating a separate ICMP chain for it. -- Respiranto (talk) 18:44, 30 March 2016 (UTC)