Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #377 > unrolled thread

iptables DNAT/SNAT/ICMP done right?

Back to article view | Back to comp.os.linux.networking

Contents

  iptables DNAT/SNAT/ICMP done right? Christian Brandt <brandtc@psi5.com> - 2011-06-21 13:41 +0200
    Re: iptables DNAT/SNAT/ICMP done right? Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2011-06-21 23:42 +0200
      Re: iptables DNAT/SNAT/ICMP done right? Christian Brandt <brandtc@psi5.com> - 2011-06-24 10:39 +0200
    Re: iptables DNAT/SNAT/ICMP done right? buck <buck@private.mil> - 2011-06-24 17:45 +0000

#377 — iptables DNAT/SNAT/ICMP done right?

[Multipart message — attachments visible in raw view] — view raw

I would like to ask for a short oppinion about the attached iptables script.

Given is a router with four official external addresses and a /24
internal private network. I try to implement a most draconic concept
only allowing an absolute minimum of services IN, OUT and FORWARD.

The full version of the script is mapping the four official adresses to
four internal addresses. For the discussion I reduced the complexity by
only showing one example of every step, the full version seems to run
fine though may lack elegance and is very ugly to read.

I am uncertain about my implementations of DNAT, SNAT and the importance
of ICMP - though I think ICMP is a good thing to have around in case of
congestion&family.

Your comments are welcome.

Christian Brandt

[toc] | [next] | [standalone]

#380

Hello,

Christian Brandt a écrit :
> 
> I am uncertain about my implementations of DNAT, SNAT and the importance
> of ICMP - though I think ICMP is a good thing to have around in case of
> congestion&family.

You don't describe your requirements, so it is not possible to tell if
your ruleset is adequate.

> # INPUT table
> iptables -A INPUT       -j ACCEPT -m state --state ESTABLISHED,RELATED
> iptables -A INPUT       -j ACCEPT -i lo
> iptables -A INPUT       -j ACCEPT             -p icmp             # ICMP

Required ICMP types (error types) are already in the RELATED state. No
need for a specific rule. Other ICMP types such as echo aka ping are
optional.

> iptables -A INPUT       -j ACCEPT -i $EXT_DEV -p tcp --dport 22   # SSH

If you DNAT and FORWARD all incoming SSH connections to another host,
then this rule will never match. The INPUT chain sees only packets which
are to be delivered to the local host.

> # OUTPUT table
> iptables -A OUTPUT      -j ACCEPT -m state --state ESTABLISHED,RELATED
> iptables -A OUTPUT      -j ACCEPT -o lo
> iptables -A OUTPUT      -j ACCEPT -o $INT_DEV -p icmp             # ICMP
> iptables -A OUTPUT      -j ACCEPT -o $INT_DEV -p tcp --dport 22   # SSH
> iptables -A OUTPUT      -j ACCEPT -o $EXT_DEV -p icmp             # ICMP
> iptables -A OUTPUT      -j ACCEPT -o $EXT_DEV -p tcp -d $MIRROR --dport 80   # HTTP
> 
> # FORWARD table outgoing
> iptables -A FORWARD     -j ACCEPT -m state --state ESTABLISHED,RELATED
> iptables -A FORWARD     -j ACCEPT             -p icmp             # ICMP
> iptables -A FORWARD     -j ACCEPT -o $EXT_DEV -p tcp --dport 22   # SSH
> 
> # PREROUTING table incoming
> iptables -A PREROUTING  -j DNAT   -i $EXT_DEV -p tcp  -d $EXT_IP --dport 22  -t nat --to $INT_SYS:22
> iptables -A FORWARD     -j ACCEPT -i $EXT_DEV -p tcp  -d $EXT_IP --dport 22

You need -d $INT_SYS (the final destination) here.

> iptables -A PREROUTING  -j DNAT   -i $EXT_DEV -p icmp -d $EXT_IP -t nat --to $INT_SYS
> iptables -A FORWARD     -j ACCEPT -i $EXT_DEV -p icmp -d $EXT_IP

Same remark as above. Besides, these two rules are not needed for ICMP
packets in the RELATED state. NAT automatically takes care of them.

> # POSTROUTING table outgoing
> iptables -A POSTROUTING -j SNAT -s $INT_SYS --to-source $EXT_IP -t nat
> 
> # Abschluß
> iptables -A INPUT       -j LOG -m state --state NEW -m limit --limit $LOGLIMIT --log-prefix="netfilter-input-reject "
> iptables -A INPUT       -j REJECT
> iptables -A OUTPUT      -j LOG -m state --state NEW -m limit --limit $LOGLIMIT --log-prefix="netfilter-output-reject "
> iptables -A OUTPUT      -j REJECT
> iptables -A FORWARD     -j LOG -m state --state NEW -m limit --limit $LOGLIMIT --log-prefix="netfilter-forward-reject "
> iptables -A FORWARD     -j REJECT
> 
> echo 1 >/proc/sys/net/ipv4/ip_forward

[toc] | [prev] | [next] | [standalone]

#383

Am 21.06.2011 23:42, schrieb Pascal Hambourg:

> You don't describe your requirements, so it is not possible to tell if
> your ruleset is adequate.

1. Lock up the router completely except SSH. This is mostly the
INPUT/OUTPUT part.

2. Make selected services (in the example SSH) available from external
net to internal clients and visa versa. This is mostly the
PREROUTING/POSTROUTING/FORWARD-part.

>> # INPUT table
>> iptables -A INPUT       -j ACCEPT -m state --state ESTABLISHED,RELATED
>> iptables -A INPUT       -j ACCEPT -i lo
>> iptables -A INPUT       -j ACCEPT             -p icmp             # ICMP
> 
> Required ICMP types (error types) are already in the RELATED state. No
> need for a specific rule. Other ICMP types such as echo aka ping are
> optional.

 Good to know, time to reread the ICMP paragraph. Are there any
objections in leaving ICMP a bit more open? It is just so handy...

>> iptables -A INPUT       -j ACCEPT -i $EXT_DEV -p tcp --dport 22   # SSH
> 
> If you DNAT and FORWARD all incoming SSH connections to another host,
> then this rule will never match. The INPUT chain sees only packets which
> are to be delivered to the local host.

 This rule allows SSH-access to the router. There is no way around sshd.
Because we have a dictionary attack running against this sshd for years
we run sshd in keyonly-authentication-mode. And in the full version we
throttle at two retries per minute.

>> # OUTPUT table
>> iptables -A OUTPUT      -j ACCEPT -m state --state ESTABLISHED,RELATED
>> iptables -A OUTPUT      -j ACCEPT -o lo
>> iptables -A OUTPUT      -j ACCEPT -o $INT_DEV -p icmp             # ICMP
>> iptables -A OUTPUT      -j ACCEPT -o $INT_DEV -p tcp --dport 22   # SSH
>> iptables -A OUTPUT      -j ACCEPT -o $EXT_DEV -p icmp             # ICMP
>> iptables -A OUTPUT      -j ACCEPT -o $EXT_DEV -p tcp -d $MIRROR --dport 80   # HTTP
>>
>> # FORWARD table outgoing
>> iptables -A FORWARD     -j ACCEPT -m state --state ESTABLISHED,RELATED
>> iptables -A FORWARD     -j ACCEPT             -p icmp             # ICMP
>> iptables -A FORWARD     -j ACCEPT -o $EXT_DEV -p tcp --dport 22   # SSH
>>
>> # PREROUTING table incoming
>> iptables -A PREROUTING  -j DNAT   -i $EXT_DEV -p tcp  -d $EXT_IP --dport 22  -t nat --to $INT_SYS:22
>> iptables -A FORWARD     -j ACCEPT -i $EXT_DEV -p tcp  -d $EXT_IP --dport 22
> 
> You need -d $INT_SYS (the final destination) here.

 My mistake, this is a typo in this shortened version, the original on
uses the equivalent of $INT_SYS.

 So I think the basic concept behind the iptables-script is ok - besides
of the obvious typo and the requirement to reread the ICMP stuff.

 Christian Brandt

[toc] | [prev] | [next] | [standalone]

#384

Christian Brandt <brandtc@psi5.com> wrote in
news:itq01e$2bn$1@news.m-online.net: 

> I am uncertain about my implementations of DNAT, SNAT and the
> importance of ICMP - though I think ICMP is a good thing to have
> around in case of congestion&family.

I think you should restrict ICMP by function.

http://www.malibyte.net/iptables/scripts/fwscripts.html
has understandable info.
--
buck

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web