8.1 Debugging Your Filtering Rules
So now it's all set up and nothing works! You're locked in. Who knows what's going on on the other side of the wall. Now what?
General Tips
- Work on one service at a time.
- Again, the first matching rule wins. Order is important. Use the
ipfwadm -[FIO] -lncommands described below as you go to get a feel for how the rules are ordered. Trace your new port type through the rules. - Always execute the rules from a complete test script. Be sure the script flushes all existing rules and resets the default policies first. Otherwise, you won't be sure which rules are in effect.
- Don't execute new rules from the command line. Especially don't execute the flush and default policy rules from the command line if you're telneted into your firewall from any other system, including another system on your local network. You'll be cut off immediately.
- If a service works on your local network but not externally, turn on logging for accepted packets for your internal traffic to see what packet types, ports, ACK flags, etc. are being sent in both directions.
- If a service doesn't work at all, temporarily change the default incoming and outgoing policies to accept and log incoming accepted packets. Is the service available now?
Checking the Firewall with ipfwadm -ln
It's a good idea to double check the order of your firewall rules. It's pretty easy to define all the rules you want but to get them out of order. Remember, the first matching rule wins.
The commands are:
ipfwadm -F -l -n
ipfwadm -I -l -n
ipfwadm -O -l -n
Checking Your Forwarding Rules
> ipfwadm -F -l -n
IP firewall forward rules, default policy: deny
type prot source destination ports
acc/m all 192.168.1.0/24 0.0.0.0/0 n/a
This says that the default forwarding rule is to deny. The table includes one rule which says that:
Any packets coming from the local network, destined for anywhere, are masqueraded and passed on through the external interface.
Checking Your Output Rules
> ipfwadm -O -l -n
IP firewall output rules, default policy: deny
type prot source destination ports
rej all 0.0.0.0/0 24.128.61.117 n/a
rej all 0.0.0.0/0 10.0.0.0/8 n/a
rej all 0.0.0.0/0 172.16.0.0/12 n/a
rej all 0.0.0.0/0 192.168.0.0/16 n/a
rej all 0.0.0.0/0 127.0.0.0/8 n/a
acc all 192.168.1.1 0.0.0.0/0 n/a
acc all 24.128.61.136 0.0.0.0/0 n/a
This says that the default output rule is to deny. The table includes seven rules which say that:
- No output from the external interface may be sent to the external interface.
- No output from the external interface may be sent to the a Class A private network.
- No output from the external interface may be sent to the a Class B private network.
- No output from the external interface may be sent to the a Class C private network.
- No output from the external interface may be sent to the loopback interface.
- All output identified as coming from the local LAN will be accepted.
- All output identified as coming from this machine will be accepted.
Notice that the acceptance rules follow the deny and reject rules. If the acceptance rules came first, they would override the rules intended to deny spoofed packets.
Checking Your Input Rules
> ipfwadm -I -l -n
IP firewall input rules, default policy: deny
type prot source destination ports
deny all 24.128.61.136 0.0.0.0/0 n/a
deny all 10.0.0.0/8 0.0.0.0/0 n/a
deny all 172.16.0.0/12 0.0.0.0/0 n/a
deny all 192.168.0.0/16 0.0.0.0/0 n/a
deny all 127.0.0.0/8 0.0.0.0/0 n/a
acc icmp 0.0.0.0/0 24.128.61.136 0,3,4,11,12
acc icmp 24.128.0.0/16 24.128.61.136 8
acc all 192.168.1.0/24 0.0.0.0/0 n/a
deny tcp 0.0.0.0/0 24.128.61.136 * -> 2049, 2000, 6000:6001
deny udp 0.0.0.0/0 24.128.61.136 * -> 2049
acc udp 24.128.60.8 24.128.61.136 53 -> 53
acc tcp 0.0.0.0/0 24.128.61.136 1024:65535 -> 80
acc tcp 0.0.0.0/0 24.128.61.136 80 -> 1024:65535
This says that the default input rule is to deny. The table includes 12 rules which say that:
- Any packet coming in on the external interface claiming to be from the the firewall machine will be denied.
- Any packet coming in on the external interface claiming to be from a Class A private network will be denied.
- Any packet coming in on the external interface claiming to be from a Class B private network will be denied.
- Any packet coming in on the external interface claiming to be from a Class C private network will be denied.
- Any packet coming in on the external interface claiming to be from the loopback interface will be denied.
- Selected incoming ICMP packets addressed to the firewall machine will be accepted from anywhere.
- Incoming ping requests will only be accepted from your ISP machines.
- Any packet coming in on the internal interface will be accepted.
- Any packet coming in on the external interface using the TCP protocol that's addressed to the NFS, openwindows or X windows (unprivileged) ports will be denied.
- Any packet coming in on the external interface using the UDP protocol that's addressed to the NFS port will be denied.
- Rules 10-12 are example acceptance rules for DNS, you as web server, and you as web client.
Testing a Rule with ipfwadm -c
Individual rules and packet types can be tested. The -c option will report whether the packet would be accepted or denied by the firewall rules currently in force.
The argument syntax is exacting for this option. All of the options included in the two examples below are necessary.
ipfwadm -I -c -P udp -W eth0 -V Your_IP_Addr -S any/0 53 -D Your_IP_Addr 53
ipfwadm -I -c -k -P tcp -W eth0 -V Your_IP_Addr -S any/0 20 -D Your_IP_Addr 6000
8.2 Checking Port Usage with netstat -a
netstat -a prints a table of all active interfaces currently in use or not. The status of every active port address is listed. You should be able to justify every entry in the table.
Some entries are listed because of local system daemons. For example, you disabled external access to the sunrpc port. But the local portmap daemon listens to that port, too.
8.3 Checking Processes with ps aux
ps aux lists every process active on your machine. You should be able to justify every process listed. (The list will be smaller if you have only one login to the console and aren't running X Windows.)
Mostly, you don't want to see daemons you thought you had disabled and daemons you won't use.
8.4 Setuid and Setgid Programs
setuid programs and scripts are usually run as root. Be certain that there are no programs or scripts editable or writable by all. It's better to not allow general read access to these programs either.
To generate a list of these files, execute the following:
find / -type f \( -perm -04000 -o -perm -02000 \) -ls
The worst offenders tend to be games, as it turns out.
