also sprach gabriel rosenkoetter (on Thu, 04 Jan 2001 03:16:04PM -0500):
You can't. Passive ftp and firewalls don't mix, and never have. Any intelligent ftp client (ncftp included, last I checked) will attempt to use passive, and fall back to active if it can't get through.
well, as far as i can tell the problem is beyond ftp. it's about stateless firewalls. because if i ssh into allspice for instance, my ssh client talks to port 22 on allspice which then spawns into a dialogue between some port x on allspice and a port above 1024 on my machine. so in a stateless firewall, that just has to be open. the port 1024+ aspect i mean...
99% of all ftp traffic nowadays is passive, so the data transfer happens from port 21 of the server to port x {x | x >= 1024} of the client.
Um... where'd you come up with that figure?
no idea. i thought i read that somewhere...
more important in this situation, it is very possible that some client program tries to establish a connection to a server with the backward connect (server -> client) being something like x -> 5021.
... or 6xxx (X).
except that ports 6000/6001 could be enabled specifically if i wanted X. the same applies to port 4000 (icq). the point is that X and icq have specific ports but the client connections to common spawn-services use the next available port...
(i DENY packets rather than to REJECT them).
Why? Short of a signature suggesting a DoS, it's common courtesy to reject. Oh, wait, you lack state. Ne'mind. Get a real (stateful) firewall, then. ;^>
i am insulted. the reason is: there are windoze clients on the networks that i am in and what i found is that if you REJECT, windoze generates a whole lot more traffic than if you simply DENY and let it poll every 15 seconds. it's weird, i know, but that's what tcpdump and my switch LEDs indicate...
so while it is perfectly understandable to me how and why and what ports under 1024 i have to block and open to secure the machine, the ports above 1024 are a mystery. a lot of networks i have worked in/with/for had firewall policies that allowed anything above 1024, but as philip pointed out, this is asking for trojans.
No, no, no. This is painfully wrong-headed. You're only asking for trojans if there's a way to break security on ports where you actually run servers. If not, then having these ports open does you no harm. If so, then a cracker will find a way to trojan you with the ports you have open anyway. (Trust me, it's not hard to write a daemon that behaves like an sshd except with certain input, when it gives you a root shell instead, and substitute that for your currently-running sshd.)
yes, you have a point. to be honest, until i started that discussion on suse-security, i did not think that having ports 1024+ open would be a problem if the rest of the system was secure...
Every workable (note I don't say *good*) ipchains setup I've ever seen just allowed ports over 1024. If you want to keep rpc or X traffic inside, you're going to have to randomly decided to block a swath of those, or trust that blocking the ports the server daemons actually run on will be enough.
that's what i am doing now...
Or install yourself lots of proxies (no kind of fun).
woohoo.
and do you guys know of free, open-source statefull firewalls for linux?
I'm pretty sure BSD ipf/ipnat will build on Linux (it does on Solaris). Not that I've tried.
does ipf do stateful in a good way? because the newer ipchains do it to (context based), but it's still simple... martin [greetings from the heart of the sun]# echo madduck@!#:1:s@\@@@.net -- heisenberg may have been here.