Una de las características principales de un firewall es su capacidad para trabajar con estados, es decir, la capacidad de entender si un paquete pertenece o no a una conexión activa.
Trabajar con estados es vital para implementar firewalls seguros. El seguimiento de una conexión ( Connetion Tracking) mantiene información sobre una conexión activa, tal como ip origen y destino, puertos tcp o udp, etc. Proporcionan un método eficaz para determinar que paquetes pertenecen a una conexión o relacionada como veremos a continuación. Para el seguimiento de paquetes debemos utilizar -m state con las opciones que pertoque.
Podemos encontrar todo tipo de detalles en el la Web de http://www.iptables.info/en/connection-state.html
| NEW | The NEW state tells us that the packet is the first packet that we see. This means that the first packet that the conntrack module sees, within a specific connection, will be matched. For example, if we see a SYN packet and it is the first packet in a connection that we see, it will match. However, the packet may as well not be a SYN packet and still be considered NEW. This may lead to certain problems in some instances, but it may also be extremely helpful when we need to pick up lost connections from other firewalls, or when a connection has already timed out, but in reality is not closed. |
| ESTABLISHED | The ESTABLISHED state has seen traffic in both directions and will then continuously match those packets. ESTABLISHED connections are fairly easy to understand. The only requirement to get into an ESTABLISHED state is that one host sends a packet, and that it later on gets a reply from the other host. The NEW state will upon receipt of the reply packet to or through the firewall change to the ESTABLISHED state. ICMP reply messages can also be considered as ESTABLISHED, if we created a packet that in turn generated the reply ICMP message. |
| RELATED | The RELATED state is one of the more tricky states. A connection is considered RELATED when it is related to another already ESTABLISHED connection. What this means, is that for a connection to be considered as RELATED, we must first have a connection that is considered ESTABLISHED. The ESTABLISHED connection will then spawn a connection outside of the main connection. The newly spawned connection will then be considered RELATED, if the conntrack module is able to understand that it is RELATED. Some good examples of connections that can be considered as RELATED are the FTP-data connections that are considered RELATED to the FTP control port, and the DCC connections issued through IRC. This could be used to allow ICMP error messages, FTP transfers and DCC’s to work properly through the firewall. Do note that most TCP protocols and some UDP protocols that rely on this mechanism are quite complex and send connection information within the payload of the TCP or UDP data segments, and hence require special helper modules to be correctly understood. |
| INVALID | The INVALID state means that the packet can’t be identified or that it does not have any state. This may be due to several reasons, such as the system running out of memory or ICMP error messages that do not respond to any known connections. Generally, it is a good idea to DROP everything in this state. |
| UNTRACKED | This is the UNTRACKED state. In brief, if a packet is marked within the raw table with the NOTRACK target, then that packet will show up as UNTRACKED in the state machine. This also means that all RELATED connections will not be seen, so some caution must be taken when dealing with the UNTRACKED connections since the state machine will not be able to see related ICMP messages et cetera. |
En definitiva, entender los estados es entender el funcionamientos de los campos de FLAG dentro de la capa de transporte (conexiones TCP) tal como podemos ver en la imagen adjunta:
Para las conexiones UDP o ICMP, como no existe la capa 4 de transporte, se simula entendiendo que una conexión es nueva cuando no está registrada previamente en la tabla de conexiones.
Importante entender que las conexiones se gestionan con tiempos:
Los tiempos pueden variar en función de la distribución y sistema instalados.
Podemos utilizar las herramientas proporcionadas por The conntrack-tools user manual para poder realizar el seguimiento adecuado de las conexión. Depende de la versión se instala de una forma u otra. En la nuestra se hace de la siguiente manera:
¿Qué versión tengo de linux?
administrador@ubuntu:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial
Instalamos conntrack
sudo apt-get update sudo apt-get install conntrack
Podemos ver de una forma muy gráfica como conntrack nos permite ver el estado de todas las conexiones y sus estados…. Nos conectamos vía PuTTY a nuestra máquina Linux, y realizamos un simple nslookup. Vemos con conntrack -E en tiempo real el seguimiento de los paquetes.
Si estás diseñando un firewall que proteja tu red de intentos de acceso desde una red externa, deberíamos restringir los paquetes entrantes. NO podemos descartar todos, pues deben entrar aquellos que sean respuesta a una petición desde la red interna.
Podemos ver el anterior Post para ver como hemos aplicado estos conceptos:
https://mytcpip.com/2017/07/10/linux-firewall-completo-con-estados-1a-parte/
Seguimiento de conexiones especiales ftp, irc, Amanda, tftp
Para el seguimiento de diferentes tipos de paquetes, IPtables usa determinados modulos que tendremos que cargar manualmente si no lo están. Por ejemplo, para el seguimiento del protocolo ftp pasivo, tendremos que cargar el módulo ip_conntrack_ftp mediante la orden modprobe.
ftp pasivo
modprobe ip_conntrack_ftp modprobe ip_nat_ftp
Para conexiones IRC
modprobeip_conntrack_irc modprobe ip_nat_irc
Para Amanda
modprobe ip_conntrack_amanda modprobe ip_nat_amanda
Podemos ver en los siguientes ejemplos podemos ver como tratar las conexiones ftp tanto activas como pasivas.
# The following two rules allow the inbound FTP connection
iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
# The next 2 lines allow active ftp connections
iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT
# These last two rules allow for passive transfers
iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT