Re: Bridging Firewall

[Joel Newkirk <netfilter@newkirk.us>]

On Wednesday 05 February 2003 05:01 pm, Tim Roberts wrote:
> Hi, I successfully configured (I think) a bridging firewall using
> Script provided in David Whitmarsh's how too at
> http://www.sparkle-cc.co.uk/firewall/firewall.html I have a few
> questions as I am trying VERY hard to never have to see a Windows
> XXAnything disc again.
>
> 1.) I do not see anything other than IPTables starting up and
> learning.......in /var/log/messages. I have unremarked kernal* to
> point to /var/log/messages. I think the only logging being done is if
> a DOS occurrs. Based on his script, how do I enable more or any
> logging that will show me a little or alot of something? :)

If you want to write something to the log during script execution, just 
use echo right in the script.  Very handy for 'breakpoint' style 
debugging of the script.  I'd suggest adding a prefix like "IPT:" to the 
echoed string, to make it easily greppable.  Otherwise, use the "-j LOG" 
target to write log entries when matching packets hit the LOGging rule.  
(the same suggestion applies here, using "--log-prefix" parameter)

> 2.) I have 2 NIC's both public (which is why I choose to bridge) In
> this script, I enabled the option to allow remote access from my LAN.
> However I cannot even ping.....from inside the LAN ,the specified
> address in the script to the firewall.

I've never worked hands-on with bridging, so I don't know if this is an 
effect of the set-up or not.  Are you sure the interface is up with that 
IP?

> 3.) The firewall cannot ping outside the LAN (which I could care less)
> but Im getting messages when the script runs that the machine cannot
> lookup or resolve FQDN's specified to be blocked.

Try inserting "dig {FQDN}" in the script, it should output its results to 
the logfile as well, and you can look to see if DNS is working correctly 
at that point in the process...  Generally it is much quicker, and 
technically safer, to specify IPs instead of FQDNs anyway.

I've commented on a few (fragmented out-of-context) portions of the 
script below...


> # Our interfaces don't have IP addresses so we have to start with the
> mangle # PREROUTING table

???  I realize this is from the original script, but still: ???

> $IPTABLES -t mangle -P PREROUTING DROP

You should never have anything but ACCEPT policy for any mangle table 
chains, nor for any nat table chains.  Filter in the filter table.

> # Now we are pretty secure, let's start the bridge
> # This will create a new interface

Simply setting DROP policy in INPUT, OUTPUT, and FORWARD chains is quite 
secure.  So long as there are no rules in any of those chains, the ONLY 
thing that will ever see a packet is netfilter itself.

> # Block obvious spoofs
>
> $IPTABLES -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP
> $IPTABLES -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP
> $IPTABLES -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP

These should be done in the FORWARD chain of the filter table, and 
possibly in the INPUT chain of the filter table, NOT in any mangle table 
chains.

> # Accept internal packets on the internal i/f
> $IPTABLES -t mangle -A PREROUTING -i $LAN_IFACE -s
> $INTERNAL_ADDRESS_RANGE -j ACCEPT

Again here. 

> $IPTABLES -t mangle -A PREROUTING -i $INET_IFACE ! -s
> $INTERNAL_ADDRESS_RANGE -j ACCEPT

Repeat after me:  "FILTER in the FILTER table.  MANGLE in the MANGLE 
table.  NAT in the NAT table."  :^)  I don't care what Mr Whitmarsh's 
script and tutorial state, this is NOT what the mangle table is for, and 
is just generally a bad idea.  For what you are doing in this setup, you 
don't even NEED the mangle table, or the nat table.

> $IPTABLES -A FORWARD -p ALL -s $INTERNAL_ADDRESS_RANGE -j ACCEPT
> $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

A good start, although some situations warrant tighter control on what 
the local clients are allowed to do.

> $IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG
> --log-level 7 --log-prefix "IPT FORWARD packet died: "

This doesn't make much sense.  All this does is log ANY packet  (well, 
actually only 3/minute maximum) that didn't come from 
INTERNAL_ADDRESS_RANGE and isn't part of or related to an ESTABLISHED 
connection, and refer to it as having 'died'.  They haven't necessarily 
'died', especially since there are more FORWARD rules below this point.

> $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 0 -j 
ACCEPT        # echo reply
> $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 3 -j 
ACCEPT        # dest unreachable
> $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 5 -j 
ACCEPT        # redirect
> $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j 
ACCEPT       # time exceeded

> $IPTABLES -A FORWARD -p ICMP -j icmp_packets

These should all be caught by the "ESTABLISHED,RELATED" state rule above, 
since they are all 'response' type communications.

> $IPTABLES -A udpincoming_packets -p UDP -s 0/0 --source-port 53 -j 
ACCEPT       # DNS
> $IPTABLES -A udpincoming_packets -p UDP -s 0/0 --source-port 123 -j 
ACCEPT      # ntp

> $IPTABLES -A FORWARD -p UDP -j udpincoming_packets

Same here.  Since you are specifying source-port of 53 and 123, then 
these should only match replies coming back, which would already have 
matched "ESTABLISHED,RELATED".  (However, someone could try to connect 
to ANY UDP port they want, and so long as the source-port is one of 
these, your firewall would allow the connection to be established!)

> $IPTABLES -A tcp_packets -p TCP -s 0/0 -d springfield.sparkle-cc.co.uk
> --dport 80 -j allowed # smtp 

If springfield.sparkle-cc.co.uk has a static IP, why not just use it 
here?  That would circumvent your DNS lookup difficulties... For better 
readability, assign "SPRINGFIELD=w.x.y.z" at the top, and use 
$SPRINGFIELD here.  (Nitpicking, but this is HTTP, not SMTP: of course, 
anyone who wouldn't realize this probably has no business digging 
through your firewall script anyway... :^)

> $IPTABLES -A FORWARD -p TCP -j tcp_packets

j