The firewall configuration is held in subversion, at the url svn+ssh:username@subversion.sihnon.net/var/svn/repos/configs/firewall/santo/iptables.bath. The live copy of the rules are held in santo:/etc/firewall/iptables.bath, and have been checked out using read-only https access to the repository. Please edit changes in your homedir, commit the changes to subversion, and update the live copy to update the config; do not make changes to the live copy of the rules as these cannot be committed to the repository and the changes may be lost. To test rules while editing the rules file, the iptables-restore tool can be used. Changes made using this tool are not persistent and will not survive a reboot. To add new holes for specific machines, scroll to the bottom of the file and copy an existing example. To add new machines is slightly more complex, but there are already examples for most scenarios in this file. To permanently affect the changes to the configuration, run the following commands on firewall.sihnon.net: ''0@@'' ===== Host firewalls ===== All traffic flows through the gateway firewall before reaching any local machines, and so individual firewalls are not essential. Firewall configuration is held in subversion, under configs:/firewall, in a subdirectory named after the host. ===== Miscellaneous tips and tricks ===== ==== Policy Routing with OpenVPN ==== The problem is that with the VPN connected, any packets directed to the office will be sent through the VPN. If the connection originated from the local network, that's fine, but if the connection originated from work and arrived via the default gateway, then things fall apart. The VPN at work uses NAT, so any packets that go through the VPN have the source address changed; if that packet is a response to a connection routed through the Internet rather than the VPN, the packet will be dropped. What is needed is a means to chose whether to route a connection through the VPN or through the default gateway, based on where the first packet in that connection arrived from. This is done through policy routing. Policy routing needs the following kernel options set: 2.6.28-gentoo-r1|''1@@'' Create an alternate routing table by adding the following line to the end of rt_tables. /etc/iproute2/rt_tables|''2@@'' The name "vpn" is used here, but the only connections which will use this table are those that will be routed through the default gateway. The name is chosen because the VPN is the reason the table is needed, not because the table contains rules for the VPN itself. The default gateway should be added to both routing tables, along with any other static routes if needed. /etc/conf.d/net|''3@@'' Now we need to specify that certain connections will be sent according to the alternate routing table instead of the main one. These scripts are stored in subversion, under routing-rules init script at configs:/network/router but is configured like this: /etc/conf.d/routing-rules|''4@@'' /etc/init.d/routing-rules|''5@@'' The final bit of magic comes in the form of some iptables rules, which mark particular connections to use the alternate routing table: iptables-rules|''6@@'' ==== Traffic Shaping ==== These have not been tested yet, but might be useful: * http://tech.slashdot.org/comments.pl?sid=563290&cid=23532554 * http://tech.slashdot.org/comments.pl?sid=563290&cid=23532858 ==== Mark traffic based on incoming interface ==== In the mangle table <code bash> - Mark packets depending on which vlan the arrived from - use the lower 4 bits of the mark space to store this information - and set it in such a way as to not distrupt the rest of the bitspace - on the mark. -A PREROUTING -m state –state NEW -m physdev –physdev-in eth1 -j CONNMARK –set-mark 13/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in vlan1 -j CONNMARK –set-mark 1/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in vlan2 -j CONNMARK –set-mark 2/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in vlan3 -j CONNMARK –set-mark 3/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in vlan4 -j CONNMARK –set-mark 4/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in vlan5 -j CONNMARK –set-mark 5/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in vlan7 -j CONNMARK –set-mark 7/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in ath1 -j CONNMARK –set-mark 8/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in vlan9 -j CONNMARK –set-mark 9/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in vlan10 -j CONNMARK –set-mark 10/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in vlan11 -j CONNMARK –set-mark 11/15 -A PREROUTING -m state –state NEW -m physdev –physdev-in ath0 -j CONNMARK –set-mark 12/15 </code> ==== Blocking too many rapid connection attempts ==== The following iptables rules block rapid SSH connections from a single source. <code bash> - Ssh Whitelisting -N SSH_WHITELIST - Catch any Ssh traffic and block repeated connection requests - http://blog.andrew.net.au/2005/02/16 -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –set –name SSH -A INPUT -p tcp –dport 22 -m state –state NEW -j SSH_WHITELIST -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 –rttl –name SSH -j LOG –log-prefix SSH_brute_force -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 –rttl –name SSH -j DROP -A FORWARD -p tcp –dport 22 -m state –state NEW -m recent –set –name SSH -A FORWARD -p tcp –dport 22 -m state –state NEW -j SSH_WHITELIST -A FORWARD -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 –rttl –name SSH -j LOG –log-prefix SSH_brute_force -A FORWARD -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 –rttl –name SSH -j DROP - Whitelisted ip addresses and ranges -A SSH_WHITELIST -s 10.0.0.0/24 -m recent –remove –name SSH -j ACCEPT -A SSH_WHITELIST -m iprange –src-range 78.86.202.79-78.86.202.93 -m recent –remove –name SSH -j ACCEPT -A SSH_WHITELIST -s 152.78.0.0/16 -m recent –remove –name SSH -j ACCEPT -A SSH_WHITELIST -j RETURN </code>