SourceFiles.org - Use the Source, Luke

F I R E | G A T E
Copyright 2002-2003 Jeff Bonner (firegate@lunarfox.com)

FREQUENTLY ASKED QUESTIONS

Q: "What kernel modules does FIRE|GATE use?"
1. See the file "KERNEL-CFG" for all the modules used on the author's test machine. Some of these are not technically necessary at present; in fact, FIRE|GATE uses only a few of them right now.

        Why put them all in?  From a security standpoint, it can be
        more secure to have a read-only (monolithic) kernel.  Thus,
        you need to know which modules to insert ahead of time and
        include them all; otherwise, you'd have to recompile for the
        slightest change.
        
        Most people use the easier -- but somewhat less secure --
        Loadable Kernel Module (LKM) method (via insmod, modconf,
        or what have you) while the kernel is still running.  The
        trouble is, a hacker may also do the same, and once your
        kernel has been compromised, all bets are off.
        
        See the information at http://grsecurity.org for details on
        closing up the /dev/kmem hole and other risks; alternatives
        include http://www.lids.org and similar patches.

2) Q: "I'm not sure what option I am missing from my kernel config

        (I'm using 2.4.20) but I get an error when starting/stopping
        firegate:"
         --snip--
         [root@box /]# /etc/firegate start
         FIRE|GATE v0.77 starting... iptables: libiptc/libip4tc.c:386: do_check:
         Assertion `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
         /etc/firegate: line 549:   376 Aborted                 $IPT -t mangle -F
         DONE.

The exact cause of this failure has not been determined; it may be a difference in the version of IPtables used (the author's machine uses 1.2.6a) or only certain combinations of IPtables and particular kernels.

        A temporary solution is to remove all lines referring to
        the "mangle" table in the script.  This should not affect
        FIRE|GATE because it doesn't make use of mangle (although
        users may have their own rules, which is why any of these
        are flushed upon STOPping the firewall).

3) Q: "I tried running firegate and configured it correctly, but I

        get a bunch of `No chain/target match by that name' errors,
        however the routing seems to be working fine."

In this particular case, it was a missing kernel module, "CONFIG_IP_NF_TARGET_REJECT=y", which is required for the script to be able to reject auth queries on port 113 (as opposed to dropping them, which causes a delay). Since the "--reject-with-tcp-reset" handling is affected by the IDENT variable, you may or may not see this depending on how you've configured your firewall.

        Note the line number associated with your error and then
        double-check your kernel configuration to make sure that
        given module is compiled.  See the "kernel-cfg-078" file
        to verify what's needed.

4) Q: "How do I make FIRE|GATE handle H.323?"

Videoconferencing via H.323 (Microsoft NetMeeting, CuSee Me, Intel Video Phone, etc) is not explicitly supported by this script.

        However, a patch does appear to be available.  In theory, if
        one opens up port 1720 inbound and loads the H.323 module,
        it should work.  However, tunnelling and RAS/gatekeepers are
        not supported.
        
        See http://www.e-infomax.com/ipmasq/matrix24.html for a list
        of application modules supported (or not) by the 2.4 kernel
        and a link to the netfilter.org page with the patch you need.
        Some of these concerns may also be addressed by the new 2.6
        kernel:  "Linux's NAT/masquerading support has been extended
        to better handle protocols that require multiple connections
        (H.323, PPTP, etc.)" (http://www.kniggit.net/wwol26.html)

5) Q: "What's with all these dropped packets from legitimate and

existing connections (could be web or IM client traffic)?"

For reasons as yet unknown, certain packets may be dropped, and occasionally en masse. This could be due to any of the following: bugs in netfilter, bugs in this script, or bugs in the implementation of traffic to/from that IP. On the whole, the traffic is not adversely affected; however with some IM clients this does appear to be the cause of failure to allow file transfer, etc. Later revisions of this script will attempt to address these problems; in the meantime, you may sometimes see valid traffic displaying ***PACKET DROP*** error messages in your logs.