On Sun, Dec 29, 2013 at 1:07 PM, Tanstaafl <tansta...@libertytrek.org> wrote:
> Hi all,
>
> Ok, I'm setting up a new server, and I'd like to rethink my iptables rules.
>
> I'd like to start with something fairly simple:
>
> 1. Allow connections from anywhere ONLY to certain ports
>
> ie, for encrypted IMAP/SMTP connections from users
>
> 2. Allow connections from only certain IP addresses to certain ports
>
> ie, for limiting SSH access
>
I'd reverse the order that #1 and #2 appear.
> 3. DROP ALL other connection attempts
>
> ie, I don't want to see these disallowed attempts in the logs
>
> In order to keep my rules more manageable, I have a commented text file that
> I manually edit whenever modifying my rules, then I do an 'iptables-restore
> < /path/to/iptables-rules' to update them.
>
> My first question is about a trick I learned some time ago (but don't
> remember where)...
>
> For the ports for which I want to allow only restricted access, I have
> something like:
>
> #######################
> # bgn exceptions blocks
> #######################
> :f_22_I - [0:0]
> :f_25_I - [0:0]
> :f_22_O - [0:0]
> :f_25_O - [0:0]
>
> Am I correct that the above are what are called 'chains' in iptables speak?
>
That defines non-kernel chains but you still need to jump to them from
INPUT/OUTPUT or whatever. So, something like:
-A -m tcp -p tcp --dport 22 --sport 1024:65535 -j f_22_I
^^^^^ I just
came up with something for the sport - it's possible there's a default
mor narrower for your client.
> #
> ### allow connections only from the following IP's
> #
> ## SSH
> #
> # my local admin hosts
> -A f_22_I -s ###.###.###.### -j ACCEPT
> -A f_22_I -s ###.###.###.### -j ACCEPT
> -A f_22_I -s ###.###.###.### -j ACCEPT
> -A f_22_I -s ###.###.###.### -j ACCEPT
> -A f_22_I -s ###.###.###.### -j ACCEPT
> #
> # external hosts
> -A f_22_I -s ###.###.###.### -j ACCEPT
> -A f_22_I -s ###.###.###.### -j ACCEPT
>
> And am I also correct that the above adds each rule to the named chain in
> order, and that the order is significant?
Yep - like ACLs, rules are processed from top down. ACCEPT, REJECT,
and DROP are end points when they match.
>
> So, if I wanted to add a last rule to that chain that DROPs all other
> connection attempts, it would be just:
>
> -A f_22_I -j DROP
I would do this just because it simplifies my life when looking at
stuff (and probably removes microseconds of processing from the
kernel). Only do this if you limit what hits this jump though (with
--dport or whatever). Otherwise, the default behavior is basically a
-j RETURN.
>
> ?
>
> Then... assuming that I have all of the specific rules after these set up to
> allow just the traffic I want, and I wanted to add a final rule that just
> silently DROPped all other inbound connection attempts, it would be:
>
> -A INPUT -j DROP
>
What you're looking for is the policy which are by default ACCEPT on
all kernel rules and which you change in the save file with something
like this:
:INPUT DROP [0:0]
And, just so that there's no confusion, you should state the policy of
OUTPUT and FORWARD at the top of your save file along with INPUT - see
the output of iptables-save as an example of what your file should
look like.
Also, if you're creating a chain just to do the same thing with
different addresses, look at using ipset. Then you just:
ipset create ssh_in iphash
ipset add ssh_in 1.2.3.4
and then this works:
-A -m set --match-set ssh_in src -j ACCEPT
ipset has the same save/load type things as ipt (minor differences
with how you handle reload, but google or ask if you want to know).
The set needs to be in place before the ipt rule is added, so ipset
comes first in your boot sequence.
> ?
>
> Thanks...
>
