You can use ExFilter to protect parts of your network from one another, for example to protect your personnel department's computers and files from other parts of your organisation to help keep sensitive data secure while still allowing the personnel department to benefit from your corporate IT investment.
ExFilter can be used in conjunction with other commercial and PD software to produce a very secure but highly usable connection to another untrusted network.
As well as protection, ExFilter can improve the perceived performance of your links.
To do this ExFilter helps you limit how much of each type of traffic (eg mail, FTP, news, telnet) you want on your link to fairly share the link between its users. ExFilter tries to prevent the packet traffic jams that can build up on slower links that destroy interactive performance.
ExNet itself uses ExFilter to regulate and filter its connections to the Internet.
ExFilter V1.1.3 runs on Sun-3s or Sun-4s under SunOS 4.1.x (Solaris 1).
Untar it into a temporary directory (say /tmp) and check that you have at least the following files:
ExFilter uses the NIT (Network Interface Tap) connection, and
so can attach to any device (eg Ethernet, PPP, SLIP) device which
carries IP packets and provides an NIT interface.
Setting Up Your Firewall System
To make a working firewall machine you need to strip down the kernel to
contain the minimum for speed and to provide the smallest possible
number of loop-holes and flaws for a hacker to break in through. You
will need to turn off kernel routing so that ExFilter can choose what
to allow through and what to block.
You will also need to load and configure trusted software to provide any application-level gateways you want to provide on the gateway, for example an SMTP email gateway and proxy versions of programs such as Telnet and FTP. You may also want to provide (for example) a public FTP service from the gateway.
You should not provide any user accounts other than a non-root administrator account and root itself, and you should not allow remote access to the machine over Telnet or a similar service---once entry is gained via any unprivileged account root access can usually be obtained fairly quickly by an experienced cracker (or UNIX sysadmin). You should also turn off services such as NIS that may induce a firewall machine to believe false information supplied form an external source. ExFilter, for example, uses static routing and avoids services such as NIS as far as possible to prevent remote tampering with its configuration.
Finally, you should turn off any non-essential services, such as daemons running from inetd.
In general do not configure into the OS kernel module, or load or enable any OS software from the distribution, that you do not absolutely need (you don't need NFS or NIS for example, life is somewhat tiresome without them, but only experienced administrators should be on the firewall host anyway). In particular, avoid all software that makes your host in anyway dependent on externally-provided information that may compromise your security. Again, avoid NIS and NFS (and RFS, etc), server and client, don't use inetd, etc. DNS is fine if you configure it properly, and preferably make it a primary or secondary for the network you are protecting so that it will only get data about your network directly from authoritative sources.
It is vital that you completely disable packet forwarding in the kernel of your firewall machine else the ExFilter will be short-circuited and no filtering or protection will be provided at all.
You should try to keep an eye on the security mailing lists and on Sun's current lists of publicly-available security patches (eg at Imperial College in the UK), and apply relevant patches to security holes that might otherwise allow ExFilter to be bypassed or disabled. In particular, beware of source-routing tricks that can be used to bypass ExFilter.
An example firewall kernel configuration for running ExFilter on, in this case for a Sun-3, is:
# @(#) FW 1.13@(#) 94/03/06 # # # FIREWALL KERNEL. # * Minimum disc-bootable kernel for Sun-3/50, Sun-3/60 or Sun-3/110. # * Loadable PPP 2.3 is used instead and loaded at runtime. # * IP forwarding is turned off here with IPFORWARDING=-1. # * We can also configure udp_checksum = 1 (in_proto.c). # * We can also expand the udp_ttl to 120 in in_proto.c. # # EDIT ../../netinet/in_proto.c IN ../FW BY HAND BEFORE BUILDING THE KERNEL. # # We allocate a little more space for file handles, etc, as we will be # running a lot of networking daemons. # machine "sun3" cpu "SUN3_50" # Sun-3/50 cpu "SUN3_60" # Sun-3/60 cpu "SUN3_110" # Sun-3/110 # # Name this kernel: # ident "FW1.13" # Expanded kernel for lots of UUCP/Sendmail/etc sessions. maxusers 32 # Turn off all kernel IP forwarding. options "IPFORWARDING=-1" #options QUOTA # disk quotas for local disks #options SYSACCT # process accounting, see acct(2) & sa(8) #options TCPDEBUG # TCP debugging, see trpt(8) options CRYPT # software encryption options INET # basic networking support - mandatory options OLDSCSI # Old SCSI architecture - mandatory options TMPFS # tmp (anonymous memory) file system options UFS # filesystem code for local disks options VDDRV # loadable modules config vmunix root on sd0 swap on sd0 pseudo-device pty # pseudo-tty's, also needed for SunView pseudo-device ether # basic Ethernet support pseudo-device loop # loopback network - mandatory pseudo-device win64 # window devices, allow 64 windows pseudo-device dtop2 # desktops (screens), allow 2 pseudo-device ms # mouse support pseudo-device kb # keyboard support pseudo-device snit # streams NIT pseudo-device pf # packet filter pseudo-device nbuf # NIT buffering module pseudo-device clone # clone device # connections for machine type 2 (SUN3_50) controller virtual 2 at nexus ? controller obmem 2 at nexus ? controller obio 2 at nexus ? # connections for machine type 7 (SUN3_60) controller virtual 7 at nexus ? controller obmem 7 at nexus ? controller obio 7 at nexus ? # connections for machine type 4 (SUN3_110) controller virtual 4 at nexus ? controller obmem 4 at nexus ? controller obio 4 at nexus ? controller vme16d16 4 at nexus ? controller vme24d16 4 at nexus ? controller vme32d16 4 at nexus ? controller vme16d32 4 at nexus ? controller vme24d32 4 at nexus ? controller vme32d32 4 at nexus ? controller si0 at obio ? csr 0x140000 priority 2 tape st0 at si0 drive 040 flags 1 disk sd0 at si0 drive 000 flags 0 device zs0 at obio ? csr 0x20000 flags 3 priority 3 device zs1 at obio ? csr 0x00000 flags 0x103 priority 3 device le0 at obio ? csr 0x120000 priority 3 device cgfour0 at obmem 7 csr 0xff300000 priority 4 # 3/60 device cgfour0 at obmem 7 csr 0xff400000 priority 4 # 3/60 #device cgsix0 at obmem 7 csr 0xff000000 priority 4 # 3/60 device bwtwo0 at obmem 2 csr 0x100000 priority 4 # 3/50 device bwtwo0 at obmem 7 csr 0xff000000 priority 4 # 3/60 device bwtwo1 at obmem 7 csr 0xff300000 priority 4 # 3/60 #device bwtwo1 at obmem 7 csr 0xff400000 # 3/60 # 3/110 stuff not in 3/50 or 3/60 config. # comment out the sc0 lines to save memory if you don't have a SCSI-2 board controller sc0 at vme24d16 ? csr 0x200000 priority 2 vector scintr 0x40 tape st0 at sc0 drive 040 flags 1 disk sd0 at sc0 drive 000 flags 0 disk sd1 at sc0 drive 001 flags 0 # comment out the si0 lines to save memory if you don't have a SCSI-3 board controller si0 at vme24d16 ? csr 0x200000 priority 2 vector siintr 0x40 device ie0 at obio ? csr 0xc0000 priority 3 device cgfour0 at obmem 4 csr 0xff000000 priority 4 # 3/110 #device bwtwo0 at obmem 4 csr 0xff000000 # 3/110A feature of this configuration is that it is short, because not much is configured in.
The setup for a Sun-4 is very similar. Start with a ``Generic'' or
``Generic Small'' configuration and cut away options from that, such as
NFS server and client support.
Designing Your ExFilter Configuration
An example /etc/ExFilter.conf ExFilter configuration file
is provided below. For an explanation of the syntax, see
here.
This example is constructed for the following, realistic, configuration:
# Set verbosity at just high enough to watch throttle activity, etc. verbosity 5 # # Set verbosity just above zero; only important things will be reported. # verbosity 1 # Throttle data to dp2 to 1100--1400B/s including all IP and other headers. # This does not allow for (for example) TCP header compression for # outgoing PPP/SLIP links, nor all the link-level framing overhead (though # it does include enough to cover all the Ethernet link-level headers # and any padding), nor does it allow for retries done at the link level # due to corruption, etc. # # Raw uncompressed bandwidth available on V.32b/V.42 link is about # 1700Bps; V.42b compression should improve this marginally. # # To try to avoid huge delays make around 1000--1450 throttleto dp2 1300 # Try to prevent traffic to/from our Ethernet getting out of hand! throttleto le0 200000 # We are interested in interfaces le0 and dp2. if le0 if dp2 # This gateway appears at address 1.2.3.254. # # This gateway should behave itself and decrement TTLs on all packets # passing through it, generate ICMP error packets where appropriate, # and discard (not route) all incoming packets addressed directly # to the underlying interfaces on the assumption that servers on the # host will deal with any application-level routing necessary. # The gateway will check and generate IP header checksums for packets # in transit and generated locally, and will not route packets with IP # header options. # # We do not run in `trace' mode unless we want to debug all traffic # through the gateway for some reason. # gateway 1.2.3.254 decttl icmperrs parallel chksum noopts notrace # ----------------------------------------------------------------------------- # ROUTING DIRECTIVES # ================== # Drop all packets arriving for our own interface addresses or for # broadcast addresses, etc. # That includes ignoring all packets arriving on our Ether interfaces # for any machines on those nets. # # Beware of us getting output packets getting fed back on our input # by nit and counted as input traffic. This will distort throttling. # (Some packet devices do this and some don't. Sun's le0 Ethernet # interface and out modified dp2.3 PPP drivers don't.) # # With the `parallel' option some of these rules are redundant and the rest # should be logged in case of nasty surprises. # # route deny le0 any any from any any any to 1.2.3.0 255.255.255.0 any log # # Remember not to route packets destined for any of the other interfaces # since SunOS will reply for all of them on any interface, generating # double replies potentially in some cases. # route deny any any any between any any any and 1.2.3.1 only any route deny any any any between any any any and 2.3.4.5 only any # # Log strangely-addressed packets. # route deny any any any between any any any and 127.0.0.0 255.0.0.0 any log route deny any any any between any any any and 0.0.0.0 only any log # # Ignore discless-client reboot attempts. # route deny any any any between any any any and 255.255.255.255 only any # # Ignore attempts to talk to our broadcast addresses. # route deny any any any between any and any and 1.2.3.0 only any log route deny any any any between any and any and 1.2.3.255 only any log # --------- # Spoofing attempts # ================= # # Block packets apparently from internal hosts on our subnet coming # in from the connected Internet and log such packets. It may be # attempts by crackers to cripple or steal data from some of our # machines by pretending to be our hosts. # route deny dp2 any any from 1.2.3.0 255.255.255.0 any to any any any log # --------- # NFS and other holes # =================== # # Block all attempts to reach non-privileged NFS ports on our internal hosts. # # Log any traffic denied this way. # route deny dp2 le0 udp between any any any and 1.2.3.0 255.255.255.0 2049 log # --------- # WWW # === # # Allow WWW packets to/from safehost for calls originated on safehost, # ie allow hhtpd packets to or from port 80 on any external machine to # any non-priv port on safehost. # # Limit to 50% of traffic when throttled. route allow dp2 le0 tcp between any any 80 and 1.2.3.5 only nonpriv throttle50 # --------- # TELNET/FTP # ========== # # Allow telnet packets to/from safehost for calls originated on safehost, # ie allow tcp packets to or from port 23 on any external machine to # any non-priv port on safehost. # # Limit to 50% of traffic when throttled. # route allow dp2 le0 tcp between any any 23 and 1.2.3.5 only nonpriv throttle50 # # Similarly for ftp on port 21 (and ftp-data on port 20) # # Limit to 50% of traffic when throttled. route allow dp2 le0 tcp between any any 20 and 1.2.3.5 only nonpriv throttle50 route allow dp2 le0 tcp between any any 21 and 1.2.3.5 only nonpriv throttle50 # --------- # FINGER/WHOIS # ============ # # Limit to 10% of traffic when throttled. # # Allow users on safehost to finger any remote host. # route allow dp2 le0 tcp between any any 79 and 1.2.3.5 only nonpriv throttle10 # # Similarly for whois on port 43. # route allow dp2 le0 tcp between any any 43 and 1.2.3.5 only nonpriv throttle10 # --------- # MAIL # ==== # # Allow mail directly to the SMTP mailer on mailhost (tcp->port 25). # # Mail does not have to be super-high-speed and so is limited to a lowish # bandwidth. # # Limit to 15% of traffic when throttled. # route allow dp2 le0 tcp between any any any and 1.2.3.4 only 25 throttle15 # --------- # PING # ==== # # This should be nearly last on the list so as to measure worst-case # performance from the network and ExFilter. # # Allow pings to and from anywhere. # # Note that ICMP traffic cannot be throttled. # route allow dp2 le0 icmp between any any nonpriv and 1.2.3.0 255.255.255.0 nonpriv # ----------------------------------------------------------------------------- # THINGS THAT SHOULDN'T GO THROUGH... # Block attempts to contact our internal DNS name servers. # route deny any any any between any any any and 1.2.3.0 255.255.255.0 53 nothrottle # Ignore attempts to get to one interface from another; these attempts # arise from our listing all (or most of) our external addresses for each # application-level gateway on the firewall. # route deny any any any between any any any and 1.2.3.1 only any route deny any any any between any any any and 2.3.4.5 only any # These are packets that shouldn't be getting here at all. # # Log them. # route deny any any any between any any any and any any any log
You should then start up ExFilter from /etc/rc.local after all interfaces are in place (ie after any loadable interface drivers have been loaded and configured). ExFilter has to be run as root (not set-uid root which might be a security hazard) to bind to the low-level interfaces.
Suitable lines in rc.local might be:
EXFILTER=/usr/local/bin/ExFilter.O.sun4-SunOS-4 if [ -f $EXFILTER ]; then echo 'Starting Exfilter.' ($EXFILTER &) > /dev/console fiNote that the initial verbosity (debugging level) of the daemon can be set with the optional -v flag, and the location of the configuration file with the optional -f flag.
So you might start ExFilter with a configuration file of /etc/altExFilter.conf rather than the default /etc/ExFilter.conf, and with a verbosity level of 50% rather than the default 1%, with:
EXFILTER=/usr/local/bin/ExFilter.O.sun4-SunOS-4 if [ -f $EXFILTER ]; then echo 'Starting Exfilter in an alternative way.' ($EXFILTER -v 50 -f /etc/altExFilter.conf &) > /dev/console fi
The file consists of a series of one-line records with whitespace-separated fields. The order of records and fields is important.
Completely blank lines are ignored.
The first field on a line (which must start in column one) determines the type of the record that that line is.
Case of alpha characters is significant.
Records are of unlimited length, but exceeding 256 bytes is inadvisable.
The following initial fields (ie, record types) are valid:
The aim of the mechanism invoked by this record is to avoid saturating slow connections like PPP links to ensure reasonable responsiveness for interactive traffic. Excess traffic is quenched where possible.
Records referring to interfaces not mentioned in an if record are invalid.
The interface names none and quench are reserved.
The port component is ignored for which it is meaningless, eg EGP. It is mainly intended for UDP and TCP.
(default options: fragment nolog throttle)
(default options: chksum nodecttl noicmperrs parallel noopts notrace)
The meaning of the various parameters to the record types is given below.
For protocols other than TCP and UDP this field is ignored with the following exception.
For ICMP, if the FRaddr address matches then the FRport port value has the following meanings:
The names none and quench are reserved and should not be declared as interface names in an ``if'' record.
The first parameter is the address ExFilter should use on outgoing packets it generates such as on ICMP error packets (when packets are denied passage through ExFilter, or when Source-quench messages are being sent to regulate traffic through ExFilter). You should allocate an otherwise unused address from the same subnet as the firewall on one of its interfaces for this, though you may get away with using one of the firewall's own addresses. ExFilter will appear as host piggybacking an all the firewall's IP connections with this address, so you might want to put up a DNS record for it for the benefit of remote network administrators.
Then zero or more flags can be set to control gateway behaviour. Although there are defaults, it is recommended that you set explicit values for all the parameters. As an example, to allow ExFilter to generate ICMP error messages (eg for throttling), the parameter icmperrs can be supplied. To turn it off noicmperrs can be supplied instead.
The meanings of the flags are:
ExFilter will log increasing amounts of information as its verbosity level is increased. Information logged at WARNING and above relates to security and potential system failures and should find its way into audit trails and logs inspected from time to time by a human operator. For example, warnings about packets that were `denied' transit by ExFilter are logged at WARING level. Hourly stats reporting is also done at WARNING level.
Information at INFO is of interest but not worth storing, so should probably go to the system console (throttling messages are logged at this level, for example), and DEBUG information will rarely be generated and you will probably want to make temporary changes to syslog's configuration to capture it if you want it at all.
The default level of verbosity the system runs at is 1, which reports most important events and little else. The level can be changes on the command line at start-up, in the configuration file, and with signals.
In general, the volume of output increases as the verbosity increases. The minimum level is 0 and the maximum 100. Anything at 50 or above is really only for debugging the software, and 100 will cripple the system with the amount of information generated, up to full dumps in hex of all packets seen.
Although the exact levels may change in future, the following verbosity levels below 50 are currently implemented:
To change its configuration you do not have to kill it, change the configurations files and restart it, you can just update the configuration files and send ExFilter a signal with the kill command to get it to reconfigure itself internally, dump statistics to the logs, etc.
This causes minimal disturbance to the flow of data through ExFilter and thus to users of the filtered IP service.
Those familiar with operation of the named DNS/BIND daemon will recognise the way that signals are used for interaction with ExFilter.
When ExFilter starts it reads its configuration information from a file called /etc/ExFilter.conf, of a format described above. The ExFilter daemon writes its process ID to a file called /etc/ExFilter.pid. This makes signaling the daemon relatively painless.
If you want to alter the configuration of ExFilter while it is running, edit the /etc/ExFilter.conf file appropriately, and send the ExFilter daemon a `HUP' signal (see the UNIX manual pages for a discussion of the different signals and their original meanings) by issuing the shell command:
kill -HUP `cat /etc/ExFilter.pid`The full list of signals and their effects is:
The solution it to ensure the MTU on all connections is either >=536 for WAN connections (since most hosts should stick to a conservative MTU of 512 bytes plus IP header for non-local traffic), or ensure the MTU on all interfaces is the same (we ensure it is 1500 for all connections routed by ExFilter), so it need never fragment.
Incoming fragments are handled correctly, but can be discarded if the `nofrag' flag is used in the appropriate route description.
ExFilter keeps a small hashed table of hosts/ports to which it has recently sent quench messages to try to send a maximum of one such quench on each `connection' each second; this table may overflow with a large number of different end-points communicating.
ExFilter cannot easily account for traffic originating to and from the firewall host itself, and such traffic will not be seen by the throttling mechanism and may allow the link to be more loaded than is desirable. Minimise the volume of traffic to/from processes on the firewall machine to minimise this problem.
In a future release regulation by round-trip time (RTT) will be added to help overcome some of these difficulties.
ExFilter does not specifically recognise and expedite `interactive' packets at the moment, but the throttle feature should be used to keep interactive performance reasonable at all times.
Note also that ExFilter relies on the kernel's ARP tables and broadcasts packets it cannot find and entry for in the host's ARP tables.
Port-number range support will be added to the routing rules in a future release, in addition to the current fixed number, priv and nonpriv values.