It will be determinant if the following testbed could be done,
better if slow CPU:
1 - Be sure ip_masq_ftp is loaded [*]
2 - Overload masquerading by, eg., spawing a lot of quick "wget"
(masq entries stays 2 minutes after connection shutdown) from
clients inside. We need to force a large lookup loop.
3 - Touch default "tcp" masq timeout
# ipfwadm -s 60 120 300
^^ default=15*60 [secs]
4 - At the masq host, start a
$ while cat /proc/net/ip_masquerade; do : ;done > /dev/null
5 - With the machine nicely loaded, start a *long* ftp transfer
from inside (better no pasv mode), it must last more than
60 secs.
Start your chronometer... in 60 secs you should be freezed.
Some thoughts ...
1. If this is true, bingo! :))
1a. BUT I had broadcast a nice security flaw
is linux masquerading :/
BTW I started working on a solution (but I want to be SURE
that the problem is THERE (dont want to touch 2.0.3x stability)
** Workaround: don't load ip_masq_ftp module, don't run midentd. **
[*] ppl who reported .configs to Doug could please add this
info?.
-- Juanjo http://juanjox.home.ml.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu