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
