Difference between revisions of "Talk:Simple stateful firewall"

From ArchWiki
Jump to: navigation, search
(Clarification on syn scan rules: Remove closed discussion.)
(ICMP blocking)
 
(36 intermediate revisions by 8 users not shown)
Line 1: Line 1:
== IPv6 icmp replies ==
+
== Question about section "Protection against spoofing attacks" ==
For ipv6 adaptation.
+
The rule when rp_filter is 0 checks the source address.
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]].
+
Previously I only read about checking the destination address with the comment "Reject external connections '''for''' internal networks".<br />
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)
+
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.
  
:: Other articles have suggested a vanilla reject, thus:
+
[[User:Maddes.b|Maddes.b]] ([[User talk:Maddes.b|talk]]) 16:39, 26 August 2014 (UTC)
  
  -A INPUT -p tcp -j REJECT --reject-with tcp-reset
+
== ICMP rate limiting considered harmful ==
  -A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable
+
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.
  -A INPUT -j REJECT
+
  
--[[User:Steve-o|Steve-o]] ([[User talk:Steve-o|talk]]) 13:44, 13 September 2013 (UTC)
+
I'm considering removing it soon.
:::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
+
[[User:Alp|Alp]] ([[User talk:Alp|talk]]) 16:26, 18 February 2015 (UTC)
:::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)
+
 
 +
: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)
 +
 
 +
: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)
 +
 
 +
== ICMP blocking ==
 +
 
 +
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.
 +
 
 +
Hence, I would suggest the following rules:
 +
-A INPUT -p {,ipv6-}icmp -j ACCEPT
 +
 
 +
[[User:Respiranto|Respiranto]] ([[User talk: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.
 +
:# 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)
 +
 
 +
::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):
 +
::{{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)
 +
 
 +
:::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)