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.