Re: [slug] Re: ftp/firewall security
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.
On Thu, Jan 04, 2001 at 22:21 +0100, MaD dUCK wrote:
also sprach gabriel rosenkoetter (on Thu, 04 Jan 2001 03:16:04PM -0500):
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...
Linux is not what you would like to call a supported platform of ipf, I guess. AFAIK the original environment is Solaris, and it has been ported to some *BSD systems, too. There has been talk of a Linux version, but it is available for kernel 2.0.x only (which might speak about the current state of this port) ... Saying "it will build" is not much of importance. You need hooks in your system's IP stack to hand the packets to the filter, and you have to agree on how to describe the packets at function passing and how the return code is meant to result in actions on the packet. Either you will have to do this job yourself or you can talk a Linux network guru into providing the interface the packet filter needs. But don't count on the ipf author to support yet another platform he is not used to or doesn't even have access to. He's a very busy guy and reluctant to accept changes he's not familiar with or not able to support in the professional way you expect him to. That OTOH adds to the fine state ipfilter is in (stable, efficient, highly functional, reliable). But then again: It doesn't matter at all what system your server(!) is running under. When you're serious, your router is a separate machine anyway and doesn't provide any other service than routing packets through. So who cares if it will run OpenBSD (which has been coming with ipf by default for some time), FreeBSD (which has received ipf hooks by default due to my initiative:), Solaris (in case you can spare one of these or it has been the router already) or any other system which is supported. If you want to "inject" a filtering box into an established topology, while you don't want to or cannot shuffle IP numbers or routing configurations, you might want to examine the bridging operation mentioned with the "advanced topics" in the HowTo. And yes, ipfilter is a *great* piece of software. Returning to the original subject (FTP sessions from a LAN) the method with ipf is like this: You accept connections from the LAN towards outside servers at destination port 21 and use the "keep state" feature as well as the "ftp proxy" for this. These two rules (ipf(5) for filtering and ipnat(5) for translating) suffice for _any_ ftp mode. You will *never* have to open "data channels" wide enough to drive trucks through, the proxy module does it for you. You don't let so called "established" packets in based on what the outside(!) tells you. Returning traffic is accepted _only_ in case the process has been initiated from the inside. Keeping state works for UDP and ICMP as well. And suddenly nobody can scan you with source ports of 53 or 20 or 80 or something (all of which is not even noticed when running ipchains in all the Linux installations I've seen so far) ... You might want to look at http://www.ipfilter.org/ or http://coombs.anu.edu.au/~avalon/ip-filter.html and glimpse over the HowTo at http://www.obfuscation.org/ipf/ to get an idea of what ipf does for you (especially in comparison to ipchains, as long as you won't use kernel 2.4 in production). The HowTo is BTW what I recommend for reading to anyone building a packet filter, no matter if ipf will be used therein. It has lots of basics in it and should be of general interest. But that's something I stated in this list a few times already. :) virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
participants (2)
-
Gerhard Sittig -
MaD dUCK