1 |
On Jan 3, 2013 4:40 AM, "Michael Orlitzky" <michael@××××××××.com> wrote: |
2 |
> |
3 |
> On 12/30/12 22:21, Walter Dnes wrote: |
4 |
> > OK, here is version 2. I had "an excellent adventure" along the way. |
5 |
> > |
6 |
> |
7 |
> I'm doing the upgrade on our servers right now, and there's another |
8 |
> possible gotcha: the newer iptables (requiring conntrack) requires |
9 |
> NETFILTER_XT_MATCH_CONNTRACK support in the kernel. This is in contrast |
10 |
> to the state matches which used NETFILTER_XT_MATCH_STATE. |
11 |
> |
12 |
> To minimize downtime during the switch, I'm doing, |
13 |
> |
14 |
> 1. Rebuild the kernel, enable conntrack and disable state. |
15 |
> |
16 |
> 2. Fix my iptables-config script to use the conntrack stuff |
17 |
> |
18 |
> 3. Create a dummy set of rules that allows me to SSH in (without |
19 |
> state matching) |
20 |
> |
21 |
> 4. Run and save those rules |
22 |
> |
23 |
> 5. Reboot to new kernel |
24 |
> |
25 |
> 6. SSH in and run iptables-config |
26 |
> |
27 |
> 7. Save the rules |
28 |
> |
29 |
> |
30 |
> > [0:0] -A INPUT -s 192.168.123.248/29 -i eth0 -j ACCEPT |
31 |
> > [0:0] -A INPUT -s 169.254.0.0/16 -i eth0 -j ACCEPT |
32 |
> > [0:0] -A INPUT -i lo -j ACCEPT |
33 |
> > [0:0] -A INPUT -m conntrack --ctstate INVALID,NEW -j UNSOLICITED |
34 |
> > [0:0] -A INPUT -p tcp -m multiport --dports 0:1023,6000:6063 -j |
35 |
BAD_DPORT |
36 |
> > [0:0] -A INPUT -p udp -m multiport --dports 0:1023,6000:6063 -j |
37 |
BAD_DPORT |
38 |
> > [0:0] -A INPUT -s 69.63.176.0/20 -j FECESBOOK |
39 |
> > [0:0] -A INPUT -s 69.220.144.0/20 -j FECESBOOK |
40 |
> > [0:0] -A INPUT -s 69.63.176.0/20 -j FECESBOOK |
41 |
> > [0:0] -A INPUT -s 69.171.224.0/19 -j FECESBOOK |
42 |
> > [0:0] -A INPUT -s 200.58.112.0/20 -j FECESBOOK |
43 |
> > [0:0] -A INPUT -s 213.155.64.0/19 -j FECESBOOK |
44 |
> > [0:0] -A INPUT -s 10.0.0.0/8 -j PRIVATE_LOG |
45 |
> > [0:0] -A INPUT -s 127.0.0.0/8 -j PRIVATE_LOG |
46 |
> > [0:0] -A INPUT -s 172.16.0.0/12 -j PRIVATE_LOG |
47 |
> > [0:0] -A INPUT -s 192.168.0.0/16 -j PRIVATE_LOG |
48 |
> > [0:0] -A INPUT -p icmp -j ICMP_IN |
49 |
> > [0:0] -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT |
50 |
> |
51 |
> These rules will be evaluated in order. I have no evidence for this, but |
52 |
> I suspect you're better off accepting the ESTABLISHED,RELATED stuff |
53 |
> earlier in the chain so you don't slow down the packets that you want. |
54 |
> |
55 |
|
56 |
True. But you will want to filter out 'suspicious' packets beforehand. |
57 |
|
58 |
In my previous employment, I had a Gentoo-based firewall with more than 100 |
59 |
lines of rules. Plus I also employ 'ipset' to allow on-the-fly manipulation |
60 |
of blocking/routing. |
61 |
|
62 |
If you want to see the whole nine yards, I can try asking my replacement to |
63 |
send me the whole deal. |
64 |
|
65 |
Rgds, |
66 |
-- |