OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: ipfw - ipf
From: Cy Schubert - ITSD Open Systems Group (Cy.Schubertuumail.gov.bc.ca)
Date: Mon Feb 14 2000 - 08:50:32 CST

In message <200002141129.MAA03051CoDe.hu>, Zahemszky Gabor writes:
> hi!
>
> I've got some questions:
>
> a) if I have both ipf and ipfw in my kernel, which is the flow of a packet?
> in -> ipf -> ipfw -> kernel | kernel -> ipfw -> ipf -> out
> or the other? (I used to use ipfw, and I'd like to switch - or learn - ipf.)

IIRC, it's the other way around. IPFW gets called first then IPF.

>
> b) Are there any ipfw to ipf converter? I'd like to use (or write) it.

No. Having gone through a recent (January) conversion, after using
IPFW for 5 years, on a couple of machines lately, there isn't much
point to it. If you use "keep state" you can reduce the size of your
rule set, though I must admit that auditing my rules in the process may
have had a part to play in this. Either way, "keep state" can replace
"established," so there is no one-to-one relationship, if you want to
make full use of IPF's features.

>
> c) Which version of ipf is in the 4.x kernel? In my 3.4R, it's 3.2.7
> (as of /usr/include/netinet/ipl.h), but 3.3.8 is on the street now

Current, which is about to be released as 4.0, has 3.3.8.

>
> d) How ipfw+natd / ipf+ipnat works contrary the post about `hacking Stateful
> Packet Filters'. ("Breaking through FTP ALGs -- is it possible?" by Mikael
> Olsson on VULN-DEV, and "FireWall-1 FTP Server Vulnerability" by John McDonal
> d
> on BugTraq)

If you don't use "keep state" for FTP sessions where the client is on
the Internet you shouldn't be vulnerable to the discussed
vulnerability, e.g. use IPF as a stateless filter for FTP. However to
do so you will need to open up access to ports 1024-65535, just as you
would with IPFW or any other stateless firewall, making it even easier
to access these ports. Some FTP sites block these ports assuming that
all clients will use PORT FTP. If this is the case and if the FTP
client is behind its own firewall, FTP will fail to work.

A better idea would be to not put your FTP server behind your firewall,
instead putting it on your DMZ or on your external network (even better
idea). The same would be true of Web servers. Use a system or systems
on the inside of your firewall as a master copy. If your Web or FTP
server is compromised, just refresh it. This will reduce the work
required to rebuild if your server is compromised.

If I may editorialise, when it comes to security, the FTP protocol is
an abortion. If you must put a Web/FTP server behind a firewall, use a
Web server without CGI scripts.

Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Sun/DEC Team, UNIX Group Internet: Cy.Schubertuumail.gov.bc.ca
ITSD
Province of BC
                    "COBOL IS A WASTE OF CARDS."

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message