From owner-freebsd-questions@FreeBSD.ORG Mon Jan 12 18:46:49 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 C789416A4D4 for ; Mon, 12 Jan 2004 18:46:49 -0800 (PST) Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F3B843D6D for ; Mon, 12 Jan 2004 18:46:21 -0800 (PST) (envelope-from wegster@mindcore.net) Received: from mindcore.net (rdu162-234-100.nc.rr.com [24.162.234.100]) i0D2kHKY024291; Mon, 12 Jan 2004 21:46:17 -0500 (EST) Message-ID: <40035BF9.1030705@mindcore.net> Date: Mon, 12 Jan 2004 21:46:17 -0500 From: Scott W User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031129 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rishi Chopra References: <200401111053.QAA05193@manage.24online> <40035568.6010306@cal.berkeley.edu> In-Reply-To: <40035568.6010306@cal.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: freebsd-questions@FreeBSD.ORG Subject: Re: (Yet Another) Home Networking Question 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: Tue, 13 Jan 2004 02:46:50 -0000 Rishi Chopra wrote: > Perhaps someone can help me with this small part of rc.firewall: > > [Ss][Ii][Mm][Pp][Ll][Ee]) > ############ > # This is a prototype setup for a simple firewall. Configure this > # machine as a named server and ntp server, and point all the > machines > # on the inside at this machine for those services. > ############ > > # set these to your outside interface network and netmask and ip > oif="ed0" > onet="192.0.2.0" > omask="255.255.255.0" > oip="192.0.2.1" > > # set these to your inside interface network and netmask and ip > iif="ed1" > inet="192.0.2.1" > imask="255.255.255.0" > iip="192.0.2.17" > > I'm curious about the difference between 'inet' and 'iip', what each > one stands for, and how to configure 'onet/oip' if the outside > interface network is configured via DHCP. > > I'm also curious about this little snippet (under the 'simple' profile): > > # Everything else is denied by default, unless the > # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel > # config file. > > What happens if this option is set in my kernel config file? Can I > safely comment out this line and use the 'simple' profile without > affecting natd? > [original questions responses snipped] inet = network, which is in part defined by your netmask- eg a netmask of 255.255.255.0 says that the first 3 octets are defining your network, and the last 3 define the individual host, thus a netmask of 255.255.255.0 allows for 256 hosts in theory, although .255 is the broadcast address, 0 is the network.... oip = actual IP address, which is a combination of the network you're on (192.0.2.0 in this case) and your host identifier (.1 in this case), so 192.0.2.1 I'm sure there are a million TCP/IP tutorials available on google, but doing a search on 'netmask' should explain anything I didn't do so well on ;-) Presumaby, IPFIREWALL_DEFAULT_TO_ACCEPT allows all packets throug the firewall as the default ruleset, which means the majority of your rules would become 'deny rules' to reject specific ports/packets etc..otherwise it's reversed, rejecting any/all packets unless you explictly allow them. Similar behavior to the functionality of the hosts.allow and hosts.deny files.... Obviously, denying everything explicitly not allowed by your ruleset is more secure....however, where you're unsure what ports (and protocols) specific applications or services use, expect to wind up spending a fair amount of time in refining your ruleset until all services you want allowed are in fact passed by the firewall. Accepting everything other than what you explicitly reject is better than no firewall, and isn't a bad starting point, combined with the output of netstat to monitor connections on a server, figuring out what traffic you absolutely must allow, and then eventually converting the system to a 'reject all' setup (after creating the 'allow ruleset' of course).... Scott