Date: Mon, 15 Mar 1999 19:53:33 +1100 From: Gavan McCormack <tetragon@cyber.com.au> To: freebsd-security@freebsd.org Subject: Re: IPFilter? Message-ID: <36ECCA8D.7EA8FFD3@cyber.com.au> References: <XFMail.990414034317.jobaldwi@vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On 14-Apr-99 Thomas Uhrfelt wrote: > > I already bought the 'Building Internet Firewalls' and its a good book, and > > I got the theoretic side of building a firewall pretty much nailed down. > > What I am missing is FreeBSD specific things + IPFilter/NAT things. I am > The section "Running NATD" gives step by step instructions on getting NAT up > and running. For manpages in general, you can go to > http://www.freebsd.org/cgi/man.cgi?manpath=FreeBSD+3.1-RELEASE THis is not the NAT in ipfilter. (AFAIK.) > I believe that you can use ipfw ('man ipfw' at the URL above) to do the same > stuff as IPFilter. ipfw is definetly a different beastie to ipfilter, and is IMHO, not as comprehensive as ipfilter. IPfilter is at this time severely lacking in documentation. I've met with Darren, he is not one for documentation. :) The best thing is to check the source, if in doubt. I guess the FreeBSD dudes will rectify this by the time IPfilter becomes the default firewall for FreeBSD. I found it pretty frustrating to setup, so here is my thoughts. When I started out on IPfilter, I made a crude rule template. type dir [log] [quick] [on $if] [proto $prot] from $host/net to $host/net \ [port = $port/range] [keep state] [flags $flags] When specifying port numbers, use ' = nn', and to specify ranges use ' 1000 <> 2000' inclusive and ' 1000 >< 2000' exclusive. You can use hostnames from /etc/hosts or wherever, and also IP numbers/subnets in the form of n.n.n.n/m where the m is the netmask in decimal bits. (Ie: a netmask of 255.255.255.248 (3-bit subnet) would be 32-3, or /29.) There are a few obvious things to know too. The best way to *check* the rules, is to allow everything, and block what you are writing the rule for. Then, once you've got everything looking like it should, reverse that. Change the rules to pass, and then block everything else. Obvious things you might miss. Dont firewall localhost. If you are blocking any to any at the end, make a rule for localhost. You must also have a rule to allow in established-connection packets. THat is, if you are allowing connections out, you'll need a rule that allows the remote host to reply. Ie: pass in quick proto tcp from any to any flags A/A (As far as I know, IPfilter maintains a table of outward going connections, and only allows in established-connection return packets for connections in the table. This stops anyone getting through by forging packets as return packets. (ACK or RST bits set on.) Can anyone confirm this is what IPfilter does? Or IPFW?) If you want to pass through 53, you will need a rule that will 'keep-state' on outgoing. Ie: pass out quick on ppp0 proto udp from any to any port = 53 keep state You'll ofcourse need an equivalent in rule. pass in quick proto tcp from any to <host> port = 53 Not _exactly_ sure what keep-state does, but it is required for 53 because it stops packets from being adversely changed. (nameserver stuff needs 53 on both ends of the connection too.) When using the NAT part of IPfilter, the IPfilter rules are applied before NAT for incoming packets, and the opposite of outgoing packets. This makes sense, its silly to translate packets just for IPfilter to drop them. The IPfilter in 3.1-RELEASE has a bug (I think) in the logging, to do with NAT. When working out what is happening in the rules when using NAT, it will log dropped packets without taking NAT into account. (Even though it should, seeing as NAT is being applied to the packets.) I can provide more info for those who are curious. Just dont take the logs _too_ literally when dealing with NAT in the equasion. Passing ICMP and UDP is a good thing initially, atleast untill you get all your TCP rules sorted out. And dont make rules needlessly, especially for ethernet interfaces. If you dont trust your ethernets, (and you have a default route to a ppp0 or a seperate interface to the net) apply the same rules for your internet interface to all interfaces by leaving out the 'on <iface>' part of the rule. You want as few rules as possible ofcourse, and if the machine routes for havily-used ethernets, the machine should be kinda beefy.. I havent used the in-kernel ftp proxy yet, so cant comment about problems with that. Apologies if I got any details wrong, I'm kinda starting out at this myself. Lemme know if I got any of that wrong. > > Thomas Uhrfelt > John Baldwin <jobaldwi@vt.edu> -- http://members.freedomnet.com/~jbaldwin/ -- Gavan McCormack - tetragon@cyber.com.au - tetragon@bitey.net Cybersource P/L. TCPIP network management & Unix system administration. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36ECCA8D.7EA8FFD3>