Hello, > iptables -A FORWARD -p tcp -m state --state NEW -j ACCEPT > > The Problem: > ------------ > When sending an ACK packet, the packet is allowed through the filter. > Due to the second rule. This means that ACK packets are accepted as > being in the state NEW and does not create an entry in the state table. > So if any rule state that we allow NEW connections, this rule can be > used for port scanning.
The "problem" has been reported here several times, already. > We were wondering if this is intentional due to some reason that we > cannot see or if it is a flaw as suggested ? The behaviour is intentional. The reason is "connection pickup". Imagine a situation where the firewall reboots. All active conntracking information will be lost. With the observed behaviour, connections are "relearned" on the fly as they create new traffic. > A Solution: > ----------- > As a temporary hack the following rule can be added as the second rule: > > iptables -A FORWARD -p tcp --tcp-flags ACK ACK -j DROP This is indeed only an ugly hack. Make your students think about what exactly they want. Somehow, new connections need to be accepted, or you wouldn't have anything to match the ESTABLISHED rule. The thing you want to at least accept, are packets with SYN set, and the SYN/ACK in the opposite direction. A real forwarding table will additionally match on certain ports, to make sure even the SYN is only accepted for permitted protocols. Thus, you want a ruleset like this to properly do "no connection pickup". I assume we are talking about tcp, only: 1) permit ESTABLISHED 2) deny INVALID (now only state NEW should be left, right?) 3) deny packets which are neither SYN nor SYN/ACK 4-N) specifically permit the desired protocols, using port based matches. > We have found something about it in the Iptables tutorial (1.1.8), > page 54 (Appendix B, "State NEW packets but no SYN bit set"). > But, this is not really convincing. I hope I could explain the rationale, and how to cope if your policy demands it, a bit better. best regards Patrick
