• iptables básico
• Introducción a iptables
  • Que é IPTABLES?
  • Información básica
• Firewall uso “sinxelo”
  • iptables en archlinux
  • Ubuntu
  • Debian
  • Fedora a partires da 23
• Xestión iptables
  • As táboas do iptables
  • Chains (cadeas)
  • Regras
  • MÓDULOS
  • Editar regras
  • Información extra

iptables básico

Información sobre configuración das regras de filtrado de iptables.

Introducción a iptables

Que é IPTABLES?

É unha implementación no kernel de Netfilter, máis comunmente se soe referir a “Iptables” como o firewall de linux, posto que esta parte de netfilter é a encargada de filtrar as conexións, o resto de netfilter se encarga de outras cousas da rede como do NAT ou de redirixir portos.

Por iso a este artigo o chamo iptables, polo interés de filtrar as conexións “refinalas” para evitar que nos entre cousas que non queremos ou saian cousas que non nos interesa emitir pola rede.

Moita da info deste post a traduzo da wikiarch e aparte incluo cousas que penso, poden facilitar a comprensión de ese gran misterio linuxero que parece “Iptables” o cal pode confundir un tanto de primeiras e con razón, a xente coa que teño falado sobre iptables soe concidir na súa complexidade de configuración, ademáis por internet se pode ver cómo se intercambian regras de filtrado coma de cromos se tratase, o cal non está mal.

Pero se tes un rato libre, por qué non facer as túas propias regras que se adapten como unha “luva” ao que tí queres ? :)

Información básica

Por defecto moitas distros como poden ser archlinux (a que nos ocupa neste artigo) Debian e ubuntu, non filtran o tráfico con iptables salvo que se lle indique, esta cuestión non soe ser preocupante para o usuario de escritorio “común” xa que non quere dicir que esté aberto a todo tipo de vulnerabilidades, posto que normalmente non ten servizos abertos de cara a internet que poidan ser explotados, por iso na comunidade linuxera non salta a lebre con este tema.

Máis o usar iptables, pode axudarche a filtrar a túa rede de cousas que non queres, ou de que obteñan información sobre o teu equipo que poida facilitar unha aditoría do mesmo non solicitada que pode ter cómo resultado a identificación do teu equipo ou software e afinar así o tipo de exploits máis adecuados para o teu sistema.

Firewall uso “sinxelo”

Iptables soe ser algo difícil de tratar para o común d@s usuari@s, e é por elo que se poden atopar clientes gráficos que o configuren ou outros frontends que fan máis sinxela dita tarefa (en Fedora por exemplo temos o firewall-cmd , do que falei nun artigo que data dos tempos do Fedora 23).

Na wiki de arch podemos atopar información sobre algunhas destas solucións:

Arch wiki Firewalls#Console_frontends

Unha das opcións que máis me convencen é “UFW” (Uncomplicated FireWall) , que se usa dende a terminal, para máis info este artigo da wiki de arch o explica bastante ben:

Arch wiki Uncomplicated_Firewall

iptables en archlinux

Por defecto non ten normas de filtrado cando instalas o paquete iptables, que tampouco está instalado no sistema se non o instalas, cousa que se verá neste artigo.

Fonte: Arch wiki Iptables.

Ubuntu

“When you install Ubuntu, iptables is there, but it allows all traffic by default.”

fonte: help.ubuntu.com/community/IptablesHowTo.

Debian

“The default Debian installation comes with the program iptables(8), configured to allow all traffic. This section briefly explains the different programs to handle network traffic manually, as well as two sample scripts.”

Fonte: https://wiki.debian.org/DebianFirewall.

Fedora a partires da 23

Pola miña experiencia creo que mínimo a partir de fedora 23, tes o firewall-cmd do cal falei nun artigo anterior, bastante sinxelo de configurar polo que xa nin me molesto en buscar se ven activado o iptables en fedora por defecto, mínimo algo de firewall si que parece traer, polo menos na súa versión de servidor.

Xestión iptables

As táboas do iptables

Iptables consta de 5 táboas:

Nome:	Descripción:
RAW	Usada só para configurar paquetes que estén exentos de seguimento (tipo UDP por exemplo).
FILTER	A taboa por defecto, é donde soen declararse as normas do firewall.
NAT	Usada para o NAT “Network address translation” , para permitir forwarding. Por exemplo: para enlazar portos de máquinas da nosa rede interna coa rede externa.
MANGLE	Usada para manipulacións especiais dos paquetes.
SECURITY	Usada para as normas de acceso obligatorias, como por exemplo con SELinux.

Nos casos máis típicos soen usarse as de “FILTER” e “NAT”.

As outras táboas son para configuracións complexas que involucran múltiples enrutamentos e decisións de enrutado.

Chains (cadeas)

As táboas consisten en cadeas, estas son listas de regras que iptables segue en orde.

A taboa por defecto, FILTER, ten incorporadas 3 cadeas:

• INPUT.
• OUTPUT.
• FORWARD.

Que son activadas en diferentes puntos do proceso de filtrado de paquetes.

A taboa NAT inclue as cadeas:

• PREROUTING.
• POSTROUTING.
• OUTPUT.

Por defecto ningunha destas cadeas contén regras.

É cousa túa agregar as regras que buscas usar.

As cadeas teñen unha política por defecto que soe ser “ACCEPT”, pero pode ser reiniciada a “DROP”.

Se buscas asegurarte de que nada pasa a través do teu conxunto de regras é mellor bloquealas de inicio, para que vaia pasando polo resto de regras hasta que a de por defecto sexa aplicada.

As regras definidas polo usuario poden ser engadidas para facer conxuntos de regras máis eficientes e máis fácilmente modificables.

Regras

Cada paquete de rede que pase por iptables, sera filtrado comprobando múltiples regras:

• Estas son especificadas por múltiples condicións (regras) que debe cumprir, para que o paquete pase ou ben será descartado.
• Tamén debe ter un destino (Acción que se toma cando o paquete pasa tódalas condicións, se non se desbota o paquete “DROP”).

As cousas típicas nos que unha regra pode coincidir é:

• A interface pola que entrou o paquete (como eth… , wlp…, enp…, lo…).
• Qué tipo de paquete é (ICMP, TCP ou UDP).
• Ou no porto de destino do paquete.

Os destinos “TARGETS” son especificados usando a opción “-j” ou “-–jump”.

Os destinos “TARGETS” poden ser:

• Cadeas definidas polo usuario.
  Por exemplo: Se estas condicións coinciden, saltar as seguientes cadeas definidas polo usuario e continuar o procesado do paquete dende ahí.
• Un dos destinos “TARGETS” especiais incorporados no propio iptables.
• Ou unha extensión de destino “TARGET EXTENSION”.

Os destinos incorporados en ip tables son:

• ACCEPT.
• DROP.
• QUEUE.
• RETURN.

As extensións de desitno son por exemplo “REJECT” e “LOG”.

Se o destino “TARGET” é un destino incorporado en iptables (built-in target), e decidido inmediatamente e o procesamento do paquete na taboa actual é parado.

Se o destino “TARGET” é unha cadea definida polo usuario (user-defined) e o destino do paquete non está decidido por esta segunda cadea, será filtrado contra as regras restantes da cadea orixinal.

As extensións de destino (TARGET EXTENSION) poden estar rematando (como destinos incorporados “built-in targets”) ou NON rematar coma cadeas definidas polo usuario sendo Traversing chains / Ruta que tomaría o paquete polas cadeas.

En “man 8 iptables-extensions” podes ver máis detalles.

Un paquete de rede recibido en calquer interface, pasa polo propio control de tráfico das cadeas das taboas.

A primeira decisión de enrutamento envolve a decisión de se o destino final do paquete é a máquina local.

Neste caso o paquete seguiría a ruta das cadeas INPUT.

No caso de ser outro destino que non sexa a máquina local, o paquete sería procesado polas cadeas FORWARD.

Na que as seguintes decisións serían decidir por qué interface se manda o paquete.

Cada cadea na ruta de procesamento do paquete, cada regra sería procesada en orde e se ningunha coincide, se executa a corespondente acción de destino ou salto (TARJET/JUMP).

Os 3 destinos (TARJETS) comunmente usados son “ACCEPT”, “DROP”, e “SALTAR A CADEA DEFINIDA POLO USUARIO” (jump to a user-defined chain).

Mentres as cadeas por defecto poden ter políticas por defecto, as cadeas definidas polo usuario non poden.

Si cada regra a que o paquete salta (jump) faia ao proveer unha concidencia completa, o paquete é descartado de volta na cadela de chamada.

Se nalgún momento a búsqueda coincide cunha regra de “DROP TARGET”, o paquete é eliminado e non se realizará ningún procesamento adicional máis.

Se o paquete é aceptado cunha cadea “ACCEPT”, será aceptado en todo o conxuto de cadeas e non atravesará ningún conxuto de cadeas máis.

SEN ENBARGO, ten coidado pois o paquete seguirá atravesando tódalas outras cadeas en outras táboas no seu percorrido normal.

MÓDULOS

Hai moitos módulos que se poden usar para extender iptables, como connlimit, contrack, limit e recent. Estos módulos engaden un extra de funcionalidades para permitir complexas regras de filtrado. Configuración e uso

Iptables actualmente é un servizo de systemd e é iniciado polo mesmo. Hai que ter en conta que non se iniciará se non atopa o arquivo “/etc/iptables/iptables.rules”, este non é provisto polo paquete “iptables” de arch.

No caso de intentar inicialo sen configuralo previamente obteremos o seguinte erro:

# systemctl start iptables
Job for iptables.service failed because the control process exited with error code.
See "systemctl status iptables.service" and "journalctl -xe" for details.

Asi qué, para iniciar o servizo por primeira vez se pode facer unha das seguintes cousas:

Facer un arquivo de regras totalmente vacío:

# touch /etc/iptables/iptables.rules

ou copiar a prantilla “estándar” que non inclue ningúnha regra:

# cp /etc/iptables/empty.rules /etc/iptables/iptables.rules

logo executar o correspondente start, se fas despois un status verias algo así:

# systemctl start iptables
[root@<nome_host> iptables]# systemctl status iptables
● iptables.service - Packet Filtering Framework
   Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; vendor preset: disabled)
   Active: active (exited) since <data>; 5s ago
  Process: 4046 ExecStart=/usr/bin/iptables-restore /etc/iptables/iptables.rules (code=exited, status=0/SUCCESS)
 Main PID: 4046 (code=exited, status=0/SUCCESS)

<data> <nome_host> systemd[1]: Starting Packet Filtering Framework...
<data> <nome_host> systemd[1]: Started Packet Filtering Framework.

Para que systemd inicie o servizo do iptables despois de cada reinicio, hai que activalo con enabled:

# systemctl enable iptables
Created symlink /etc/systemd/system/multi-user.target.wants/iptables.service → /usr/lib/systemd/system/iptables.service.

Se comprobas o seu estado co seguinte comando podrás ver que de momento non estás a filtrar nada:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Editar regras

As regras poden ser editadas engadindo o final “-A” dunha regra a unha cadea.

Insertando “-I” podes especificar a posición da regra na cadea.

Con “-R” podes reemplazar unha regra existente, ou borrala con “-D”.

Primeiro de todo, o noso computador non é un router (a excepción de que sexa un router).

Salvo en caso de ter máquinas virtuáis (neste caso xa sería outra historia o do enrutamento, meternos en redes virtuais, etc…) polo xeral non nos interesa a política “FORWARD” (“Pasar os paquetes que nos den” como faría un enrutador, ou a nosa máquina física coas virtuais no caso de querer darlles acceso a outras redes fora da súa virtual).

Polo que unha boa recomendación da wiki arch, é a de cambiar a cadea “FORWARD” de “ACCEPT” (aceptar estas redireccións) a “DROP” (tirar estos paquetes) O cal axuda a que non usen o noso equipo para transmitir paquetes de rede de outros equipos, e evitar por exemplo que nos usen para “blanquear conexións” ou usar o noso equipo a modo de “proxy”, en definitiva evitar que nos “usen” de chivo expiatorio…

# iptables -P FORWARD DROP

Según o man de iptables:

   -P, --policy chain target
              Set the policy for the built-in (non-user-defined) chain to the given target.  The policy target must be either ACCEPT or DROP.

Acabo de aplicar a política, e de probar unha máquina con windows XP no virtualbox, non tiven problemas con navegar co firefox en dita máquina, poñendo a interface da máquina en NAT, ou BRIDGET.

Supoño que se tivera configurada unha interface NAT para as máquinas do virtualbox, no caso de seleccionar a opción “NAT NETWORK” quizás tivera algún problema co filtrado.

Nos dous casos colleu a ip por dhcp e se puxo a funcionar como un equipo máis da rede real.

Esta foi a info que recollín de iptables, executada antes e despois da proba:

[root@<equipo> ]# iptables -nvL
Chain INPUT (policy ACCEPT 1 packets, 32 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
[root@<equipo> ]# iptables -nvL
Chain INPUT (policy ACCEPT 7044 packets, 6688K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 5039 packets, 359K bytes)
 pkts bytes target     prot opt in     out     source               destination

Como se pode ver, recibín máis paquetes dos que enviei, foron duas simples búsquedas en google, e tamén o propio SO facendo as solicitudes de DHCP supoño.

Polo tanto, aplicar a norma de tirar os paquetes que hai que “pasar” a través de nós, eu creo que é algo recomendando, así cómo o creen na wiki de arch.

Bueno o resto de este post basado no da wiki de arch, ten unha advertencia e é que non se van a explicar unhas normas boas para a securicación dun servidor, para elo hai que ver este outro posto da wiki arch:

https://wiki.archlinux.org/index.php/Simple_stateful_firewall

Con isto remataría o básico de IPTABLES un filtro de paquetes de NETFILTER.

Se queres consellos “cromos” sobre regras a aplicar podes botarlle unha ollada ao enlace do “simple stateful firewall” que recomendan na wiki de Arch.

Eu seguramente faga un post co meu primer “cromo” ao respecto, e iso sí, que quede claro que chegado a este punto do meu post, todavía non estás a filtrar nada, salvo os paquetes FORWARD, pero nin tes bloqueados os portos, nin nada polo estilo, espero que che axudara a entender algo máis iptables.

Información extra

A continuación deixo uns “extras” que non merei oco onde metelos no post: Diferencia básica entre DROP e REJECT

DROP desestima o paquete e punto. (Como cando chama a casa un descoñecido, e simplemente non damos resposta, drop non ofrece ningún tipo de feedback.)

REJECT , desestima o paquete e informa ao trasmisor de que o rechaza (Como cando chaman a nosa casa e berramos como tolos iso de “Non mercamos libros!! :O” , sabrán que estamos en casa pero que non nos interesa, ofrecendo un feedback ao emisor). Reiniciando as regras de filtrado

Podes reiniciar e limpar iptables aos valores por defecto con estos comandos:

# iptables -F
# iptables -X
# iptables -t nat -F
# iptables -t nat -X
# iptables -t mangle -F
# iptables -t mangle -X
# iptables -t raw -F
# iptables -t raw -X
# iptables -t security -F
# iptables -t security -X
# iptables -P INPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P OUTPUT ACCEPT

Con “-F” sen argumentos, limpas todas as cadeas (chains) na taboa actual. Algo parecido con “-X” que borra todas as cadeas non estandar, vacías dunha taboa. As cadeas individuais poden ser limpadas ou borradas poñendo “-F” e “-X” seguido co nome da taboa como argumento.