The rc.DHCP.firewall.txt script is pretty much identical to the original
rc.firewall.txt. However,
this script no longer uses the STATIC_IP variable, which is
the main change to the original rc.firewall.txt script. The reason is that
this won't work together with a dynamic IP connection. The actual changes
needed to be done to the original script are minimal, however, I've had some
people mail me and ask about the problem so this script will be a good
solution for you. This script will allow people who uses
DHCP, PPP and
SLIP connections to connect to the Internet.
The rc.DHCP.firewall.txt script requires the following
options to be compiled statically to the kernel, or as modules, as a bare
minimum to run properly.
The main changes done to the script consist of erasing the
STATIC_IP variable as I already said and deleting all
references to this variable. Instead of using this variable the script now
does its main filtering on the variable INET_IFACE. In
other words -d $STATIC_IP has been changed to -i
$INET_IFACE. This is pretty much the only change made and that's all
that's needed really.
There are some more things to think about though. We can no longer filter in the
INPUT chain depending on, for example,
--in-interface $LAN_IFACE --dst $INET_IP. This in turn forces
us to filter only based on interfaces in such cases where the internal machines
must access the Internet addressable IP. One great example is if we are
running an HTTP on our firewall. If we go to the main
page (i.e., https://192.168.0.1/), which contains static links back to the same
host (i.e., https://foobar.dyndns.net/fuubar.html), which could be some dyndns
solution, we would get a minor problem. The
NATed box would ask the DNS
for the IP of the HTTP server, then try to access
that IP. In case we filter based on interface and IP, the
NATed box would be unable to get to the
HTTP because the INPUT chain
would DROP the packets flat to the ground. This also
applies in a sense to the case where we got a static IP, but in such cases it
could be gotten around by adding rules which check the
LAN interface packets for our
INET_IP, and if so ACCEPT them.
As you may read from above, it may be a good idea to get a script, or
write one, that handles dynamic IP in a better sense. We could for example
make a script that grabs the IP from ifconfig and adds it to
a variable, upon boot-up of the Internet connection. A good way to do this,
would be to use, for example, the ip-up scripts provided
with pppd and some other programs. For a good site, check
out the linuxguruz.org iptables site which has a huge collection of scripts
available to download. You will find a link to the linuxguruz.org site from
the Other resources and links
appendix.
 | This script might be a bit less secure than the
rc.firewall.txt script. I would definitely advise you to
use that script if at all possible since this script is more open to attacks
from the outside.
|
Also, there is the possibility to add something like this to your scripts:
INET_IP=`ifconfig $INET_IFACE | grep inet | cut -d : -f 2 | \
cut -d ' ' -f 1`
The above would automatically grab the IP address
of the $INET_IFACE variable, grep the correct line which
contains the IP address and then cuts it down
to a manageable IP address. For a more
elaborate way of doing this, you could apply the snippets of code available
within the retreiveip.txt script,
which will automatically grab your Internet IP address when you run the script.
Do note that this may in turn lead to a little bit of "weird" behavior, such
as stalling connections to and from the firewall on the internal side. The
most common strange behaviors are described in the following list.
If the script is run from within a script which in turn is executed by,
for example, the PPP daemon, it will hang all currently
active connections due to the NEW not SYN rules (see the State NEW packets but no SYN bit set section). It is possible
to get by, if you get rid of the NEW not SYN rules for
example, but it is questionable.
If you got rules that are static and always want to be around, it is
rather harsh to add and erase rules all the time, without hurting the already
existing ones. For example, if you want to block hosts on your
LAN to connect to the firewall, but at the same time
operate a script from the PPP daemon, how would you do
it without erasing your already active rules blocking the
LAN?
It may get unnecessarily complicated, as seen above which, in turn, could
lead to security compromises. If the script is kept simple, it is easier to spot
problems, and to keep order in it.
