On 2013-12-29 1:39 PM, shawn wilson <ag4ve...@gmail.com> wrote:
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.
Well, I was just writing that as a general description. Looking in the rules
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
Well, yeah... I didn't post my entire ruleset... ;)
^^^^^ I just
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.
Good, thanks.
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.
Ok, well, maybe I should have posted my entire ruleset...
I have this above where I define my chains:
#
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
#
Does it matter where this goes?
And then above that, I have something else that I've never understood:
*mangle
:PREROUTING ACCEPT [1378800222:449528056411]
:INPUT ACCEPT [1363738727:447358082301]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1221121261:1103241097263]
:POSTROUTING ACCEPT [1221116979:1103240864155]
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,PSH,URG -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
COMMIT
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, looks interesting and useful...
So much to learn, so little time... ;)
