All of lore.kernel.org
 help / color / mirror / Atom feed
* DNAT rule requires extra firewall pinhole
@ 2007-05-25 22:17 Jeff Weber
  2007-05-26 13:44 ` Jan Engelhardt
  2007-05-26 14:52 ` Pascal Hambourg
  0 siblings, 2 replies; 3+ messages in thread
From: Jeff Weber @ 2007-05-25 22:17 UTC (permalink / raw)
  To: netfilter

I've setup DNAT on gateway such that external clients connecting to TCP port 
$SCADA_PORT on the gateway are actually connected to the node $MCB_IP on a 
private network.  Here's my rule:

 $IPTABLES -t nat -A PREROUTING -p tcp -d $DAS_SCADA_IP --dport $SCADA_PORT \
        -i $DAS_SCADA_IF -j DNAT --to $MCB_IP:$SCADA_PORT

The gateway knows how to forward packets between the internal and external 
interfaces.  The above rule works fine.

I've added a firewall rule to block external requests to forward through the 
gateway:

$IPTABLES -A FORWARD -p tcp -i $DAS_SCADA_IF --syn -j DROP

The trouble is, I just found out that the above firewall rule is not 
compatible with my DNAT rule.  That is, DNAT rewrites the destination IP [as 
it should] to the $MCB_IP, then forwards the packet, which then encounters 
the new firewall rule, and is dropped.

So I preceeded the above firewall rule with another rule:
$IPTABLES -A FORWARD -p tcp -i $DAS_SCADA_IF -s $SCADANET -d $MCB_IP \
    --dport $SCADA_PORT -j ACCEPT

which enables the DNAT to work again.  However, a side effect is that now 
external nodes on $SCADANET can forward port=$SCADA_PORT to IP=$MCB_IP 
directly through the firewall.  Granted this is a small pinhole, but I'd like 
to plug it if possible.  I would think that it should be possible to prevent 
all external nodes from forwarding through the firewall, and to prevent 
external hosts from directly "seeing" an internal node on the private net.

Any suggestions?

	TIA,
	Jeff


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: DNAT rule requires extra firewall pinhole
  2007-05-25 22:17 DNAT rule requires extra firewall pinhole Jeff Weber
@ 2007-05-26 13:44 ` Jan Engelhardt
  2007-05-26 14:52 ` Pascal Hambourg
  1 sibling, 0 replies; 3+ messages in thread
From: Jan Engelhardt @ 2007-05-26 13:44 UTC (permalink / raw)
  To: Jeff Weber; +Cc: netfilter


On May 25 2007 17:17, Jeff Weber wrote:
>
>I've added a firewall rule to block external requests to forward through the 
>gateway:
>
>$IPTABLES -A FORWARD -p tcp -i $DAS_SCADA_IF --syn -j DROP

Well that sounds a little broken, because the first packet of a TCP
connection _is_ SYN.

So you might want

 -p tcp ! -d destaddr ! --dport destport --syn -j DROP here...

Alternatively ...

 -p tcp --syn -m conntrack --ctstate DNAT -j ACCEPT
 -p tcp --syn -j DROP


	Jan
-- 


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: DNAT rule requires extra firewall pinhole
  2007-05-25 22:17 DNAT rule requires extra firewall pinhole Jeff Weber
  2007-05-26 13:44 ` Jan Engelhardt
@ 2007-05-26 14:52 ` Pascal Hambourg
  1 sibling, 0 replies; 3+ messages in thread
From: Pascal Hambourg @ 2007-05-26 14:52 UTC (permalink / raw)
  To: netfilter

Hello,

Jeff Weber a écrit :
> I've setup DNAT on gateway such that external clients connecting to TCP port 
> $SCADA_PORT on the gateway are actually connected to the node $MCB_IP on a 
> private network.  Here's my rule:
> 
>  $IPTABLES -t nat -A PREROUTING -p tcp -d $DAS_SCADA_IP --dport $SCADA_PORT \
>         -i $DAS_SCADA_IF -j DNAT --to $MCB_IP:$SCADA_PORT
> 
> I've added a firewall rule to block external requests to forward through the 
> gateway:
> 
> $IPTABLES -A FORWARD -p tcp -i $DAS_SCADA_IF --syn -j DROP
> 
> The trouble is, I just found out that the above firewall rule is not 
> compatible with my DNAT rule.

Indeed. The TCP SYN packet arrives on $DAS_SCADA_IF, so it matches the rule.

> That is, DNAT rewrites the destination IP [as 
> it should] to the $MCB_IP, then forwards the packet, which then encounters 
> the new firewall rule, and is dropped.

Actually DNAT only rewrites the destination and does nothing more. It is 
the routing decision which forwards the packet.

> So I preceeded the above firewall rule with another rule:
> $IPTABLES -A FORWARD -p tcp -i $DAS_SCADA_IF -s $SCADANET -d $MCB_IP \
>     --dport $SCADA_PORT -j ACCEPT
> 
> which enables the DNAT to work again.  However, a side effect is that now 
> external nodes on $SCADANET can forward port=$SCADA_PORT to IP=$MCB_IP 
> directly through the firewall.

Yes, this is a known side effect. Like you I used to worry about it but 
not any more now, considering that accesses via either the internal and 
external addresses have exactly the same effects. Besides, one has to 
know about the internal address in order to use it, so why hide it ?

> Granted this is a small pinhole, but I'd like 
> to plug it if possible.  I would think that it should be possible to prevent 
> all external nodes from forwarding through the firewall, and to prevent 
> external hosts from directly "seeing" an internal node on the private net.

I can think of the following options :

- Drop packets which match "-d $MCB_IP" in the mangle/PREROUTING chain. 
The mangle table is not the preffered way for filtering (you cannot use 
REJECT there) but it works. Do not use the nat table for filtering.

- MARK packets which match "-p tcp -d $DAS_SCADA_IP --dport $SCADA_PORT" 
in the mangle/PREROUTING, then DNAT the marked packet in the 
nat/PREROUTING chain and ACCEPT them in the filter/FORWARD table before 
the DROP rule. Or MARK the packets which do not match, don't DNAT them 
and DROP/REJECT them.

- In the filter/FORWARD chain, ACCEPT only packets matching
"-m conntrack --ctstate DNAT --ctorigdst $DAS_SCADA_IP", that is with 
the external original destination address.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-05-26 14:52 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-05-25 22:17 DNAT rule requires extra firewall pinhole Jeff Weber
2007-05-26 13:44 ` Jan Engelhardt
2007-05-26 14:52 ` Pascal Hambourg

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.