|
Introduction Main Features What's new License Downloads Mirrors CVS Support Mailing lists Useful links Documentation Installation Configuration Modules Gateway About us Thanks Testimonials Help Us |
|
| Thanks to our friends from Open Network Architecture for their support! |
Written by: Adrian Pascalau apascalau@openna.com
Written by: Gerhard Mourani gmourani@openna.com
Last update: June 08, 2002
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled GNU Free Documentation License.This document describe the main configuration procedure of the GIPTables Firewall package on a RedHat Linux or compatible system.
You should allready have the firewall installed on your system. See the GIPTables Firewall Installation Guide page for installation instructions. If you are using OpenNA Linux BETA3 or newer, GIPTables Firewall comes by default installed as a
rpm package, but the configuration procedure is the same.Introduction
After GIPTables has been installed successfully in your system, your next step is to configure or customize its configuration file to suit your needs. GIPTables is not software that needs to be compiled to work on your system but just to be configured. As we can imagine there are many possible configurations for a firewall design. Someone may need to configure it to run for a Web Server, other may need to configure it to run for a Mail Server, or DNS Server, or Virtual Server, Gateway Server, etc, or simply want to have the possibility to customize it for specific requirement.
This is one of the advantages of GIPTables. It comes with many pre built configuration files suitable for the type of server you want to protect. The GIPTables Firewall configurations files are very flexible and easy to understand and setup. All you have to do is to answer to the available questions, which refer to a specific option of the firewall by
"yes" to enable the service
or "no" to disable the service.All pre built configuration files are located under the
/lib/giptables/conf directory. Please,
look into this directory for any existing configuration file pertaining to the version of the
GIPTables software that you may have. At this writing, the following pre configured GIPTables
configuration files are available:
giptables.conf.dns1 Default configuration file for a Master DNS Server giptables.conf.dns2 Default configuration file for a Slave DNS Server giptables.conf.ftpserver Default configuration file for a FTP Server giptables.conf.gateway Default configuration file for a Gateway Server giptables.conf.mailserver Default configuration file for a Mail Server giptables.conf.ppp Default configuration file for a PPP gateway server giptables.conf.README Contains all possible configuration parameters giptables.conf.virtual Default configuration file for a Virtual Server giptables.conf.webserver Default configuration file for a Web Server giptables.conf.workstation Default configuration file for a Workstation
/etc/giptables.conf(The GIPTables Configuration File)/etc/rc.d/rc.giptables.blocked(The GIPTables Blocked File)/etc/rc.d/rc.giptables.custom(The GIPTables Custom File)/etc/init.d/giptables(The GIPTables Initialization File)
/etc/giptables.conf: The GIPTables Configuration FileThe
/etc/giptables.conf file is the main configuration file for GIPTables Firewall. Though there
may have many options in this file, you should only need to change some values to get
GIPTables up and running.Just after installation,
giptables.conf file do not exist in /etc directory. Why? Remember that
many possible configurations exist on the firewall world and depending of your requirement and
the server type that you expect to protect, configuration will differ. GIPTables have some default
example configuration files available under the /lib/giptables/conf directory to suit your
needs. You have to choose the one that is suitable for your server type and create a symbolic link
in /etc directory that point to it. This is the reason why the giptables.conf file do not exist
into the /etc directory. You have to make a symbolic link pointing to the predefined GIPTables
configuration files available in the /lib/giptables/conf directory to create it as
giptables.conf file in /etc directory.Step 1
First of all, you should choose one of the default configuration file that can be found in
/lib/giptables/conf directory. Take one that mostly meet your needs, make a copy of it and
open it with any kind of text editor to configure it. In our fictive example, we will configure our
GIPTables Firewall software for a Gateway/Proxy Server with two network interfaces since it is
the most complicated configuration.These procedures can be accomplished with the following commands:
[root@deep /]# cd /lib/giptables/conf/ [root@deep conf]# cp giptables.conf.gateway giptables.conf.mybox [root@deep conf]# ln -sf /lib/giptables/conf/giptables.conf.mybox /etc/giptables.confIn the above step, we make a copy of our original
giptables.conf.gateway file and create
a symbolic link pointing to the copy.NOTE: It is a good idea to not modifying directly an example configuration file, because if you damage it, then you have to install the package again in order to get it back.
Step 2
Now our
giptables.conf file that is a symbolic link pointing to the original configuration file for
a Gateway set-up exists. It is time to edit it and provide or change some minimal values to make it
work for our system.In the GIPTables configuration file below, we ONLY talk and explain how to configure and set parameters that are the same for all type of GIPTables firewall configuration. Parts that differ are associated to different available GIPTables modules that must be loaded by the firewall configuration file to enable different required services. All available modules with GIPTables firewall are explained in GIPTables Firewall Module Configuration Guide.
Edit the
giptables.conf file and configure it to fit your
system and networking setup:
[root@deep /]# vi /etc/giptables.confTexts in bold are what should be changed by you to make the firewall work on your server
The Debug Definition
The first configurable option that is the same for all type of GIPTables Firewall configuration is
DEBUG and it is set to "off" by default. This option is useful only for debugging purpose.# ---------------------------------------------------------------------------- # DEBUG # DEBUG="off"If you set this option to
"on", then the firewall will display on the screen all iptables rules
pertaining to the GIPTables configuration file that you use, nothing will go to kernel. The
displayed set of rules will be commented so that you will not end up with lots of rules on the
screen that you do not understand, but with a commented set of rules. In this way you can only
see what the firewall is generating, and also you will be able to better understand which rule is for
what.When this option is set to
"off" (the default setting), the firewall will send all generated rules to
the kernel, nothing will be displayed on your screen and the firewall will run on your system.
Therefore if you want to run GIPTables on your system, you must be sure that this option is set
to "off".NOTE: When the
DEBUG option is set to "on", it is possible to redirect the output of the firewall
rules to a file, and use this file as learning example of how to set up iptables rules for different
kind of services. This is possible with the following command:
[root@deep tmp]# /etc/init.d/giptables start > giptables.rules.txtThe Monolithic Kernel Definition
The second configurable option that is the same for all type of GIPTables firewall configuration is
MONOLITIC_KERNEL and it is set to "no" by default. This option exists because the GNU/Linux
kernel can be compiled so that it will contains all the required iptables drivers code directly in
it. In this way we have a Monolithic Kernel and we need to answer by "yes" to the option.
# ----------------------------------------------------------------------------
# Some definitions for easy maintenance
# Edit these to suit your system
#
MONOLITIC_KERNEL="no"
If you set this option to "yes", then GIPTables will be informed that all native iptables
modules are directly compiled into the kernel. It is important to say "yes" here only if you have a
Monolithic Kernel installed on your computer otherwise say "no".If this option is set to
"no" (the default), then GIPTables will be informed that all native
iptables modules are NOT directly compiled into the kernel. The firewall will look and load all
iptables modules that are required, depending on your configuration file.NOTE: If you compile your kernel as Monolithic, you should know what iptables modules you need to compile directly into the kernel, since the firewall will not try to load them. If you missed some modules, you will inevitably get errors, or the firewall might not work as expected. The best solution for a Monolithic Kernel set-up is to compile all native iptables modules into the kernel. Please see the GIPTables Firewall Installation Guide for instructions how to compile your kernel. Also, don't forget to set
MONOLITIC_KERNEL="yes" in the firewall configuration file.The External Network Interface Definition
The next configurable option that is the same for all type of GIPTables Firewall configuration is one of the most important settings for the configuration file.
# Interface 0: This is our external network interface
# It is directly connected to Internet
INTERFACE0="eth0"
INTERFACE0_IPADDR="x.x.x.x"
ANY_IPADDR="0/0"
The above definitions set up parameters associated with our network interface. The first
parameter INTERFACE0="eth0" defines our external interface (the one directly connected to
the Internet). By convention, we set it as "eth0", but this is not mandatory and you can change it
for whatever your external network interface is.The second parameter
INTERFACE0_IPADDR="x.x.x.x" defines the external IP address
associated with the eth0 interface that your ISP or administrator assigned to you. Be aware that
every one have a different IP address, therefore the IP value should be different for every one.The third parameter
ANY_IPADDR="0/0" defines the IP address of any machine. The value of
"0/0" means any machines from anywhere. This should NOT be changed, since we use this
parameter when we want to talk to any machine out there.WARNING: This warning apply only for DHCP server configuration: If you get your external IP address from your ISP DHCP server, then set the value associated with the
INTERFACE0_IPADDR parameter to:
INTERFACE0_IPADDR=`/lib/giptables/if_ipaddr $INTERFACE0`.
Also, because the firewall is configured to be loaded before any network is initialized, we have to
edit /etc/init.d/giptables file and replace the second line that read
# chkconfig: 2345 08 92 to read # chkconfig: 2345 11 92
In this way, we configure our firewall to start up after the network is initialized, and after we
received our dynamic IP address from the DHCP server.The Internal Network Interface Definition
The next definition is very important for a Gateway Server set-up ONLY since it allow us to define our second network interface on the system. It is simply NOT require and do not apply on servers or workstations with only one network interface.
# Interface 1: This is our internal network interface
# It is directly connected to our internal Network 1
INTERFACE1="eth1"
INTERFACE1_IPADDR="192.168.1.254"
NETWORK1="192.168.1.0/24"
The above definitions set up parameters associated with our second network interface (if any). As
we can imagine, the first parameter INTERFACE1="eth1" defines in this case our internal
interface name (the one directly connected to our internal private network).The second parameter
INTERFACE1_IPADDR="192.168.1.254" defines the internal IP
address associated with the "eth1" interface. Don't forget to change the IP address if your IP
address is different.Finally, the third and new parameter
NETWORK1="192.168.1.0/24" defines our internal
subnet. You can remark that we define it with IP range to cover every node into our private
internal network. As usually, you have to change the example IP address range for the one that
you use.NOTE: If you do not have an internal network, then your machine is a Workstation or a Server with only one network interface. In this case just comment out those three options or only the
INTERFACE1 option, and the firewall will totally ignore any other options that refers to internal
interface and to the internal network. If this is your case, then you have to use another GIPTables example
configuration file instead of the giptables.conf.gateway configuration file that is only
suitable for a Gateway Server.If you would like your internal network to be automatically
SNATed (MASQUERADED) by GIPTables Firewall,
then you should not change the default value of the following parameters, that is NETWORK1_NAT="yes".
However, if the ip addresses from your internal network are alocated to you by your ISP, you might not
require your connections to be SNATed. If you are unsure, just leave it with the default value.
# Do you need Network Address Translation for your internal network?
NETWORK1_NAT="yes"
The Name Servers DefinitionThe Name Servers definition is where we define IP addresses for our Primary and Secondary Domain Name Servers. The entries can be the IP addresses that your ISP gave you or the one that your administrator gave you for your network.
# Your name servers ip address
ISP_PRIMARY_DNS_SERVER="a.a.a.a"
ISP_SECONDARY_DNS_SERVER="b.b.b.b"
The SYSLOG Server DefinitionThe SYSLOG Server definition is mandatory. You only need to define it if you have one central log server configured to receive all syslog messages on your network. In general, and if you use this feature, you will have one server on your network configured to receive all log messages and all other servers configured to send their syslog message to the central log server. The value that should be entered into the SYSLOG Server Definition is the IP address of the central log server.
# SYSLOG server ip address SYSLOG_SERVER="c.c.c.c"The loopback Interface Definition
The next definition in our GIPTables configuration pertains to the loopback interface of GNU/Linux and you don't need to modify it at all.
# Loopback interface
LOOPBACK_INTERFACE="lo" # Loopback interface
The Ports Declarations DefinitionThe same it true for the definition of privileged and unprivileged ports numbers in our system. The privileged ports numbers are used by daemon services that we run on the server and the unprivileged ports number by client to establish a connection to the ports of the server. The ports declaration are important for GIPTables to distinct on which ports important services are allowed to run and on which ports client are allowed to connect. This is a security feature.
# Port declarations do not change them
PRIV_PORTS="0:1023"
UNPRIV_PORTS="1024:65535"
The Custom Rules DefinitionMost of all services and rules required and used on production servers are already included with GIPTables through different modules files. There can be a situation where we need for some reason to add additional rules to the firewall; this is possible with the Custom Rules Definition. If you answer by
"yes" to the definition below, GIPTables will let you add you own custom
iptables rules through the file called rc.giptables.custom located under the /etc/rc.d
directory and the rules will be added to the firewall.# Loading custom firewall rules from /etc/rc.d/rc.giptables.custom # LOAD_CUSTOM_RULES="yes"If
LOAD_CUSTOM_RULES="no", then the Custom Rules Definition is disable.The Logging Definition
This section configures the logging of dropped packets and sends the information to
/var/log/messages
log file for investigation. As you will see, for each interface and our internal network we have
separate logging options. If you do not have an internal interface, then just ignore, comment out
or delete those options that refer to internal interface and internal network (INTERFACE1 and
NETWORK1).
# ----------------------------------------------------------------------------
# Logging
# Limit the amount of incoming dropped packets that gets sent to the logs.
#
# We log & drop all the packets that are not expected. In order to avoid
# our logs being flooded, we rate limit the logging.
# Interface 0 log dropped packets
INTERFACE0_LOG_DROPPED_PACKETS="yes"
INTERFACE0_LOG_LIMIT="5/m"
INTERFACE0_LOG_LIMIT_BURST="7"
# Interface 1 log dropped packets
INTERFACE1_LOG_DROPPED_PACKETS="yes"
INTERFACE1_LOG_LIMIT="7/m"
INTERFACE1_LOG_LIMIT_BURST="9"
# Network 1 log forwarded dropped packets
NETWORK1_LOG_DROPPED_PACKETS="yes"
NETWORK1_LOG_LIMIT="9/m"
NETWORK1_LOG_LIMIT_BURST="11"
Our firewall default policy is to DROP everything, and before of this, ACCEPT only wanted
packets. In an ideal network environment, we do not need to drop a single packet, but when we
want to protect our machine or our internal network from the garbage that is out there over the
Internet then we really need to consider dropping unwanted packets.What we actually drop are weird packets, incoming connections for services that we do not want to give to the external world, and so on. When those unwanted packets are coming in, we log them just to be able to see when and from where those packets are coming in.
Now, there might be a situation when somebody out there will send to us only packets that we don't want, and because we log everything that we drop, soon our logs will fill out of our disk space. To avoid this situation, we impose a rate limit to the logging, so that at any time, only the value entered into the
LOG_LIMIT parameter will be logged with a burst of the value entered into
the LOG_LIMIT_BURST parameter.The
LOG_LIMIT module option specifies the maximum average number of matches to allow per
second, per minute, per hour or per day by using /second or /s, /minute or /m, /hour or /h
and /day or /d.The
LOG_LIMIT_BURST module option specifies the exact number of packets to log pertaining to
the value defined into the LOG_LIMIT module option.Ok, I'm pretty sure that this seems to be a little bit confusing here...
Therefore, if we take the above
INTERFACE0 example, the definitions mean that, the first time
this rule is reached, the packet will be logged; in fact, since the default burst is 7
(INTERFACE0_LOG_LIMIT_BURST="7"), the first seven packets will be logged. After this, it will
be five minutes (INTERFACE0_LOG_LIMIT="5/m") before a packet will be logged from this rule,
regardless of how many packets reach it.The log information is sent to the
/var/log/messages file. There are different strings that can
be used to interpret the /var/log/messages file in order to find different type of dropped
packet information:
giptables-drop-src-ipaddr: The packet was dropped based on the source IP address.
giptables-drop-dst-ipaddr: The packet was dropped based on the destination IP address.
giptables-drop-src-spoof: The packet was dropped becuase it has a spoofed source ip address.
giptables-drop-src-norule: The packet was dropped because it reached the end of firewall chains.
giptables-drop-dst-norule: The packet was dropped because it reached the end of firewall chains.
giptables-new-no-syn: The TCP packet was dropped because it was a NEW one without SYN flag set.
giptables-fragments: The packet was dropped because it was a fragment.
giptables-malformed-xmas: The TCP packet was dropped because it looks like a malformed XMAS packet.
giptables-malformed-null: The TCP packet was dropped because it looks like a malformed NULL packet.
giptables-end-of-firewall: The packet was dropped because it reached the end of firewall chains.
Used only for testing purpose, during developemnet.
The Network Ghouls DefinitionThere might be situations when we would like to DROP any connection to and from one or more IP addresses. This can be done using the Network Ghouls section and by changing the default value of
"no" to "yes" with NETWORK_GHOULS="yes".
# ----------------------------------------------------------------------------
# Network Ghouls
# Refuse any connection from problem sites
#
NETWORK_GHOULS="no"
To enable Network Ghouls definition and feature with GIPTables, we have to answer by "yes" to
the first parameter (NETWORK_GHOULS="yes"). If NETWORK_GHOULS="no", this section is
ignored by the firewall.NOTE: The list of IP addresses that will be blocked from having any kind of access to your server on all interfaces should be defined into the
/etc/rc.d/rc.giptables.blocked file when the
NETWORK_GHOULS parameter is set to "yes".The Syn-flood Protection Definition
To protect your machine from SYN-flooding Denial of Service (DoS) attacks, the
SYN_FLOOD_PROTECTION parameter should be set to "yes". This allows us to limit the number of
incoming TCP connections, and have at anytime a well-defined number of allowed TCP
connections on the system.
# ----------------------------------------------------------------------------
# Syn-flood protection
# Limit the number of incoming tcp connections
#
SYN_FLOOD_PROTECTION="yes"
# Interface 0 incoming syn-flood protection
INTERFACE0_IN_SYN_FLOOD_PROTECTION="yes"
INTERFACE0_IN_TCP_CONN_LIMIT="1/s"
INTERFACE0_IN_TCP_CONN_LIMIT_BURST="3"
# Interface 1 incoming syn-flood protection
INTERFACE1_IN_SYN_FLOOD_PROTECTION="yes"
INTERFACE1_IN_TCP_CONN_LIMIT="3/s"
INTERFACE1_IN_TCP_CONN_LIMIT_BURST="5"
# Network 1 forwarded incoming syn-flood protection
NETWORK1_IN_SYN_FLOOD_PROTECTION="yes"
NETWORK1_IN_TCP_CONN_LIMIT="5/s"
NETWORK1_IN_TCP_CONN_LIMIT_BURST="7"
The TCP_CONN_LIMIT option specifies the maximum average number of new TCP packets that
starts a new connection to be accepted per second, per minute, per hour or per day by using
/second or /s, /minute or /m, /hour or /h and /day or /d.In our example, we have two interfaces definition (
INTERFACE0 and INTERFACE1) and one
network definition (NETWORK1). The network definition refers to our internal network and the SYN-
flood protection feature is enabling on each one. If you don't have an internal interface, then just
ignore, comment out or delete the options that refer to internal interface and network (INTERFACE1
and NETWORK1).If
SYN_FLOOD_PROTECTION="no", then the entire SYN-flood protections section are ignored.The Sanity Check Definition
The Sanity Check definition allows us to check the sanity (health) of packets that are coming in. If the
SANITY_CHECK option is set to "yes", Sanity Check protection with your firewall will be
enable.
# ----------------------------------------------------------------------------
# Sanity check
#
SANITY_CHECK="yes"
# Make sure NEW incoming TCP connections are SYN packets
INTERFACE0_IN_DROP_NEW_WITHOUT_SYN="yes"
INTERFACE1_IN_DROP_NEW_WITHOUT_SYN="yes"
NETWORK1_IN_DROP_NEW_WITHOUT_SYN="yes"
# Drop all incoming fragments
INTERFACE0_IN_DROP_ALL_FRAGMENTS="yes"
INTERFACE1_IN_DROP_ALL_FRAGMENTS="yes"
NETWORK1_IN_DROP_ALL_FRAGMENTS="yes"
# Drop all incoming malformed XMAS packets
INTERFACE0_IN_DROP_XMAS_PACKETS="yes"
INTERFACE1_IN_DROP_XMAS_PACKETS="yes"
NETWORK1_IN_DROP_XMAS_PACKETS="yes"
# Drop all incoming malformed NULL packets
INTERFACE0_IN_DROP_NULL_PACKETS="yes"
INTERFACE1_IN_DROP_NULL_PACKETS="yes"
NETWORK1_IN_DROP_NULL_PACKETS="yes"
There are 4 different kinds of sanity checks protection used in this version of GIPTables
Firewall and each one has a specific function to accomplish as follow:
- Make sure that NEW incoming TCP connections are SYN packets. This will log and drop any new packet that does not have SYN flag set.
- Drop all incoming fragments. This will log and drop any fragment. Fragments can be overlapped, and the subsequent interpretation of such fragments is very OS-dependent. In our protection, we are not going to trust any fragments, thus we log them just to see if we get any, and drop them too.
- Drop all incoming malformed XMAS packets. A typical XMAS scan will most likely show all flags from TCP packet header set. We log and drop all XMAS packets.
- Drop all incoming malformed NULL packets. A NULL packet has no flags set in the TCP header, so it does not do anything and we don't need it. Those NULL packets are usually used for port scans; therefore we should safely drop all of them.
INTERFACE1 and NETWORK1).If
SANITY_CHECK="no", then the entire sanity check section is ignored.The Spoofing and Bad Addresses Definition
All IP packet headers contain the source and destination IP addresses and the type of IP protocol message (ICMP, UDP or TCP) the packet contains. The only means of identification under the Internet Protocol (IP) is the source address in the IP packet header. This is a problem that opens the door to source address spoofing, where the sender may replaces its address with either a nonexistent address, or the address of some other site.
Also, there are at least seven sets of source addresses you should refuse on your external interface in all cases.
These are incoming packets claiming to be from:
- Your external IP address
- Class A private IP addresses
- Class B private IP addresses
- Class C private IP addresses
- Class D multicast addresses
- Class E reserved addresses
- The loopback interface
In this section we log and drop all incoming packets with source IP addresses that we do not expect or we do not want. There are some important that really need to be monitored and controlled as shown below:
# ----------------------------------------------------------------------------
# Spoofing and bad addresses
#
REFUSE_SPOOFING="yes"
There is no way for a packet that come in from the Internet on our external interface to have its
own source IP address the same with our external IP address. If this happen, then packets are
spoofed; therefore we log and drop them.We log and drop all incoming packets claiming to be from the IP addresses of our interfaces. In a Gateway firewall configuration, we have two network interfaces, and two IP addresses associated with them. Therefore, we should protect both interfaces as follow.
# Refuse incoming packets claiming to be from the IP addresses of our interfaces REFUSE_SPOOFING_IPADDR[0]=$INTERFACE0_IPADDR INTERFACE0_IN_REFUSE_SPOOFING[0]="yes" INTERFACE1_IN_REFUSE_SPOOFING[0]="no" NETWORK1_IN_REFUSE_SPOOFING[0]="yes" REFUSE_SPOOFING_IPADDR[1]=$INTERFACE1_IPADDR INTERFACE0_IN_REFUSE_SPOOFING[1]="no" INTERFACE1_IN_REFUSE_SPOOFING[1]="yes" NETWORK1_IN_REFUSE_SPOOFING[1]="no"We log and drop all incoming packets claiming to be from broadcast source address range. We accept broadcast source packets only in one situation: when we have a DHCP Server, and this, because a DHCP Client will request its IP address by sending out a DHCP discovery packet that has source IP address "0.0.0.0" and destination IP address "255.255.255.255". In this situation, the Gateway Server is also a DHCP Server, so we will accept by default those broadcast source packets only on the internal interface.
# Refuse incoming packets claiming to be from broadcast-src address range
REFUSE_SPOOFING_IPADDR[2]="0.0.0.0/8"
INTERFACE0_IN_REFUSE_SPOOFING[2]="yes"
INTERFACE1_IN_REFUSE_SPOOFING[2]="no"
NETWORK1_IN_REFUSE_SPOOFING[2]="yes"
We log and drop all incoming packets claiming to be from reserved loopback IP address
range. This is so obvious. We should never have incoming packets with source IP
address from the loopback address range. We can refuse them safely on all our
interfaces.
# Refuse incoming packets claiming to be from reserved loopback address range
REFUSE_SPOOFING_IPADDR[3]="127.0.0.0/8"
INTERFACE0_IN_REFUSE_SPOOFING[3]="yes"
INTERFACE1_IN_REFUSE_SPOOFING[3]="yes"
NETWORK1_IN_REFUSE_SPOOFING[3]="yes"
We log and drop all incoming packets claiming to be from well-known private networks:
A, B, C. We can safely refuse all packets claiming to be from those private networks on
all of our interfaces, and internal network.
# Refuse incoming packets claiming to be from class A private network
REFUSE_SPOOFING_IPADDR[4]="10.0.0.0/8"
INTERFACE0_IN_REFUSE_SPOOFING[4]="yes"
INTERFACE1_IN_REFUSE_SPOOFING[4]="yes"
NETWORK1_IN_REFUSE_SPOOFING[4]="yes"
# Refuse incoming packets claiming to be from class B private network
REFUSE_SPOOFING_IPADDR[5]="172.16.0.0/12"
INTERFACE0_IN_REFUSE_SPOOFING[5]="yes"
INTERFACE1_IN_REFUSE_SPOOFING[5]="yes"
NETWORK1_IN_REFUSE_SPOOFING[5]="yes"
# Refuse incoming packets claiming to be from class C private network
REFUSE_SPOOFING_IPADDR[6]="192.168.0.0/16"
INTERFACE0_IN_REFUSE_SPOOFING[6]="yes"
INTERFACE1_IN_REFUSE_SPOOFING[6]="no"
NETWORK1_IN_REFUSE_SPOOFING[6]="yes"
WARNING: There is only one exception in which case we do not refuse incoming packets on our
internal interface claiming to be from our internal private network. This appears only for a
Gateway Server when your internal network is from class C. You should not refuse incoming
packets on internal interface from your internal network.We log and drop all incoming packets claiming to be from class D, E, and unallocated. Those refer to classes that are not currently used or that are unallocated. There is no reason for an incoming packet to have source IP address from those classes.
# Refuse incoming packets claiming to be from class D, E, and unallocated
REFUSE_SPOOFING_IPADDR[7]="224.0.0.0/3"
INTERFACE0_IN_REFUSE_SPOOFING[7]="yes"
INTERFACE1_IN_REFUSE_SPOOFING[7]="yes"
NETWORK1_IN_REFUSE_SPOOFING[7]="yes"
The above Spoofing and bad addresses protection suppose that you have two network interfaces
installed on your system. This configuration is suitable for a Gateway Server. If you only have one
network interface on your server, then just ignore, comment out or delete those options that refer
to internal interface and network (INTERFACE1 and NETWORK1).If
REFUSE_SPOOFING="no" then the entire spoofing protection section is ignored.The above configuration closes our discussion about all parameters that are the same for all type of GIPTables firewall configuration. Once you have configured all of the customized values in this part of the GIPTables configuration file suitable for your type of system, you are ready to start the software and see the result.
/etc/rc.d/rc.giptables.blocked: The GIPTables Blocked FileSometimes you'll know an address that you would like to block from having any access at all to your server. Instead of entering the entire iptables line per IP address for those jerks on the internet, you can write them into the
rc.giptables.blocked file, that will take a listing of IP
address, strip out any comments and run the resulting list through an iptables routine.The net effect is to have the
/etc/giptables.conf file increase no more than needed,
especially when one might have a large number of IP addresses to deny.Step 1
Edit the
rc.giptables.blocked file and add inside this file all the IP addresses
that you want to block from having any access to your server at all:
[root@deep /]# vi /etc/rc.d/rc.giptables.blockedFor example, I've put the following IP addresses in this file:
# ---------------------------------------------------------------------------- # GIPTables Firewall 1.0 http://www.giptables.org # Copyright (C) 2002 Adrian Pascalau <apascalau@openna.com> # rc.giptables.blocked file # # ---------------------------------------------------------------------------- # This file is part of GIPTables Firewall # # GIPTables Firewall is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 204.254.45.9 # Cracker site with priority 01. 187.231.11.5 # Spam site with priority 07. #214.34.144.4 # Temporaly reactivated, please verify with log file. # ---------------------------------------------------------------------------- # End of fileHere we can see how this file can be useful. Now we can add the bad IP address, with some comments if necessary to remember actions taken for the specified IP address, into the
/etc/rc.d/rc.giptables.blocked file and restart GIPTables for the changes to takes
effect.To restart GIPTables Firewall, use the following command:
[root@deep /]# /etc/rc.d/init.d/giptables restart
/etc/rc.d/rc.giptables.custom: The GIPTables Custom FileSometimes you'll also need to add some custom iptables rules to the GIPTables Firewall. This is very usefull when you need new features that are not already implemented, like, for example, port redirection. The rules that you insert here in this file will be added just before the end of the iptables chains, where the kernel looks at the chain policy to decide what to do. In a good security-conscious firewall, like GIPTables, this policy tells the kernel to DROP the packet.
Step 1
Edit the
rc.giptables.custom file and add inside this file all the iptables rules
that you want just after the following line: # Add your custom iptables rules here.To edit the file, use the following command:
[root@deep /]# vi /etc/rc.d/rc.giptables.customThis is the
rc.giptables.custom file that comes by default with GIPTables:# ---------------------------------------------------------------------------- # GIPTables Firewall v1.1 http://www.giptables.org # Copyright (C) 2002 Adrian Pascalau <apascalau@openna.com> # rc.giptables.custom file # # ---------------------------------------------------------------------------- # This file is part of GIPTables Firewall # # GIPTables Firewall is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # Add your custom iptables rules here # ---- THE END OF THE FIREWALL ---- # This is the end of the firewall's chains # All packets that reach this point, will be dropped # All incomming packets that reach this point will be also logged # if DROP_EVERYTHING_FROM_HERE="yes" # If you would like to see those packates that are dropped, uncomment the # following 4 lines (this is very good during fireall developement & testing) # [ "$DEBUG" = "on" ] && echo -e "\n# Logging needed during developement" # $IPTABLES -A INPUT -j LOG --log-prefix "giptables-end-of-firewall: " # $IPTABLES -A OUTPUT -j LOG --log-prefix "giptables-end-of-firewall: " # $IPTABLES -A FORWARD -j LOG --log-prefix "giptables-end-of-firewall: " # Do not add any iptables rules after this point, # since this is the end of the firewall !!! # ---------------------------------------------------------------------------- # End of fileHere we can see that this file has also other functionality: logging all packets that reached the end of the firewall chains, during firewall developement and testing. By default, this feature is disabled, but if you have problems configuring GIPTables Firewall, is good to enable it.
Step 2
Edit the
rc.giptables.custom file and uncomment the following lines by deleting the
# character before of them:
# [ "$DEBUG" = "on" ] && echo -e "\n# Logging needed during developement" # $IPTABLES -A INPUT -j LOG --log-prefix "giptables-end-of-firewall: " # $IPTABLES -A OUTPUT -j LOG --log-prefix "giptables-end-of-firewall: " # $IPTABLES -A FORWARD -j LOG --log-prefix "giptables-end-of-firewall: "To edit the file, use the following command:
[root@deep /]# vi /etc/rc.d/rc.giptables.customAfter deleting the
# character, the lines should look like this:
[ "$DEBUG" = "on" ] && echo -e "\n# Logging needed during developement" $IPTABLES -A INPUT -j LOG --log-prefix "giptables-end-of-firewall: " $IPTABLES -A OUTPUT -j LOG --log-prefix "giptables-end-of-firewall: " $IPTABLES -A FORWARD -j LOG --log-prefix "giptables-end-of-firewall: "In this stage, all the packets that are dropped by the firewall will be logged in the
/var/log/messages file.In order to see all the packets that were dropped and logged, use the following command:
[root@deep /]# grep giptables-end-of-firewall /var/log/messages > giptables.dropped.txtNow, the
giptables.dropped.txt file will contain all packets that were dropped. We
can use the information in this file to debug the firewall functionality. After finishing the
developement and testing, do not forget to comment back all those rules that we uncommented before,
or you risk you filesystem to become full.In order for the custom rules that you have added or uncommented to take effect, we should restart GIPTables Firewall, using the following command:
[root@deep /]# /etc/rc.d/init.d/giptables restart
/etc/init.d/giptables: The GIPTables Initialization FileThe
/etc/init.d/giptables script file is responsible to automatically start and stop the
GIPTables Firewall on your server. It can take few parameters like start, stop, restart
and panic.The
start parameter will actually start the firewall, read the configuration file,
clear any pre-defined rules and chains from the kernel, set default policy as DROP to deny
everything by default and then generate the iptables rules according to your GIPTables
configuration file.The
stop parameter will stop the firewall, clear any pre-defined rules and chains from the
kernel, and set default policy as ACCEPT for all iptables default chains.
The restart option is really just start as this firewall isn't a daemon
and start clears any pre-defined rules anyway. This is really only here to make those who
expect it happy.The
panic option should be used when you want to cut any connections to and from your
machine. It will clear any pre-defined rules and chains from the kernel, set default policy as
DROP for all iptables default chains and let the packets going only through lookpback
interface.To start GIPTables on your system, use the following command:
[root@deep /]# /etc/init.d/giptables startAfter the main configuration of GIPTables Firewall, please read the GIPTables Firewall Modules Configuration Guide for further configuration instructions. Please check our documentation page and our FAQ for more informations regarding GIPTables Firewall.
Back
Written by: Adrian Pascalau apascalau@openna.com
Written by: Gerhard Mourani gmourani@openna.com
Last update: June 08, 2002
 |
|
Copyright © 2002 Adrian Pascalau. All Rights Reserved. All other logos and trademarks in this site are property of their respective owner. |