Talk:Simple stateful firewall
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.
- 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
- (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)
The note about ICMPv6 Neighbor Discovery
At section 2.4, Simple_stateful_firewall#The_INPUT_chain, there is a note that mentions ICMPv6 Neighbor Discovery. The note also suggests iptables -A INPUT -p 41 -j ACCEPT
. It doesn't mentions that it is for the case of forwarding protocol 41 (6to4), and the issue might also applies to straight IPv6.
—This unsigned comment is by Regid (talk) 21:35, 26 August 2018. Please sign your posts with ~~~~!
Resulting ip6tables.rules file
The order seems incorrect, the final ACCEPT coming after the final "REJECT"
-A INPUT -j REJECT --reject-with icmp6-adm-prohibited -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -m conntrack --ctstate NEW -j ACCEPT
If you allow, the entire ip6tables section is a bit approximate (but it dit allow me to create a configuration and I don't think I'm best placed to improve, sorry)
—This unsigned comment is by Spuddie (talk) 09:05, 20 July 2019. Please sign your posts with ~~~~!
Reading rules helper
iptables -S | sorted | colored Lacsap (talk) 07:58, 31 July 2019 (UTC)
Connection state tracking for FORWARD chain
Why don't we track connection state NEW in the chain fw-open?
For example: iptables -A fw-open -d 192.168.0.5 -p tcp --syn --dport 22 -m conntrack --ctstate NEW -j ACCEPT
LetzteInstanz (talk) 05:26, 19 March 2020 (UTC)
ICMPv6 source scope
From Neighbor Discovery for IP version 6 (IPv6):
Note that this specification does not strictly comply with the consistency requirements in [ADDR-SEL] for the scopes of source and destination addresses. It is possible in some cases for hosts to use a source address of a larger scope than the destination address in the IPv6 header.
The source scope should be omit and it is necessarily to add --icmpv6-type neighbour-solicitation,neighbour-advertisement,redirect
# ip6tables -A INPUT -p ipv6-icmp --icmpv6-type neighbour-solicitation,neighbour-advertisement,redirect -j ACCEPT
LetzteInstanz (talk) 10:10, 16 May 2020 (UTC)
# ip6tables -A INPUT -p ipv6-icmp --icmpv6-type router-advertisement -j ACCEPT # ip6tables -A INPUT -p ipv6-icmp --icmpv6-type neighbour-solicitation -j ACCEPT # ip6tables -A INPUT -p ipv6-icmp --icmpv6-type neighbour-advertisement -j ACCEPT # ip6tables -A INPUT -p ipv6-icmp --icmpv6-type redirect -j ACCEPT
LetzteInstanz (talk) 11:24, 16 May 2020 (UTC)
--ctstate INVALID breaks ICMPv6 ping with multicast
Multicast ICMPv6 comes back with conntrack state invalid. LetzteInstanz (talk) 10:27, 27 May 2020 (UTC)
Blocking broadcast and multicast packets forwarding
In addition to the items listed in the Accuracy template, I am not sure that this section is really needed. It looks like a very specific use case and does not fall under the term "simple firewall". -- Duodai (talk) 12:44, 5 May 2021 (UTC)
- Ok, I remove the section because in the current state it raises a lot of questions. I shall not delete the topic on this talk page, so I leave the content of the Accuracy template here:
- Is this really an attack (or just misconfiguration)?
- The default table (
filter
) has no PREROUTING and POSTROUTING chains. Must-t nat
option be used? - If
! --src-type UNICAST
is used, what a reason to set the rules with UNSPEC, BROADCAST, and MULTICAST src-types? - This is not a single machine firewall related topic. Is it better to move this content in #Setting up a NAT gateway?
- The deletion edit: Special:Diff/668140 -- Duodai (talk) 05:29, 7 May 2021 (UTC)