# Red Hat Linux firewall using iptables
#
# Created: October 2002
# Last Revised: August 2006
#
# Authors: Dennis G. Allard (allard@oceanpark.com) and Don Cohen (don@isis.cs3-inc.com)
#
# This script works on on servers running Red Hat 7.3, 8.0, 9.0, and
# RHEL ES 3 and 4.  Variants of this script are in active use on
# many servers.
#
# No warranty is implied.  Use at your own risk!!

# Using this script
# -----------------
#
# I save this file as /etc/sysconfig/iptables-precursor
# and then source it and run iptables-save to create
# /etc/sysconfig/iptables, which is an input file
# consumed by the script /etc/rc.d/init.d/iptables,
# which in turn makes use of the script /sbin/iptables-restore.
#
# Before mucking with setting up iptables, you should
# disconnect the machine from the internet.  Examine
# and understand the current set of iptables rules
# before you reconnect to the internet.
#
# To configure the set of iptables rules:
#
#   /etc/rc.d/init.d/iptables stop
#   source /etc/sysconfig/iptables-precursor
#
# To save the current set of iptables rules for use at next reboot:
#   
#   iptables-save > /etc/sysconfig/iptables
#   
# To dynamically restart iptables after modifying /etc/sysconfig/iptables:
#
#   /etc/rc.d/init.d/iptables restart
#
# Note that /etc/rc.d/init.d/iptables is a script.  You can read it to
# gain understanding of how iptables uses iptables-restore to restore
# iptables firewall rules at reboot.
#
# To examine the current set of rules in effect:
#
#   /etc/rc.d/init.d/iptables status
#
# However, I prefer to show the current set of rules via:
#
#   iptables -nvL -t filter   
#   iptables -nvL -t nat
#
# or 
#
#   iptables -vL -t filter   
#   iptables -vL -t nat
#
#
# To configure iptables to be used at next system reboot:
#   
#   chkconfig --add iptables
#
# To see if iptables is currently configured to start at boot, do:
#   
#   chkconfig --list iptables
#
# (You might have to do chkconfig --del ipchains to remove ipchains)
#
# The rest of this file is derived from my old ipchains script.
#

# A word about routing
# --------------------
# 
# Note that this web page does not discuss routing decisions.  Routing
# (see the 'ifconfig' and 'route' commands) decides which interface an
# incoming packet will be delivered to, i.e. if a given packet will be
# 'input' to this machine or be 'forwarded' to some interface for
# delivery to another machine, say on an internal network.  You should
# have your routing configured before you attempt to configure your
# firewall.
#
# Caveat.  DNAT and SNAT provide a way for the IPTABLES firewall to modify the
# Destination or Source IP addresses of a packet and, in this way, interact
# with routing decisions.  See section below: 'More about NAT and routing'.
# 

# The network
# -----------
#
# This firewall is running on a gateway machine having multiple ethernet
# interfaces, a public one, eth0, which is a DSL connection to an ISP,
# and one or more internal ones, including eth1, which is assigned to
# 192.168.0.1, an IP number on my internal private network.  My public
# network has static IP numbers depicted below as x.y.z....  Actual
# IP numbers would, of course, be a sequence of four octets.  For this
# script, I assume that the firewall is running on the same machine
# having the interfaces configued with my public IPs.  For this reason,
# most of the rules below are INPUT rules.  Were I to route some of my public
# static IP numbers to interfaces on one or more machines inside the
# firewall on the internal network, I would modify certain rules to be
# FORWARD rules instead of INPUT rules.  I show some examples below of
# FORWARD rules.  Finally, the script is just for a single server IP,
# hence all of the "/32" network masks below.  A more realistic situation
# would involve using IP ranges and their corresponding network masks.
#
# The gateway at my ISP is x.y.z.1.  I run a few web servers on
# x.y.z.w, a DNS server on x.y.z.n, and qmail on x.y.z.m.
#
# Using this file in a more complex network would require some
# modifications. Particular attention would need to be given to using
# the right the IP numbers and interfaces, among other things. :-)
# 

# Preliminaries
# -------------
#
# To permit machines internal to the network to be able to
# send IP packets to the outside world, enable IP Forwarding:
#
#   echo 1 > /proc/sys/net/ipv4/ip_forward
#
# Prevent SYN floods from consuming memory resources:
#
#   echo 1 > /proc/sys/net/ipv4/tcp_syncookies
#
# I place the above echo commands into /etc/rc.d/rc.local
# so that they will be executed at boot time.
# 


# The basic idea of this firewall
# -------------------------------
#
# Provide rules that are applied in the following order:
#
# ACCEPT all UDP packets for certain UDP services
#
# Currently the only UDP connections I accept are to my secure DNS
# server, tinydns.
#
# DROP all other UDP packets.
#
# ACCEPT SYN packets just for certain TCP services
#
# SYN packets are specified via the -syn flag in the input
# rules defined below.  Note that certain services can be
# further filtered by xinetd.
#
# DROP all other TCP SYN packets.
#
# ACCEPT all other TCP packets that are part of existing connections
#
# DROP all other TCP packets.
#
# In other words, we allow any TCP packet through that is part of an
# established TCP connection, but we are very selective in just which
# connections we permit to be made to start off with.
#
# A brief explanation of SYN packets goes as follows.  TCP connections
# are initiated via a hand shaking protocol between the client and server
# programs at either end of the connection.  The very first TCP packet
# is sent by the client to the server and is called a SYN packet,
# because it has the SYN flag set to 1 in the TCP packet header.  We
# only allow SYN packets for the specific servers running on specific
# ports of specific hosts.  Subsequently, we only permit further TCP
# packets in that are determined to be part of a connection whose
# initial SYN packet was already accepted and responded to by one of our
# servers.  This is done via 'Stateful Packet Inspection' provided by the
# netfilter functionality added to linux as of kernel 2.4.  By stopping all
# other packets in their tracks, we limit attempts to attack our internal
# network.
# 
# There are subtle ways that Denial of Service attacks can be performed
# if an attacker is able to somehow gain access to a machine inside our
# network or otherwise hijack a connection.  However, even in such
# cases, current research is leading to ways to greatly limit the effect
# of such attacks.
#
# For detailed background reading about iptables, please refer to:
# https://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html
#


# begin oceanpark.com firewall rules (using iptables)
# ---------------------------------------------------

# Here we go...

#
# Configure default policies (-P), meaning default rule to apply if no
# more specific rule below is applicable.  These rules apply if a more specific rule below
# is not applicable.  Defaults are to DROP anything sent to firewall or internal
# network, permit anything going out.
#
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

#
# Flush (-F) all specific rules
#
iptables -F INPUT 
iptables -F FORWARD 
iptables -F OUTPUT 
iptables -F -t nat


# The rest of this file contains specific rules that are applied in the order
# listed.  If none applies, then the above policy rules are used.

#
# Forward all packets from eth1 (internal network) to eth0 (the internet).
#
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

#
# Forward packets that are part of existing and related connections from eth0 to eth1.
#
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

#
# Permit packets in to firewall itself that are part of existing and related connections.
#
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Note, in the above two rules, a connection becomes ESTABLISHED in the
# iptables PREROUTING chain upon receipt of a SYNACK packet that is a
# response to a previously sent SYN packet. The SYNACK packet itself is
# considered to be part of the established connection, so no special
# rule is needed to allow the SYNACK packet itself.

#
# Allow all inputs to firewall from the internal network and local interfaces
#
iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT


#
# Enable SNAT functionality on eth0
#
# SNAT (Source NAT) is used to map private source IP numbers of
# interfaces on the internal LAN to one of my public static IP numbers.
# SNAT performs this mapping when a client running on one of the
# internal hosts (x.y.z.c) initiates a TCP connection (SYN) through
# eth0.
#
iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT --to-source x.y.z.c

#
# Alternative to SNAT -- MASQUERADE
#
# If your firewall has a dynamic IP number because it connects to the
# internet itself via DHCP, then you probably cannot predict what the IP
# number is of your firewall's interface connected to the internet. In 
# this case, you need a rule like the following that assigns the (an) IP
# number associated with eth0 to outgoing connections without you needing
# to know in advance (at time of writing this rule) what that IP number is:
#
# iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
#
# Note that the above SNAT and MASQUERADE rules are applicable
# independent of how a host on the internal network is assigned its own
# internal IP number.  The host could be assigned a static IP number on
# an internal nonpublic network (e.g. 10. or 192.168.)  or it could be
# itself assigned a dynamic IP number from your own DHCP server running
# on the firewall, or it could even have a public static IP number.
# However, it seems unlikely that one would want to assign a public IP
# number to a host and then proceed to hide that number from the public.
# 

#
# DROP any packet coming in on the public internet interface eth0
# which has a spoofed source address from our local networks:
#
iptables -A INPUT -i eth0 -s x.y.z.s/32 -j DROP
iptables -A INPUT -i eth0 -s x.y.z.c/32 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP

#
# Accept all tcp SYN packets for protocols SMTP, HTTP, HTTPS, and SSH:
# (SMTP connections are further audited by our SMTP server)
#
iptables -A INPUT -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 80 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 443 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT

#
# Notice that the above rules are all INPUT rules.  My current network
# does not require me to make use of FORWARD rules, since I run all
# publicly accessible servers directly on my firewall machine.  But I
# promised above in the description of my network to give examples of
# rules used when there are servers running on machines on the internal
# network.  Following are examples of FORWARD rules I would use if I ran
# mail, web, and ssh servers on machines on the internal network inside
# the firewall.
#
# iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT
# iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 80 --syn -j ACCEPT
# iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 443 --syn -j ACCEPT
# iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT
#
# 
# The first three of the above four rules would be used if my routing
# delivered packets having destination IP x.y.z.m, port 25, or IP
# x.y.z.w, port 80 or 443, to an interface connected to my internal
# network (i.e. the packet was being FORWARDed). The fourth of the above
# four rules is similar but operates on any destination IP, port 22.
# 
# The difference between an INPUT rule and a FORWARD rule is that an
# INPUT rule applies to packets that are 'input' to this machine (the
# machine on which these iptables firewall rules are installed), whereas
# a FORWARD rule applies to packets that are being 'fowarded', i.e. to
# packets that are passing through this machine to some other machine,
# such as a machine on my internal network.
# 
# If I ran my mail server on an internal machine, I would no longer
# need my previous INPUT rule for x.y.z.m and would use the above
# FORWARD rule instead.
#  

# 
# Begin Caveat, More about NAT and routing
# 
# The above talk of routing is independent of the rules defined here.
# I.e., routing is determined by ifconfig, route, et. al.  I have not
# yet seen any very good explanation of how to setup the static routing
# table (what you see as output from the `route` command).  I will not
# attempt to remedy that lacuna at this time.  If you know of some
# good documenation that completely and accurately explains the
# semantics of the ifconfig and route commands, i.e., explains what
# affect each has such that I can reliably predict what the output
# of `route` will be after executing a sequence of ifconfig and
# route commands, then please do let me know.
# 
# What *can* be done by IPTABLES rules that has the 'feel' of routing is
# DNAT (Destintion NAT) and SNAT (Source NAT).  DNAT and SNAT rules are,
# respectively, mechnisms to map the incoming destination IP number and
# outgoing source IP number to different IP numbers.  For example, SNAT
# can be used to map an internal source IP number to any one of your
# external public IP numbers so that a workstation on your internal
# network will appear to servers on the internet to which it connects to
# have a source IP number equal to the mapped public IP number.
# 
# DNAT goes the other way. It is a mechanism used typically to map
# public destination IP numbers to internal private IP numbers.  (In
# fact, DNAT could also map public to public or private to private or
# private to public, but that is left as an exercise for the reader).
# So, for example, if you run a mail server on a machine configured with
# an internal IP number but wish to expose that service to the external
# world via a public IP number, DNAT is for you.
# 
# Now, DNAT and SNAT are *not* routing but can *interact* with routing.
# Routing decides whether a packet is going to be INPUT to this machine
# or be FORWARDed to another machine.  That decision is done by routing.
# Once that decision is made, and only then, are the IPTABLES filtering
# rules (FORWARD and INPUT rules) applied to a given packet.  On the
# other hand DNAT is applied by a PREROUTING rule and SNAT by a POSTROUTING
# rule.  It is now time for you to read the following Packet Filtering
# HOWTO section:
# 
# https://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-9.html
# 
# which states:
# 
#     It's common to want to do Network Address Translation (see the
#     NAT HOWTO) and packet filtering. The good news is that they mix
#     extremely well.  [editor- The NAT HOWTO can be found at:
#     https://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html]
# 
#     You design your packet filtering completely *ignoring* any NAT you
#     are doing. The sources and destinations seen by the packet filter
#     will be the `real' sources and destinations. For example, if you
#     are doing DNAT to send any connections to 1.2.3.4 port 80 through
#     to 10.1.1.1 port 8080, the packet filter would see packets going
#     to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80.
#     Similarly, you can ignore masquerading: packets will seem to come
#     from their real internal IP addresses (say 10.1.1.1), and replies
#     will seem to go back there.
# 
# 
# Hence, INPUT/FORWARD rules would operate on destination IP numbers
# *after* a DNAT rule is applied.  But if you don't have any DNAT rules,
# then INPUT/FORWARD would apply to the IP numbers as they are in the
# incoming packet.
# 
# INPUT or FORWARD would be needed purely depending on whether your
# routing would cause the packet to stay on the machine where the
# firewall is installed or be forwarded to another machine.  THAT
# decision is done by routing and *not* by DNAT or SNAT or anything
# else in this firewall script.
# 
# It is perfectly possible for the machine having the firewall to have
# both public and internal IPs configured and/or for some packets to be
# INPUT and others to be FORWARDed.
# 
# DNAT is done by a PREROUTING rule, so you should think of things as
# proceeding in the following order:
# 
#     1.  apply PREROUTING DNAT rules (if any) to map destination IP
#     2.  apply routing decisions (see ifconfig et. al.)
#     3a. apply INPUT rules to packets having a destination IP on this machine
#     3b. apply FORWARD rules to packets having a destination IP elsewhere
#     4.  apply POSTROUTING SNAT rules (if any) to map source IP
# 
# (3a and 3b can be done in either order since they apply to a mutually
# exclusive set of packets)
# 
# I *think* that's correct. 
# 
# End Caveat, More about NAT and routing
# 


#
# Sometimes I run older versions of SSH on port 2200:
#
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 2200 --syn -j ACCEPT

#
# For imapd via stunnel (instead of xinetd-based imapd):
#
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 993 --syn -j ACCEPT

#
# For xinetd-based IMAP server (see /etc/xinetd.conf for who can use it):
#
#iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 143 --syn -j ACCEPT

#
# For DHCP server:
#
iptables -A INPUT -i eth1 -p tcp --sport 68 --dport 67 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --sport 68 --dport 67 -j ACCEPT

#
# For LDAP clients:
#
#iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 389 -syn -j ACCEPT
#dga- worry about LDAP later (after I decode LDAP documentation (-;)


#
# DNS queries:
#
# Permit responses from our ISP's DNS server.  When a client running on our
# host makes a DNS query, the outgoing query is allowed since we permit all
# outgoing packets.  The reply will be a UDP connection back to the high
# numbered client port from which the query was made.  So we only need to
# permit UDP packets from our ISP's DNS servers back to high numbered ports:
#
#iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT
#
# But since we trust our ISP DNS Server not not have been hacked and we may
# not be sure what our client IP range is, we loosen this to:
#
iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 -j ACCEPT


#
# Running a caching DNS Server
#
# We need to permit querying a remote DNS server.  Since I am running
# a caching DNS server on x.y.z.d that makes requests for DNS lookups
# to external DNS servers, those servers send back responses via UDP to
# the high numbered client port on x.y.z.d where the caching server listens.
# I could of course increase security by running the dns cache on its own
# machine/IP and restricting to just that machine/IP.
#
iptables -A INPUT -p udp -s 0/0 --source-port 53 -d x.y.z.d/32 --destination-port 1024:65535 -j ACCEPT


#
# Running a DNS server (tinydns)
#
# When we run a DNS server, we have to accept UDP from anywhere to port 53
#
iptables -A INPUT -p udp -s 0/0 -d 0/0 --destination-port 53 -j ACCEPT


#
# Running a Master DNS Server to update slave DNS servers
#
# You may have your server colocated at an ISP and may arrange to have your
# ISP provide your primary and secondary DNS with the ISP DNS servers slaving
# off of your master DNS server.  This has the advantage of letting you be
# in full control of the DNS zone files yet keeping the DNS servers exposed
# to the public outside of your network.  To achieve this, in addition to
# permitting vanilla DNS responses from the ISP DNS serves, you also need
# to allow TCP connections from the ISP Master DNS Server:
#
# Allow DNS zone transfers via TCP from ISP Master DNS server:
#
# iptables -A INPUT -p tcp -s <ISP Master DNS server IP>/32 -d 0/0 --destination-port 53 --syn -j ACCEPT


#
# For some other custom server running here listening on port <port number>:
#
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port <port number> --syn -j ACCEPT

#
# For FTP server, restricted to specific local hosts (and see /etc/xinetd.conf):
# (for public file transfers we use scp, sftp, and related SSH file transfer tools)
#
iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 20 --syn -j ACCEPT
iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 21 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 20 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 21 --syn -j ACCEPT

#
# For Samba (smbd and nmbd), restricted to specific local client hosts (x.y.z.c):
#
iptables -A INPUT -p tcp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 139 --syn -j ACCEPT
iptables -A INPUT -p udp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 137 -j ACCEPT

#
#Special cable modem rules.  I used to have a third ethernet card,
#eth2, attached to a separate ISP via a cable modem and used the rules
#shown below to cause a specific Windows machine on my internal network
#(192.168.0.128) to send traffic out via DSL and get it back via cable.
#This violates ingres filtering rules but seems to work.  It was neat
#since my cable modem had higher inbound bandwidth and it permitted
#me to do downloads without impacting my DSL inbound bandwidth.
#I no longer have that third interface, so no longer use this technique.
#
#iptables -A INPUT -i eth2 -s 68.65.209.39/32 -j DROP
#iptables -A INPUT -i eth2 -s 127.0.0.0/8 -j DROP
#iptables -t nat -A POSTROUTING -s 192.168.0.128/32 -d 0/0 -j SNAT --to-source 68.65.209.39

#
# Finally, DROP all connection requests to any UDP port not yet provided
# for and all SYN connection requests to any TCP port not yet provided
# for.  Using DROP instead of REJECT means that no 'ICMP port
# unreachable' response is sent back to the client attempting to
# connect.  I.e., DROP just ignores connection attempts.  Hence, use of
# DROP causes UDP connection requests to time out and TCP connection
# requests to hang.  Hence, using DROP instead of REJECT may have
# the effect of frustrating attackers due to increasing the amount of
# time taken to probe ports.
#
# Note that there is a fundamental difference between UDP and TCP
# protocols.  With UDP, there is no 'successful connection' response.
# With TCP, there is.  So an attacking client will be left in the dark
# about whether or not the denied UDP packets arrived and will hang
# waiting for a response from denied TCP ports.  An attacker will not
# be able to immediately tell if UDP connection requests are simply
# taking a long time, if there is a problem with connectivity between
# the attacking client and the server, or if the packets are being
# ignored.  This increases the amount of time it takes for an attacker
# to scan all UDP ports.  Similarly, TCP connection requests to denied
# ports will hang for a long time.  By using REJECT instead of DROP, you
# would prevent access to a port in a more 'polite' manner, but give out
# more information to wannabe attackers, since the attacker can positively
# detect that a port is not accessible in a small amount of time from
# the 'ICMP port unreachable' response.

iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP
iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP


# end oceanpark.com firewall rules (using iptables)
# -------------------------------------------------