#
# scipfire design graphic
#
# $Id: design,v 1.2 2001/07/29 21:23:35 scip Exp $

    
  The design of the scipfire iptables firewall system
========================================================
        

INCOMING TRAFFIC       
       v
       |
       |         [deliver]
       |          ^
       |          |
       v          |
     o=+==========+===o
     I |          |   I
     I |          +---------------+
     I |              I           |
     I |              I           v
     I |          +---+--------> {NAT}
     I |          |   I
     I +------------->+--------> {INPUT}
     I            |   I           |
     I Ethernet/1 |   I           +------> {INPUT_EXTERN}
     I EXTERN     |   I                     |
     I            |   I                     +---------> {IN_xxx} (i.e. IN_FTP)
     I            |   I                     |                 |
     o============+===o                    / \               / \
                  |                 [accept]   [drop] [accept]   [drop]
                   \                |                 |
                     \              +-----+     +-----+
                       \                  |     |
                         \                 \   /
                           \               {NAT} 
     o================o      \               |
     I                I       |              |
     I             +--+-------|--------------+
     I Ethernet/0  |  I       |
     I  INTERN     |  I       |
     I             |  I       |
     I  +--------- | -+--------> {INPUT} 
     I  |          v  I       |   |
     o==+==========+==o       |   +------> {INPUT_INTERN}
        ^          |          |             |
        |          |          |             +---------> {xxx} (i.e. FTP or WWW)
        |          v          |             |              |
        |         [deliver]   |          [drop]           / \
        |                     |                   [accept]   [drop]
        |                     |                  /
        |                     +----------------/
        ^
 OUTGOING TRAFFIC



Note: words inside { } are iptables chains as defined in
the chains/ scripts.





 How it works at all
-----------------------------------------

 1. Directory structure

    bin/
		contains the startscript scipfire, which
		starts and stops the firewall.

    chains/
		contains one script per chain, these scripts
		will be started by scipfire via the rc.d/S*
		sym-links.

    conf/
		contains the configuration for scipfire, there
		are no iptable rules, just variables and stuff.
		rules resides in the chains/ scripts.

    doc/
		documentation for scipfire.

    lids/
		sample LIDS setup for a debian-based firewall.

    dns/
		sample bind setup for a debian-based firewall.

    syslog/
		sample syslogd setup.

    rc.d/
		contains symbolic links to the chains scripts.
		For each chain a S* and another K* symlink exists.
		This is neccessary, because the order how a chain
		is to be started or stopped is different. If a
		chains is being referenced by another chain then
		that particular chain must be removed prior removal
		of the referring chain.
		Symlinks beginning with "S" are start-links, they
		will be used when you issue "scipfire start[log]".
		Symlinks beginning with "K" are stop-links, which
		will be used if you stop scipfire: "scipfire stop".
		Each symlink must have a specific number following 
		the K or S, for example:
			S10input  -> ../chains/INPUT
			S11output -> ../chains/OUTPUT
		that means, that the INPUT script will be executed
		before the OUTPUT script because of the higher number
		which it's symlink has (10 in our case).
		This mechanismus is adopted from the approved and 
		well-known SYSV-init style rc startup cwsystemscripts
                for different runlevels. See also init(1) for more on
		this.
	

 2. Step-by-Step startup scheme description

    The very first thing is the following command, which can be
    executed manually or during system startup by init(1):

	# /etc/init.d/scipfire start

    The first thing scipfire does is to initialize it's config.
    It does this by sourcing the confguration file in
    /etc/scipfire.d/conf/scipfire.cfg.

    The config file itself is also a shell script. It contains
    all definitions such as the Internal network, interfaces,
    several defaults and the like. In addition it prepares the
    iptables commandline which will be used later in every chain-
    script, $fw.

    After that, the script enters the directory /etc/scipfire.d/rc.d
    and executes everything overthere beginning with the letter
    "S" in ascending order, which will be controlled by the numbers
    which follows the "S" (see above). Every chain script will be
    passed with the actual run parameter. On startup this is "start".

    Each chain script will source the config too and then execute
    some iptables commands. Take a look into the chains scripts for
    more details, or execute scipfire with the "print" or "printlog"
    parameter if you want to see, what the hell it does :-)


 3. Default chains

    By default the following chains will be started:

	1. KERNEL
           this is in fact not really a chain script, it set some
           kernel parameters and loads some modules, if neccessary.

        2. SERVICE CHAINS (FTP, WWW and so forth)
           these will be referenced later by input and output chains

        3. POSTROUTING
           this is the one, that initializes NAT. (Source NAT in fact)

        4. BLOCKED
           this one blocks broadcasts, reserved address spaces to avoid
           ip spoofing

        5. RFC
           this blocks RFC address spaces (in both directions). If one
           of your internal or external networks IS in an rfc address-
           space, it will NOT blocked, of course

        6. INPUT_EXTERN, INPUT_INTERN
           the general input chain will refer to one of this chains,
           which are controling incoming or outgoing traffic.

        7. INPUT
           the buildin input chain, just desides, from which interface
           the incoming traffic comes and forwards to the appropriate
           INPUT_* chain.

        8. OUTPUT
           this is the chain, which controlls, which traffic is allowed
           to leave the firewall itself, i.e. dns query replys.

        9. FORWARD
           controlls the buildin forward chain. by default it just applies
           the default policy, nothing more.
          

   When the firewall will be stopped (or restarted), then the order is
   exactly vise-versa.	
