Re: [gentoo-user] IPTables question... simple as possible for starters

[Tanstaafl]

On 2013-12-29 1:39 PM, shawn wilson <ag4ve.us@×××××.com> wrote:
> On Sun, Dec 29, 2013 at 1:07 PM, Tanstaafl <tanstaafl@×××××××××××.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... ;)