From owner-freebsd-security Sat Mar 11 8:45:49 2000 Delivered-To: freebsd-security@freebsd.org Received: from area51.v-wave.com (area51.v-wave.com [24.108.26.39]) by hub.freebsd.org (Postfix) with SMTP id D2FC237BC54 for ; Sat, 11 Mar 2000 08:45:44 -0800 (PST) (envelope-from flatline@area51.v-wave.com) Received: (qmail 14162 invoked by uid 1001); 11 Mar 2000 16:46:31 -0000 Date: Sat, 11 Mar 2000 09:46:31 -0700 From: Chris Wasser To: Ben H Cc: freebsd-security@FreeBSD.ORG Subject: Re: More ipf fun.. Message-ID: <20000311094631.C13921@area51.v-wave.com> References: <20000311144931.A1531@lust.poo.pants> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000311144931.A1531@lust.poo.pants>; from bens_lists@mailandnews.com on Sat, Mar 11, 2000 at 02:49:31PM +0000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Mar 11, 2000 at 02:49:31PM +0000, Ben H wrote: > [pass in quick all] > ioctl(SIOCADDFR): Invalid argument > [pass out quick all] > pass in quick from any to any > ioctl(SIOCADDFR): Invalid argument > pass out quick from any to any The format is correct, however, I've seen that message when one a few things happen: (a) your ipfilter binaries are out of sync with the kernel, ie: you're using 3.3.8 in the kernel for example, yet trying to access it from userland with 3.3.3 binaries. (b) no kernel support for ipfilter is enabled. There are more, but it escapes me, here, it would probably help you if I show you how mine is set up, and you take that knowledge over to your box: IP Filter: initialized. Default = pass all, Logging = enabled IP Filter: v3.3.8 In dmesg, this should show up if IPFILTER is correctly intalled into the kernel. A quick test from the commandline will confirm the binary version: # ipf -V ipf: IP Filter: v3.3.8 (192) Kernel: IP Filter: v3.3.8 Running: yes Log Flags: 0 = none set Default: pass all, Logging: available Active list: 0 Make sure you only have one ipf/ipnat/ipmon et al. I remember problems in 3.x where people would install newer ipfilter src against the kernel and it would install new bins in different paths, creating much confusion. Your kernel should have the following directives: options IPFILTER #ipfilter support options IPFILTER_LOG #ipfilter logging If you're using 4.0 and want to get creative (but read the documentation, enabling some of these options are not a good idea) options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN options TCP_RESTRICT_RST #restrict emission of TCP RST options ICMP_BANDLIM #Rate limit bad replies options IPSTEALTH #support for stealth forwarding Assuming you're still using 4.0 [who isn't? :)] we proceed to modify /etc/rc.conf for extra goodies: rand_irqs="1 3 4 5 6 7 10 11 12 14" tcp_drop_synfin="YES" tcp_restrict_rst="NO" icmp_drop_redirect="YES" icmp_log_redirect="NO" icmp_bmcastecho="NO" forward_sourceroute="NO" accept_sourceroute="NO" This is for my configuration mind you, and your mileage will definitely vary (for example, the documentation states enabling drop_syn+fin is not a good idea for webservers) Check /etc/defaults/rc.conf for all the gory details, don't just copy my setup verbatim. Moving onward, we then supply ipfilter with some rules to do some nifty things, for example, my rule sets (and configuration) break tcp stealth scans (fin,xmas,null) as well as OS fingerprinting (-O option for nmap) and generally act paranoid to everyone and everything dealing with the wan interface (in my ruleset, dc0) block in log first level auth.alert proto tcp all with short block in log first level auth.alert all with ipopts block return-icmp-as-dest(port-unr) in log first level auth.alert on dc0 proto udp from any to 24.108.26.39/32 block return-rst in log first level auth.alert on dc0 proto tcp from any to 24.108.26.39/32 block in log first level auth.alert quick on dc0 from 192.168.0.0/16 to any block in log first level auth.alert quick on dc0 from 172.16.0.0/12 to any block in log first level auth.alert quick on dc0 from 10.0.0.0/8 to any block in log first level auth.alert quick on dc0 from 127.0.0.0/8 to any block in log first level auth.alert quick on dc0 from 24.108.26.39/32 to any pass out quick on dc0 proto tcp/udp from 24.108.26.39/32 to any keep state pass out quick on dc0 proto icmp from 24.108.26.39/32 to any keep state pass in quick on dc0 proto tcp from 206.75.216.200 to any port = 53 flags S pass in quick on dc0 proto udp from 206.75.216.200 to any port = 53 pass in quick on dc0 proto tcp from 206.75.216.210 to any port = 53 flags S pass in quick on dc0 proto udp from 206.75.216.210 to any port = 53 pass in quick on dc0 proto tcp from any to 24.108.26.39/32 port = 25 flags S keep state keep frags pass in quick on dc0 proto tcp from any to 24.108.26.39/32 port = 113 flags S keep state keep frags pass in quick on dc0 proto tcp from any to 24.108.26.39/32 port = 6667 flags S keep state keep frags pass in quick on dc0 proto tcp from any to any port = 21 flags S keep state keep frags pass in quick on dc0 proto tcp from any port = 20 to any flags S keep state keep frags pass in quick on dc0 proto icmp from any to any icmp-type 0 pass in quick on dc0 proto icmp from any to any icmp-type 3 pass in quick on dc0 proto icmp from any to any icmp-type 3 code 4 pass in quick on dc0 proto icmp from any to any icmp-type 11 block in log first level auth.alert quick on dc0 proto icmp from any to any As a side note, according to Building Internet Firewalls [O'Reilly] passing ICMP type 12 (parameter problem) should be OK as well, I didn't in my example above however, but if you're gungho to add it: pass in quick on dc0 proto icmp from any to any icmp-type 12 Hope this helps. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message