#!/bin/sh
FWVER=1.14
#
# doug_firewall 2014.09.17 Ver:1.14
#     Direct DROP some sub-nets from China.
#     I am fed up with them.
#     Move the INPUT related by-pass to an
#     earlier place.
#
# doug_firewall 2014.08.23 Ver:1.13
#     See also revision 1.06.
#     Increase the blanket ICMP echo request
#     drop rule from 128 to 256 bytes.
#     This is to deal with 74.213.187.140 and
#     204.244.49.91. See also tcpdump/070 and
#     tcpdump/069.
#
# doug_firewall 2014.03.30 Ver:1.12
#     Move HTTP specific blacklist to
#     port 80 NEW chains.
#
# doug_firewall 2014.03.28 Ver:1.11
#     Begin switch to PER IP on port 80.
#     Note: Customs tables referenced from
#     other custom tables must already exist.
#
# doug_firewall 2014.03.27 Ver:1.10
#     1.10 did not work, and actually made things
#     worse when the rule kicks in.
#     see incident report for 2014.03.26.
#     Break NEW HTTP out into a subroutine, but
#     otherwise behaviour doesn't change, yet.
#
# doug_firewall 2014.02.21 Ver:1.09
#     Another attempt to rate limit new connections
#     to port 80. See also revision 1.01. I'm wanting
#     to isolate and kill these jerks from Israel,
#     even though they only come once per year.
#     Note: the hitcount maximum is 20.
#
# doug_firewall 2013.11.28 Ver:1.08
#     Having added a bridge network interface
#     to an internal server, there is now constant
#     IGMP packets, from that server, hitting the
#     INPUT chain catch all logging rule.
#     Change the existing rule, very early in the INPUT
#     chain, that was only dealing with ISP (Telus)
#     IGMP packets, to a more generic rule.
#
# doug_firewall 2013.10.31 Ver:1.07
#     There was an instance, with a visitors
#     phone, of packet leakage to internet due
#     to a bogus header length of 0 (must be
#     at least 20) in the IP segment of an
#     ICMP packet.
#     Remove the tcp protocol specifier on the
#     INVALID check, so that an INVALID packet
#     for any protocol will be dropped.
#     I have no idea how to test this change.
#
# doug_firewall 2013.10.21 Ver:1.06
#     Issues with ICMP echo requests, continued.
#     Implement a blanket drop rule for shorter
#     payload packets. Thus the power of "ping" as
#     a debug tools is still present, but most, if
#     not all, of the garbage should be dropped.
#
# doug_firewall 2013.10.14 Ver:1.05
#     There is a very odd set of ICMP echo requests.
#     Once every 5 minutes, about 52 or 53 requests,
#     all from different IP addresses.
#     One identiying feature seems to be payload length.
#     Drop such ICMP echo requests.
#     The disadvantage with this method is that The bad guy
#     IP addresses are not completley banned.
#     The advantage with this method is that the list
#     of involed IP addresses is pretty long, and possibly
#     changing, and this will catch them all.
#
# doug_firewall 2013.02.21 Ver:1.04
#     With the elimination of forced module loading in the
#     overhaul edit of version 1.00, the close_wait change
#     became invalid because the file did not exist.
#     This edit will move that stuff to the end.
#
# doug_firewall 2013.01.08 Ver:1.03
#     As of about 2012.12.02 16:59:29 there seems to be an
#     endless spew of NETBIOS name service requests (port 137)
#     going out to internet. It appears to be related to a
#     windows update installed in doug-xps about that time.
#     Furthermore, it might be related to updates to
#     .NET Framework 4, but I am not certain.
#     Add an outgoing rule to REJECT or DROP port 137
#     packets.
#
# doug_firewall 2012.11.06 Ver:1.02
#     Connection limiting is blocking proper people.
#     I have it set too tight, but if relaxed it won't help.
#     For now take it out for port 80, but leave it for port 25.
#     Continue with trying to get REJECT to work properly.
#     -reject-with tcp-reset doesn't appear to work. Why not?
#     I think because typically it is a reply to a forgotten
#     connection, and so it doesn't know what to relate to.
#     Also there are troubles with default REJECT, effectively
#     --reject-with port unreachable as the ICMP INVALID state
#     applies when a related connection can not be found.
#     So, take out ICMP INVALID check.
#
# doug_firewall 2012.11.04 Ver:1.01.
#     The version1 series is not working perfectly yet
#     with respect to REJECT packets.
#     Two IP addresses (62.219.8.230 then 192.114.71.13) were
#     copying my entire web site.
#     Try adding connection limiting, as so many
#     recommend.
#
# doug_firewall 2012.11.01 Ver:1.00.
#     An overhaul. Get rid of obsolete stuff, such
#     as module loading.
#     Switch to REJECT instead of DROP in some places,
#     in an attempt to reduce extra packets.
#     No longer need specific MAC stuff.
#
# doug_firewall 2012.10.02
#     A port forwarding test
#
# doug_firewall 2012.08.09
#     Temporary edit to block some more
#     jerks.
#
# doug_firewall 2012.07.06
#     Temporary edit to block these idiots
#     at cleanmx that have declared one of
#     my web pages to be a phishing site.
#     The stupid jerks.
#
# doug_firewall 2012.06.15 Ver:0.41.
#     Static External IP address change.
#     209.121.28.192 > 173.180.45.4
#     External gateway also changes, which
#     this rule set monitors the MAC address.
#
# doug_firewall 2012.02.20 Ver:0.40.
#     Add a log entry for each port 80 NEW connection.
#     While the SYN attack of 0.39 has ended, the connection
#     rate is still slightly higher than expected. This
#     is merely to help investigate.
#     I am also changing from NEW, RELATED, ESTABLISHED to
#     NEW because there is an ealier path for RELATED, ESTABLISHED.
#
# doug_firewall 2012.02.13 Ver:0.39.
#     SYN flood attack. (SYN trickle attack.)
#     see also version 0.29 and 0.27.
#     This one uses illegal port numbers, as well as real ones.
#     Try to create a bad_guy list based on illegal port number.
#
# doug_firewall 2011.12.31 Ver:0.38.
#     Roll back to same as ver 0.36, but left the PS3 port 3074
#     stuff commented out.
#
# doug_firewall 2011.10.03 Ver:0.37.
#     Forward port 3074 and 3075 requests directly to the PS3,
#     but after related established check.
#     Does it improve the game experience?
#     Temporarily allow 169.254.X.X incoming. This is for an experiment,
#     and raises no security risk, as all the other rules are still applied.
#     It is likely this version will be rolled back to 0.36.
#
# doug_firewall 2011.09.20 Ver:0.36.
#     Add some debug only log entries. Normally commented out.
#
# doug_firewall 2011.08.11 Ver:0.35.
#     Move the 0.34 edits from the OUTPUT chain to the FORWARD chain.
#     Double up the INPUT RFC1918 checks into the FORWARD chain.
#     The path through the iptables depends on the final destination,
#     and some bad packets were still getting through, both ways.
#
# doug_firewall 2011.04.19 Ver:0.34.
#     The PS3 playing internet Call of Duty (Black Ops), and perhaps
#     many other games, has some serious issues. It is sending
#     packets to non-routable (RFC1918) destinations (see port 3074
#     traffic). I assume it is told to do so by some server. Clearly,
#     it should not be told to do such things.
#     Add outgoing RFC1918 destination address checks.
#     The SYN flood attack noted in 0.29 and 0.27 has long since ended.
#     Remove the rules specifically related to this attack (but by
#     commenting out only, so that I can recall how to do such rules
#     in the future).
#
# doug_firewall 2011.03.26 Ver:0.32.
#     Take out ICMP DNAT invalid drop.
#
# doug_firewall 2011.02.27 Ver:0.31.
#     I had a misconception about TCP --syn.
#     Fix and remove related debug stuff.
#
# doug_firewall 2011.02.26 Ver:0.30.
#     Many debug and experimental rules added.
#     There should not be any functional difference.
#     However, watch the log file sizes.
#
# doug_firewall 2011.02.24 Ver:0.29.
#      The SYN flood attack, noted in 0.27 below, continues.
#      Many source IP addresses are used.
#      Rather than try to keep up with them, try
#      a DROP rule based on the TCP window size of 61690,
#      which doesn't seem to occur elsewhere.
#      If that has issues then the sequence number
#      always seems to be 846930886.
#
# doug_firewall 2011.02.23 Ver:0.28.
#      Major change. To speed up investigations, I am going to
#      make each log-n-drop jump unique, with a log prefix that
#      I can then use grep to extract. So, perhaps at a little
#      cost of extra time to traverse the table, I might as well
#      just do it in-line.
#      For debugging purposes only, add back INVALID check to
#      the INPUT chain.
#
# doug_firewall 2011.02.22 Ver:0.27.
#      Block 203.81.*.* directly.
#      This after 2 SYN flood attacks in less than 24 hours.
#      It was not a problem, but my system was replying to the
#      port 80 requests 6 times per NEW SYN request. I.E.
#      packet gain was 6 times.
#
# doug_firewall 2011.02.10 Ver:0.26.
#      Version 0.25 works fine and as expected.
#      However, the majority of the INVALID packets have
#      the RST flag set and the system doesn't seem to allow
#      replying with another packet with the RST flag set.
#      It depends on the local computers, MACs tend to send
#      more FIN-ACK packets whereas windows computers seem
#      to send more RST packets. At this point it is only a few
#      extra termination packets per INVALID termination session.
#      This edit will basically go back to a default policy of
#      DROP for the OUTPUT chain, which is more secure anyhow.
#      Now, since the REJECT with RST flag packets will get
#      dropped in the OUTPUT chain anyhow, also change to DROP
#      INVALID TCP packets.
#      This edit also includes some clean up.
#
# doug_firewall 2011.02.10 Ver:0.25.
#      O.K. the ip_conntrack_tcp_loose setting of 0 results
#      in leakage packets again. So, this version will go back
#      to using the INVALID TCP packet check in the FORWARD
#      chain as per version 0.23. However, it will also
#      use a default policy of ACCEPT rahter than DROP for the
#      OUTPUT chain so that the REJECT packet with the RST flag
#      set can get through. It is the local network that we are
#      trying to keep in order here. All we are wanting to do
#      is get the local client to not keep sending these
#      INVALID packets  many times for each occurance of this
#      condition. One needs to be certain that no undesired
#      packets will get through the OUTPUT chain with the
#      ACCEPT policy. The other option is to leave the default
#      policy as DROP and not bother trying to REJECT the
#      INVALID TCP packets, but just DROP them. The local clients
#      eventually do give up sending the INVALID TCP packets.
#      Also remove temporary rule introduced in version 0.21.
#
# doug_firewall 2011.02.09 Ver:0.24.
#      While the INVALID TCP packet check is working fine,
#      and has eliminated the packet leakage issue,
#      the REJECT packets (which contain a TCP RST) are being
#      trapped by the OUTPUT chain rules which DROPs them.
#      This version will try the ip_conntrack_tcp_loose=0 method
#      (which will be persistantly set outside of this file)
#
# doug_firewall 2011.02.05 Ver:0.23.
#      Still have packet leakage.
#      move INVALID TCP check to forward chain.
#
# doug_firewall 2011.02.04 Ver:0.22.
#      More TCP rules in an attempt to cover strange
#      states that end up in packet leakage.
#
# doug_firewall 2011.01.30 Ver:0.21.
#      Temporary, until I can fix it at the source,
#      trap and DROP escaping netbios-ns stuff (port 137).
#
# doug_firewall 2011.01.29 Ver:0.20.
#      NEW TCP SYN rule is still not giving expects results.
#      This edits will only look at eth0.
#      Add site specific rule to drop all packets
#      from the wireless router gateway, which is configured
#      as a switch, but I can not get it to shutup.
#      See 192.168.111.57 rule.
#
# doug_firewall 2011.01.28 Ver:0.19 Fix NEW TCP SYN rule.
#
# doug_firewall 2011.01.27 Ver:0.18 Changes to POSTROUTING.
#      Switch back to "stronger" form of POSTROUTING from
#      the "more liberal" switched to in version 0.17.
#      The "more liberal" form had the same rogue packet issue.
#      I think the rogue packets are due to incorrect
#      handling of what the server thinks is a NEW TCP
#      connection and the local client thinks is an existing
#      connection. In such cases, the SYN bit is not set,
#      therefore add a rule to check for it and drop such packets
#      so that they do not escape to internet.
#
# doug_firewall 2011.01.26 Ver:0.17 Changes to OUTPUT chain.
#      Note: Version 0.16 was retracted. It was an attempt
#      to make the output sanity check actually work. It turns
#      out to not be possible to do a complete sanity check
#      on output packets as we not have access to the after
#      NAT IP address. RFC1918 packets are still escaping.
#      Sometimes NAT seems to forget the translation and some packets
#      go through with the original (192.168.111.100, for example)
#      IP address as the source.
#      Specifically, this edit will eliminate some output rules that
#      didn't work anyhow and change to try the "more liberal" form
#      of NAT (using MASQUERADE) rather than the stonger form
#      (using SNAT).
#
# doug_firewall 2010.12.28 Ver:0.15 INPUT chain addition:
#      Specifically drop bad source MAC.
#
# doug_firewall 2010.12.26 Ver:0.14 Complete the sanity checks.
#      Use the IPv4 reserved and private allocation master references.
#
# doug_firewall 2010.12.26 Ver:0.13 Sanity checks. Some RFC1918 packets
#      are escaping.
#      Similiarly, look for RFC1918 voilations on incoming packets.
#      Temporarily add log-n-drop user chain. I prefer direct drop, but
#      am having difficulty tracing all of tracffic.
#
# doug_firewall 2010.12.21 Ver:0.12 Duhhh... Enable e-mail port.
#
# doug_firewall 2010.12.19 Ver:0.11 Expand basic nat to include firewall.
#          There is not a lot left over from the old server firewall.
#
# doug_nat 2010.12.19 Ver: 0.10 Setup IP forwarding and masquerading.
#          Among other references, see:
#          http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/index.html
#          The above refernece has many many comments within it's
#          example script.
#
#               Initial SIMPLE IP Masquerade test for 2.6 / 2.4 kernels
#               using IPTABLES.
#

echo "Loading doug_firewall version $FWVER..\n"

# The location of the iptables program
#
IPTABLES=/sbin/iptables

#Setting the EXTERNAL and INTERNAL interfaces and addresses for the network
#
EXTIF="eth1"
INTIF="eth0"
EXTIP="173.180.45.4"
INTNET="192.168.111.0/24"
INTIP="192.168.111.1/32"
UNIVERSE="0.0.0.0/0"

echo "   External Interface: $EXTIF   Internal Interface: $INTIF   External IP: $EXTIP  Internal Network: $INTNET   Internal IP: $INTIP"

#CRITICAL:  Enable IP forwarding since it is disabled by default
#
echo Enabling forwarding...
echo "1" > /proc/sys/net/ipv4/ip_forward

# Dynamic IP users:
#
#   If you get your IP address dynamically from SLIP, PPP, or DHCP,
#   enable this following option.  This enables dynamic-address hacking
#   which makes the life with Diald and similar programs much easier.
#
# Smythies: I get my adress via DHCP, but it is a static address.
# Smythies: I wonder if I need this?
# Smythies: Action: Try without it.
echo Enabling DynamicAddr...
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

#Clearing any previous configuration
#
echo "  Clearing any existing rules and setting default policy to DROP.."
$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT DROP
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
# Otherwise, I can not seem to delete it later on
$IPTABLES -F log-n-drop
$IPTABLES -F http-new-in
$IPTABLES -F http-new-in2
$IPTABLES -F http-new-in3
$IPTABLES -F http-new-in4
# Delete user defined chains
$IPTABLES -X
# Reset all IPTABLES counters
$IPTABLES -Z
# Smythies: While my references do not have it, I think this is needed.
$IPTABLES -t nat -Z

#######################################################################
# USER DEFINED CHAIN SUBROUTINES:
#
# log-n-drop
# I only use this when I am having troubles and want more details.
# Normally, I just DROP packets at the earliest determination of that
# ultimate course of action.
$IPTABLES -N log-n-drop
$IPTABLES -A log-n-drop -j LOG --log-prefix "GENERIC:" --log-level info
$IPTABLES -A log-n-drop -j DROP

#######################################################################
# USER DEFINED CHAIN SUBROUTINES:
#
# http-new-in4
#
# A NEW Connection on port 80 part 4.
#
# multiple hits on the banned list means you get a one day ban.
# (I re-load the firewall rule set often, so going longer makes
# little sense.)
#
# Custom tables must exist before being referenced, hence the order
# of these sub-toutines.
#
# Place holder routine, but tested. Logs if a day ban would have
# been activated.
#
$IPTABLES -N http-new-in4
#$IPTABLES -A http-new-in4 -m recent --set --name HTTP_BAN_DAY

$IPTABLES -A http-new-in4 -j LOG --log-prefix "DAY80:" --log-level info
$IPTABLES -A http-new-in4 -j DROP

#######################################################################
# USER DEFINED CHAIN SUBROUTINES:
#
# http-new-in3
#
# A NEW Connection on port 80 part 3.
#
# carry forward to the actual banned list:
# Increment this count. Leave the previous count.
#
# Custom tables must exist before being referenced, hence the order
# of these sub-toutines.
#
$IPTABLES -N http-new-in3
$IPTABLES -A http-new-in3 -m recent --remove --name HTTP_02
$IPTABLES -A http-new-in3 -m recent --update --hitcount 1 --seconds 86400 --name HTTP_BAN -j http-new-in4
$IPTABLES -A http-new-in3 -m recent --set --name HTTP_BAN

$IPTABLES -A http-new-in3 -j LOG --log-prefix "BAN80:" --log-level info
$IPTABLES -A http-new-in3 -j DROP

#######################################################################
# USER DEFINED CHAIN SUBROUTINES:
#
# http-new-in2
#
# A NEW Connection on port 80 part 2.
#
# carry forward from previous max new connections per unit time:
# Increment this count and clear the lesser significant count.
#
$IPTABLES -N http-new-in2
$IPTABLES -A http-new-in2 -m recent --remove --name HTTP_01
$IPTABLES -A http-new-in2 -m recent --update --hitcount 3 --seconds 720 --name HTTP_02 -j http-new-in3
$IPTABLES -A http-new-in2 -m recent --set --name HTTP_02

$IPTABLES -A http-new-in2 -j LOG --log-prefix "CARRY80:" --log-level info
$IPTABLES -A http-new-in2 -j ACCEPT

#######################################################################
# USER DEFINED CHAIN SUBROUTINES:
#
# http-new-in
#
# A NEW Connection on port 80:
#
$IPTABLES -N http-new-in

echo Allowing EXTERNAL access to the WWW server

# . check the static blacklist.
#
# http related
$IPTABLES -A http-new-in -i $EXTIF -s 5.248.83.0/24 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 12.94.27.194 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 37.115.189.101 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 37.115.0.0/16 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 37.139.52.23 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 42.147.128.0/17 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 46.118.0.0/15 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 46.118.117.249 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 46.118.118.106 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 46.118.119.252 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 46.119.114.21 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 46.119.118.178 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 46.119.122.97 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 46.119.124.40 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 46.147.128.0/17 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 46.147.187.16 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 62.210.124.7 -j DROP
# V1.01 Never comment out 62.219.8.230, as it is the IP in Israel that copies the entire site.
$IPTABLES -A http-new-in -i $EXTIF -s 62.219.8.230 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 82.193.99.33 -j DROP
# Re: 85.17.75.221 See Incident Report for 2014.03.26.
$IPTABLES -A http-new-in -i $EXTIF -s 85.17.75.221 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 86.51.26.0/24 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 89.108.102.171 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 89.111.176.0/23 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 91.207.4.186 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 91.207.4.206 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 91.207.6.34 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 91.207.9.226 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 91.223.75.116/30 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 92.249.127.111 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 93.170.1.53 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 94.153.0.0/16 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 94.153.64.0/18 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 94.153.64.49 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 94.153.64.140 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 94.153.65.87 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 94.153.65.117 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 94.181.91.142 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 95.168.172.156 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 109.120.157.179 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 134.249.0.0/16 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 150.70.0.0/16 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 159.224.99.210 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 176.8.88.90 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 176.8.88.134 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 176.8.91.143 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 176.102.219.6 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 176.123.0.57 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 178.137.0.0/16 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 178.137.5.8 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 178.137.5.24 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 178.137.5.249 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 178.137.5.142 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 178.137.18.206 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 178.137.19.179 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 178.137.128.0/23 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 192.95.54.38 -j DROP
# V1.01 Never comment out 192.114.71.13. as it is the IP in Israel that copies the entire site.
$IPTABLES -A http-new-in -i $EXTIF -s 192.114.71.13 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 192.162.19.177 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 192.162.19.183 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 193.0.212.119 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 193.106.136.0/24 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 193.150.120.14 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 195.43.128.119 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 195.214.79.22 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 195.242.218.133 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 202.53.8.82 -j DROP
#$IPTABLES -A http-new-in -i $EXTIF -s 213.110.133.221 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 216.244.87.170 -j DROP

# http - 360Spider related
$IPTABLES -A http-new-in -i $EXTIF -s 101.226.160.0/20 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 182.118.16.0/20 -j DROP

# http - EasouSpider related
$IPTABLES -A http-new-in -i $EXTIF -s 183.60.213.28 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 183.60.214.118 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 183.60.215.28 -j DROP

# http - Sosospider related (maybe forged)
#$IPTABLES -A INPUT -i $EXTIF -s 123.151.148.164 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 62.219.8.234 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 82.80.0.0/16 -j DROP

# http - ++++++++++++Result:+no+post+sending+forms+are+found related
# I don't really know what it is about, nor do I care. I just ban them.
# This includes the entire unit-is.com ip range (darned Ukrane again).
#
$IPTABLES -A http-new-in -i $EXTIF -s 37.59.30.39 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 63.141.248.28 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 178.32.56.65 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 192.151.152.203 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 195.211.152.0/22 -j DROP
$IPTABLES -A http-new-in -i $EXTIF -s 198.27.126.38 -j DROP

# . check the dynamic banned list
#
# The 1 Day banned list:
# (Tested, but commented out. There is a placeholder routine)
#
#$IPTABLES -A http-new-in -m recent --update --seconds 86400 --name HTTP_BAN_DAY --rsource -j LOG --log-prefix "DAY80:" --log-level info
#$IPTABLES -A http-new-in -m recent --update --seconds 86400 --name HTTP_BAN_DAY --rsource -j DROP
# The 1 Hour banned list (bumped to 90 minutes):
$IPTABLES -A http-new-in -m recent --update --seconds 5400 --name HTTP_BAN --rsource -j LOG --log-prefix "LIM80:" --log-level info
$IPTABLES -A http-new-in -m recent --update --seconds 5400 --name HTTP_BAN --rsource -j DROP

# A generic log entry. Usually only during degugging
#
#$IPTABLES -A http-new-in -j LOG --log-prefix "NEW80ALL:" --log-level info

# Ver 1.09 Try rate limting again, the Dynamic Badguy method doesn't work because the hitcount maximum is 20.
# A hit count of 300 should allow a well behaved bot to not get falsely locked out, but watch for it.
# (307 is a prime number)(over what time period does burst apply?)
#$IPTABLES -A http-new-in -i $EXTIF -m state --state NEW -p tcp -m limit --limit 307/hour --limit-burst 200 -s $UNIVERSE -d $EXTIP --dport 80 -j ACCEPT
# a log comment to show a rate limited packet, and make it easier to extract. Otherwise it will hit the catch all anyhow.
#$IPTABLES -A http-new-in -i $EXTIF -m state --state NEW -p tcp -s $UNIVERSE -d $EXTIP --dport 80 -j LOG --log-prefix "LIM80:" --log-level info
#$IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p tcp -s $UNIVERSE -d $EXTIP --dport 80 -j ACCEPT

# Dynamic Badguy List. Least significant hit counter.  Detect and DROP Bad IPs that do excessive connections to port 80.
#
$IPTABLES -A http-new-in -m recent --update --hitcount 20 --seconds 240 --name HTTP_01 -j http-new-in2
$IPTABLES -A http-new-in -m recent --set --name HTTP_01

$IPTABLES -A http-new-in -j LOG --log-prefix "NEW80:" --log-level info
$IPTABLES -A http-new-in -j ACCEPT

#######################################################################
# INPUT: Incoming traffic from various interfaces.  All rulesets are
#        already flushed and set to a default policy of DROP.
#

# loopback interfaces are valid.
#
$IPTABLES -A INPUT -i lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT

# A very site specific rule: Will 192.168.111.57 please shutup.
# It is not clear to me why, but after many many months, it did shutup.
#
#$IPTABLES -A INPUT -i $INTIF -s 192.168.111.57 -j DROP

# Site Specific: DROP the packets from the speedtouch ADSL modem.
# This will prevent the further below generic 10.0.0.0/8 rule from logging stuff that is already known.
# (commented out in Ver: 0.31 as it doesn't detect anything)
# V1.00 Why doesn't it detect anything? Try again.
# V1.02 The desintation MAC is not this server. This rule will never trigger.
# the tcpdump filter is still needed becuase the packet is present.
#$IPTABLES -A INPUT -i $EXTIF -s 10.0.0.138 -d $UNIVERSE -j DROP

# Site Specific: ISP (Telus) annoying stuff
# This will prevent the further below generic 10.0.0.0/8 rule from logging stuff that is already known.
# V1.08: Change to generic 224.0.0.1 destination DROP for both internel and external source.
#$IPTABLES -A INPUT -i $EXTIF -s 10.197.248.13 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -d 224.0.0.1 -j DROP

# e-mail related
#$IPTABLES -A INPUT -i $EXTIF -s 66.64.41.226 -j DROP

# port 33434 related
#$IPTABLES -A INPUT -i $EXTIF -s 199.241.142.0/24 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 178.17.160.216/29 -j DROP

# ICMP related
# Note: (Rev 1.06) see more generic drop rule below
#$IPTABLES -A INPUT -i $EXTIF -s 12.129.199.100 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 12.129.199.108 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 12.129.199.110 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 12.130.81.230 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 12.130.81.231 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 12.130.81.247 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 64.74.254.20 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 64.94.88.20 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 74.217.78.143 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 74.217.78.144 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 171.20.34.7 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 198.98.99.0/24 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 208.78.169.234 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 208.78.169.235 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 208.78.169.236 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 204.11.51.59 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 204.11.51.61 -j DROP
#$IPTABLES -A INPUT -i $EXTIF -s 216.52.92.10 -j DROP

#************************* debug experimenting only *******************************
# test all TCP packets. (be careful of log file sizes)
#$IPTABLES -A INPUT -i $INTIF -p tcp ! --syn -j LOG --log-prefix "ZZN:"
#$IPTABLES -A INPUT  -m limit --limit 1/s --limit-burst 7   -j LOG --log-prefix "[IPTABLES INPUT "
#$IPTABLES -A INPUT -i $INTIF -p tcp ! --syn -j LOG --log-prefix "ZZN:" --log-level info
#$IPTABLES -A INPUT -i $INTIF -p tcp --syn -j LOG --log-prefix "ZZS:" --log-level info
#$IPTABLES -A INPUT -p tcp ! --syn -j LOG --log-prefix "ZZN:" --log-level info
#$IPTABLES -A INPUT -p tcp --syn -j LOG --log-prefix "ZZS:" --log-level info

# Ver: 0.28: This rule is for debugging and education. See more detailed comments for the similar rule in the FORWARD chain.
# The experiment is to double check results from Ver 0.22 that this condition is not detected in the INPUT chain.
# Ver: 0.30 Comment out the DROP line. Is there ever a case where this rule triggers but the FORWARD chain one does not?
$IPTABLES -A INPUT -i $INTIF -p tcp -m state --state INVALID -j LOG --log-prefix "IINVALID:" --log-level info
#$IPTABLES -A INPUT -i $INTIF -p tcp -m state --state INVALID -j DROP

# A NEW TCP connection requires SYN bit set and FIN,RST,ACK reset.
# Un-NAT'ed packets can go out to internet without this rule.
# Sending RFC1918 packets to internet is considered poor form, by me anyhow.
# V1.02: Many packets here are due to forgotten connections. Try REJECT instead of DROP.
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "NEW TCP no SYN:" --log-level info
#$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j REJECT

# At this point local interface, local machines, going anywhere is valid
#
$IPTABLES -A INPUT -i $INTIF -s $INTNET -d $UNIVERSE -j ACCEPT

# remote interface, RFC 1918, private internet packets, and some others.
#
$IPTABLES -A INPUT -i $EXTIF -s 192.168.0.0/16 -d $UNIVERSE -j LOG --log-prefix "Sub192:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 192.168.0.0/16 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 10.0.0.0/8 -d $UNIVERSE -j LOG --log-prefix "Sub10:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 10.0.0.0/8 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 172.16.0.0/12 -d $UNIVERSE -j LOG --log-prefix "Sub172:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 172.16.0.0/12 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 240.0.0.0/5 -d $UNIVERSE -j LOG --log-prefix "Sub240:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 240.0.0.0/5 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 224.0.0.0/4 -d $UNIVERSE -j LOG --log-prefix "Sub224:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 224.0.0.0/4 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 169.254.0.0/16 -d $UNIVERSE -j LOG --log-prefix "Sub169:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -s 169.254.0.0/16 -d $UNIVERSE -j DROP

# Allow any related traffic coming back to the server in.
#
#  STATEFULLY TRACKED
#
$IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state ESTABLISHED,RELATED -j ACCEPT

# direct drops. I do not like you.
#
# Attack of 2011.02 always had same TCP window size (TOS offset = 6 (TCP=6), Window size offset = 32)
#
#$IPTABLES -A INPUT -i $EXTIF -m u32 --u32 "6&0xFF=0x6 && 32&0xFFFF=0xF0FA" -j LOG --log-prefix "BADZ:" --log-level info
#$IPTABLES -A INPUT -i $EXTIF -m u32 --u32 "6&0xFF=0x6 && 32&0xFFFF=0xF0FA" -j DROP

# Odd batches of ICMP echo requests. When occuring, 52 or 53 packets every 5 minutes.
# "6 & 0xFF = 1 ... the first part is protocol check, where 1 is ICMP.
# ... 0 >> 22 & 0x3C @ 0 >> 24 = 8 ... the second part, directly from the man pages, is the complicated type 8 (Echo Request) check.
# ... 0 & 0XFFFF = 0x60" the third part is the total length check 96 bytes (76 bytes ICMP payload)
# ... 0 & 0XFFFF = 0x1C" also the third part is the total length check 28 bytes (8 bytes ICMP payload)
#
#$IPTABLES -A INPUT -i $EXTIF -m u32 --u32 "6 & 0xFF = 1 && 0 >> 22 & 0x3C @ 0 >> 24 = 8 && 0 & 0XFFFF = 0x60" -j LOG --log-prefix "BAD76:" --log-level info
#$IPTABLES -A INPUT -i $EXTIF -m u32 --u32 "6 & 0xFF = 1 && 0 >> 22 & 0x3C @ 0 >> 24 = 8 && 0 & 0XFFFF = 0x60" -j DROP
#$IPTABLES -A INPUT -i $EXTIF -m u32 --u32 "6 & 0xFF = 1 && 0 >> 22 & 0x3C @ 0 >> 24 = 8 && 0 & 0XFFFF = 0x1C" -j LOG --log-prefix "BAD8:" --log-level info
#$IPTABLES -A INPUT -i $EXTIF -m u32 --u32 "6 & 0xFF = 1 && 0 >> 22 & 0x3C @ 0 >> 24 = 8 && 0 & 0XFFFF = 0x1C" -j DROP
#
# Generic ICMP echo request DROP if the packet total length is not >= 128 bytes (rev 1.13 256 bytes)
# ... 0 & 0XFF80 = 0" in this case the third part, the total length check mask gives < any 128 bytes will be TRUE for test condition.
#
#$IPTABLES -A INPUT -i $EXTIF -m u32 --u32 "6 & 0xFF = 1 && 0 >> 22 & 0x3C @ 0 >> 24 = 8 && 0 & 0XFF80 = 0" -j DROP
$IPTABLES -A INPUT -i $EXTIF -m u32 --u32 "6 & 0xFF = 1 && 0 >> 22 & 0x3C @ 0 >> 24 = 8 && 0 & 0XFF00 = 0" -j DROP
# external interface, from any source, for any remaining ICMP traffic is valid
$IPTABLES -A INPUT -i $EXTIF -p ICMP -s $UNIVERSE -d $EXTIP -j ACCEPT

#
# After a coordinated attack involving several sub-nets from China, they are no banned forever.
#
$IPTABLES -A INPUT -i $EXTIF -s 61.174.51.0/24 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 116.10.191.0/24 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 122.225.103.0/24 -d $UNIVERSE -j DROP
$IPTABLES -A INPUT -i $EXTIF -s 122.225.109.0/24 -d $UNIVERSE -j DROP

# ----- Begin OPTIONAL INPUT Section -----
#
# DHCPd - Enable the following lines if you run an INTERNAL DHCPd server
#
# Smythies: Is not only the udp line required? There will never be tcp for this.
#$IPTABLES -A INPUT -i $INTIF -p tcp --sport 68 --dport 67 -j ACCEPT
$IPTABLES -A INPUT -i $INTIF -p udp --sport 68 --dport 67 -j ACCEPT

# Secure Shell on port 22.
#
# Dynamic Badguy List. Detect and DROP Bad IPs that do password attacks on SSH.
# Once they are on the BADGUY list then DROP all packets from them.
#$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 5400 --name BADGUY_SSH -j LOG --log-prefix "SSH BAD:" --log-level info
#$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 5400 --name BADGUY_SSH -j DROP
# Sometimes make the lock time very long. Typically to try to get rid of coordinated attacks from China.
$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j LOG --log-prefix "SSH BAD:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j DROP
$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 22 -m recent --set --name BADGUY_SSH -j ACCEPT

# Ver 0.39: Current SYN flood attack uses illegal ports. Filter based on port 0 to get rid of them.
# Ver 0.40: Comment out. Event has ended.
#
#$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 2 --seconds 5400 --name BADGUY_SYN -j LOG --log-prefix "SYN BAD:" --log-level info
#$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 2 --seconds 5400 --name BADGUY_SYN -j DROP
#$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --sport 0 --dport 80 -m recent --set --name BADGUY_SYN -j DROP

# If required, go to NEW HTTP connection sub-routine
#
$IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p tcp -s $UNIVERSE -d $EXTIP --dport 80 -j http-new-in

# E-mail on port 25. Enable the following lines if you run an EXTERNAL e-mail server.
#
echo Allowing EXTERNAL access to e-mail
# Sometimes I uncomment the next line for awhile, when under some e-mail attack.
#$IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p tcp -s $UNIVERSE -d $EXTIP --dport 25 -j DROP
$IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p tcp -m limit --limit 5/minute --limit-burst 3 -s $UNIVERSE -d $EXTIP --dport 25 -j ACCEPT

# Just for my own interest, specifically identify if source MAC address is the ISP gateway (173.180.45.1 in my current case)
# A lot of traffic comes to this rule due to the half-duplex TCP close sequence. Be polite and REJECT instead of DROP.
#$IPTABLES -A INPUT -i $EXTIF -p tcp -m mac --mac-source 6C:BE:E9:A7:F1:07 -j LOG --log-prefix "GW MAC:" --log-level info
#$IPTABLES -A INPUT -i $EXTIF -p tcp -m mac --mac-source 6C:BE:E9:A7:F1:07 -j REJECT --reject-with tcp-reset

# Again, just for my own interest, specifically identify if source MAC address is my other IP address MAC (173.180.45.3 in my current case)
#
#$IPTABLES -A INPUT -i $EXTIF -m mac --mac-source 00:14:BF:BC:25:EE -j LOG --log-prefix "BEFSR81:" --log-level info
#$IPTABLES -A INPUT -i $EXTIF -m mac --mac-source 00:14:BF:BC:25:EE -j DROP

# V1.00 No longer use the specific MAC stuff, as the BEFSR81 was long since fixed.
# See also: http://www.smythies.com/~doug/network/mac_adr/index.html
# At this point traffic to ports 80 or 443 is likely due to the half-duplex TCP close sequence. Be polite and REJECT instead of DROP.
# REJECT requires a corresponding rule in the OUTPUT chain to allow the packet to get thru.

$IPTABLES -A INPUT -i $EXTIF -p tcp -m multiport --sport 80,443 -j LOG --log-prefix "BAD80:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -p tcp -m multiport --sport 80,443 -j REJECT

# Catch all rule, all other incoming is denied.
# (Leave the log-n-drop jump here so that in future I can remember how to do it.)
#
$IPTABLES -A INPUT -s $UNIVERSE -d $UNIVERSE -j log-n-drop
# ----- End OPTIONAL INPUT Section -----
#
echo Loading OUTPUT rulesets...

#######################################################################
# OUTPUT: Outgoing traffic from various interfaces.  All rulesets are
#         already flushed and set to a default policy of DROP.
#

# Sanity check 1: RFC 1918 check: (Ver: 0.17: Does not work, but
# only commented out, for now)
#
# Smythies: Why doesn't this work?
#$IPTABLES -A OUTPUT -o $EXTIF -s BLACKHOLE -d $UNIVERSE -j DROP
#
#$IPTABLES -A OUTPUT -o $EXTIF -s 192.168.0.0/16 -d $UNIVERSE -j log-n-drop
#$IPTABLES -A OUTPUT -o $EXTIF -s 10.0.0.0/8 -d $UNIVERSE -j log-n-drop
#$IPTABLES -A OUTPUT -o $EXTIF -s 172.16.0.0/12 -d $UNIVERSE -j log-n-drop
#$IPTABLES -A OUTPUT -o $EXTIF -s 224.0.0.0/4 -d $UNIVERSE -j log-n-drop
#$IPTABLES -A OUTPUT -o $EXTIF -s 240.0.0.0/5 -d $UNIVERSE -j log-n-drop
#$IPTABLES -A OUTPUT -o $EXTIF -s 169.254.0.0/16 -d $UNIVERSE -j log-n-drop

# Workaround bug in netfilter
# See http://www.netfilter.org/security/2002-04-02-icmp-dnat.html
# Smythies: That hyper-link does not work.
# Smythies: As far as I can determine the issue here is both old and only
# applied to DNAT, which I am not using.
# Ver: 0.32: change to log only, but do not drop the packet.
# Ver: 0.33: change back to log and drop.
# Ver: 1.02: Remove. icmp INVALID applies to REJECT response when there
# is no related connection to associate with. Typically the connection
# has already been forgotten.
#
#$IPTABLES -A OUTPUT -m state -p icmp --state INVALID -j LOG --log-prefix "OICMP:" --log-level info
#$IPTABLES -A OUTPUT -m state -p icmp --state INVALID -j DROP

# loopback interface is valid.
#
$IPTABLES -A OUTPUT -o lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT

# local interfaces, any source going to local net is valid
#
$IPTABLES -A OUTPUT -o $INTIF -s $EXTIP -d $INTNET -j ACCEPT

# local interface, server source going to the local net is valid
#
# Note that this is a restrictive rule. It would probably be O.K.
# to leave out the source IP check, because any other source IP address
# from the outside world would not take the OUTPUT path but rather the
# FORWARD path. This rule creates trouble for some REJECT packets being
# returned to an internal sender. Rather than relax this rule, at least for
# now, special and specific rules for REJECT packets are further below.
#
$IPTABLES -A OUTPUT -o $INTIF -s $INTIP -d $INTNET -j ACCEPT

# outgoing to local net on remote interface, stuffed routing, deny
# Ver: 0.34: Commented out, this same condition is now a subset of RFC1918 checks above
#
#$IPTABLES -A OUTPUT -o $EXTIF -s $UNIVERSE -d $INTNET -j LOG --log-prefix "OSTUFF:" --log-level info
#$IPTABLES -A OUTPUT -o $EXTIF -s $UNIVERSE -d $INTNET -j DROP

# anything else outgoing on remote interface is valid
#
$IPTABLES -A OUTPUT -o $EXTIF -s $EXTIP -d $UNIVERSE -j ACCEPT

# ----- Begin OPTIONAL OUTPUT Section -----
#

# Special allowance for REJECT packets. Be careful not to create a security hole.
# This probably could have been done above, with one less restrictive rule, because
# it isn't possible for a packet to traverse the OUTPUT chain if it didn't originate
# in the server itself. However, specifically allowing helps keep track of things.
# Sometimes logging is used. There should be a 1 to 1 correlation with REJECT source.
# Ver 1.02: This was for -reject-with tcp-reset, which didn't work anyhow.
#$IPTABLES -A OUTPUT -o $INTIF -p tcp -d $INTNET -m multiport --sport 80,443 -j LOG --log-prefix "OSPECIAL:" --log-level info
#$IPTABLES -A OUTPUT -o $INTIF -p tcp -d $INTNET -m multiport --sport 80,443 -j ACCEPT

# Catch all rule, all other outgoing is denied.
$IPTABLES -A OUTPUT -s $UNIVERSE -d $UNIVERSE -j LOG --log-prefix "OCATCH:" --log-level info
$IPTABLES -A OUTPUT -s $UNIVERSE -d $UNIVERSE -j DROP

# ----- End OPTIONAL OUTPUT Section -----
#

echo Loading FORWARD rulesets...

# an experiment. Left here to remind me how to do it.
#
#$IPTABLES -A FORWARD -i $INTIF -s 192.168.111.100 -p tcp -d 69.171.229.16 -j DROP
#$IPTABLES -A FORWARD -i $INTIF -s 192.168.111.100 -p tcp -m iprange --dst-range 66.220.144.0-66.220.159.255 -j DROP
#$IPTABLES -A FORWARD -i $INTIF -s 192.168.111.100 -p tcp -m iprange --dst-range 69.63.176.0-69.63.191.255 -j DROP
#$IPTABLES -A FORWARD -i $INTIF -s 192.168.111.100 -p tcp -m iprange --dst-range 69.171.224.0-69.171.255.255 -j DROP
#$IPTABLES -A FORWARD -i $INTIF -s 192.168.111.100 -p tcp -m iprange --dst-range 204.15.20.0-204.15.23.255 -j DROP

# See V 1.03 history notes. Block stupid port 137 stuff to WAN.
#
$IPTABLES -A FORWARD -o $EXTIF -p UDP --dport 137 -j DROP

# destination check for RFC1918 and some others. (added in Ver: 0.34, moved here in 0.35)
#
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 192.168.0.0/16 -j LOG --log-prefix "F192:" --log-level info
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 192.168.0.0/16 -j DROP
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 10.0.0.0/8 -j LOG --log-prefix "F10:" --log-level info
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 10.0.0.0/8 -j DROP
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 172.16.0.0/12 -j LOG --log-prefix "F172:" --log-level info
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 172.16.0.0/12 -j DROP
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 224.0.0.0/4 -j LOG --log-prefix "F224:" --log-level info
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 224.0.0.0/4 -j DROP
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 240.0.0.0/5 -j LOG --log-prefix "F240:" --log-level info
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 240.0.0.0/5 -j DROP
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 169.254.0.0/16 -j LOG --log-prefix "F169:" --log-level info
$IPTABLES -A FORWARD -o $EXTIF -s $UNIVERSE -d 169.254.0.0/16 -j DROP

#######################################################################
# FORWARD: Enable Forwarding and thus IPMASQ
#
# ----- Begin OPTIONAL FORWARD Section -----

# There seem to be many abuses of TCP session termination handshaking that results in
# packet leakage to the internet with untranslated IP addresses. The problem occurs from
# the MACbook, the IPod Touch, the PS3, the Windows 7, vista, and XP machines.
# This rule is an attempt to elimiate the issue.
# Should this go in the INPUT chain or the FORWARD chain? Does not work in INPUT chain.
# Does not Works: (Ver: 0.22)
#$IPTABLES -A INPUT -i $INTIF -p tcp -m state --state INVALID -j log-n-reject
# Works: (Ver:023) Moved to forward chain. But the REJECT gets DROPped in the OUTPUT section
# For version 0.24 this is commented out and ip_conntrack_tcp_loose=0 is used instead.
# For version 0.25 this rule is used again, as ip_conntrack_tcp_loose=0 does not prevent
# packet leakage.
# V1.07 delete the tcp protocol specifier. DROP any INVALID for any protocol
$IPTABLES -A FORWARD -i $INTIF -m state --state INVALID -j LOG --log-prefix "FINVALID:" --log-level info
#$IPTABLES -A FORWARD -i $INTIF -p tcp -m state --state INVALID -j LOG --log-prefix "FINVALID:" --log-level info
#$IPTABLES -A FORWARD -i $INTIF -p tcp -m state --state INVALID -j DROP
#$IPTABLES -A FORWARD -i $INTIF -p tcp -m state --state INVALID -j REJECT --reject-with tcp-reset
$IPTABLES -A FORWARD -i $INTIF -m state --state INVALID -j REJECT

#
# ----- End OPTIONAL FORWARD Section -----

echo "FWD: Allow all connections OUT and only existing/related IN..."
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
#$IPTABLES -A FORWARD -i $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
#
# port forward stuff. see also the prerouting area.
#$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 80 -d 192.168.111.112 -m state --state NEW -j LOG --log-prefix "PFNEW80:" --log-level info
#$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 80 -d 192.168.111.112 -m state --state NEW -j ACCEPT
#$IPTABLES -A FORWARD -i $INTIF -o $INTIF -p tcp --dport 80 -d 192.168.111.112 -m state --state NEW -j LOG --log-prefix "PFINT80:" --log-level info
#$IPTABLES -A FORWARD -i $INTIF -o $INTIF -p tcp --dport 80 -d 192.168.111.112 -m state --state NEW -j MARK --set-xmark 0x4
#$IPTABLES -A FORWARD -i $INTIF -o $INTIF -p tcp --dport 80 -d 192.168.111.112 -m state --state NEW -j ACCEPT
#$IPTABLES -A FORWARD -p icmp -s 173.180.45.3 -d 192.168.111.112 -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT

# Catch all rule, all other forwarding is denied and logged.
#
$IPTABLES -A FORWARD -j LOG --log-prefix "FCATCH:" --log-level info
$IPTABLES -A FORWARD -j DROP

#echo "NAT: Enabling DNAT port 3074 forwarding..."
# Ver 0.37 For PS3. UDP port 3074. Source port can be NAT'd and not 3074.
# Ver 0.38 Commented out.
#
#$IPTABLES -t nat -A PREROUTING -p udp -i $EXTIF --dport 3074 -j DNAT --to 192.168.111.109:3074
#
# some port forward stuff. (normally commented out) see also FORWARD area.
#$IPTABLES -t nat -A PREROUTING -p tcp -i $EXTIF --dport 80 -j DNAT --to 192.168.111.112:80
#$IPTABLES -t nat -A PREROUTING -p tcp -i $EXTIF --dport 8083 -j DNAT --to 192.168.111.112:80
#$IPTABLES -t nat -A PREROUTING -p tcp -i $INTIF --dport 8083 -d $EXTIP -j DNAT --to 192.168.111.112:80
#$IPTABLES -t nat -A PREROUTING -p icmp -s 173.180.45.3 -d 173.180.45.4 -j DNAT --to 192.168.111.112

echo "NAT: Enabling SNAT (MASQUERADE) functionality on $EXTIF..."
#
#More liberal form (Ver: 0.17: Try this method instead. Does it solve the problem? No.)
#$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
#
#Stricter form (Used before (and after) Ver: 0.17, but RFC1918 packets are being sent out)
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP
#$IPTABLES -t nat -A POSTROUTING -m mark --mark 0x4 -j SNAT --to $EXTIP
# $IPTABLES -t nat -A POSTROUTING -i $INTIF --sport 80 -s 192.168.111.112 -j ACCEPT
#
# following is for debug only. Normally commented out.
#$IPTABLES -t nat -A POSTROUTING -j LOG --log-prefix "NAT_POST" --log-level info

#######################################################################

# Ver 1.04 These commands must be after kernel modeules loaded.
# By default, this is turned on.
# I have not figured out where is gets turned on. It is not in
# sysctl.conf
# see "sysctl -w net.ipv4.ip_conntrack_loose=0"
# The above command does not make the setting persistant.
# It doesn't help with packet leakage anyhow.
#echo Disable loose TCP in conntrack
#echo 0 >/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose

# TCP CLOSE_WAIT time. Default is 60 seconds.
# The number of wasted packets and TCP INVALID hits is
# greatly reduced by using a longer CLOSE_WAIT time.
# I have been experimenting with 3600 seconds.
# (Evidently it used to be 3 days)
# sudo sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait=3600
# or
echo 3600 >/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait

echo doug_firewall $FWVER done.