1 |
On Sun, Dec 29, 2013 at 1:07 PM, Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
2 |
> Hi all, |
3 |
> |
4 |
> Ok, I'm setting up a new server, and I'd like to rethink my iptables rules. |
5 |
> |
6 |
> I'd like to start with something fairly simple: |
7 |
> |
8 |
> 1. Allow connections from anywhere ONLY to certain ports |
9 |
> |
10 |
> ie, for encrypted IMAP/SMTP connections from users |
11 |
> |
12 |
> 2. Allow connections from only certain IP addresses to certain ports |
13 |
> |
14 |
> ie, for limiting SSH access |
15 |
> |
16 |
|
17 |
I'd reverse the order that #1 and #2 appear. |
18 |
|
19 |
> 3. DROP ALL other connection attempts |
20 |
> |
21 |
> ie, I don't want to see these disallowed attempts in the logs |
22 |
> |
23 |
> In order to keep my rules more manageable, I have a commented text file that |
24 |
> I manually edit whenever modifying my rules, then I do an 'iptables-restore |
25 |
> < /path/to/iptables-rules' to update them. |
26 |
> |
27 |
> My first question is about a trick I learned some time ago (but don't |
28 |
> remember where)... |
29 |
> |
30 |
> For the ports for which I want to allow only restricted access, I have |
31 |
> something like: |
32 |
> |
33 |
> ####################### |
34 |
> # bgn exceptions blocks |
35 |
> ####################### |
36 |
> :f_22_I - [0:0] |
37 |
> :f_25_I - [0:0] |
38 |
> :f_22_O - [0:0] |
39 |
> :f_25_O - [0:0] |
40 |
> |
41 |
> Am I correct that the above are what are called 'chains' in iptables speak? |
42 |
> |
43 |
|
44 |
That defines non-kernel chains but you still need to jump to them from |
45 |
INPUT/OUTPUT or whatever. So, something like: |
46 |
-A -m tcp -p tcp --dport 22 --sport 1024:65535 -j f_22_I |
47 |
^^^^^ I just |
48 |
came up with something for the sport - it's possible there's a default |
49 |
mor narrower for your client. |
50 |
|
51 |
> # |
52 |
> ### allow connections only from the following IP's |
53 |
> # |
54 |
> ## SSH |
55 |
> # |
56 |
> # my local admin hosts |
57 |
> -A f_22_I -s ###.###.###.### -j ACCEPT |
58 |
> -A f_22_I -s ###.###.###.### -j ACCEPT |
59 |
> -A f_22_I -s ###.###.###.### -j ACCEPT |
60 |
> -A f_22_I -s ###.###.###.### -j ACCEPT |
61 |
> -A f_22_I -s ###.###.###.### -j ACCEPT |
62 |
> # |
63 |
> # external hosts |
64 |
> -A f_22_I -s ###.###.###.### -j ACCEPT |
65 |
> -A f_22_I -s ###.###.###.### -j ACCEPT |
66 |
> |
67 |
> And am I also correct that the above adds each rule to the named chain in |
68 |
> order, and that the order is significant? |
69 |
|
70 |
Yep - like ACLs, rules are processed from top down. ACCEPT, REJECT, |
71 |
and DROP are end points when they match. |
72 |
|
73 |
> |
74 |
> So, if I wanted to add a last rule to that chain that DROPs all other |
75 |
> connection attempts, it would be just: |
76 |
> |
77 |
> -A f_22_I -j DROP |
78 |
|
79 |
I would do this just because it simplifies my life when looking at |
80 |
stuff (and probably removes microseconds of processing from the |
81 |
kernel). Only do this if you limit what hits this jump though (with |
82 |
--dport or whatever). Otherwise, the default behavior is basically a |
83 |
-j RETURN. |
84 |
|
85 |
> |
86 |
> ? |
87 |
> |
88 |
> Then... assuming that I have all of the specific rules after these set up to |
89 |
> allow just the traffic I want, and I wanted to add a final rule that just |
90 |
> silently DROPped all other inbound connection attempts, it would be: |
91 |
> |
92 |
> -A INPUT -j DROP |
93 |
> |
94 |
|
95 |
What you're looking for is the policy which are by default ACCEPT on |
96 |
all kernel rules and which you change in the save file with something |
97 |
like this: |
98 |
:INPUT DROP [0:0] |
99 |
|
100 |
And, just so that there's no confusion, you should state the policy of |
101 |
OUTPUT and FORWARD at the top of your save file along with INPUT - see |
102 |
the output of iptables-save as an example of what your file should |
103 |
look like. |
104 |
|
105 |
Also, if you're creating a chain just to do the same thing with |
106 |
different addresses, look at using ipset. Then you just: |
107 |
ipset create ssh_in iphash |
108 |
ipset add ssh_in 1.2.3.4 |
109 |
|
110 |
and then this works: |
111 |
-A -m set --match-set ssh_in src -j ACCEPT |
112 |
|
113 |
ipset has the same save/load type things as ipt (minor differences |
114 |
with how you handle reload, but google or ask if you want to know). |
115 |
The set needs to be in place before the ipt rule is added, so ipset |
116 |
comes first in your boot sequence. |
117 |
|
118 |
> ? |
119 |
> |
120 |
> Thanks... |
121 |
> |