Talk:Simple stateful firewall

From ArchWiki
Jump to: navigation, search

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)