iptables
 
you could use firestarter or some other gui. But they all use iptables. The best thing is to get a good set of rules and use them.
 
look here for some good ones
 
http://www.linuxguruz.org/iptables/

Thanks ill check it out

ip table
 
# 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. For an explanation of why tinydns is secure, see:
# http://www.faqts.com/knowledge_base/view.phtml/aid/8739/fid/699.
#
# DENY 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.
#
# DENY all other TCP SYN packets.
#
# ACCEPT all other TCP packets that are part of existing connections
#
# DENY 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 further reading, see: http://www.cs3-inc.com/ddos.html.
#
# For detailed background reading about iptables, please refer to:
# http://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.
#
 
#
# Deny 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:
#
# http://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:
# http://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, DENY 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 DENY instead of REJECT means that no 'ICMP port
# unreachable' response is sent back to the client attempting to
# connect. I.e., DENY just ignores connection attempts. Hence, use of
# DENY causes UDP connection requests to time out and TCP connection
# requests to hang. Hence, using DENY 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 DENY, 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)
# -------------------------------------------------

ip chain
 
# Red Hat 7.1 Linux firewall using ipchains
# May, 2001
# configured by Dennis G. Allard and Don Cohen, http://oceanpark.com
#
# Permission to copy is granted provided that credit is given
# to the author and whatever HOWTOs are used to understand this
# stuff.
#
# No warrenty is implied. Use at your own risk!!
 
# This web page documents my old ipchains firewall. I have
# updated my firewall to use iptable and udpated the description
# of my firewall at http://oceanpark.com/notes/firewall_example.html.
 
# This file is /etc/sysconfig/ipchains, intended for
# consumption by the script /etc/rc.d/init.d/ipchains,
# which makes use of the script /sbin/ipchains-restore.
 
# In Red Hat 7.1, the man page for ipchains and for
# ipchains-restore does not document the syntax of this
# file. I had to read the script to understand better
# what is going on.
 
# The firewall that the Red Hat 7.1 installer set up for me
# in response to my request for a high level of security
# was too restrictive. And, I couldn't find any GUI tool
# in either GNOME or KDE to reconfigure the firewall.
# For example, the KDE menu item for editing my firewall
# showed an empty set of rules even though this file and
# the above startup script existed. So I had no confidence
# in the GUI firewall tools, resulting in my decision to edit
# this file manually.
 
# The network
# -----------
#
# This firewall was running on a gateway machine having two
# ethernet interfaces, an external one, eth0, which is
# my DSL connection to my ISP, and an internal one, eth1
# which is assigned to 198.211.65.1, an IP number on my
# class C network. I run a web server, DNS server, and
# sendmail on the firewall machine itself.
#
# 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.
 
# Running this script
# -------------------
#
# Red Hat 7.1 runs /etc/rc.d/init.d/ipchains at system
# startup, which uses this file as input. You can
# turn ipchains on and off via chkconfig. See:
#
# chkconfig --list | grep ipchains
#
# You can restart the ipchains firewall via:
#
# /etc/rc.d/init.d/ipchains restart
#
# A good way to show your ipchains rules is with:
#
# ipchains -vnL
 
 
# 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
#
# DENY all other UDP packets.
#
# ACCEPT SYN packets just for certain TCP services
# SYN packets are specified via the -y flag in the input
# rules defined below. Note that certain services can be
# further filtered by xinetd.
#
# DENY all other TCP SYN packets.
#
# ACCEPT all other TCP packets (the default input chain policy.)
#
# 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. IMPORTANT:
# ipchains is less powerful than iptables since iptables, introduced
# in linux kernel 2.4 provides for Stateful Packet Inspection. ipchains
# will allow packets in that are not part of an existing TCP connection.
# Although such packets will not normally be processed by an application,
# they can be used as part of a denial of service attack. We recommend
# that you use an iptables firewall, which is able to audit connections
# more completely. See:
#
# IPTABLES Firewall Example
#
# 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. 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 further reading, see: http://www.cs3-inc.com/ddos.html.
#
# For detailed background reading about iptables, please refer to:
# http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html
#
 
 
# oceanpark.com firewall rules (using ipchains)
# ---------------------------------------------
 
# Tell ipchains-restore what default policies to use...
:input ACCEPT
:forward ACCEPT
:output ACCEPT
 
# The above will accept anything not prevented by the following rules.
 
# Deny any packet coming in on the public internet interface eth0
# which has source address of our local network (attempt to spoof an
# address which should never come from any place but eth1) or which
# claims to be from the reserved local loop network 127.0.0.0.
-A input -i eth0 -s 198.211.65.0/24 -j DENY
-A input -i eth0 -s 127.0.0.0/8 -j DENY
 
# Accept all tcp SYN packets for protocols SMTP, HTTP, and SSH
# Note, SMTP connections are further audited by my SMTP server
-A input -s 0/0 -d 198.211.65.1/32 25 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT
 
# If you query remote DNS servers, permit UDP responses from it
# -A input -s <remote DNS server IP> 53 -d 0/0 -p udp -j ACCEPT
 
# I had to add the following line to make my DNS server honor requests
# from the public internet.
-A input -s 0/0 -d 0/0 53 -p udp -j ACCEPT
 
# Open up IMAP server (see /etc/xinetd.conf for who can use it)
-A input -s 0/0 -d 0/0 143 -p tcp -y -j ACCEPT
 
# Open up FTP server (see /etc/xinetd.conf for who can use it)
-A input -s 0/0 -d 0/0 20 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT
 
# Allow all inputs from the internal and local interfaces
-A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT
-A input -s 0/0 -d 0/0 -i lo -j ACCEPT
 
# If we wanted to use masqueading (can do even for legit internal IPs)
# -A forward -s 198.211.65.78 -j MASQ
 
# Finally, DENY 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 DENY instead of REJECT means that no 'ICMP port
# unreachable' response is sent back to the client attempting to
# connect. I.e., DENY just ignores connection attempts. Hence, use of
# DENY causes UDP connection requests to time out and TCP connection
# requests to hang. Hence, using DENY 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 DENY, 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 pot unreachable' response.
 
-A input -s 0/0 -d 0/0 -p udp -j DENY
-A input -s 0/0 -d 0/0 -p tcp -y -j DENY
 
# end of firewall rules