1 |
On 12/26/2012 07:47 PM, Walter Dnes wrote: |
2 |
> Many years ago, I understood IPCHAINS, and the first versions of |
3 |
> IPTABLES. However, IPTABLES has followed the example of Larry Wall's |
4 |
> Practical Extraction and Reporting Language |
5 |
> and turned into a pseudo-OS that I barely comprehend. Some rules |
6 |
> that I added many years ago were designed to reject unsolicited |
7 |
> connection attempts (after whitelisting my small LAN)... |
8 |
> |
9 |
> -A ICMP_IN -p icmp -m state -j UNSOLICITED |
10 |
> -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED |
11 |
> -A UDP_IN -p udp -m state -j UNSOLICITED |
12 |
> |
13 |
> Now these all give me the error message... |
14 |
> |
15 |
> WARNING: The state match is obsolete. Use conntrack instead. |
16 |
> iptables-restore v1.4.16.3: state: option "--state" must be specified |
17 |
> |
18 |
|
19 |
The 'conntrack' module is supposed to be a superset of 'state', so most |
20 |
things should be compatible. You really have two warnings there; the |
21 |
first is for the state -> conntrack switch, and the second is because |
22 |
you're missing the --state flag in your rules. |
23 |
|
24 |
In your example, you turn on the state matching, |
25 |
|
26 |
iptables -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED |
27 |
|
28 |
but you don't specify *which* state(s) you want to match. It wants you |
29 |
to specify --state SOMETHING. I'd guess that it used to interpret "no |
30 |
state" as "any state." |
31 |
|
32 |
You said that you whitelisted your LAN prior to that rule, so you're |
33 |
probably just rejecting every {ICMP, TCP, UDP} packet with those three |
34 |
rules. |
35 |
|
36 |
If so, the equivalent rules are just, |
37 |
|
38 |
iptables -A ICMP_IN -p icmp -j DROP |
39 |
iptables -A TCP_IN -p tcp -j DROP |
40 |
iptables -A UDP_IN -p udp -j DROP |
41 |
|
42 |
In other words, you only really need the connection tracking to /accept/ |
43 |
related connections. You don't want to deny related or established |
44 |
connections, usually. And once you have accepted those two types, you |
45 |
can just reject the rest, because they're necessarily new (or in rare |
46 |
cases, "invalid"). |
47 |
|
48 |
I would be wary of this: |
49 |
|
50 |
-A ICMP_IN -p icmp -m conntrack --ctstate INVALID -j UNSOLICITED |
51 |
|
52 |
since if the old rule works like I think it does (reject everything) the |
53 |
new one might allow some things that the old one didn't. |