Next
Previous
Contents
You should read the
Firewall-HOWTO.
That will tell you where to get ipfwadm if you don't already
have it. There are other tools you can get but I made no progress until
I tried ipfwadm. It is nice and low level! You can see exactly what
it is doing.
You have compiled IP-forwarding and masquerading into the kernel so
you will want to check that the firewall is in its default (accepting)
state with
ipfwadm -I -l ipfwadm -O -l ipfwadm -F -l
That is respectively, "display the rules affecting the .."
incoming or outgoing or forwarding (masquerading) ".. sides of the
firewall". The "-l" means "list".
You might have compiled in accounting too:
ipfwadm -A -l
You should see that there are no rules defined and that the default
is to accept every packet. You can get back to this working state anytime
with
ipfwadm -I -f
ipfwadm -O -f
ipfwadm -F -f
The "-f" means "flush". You may need to use that.
I want to cut the world off from my internal net and do nothing else,
so I will want to give as a last (default) rule that the firewall should
ignore any packets coming in from the internal net and directed to outside.
I put all the rules (in this order) into /etc/rc.d/rc.firewall and
execute it from /etc/rc.d/rc.local at bootup.
ipfwadm -I -a reject -S 192.168.2.0/255.255.255.128 -D 0.0.0.0/0.0.0.0
The "-S" is the source address/mask. The "-D" is
the destination address/mask.
This format to is rather long-winded. Ipfwadm
is intelligent about network names and some common abbreviations. Check
the man pages.
It is possibly more convenient to put some or all of these rules on
the outgoing half of the firewall by using "-O" instead of "-I",
but I'll state the rules here all formulated for the incoming half.
Before that default rule, I have to place some rules that serve as exceptions
to this general denial of external services to internal clients.
I want to treat the firewall machines address on the internal net specially.
I will stop people logging in to the firewall machine unless they have
special permission, but once they are there they should be allowed to talk
to the world.
ipfwadm -I -i accept -S 192.168.2.100/255.255.255.255 \
-D 0.0.0.0/0.0.0.0
I also want the internal clients to be able to talk to the firewalling
machine. Maybe they can persuade it to let them get out!
ipfwadm -I -i accept -S 192.168.2.0/255.255.255.128 \
-D 192.168.2.100/255.255.255.255
Check at this point that you can get in to the clients from outside
the firewall via telnet, but that you cannot get out. That should
mean that you can just about make first contact, but the clients cannot
send you any prompts. You should be able to get all the way in if you use
the firewall machine as a staging post. Try rlogin and ping too,
with tcpdump running on one card or the other. You should be able
to make sense of what you see.
I went on to relax the rules protocol by protocol. I want to allow pings
from the outside to the inside to get an echo back, for instance, so I
inserted the rule:
ipfwadm -I -i accept -P icmp -S 192.168.2.0/255.255.255.128 \
-D 0.0.0.0/0.0.0.0
The "-P icmp " works the protocol-specific magic.
Until I get hold of an ftp proxy I am also allowing ftp calls
out with port-specific relaxations. This targets ports 20 21 and 115 on
outside machines.
ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
-D 0.0.0.0/0.0.0.0 20 21 115
I could not make sendmail between the local clients work without
a nameserver. Rather than set up a nameserver right then on the firewall,
I just lifted the firewall for tcp domain service queries precisely aimed
at the nearest existing nameserver and put its address in the clients /etc/resolv.conf
("nameserver 123.456.789.31 " on a separate line).
ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
-D 123.456.789.31/255.255.255.255 54
You can find which port number and protocol a service requires with
tcpdump. Trigger the service with a an ftp or a telnet
or whatever to or from the internal machine and then watch for it on the
input and output ports of the firewall with tcpdump:
tcpdump -i eth1 -e host client04
for example. The /etc/services file is another important source
of clues. To let telnet and ftp IN to the firewall from outside,
you have to allow the local clients to call OUT on a specific port. I understand
why this is necessary for ftp - it's the server that establishes
the data stream in the end - but I am not sure why telnet also needs
this.
ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 ftp telnet \
-D 0.0.0.0/0.0.0.0
There is a particular problem with some daemons that look up the hostname
of the firewalling machine in order to decide what is their networking
address. Rpc.yppasswdd is the one I had trouble with. It insists
on broadcasting information that says it is outside the firewall (on the
second card). That means the clients inside can't contact it.
Rather than start IP aliasing or change the daemon code, I mapped the
name to the inside card address on the clients in their /etc/hosts.
You want to test that you can still telnet, rlogin and
ping from the outside. From the inside you should be able to ping
out. You should also be able to telnet to the firewall machine from
the inside and the latter should be able to do anything.
That is it. At this point you probably want to learn about rpc/Yellow
Pages and the interaction with the password file. The firewalled
network wants to run without its unprivileged users being able to log on
to the firewall - and thus get out. Some other HOWTO!
Next
Previous
Contents
|