philosophical question regarding NAT

philosophical question regarding NAT

[Ian Laurie]

I've got a philosophical question regarding NAT as follows.

Imagine the following unrealistic gateway firewall:

## eth0 = WAN, eth1 = LAN
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

Although NAT is enabled and LAN side systems will be NATed to the 
gateway's WAN side IP address, WAN side systems can still access 
systems on the inside of the firewall if they know what the LAN 
side addresses are (and have a route to the gateway somehow).

In other words, even though NAT is active the bridging function 
provided by ip_forward is still happening as well.

It seems you can disable the bridging function with the following 
PREROUTING rule:

-A PREROUTING -i eth0 -d <private_lan_block> -j DROP

which enforces NAT, ie, only NATed things can get through.  While 
you can achieve the same thing by setting policy of FORWARD to DROP 
and allowing only RELATED and ESTABLISHED stuff through (which I do)
I am surprised I have not seen this PREROUTING rule used more 
often as a safety measure.

It doesn't seem to break anything, does anyone know why this 
technique isn't seen more often?

Ian

Re: philosophical question regarding NAT

[Vasilii.Alferov]

Ian Laurie wrote:

> I've got a philosophical question regarding NAT as follows.
> 
> Imagine the following unrealistic gateway firewall:
> 
> ## eth0 = WAN, eth1 = LAN
> *nat
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A POSTROUTING -o eth0 -j MASQUERADE
> COMMIT
> 
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> COMMIT
> 
> Although NAT is enabled and LAN side systems will be NATed to the
> gateway's WAN side IP address, WAN side systems can still access
> systems on the inside of the firewall if they know what the LAN
> side addresses are (and have a route to the gateway somehow).
> 
> In other words, even though NAT is active the bridging function
> provided by ip_forward is still happening as well.
> 
> It seems you can disable the bridging function with the following
> PREROUTING rule:
> 
> -A PREROUTING -i eth0 -d <private_lan_block> -j DROP
> 
> which enforces NAT, ie, only NATed things can get through.  While
> you can achieve the same thing by setting policy of FORWARD to DROP
> and allowing only RELATED and ESTABLISHED stuff through (which I do)
> I am surprised I have not seen this PREROUTING rule used more
> often as a safety measure.
> 
> It doesn't seem to break anything, does anyone know why this
> technique isn't seen more often?
> 
> Ian


More effective solution is to enable rp_filter in kernel using proc
filesystem or sysctl. It prevents anyone from spoofing IP addresses.

Vasilii.

Re: philosophical question regarding NAT

[Ian Laurie]

> More effective solution is to enable rp_filter in kernel using proc
> filesystem or sysctl. It prevents anyone from spoofing IP addresses.

DOH!!  How right you are..... rp_filter slipped my mind completely.

Thank you for reminding me.

Ian

Problem adding connlimit rule

[Ruben Cardenal]

Hi,

  I'm trying to add a quite simple rule but I get an error:

# iptables -I INPUT -p tcp --syn --dport 25 -m connlimit --connlimit-above
10 -j REJECT
iptables: No chain/target/match by that name

But:

# lsmod
Module                  Size  Used by    Tainted: PF 
ipt_REJECT              3160   0  (unused)
ipt_conntrack           1176   0  (unused)
ipt_limit               1048   0  (unused)
ipt_iplimit             1560   0  (unused)
ipt_TARPIT              2104   0  (unused)
af_packet              14792   0  (autoclean)
esm                    71503   1 
nls_cp437               4348   1  (autoclean)
nls_iso8859-1           2844   1  (autoclean)
smbfs                  40144   1  (autoclean)
nfsd                   85168   0  (autoclean)
abi-ibcs                6604   0  (autoclean) (unused)
abi-svr4               79620   0  (autoclean) [abi-ibcs]
lcall7                  1728   0  (autoclean) [abi-ibcs]
abi-util                2176   0  (autoclean) [abi-svr4 lcall7]
iptable_nat            17638   0  (autoclean) (unused)
ip_conntrack           19384   3  (autoclean) [ipt_conntrack ipt_iplimit
iptable_nat]
iptable_mangle          2200   0  (autoclean) (unused)
iptable_filter          1708   1  (autoclean)
ip_tables              11808  10  [ipt_REJECT ipt_conntrack ipt_limit
ipt_iplimit ipt_TARPIT iptable_nat iptable_mangle iptable_filter]
ide-cd                 32252   0  (autoclean)
isa-pnp                32520   0  (unused)
ipv6                  179508  -1  (autoclean)
st                     30740   0  (autoclean) (unused)
sr_mod                 13624   0  (autoclean) (unused)
cdrom                  30496   0  (autoclean) [ide-cd sr_mod]
sg                     29276   0  (autoclean)
mousedev                4536   0  (unused)
joydev                  5984   0  (unused)
evdev                   4352   0  (unused)
input                   3488   0  [mousedev joydev evdev]
usb-ohci               22056   0  (unused)
usbcore                66508   1  [usb-ohci]
raw1394                16756   0  (unused)
ieee1394               38064   0  [raw1394]
bcm5700                82948   1 
e100                   56328   1 
perle-serial           43144   1 
lvm-mod                70500   0  (autoclean)
quota_v2                7408   0 
reiserfs              227988   4 
aacraid                27748   8 

  Am I missing any module?

  I'm using iptables v1.3.1 on a SuSe.

  Regards,

- Ruben

Re: philosophical question regarding NAT

[Francesco Ciocchetti]

Ian Laurie wrote:

>
> which enforces NAT, ie, only NATed things can get through.  While you
> can achieve the same thing by setting policy of FORWARD to DROP and
> allowing only RELATED and ESTABLISHED stuff through (which I do)
> I am surprised I have not seen this PREROUTING rule used more often as
> a safety measure.
>
> It doesn't seem to break anything, does anyone know why this technique
> isn't seen more often?
>
> Ian
>
>
It does not break anything to put a DROP Target Rule in Prerouting Chain
of nat table ,  but it should be done not because of a ... convention :)

i mean , there are 3 Tables ok? and each of them has its scope.

NAT for Address Translations.
FILTER for filtering packets.
MANGLE for dealing with packet flags and so on ...

Why DROPPING in NAT Table instead of doint this in its chain ? i don't
think is a Performance Issue ... ok, Dropping as soon as possible can
reserve some resources, but do you really need to reserve these ? how
many rules u have ?

Use Tables for what is its scope because of Packet Traversing Scheme and
Flow Control, this is my Hint.

BTW is Normal that using only NAT will leave a lot of Holes in your
Firewall, NAT is just one piece of your NET Security ... Filtering is
another one ;)

Bye

Re: Problem adding connlimit rule

[Jason Opperisano]

On Tue, May 10, 2005 at 01:26:24PM +0200, Ruben Cardenal wrote:
> Hi,
> 
>   I'm trying to add a quite simple rule but I get an error:
> 
> # iptables -I INPUT -p tcp --syn --dport 25 -m connlimit --connlimit-above
> 10 -j REJECT
> iptables: No chain/target/match by that name
> 
> But:
> 
> # lsmod
> Module                  Size  Used by    Tainted: PF 
> ipt_REJECT              3160   0  (unused)
> ipt_conntrack           1176   0  (unused)
> ipt_limit               1048   0  (unused)
> ipt_iplimit             1560   0  (unused)
> ipt_TARPIT              2104   0  (unused)
> af_packet              14792   0  (autoclean)
> esm                    71503   1 
> nls_cp437               4348   1  (autoclean)
> nls_iso8859-1           2844   1  (autoclean)
> smbfs                  40144   1  (autoclean)
> nfsd                   85168   0  (autoclean)
> abi-ibcs                6604   0  (autoclean) (unused)
> abi-svr4               79620   0  (autoclean) [abi-ibcs]
> lcall7                  1728   0  (autoclean) [abi-ibcs]
> abi-util                2176   0  (autoclean) [abi-svr4 lcall7]
> iptable_nat            17638   0  (autoclean) (unused)
> ip_conntrack           19384   3  (autoclean) [ipt_conntrack ipt_iplimit
> iptable_nat]
> iptable_mangle          2200   0  (autoclean) (unused)
> iptable_filter          1708   1  (autoclean)
> ip_tables              11808  10  [ipt_REJECT ipt_conntrack ipt_limit
> ipt_iplimit ipt_TARPIT iptable_nat iptable_mangle iptable_filter]
> ide-cd                 32252   0  (autoclean)
> isa-pnp                32520   0  (unused)
> ipv6                  179508  -1  (autoclean)
> st                     30740   0  (autoclean) (unused)
> sr_mod                 13624   0  (autoclean) (unused)
> cdrom                  30496   0  (autoclean) [ide-cd sr_mod]
> sg                     29276   0  (autoclean)
> mousedev                4536   0  (unused)
> joydev                  5984   0  (unused)
> evdev                   4352   0  (unused)
> input                   3488   0  [mousedev joydev evdev]
> usb-ohci               22056   0  (unused)
> usbcore                66508   1  [usb-ohci]
> raw1394                16756   0  (unused)
> ieee1394               38064   0  [raw1394]
> bcm5700                82948   1 
> e100                   56328   1 
> perle-serial           43144   1 
> lvm-mod                70500   0  (autoclean)
> quota_v2                7408   0 
> reiserfs              227988   4 
> aacraid                27748   8 
> 
>   Am I missing any module?

do *you* see ipt_connlimit in that list?  i don't.

>   I'm using iptables v1.3.1 on a SuSe.

i'll take a stab in the dark, and say that you're running SuSE 9.3,
which does not ship support for the connlimit match in its default kernel.

- download kernel source, iptables source, and PoM source
- apply connlimit patch from PoM
- recompile kernel
- recompile iptables (probably not absolutely necessary in this case)
- reboot with new kernel
- use connlimit

-j

--
"Stewie: Do these huggies make my ass look big?"
        --Family Guy

Re: philosophical question regarding NAT

[Taylor, Grant]

> Although NAT is enabled and LAN side systems will be NATed to the 
> gateway's WAN side IP address, WAN side systems can still access systems 
> on the inside of the firewall if they know what the LAN side addresses 
> are (and have a route to the gateway somehow).
> 
> In other words, even though NAT is active the bridging function provided 
> by ip_forward is still happening as well.
> 
> It seems you can disable the bridging function with the following 
> PREROUTING rule:
> 
> -A PREROUTING -i eth0 -d <private_lan_block> -j DROP
> 
> which enforces NAT, ie, only NATed things can get through.  While you 
> can achieve the same thing by setting policy of FORWARD to DROP and 
> allowing only RELATED and ESTABLISHED stuff through (which I do)
> I am surprised I have not seen this PREROUTING rule used more often as a 
> safety measure.
> 
> It doesn't seem to break anything, does anyone know why this technique 
> isn't seen more often?

Usually (as far as I know any way) there are accompanying rules that will only allow any traffic form the internal LAN to pass out to the internet (assuming that you don't want to do any Q & A filtering) and ONLY allow ESTABLISHED and RELATED stateful traffic back in from the internet to the internal LAN.  If you have corresponding INPUT rules on your firewall I think that a LOT of what you are thinking about will be stopped at the firewall it's self.  To my knowledge this is what the statful matching is for.  Does any one care to comment on this?



Grant. . . .