Firewall

Scout · December 16, 2002

Hello is there a good firwall to use with red hat 8.0 ?

scout

FishDog · December 17, 2002

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/

Scout · December 17, 2002

Thanks ill check it out

prakash0106 · February 4, 2010

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)

# -------------------------------------------------

prakash0106 · February 4, 2010

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