From owner-freebsd-questions@FreeBSD.ORG Sat Jul 31 17:51:08 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E63F16A4CE for ; Sat, 31 Jul 2004 17:51:08 +0000 (GMT) Received: from pearl.ibctech.ca (dev.eagle.ca [209.167.58.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D13BF43D58 for ; Sat, 31 Jul 2004 17:51:07 +0000 (GMT) (envelope-from iaccounts@ibctech.ca) Received: (qmail 66682 invoked by uid 1002); 31 Jul 2004 17:51:19 -0000 Received: from iaccounts@ibctech.ca by pearl.ibctech.ca by uid 89 with qmail-scanner-1.22 (clamscan: 0.73. spamassassin: 2.63. Clear:RC:1(127.0.0.1):. Processed in 1.297463 secs); 31 Jul 2004 17:51:19 -0000 Received: from unknown (HELO webmail.ibctech.ca) (127.0.0.1) by localhost.ibctech.ca with SMTP; 31 Jul 2004 17:51:17 -0000 Received: from 64.39.177.47 (SquirrelMail authenticated user steve@ibctech.ca); by webmail.ibctech.ca with HTTP; Sat, 31 Jul 2004 13:51:18 -0400 (EDT) Message-ID: <10685.64.39.177.47.1091296278.squirrel@64.39.177.47> In-Reply-To: <20040731173613.GA30298@gothmog.gr> References: <000401c47721$07faf590$6e01a8c0@sabrina> <20040731173613.GA30298@gothmog.gr> Date: Sat, 31 Jul 2004 13:51:18 -0400 (EDT) From: "Steve Bertrand" To: "Giorgos Keramidas" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: "James A. Coulter" cc: freebsd-questions@freebsd.org Subject: Re: [OT] Firewall Rule Set not allowing access to DNS servers? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 17:51:08 -0000 > There are many ways in which your ruleset might break. Two of the > most > important comments I wanted to make when I first saw the posts of this > thread are: > > a) Why do you use static rule numbers? > > You'd only have to use static rule numbers if your ruleset > had more than 65536/100 = 655 rules. This limit is > relatively hard to hit in a SOHO installation (Small Office, > Home Office). If you do reach such limits, there's > definitely something weird going on with the way your ruleset > is written ;-) > Giorgos, I am interested in where I can get more information about this. Are you suggesting that IPFW reads the ruleset and formulates a rule number according to position in the script? (I always use custom scripts). If this is true, how does this ``dynamic'' feature get affected when one houses multiple rule _sets_? Can you please provide any links to information that I can gain valuable information on this? This would certainly make ruleset creation much easier ;o) Also, links to any information on how/what/why on the 16b/100 limit on the dynamic rules, so I (we) can learn more about this? I must admit, I've never even come within 1/15 of this number, but it is interesting. All my rules have always been simply, allow, allow, allow, DENY. Tks much, Steve > b) Why do you use so many rules that 'filter' outgoing traffic? > > I saw smtp, pop3, time, http, https and many others. You > don't need to explicitly allow outgoing connections unless > the users in the internal LAN are not to be trusted at all > and even then IPFW is most of the time not the right way to > do it. > > I'd probably just use something of this form in the /etc/ipfw.rules > file > and let rc.firewall find it by setting firewall_type="/etc/ipfw.rules" > in my rc.conf file: > > # First clean up all the rules of ipfw. > flush > > # Packets should be passed to natd *before* any other rule as > # mentioned in the natd(8) manpage, unlike your current script. > add divert natd all from any to any via dc1 > > # Allow only lo0 interface to use the 127.0.0.1 address. > add allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > add deny ip from 127.0.0.1 to any > add deny ip from any to 127.0.0.1 > > # Add only the dc0 interface to receive or send packets in the > # 192.168.0.0/16 address range. > add allow ip from 192.168.0.0/16 to 192.168.0.0/16 via dc0 > add deny ip from 192.168.0.0/16 to any > add deny ip from any to 192.168.0.0/16 > > # Block packets with addresses that are used in private networks > # and should not appear in any of our interfaces below this point. > add deny ip from 10.0.0.0/8 to any > add deny ip from any to 10.0.0.0/8 > add deny ip from 172.16.0.0/12 to any > add deny ip from any to 172.16.0.0/12 > > # Allow DNS and NTP through. > add allow udp from any to any 53,123 keep-state out > > # Pass all ICMP messages through. They're rate limited by the > # kernel if sysctl net.inet.icmp.icmplim is enabled, so this is > # not very unsafe to do. > add allow icmp from any to any > > # > # Stateful tcp filtering. > # > > add check-state > add deny tcp from any to any established > > # All outgoing and incoming connections are allowed in dc0 (private > iface). > # Only outgoing connections are allowed on dc1 (external iface). > add allow tcp from any to any keep-state out xmit dc0 setup > add allow tcp from any to any keep-state in recv dc0 setup > add allow tcp from any to any keep-state out xmit dc1 setup > > # Only selected services are allowed to pass through external iface. > add allow tcp from any to any 22 keep-state in recv dc1 setup > add allow tcp from any to any 113 keep-state in recv dc1 setup > > # The default firewall policy. > add deny log logamount 0 ip from any to any > > No inline numbers, a simpler layout and a logic that you can hopefully > extend at the second from last paragraph to allow more services > through > your external interface (the `in recv dc1 setup' rules). > > Note that I haven't tested this, so it might contain syntax errors > because it's based on the ruleset I'm using at home but it also > includes > some modifications. Instead of untangling the ruleset you're now > trying > to use which seemed unnecessarily complex to me, I'm posting this just > in case it's useful but it's up to you to bring it to shape for your > setup if it doesn't "Just Work(TM)" when you load it. > > - Giorgos > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" >