Attachment #23428 for bug #40313

View | Details | Raw Unified | Return to bug 40313
Collapse All | Expand All




	respect except that it forwards encryption keys by default.  What
	this means is that if you have a secure workstation holding keys
	that give you access to the rest of the system, and you
	ssh to an insecure machine, your keys are usable by the
	insecure system.  The actual keys themselves are not exposed, but
	ssh installs a forwarding port for the
	duration of your login, and if an attacker has broken
	<username>root</username> on the

      
      <para>There are currently two distinct types of firewalls in common use
	on the Internet today.  The first type is more properly called a
	<emphasis>packet filtering router</emphasis>, where a
	multi-homed machine chooses whether to forward or block packets based
	on a set of rules.  The second type, known as a <emphasis>proxy
	  server</emphasis>, relies on daemons to provide authentication and to

	<title>Packet Filtering Routers</title>

	<para>A router is a machine which forwards packets between two or more
	  networks.  A packet filtering router has extra code to
	  compare each packet to a list of rules before
	  deciding if it should be forwarded or not.  Most modern IP routing
	  software has packet filtering code within it that defaults to
	  forwarding all packets.  To enable the filters, you need to define a
	  set of rules for the filtering code so it can decide if any given
	  packet should be allowed to pass or not.</para>
	    
	<para>To decide whether a packet should be passed on, the firewall looks
	  through its set of rules for a rule which matches the contents of
	  the packet's headers.  Once a match is found, the rule action is
	  obeyed.  The rule action could be to drop the packet, to forward the
	  packet, or even to send an ICMP message back to the originator.
	  Only the first match counts, and the rules are searched in order.
	  Hence, the list of rules can be referred to as a <quote>rule
	  chain</quote>.</para>
	    
	<para>The packet-matching criteria varies depending on the software
	  used, but typically you can specify rules which depend on the source
	  IP address of the packet, the destination IP address, the source
	  port number, the destination port number (for protocols which
	  support ports), or even the packet type (UDP, TCP, ICMP,
	  etc.).</para>
      </sect3>
	  
      <sect3 id="firewalls-proxy-servers">

	    
	<para>Proxy servers are machines which have had the normal system
	  daemons (<application>telnetd</application>, 
	  <application>ftpd</application>, etc.) replaced with special servers.
	  These
	  servers are called <emphasis>proxy servers</emphasis>, as they
	  normally only allow onward connections to be made.  This enables you
	  to run (for example) a proxy <application>telnet</application> server on your firewall host,
	  so people can <application>telnet</application> in to your firewall from the outside, go
	  through some authentication mechanism, and then gain access to the
	  internal network (alternatively, proxy servers can be used for
	  signals coming from the internal network and heading out).</para>
	    
	<para>Proxy servers are normally more secure than normal servers, and
	  often have a wider variety of authentication mechanisms available,
	  including <quote>one-shot</quote> password systems, so that even if
	  someone manages to record a password being used, they will not be
	  able to use it, as the password
	  instantly expires on first use.  As they do not actually give users direct access to the
	  host machine, it becomes a lot more difficult for someone to install
	  backdoors around your security system.</para>
	    
	<para>Proxy servers often have ways of restricting access further, so
	  that only certain hosts can gain access to the servers, and often
	  they can be set up to limit which users can talk to
	  which destination machines.  Again, what facilities are available
	  depends largely on what proxy software you choose.</para>
      </sect3>
    </sect2>

	FreeBSD, is a packet filtering and accounting system which resides in
	the kernel, and has a user-land control utility,
	    &man.ipfw.8;.  Together, they allow you to define and query the
	rules used by the kernel for its routing decisions.</para>
	  
      <para>There are two related parts to IPFW.
	The firewall section performs packet filtering.  There is
	also an IP accounting section which tracks usage of your
	router, based on similar rules.  This allows
	you to see (for example) how much traffic your router is getting from
	a certain machine, or how much WWW (World Wide Web) traffic it is
	forwarding.</para>

	      firewall activity, but do not want to be open to a denial of
	      service attack via syslog flooding.</para>

	    <para>When a chain entry (rule) reaches the packet limit specified,
	      logging is turned off for that particular entry.  To resume
	      logging, you will need to reset the associated counter using the
		&man.ipfw.8; utility:</para>
	    
	    <screen>&prompt.root; <userinput>ipfw zero 4500</userinput></screen>
	    <para>Where 4500 is the chain entry you wish to resume
	      logging.</para>
	  </listitem>
	</varlistentry>

	    <term>allow</term>
	    
	    <listitem>
	      <para>Pass the packet on as normal (aliases:
		<literal>pass</literal>, <literal>permit</literal>, and
		<literal>accept</literal>).</para>
	    </listitem>
	  </varlistentry>
	  

	    <listitem>
	      <para>Drop the packet.  The source is not notified via an
		ICMP message (thus it appears that the packet never
		arrived at the destination).  Alias: <literal>drop</literal>.</para>
	    </listitem>
	  </varlistentry>
	  

	    <listitem>
	      <para>Matches if the IP header contains the comma separated list
		of options specified in <replaceable>spec</replaceable>.  The
		supported list of IP options is: <literal>ssrr</literal>
		(strict source route), <literal>lsrr</literal> (loose source
		route), <literal>rr</literal> (record packet route), and
		<literal>ts</literal> (time stamp).  The absence of a
		particular option may be specified with a leading
		<literal>!</literal>.</para>
	    </listitem>
	  </varlistentry>

	    <arg>-a</arg>
	    <arg>-t</arg>
	    <arg>-N</arg>
	    <arg choice="plain">list</arg>
	  </cmdsynopsis></para>

	<para>The list command may be abbreviated. There are three valid flags when using this form of the
	  command:</para>
	    
	<variablelist>


	<para>This causes all entries in the firewall chain to be removed
	  except the fixed default policy enforced by the kernel (index
	  65535).  Use caution when flushing rules; the default deny policy
	  will leave your system cut off from the network until allow entries
	  are added to the chain.</para>
      </sect3>


	<para>When used without an <replaceable>index</replaceable> argument,
	  all packet counters are cleared.  If an
	  <replaceable>index</replaceable> is supplied, the clear operation
	  only affects a specific chain entry.</para>
      </sect3>
    </sect2>

      
      <note>
	<para>The following suggestions are just that: suggestions.  The
	  requirements for each firewall are different and we cannot tell you
	  how to build a firewall to meet your particular requirements.</para>
      </note>
	  
      <para>When initially setting up your firewall, unless you have a test
	bench setup where you can configure your firewall host in a controlled
	environment, it is strongly recommend you use the logging versions of the
	commands and enable logging in the kernel.  This will allow you to
	quickly identify problem areas and cure them without too much
	disruption.  Even after the initial setup phase is complete, I
	recommend using the logging for `deny' rule, as it allows tracing of
	possible attacks and also modification of the firewall rules if your
	requirements change.</para>
	  
      <note>
	<para>If you use the logging versions of the <command>accept</command>
	  command, it can generate <emphasis>large</emphasis> amounts of log
	  data, as one log line will be generated for every packet that passes
	  through the firewall; this means large FTP/http transfers, etc., will really
	  slow the system down.  It also increases the latencies on those
	  packets as it requires more work to be done by the kernel before the
	  packet can be passed on.  <application>syslogd</application> will 

	  
      <para>You should enable your firewall from
	<filename>/etc/rc.conf.local</filename> or
	<filename>/etc/rc.conf</filename>.  The <filename>/etc/rc.conf</filename> manual page explains
	which knobs to fiddle and lists some preset firewall configurations.
	If you do not use a preset configuration, <command>ipfw list</command>
	will output the current ruleset into a file that you can

	<emphasis>do</emphasis>! This is largely dependent on what access to
	your network you want to allow from the outside, and how much access
	to the outside world you want to allow from the inside. Some general
	rules to start with are:</para>
      
      <itemizedlist>
	<listitem>

	  <para>Block <emphasis>all</emphasis> incoming UDP traffic.  There
	    are very few useful services that travel over UDP, and what useful
	    traffic there is, is normally a security threat (e.g. Suns RPC and
	    NFS protocols).  This has its disadvantages also; since UDP is a
	    connectionless protocol, denying incoming UDP traffic also blocks
	    the replies to outgoing UDP traffic.  This can cause a problem for
	    people (on the inside) using external archie (prospero) servers.

	      
	<listitem>
	  <para>Check what ports any internal servers use (e.g. SQL servers,
	    etc.).  It is probably a good idea to block those as well, as they
	    normally fall outside the 1-1024 range specified above.</para>
	</listitem>
      </itemizedlist>

	<literal>ip_fw_chk</literal> routine, displaying the results
	to the console every 1000 packets.</para>

      <para>Two rule sets, each with 1000 rules, were tested.  The
	first set was designed to demonstrate a worst case scenario by
	repeating the rule:</para>

      <screen>&prompt.root; <userinput>ipfw add deny tcp from any to any 55555</userinput></screen>

      <para>This demonstrates a worst case by causing most of IPFW's
	packet check routine to be executed before finally deciding
	that the packet does not match the rule (by virtue of the port
	number). Following the 999th iteration of this rule was an

	rule. Thus the theoretical packet processing limit with these
	rules is around 370 packets per second. Assuming 10Mbps
	Ethernet and a ~1500 byte packet size, we would only be able
	to achieve 55.5% bandwidth utilization.</para>

      <para>For the latter case each packet was processed in
	approximately 1.172ms, or roughly 1.2 microseconds per rule.

Return to bug 40313