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
 
GIPTables Firewall Homepage
Thanks to our friends from Open Network Architecture for their support!
GIPTables Firewall Modules Configuration Guide

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 modules 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.

The main configuration procedure of GIPTables Firewall should already be done. See GIPTables Firewall Main Configuration Guide for main configuration instructions.

The GIPTables Firewall Module Files

Once you have chosen the right GIPTables configuration file suitable for the type of server that you want to protect and once all parameters, which are the same for all type of GIPTables firewall have been configured, GIPTables should have enough information to run properly on your system. In general, your work is done and your firewall is well protected to handle attacks.

Every one has different set-up for his firewall design and sometime we need to implement a new service and open, control the port associated with this service on our server. GIPTables allows us to add, modify, delete, and customize any existing or expected services in a simple manner through its modules feature.

With GIPTables, each service like DNS, FTP, HTTPD, etc have their own modules. Those modules are loaded only when defined into the giptables.conf file, so that if there are no options related to FTP for example, the FTP module will not be loaded. You can specify on which interface or network the module will work, and what kind of requests information (incoming, outgoing request) can go thought that interface or network.

All GIPTables modules are located under the /lib/giptables/modules directory and it's into these modules files that we handle all rules pertaining to the specific service. When we configure, customize and enable services parameters into the giptables.conf file, the parameter in question get its information about iptables rules that must be used through the modules files available under the /lib/giptables/modules directory. If the parameter of the specific service that you want to enable is not defined into the GIPTables configuration file, then this service will not load its iptables rules from its modules file and will not run with your GIPTables Firewall software.

If you look into the /lib/giptables/modules directory, you'll find the following modules for each possible services that you can enable with GIPTables Firewall.

giptables-ANY        The ANY module, which refer to ANY services
giptables-AUTH       The AUTH module, which refer to AUTH services
giptables-DHCP       The DHCP module, which refer to DHCP services
giptables-DNS        The DNS module, which refer to DNS services
giptables-FINGER     The FINGER module, which refer to FINGER services
giptables-FTP        The FTP module, which refer to FTP services
giptables-HTTP       The HTTP module, which refer to HTTP services
giptables-HTTPS      The HTTPS module, which refer to HTTPS services
giptables-ICMP       The ICMP module, which refer to ICMP services
giptables-IMAP       The IMAP module, which refer to IMAP services
giptables-IMAPS      The IMAPS module, which refer to IMAPS services
giptables-LDAP       The LDAP module, which refer to LDAP services
giptables-LDAPS      The LDAPS module, which refer to LDAPS services
giptables-LPD        The LPD module, which refer to LPD services
giptables-MSSQL      The MSSQL module, which refer to MSSQL services
giptables-MYSQL      The MYSQL module, which refer to MYSQL services
giptables-NETBIOS    The NetBIOS module, which refer to NetBIOS services
giptables-NNTP       The NNTP module, which refer to NNTP services
giptables-NNTPS      The NNTPS module, which refer to NNTPS services
giptables-NTP        The NTP module, which refer to NTP services
giptables-ORACLE     The ORACLE module, which refer to ORACLE services
giptables-POP3       The POP3 module, which refer to POP3 services
giptables-POP3S      The POP3S module, which refer to POP3S services
giptables-POSTGRES   The POSTGRES module, which refer to POSTGRES services
giptables-SMTP       The SMTP module, which refer to SMTP services
giptables-SMTPS      The SMTPS module, which refer to SMTPS services
giptables-SNMP       The SNMP module, which refer to SNMP services
giptables-SOCKS      The SOCKS module, which refer to SOCKS services
giptables-SQUID      The SQUID module, which refer to SQUID services
giptables-SSH        The SSH module, which refer to SSH services
giptables-SYSLOG     The SYSLOG module, which refer to SYSLOG services
giptables-TELNET     The TELNET module, which refer to TELNET services
giptables-TELNETS    The TELNETS module, which refer to TELNETS services
giptables-TRACEROUTE The TRACEROUTE module, which refer to TRACEROUTE services
giptables-VNC        The VNC module, which refer to VNC services
giptables-WEBCACHE   The WEBCACHE module, which refer to WEBCACHE services
giptables-WHOIS      The WHOIS module, which refer to WHOIS services
giptables-X11        The X11 module, which refer to X11 services
How GIPTables parameters work?

As we know now, GIPTables modules are loaded ONLY when we define and enable their specific parameters into the GIPTables configuration file. Therefore, if we want to add to our existing configuration a new service that doesn't exist, we have to define, enable and configure the service with the right parameter lines.

The best way to get an idea about the implementation is to include a new service into our existing GIPTables configuration file. In our example, we will suppose that we want to add MySQL service to our Gateway Server GIPTables Firewall. Here are all the steps that you need to do to add MySQL service to your GIPTables Firewall. Note that all of the following steps are the same for any additional services that you expect to add to your existing GIPTables configuration file.

Step 1
The first step will be to enable the MySQL service module into the GIPTables configuration file. This is possible by adding the following lines into the file. Text in bold is what should be added to enable the fictive example MySQL service.

Edit the giptables.conf file:
[root@deep /]# vi /etc/giptables.con
Add the following line:

ACCEPT_MYSQL="yes"
The above line informs the software to enable MySQL module service for MySQL database on any network interfaces or network present on the system and for any requests information (incoming or outgoing request).

Step 2
Once the MySQL module service has been enabled, we need to add the right parameters lines specific to MySQL service to the GIPTables configuration file. Remember that GIPTables is a flexible program that let us control traffics on external interface, internal interface, and internal network for incoming and outgoing traffics. For a Gateway Server, all options are required but for a server with one network interface, we only need to control traffics on the external interface for incoming and outgoing packets.

NOTE: It is important to note that each GIPTables parameter has the same definition and only parts, which relate to services that we want to define change.

Enabling outgoing client requests
In the example below, we define and enable MySQL outgoing client request for a Gateway Server. The difference about parameters with other type of servers is that we need to define additional network interface (INTERFACE1) and network (NETWORK1) for a Gateway Server set-up. Any texts in bold should be configured to define and enable the MySQL service.

# Interface 0 MYSQL outgoing client request

    INTERFACE0_MYSQL_CLIENT="yes"

    INTERFACE0_MYSQL_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_MYSQL_OUT_DST_IPADDR[0]=$ANY_IPADDR
In the above example, we firstly enable MySQL outgoing client request on the external interface (INTERFACE0_MYSQL_CLIENT="yes").

Next, we instruct the firewall that on the external interface (INTERFACE0), all MySQL (MYSQL) outgoing packets (OUT) with source ip address (SRC_IPADDR) coming from our external interface ip address ($INTERFACE0_IPADDR) and with destination ip address (DST_IPADDR) of any ip address ($ANY_IPADDR) will be allowed to go out and/or start a new connection.

In other terms, any outgoing MySQL packets generated on our machine with our external ip address as source ip address and any ip address as destination ip address will be allowed to go out and/or start a new connection. Using the connection tracking capability of iptables, the related MySQL incoming packets are automatically allowed back in by the firewall. In this case, our machine can be a MySQL client that is allowed to access any MySQL server from the Internet.

If we want to restrict the access of our machine to only one MySQL server, the parameters should be configured like in the example below:
# Interface 0 MYSQL outgoing client request

    INTERFACE0_MYSQL_CLIENT="yes"

    INTERFACE0_MYSQL_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_MYSQL_OUT_DST_IPADDR[0]="x.x.x.x"
In this case, "x.x.x.x" is the ip address of the MySQL server that we want to access. For a second MySQL server, another set of parameters should be added, like in the example below:
# Interface 0 MYSQL outgoing client request

    INTERFACE0_MYSQL_CLIENT="yes"

    INTERFACE0_MYSQL_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_MYSQL_OUT_DST_IPADDR[0]="x.x.x.x"
		
    INTERFACE0_MYSQL_OUT_SRC_IPADDR[1]=$INTERFACE0_IPADDR
    INTERFACE0_MYSQL_OUT_DST_IPADDR[1]="y.y.y.y"
"x.x.x.x" is the ip address of the first MySQL server that we want to access and "y.y.y.y" is the ip address of the second MySQL server that we want to access. Please note that the index of parameters has been increased, so that the first set of parameters have the index 0, and the second set of parameters have the index 1.

NOTE: This rule is the same for all GIPTables Firewall parameters that have an index. If you would like to add a second set of parameters, just copy/paste them, make the required changes and do not forget to increase the index.

On a Gateway Server or machines that have two networks interface, we need to define the following additional parameters for the firewall to recognize the other network interface and private network behind it.

# Interface 1 MYSQL outgoing client request

    INTERFACE1_MYSQL_CLIENT="yes"

    INTERFACE1_MYSQL_OUT_SRC_IPADDR[0]=$INTERFACE1_IPADDR
    INTERFACE1_MYSQL_OUT_DST_IPADDR[0]=$NETWORK1
In the above example, we enable MySQL outgoing client request on the internal interface (INTERFACE1_MYSQL_CLIENT="yes").

Next, we instruct the firewall that on the internal interface (INTERFACE1), all MySQL (MYSQL) outgoing packets (OUT) with source ip address (SRC_IPADDR) coming from our internal interface ip address ($INTERFACE1_IPADDR) and with destination ip address (DST_IPADDR) from our internal subnet ip range ($NETWORK1) will be allowed to go out and/or start a new connection.

In other terms, any outgoing MySQL packets generated on our machine with our internal ip address as source ip address and with destination ip address from our subnet ip range will be allowed to go out and/or start a new connection. Using the connection tracking capability of iptables, the related MySQL incoming packets are automatically allowed back in by the firewall. In this case, our machine can be a MySQL client that is allowed to access any MySQL server from our internal subnet.

# Network 1 MYSQL forwarded outgoing client request

    NETWORK1_MYSQL_CLIENT="yes"

    NETWORK1_MYSQL_OUT_SRC_IPADDR[0]=$NETWORK1
    NETWORK1_MYSQL_OUT_DST_IPADDR[0]=$ANY_IPADDR
In the above example, we enable MySQL outgoing client request on our internal subnet (NETWORK1_MYSQL_CLIENT="yes").

Next, we instruct the firewall that in our internal subnet (NETWORK1), all MySQL (MYSQL) outgoing packets (OUT) with source ip address (SRC_IPADDR) from our internal subnet ip address range ($NETWORK1) and with destination ip address (DST_IPADDR) of any ip address ($ANY_IPADDR) will be allowed to go out and/or start a new connection.

In other terms, any outgoing MySQL packets generated on machines from our internal network with source ip address from our internal subnet ip address range and any ip address as destination ip address will be allowed to go out and/or start a new connection. Using the connection tracking capability of iptables, the related MySQL incoming packets are automatically allowed back in by the firewall. In this case, our machines from our internal subnet are the MySQL clients and are allowed to access any MySQL server from the Internet.

NOTE: The requests are automatically SNATed (MASQUERADEd) by the GIPTables Firewall, so that the MySQL server from the Internet thinks that talks with our gateway.

NOTE: In general, you should only replace MYSQL with the name of the service that you want to define for the parameters to work for other type of services. In our example, we use MYSQL; it is to you to change it for the service of your choice.

Enabling incoming client requests
As we can see, all of the above parameters apply to outgoing client request for MySQL service on a Gateway Server. Now for incoming server requests, we should add the related lines to the configuration file to allow them. In the example below, we define and enable MySQL incoming client request for a Gateway Server. The difference about parameters with other type of servers is that we need to define additional network interface (INTERFACE1) and network (NETWORK1) for a Gateway Server set-up.

# Interface 0 MYSQL incoming client request

    INTERFACE0_MYSQL_SERVER="yes"

    INTERFACE0_MYSQL_IN_SRC_IPADDR[0]=$ANY_IPADDR
    INTERFACE0_MYSQL_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR
In the above example, we enable MySQL incoming client request on the external interface (INTERFACE0_MYSQL_SERVER="yes").

Next, we instruct the firewall that on the external interface (INTERFACE0), all MySQL (MYSQL) incoming packets (IN) with source ip address (SRC_IPADDR) of any ip address ($ANY_IPADDR) and with destination ip address (DST_IPADDR) coming from our external interface ip address ($INTERFACE0_IPADDR) will be allowed to come in and/or start a new connection.

In other terms, any incoming MySQL packets with any ip address as source ip address and with our external interface ip address as destination ip address will be allowed to come in and/or start a new connection. Using the connection tracking capability of iptables, the related MySQL outgoing packets are automatically allowed back out by the firewall. In this case, our machine is a MySQL server that is allowed to receive requests from any MySQL client from the Internet.

If we want to restrict the access to our MySQL server to only one machine, the parameters should be configured like in the example below:
# Interface 0 MYSQL incoming client request

    INTERFACE0_MYSQL_SERVER="yes"

    INTERFACE0_MYSQL_IN_SRC_IPADDR[0]="x.x.x.x"
    INTERFACE0_MYSQL_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR
In this case, "x.x.x.x" is the ip address of the MySQL client that is allowed to access our MySQL server. For a second MySQL client allowed, another set of parameters should be added, like in the example below:
# Interface 0 MYSQL incoming client request

    INTERFACE0_MYSQL_SERVER="yes"

    INTERFACE0_MYSQL_IN_SRC_IPADDR[0]="x.x.x.x"
    INTERFACE0_MYSQL_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR
		
    INTERFACE0_MYSQL_IN_SRC_IPADDR[1]="y.y.y.y"
    INTERFACE0_MYSQL_IN_DST_IPADDR[1]=$INTERFACE0_IPADDR
"x.x.x.x" is the ip address of the first MySQL client that is allowed to access our MySQL server and "y.y.y.y" is the ip address of the second MySQL client that is allowed to access our MySQL server. Please note that the index of parameters has been increased, so that the first set of parameters have the index 0, and the second set of parameters have the index 1.

NOTE: This rule is the same for all GIPTables Firewall parameters that have an index. If you would like to add a second set of parameters, just copy/paste them, make the required changes and do not forget to increase the index.

Don't forget that we need to add all of the lines below for a Gateway Server set-up for the firewall to recognize the second network interface and our internal subnet. Definitions and explanations are the same as for outgoing client request as explained further up.

# Interface 1 MYSQL incoming client request

    INTERFACE1_MYSQL_SERVER="yes"

    INTERFACE1_MYSQL_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_MYSQL_IN_DST_IPADDR[0]=$INTERFACE1_IPADDR
In the above example, we enable MySQL incoming client request on the internal interface (INTERFACE1_MYSQL_SERVER="yes").

Next, we instruct the firewall that on the internal interface (INTERFACE1), all MySQL (MYSQL) incoming packets (IN) with source ip address (SRC_IPADDR) from our internal subnet ip address range ($NETWORK1) and with destination ip address (DST_IPADDR) coming from our internal interface ip address ($INTERFACE1_IPADDR) will be allowed to come in and/or start a new connection.

In other terms, any incoming MySQL packets with source ip address from our internal subnet ip address range and with our internal interface ip address as destination ip address will be allowed to come in and/or start a new connection. Using the connection tracking capability of iptables, the related MySQL outgoing packets are automatically allowed back out by the firewall. In this case, our machine is a MySQL server that is allowed to receive requests from any MySQL client from our internal subnet.

There might be a situation when we would like to access the MySQL server from our internal subnet using the external interface ip address ($INTERFACE0_IPADDR) as destination ip address (DST_IPADDR). This is the case when we connect to the MySQL server using its host name instead of the ip address. Our DNS server might resolve the MySQL server's ip address as the external interface ip address. In this case, the parameters should be configured like in the example below:
# Interface 1 MYSQL incoming client request

    INTERFACE1_MYSQL_SERVER="yes"

    INTERFACE1_MYSQL_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_MYSQL_IN_DST_IPADDR[0]=$INTERFACE1_IPADDR

    INTERFACE1_MYSQL_IN_SRC_IPADDR[1]=$NETWORK1
    INTERFACE1_MYSQL_IN_DST_IPADDR[1]=$INTERFACE0_IPADDR
As you can see, we have copy/paste the first set of parameters, then changes the destination IP address (DST_IPADDR) to our external interface ip address ($INTERFACE0_IPADDR) and also increase the index number.
# Network 1 MYSQL forwarded incoming client request

    NETWORK1_MYSQL_SERVER="yes"

    NETWORK1_MYSQL_IN_SRC_IPADDR[0]=$ANY_IPADDR
    NETWORK1_MYSQL_IN_DST_IPADDR[0]="192.168.1.1"
In the above example, we enable MySQL incoming client request on our internal subnet (NETWORK1_MYSQL_SERVER="yes").

Next, we instruct the firewall that in our internal subnet (NETWORK1), all MySQL (MYSQL) incoming packets (IN) with source ip address (SRC_IPADDR) of any ip address ($ANY_IPADDR) and with destination ip address (DST_IPADDR) "192.168.1.1" will be allowed to come in and/or start a new connection.

In other terms, any incoming MySQL packets with any ip address as source ip address and with 192.168.1.1 as destination ip address will be allowed to come in and/or start a new connection. Using the connection tracking capability of iptables, the related MySQL outgoing packets are automatically allowed back out by the firewall. In this case, our machine from our internal subnet that has the ip address 192.168.1.1 is the MySQL server and it is allowed to receive requests from any MySQL client from the Internet.

NOTE: The MySQL client from the Internet thinks that it talks to our gateway, so the actual destination ip address of the packet is our external interface ip address ($INTERFACE1_IPADDR), but the packet is automatically DNATed to 192.168.1.1

NOTE: Make special attention to the above parameters. We remark that ip address "192.168.1.1" is used as a value for the incoming server request in forwarding feature. This is important and if your internal workstation ip address is different, you have to adjust the setting to fit your own ip address for each forwarding definitions.

Step 3
Now that our parameters for MySQL service have been correctly implemented into the GIPTables configuration file, we need to restart our GIPTables firewall for the changes to take effect.

To restart GIPTables on your system, use the following command:

[root@deep /]# /etc/init.d/giptables restart
Well, now we have some better idea about what these cryptic definitions do and how to change them to fit our needs depending of the type of firewall that we need for our server. Human error is inevitable and if we provide all additional parameters that we may need to enable a specific service with GIPTables by hand, we could in inadvertence make some errors. To avoid this risk, GIPTables provide through it /lib/giptables/conf/giptables.conf.README file all possible definition for all services available to use with it.

Therefore, if you have to add some additional services, which do not exist by default into the giptables.conf file you have chosen to run on your system, you can refer to this file to get the complete parameters to make your service run with GIPTables Firewall. All you'll need to do will be to cut and past the required lines into your GIPTables configuration file and set up each parameters by answering by "yes" or "no" to the questions.

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

powered by Linux
Copyright © 2002 Adrian Pascalau. All Rights Reserved.
All other logos and trademarks in this site are property of their respective owner.