Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Oct 1999 14:46:24 -0700
From:      "Ronald F. Guilmette" <rfg@monkeys.com>
To:        freebsd-bugs@freebsd.org
Subject:   Some fixes for some non-features of the /etc/rc.firewall script
Message-ID:  <726.941233584@segfault.monkeys.com>

next in thread | raw e-mail | index | archive | help

Well folks, like the old saying goes, ``Yesterday, I couldn't even spell
`unginer', but today I are one!''

I learned essentially everything I know about both ipfw and natd in just
the last 24 hours, but I'm already ready to be a critic! :-)

But before I go filing any formal pr's, I guess I ought to at least run
my ideas past some of the more seasoned critics that might be reading this
list/newsgroup.  OK, so here goes...

Let me set the stage first.  I am trying to use ipfw in conjunction natd.
This worked pretty darn good, right out of the box, at least after I built
and installed a proper kernel, and after I put the proper directives into
my /etc/rc.conf file, but *only* when I had:

firewall_type="open"

set in the /etc/rc.local file.

I tried to set that instead to firewall_type="simple" and all sorts of
stuff ceased to work.  So I just grunged around in the /etc/rc.firewall
script and made changes until everything *did* work again.  My suggested
patches for /etc/rc.firewall are included below.  I plan to file an official
pr for these things, but first I'll get some comments from the readership
here.  (Some of these things may be just matters of taste.)

The first patch below was needed in order to actually allow natd to be
useful in conjunction with the "simple" firewall type.  Without this change
my NAT-supported machines on the local net could not connect out to anything
in the outside world.

The second patch below allows outsiders to connect to your AUTH port (113).
I found that allowing this will cut down a lot on the number of pointless
"Deny" log messages you will get if you don't have this, because a *lot*
of things out in the real world (most notably Sendmail) _will_ try to
connect to your local auth port whenever you connect out to them.

The next patch allows ICMP packets and UDP packets to flow freely between
other machines on the local net and the current (firewall) machine and vise
versa.  I don't see how allowing this could create a security threat, so
it seems to me that it ought to be allowed.  I was definitely annoyed when,
after having first tried the "simple" firewall setup, I found that I could
no longer even ping the firewall machine from other machines on my own local
net.  Also, I believe that this patch helped to clear up an obscure problem
I was having with my X server (and with starting new xterms) when I first
tried using the "simple" firewall type.

The third patch below also allows ICMP to and from the firewall machine and
the outside world.  Some people will undoubtedly say that this introduces
a security threat, but frankly, even if that's true, I can live with it.  I
don't see it as a big problem, and I'd rather be able to ping this (firewall)
machine from the outside than not.

Last but not least, I added an EXPLICIT command:

	ipfw add deny log ip from any to any

This is intended to take the place of the implicit default "fall through"
deny command that you will get anyway, with the only difference being that
_this one_ asks for denied packets to be logged (and the default rule doesn't
do that).

I like knowing when suspicious stuff is going on, therefore I prefer to have
the logging of denied packets be on in all cases.  (I also added the "log"
qualifier to all of the other "deny" commands in this file also, but I seem
to have misplaced those patches now.  Humph.)

Comments?




*** rc.firewall	Fri Oct 29 14:10:14 1999
--- rc.firewall	Fri Oct 29 14:15:35 1999
***************
*** 151,154 ****
--- 151,161 ----
      $fwcmd add deny all from ${onet}:${omask} to any in via ${iif}
  
+     # Allow TCP through to internal RFC1918 nets if using natd & setup succeded
+     if [ "X${natd_enable}" = X"YES" -a "X${natd_interface}" != X"" ]; then
+ 	$fwcmd add pass tcp from any to 192.168.0.0:255.255.0.0 established
+ 	$fwcmd add pass tcp from any to 172.16.0.0:255.240.0.0 established
+ 	$fwcmd add pass tcp from any to 10.0.0.0:255.0.0.0 established
+     fi
+ 
      # Stop RFC1918 nets on the outside interface
      $fwcmd add deny all from 192.168.0.0:255.255.0.0 to any via ${oif}
***************
*** 171,174 ****
--- 178,184 ----
      $fwcmd add pass tcp from any to ${oip} 80 setup
  
+     # Allow access to our AUTH
+     $fwcmd add pass tcp from any to ${oip} 113 setup
+ 
      # Reject&Log all setup of incoming connections from the outside
      $fwcmd add deny log tcp from any to any in via ${oif} setup
***************
*** 177,180 ****
--- 187,202 ----
      $fwcmd add pass tcp from any to any setup
  
+     # Allow ICMP on the inside
+     $fwcmd add pass icmp from ${inet}:${imask} to ${iip}
+     $fwcmd add pass icmp from ${iip} to ${inet}:${imask}
+ 
+     # Allow UDP on the inside
+     $fwcmd add pass udp from ${inet}:${imask} to ${iip}
+     $fwcmd add pass udp from ${iip} to ${inet}:${imask}
+ 
+     # Allow all ICMP out in the world
+     $fwcmd add pass icmp from any to ${oip}
+     $fwcmd add pass icmp from ${oip} to any
+ 
      # Allow DNS queries out in the world
      $fwcmd add pass udp from any 53 to ${oip}
***************
*** 186,189 ****
--- 208,212 ----
  
      # Everything else is denied as default.
+     $fwcmd add deny log ip from any to any
  
  elif [ "${firewall_type}" != "UNKNOWN" -a -r "${firewall_type}" ]; then


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?726.941233584>