Iptables Forwarded traffic

Hi,

I am rewriting my iptables rules and I have a (stupid) question :


Code:
iptables -A FORWARD -t filter -p ALL -i eth0 -m state --state
ESTABLISHED,RELATED -j ACCEPT

eth0 is the interface connected to internet

Since all connections coming from the outside world can't contact the
local network directly (i mean that one NATed computer has to ask for it),
it seems impossible that a connection marked as new could try to reach
another computer than my router ? Isn't this rule stupid (or paranoid) ?
Since I have found a lot of iptables script using it, could someone
explain me in why I should not ACCEPT all incoming forwarded traffic ?
It would be something like that :

Code:
iptables -A FORWARD -t filter -p ALL -i eth0 -j ACCEPT

Thanks in advance

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Hello,

test a écrit :
>
> iptables -A FORWARD -t filter -p ALL -i eth0 \
> -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> eth0 is the interface connected to internet
>
> Since all connections coming from the outside world can't contact the
> local network directly (i mean that one NATed computer has to ask for
> it), it seems impossible that a connection marked as new could try to
> reach another computer than my router ? Isn't this rule stupid (or
> paranoid) ?
> Since I have found a lot of iptables script using it, could someone
> explain me in why I should not ACCEPT all incoming forwarded traffic ?

Sure. Here is where you're wrong :

> all connections coming from the outside world can't contact the
> local network directly

They can. Or at least they could, and some can. All that is needed is
that packets arrive at eth0 with the destination address of one of your
private hosts, and your Linux-based router will happily route them to
their destination.

Now you're gonna ask how the hell a packet with a private destination
address could reach your router from the outside ? Well, this could be
caused by a routing problem at your ISP, or you could be on a shared
media (e.g. cable) with other subscribers which can directly send you
packets with arbitrary destination address. This is as simple as adding
a route on their box.

route add <your_private_subnet> gw <your_public_address>

Anyway, assuming this cannot happen is making your security depend on
something you do not control.

> Now you're gonna ask how the hell a packet with a private destination
> address could reach your router from the outside ? Well, this could be
> caused by a routing problem at your ISP, or you could be on a shared
> media (e.g. cable) with other subscribers which can directly send you
> packets with arbitrary destination address. This is as simple as adding
> a route on their box.
>
> route add <your_private_subnet> gw <your_public_address>
>
> Anyway, assuming this cannot happen is making your security depend on
> something you do not control.

thanks for your answer.

If I understand correctly, the only problematic case would be something
like that :

a) a computer of my local network initiate a connection to a distant
computer.
b) my router use SNAT to change the source ip address of this connection
for the external ip adress.
c) my routeur keeps track of this connection, and send the signal to the
internet server. The state machine write it is NEW
d) the server answers back using the router external ip adress.
e) the router receives the signal and recognize it. The state machine write
it is ESTABLISHED.
f) because my router recognize the connection, he routes the incoming
packets of this connection to the local network computer which initiate the
connection at first (and all following packets of this connection).

Now, how could someone exploit this behavior ?
A hacker or a bot or spyware on the server I have contacted launch an
attack after f, because the connection tracking system recognize it as
ESTABLISHED. He launch another connection which is considered as RELATED to
the first by my router. Using this strategy, he can contact any port of the
local computer from the outside world. But even if it this is possible, the
rule i mentionned will accept it... Even if I see now the interest of this
iptables rule, I don't find it really secure ?

(E-Mail Removed) a écrit :
>
> If I understand correctly, the only problematic case would be something
> like that :
>
> a) a computer of my local network initiate a connection to a distant
> computer.
> b) my router use SNAT to change the source ip address of this connection
> for the external ip adress.
> c) my routeur keeps track of this connection, and send the signal to the
> internet server. The state machine write it is NEW
> d) the server answers back using the router external ip adress.
> e) the router receives the signal and recognize it. The state machine write
> it is ESTABLISHED.
> f) because my router recognize the connection, he routes the incoming
> packets of this connection to the local network computer which initiate the
> connection at first (and all following packets of this connection).

This is the normal case. Nothing problematic here.

> Now, how could someone exploit this behavior ?
> A hacker or a bot or spyware on the server I have contacted launch an
> attack after f, because the connection tracking system recognize it as
> ESTABLISHED. He launch another connection which is considered as RELATED to
> the first by my router. Using this strategy, he can contact any port of the
> local computer from the outside world.

Err... It's not that simple. A connection from a host is not considered
RELATED just because another connection between your box and that host
is already established. There has to be a good reason to do so, e.g. the
existing connection is an FTP control connection and the new connection
is identified as a related FTP data connection by the FTP conntrack
helper. Besides, this related connection cannot cannot connect to any
arbitrary port but only to the port your box opened for it.

--
Et dire qu'on pourrait parler de ça dans un forum francophone...

Thank you very much for your good explanation.

I'm taking the opportunity to ask you two question :

- is this possible the new port open by the ftp connection would receive any
ftp order or command, even it is not the order sollicited by the local
computer ?
- in the case of RTSP protocol which use arbirtrary related port to answer
(like freebox tv), what will happen ?

-------------------------
Merci de ta patience :-)

(E-Mail Removed) a écrit :
>
> - is this possible the new port open by the ftp connection would receive any
> ftp order or command, even it is not the order sollicited by the local
> computer ?

FTP related connections are data connections which do not transport
commands but only data such as directory listings and files. Only the
initial control connection on a fixed port (usually 21) transports
commands. Basically such commands may say to the other side : "please
connect to my port xxx in order to send|receive the data". If loaded,
the FTP connection tracking helper module reads the control connection
and will consider RELATED only a connection from the remote FTP agent to
the port that was specified in the above command. Connections from the
same host to other ports will be considered NEW, not RELATED.

> - in the case of RTSP protocol which use arbirtrary related port to answer
> (like freebox tv), what will happen ?

The behaviour is the same as FTP. The RTSP connection uses a well known
fixed port (usually 554) and transport requests from the client to the
server saying "please send the UDP data stream to port xxx". If loaded,
the RTSP connection tracking helper module reads the RTSP connection and
will consider RELATED only UDP packets from the server to the client
port that was specified in the request. Note that the RTSP conntrack and
NAT helper module is not yet included in the mainline Linux kernel.

Thank you very much. If you are not already an informatic teacher, you
should really consider it !