[ale] Iptables packet mangling

Stuffed Crust pizza at shaftnet.org
Sun Jul 1 09:28:22 EDT 2001


On Sun, Jul 01, 2001 at 02:40:12AM -0400, Transam at cavu.com wrote:
> Actually, that is only partially true for TCP.  If one of the machines goes
> down, most SysAdmins do not want the connection to stay open for five days,
> allowing some attacks and certainly wasting resources (ports and related
> memory) and risking DoS attacks too.  It would have been trivial to add to
> keep the interface that IP Chains used for setting this.

I just had to reboot one of my machines because a remote machine went
down in the middle of the FIN sequence.  The problem here was that it
was connected to a service port, and I couldn't restart the daemon
because the port was still in use even though the remote machine had
dropped some six hours ago.

This had nothing to with IPMasq; a genuine bug in the 2.2.19 TCP stack.
The FIN state's supposed to time out, but it never did. 

Masquerading breaks the end-to-end internet.  And if you're getting
DOS'ed because of hanging masq'ed connections, then you have internal
network/security problems and that's a whole seperate ballgame.   

> For UDP it is not true at all because UDP is stateless.  The default is
> much too small for someone using NFS occasionally or for many other similar
> applications.  (While using NFS over the Internet generally is a security
> risk, someone might have firewalls between different protected subnets in
> a company where this makes sense.  The poor design prevents tuning the
> timeouts.)

But that's a flawed example; only valid when the NFS server itself is
the one being masqueraded.  Because NFS is (used to be) stateless, each
request results in one response.  There will be no packets showing up
five minutes later unless more were requested five minutes later; in
that case the UDP "masquerade" will be renewed.  

The later versions of NFS that are stateful (and much faster) operate
over TCP.

UDP is connectionless.  The applications themselves must handle packet
loss, retries, and high-level error correction.  Any application that
requires a virtual UDP 'connection' and assumes it to be persistent
and reliable is poorly designed.

Perhaps the real problem here is that the UDP-based protocols you're
masquerading really need packet-mangling too.  ICQ, RealAudio, Quake,
that sort of thing all use UDP, but they also include dynamic port
numbers in the protocol themselves.  the old masq modules understood
those packets and rewrote them as necessary.  And they haven't been
rewritten for the 2.4 iptables conntrack way of doing things. The
problem here isn't the UDP masquerade timeout; it's the fact that you're
masquerading to begin with, and the protocols themselves weren't
designed to cope with NAT.  

 - Pizza
-- 
Solomon Peachy                                    pizzaATfucktheusers.org
I ain't broke, but I'm badly bent.                           ICQ# 1318344
Patience comes to those who wait.
    ...It's not "Beanbag Love", it's a "Transanimate Relationship"...
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.





More information about the Ale mailing list