Nat and firewall holes

Nat and firewall holes

[ratheesh k]

hi ,

I have a linux machine'( say B )  with two interfaces ( eth0
-192.168.1.1  and eth1 - 192.168.55.1 ) .This linux machine works as a
gateway machine . eth0 is connected to LAN network and eth1 is
connected to WAN network . below rules are applied on the gateway
machine .,

    iptables -A  INPUT -i eth0 -j ACCEPT
    iptables -A INPUT  -i eth1 -j DROP

    iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
    iptables -A FORWARD -i eth1 -o eth0 -j DROP

    iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE .


LAN ---> eth0 : Gateway linux machine :eth1 ---> WAN

We have machine called A , connected to LAN network and is assigned an
ip 192.168.1.100 and its gateway is machine B's eth0 interface (
192.168.1.1 ) .
if i access "google.com " from machine A , syn packet with dest ip as
a.b.c.d ( google.com ip ) and  dest port 80 will go to machine B
(default gateway ) . Since we are masquerading all the packets , it
will change  source ip with 192.168.55.1 and source port with some
random port ( say portx ) . Packets from server will be having
192.18.55.1 ip and port as portx . This will be changed to original ip
and port by conntrack module .

 My qustion is : if i create a packet with source ip as 192.168.55.1
and dest port as portx , can i get into the machine B from WAN side .

Thanks,
Ratheesh.

Re: Nat and firewall holes

[Jan Engelhardt]

On Monday 2010-03-22 16:46, ratheesh k wrote:

>We have machine called A , connected to LAN network and is assigned an
>ip 192.168.1.100 and its gateway is machine B's eth0 interface (
>192.168.1.1 ) .
>if i access "google.com " from machine A , syn packet with dest ip as
>a.b.c.d ( google.com ip ) and  dest port 80 will go to machine B
>(default gateway ) . Since we are masquerading all the packets , it
>will change  source ip with 192.168.55.1 and source port with some
>random port ( say portx ) . Packets from server will be having
>192.18.55.1 ip and port as portx . This will be changed to original ip
>and port by conntrack module .
>
> My qustion is : if i create a packet with source ip as 192.168.55.1
>and dest port as portx , can i get into the machine B from WAN side .

Yes.

Re: Nat and firewall holes

[Pascal Hambourg]

ratheesh k a écrit :
> 
> I have a linux machine'( say B )  with two interfaces ( eth0
> -192.168.1.1  and eth1 - 192.168.55.1 ) .This linux machine works as a
> gateway machine . eth0 is connected to LAN network and eth1 is
> connected to WAN network . below rules are applied on the gateway
> machine .,
> 
>     iptables -A  INPUT -i eth0 -j ACCEPT
>     iptables -A INPUT  -i eth1 -j DROP
> 
>     iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
>     iptables -A FORWARD -i eth1 -o eth0 -j DROP

Hmm, not sure that dropping everything received on eth1 is a good idea.

>     iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE .
> 
> 
> LAN ---> eth0 : Gateway linux machine :eth1 ---> WAN
> 
> We have machine called A , connected to LAN network and is assigned an
> ip 192.168.1.100 and its gateway is machine B's eth0 interface (
> 192.168.1.1 ) .
> if i access "google.com " from machine A , syn packet with dest ip as
> a.b.c.d ( google.com ip ) and  dest port 80 will go to machine B
> (default gateway ) . Since we are masquerading all the packets , it
> will change  source ip with 192.168.55.1 and source port with some
> random port ( say portx ) .

MASQUERADE won't change the source port unless specified otherwise by
--random or --to-ports options, or if it is necessary in order to avoid
a "collision" with an existing connection (e.g. two clients connecting
to the same server with the same source port). See iptables man page.

> Packets from server will be having
> 192.18.55.1 ip and port as portx . This will be changed to original ip
> and port by conntrack module .

Actually the conntrack module will only associate the packet to the
existing connection, and the nat module will change the addresses and ports.

>  My qustion is : if i create a packet with source ip as 192.168.55.1
> and dest port as portx , can i get into the machine B from WAN side .

Do you mean machine A (the client) ?
If a crafted packet matches all the characteristics of the conntrack
entry for that connection (including reply source port 80, TCP sequence
number), then it will be considered belonging to the reply direction of
that connection and the NAT will process it accordingly.

Re: Nat and firewall holes

[ratheesh k]

>On Mon, Mar 22, 2010 at 10:42 PM, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote:
> If a crafted packet matches all the characteristics of the conntrack
> entry for that connection (including reply source port 80, TCP sequence
> number), then it will be considered belonging to the reply direction of
> that connection and the NAT will process it accordingly.


i thought ,  only a tuple of ip and port is kept for connection
tracking ( not tcp sequence )  .



On Mon, Mar 22, 2010 at 10:42 PM, Pascal Hambourg
<pascal.mail@plouf.fr.eu.org> wrote:
> ratheesh k a écrit :
>>
>> I have a linux machine'( say B )  with two interfaces ( eth0
>> -192.168.1.1  and eth1 - 192.168.55.1 ) .This linux machine works as a
>> gateway machine . eth0 is connected to LAN network and eth1 is
>> connected to WAN network . below rules are applied on the gateway
>> machine .,
>>
>>     iptables -A  INPUT -i eth0 -j ACCEPT
>>     iptables -A INPUT  -i eth1 -j DROP
>>
>>     iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
>>     iptables -A FORWARD -i eth1 -o eth0 -j DROP
>
> Hmm, not sure that dropping everything received on eth1 is a good idea.
>
>>     iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE .
>>
>>
>> LAN ---> eth0 : Gateway linux machine :eth1 ---> WAN
>>
>> We have machine called A , connected to LAN network and is assigned an
>> ip 192.168.1.100 and its gateway is machine B's eth0 interface (
>> 192.168.1.1 ) .
>> if i access "google.com " from machine A , syn packet with dest ip as
>> a.b.c.d ( google.com ip ) and  dest port 80 will go to machine B
>> (default gateway ) . Since we are masquerading all the packets , it
>> will change  source ip with 192.168.55.1 and source port with some
>> random port ( say portx ) .
>
> MASQUERADE won't change the source port unless specified otherwise by
> --random or --to-ports options, or if it is necessary in order to avoid
> a "collision" with an existing connection (e.g. two clients connecting
> to the same server with the same source port). See iptables man page.
>
>> Packets from server will be having
>> 192.18.55.1 ip and port as portx . This will be changed to original ip
>> and port by conntrack module .
>
> Actually the conntrack module will only associate the packet to the
> existing connection, and the nat module will change the addresses and ports.
>
>>  My qustion is : if i create a packet with source ip as 192.168.55.1
>> and dest port as portx , can i get into the machine B from WAN side .
>
> Do you mean machine A (the client) ?
> If a crafted packet matches all the characteristics of the conntrack
> entry for that connection (including reply source port 80, TCP sequence
> number), then it will be considered belonging to the reply direction of
> that connection and the NAT will process it accordingly.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Nat and firewall holes

[Pascal Hambourg]

ratheesh k a écrit :
>> On Mon, Mar 22, 2010 at 10:42 PM, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote:
>> If a crafted packet matches all the characteristics of the conntrack
>> entry for that connection (including reply source port 80, TCP sequence
>> number), then it will be considered belonging to the reply direction of
>> that connection and the NAT will process it accordingly.
> 
> i thought ,  only a tuple of ip and port is kept for connection
> tracking ( not tcp sequence )  .

Window and sequence number tracking has been included in TCP connection
tracking since kernel 2.6.9, making out-of-window segments INVALID.

Re: Nat and firewall holes

[ratheesh k]

>>> On Mon, Mar 22, 2010 at 10:42 PM, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote
> Window and sequence number tracking has been included in TCP connection
> tracking since kernel 2.6.9, making out-of-window segments INVALID.

Beautiful ...
So this packet will be rejected by
iptables -A FORWARD -m state --state INVALID -j DROP  rule ??



Thanks,
RAtheesh

On Mon, Mar 22, 2010 at 11:09 PM, Pascal Hambourg
<pascal.mail@plouf.fr.eu.org> wrote:
> ratheesh k a écrit :
>>> On Mon, Mar 22, 2010 at 10:42 PM, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote:
>>> If a crafted packet matches all the characteristics of the conntrack
>>> entry for that connection (including reply source port 80, TCP sequence
>>> number), then it will be considered belonging to the reply direction of
>>> that connection and the NAT will process it accordingly.
>>
>> i thought ,  only a tuple of ip and port is kept for connection
>> tracking ( not tcp sequence )  .
>
> Window and sequence number tracking has been included in TCP connection
> tracking since kernel 2.6.9, making out-of-window segments INVALID.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Nat and firewall holes

[Pascal Hambourg]

ratheesh k a écrit :
>>>> On Mon, Mar 22, 2010 at 10:42 PM, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote
>> Window and sequence number tracking has been included in TCP connection
>> tracking since kernel 2.6.9, making out-of-window segments INVALID.
> 
> Beautiful ...
> So this packet will be rejected by
> iptables -A FORWARD -m state --state INVALID -j DROP  rule ??

Actually not in your masquerading setup : INVALID packets skip NAT
(which is good enough a reason to DROP them in a NAT setup, in order to
prevent private addresses from leaking outside), so the packet won't be
demasqueraded and will fall into the INPUT chain instead of the FORWARD
chain.

Re: Nat and firewall holes

[ratheesh k]

>> Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote
>Actually not in your masquerading setup : INVALID packets skip NAT
> (which is good enough a reason to DROP them in a NAT setup, in order to
> prevent private addresses from leaking outside), so the packet won't be
> demasqueraded and will fall into the INPUT chain instead of the FORWARD
> chain.

 beautiful answer .
 Thanks a ton for  your valuable time .