Title: Basic IPTABLES

iptables –policy INPUT DROP
iptables –policy OUTPUT DROP
iptables –policy FORWARD DROP

[INPUT]
iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp -m icmp –icmp-type 8 -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT

iptables -A INPUT -s 192.168.111.151 -d 192.168.111.158 -p tcp -m tcp –dport 80 -j ACCEPT
iptables -A INPUT -s 192.168.111.151 -d 192.168.111.158 -p tcp -m tcp –dport 22 -j ACCEPT

[OUTPUT]
iptables -A OUTPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p icmp -m icmp –icmp-type 8 -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT

iptables -A OUTPUT -s 192.168.111.158 -d 192.168.111.151 -p udp -m udp –dport 123 -j ACCEPT

iptables -A OUTPUT -s 192.168.111.158 -d 192.168.111.2 -j ACCEPT

To Open Passive FTP in iptable root login is require.

If you want to open port range from 30000:64000 then run the following command from shell.

iptables -A INPUT -p tcp -m tcp –dport 30000:64000 -j ACCEPT

Similarly you can open passive post range as per your requirement.

Należy dodać wpis do firewall, plik firewall najlepiej utworzyć w /etc/init.d/ (jeśli takowego nie mamy):

# touch /etc/init.d/firewall

i dodajemy wpis:, który odblokuje port dla ssh (22):

iptables -A INPUT -p tcp –dport 22 -j ACCEPT

następnie logujemy się na np. 192.168.1.1, po ‘-l’ podajemy login
$ ssh -l bialy 192.168.1.1

Wstęp

W wiekszości przypadków ludzie nie mający za wiele wspólnego z systemem Linuks interesują się nim w kontekście prostego serwera dostępowego do sieci Internet.
Nie potrzeba mieć jakiejś szczególnej wiedzy, aby zainstalować dzisiaj Linuksa. W sieci jest pełno dystrybucji przyjaznych dla użytkownika, posiadających konfiguratory i/lub automatycznie konfigurujących siec – to pięknie, ale czasem warto wiedzieć jak coś skonfigurować “z palca”.
Poniżej przedstawiam sposób, w jaki ja, na szybko, ustawiłbym serwer dostępowy.
Podany poniżej przepis działał będzie na pewno na debianie/ubuntu, powinien też działać na klonach RedHat (Centos,Whitebox,Fedora) oraz na większości innych dystrybucji.

Do dzieła

Po zainstalowaniu czystego systemu operacyjnego (najlepiej bez serwera X i innych zbędnych narzędzi) zalecam zaktualizowanie systemu do najnowszej wersji w ramach danego wydania, zainstalować swój ulubiony edytor tekstowy i przygotować się na trochę pisania na klawiaturze .

konfiguracja interfejsów

Aby nasz komputer mógł pracować jako serwer dostępowy do sieci Internet musi posiadać przynajmniej dwa interfejsy sieciowe. Dla celów opisowych przyjmiemy iż:

• eth0 – interfejs od strony sieci lokalnej, na której będzie nasłuchiwał serwer DHCP
• eth1 – interfejs od strony sieci Internet, skonfigurowany automatycznie przez DHCP

Interfejs eth1 jest konfigurowany automatycznie przez DHCP dostawcy Internetu (jak to ma miejsce w większości przypadków u lokalnych dostawców Internetu), ale nie niczemu nie przeszkadza, jeśli statycznie skonfigurujemy ten interfejs.
Konfiguracja interfejsów sieciowych w systemie ubuntu/debian znajduje się w pliku /etc/network/interfaces.
W tej chwili mój plik wygląda następująco:

auto lo
iface lo inet loopback

auto eth1
iface eth1 dhcp

auto eth0
iface eth0 inet static
address 1.1.1.1
netmask 255.255.255.0
network 1.1.1.0
broadcast 1.1.1.255

Interfejs eth1 jest konfigurowany automatycznie, ale można jego deklaracje skasować i ustawić podobnie do tej, z eth0 wypełniając odpowiednio parametry. Należy pamiętać, iż przy ustawianiu statycznym interfejsu od strony Internetu trzeba jeszcze wskazać w pliku /etc/resolv.conf.
Przykład pliku:

search domena.pl
nameserver x.x.x.x
nameserver x.x.x.x

Opcja search powoduje, że w momencie gdy będziemy chcieli odszukać w sieci komputer i nie będzie on możliwy do odnalezienia przy nazwie, która podaliśmy, to do tej nazwy doda domenę i tak zestawioną nazwę hosta postara się odnaleźć.

Parametr nameserver wskazuje adresy IP serwerów nazw dla naszego komputera. Warto je zapamiętać, bo potrzebne będą przy konfiguracji serwera DHCP (o ile nie posiadamy własnego serwera DNS).

Po zmianie w pliku interfaces wydajemy polecenie /etc/init.d/networking restart i aby wszystko sprawdzić, czy się zgadza ifconfig

Konfiguracja DHCP

DHCP służy do automatycznego konfigurowania komputerów w sieci. Przedstawiony tutaj przykład jest bardzo prosty, z samym serwerem DHCP można zrobić dużo, ale to nie jest temat na ten artykuł.
Instalujemy paczkę dhcp3-server za pomocą polecenia apt-get install, a następnie edytujemy dwa pliki.
/etc/default/dhcp3-server
W parametrze INTERFACES wpisujemy “eth0″, lub inny interfejs, na którym serwer DHCP na nasłuchiwać.

/etc/dhcp3/dhcpd.conf
Ustawiamy:

• option domain-name “twoja_domena”;
• option domain-name-servers x.x.x.x,y.y.y.y; – adresy ip serwerów DNS oddzielonych przecinkami

Usuwamy komentarz (znak ‘#’) z sekcji subnet i ustawiamy następująco:

subnet 1.1.1.0 netmask 255.255.255.0 {
range 1.1.1.2 1.1.1.200;
option routers 1.1.1.1;
}

Oczywiście możecie ustawić to w swoich plikach tak, aby odpowiadało waszym zakresom IP.
Parametr “range” wskazuje ile adresów IP będzie przydzielanych przez serwer DHCP, routers przekazuje komputerom klienckim adres IP routera.
Po wszystkich tych czynnościach przeładowujemy serwer DHCP /etc/init.d/dhcp3-server restart.
Jeśli będą wyświetlały się jakieś błędy zobaczcie do pliku konfiguracyjnego czy nie zapomnieliście gdzieś dać średnika ‘;’ lub czy wszystkie nawiasy są zamknięte. Konkretne miejsce znajdziecie w syslogu.

Konfiguracja NAT

NAT w Linuksie konfiguruje się za pomocą iptables.
Ja to robię w następujący sposób:
Tworzę plik o dowolnej nazwie w /etc/init.d i w nim podaję regułki firewall:

echo '1' > /proc/sys/net/ipv4/ip_forward
iptables -t nat -F
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE


pierwsza linia pozwala na przekazywanie pakietów między interfejsami, druga czyści łańcuch “nat”, trzecia ustawia maskowanie pakietów – tutaj podajemy nazwę interfejsu od strony Internetu.

Tak przygotowany plik ustawiamy jako wykonywujący (chmod +x nazwa_pliku) oraz linkujemy go do rcx.d (ln -s /etc/init.d/nazwa_pliku /etc/rc2.d/S99nazwapliku). Owe rcx.d jest odpowiedzialne za uruchamianie odpowiednich usług w zależności od trybu działania systemu (wykracza to poza zakres tego artykułu). Jeśli nie jesteście pewni to zlinkujcie ten plik do rc2.d, rc3.d i rc5.d.

Po restarcie systemu sprawdźcie, czy wszystko działa.

Este é um artigo explicando como colocar o suporte ao Layer7 no Debian Lenny e para isso precisaremos modificar tanto o pacote .deb do kernel quanto do iptables, porque ambos precisarão ter suporte à este. O Debian é uma distribuição GNU/Linux bem tradicionalista, muito estável, com excelente performance e com mais de 20.000 pacotes binários em seus repositórios oficiais.

Vamos precisar dos seguintes pacotes já pré-instalados para que não tenhamos erros na compilação dos pacotes:

# aptitude install fakeroot libncurses5-dev kernel-package dpkg-dev file gcc g++ libc6-dev make patch perl autoconf automake dh-make debhelper devscripts fakeroot gnupg g77 gpc xutils lintian quilt libtool libselinux1-dev linuxdoc-tools zlib1g-dev

Primeiramente vamos baixar o fonte do kernel, porque a partir dele vamos aplicar os patches que necessitamos e logo após geraremos novos pacotes .deb. Abaixo nós temos os comandos para baixarmos nosso fonte do kernel e logo após descompactarmos ele:

# cd /usr/src
# aptitude install linux-source-2.6.26
# tar -xvjpf linux-source-2.6.26.tar.bz2

Criaremos um link simbólico para facilitar nossa vida:

# ln -sf linux-source-2.6.26 linux

Agora baixaremos o Layer7 para aplicarmos no kernel e no iptables mais tarde. Para isso acessaremos http://sourceforge.net/projects/l7-filter/files/ e baixaremos o netfilter-layer7-v2.22.tar.gz em /usr/src. Logo em seguida descompactaremos nosso programa:

# cd /usr/src
# tar -xvzpf netfilter-layer7-v2.22.tar.gz

Agora que temos os arquivos necessários precisamos copiar o patch para o kernel e aplicá-lo. Como nosso kernel no Debian Lenny é o 2.6.26, então usaremos o patch para kernels de 2.6.25 à 2.6.28:

# cd netfilter-layer7-v2.22
# cp kernel-2.6.25-2.6.28-layer7-2.22.patch /usr/src/linux/
# cd /usr/src/linux
# patch -p1 < kernel-2.6.25-2.6.28-layer7-2.22.patch

Agora que aplicamos o patch no kernel, precisamos habilitá-lo antes de compilarmos nosso novo kernel:

# cp /boot/config-2.6.26-2-686 /usr/src/linux/.config
# make menuconfig

Siga o menu abaixo para habilitar o Layer7 no kernel:

Networking —> Networking options —> Network packet filtering framework (Netfilter) —> Core Netfilter Configuration —>
<M>   “layer7″ match support
[ ]     Layer 7 debugging output

Volte e saia salvando. Agora para gerarmos nosso novo kernel faremos os comandos abaixo:

# make-kpkg clean
# fakeroot make-kpkg –initrd –append-to-version=-custom kernel_image kernel_headers

Bem, nesse momento seria interessante uma pipoca e um bom filme, pois esse procedimento levará bastante tempo. Se tudo correr bem no final teremos o pacote .deb do kernel e instalaremos como abaixo:

# cd /usr/src
# dpkg -i linux-image-2.6.26-custom_2.6.26-custom-10.00.Custom_i386.deb

Agora que instalamos nosso novo kernel, precisamos apontar ele no /boot/grub/menu.lst alterando o parâmetro “default 0″ para o seu novo kernel. No meu caso aqui ficou “default 2″. Tendo feito isso, reinicie seu sistema e certifique-se de entrar com seu novo kernel. Após o boot, para ter certeza execute:

# uname -a
Linux debian 2.6.26-custom #1 SMP Mon Oct 19 17:36:31 BRST 2009 i686 GNU/Linux

Lá está nosso kernel custom carregado. Agora partiremos para o iptables.

Copiaremos xt_layer7.h do kernel para o lugar correto onde será usado na hora da compilação do iptables:

# cp /usr/src/linux-source-2.6.26/include/linux/netfilter/xt_layer7.h /usr/include/linux/netfilter/

Agora vamos instalar nosso fonte do iptables. Antes certifique-se que os repositórios de fontes estão habilitados no /etc/apt/sources.list:

# cat /etc/apt/sources.list

Para instalar o fonte do iptables façamos:

# cd /usr/src
# apt-get source iptables

Agora vamos copiar os arquivos necessários para que layer7 seja incorporado ao nosso iptables:

# cp /usr/src/netfilter-layer7-v2.22/for_older_iptables/iptables-1.4.1.1-for-kernel-2.6.20forward/* /usr/src/iptables-1.4.2/extensions

Bem, só precisamos gerar nosso novo pacote iptables e para isso façamos os procedimentos abaixo:

# cd /usr/src/iptables-1.4.2
# dpkg-buildpackage -rfakeroot

No final do comando acima teremos nosso pacote .deb do iptables e para instalá-lo façamos:

# cd /usr/src
# dpkg -i iptables_1.4.2-6_i386.deb

Isso vai nos gerar um problema, porque quando fizermos um “aptitude dist-upgrade”, por exemplo, o sistema vai querer atualizar o iptables com a versão oficial. Para que isso não ocorra criaremos, se não existir, o arquivo /etc/apt/preferences e colocaremos nele as seguintes linhas:

Para usarmos nosso novo sistema de filtragem Layer7 também precisaremos dos protocolos que iremos utilizar, que podem ser baixados do seguinte site:

• http://l7-filter.sourceforge.net/protocols

São os arquivos .pat e devem ser colocados em /etc/l7-protocols/. Esse diretório não vai existir, logo precisamos criá-lo:

# mkdir /etc/l7-protocols/

Agora vamos fazer um teste prático. Baixaremos o .pat do ssh:

# cd /etc/l7-protocols
# wget -c http://l7-filter.sourceforge.net/layer7-protocols/protocols/ssh.pat

Vamos carregar nosso módulo:

# modprobe xt_layer7

E agora a nossa regra para bloquear o protocolo “ssh”, mas o “telnet” na porta 22 funcionará. Estamos bloqueando o protocolo independente da sua porta.

Em nosso servidor fiz a regra abaixo que diz para bloquear qualquer ssh da estação 192.168.10.253 para ele:

# iptables -I INPUT -s 192.168.10.253 -m layer7 –l7proto ssh -j DROP

Da estação 192.168.10.253 fiz primeiro um telnet na porta 22 para mostrar que a regra permite o acesso:

# telnet 192.168.10.175 22
Trying 192.168.10.175…
Connected to 192.168.10.175.
Escape character is ‘^]’.
SSH-2.0-OpenSSH_5.1p1 Debian-5

Como podem ver a conexão fechou com o serviço ssh. Agora farei o ssh para o servidor:

# ssh 192.168.10.175
……

Não conecta porque o protocolo ssh está bloqueado. Funcionou perfeitamente!

Bem, espero ter ajudado.

Marcelo Gondim <gondim @ linuxinfo.com.br>

Eu encontrei no vivaolinux

olhem bem como unstable ja tem um pacote com os protocolos do l7 ok

O iptables é uma interface de configuração do netfilter, um firewall que funciona como um filtro de pacotes em sistemas Linux. Sua principal função é proteger a rede de ataques externos.

O netflter começou a ser implementado no kernel Línux a partir da versão 2.4. Você pode encontrar a documentação completa aqui .

O iptables trabalha com a seguinte configuração:

#iptables [-t tabela] [opção] [chain] [dados] -j [ação]

A tabela default é a tabela filter e contem as seguintes opções:

INPUT – todos os pacotes que entram no computador através para internet.
OUTPUT – todos os pacotes que o computador envia pela rede.
FORWARD – pacote que são encaminhado para outros computadores da rede.

Na figura abaixo é descrito o funcionamento do filtro do iptable:

Diagrama de funcionamento do iptables

Principais opções da tabela filter

-p –> Policy (política). É a politica do firewall, inicialmente esta configurada como ACCEPT para INPUT, OUTPUT e FOWARD, ou seja aceita qualquer pacote. Para negar o trafego de qual pacote deve usar a opções DROP.

-A –> Append (anexar). Acrescenta uma nova regra a tabela atual. A opção -A tem prioridade sobre a opção -p, por isso é normal negar todas entradas e saídas de pacotes da rede com DROP, e depois usar o -A para liberar pacotes específicos.

-L –> lista as regras atuais.

-D –> (Delete). Apaga uma regra. Pode usado apos tabela numero da linha

-F –> (Flush) – Apaga todas as regras, mas não altera a politica.

Dados:

-s –> source . Especifica a origem dos dados. pode ser um endereço IP.

-d –> (Destination) . ESpecifica o destino do pacote.

-p –> (Protocol) – Especifica o protocolo a ser filtado.

-i –> In interface – Especifica a interface de saída.

-o –> Out-Interface (interface de saída). Especifica a interface de saída. Similar a -i, inclusive nas flexibilidades. O -o não pode ser utilizado com a chain INPUT.

-! –> Exclusão. Utilizado com -s, -d, -p, -i, -o e outros, para excluir o argumento.

–sport –> Source Port. Porta de origem. Só funciona com as opções -p udp e -p tcp.

–dport –> Destination Port. Porta de destino. Só funciona com as opções -p udp e -p tcp.

Ações
As principais ações são:

ACCEPT –> Aceitar. Permite a passagem do pacote.

DROP –> Abandonar. Não permite a passagem do pacote, descartando-o. Não avisa a origem sobre o ocorrido.

REJECT –> Igual ao DROP, mas avisa a origem sobre o ocorrido (envia pacote icmp unreachable).

LOG –> Cria um log referente à regra, em /var/log/messages. Usar antes de outras ações.

If you’re using an OpenVPN Server to surf in Ubuntu, maybe you experienced this strange problem : you can connect but you cannot surf !    This how to fix it...

Before we start check your current IP online and save it.

The first thing you have to know is that you shouldn’t use NetworkManager Applet to configure your OpenVPN Connexion, it seems that there’s a problem with vpn connections when using this applet (atleast with Intrepid), you can connect but traffic isn’t redirected correctly, so let’s first make sure you’re correctly  connected ! The best thing to do is to download the configuration files from the OpenVPN Server’s website (just look in the forum if you don’t find it, it’s generally an archive file with a *.conf file and a *.crt file, this last one is the certificate) and use’em directly in a shell console.

Copy the archive content files to

/etc/openvpn/

Type :

cd /etc/openvpn && sudo openvpn yourserver.conf

Enter your login and password and wait till you see :

Initialization Sequence Completed

It means that you’re in.

Now to make sure that you’re not facing a routing problem, just type :

route -n

If you see tunX connections with new IPs, it’s OK you’re connected, if one of your web connected peripheral connections (ethX, athX…) is showing the IP of your OpenVPN Server as a destination you’re correctly routed.

Now try to ping the tunX IP with a gateway, if you’ve got this message :

ping: sendmsg: Operation not permitted

You got the fix ! It’s a SIMPLE FIREWALL PROBLEM !

To solve it, you have to edit :

/etc/firestarter/user-pre

First thing to do is to make it writable (it’s a read-only file) then paste these lines and save the file :

# Allow OpenVPN traffic
$IPT -A INPUT -i tun+ -j ACCEPT
$IPT -A OUTPUT -o tun+ -j ACCEPT

Restart Firestarter :

sudo /etc/init.d/firestarter restart

It should work now ! Just re-check your Online IP to see if it changed !

Para quem gostaria de estudar o tema, ai vai alguns link’s bem legais.

http://www.vivaolinux.com.br/artigo/Mecanismo-de-firewall-e-seus-conceitos
http://www.tchelinux.org/2009/cultura/slides/Iptables-Entenda.pdf
http://www.vivaolinux.com.br/artigo/Estrutura-do-Iptables/
http://www.vivaolinux.com.br/artigo/Estrutura-do-IPTables-2-a-tabela-nat/
http://www.vivaolinux.com.br/artigo/255.255.255.0-A-matematica-das-mascaras-de-rede/
http://www.vivaolinux.com.br/artigo/Seguranca-com-iptables-1/

IPTables with DMZ
Let consider the interface to setup/understand the DMZ.

• eth0: external interface (192.168.1.0/24)
• eth1: Internal Interface (10.0.0.0/8)
• eth2: The DMZ zone (172.16.0.0/16)

Step 1:
Create DNAT for all the servers in the DMZ zone (eth2) for accessing the service externally

If any request comes to firewall with the destination IP as 192.168.1.2 and port as 80 will be DNATed to 172.16.0.2 in DMZone.
Now test accessing the service in DMZone from Internel as well externel network. From both the network we will be able to access the server in the DMZone using the IP 192.168.1.2.

Step2:
Configure the split DNS or 2 DNS systems (Inside&Outside of the DMZone).
Step3:
Setup rule for trusted network from the outside network(Internet) for the traffic which will allow system access (SSH).

This will deny all access to the DMZone from the internet hosts, only allows the Internal network. Because the default policy of FORWARD chain is set to drop, we need to create the “state match” for the hosts in the DMZone(This will deny sourcing a new connection from the DMZone, only established connection will be permitted).

Dual DMZ Configuration
This is the way of segmenting the servers to separate DMZones.
Let consider the interface to setup/understand the Dual DMZ.

• eth0: externel interface (192.168.1.0/24)
• eth1: Internel Interface (10.0.0.0/8)
• eth2: The DMZ1 zone (172.16.0.0/16) (Web servers)
• eth3: The DMZ2 zone (172.17.0.0/16) (DBMS, App servers like JBOSS, TOMCAT etc)

Using this method we will be able to control the traffic from one DMZone to another. This is used for the scenarios of Application servers which need to contact the DB Servers located on separate server.

Here we have to permit only the DMZ1 to contact the DMZ2. all other traffic will be denied.So the servers in the DMZ2 zone will be more secured.

This will make only the DMZ1 to contact the DMZ2. And from DMZ2 only the established connection will be permitted. All other request will be dropped in the FORWARD chain.
Note:-
These rules are the basic backbone for setting up the routing and Natting in DMZone. All other rules should be defined according to our network need.

IPTables NAT
    Network Address Translation is the feature that makes Linux based firewall mostly in use. NAT is commonly used to masquerade the IP address

NAT CHAINS
    The NAT table contains 3 chains
1. PREROUTING
    The DNAT is defined in the PREROUTING chain. Using this we will make available of our internal service to external (Internet).i.e, from internet to lan (changes the packets before it routes to lan)
2. POSTROUTING
    This is responsible for MASQUERADE (dynamic SNAT) & SNAT. When packet needs to leave from one subnet(internel) through the linux firewall to another it traverse through POSTROUTING chain. (Changes the packet after it leaves the route from lan). eg:- MASQUERADE option is used in certain cases like, if ISP provides the DHCP address and the internel LAN needs to brows, then we have to masquerade all the request from the lan to the DHCP address provided by isp
3. OUTPUT
    Locally sourced/generated packets are subjected to NAT. Eg:- If the firewall has more than one IP address using this chain we can re-write the packets going out from this linux machine to a single IP.

TYPEs in NAT
    3 types of NATing is used.

• masquerade
• snat
• dnat

1. MASQUERADE
        This feature of NAT is used to dynamically masquerade all the internal address to the external IP

The following example will masquerade all the outgoing traffic to the externel bound IP of the firewall.

# iptables -t nat -A POSTROUTING -j MASQUERADE

Another example that masquerades all the traffic from network 10.0.0.0/8

# iptables -t nat -A POSTROUTING -j MASQUERADE -s 10.0.0.0/8

    This will masquerade all the request from the 10.0.0.0/8 subnet to the external ip of the firewall.
Test by enabling logging for nat and check the log file.

Masquerading Port:

#iptables -A POSTROUTING -t nat -p tcp -j MASQUERADE –to-ports 1024-10240

    This will masquerade all the ports to the range from 1024 to 10240. So when a external client makes connection to the internal server (for eg:- # telnet 22) then the port allocated to the client will be in between 1024 to 10240. As a result the internal system will be only able to source the port in range of 1024 to 10240.

2.SNAT    
        This feature of NAT is used to masquerade a particular internal ip adress to a given external address. Though SNAT and masquerading perform the same fundamental function, mapping one address space into another one, the details differ slightly. Most noticeably, masquerading chooses the source IP address for the outbound packet from the IP bound to the interface through which the packet will exit. i.e, SNAT permits 1-to-1 and/or 1-to-many mappings. It is used when we have a static public IP address.

This example will masquerade all the outgoing traffic from the subnet 10.0.0./8 to the ip 123.12.23.43.

# iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -j SNAT –to-source 12.34.56.78

or

# iptables -t nat -A POSTROUTING -j SNAT -s 10.0.0.0/8 –to-source 11.22.33.44

SNAT using multiple address:

# iptables -A POSTROUTING -p tcp -s 10.0.0.55  -j SNAT –to-source 192.168.1.100
# iptables -A POSTROUTING -p tcp -s 10.0.0.0/8 -j SNAT –to-source 192.168.1.200

    The first rule will nat all the traffic from source 10.0.0.55 to 192.168.1.100, and second rule states that all other traffic from the subnet 10.0.0.0/8 should be NATed to 192.168.1.200.
Test the functionality by enabling the LOG and use # netstat -ant

3.DNAT   
    This feature of NAT is used to translate the packet coming to a perticular destination.Destination NAT with netfilter is commonly used to publish or make available of a internal network service to a publicly accessible IP. The connection tracking mechanism of netfilter will ensure that subsequent packets exchanged in either direction (which can be identified as part of the existing DNAT connection) are also transformed.

In this following example, all packets arriving on the router with a destination of 10.10.20.99 will depart from the router with a destination of 10.10.14.2

# iptables -t nat -A PREROUTING -d 10.10.20.99 -j DNAT –to-destination 10.10.14.2

 Make the internal mail server available for external access.

# iptables -A PREROUTING -t nat -d mail.domain.com -p tcp –dport 25 -j DNAT –to-destination 192.168.1.25
# iptables -A PREROUTING -t nat -d mail.domain.com -p tcp –dport 110 -j DNAT –to-destination 192.168.1.25

    Here if any request comes to the ip of mail.domain.com with the destination port of 25 or 110, then IPTables will redirect (nat) to the internel address of 192.168.1.25.

Netmap TAGRGET in NAT:
    It is implemented in NAT table PREROUTING Chain. This is used to translate the one to one address from one subnet to another subnet.
For Eg:-
Consider we have one subnet 10.0.0.0/24. and we need to translate all the ip in this subnet equalent to 192.168.1.0/24

# iptables -A PREROUTING -t nat -s 10.0.0.0/24 -j NETMAP –to 192.168.1.0/24

    This will convert/rewrite all the packets coming from the subnet 10.0.0.0/24 to 192.168.1.0/24.
i.e, the request from the ip 10.0.0.1 will be masked as 192.168.1.1.

Well I needed to forward port 587 in my server so that Thunderbird installed in my local desktop could send mails through gmail account.
Here is how I did it.

iptables -I FORWARD -p tcp –dport 587 -j ACCEPT

What the above command does exactly is writes a (-I) inserts a new rule in the FORWARD chain which (-j) ACCEPTs all packets following (-p) tcp protocol and (–dport) destination port 587

IPTables Routing (Forward Chain)
           The Forward chain holds the rules that take care of routing
Enabling the Routing.

This is the key utilities which shows the running kernel parameters.

This will show the status of the IPV4 routing in our local system.

This will turn on the routing in kernel.

This will make the routing permanent.

This will make the net routing in Linux host.

Forward Chain to Manage the Routing.
     All the packets that is subjected to route will traverse through Forward Chain in a Linux router.

Defining the Forward chain policy
1. Initially make the default policy to Drop all the routing traffic in firewall

This will make all the routing traffic to be dropped as a default policy.
2. Specify only certain source network to be routed

This will allow the traffic from 192.168.1.0 network to 10.0.0.0. But the traffic from 10.0.0.0/8 network if comes back will not be accepted until & unless we define a state rule or a rule that allows the traffic from the given source.
or

This will allow and route all the new and established connection from the network 192.168.1.0 to any destination
3. Accept the return traffic

This will allow/accept all the established connection in the forward chain. This will allow the return traffic.
or define a rule that allows the return traffic from the network 10.0.0.0/8. Here usage of the “state” rule makes the definition of the firewall rule more easier and secure.

Logging the routing traffic in FORWARD Chain:

This will create a new chain and starts logging all the routing activities.

Allowing a subnet to access outer world web

Allow the UDP(DNS) queries to outside

IPTables

Included with Red Hat Enterprise Linux are advanced tools for network packet filtering — the process of controlling network packets as they enter, move through, and exit the network stack within the kernel. Kernel versions prior to 2.4 relied on ipchains for packet filtering and used lists of rules applied to packets at each step of the filtering process. The 2.4 kernel introduced iptables (also called netfilter), which is similar to ipchains but greatly expands the scope and control available for filtering network packets.

This chapter focuses on packet filtering basics, defines the differences between ipchains and iptables, explains various options available with iptables commands, and explains how filtering rules can be preserved between system reboots.

Packet Filtering

The Linux kernel uses the Netfilter facility to filter packets, allowing some of them to be received by or pass through the system while stopping others. This facility is built in to the Linux kernel, and has three built-in tables or rules lists, as follows:

• filter — The default table for handling network packets.
• nat — Used to alter packets that create a new connection and used for Network Address Translation (NAT).
• mangle — Used for specific types of packet alteration.

Each table has a group of built-in chains, which correspond to the actions performed on the packet by netfilter.

The built-in chains for the filter table are as follows:

• INPUT — Applies to network packets that are targeted for the host.

· OUTPUT — Applies to locally-generated network packets.

· FORWARD — Applies to network packets routed through the host.

The built-in chains for the mangle table are as follows:

·   INPUT — Alters network packets targeted for the host.

· OUTPUT — Alters locally-generated network packets before they are sent out.

· FORWARD — Alters network packets routed through the host.

· PREROUTING — Alters incoming network packets before they are routed.

· POSTROUTING — Alters network packets before they are sent out.

Every network packet received by or sent from a Linux system is subject to at least one table. However, a packet may be subjected to multiple rules within each table before emerging at the end of the chain. The structure and purpose of these rules may vary, but they usually seek to identify a packet coming from or going to a particular IP address, or set of addresses, when using a particular protocol and network service.

Differences Between IPTables and IPChains

Both ipchains and iptables use chains of rules that operate within the Linux kernel to filter packets based on matches with specified rules or rule sets. However, iptables offers a more extensible way of filtering packets, giving the administrator greater control without building undue complexity into the system.

You should be aware of the following significant differences between ipchains and iptables:

Using iptables, each filtered packet is processed using rules from only one chain rather than multiple chains.

For example, a FORWARD packet coming into a system using ipchains would have to go through the INPUT, FORWARD, and OUTPUT chains to continue to its destination. However, iptables only sends packets to the INPUT chain if they are destined for the local system, and only sends them to the OUTPUT chain if the local system generated the packets. It is therefore important to place the rule designed to catch a particular packet within the chain that actually handles the packet.

IPTables Targets(-j)
Commonly used targets are
1. ACCEPT
     Sends packtes to other rule or process

2. DROP
     Drops the packet silently. Remote machine will not be aware about what happend to the packet.

3. REJECT
     When the rule met an error msg is send to client.
Eg of Reject:-

# iptables -A INPUT -p icmp –icmp-type echo-request -j REJECT

This will reject all the echo request part with a msg icmp-port-unreachable. If we ping to the host we will get a destination host unreachable.

4. REDIRECT
     This is used to redirect a current traffic to a desired target. It is applied to PREROUTING chain of NAT table.
Eg:-

# iptables -t nat -A PREROUTING -p tcp –dport 3128 -j REDIRECT –to-port 80

     This will redirect all the trafic coming to the destination port 3128 to 80.

# iptables -L -n -t nat -v

     Test with the verbose mode to get the packet count which hits the rule.

5. LOG
     This allow us to log the traffic which meets the rules from the level of debug to emergency using syslog.

IPTable Logs:
     It relies upon the kernel(kern) facility in syslog. So have to setup the syslog for logging the iptables activities.

Setup Logging
     Primarily we enable the logging in IPTables
Enabling the Log for a chain

# iptables -I INPUT 1 -p tcp –dport 22 -j LOG

This will start logging for the traffic which meets the above rule.(Logs all the incoming ssh request.) The default level of logging is warning. The Log level corresponds to the syslog.

# iptables -L -n -v

Check any packets hits the log

# tail -f /var/log/messages

This is the default place where undefined facilities logs to.So we the kern facility has been logging to /var/log/messages.
Configure syslog to log iptables activity separately:
We will change the facility to log to a seperate file

# vi /etc/syslog.conf
kern.none /var/log/messeges
kern.* /var/log/firewall.log

This will stop the kern facility to log to /var/log/messeges and redirects all levels of logs to /var/log/firewall.log

# service syslog reload

This will restart the syslog daemon and creates the file /var/log/firewall.log.
Test the Logging information by creating the traffic to port 22 on host.

# tail -f /var/log/firewall.log

brief about the log format:-
time- syslog facility – interface that revived the tracfic- MAC address of the remote system- MAC address of the local system – SRC IP- DSTIP – ID=packet sequence number – SPT=source port – DPT=destination port etc

Note:-
Generally logging should be enabled for separate chains & a specific rule. A catch all log for all the traffic will grow the log file numerously.

Loging All trafic

# iptables -A INPUT -j LOG
# tail -f /var/log/firewall.log

This will Log all traffic destined to the local server(INPUT). This will log all the protocols

Log All except a perticular protocol from host 192.168.1.53

# iptables -I INPUT 1 -p tcp ! –dport 22 -src 192.168.1.53 -j LOG
# tail -f /var/log/firewall.log

This will log everything except traffic to destination port 22

Log Excluding Multiple port in single rule

# iptables -I INPUT 1 -m multiport -p tcp –dport !80,8080 -j LOG
# tail -f /var/log/firewall.log

This will log all traffic except packet destined to port 80 and 8080.

Log using separate chains
Now we will check how to create a separate chain in IPTables for logging activities.
Create a New chain

# iptables -N LOGGER

Create a reference in INPUT chain to new chain LOG

# iptables -I INPUT 1 -j LOGGER

Create the logging rule in chain LOG

# iptables -A LOGGER -m multiport -p tcp –dport 21,22,80,143,8080 -j LOG
# tail -f /var/log/firewall.log

This will start logging ports 21,22,80,143 & 8080.

Loging the ssh access to the console.
In iptables:
Create a New CHAIN

# iptables -N SSHLOG

Create a reference in INPUT chain to new chain SSHLOG

# iptables -I INPUT 1 -j SSHLOG

Create the loging rule in chain LOG

# iptables -A LOGGER -p tcp –dport 22 -j LOG

In syslog:

# vim /etc/syslog.conf
kern.* /dev/console
# service syslogd restart

This will start logging any ssh access to the console.

Prefixing Interesting Traffic with a Log Prefix(–log-prefix “log prefix”)

# iptables -A LOGGER -p tcp –dport 22 -j LOG –log-prefix “SSH Access Logs”

This will prefix the given string to the log. So it is easy to grep/awk the content from the log file.
Note:-
The Maximum prefix length is 29 characters.

Note:-
–log-level (debug to emer)
This will decide the level of log from debug to emergency level.

IPTables Statefullness(-m state –state):
    IPTables provide state fullness. The state full firewall is considered more secure than stateless firewall because of their connection tracking capability and their ability to determine whether or not the session is new,related, invalid or established. Based on this criteria we can create more powerfull rules.
State Module:

    This is the module that makes IPTables to behave as statefull. It is applicable for all the protocols (TCP/UDP/ICMP)
The states are:
NEW (The First SYN traffic)
ESTABLISHED
RELATED(SESSION/STATE)
INVALID
    When a user creates a TCP/UDP based session IPTables can follow the connection. Here IPTable will keep a track with SYN, ACK-SYN, ACK and labelled with NEW(for SYN), ESTABLISHED or RELATED (For all other subsequent connections).

Example:
Permit Host to Initialte the connection and deny other hosts from initiating traffic to our host.

End Result:
The host will be able to make all connections to out side(NEW & ESTABLISHED is allowed in OUTPUT chain).
All new connection coming to our system will be dropped(No NEW is defined in INPUT chain only  ESTABLISED as well the default rule of DROP) only allows the ESTABLISHED connections(Initiated by our host)

The details of the connection tracking will be stored in

    This file contains the status of all the established connections in the system for all protocols. The number of packets that transmitted, The
source and destination address, source and destination port etc.

IPTables Building Rules with Source, Destination of IP, MAC, Protocols & Port
   
    Here we will deal with the possibilities to match the traffic to define the rule, i.e, matching destination & source IP/MAC/PORT/PROTOCOL, Interfaces,Usage of Wildcards etc.

Matching the traffic based on Source and destination:
–src/-s/–source
–dst/-d/–destination
    These are the switches used to match the source and destination of the traffic. Widely used while rules created based on source and destination address
Eg:-
Blocking all the traffic from a source (192.168.1.200) (–src)

# iptables -A INPUT –src 192.168.1.200 -j DROP

    This Drops all the incoming traffic to out server from the Source 192.168.1.200. Here the match of source is used by “–src”.
Blocking all the traffic To a destination from our server (–dst)

# iptables -A OUTPUT –dst 192.168.1.200 -j DROP

    This Drops all the outgoing traffic in our server to 192.168.1.200. Here the match of destination is used by “–dst”.

Matching Based on Interface:
    It is useful while creating the rules based on a particular interface.
(-i eth0/eth1.. etc)
    switch “-i” is used to match the traffic with the interface to define the rule.
Eg:-
(-i eth1)

# iptables -A INPUT -i eth1 –src 192.168.1.200 -j DROP

    Any incoming traffic from the ip address on the interface eth1 will be dropped.

Negation rule:

# iptables -A INPUT -i eth1 –src !192.168.1.200 -j DROP

    This will Drop all the incoming traffic to the interface eth1 other than the IP 192.168.1.200. Only the incoming traffic from ip 192.168.1.200 will be accepted.

# iptables -A INPUT -i eth1 -j DROP

    This Drops all the incoming traffic on the interface eth1.

Wildcard for Matching all interfaces(eth+):
For eg:-
    IF we have more interfaces like eth0, eth1, eth2, eth3, eth4 etc and need to define a rule that matched all the interface, we can use the wild-card eth+ . eth+ will match all the interfaces starting with “eth”.
For Eg:-

# iptables -A INPUT -i eth+ -p tcp –dport 23 -j DROP

    This will drop all the incoming telnet traffic to all interfaces, which starts with eth.

TCP Based Matching (–protocol/-p): (Connection Oriented)
     Majority of the rules are based on TCP . TCP is on Transport Layer (layer 4).
-p tcp/ –protocol tcp
    This switch will make IPTables to initiate the tcp modules and allow/deny the tcp based traffic. This switch makes sense to IPTables about the three way handshake of TCP. The protocol type (tcp/udp) has to be specified while using the “-p” match.
–sport/–source-port
    Generally the –sport of TCP client will be greater than 1024, and it is generaly picked arbitrarily from greater than 1024. So usally we wont filter based on the source port for TCP based traffic until and unless we know exactly how a application behaves.
–dport/–destination-port
    This is the common match that used along with the “-p” switch. Each and every TCP connection will have a well defined destination port. so based on this destination port we created/matched the rule.
–tcp-flags SYN, ACK SYN, ACK, FIN
    This is used to match the three way handshake of the tcp protocols.
    SYN – Step 1 of Three way Handshake (Initial synchronization) (From Server)
    ACK SYN – Step 2 of three way Handshake (To Acknowledge that the SYN has recieved) (From Client)
    ACK – Step 3 of Three way HandShake(From Server)
    FIN (Finishing a TCP Session)
Eg:-

# iptables -A INPUT -p tcp –dport 23 -j DROP

    Here Match is made with the protocol TCP having the destination port of 23. So all the incoming traffic to telnet will be dropped.

# iptables -A OUTPUT -p tcp –dport 21 -j DROP

    This will Drop all the FTP outbound traffic(all request to ftp access from our server)

UDP Based Match: (Connection Less)
    Some of the UDP based applications are TFTP:69, Syslog:514, NTP:123, DHCP:67/68, DNS:53
-p udp/–protocol udp
–dport/–destination-port
–sport/–source-port
    In majority of the cases, the UDP based traffic having same source port as the destination port.Eg:- The NTP client packets has same destination-port and source-port as 123 in header.
Eg:-
If we are running the syslogd daemon we have to block all other traffic to the service other than the syslog server.

# iptables -A INPUT -p udp –dport 514 -s !192.168.1.3 -j DROP

    So here only the traffic from the host 192.168.1.3 with UDP:514 will be accepted and all other source will be denied. Here the match is made with the protocol UDP and –dport 514 along with the Source(-s) using Negation(!).

ICMP based traffic Match.
    This is designed to communicate the status information.
various types of ICMP:
    echo-request – PING (sends the request via output chains using echo-request to destination)
    echo-reply -   PONG (Remote system Recieves the echo-request and responds with an echo-reply (PONG))
-p icmp/–protocol icmp
    Here defines the protocol type
–icmp-type name/number of icmp type
    Here we specifies the ICMP-Types. It can be name or number.eg:- echo-reply, icmp-request etc.
To get the list of icmp types that supported by the IPTables

# iptables -p icmp –help

        Using this we can build the rules. The above command can be used for both the tcp and udp protocols

    # iptables -p tcp –help
    # iptables -p udp –help

Eg:-

# iptables -A INPUT -p icmp –icmp-type echo-reply -j DROP

    All the echo-reply from outside will be droped.
Rule to drop all the echo-request to our filrewall from all outbound destination.

# iptables -A INPUT -i eth1 -p icmp –icmp-type echo-request -j DROP

    This will disable all the echo-request from the outside interface. But from this server we will be able to ping to any other system because we have not doped any incoming echo-reply.

Multiport Matching in single rule (-m):
    This feature uses to match multiple ports in a single rule.
-m multiport
 Checking the Multiport module installation

# rpm -ql iptables |grep multiport
/lib/iptables/libipt_multiport.so

    This is the modlue responsible for multiport
Eg:-

# iptables -A INPUT -p tcp -m multiport –dport 21,23 -j DROP

    Here we defined the multiple ports in single rule.

Matching Layer 2 Traffic (MAC-address):
    The MAC address is least changable.
Checking the capability of iptables to match the Layer 2 traffic

# rpm -ql iptables |grep mac
/lib/iptables/libipt_mac.so

    This is the modlue responsible for mac address based rule.
-m mac
    This will tell iptables to consult the libipt_mac.so module for processing the rule
–mac-source
    Source MAC address. Same as the –src option in Layer 3 (IP Adress)
–mac-destination
    Destination MAC address. Same as the –dst option in Layer 3 (IP Address)
Eg:-

# iptables -A INPUT -p tcp -m mac –mac-source 00:09:8F:3E:10:3A -j DROP

    IF the source mac address is matched then the traffic will be DROPed.
Filtering based on Layer 2 (MAC Address) is more secure because the IP Address can easily be changed.

IPTables Chain Management

Listing all the chains in Table Filter

    It lists INPUT, FORWARD and OUTPUT chains and rules associated with. Each of the chains will have a default policy. i.e the default policy is accept the traffic in IPTables.

    It will list all the rules in the chain OUTPUT for the default table.

Listing all the chains in Table NAT.

     It contains the chains PREROUTING(will use NAT before routing occurred -destination nat-),  POSTROUTING(uses NAT to after the packets get routed  -source nat-) & OUTPUT (Reserved for packets that sourced locally that need the NAT)

Listing all the chains in Table Mangle.

    It contains chains INPUT,OUTPUT,FORWARD, PREROUTE & POSTROUTE. Mangle Table is the ANDing of Filter & NAT table.

To List the amount of traffic that processed by the a chain

    This will show the total amount of traffic in each chains. Even if there is no rule defined it shows the traffic in chains. This is because there is default rule of accept all in IPTables.

Determine the Line number of the rule in a chain

    This will show the line numbers column for all the chains.

Appending(-A) and Inserting(-I) rules to Chains

    We will  try to understand each chains with a real time scenario
Source (192.168.1.1)pings to -> destination (192.168.254)
    In this case the source sends a ICMP (echo-request) packet to 192.168.254 which pass across the OUTPUT chain in filter table. Once the request reaches the destination it responds with a echo-reply to the source 192.168.1.1 which pass across the INPUT chain in filter table.

Now we will create rule in source all traffic for SSH will be permitted and Telnet traffic will be denied
Appending a rule(-A):

    This will make the server to accept only the ssh based connection and telnet sessions wll be droped.
The append (-A) will add the rule to the last rule in the chain(to the end of the rule list in chain).

    This will list the newly added rule

Inserting a rule (-I):
We can insert the rule into a particular line number using this option. (Keep in mind the iptable checks the rule from above to bottom and once it matches the criteria it executes the rule).(We can even insert a same rule to the chain, creating a duplicate rule. IPTables doesn’t have a feature to detect the duplicate rules that have appended or inserted.

    Here we can see that the rule for dropping the telnet session has been added to first line in the chain. So IPTables will process the rule number 1 before it hitting the rule number 2.
Other examples:

    It inserts a rule to line number 2 in INPUT Chain for the table Filter,for Dropping all FTP traffic.

Deleting(-D) and Replacing(-R) Rules
Deleting a Rule:
Syntax for deleting the rule from the chain:
# iptables -D
# iptables -D
Type 1

    This will delete the 2nd rule in the chain INPUT.
Type 2

    This will delete the rule as mentioned . This need the exact match and in case of any duplicate rules the first match will be deleted.

Replacing Rules:
Syntax:
# iptables -R

    This will replace the existing rule from DROP to ACCEPT (we had previously denied the telnet access)

Flush(-F) rules and Zero counters (-Z)

Flush rules:
syntax:
# iptables -F

    This will flush all the rules in the chain INPUT.

    This will flush all the rules from all the chains in default Table. But the flusing will not zero the packet counters (iptables -L -v).

Zero Counters:
Syntax:
# iptables -Z

    This will reset the packet count for the chain INPUT

    This will reset all the chain packet counts in default table.

    This will reset the packet counter for the chain POSTROUTING for table nat.

User Defined Tables/Chains (Creating (-N) and Renaming (-E old new)):
    IPTables ships with 3 default tables which cannot be deleted.

Creating a New chain called INTRANET

    This will create a new chain called INTRANET in the filter table. This will create a chain with the default refereces as “0″. reference is the link towards the default chains(INPUT, OUTPUT & FORWARD).
Now we define the new chain INTRANET how to behave. i.e, which traffic should be this chain responsilbe for.

    This will tell IPTables that – In rule number 1, any trafic having the source network ID 192.168.1.0 should be contacted the chain INTRANET

    Here we can see that a new entry for the Chain is added into the Line number 1 stating that for all the packages having source address in the network 192.168.1.0/24 should jump to target chain INTRANET.

Now create the rules

    So when a packet comes with a source address in 192.168.1.0/24 with the destination port 23. The iptables will refer from the INPUT chain to the INTRANET chain and Then IPTables will start matching the rule. If the packet has the destitantion port 23 then it will DROP.

Note:-
    User defined chains must have unique names. Because it function has the target (-j).

Rename a Chain(-E):
    If we need to rename a user defined chain
Syntax:
# iptables -E

    This will rename the chain to SUBINTRANET. The iptables “will update the references as well”(The reference to the default chain).
Chain Policy (-P):
    It is usually “accept” in RedHat environment for all the chains in filter table. should be very careful while setting the chain default policy to DROP(Update the iptables to permit the appropriate access, else if we are using a remote session this may freez the access).
Syntax:
# iptables -P

    Check the “chain INPUT (policy DROP)” to verify.
Note:-
    Default DROP Policy may prevent typical TCP/UDP/ICMP communication.So a state matching rule should be added in case of such scenarios.

IPTABLES
    The integrated firewall feature in Linux Kernel is IPTables. Using IPTables can turn the Linux machine to a fully fledged firewall. Since the IPTable netfilter frame work is capacble to filter pretty much most of the level of OSI models & with in all the various field in TCP, UDP and ICMP packets it has a significant value in corporate enviornment to build the security.

OSI Models
    The Open System Interconnection Reference Model (OSI Reference Model or OSI Model) is an abstract description for layered communications and computer network protocol design. It was developed as part of the Open Systems Interconnection (OSI) initiative. In its most basic form, it divides network architecture into seven layers which, from top to bottom, are

•     Layer 1: Physical Layer
•     Layer 2: Data Link Layer
•     Layer 3: Network Layer
•     Layer 4: Transport Layer
•     Layer 5: Session Layer
•     Layer 6: Presentation Layer
•     Layer 7: Application Layer

some of the Protocols in each Layer are given below.
7. Application Layer
NNTP  · SIP  · SSI  · DNS  · FTP  · Gopher  · HTTP  · NFS  · NTP  · SMPP  · SMTP  · SNMP  · Telnet (more)
6. Presentation Layer
MIME  · XDR  · SSL  · TLS
5. Session Layer
Named Pipes  · NetBIOS  · SAP
4. Transport Layer
TCP  · UDP  · PPTP  · L2TP  · SCTP
3. Network Layer
IP  · ICMP  · IPsec  · IGMP
2. Data Link Layer
ARP  · CSLIP  · SLIP  · Frame relay  · ITU-T G.hn DLL
1. Physical Layer
RS-232  · V.35  · V.34  · I.430  · I.431  · T1  · E1  · Ethernet  · POTS  · SONET  · DSL  · 802.11a/b/g/n PHY  · ITU-T G.hn PHY
   
    IPTables is a front end user space tool to manage Netfilter in Linux kernel. IPTables functions primarily in the Transport (Layer4) and Network (Layer 3), even it can work in the DataLink layer too. IPTables can manage the ICMP .

Layer 4 -Transport- Focuses on Protocols & Ports (TCP/UDP & Ports(0-65535)). The ports are based on 16bit value
Layer 3 -Network- Focuses on Source & Destination (IP Address). The IP address is based on 32 bit value

Installing IPTables
         The package IPTables will be installed by default in most of the Linux distro.

# rpm -qa |grep -i IPTables

    Or download the Latest package of IPTables from http://www.netfiler.org

# rpm -ql iptables
    IPTables ships with many modules that provides the functionality of Masquerading, Rejecting, Mapping etc. The modules that installed can be found in /lib/iptables/*.so.

Checking the kernel for the support of the IPTables.

Find the area for “NETFILTER” in Kernel config file.

# uname -a

# vim /boot/config-

CONFIG_NETFILTER=y

    (y)This means the netfilter basic support has been integrated and compiled to the kernel.If (m) option is defined then this means the module can be loaded on the fly so here we need to check the iptables modules has been loaded by command “lsmod”.

Default Tables & Chains in IPTables
    There are 3 default tables which cannot be deleted. Each table contains chains and the rules are written to the chains
1. Mangle
    This allows to alter packets eg:- Type Of Service, Time To Live etc.
2. NAT
    Network Address Translation, This allows to change IP Address & Ports. Eg:- Source NAT / DST NAT etc
3. Filter
    Here we perform the Filtering the traffic (INPUT, OUTPUT & FORWARD). It works between Layer 3 & Layer 4.

Rule Syntax IPTables.

# /sbin/iptables   
commands are used in the following syntax:
    name of chain – action done to chain (Append/Incert or Replace)
    name of table – default it will append to filter table
    Layer 3 object – src or dst of ip address
    Layer 4 object – protocols & ports
    Jump/Target – if the above criteria meets the do this action

Example of iptables
Drop All the packages from a Host

# iptables -A INPUT -t filter -s 192.168.1.233    -j DROP

    This will Drop all the packages coming from the source 192.168.1.233.
Now Test by pinging to the destination host 192.168.1.233
     Here we have the OUTPUT chain opened and the rule is defined in INPUT chain. This means our system is able to send the packages to the destination and while the destination machines replies back we drop the packets.

Saving and Restoring the rules in IPTables

# iptables-save

    This will dump the rules to STDOUT(to the terminal). The output will be in the iptables default format.

# iptables-save > firewall-rules

    This will write the rule the file firewall-rules

# iptables-restore

    Default reads the rule from STDIN and loads in to the kernel.

# iptables-restore < firewall-rules

    This will restore the rule that saved in the file firewall-rules.

I do not use any GUI application to configure the network interfaces on my Linux machines. Instead, I simply edit the configuration files.

The simplest way, among many solutions found on the web, was to write a script that runs iptables with various command line switches.

So I wrote a simple script, /etc/network/if-up.d/iptables, as follows. Whenever a network interface is brought up, the scripts in /etc/network/if-up.d are executed.
If the file does not exist, you can create one.

#!/bin/sh

# Flushing all rules
iptables -F
iptables -X
# Setting default filter policy
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
# Block the use of http://www-proxy:3128
iptables -A OUTPUT -p tcp --dport 3128 -j DROP