Date: Mon, 26 Jun 2000 22:08:52 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: security@FreeBSD.ORG Subject: ipfilter hooks in rc.network Message-ID: <20000626220852.M9883@speedy.gsinet>
next in thread | raw e-mail | index | archive | help
Lately I suggested to add hooks for ipfilter in rc.network (I did so via PM to Matt Dillon jumping on his rc.network commit). There I was heavily inspired by the "Configuration of ipfilter on FreeBSD" document at http://www.free-x.ch/pub/ipf-conf-en.html. But I failed to identify all the places where to plug the new code into. So I bundled all the three parts ipf, ipnat and ipmon in pass1 right after setting the hostname and before the network interfaces come up. Doing so was led by this reasoning: - Interfaces referenced by filter rules don't have to be up yet, the rules just get parsed and stored away to be checked against when packets actually show up - Filter rules should be established before any traffic is produced. The fact that ifconfig(8)ed interfaces automatically have a route to their locally attached networks makes me afraid packets can come in just because I bring up an interface. And in addition the answers can go out just because I brought up the interface -- the routing was done by magic! This is all untouched by enabling gatewaying or adding further routes in a later stage. - Even if there are no explicit service programs (i.e. daemons) running, the kernel's IP stack will happily accept some packets and respond to some of them. ICMP, ARP and friends come to mind. So I'm tempted to set up ipfilter parts in a *very* early stage. Best would be to do it before any interface goes up. Unless I'm wrong in any of the above assumptions. And for some details: I still don't know why one would want to separate ipf and ipnat invocation. As far as I got it ipnat is "just" a logical complement to filtering. Maybe they're even held in the same structures and handled by the same code as the packet filtering is. So I see them as _one_ ruleset in a two section notation. And how good or bad is it to start ipmon far away from the ipf process which fills the /dev/ipl and Co logging channels? Are there chances to "miss" log entries? Are there chances for the fifo(?) queues to fill up and block until the reader ipmon comes in? My (admittedly simplistic -- I'm not the expert here) approach was then to have a diff like this (for demonstration, surely it's mangled by copy&paste and mail transport): ----- :r !rcsdiff -u /etc/rc.network ---------------------------- =================================================================== RCS file: /etc/RCS/rc.network,v retrieving revision 1.1 diff -u -r1.1 /etc/rc.network --- /etc/rc.network 2000/06/21 19:15:50 1.1 +++ /etc/rc.network 2000/06/24 09:05:45 @@ -20,6 +20,28 @@ echo -n ' hostname' fi + # ----- gsi 2000/06/21: added from ipf-conf-en.html + if [ X"${ipfilter}" = X"YES" -a -f "${ipfilter_rules}" ]; then + echo -n ' ipfilter' + ipf -Fa -f ${ipfilter_rules} + else + ipfilter="NO" + fi + if [ X"${ipfilter}" = X"YES" -a X"${ipmon_flags}" != X"NO" ]; then + echo -n ' ipmon' + ipmon ${ipmon_flags} + fi + if [ X"${ipfilter}" = X"YES" -a X"${ipnat}" = X"YES" ]; then + if [ -f "${ipnat_rules}" ]; then + echo -n ' ipnat' + ipnat -CF -f ${ipnat_rules} + else + echo -n ' NO NAT RULES' + ipnat="NO" + fi + fi + # ----- end of added ipfilter code + # Set the domainname if we're using NIS # case ${nisdomainname} in ----------------------------------------------------------------- Later in the discussion it turned out that there's a need for an ${ipfilter_flags} variable with a default setting of "-E" which needs to be unset when ipfilter is in the kernel instead of being a module. This will eliminate a warning and could serve for further customization if the admin feels like doing so. :) And before I forget the real intent for all of this: what made me think this belongs into the base system (rc.network and rc.conf) is the following: - ipfilter comes together with the base in /usr/src/contrib, the programs live in /sbin, they're no "strangers" - I failed to achieve the same with the rc.firewall script or the firewall variables -- even specifying a script instead of a rule scheme I could never prevent ipfw commands from being sent out. So I would end up with _both_ ipfw and ipfilter loaded or present in the kernel. I'm not certain about the implications, but frankly speaking I just don't want to experiment with this. - Of course the above sketched modifications could always be done by an admin after installation. But it would potentially collide with _every_ future update (mergemaster run). Please help out in identifying - where to put in the new code - what the defaults for /etc/defaults/rc.conf should look like (of course the new stuff has to be disabled and LINT has the usual hint "if you enable IPFILTER_DEFAULT_BLOCK make sure you open your needed ports with filter rules") - how much of configurability is needed (does a simple ${program_to_start_in_rc_network_if_present} do already? this would be a very generic mechanism:) I cannot speak for Matt, but I feel he will be glad to commit a proven solution to CURRENT and some time later STABLE admins have one worry less to care about after installation. :> Speaking for myself loading everything in this early stage and all together works for me. But I could have missed something. 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. 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?20000626220852.M9883>