Difference between revisions of "Talk:Simple stateful firewall"

From ArchWiki
Jump to: navigation, search
(Clarification on syn scan rules: Remove closed discussion.)
(iptables CT target: re, close)
 
(51 intermediate revisions by 10 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)
 +
 
 +
== Suggest opening incoming TCP connections on port 53 for the DNS server in addition to UDP? ==
 +
 
 +
In the 'Opening portsfor inncoming connections' sub-section there is suggestion on accepting "Incoming UDP streams on port 53 for DNS server". After I did that I also had to open TCP in similar fashion, otherwise the server would fail the test (it's part of the OpenNIC infrastructure, they have a tool to test the server through their web interface). My question is, should that extra rule for TCP connections be added to the wiki article?
 +
 
 +
I was going to add '''''iptables -A TCP -p tcp --dport 53 -j ACCEPT'''''
 +
 
 +
--[[User:Soocki|Soocki]] ([[User talk:Soocki|talk]]) 09:35, 1 July 2017 (UTC)
 +
 
 +
:Sounds reasonable. Go ahead.
 +
:It might be noted, however, that those examples listed are nothing but examples. Anybody running a DNS server should know, which ports to open.
 +
:[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 12:57, 1 July 2017 (UTC)
 +
 
 +
::Done.
 +
::How about a note saying: "The following rules are nothing but examples, make sure they match your particular setup before implementing any of the ''suggestions'' below." on top of that section?
 +
::--[[User:Soocki|Soocki]] ([[User talk:Soocki|talk]]) 14:52, 1 July 2017 (UTC)
 +
 
 +
:::Well, I think the current ''Note'' should suffice.
 +
:::I just wanted to somehow relativate my former statement, i.e. to say, that there is no need to cover every use case.
 +
:::[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 15:30, 1 July 2017 (UTC)
 +
 
 +
:[https://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport Wikipedia says], that DNS uses the TCP protocol only for responses (which are not to/from port 53) and only if the response size is too big. If OpenNIC relies on the TCP port 53, it's specific to their test and hence inappropriate for this general page. I'll undo the change. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:01, 1 July 2017 (UTC)
 +
 
 +
::To me, this is not obvious from the Wikipedia entry. In contrast, [https://tools.ietf.org/html/rfc7766#page-6 RFC7766] states "Stub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries depending on local operational reasons." and "In addition, it is noted that all recursive and authoritative servers MUST send responses using the same transport as the query arrived on."
 +
::[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 22:50, 1 July 2017 (UTC)
 +
 
 +
:::To me that part still sounds like talking about the responses, i.e. what the resolver sends back. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:11, 2 July 2017 (UTC)
 +
 
 +
::::The (stub) resolver is the client. I.e. it speaks first. Hence, I understand the quoted statements as demanding a nameserver to accept and reply to TCP queries (using TCP). Also, it is stated: "TCP MAY be used before sending any UDP queries." By the way, dig(1) has an option `+tcp'.
 +
::::[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 21:26, 2 July 2017 (UTC)
 +
 
 +
::::Due to no further reply, I have reverted the change now. -- [[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 12:16, 9 July 2017 (UTC)
 +
 
 +
== <s>iptables CT target</s> ==
 +
 
 +
Found this in dmesg:
 +
 
 +
[15393.042447] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
 +
 
 +
Does this mean "-m conntrack" is deprecated in favor of something like "-j CT"?
 +
 
 +
(Disclaimer, ran across this in Ubuntu's logs when using this guide; just say so if it's Ubuntu doing dumb things)
 +
[[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 23:19, 1 August 2017 (UTC)
 +
 
 +
:No, it means something like {{ic|-m conntrack --ctstate RELATED -m helper ... }} is deprecated in favor of {{ic|-j CT}}. Automatic helpers assignment is already disabled in Arch kernel with {{ic|/proc/sys/net/netfilter/nf_conntrack_helper}} being unset, and not covered in this article. See also [https://wiki.archlinux.org/index.php?title=Iptables&type=revision&diff=485050&oldid=464363]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:42, 12 August 2017 (UTC)

Latest revision as of 18:42, 12 August 2017

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)

Suggest opening incoming TCP connections on port 53 for the DNS server in addition to UDP?

In the 'Opening portsfor inncoming connections' sub-section there is suggestion on accepting "Incoming UDP streams on port 53 for DNS server". After I did that I also had to open TCP in similar fashion, otherwise the server would fail the test (it's part of the OpenNIC infrastructure, they have a tool to test the server through their web interface). My question is, should that extra rule for TCP connections be added to the wiki article?

I was going to add iptables -A TCP -p tcp --dport 53 -j ACCEPT

--Soocki (talk) 09:35, 1 July 2017 (UTC)

Sounds reasonable. Go ahead.
It might be noted, however, that those examples listed are nothing but examples. Anybody running a DNS server should know, which ports to open.
Respiranto (talk) 12:57, 1 July 2017 (UTC)
Done.
How about a note saying: "The following rules are nothing but examples, make sure they match your particular setup before implementing any of the suggestions below." on top of that section?
--Soocki (talk) 14:52, 1 July 2017 (UTC)
Well, I think the current Note should suffice.
I just wanted to somehow relativate my former statement, i.e. to say, that there is no need to cover every use case.
Respiranto (talk) 15:30, 1 July 2017 (UTC)
Wikipedia says, that DNS uses the TCP protocol only for responses (which are not to/from port 53) and only if the response size is too big. If OpenNIC relies on the TCP port 53, it's specific to their test and hence inappropriate for this general page. I'll undo the change. -- Lahwaacz (talk) 18:01, 1 July 2017 (UTC)
To me, this is not obvious from the Wikipedia entry. In contrast, RFC7766 states "Stub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries depending on local operational reasons." and "In addition, it is noted that all recursive and authoritative servers MUST send responses using the same transport as the query arrived on."
Respiranto (talk) 22:50, 1 July 2017 (UTC)
To me that part still sounds like talking about the responses, i.e. what the resolver sends back. -- Lahwaacz (talk) 06:11, 2 July 2017 (UTC)
The (stub) resolver is the client. I.e. it speaks first. Hence, I understand the quoted statements as demanding a nameserver to accept and reply to TCP queries (using TCP). Also, it is stated: "TCP MAY be used before sending any UDP queries." By the way, dig(1) has an option `+tcp'.
Respiranto (talk) 21:26, 2 July 2017 (UTC)
Due to no further reply, I have reverted the change now. -- Respiranto (talk) 12:16, 9 July 2017 (UTC)

iptables CT target

Found this in dmesg:

[15393.042447] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

Does this mean "-m conntrack" is deprecated in favor of something like "-j CT"?

(Disclaimer, ran across this in Ubuntu's logs when using this guide; just say so if it's Ubuntu doing dumb things) Physicist1616 (talk) 23:19, 1 August 2017 (UTC)

No, it means something like -m conntrack --ctstate RELATED -m helper ... is deprecated in favor of -j CT. Automatic helpers assignment is already disabled in Arch kernel with /proc/sys/net/netfilter/nf_conntrack_helper being unset, and not covered in this article. See also [3]. --Indigo (talk) 18:42, 12 August 2017 (UTC)