Bloquear IPs automáticamente

En la anterior entrada, Bloquear múltiples IPs eficientemente comentamos cómo poder emplear IPSet para crear listas de fácil acceso y que simplifiquen el proceso de bloqueo de IPs o rangos de IPs que no nos interesen. Esto simplifica mucho el trabajo de mantener un firewall, pero como se prometió al final de la entrada, existen páginas en la red que ofrecen un listado de IPs consideradas maliciosas y que sería un buen trabajo poder mantenerlas y bloquearlas. Un ejemplo es la web iblocklist, que ofrece listados de IPs de diferentes consideraciones y que podríamos emplear conjuntamente con IPSet para tener una mejor protección. Un ejemplo de esta unión sería poder bloquear todas aquellas IPs que se consideren que tienen presencia de la BotNet ZeuS, por ejemplo.

Esto es posible hacerlo y vamos a ver cómo.

Instalación

Lo primero que necesitamos es instalar las herramientas necesarias para manejar el listado que nos vamos a descargar.

shell> pip install iblocklist2ipset

Uso

Con el software instalado, ya podemos comenzar a generar las tablas que nos interesen para cargarlas en IPSet.

shell> iblocklist2ipset generate --ipset zeus \
"http://list.iblocklist.com/...archiveformat=gz" \
> /backup/zeus.list

Este comando generará un fichero, /backup/zeus.list, que tendrá todas aquellas IPs que se sabe que tienen la BotNet Zeus. Lógicamente, hay que actualizarlo cada cierto tiempo, pero de base la protección es bastante bueno, pues a día de hoy, por ejemplo, tiene más de 237k entradas. Lo cual, ya nos saca muchas probabilidades.

Ahora toca cargar el fichero como una tabla de IPSet, por lo que empleamos la opción de restore.

shell> ipset restore < /backup/zeus.list

Si cuando estás intentando cargar la nueva lista obtienes un fallo similar a este,

ipset v6.11: Error in line 1: Set cannot be created: set with the same name already exists

Es debido a que la lista que intentas cargar ya existe, por lo que tendrás que destruirla para poder cargarla nuevamente.

shell> ipset destroy zeus
shell> ipset restore < /backup/zeus.list

Con esta lista, ya puedes poner la regla de IPTables que consideres oportuna para manejarla.

Referencias

• iblocklist
• ipset netfilter

Leer más

Fail2ban: proteger servidor SSH

Fail2ban es una aplicación, escrita en Python, con la intención de prevenir la intrusión en nuestros sistemas por fuerza bruta. Para hacerlo, penaliza el bloqueo de conexiones remotas que intenten accesos por fuerza bruta. Trabaja conjuntamente con un sistema de firewall, por ejemplo IPTables y lo que realiza es una consulta constante de los ficheros de logs del sistema para detectar ataques de fuerza bruta. Si detecta uno, bloquea la IP por un tiempo limitado o permanentemente.

Actualmente Fail2ban tiene soporte de filtros para apache, ssh, qmail, vsftp, lighttp, postfix y courier mail. Cada uno de estos filtros es llamado "jail" y en realidad no es más que una tupla de filtro + acción.

Hoy, vamos a ver cómo proteger nuestro sistema de ataques por fuerza bruta a SSH con Fail2ban y para cambiar un poco las reglas, vamos a ver cómo hacerlo en un sistema CentOS.

Instalación

La instalación en CentOS es muy similar a la realizada en sistemas Debian, ya que ambos sistemas tienen el paquete disponible en sus repositorios. En el caso de CentOS, lo primero que debemos es instalar el repositorio EPEL.

shell> yum install epel-release

Y tras ello, ya podemos instalar Fail2ban.

shell> yum install fail2ban

Y nos garantizamos de que arranque al inicio del sistema,

shell> chkconfig fail2ban on

Configuración

Por defecto, Fail2ban trae la configuración de varios "jail" por defecto, que deberemos de eliminar o sobrescribir para tener el funcionamiento que nos interesa. El fichero de configuración a manejar es /etc/fail2ban/jail.conf y en él tenemos la sección [DEFAULT], que contiene los parámetros por defecto y genéricos y luego cada una de las tuplas de los servicios a monitorizar. Puesto que nos interesa tener el servicio SSH controlado, tenemos que definir el "jail" [ssh-iptables] y un ejemplo, puede ser el siguiente,

[DEFAULT]
ignoreip = 127.0.0.1 192.168.1.0/24
bantime = 86400
maxretry = 5
findtime = 600
mta = sendmail

[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=you@local.com, sender=ban@local.com]
logpath = /var/log/secure
maxretry = 3

Acorde con la configuración anteriormente descrita, si alguien intenta acceder más de 3 (maxretry) veces al servicio SSH en 10 minutos (findtime), la IP origen será automáticamente bloqueada por el servicio y estará bloqueada durante 1 día (bantime).

Con la configuración ya lista, lo que debemos es de arrancar el servicio.

shell> /etc/init.d/fail2ban restart

Prueba

Inicial

Lo primero es saber que el sistema está funcionando correctamente. Para ello existe el comando fail2ban-client que nos asegura que el servicio Fail2ban está iniciado y funcionando. Al llamarlo, la respuesta esperada si todo está correcto es la siguiente,

shell> fail2ban-client ping
Server replied: pong

Check Fail2ban Status

[ssh-iptables] emplea IPTables para realizar los bloqueos, por lo que, para comprobar su estado, lo podemos hacer directamente desde IPTables.

shell> iptables --list -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-SSH  tcp  --  0.0.0.0/0         0.0.0.0/0           tcp dpt:22 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-SSH (1 references)
target     prot opt source               destination         
DROP       all  --  172.16.0.92          0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Aunque también el propio Fail2ban tiene su propio status interno para saber el estado de una "jail".

shell> fail2ban-client status ssh-iptables
Status for the jail: ssh-iptables
|- filter
|  |- File list: /var/log/secure 
|  |- Currently failed: 0
|  `- Total failed: 0
`- action
   |- Currently banned: 1
   |  `- IP list: 172.16.0.92
   `- Total banned: 1

Desbloquear IP bloqueada

Si ahora nos interesa desbloquear una IP bloqueada, lo podemos hacer directamente desde IPTables,

shell> iptables -D fail2ban-SSH -s 172.16.0.92 -j DROP

Y desde el interfaz de Fail2ban sería...

shell> fail2ban-client set ssh-iptables unbanip 172.16.0.92

Leer más

Bloquear múltiples IPs eficientemente

Fijo que a muchos nos ha pasado que tengamos que bloquear un listado de IPs o rangos de red que están intentando atacar un servidor. La forma más sencilla y habitual de hacerlo, no es otra que emplear IPTables para realizar el trabajo. Algo similar a lo que sigue, para cada una de las IPs a bloquear,

shell> iptables -A INPUT -s 192.168.0.16 -p TCP -j DROP

O si lo necesitas hacer para una red,

shell> iptables -A INPUT -s 192.168.0.0/24 -p TCP -j DROP

Esto funciona perfectamente, pero si hay que repetir este paso para unas 1000 IPs/redes, quizás la forma de hacerlo ya no sea tan sencilla de aplicar, y mucho menos, tan gustosa de hacer. Para solucionar esto, IP Sets simplifica este proceso.

Qué es IP Sets

IP Sets es una feature del kernel de Linux que permite definir múltiples y diferentes IPs, redes, direcciones MAC o puertos y cargarlas desde IPTables. La ventaja es que para almacenarlas y usarlas emplea estructuras bitmap/hash, lo que lo hace muy eficiente en acceso. Esta es la principal ventaja, la otra es que puedes meter en dicha tabla miles de direcciones y cargarlas todas con una única regla de IPTables.

Instalación

Lo primero que vamos a ver es cómo instalar este software.

shell> apt-get install ipset

Uso

Tras la instalación del mismo, únicamente nos queda por crear la tabla que después cargaremos. Para ello, emplearemos el siguiente comando,

shell> ipset create bannet hash:ip

El primer argumento (bannet) es el nombre de la tabla que vamos a crear. El segundo (hash:ip) es el tipo de tabla a crear. Este tipo puede ser diferente según nuestros propósitos y puedes ver aquí todos los métodos soportados. En este caso, nos interesa un tipo hash:ip, ya que vamos a almacenar en ella un listado de IPs aisladas.

Con la tabla creada, ya sólo nos queda meterle las IPs que deseamos. Para ello, y este proceso sí que debe ser manual,

shell> ipset add bannet 1.1.1.1
shell> ipset add bannet 1.1.2.2
shell> ipset add bannet 1.1.3.3
shell> ipset add bannet 1.1.4.4

Y para ver un listado de las IPs introducidas,

shell> ipset list
Name: bannet
Type: hash:ip
Header: family inet hashsize 1024 maxelem 65536 
Size in memory: 16568
References: 0
Members:
1.1.3.3
1.1.4.4
1.1.2.2
1.1.1.1

Llegados a este punto, sólo nos queda cargar este IPSet en IPTables. Para hacerlo emplearemos la opción "-m set --match-set", quedando la regla tal que así,

shell> iptables -I INPUT -m set --match-set bannet src -p TCP -j DROP

Cómo veis, una única regla para manejar todas aquellas IPs bloqueadas.

Guardado y restauración

Las tablas creadas van a necesitar un mantenimiento, e IPSet está preparado para ofrecerlo, incorporando opciones de borrado, restauración, testeo, destrucción y un largo etcétera. Se recomienda leer la página man de IPSet. De todas formas, quizás una de las tareas más importantes sea la de guardar las reglas de un tabla, por tener un backup, y volver a restaurarlas en caso de necesidad.

Para hacer un backup de un conjunto de reglas,

shell> ipset save bannet > /backup/bannet.list

Para destruir un conjunto de las mismas,

shell> ipset destroy bannet

Y para restaurarlas, en caso de necesidad,

shell> ipset restore < /backup/bannet.list

En la próxima entrada veremos cómo aprovechas las listas disponibles en la red para mejorar la seguridad de nuestra red. Pero por el momento, quizás con esta opción, muchas de las reglas que tenéis en IPTables puedan ser reducidas de forma muy eficiente.

Referencias

• ipset netfilter

Leer más

Filtrar países con IPTables

Una de las cosas que más nos llama la atención a los administradores de sistemas, especialmente si tenéis acceso a equipos de Firewall es siempre la cantidad de ataques que se están recibiendo. Es cierto que la red no es un lugar cómodo ni pacífico. A los 5 minutos de conectar un equipo a una IP pública, éste ya comienza a recibir ataques. Nos guste o no, tenga lógica o no, la mayoría de los ataques a los equipos provienen de determinados países, llamémosle conflictivos, como puedes ser China, Rusia, etc. Por suerte para nosotros, GNU/Linux tiene un sistema de Firewall modular que permite añadir pequeñas mejoras. Hoy vamos a ver cómo filtrar los paquetes de determinados países gracias a xtables_addons.

xtables_addons es un sistema modular para el kernel que permite añadir funcionalidades sin parchear éste, gracias a la creación de módulos dinámicos (dkms), lo que evita tener que compilar y reiniciar el sistema. En determinadas distribuciones (Ubuntu y derivados) está disponible ya para instalación, mientras que en otras hay que compilarlos desde las fuentes. Puesto que el funcionamiento una vez instalado es el mismo, vamos a partir de una Ubuntu desde la que podamos simplificar la instalación.

shell> apt-get install xtables-addons-dkms

La instalación de este paquete llevará un poco de tiempo, puesto que crea los módulos para la versión del kernel que tengamos instalada. Gracias a dkms, si se actualiza el kernel, los módulos se volverán a reconstruir automáticamente. Una vez instalado xtables_addons, debemos instalar el paquete que simplifica la forma de procesar los paquetes de rangos de IPs de los países. Para ello,

shell> apt-get install libtext-csv-xs-perl

Ahora ya estamos listos para comenzar a trabajar y filtrar las conexiones entrantes o salientes de IPTables a determinados países. Lo primero será descargar las bases de datos de rangos IP de cada país. Para ello,

shell> cd /tmp
shell> /usr/lib/xtables-addons/xt_geoip_dl

Esto nos descargará dos ficheros, GeoIPv6.csv.gz y GeoIPCountryCSV.zip, que los procesará y dejará en el directorio actual un fichero más llamado GeoIPCountryWhois.csv, que es el que realmente nos va a interesar. Ahora tenemos que procesar este fichero .cvs para darle el formato adecuado y que xtables_addons e IPTables lo entiendan. Para hacer esto,

shell> mkdir -p /usr/share/xt_geoip/
shell> /usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip/ \
       GeoIPCountryWhois.csv
91027 entries total
    0 IPv6 ranges for A1 Anonymous Proxy
  102 IPv4 ranges for A1 Anonymous Proxy
    0 IPv6 ranges for A2 Satellite Provider
  425 IPv4 ranges for A2 Satellite Provider
    0 IPv6 ranges for AD Andorra
    8 IPv4 ranges for AD Andorra
    0 IPv6 ranges for AE United Arab Emirates
      ...
  485 IPv4 ranges for ZA South Africa
    0 IPv6 ranges for ZM Zambia
   43 IPv4 ranges for ZM Zambia
    0 IPv6 ranges for ZW Zimbabwe
   47 IPv4 ranges for ZW Zimbabwe

Llegados a este punto ya estamos listos para emplear el filtrado por países en IPTables. Lo único que debemos de hacer es emplear "-m geoip" y "--src-cc XX", siendo XX el código ISO del país (código ISO en Wikipedia).

Por ejemplo, para bloquear las conexiones entrantes desde IPs del rango de China (ISO CN), tendríamos que hacer algo como,

shell> iptables -A INPUT -m geoip --src-cc CN -j DROP

También se puede emplear este truco de geoip con las opciones habituales de IPTables,

shell> iptables -A INPUT \
       -p tcp -m tcp -m multiport --dports 80,443 \
       -m geoip --src-cc CN \
       -j DROP

Tras ello, podemos ver cómo quedaría nuestro Firewall configurado,

shell> iptables -L -n -v
Chain INPUT (policy ACCEPT 1644 packets, 2796K bytes)
pkts B target prot opt in out source    destination         
0    0 DROP   all  --  *  *   0.0.0.0/0 0.0.0.0/0 -m geoip --source-country CN
0    0 DROP   tcp  --  *  *   0.0.0.0/0 0.0.0.0/0 tcp multiport dports 80,443 -m ...

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

Chain OUTPUT (policy ACCEPT 1423 packets, 221K bytes)
pkts B target prot opt in out source destination

Leer más

Tracear reglas IPTables

En el mundo de las conexiones de red y de los filtros que IPTables puede hacer, hay veces que se nos puede escapar algún paquete y que no sepamos exactamente qué regla es la que está haciendo el comportamiento anómalo. Si esto pasa, depurarlo puede ser complejo y llegarnos a hacer perder bastante tiempo.

Todos los que alguna vez hemos tocado IPTables solemos usar en la opción de qué hacer con el paquete (-j), la cadena DROP, REJECT, ACCEPT, LOG, CONNMARK, y alguna más que otra más. Sin embargo, si bien es cierto, que por ejemplo LOG y CONNMARK pueden ayudar a depurar, no están pensadas exactamente para eso.

Entonces, ¿cómo seguimos un paquete a través de las reglas?

Pues bien, para hacer exactamente eso, tenemos la opción TRACE, que se carga al incluir el módulo ipt_LOG. Esta nueva regla se usa tal que así,

shell> iptables -A PREROUTING -t raw -p icmp -j TRACE

Y permite rastrear las reglas y tablas por las que pasa un paquete. El formato de salida:

TRACE: tablename:chainname:type:rulenum"

y toda la información queda depositada en syslog, para su posterior análisis. La única condición para habilitarlo es que se aplique sobre la tabla raw.

Desde mi punto de vista es una opción un tanto desconocida, pero muy útil si necesitas ver dónde te has equivocado en el filtrado de los paquetes, especialmente cuando estamos hablando de que IPTables está manejando un elevado número de reglas.

Para más información sobre el uso de TRACE, consultar el man de iptables.

La entrada Tracear reglas IPTables la puedes leer en Puppet Linux.

Leer más

IPTables, limitar número conexiones por IP

Aunque existen muchos trucos para limitar el número de conexiones por IP a un determinado servicio, cuando más a bajo nivel lo realicemos, mejor será el resultado. Si un paquete que debe ser "eliminado" sube a la capa de aplicación usará más recursos que si directamente lo eliminamos desde IPTables. Para ello, IPTables cuenta con el módulo connlimit, que limita el número máximo de conexiones que una IP puede establecer.

Se puede usar connlimit para limitar o mitigar el efecto de un ataque DDOS, y en general para limitar el número máximo de conexiones que una misma IP puede realizar a un equipo. Para hacer uso de este módulo, primeramente hay que cargarlo,

shell> modprobe xt_connlimit

Y a continuación escribir las reglas que hagan uso de dicho módulo.

shell> iptables -I INPUT -p tcp --syn --dport 80 \
       -m connlimit --connlimit-above 10 \
       -j DROP

En la regla anteriormente descrita se limita el número de conexiones de establecimiento (--syn) a 10 (--connlimit-above) por IP al servicio web (--dport). En caso de que una misma IP intente más de 10 conexiones simultáneas o en muy poco tiempo, el resto de conexiones que superen las 10 primeras será rechazadas.

Lógicamente connlimit trabaja también con IP's de entrada y de salida, así como con reglas más complejas de IPTables. La regla escrita únicamente sirve para demostrar el funcionamiento general.

La entrada IPTables, limitar número conexiones por IP la puedes leer en Puppet Linux.

Leer más

IPTables, filtrador MAC

En muchas ocasiones, dependiendo de la red en la que uno se encuentre una dirección IP no tiene por que pertenecer al mismo equipo. También, suplantar una dirección IP es más sencillo que suplantar una dirección MAC, así que hoy vamos a ver cómo crear filtro en IPTables mediente MAC.

La utilidad de este filtrado ya depende de cada uno, pero lo importante es saber que IPTables soporta MAC-filter.

Para poder establecer el filtro MAC es necesario conocer la MAC origen de la conexión. Lo mismo que la IP, pero con la MAC. Supongamos por lo tanto que MAC origen es 00:08:10:5a:ab:d7, para filtrarla como origen,

shell> iptables -A INPUT -p tcp --destination-port 22 \
       -m mac --mac-source 00:08:10:5a:ab:d7 \
       -j DROP

Y el resultado,

shell> iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source      destination         
DROP   tcp  --  0.0.0.0/0   0.0.0.0/0    tcp dpt:22 MAC 00:08:10:5a:ab:d7

La entrada IPTables, filtrador MAC la puedes leer en Puppet Linux.

Leer más

Bloquear tráfico P2P desde IPTables

Puede que en nuestra red no nos interese tener tráfico P2P, por motivos de rendimiento de la misma o simplemente por que es una red de empresa, en la que la gente debería de estar trabajando y no descargando cosas. Si bien es cierto que el P2P hoy en día se emplea para muchas cosas, puede darse el caso de que nos interese filtrarlo. En ese caso, vamos a ver cómo bloquear el tráfico con IPTables, algo que no suele ser trivial en la mayoría de los casos.

Para poder llevar a cabo esta tarea, vamos a hacer uso de xtables-addons, una pequeña extensión para IPTables que nos ayudará de forma efectiva a realizar la tarea. Algunas de estas extensiones todavía no fueron aprobadas para entrar a forma parte del kernel, otras quizás nunca lo serán. A nosotros nos interesa concretamente el módulo ipp2p (xt_ipp2p), que el es que facilita el filtrado del tráfico P2P.

Puesto que partimos de un sistema Debian, existe un paquete disponible en los repositorios que facilita la instalación de las xtables. También tenemos disponible el paquete con el código fuente, para poder compilarlo, en caso de que nos interesase. Lo primero, por lo tanto, instalar el software necesario.

shell> apt-get install xtables-addons-common

Al finalizar la instalación, simplemente simplemente tendremos que ver que estén correctamente cargadas y sean funcionales. Para ello,

shell> iptables -m ipp2p --help
...
ipp2p v0.10 match options:
  --edk    [tcp,udp]  All known eDonkey/eMule/Overnet packets
  --dc     [tcp]      All known Direct Connect packets
  --kazaa  [tcp,udp]  All known KaZaA packets
  --gnu    [tcp,udp]  All known Gnutella packets
  --bit    [tcp,udp]  All known BitTorrent packets
  --apple  [tcp]      All known AppleJuice packets
  --winmx  [tcp]      All known WinMX
  --soul   [tcp]      All known SoulSeek
  --ares   [tcp]      All known Ares
...

Si en la ayuda os aparece eso, es que el módulo ipp2p está cargado y es funcional. Como podéis observar, el tráfico P2P que detecta y permite filtrar es el típico, por lo que ésto tiene buena pinta...

Ahora toca ver cómo emplear estas reglas para ver si funcionan o no. El método de funcionamiento es el mismo de siempre con IPTables, la única diferencia es que vamos a añadir un match contra el módulo P2P que hemos instalado. Así que para bloquear todo el tráfico P2P, nos quedarían unas reglas tal que así,

shell> iptables -A FORWARD -p tcp -m ipp2p --edk -j DROP
shell> iptables -A FORWARD -p udp -m ipp2p --edk -j DROP
shell> iptables -A FORWARD -p tcp -m ipp2p --dc -j DROP
shell> iptables -A FORWARD -p tcp -m ipp2p --kazaa -j DROP
shell> iptables -A FORWARD -p udp -m ipp2p --kazaa -j DROP
shell> iptables -A FORWARD -p tcp -m ipp2p --gnu -j DROP
shell> iptables -A FORWARD -p udp -m ipp2p --gnu -j DROP
shell> iptables -A FORWARD -p tcp -m ipp2p --bit -j DROP
shell> iptables -A FORWARD -p udp -m ipp2p --bit -j DROP
shell> iptables -A FORWARD -p tcp -m ipp2p --apple -j DROP
shell> iptables -A FORWARD -p tcp -m ipp2p --winmx -j DROP
shell> iptables -A FORWARD -p tcp -m ipp2p --soul -j DROP
shell> iptables -A FORWARD -p tcp -m ipp2p --ares -j DROP

Más información: xtables-addons

La entrada Bloquear tráfico P2P desde IPTables la puedes leer en Puppet Linux.

Leer más

IPTables, estado del firewall

IPTables es el cortafuegos integrado en el kernel de GNU/Linux y vamos a ver en una serie de post's algunos de los usos más básicos hasta otros más avanzados para intentar comprender, mediante ejemplos las posibilidades de iptables.

Primeramente vamos a comprobar el estado de nuestro cortafuegos. Para ello, empleando el comando iptables, solicitaremos un listado de las reglas con las opciones:

• L -:- Lista las reglas.
• v -:- Muestra información más detallada, como la cantidad de paquetes tranferidos y los datos procesados por dicha regla (en K, M o G).
• n -:- Muestra la IP y puerto en formato numérico. No resuelve nombres, para ir más rápido.

Un ejemplo del comando en funcionamiento sería,

shell> iptables -L -n -v
Chain INPUT (policy ACCEPT 475K packets, 474M bytes)
pkts  bytes  target  prot  opt  in  out  source  destination

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

Chain OUTPUT (policy ACCEPT 378K packets, 67M bytes)
pkts  bytes  target  prot  opt  in  out  source  destination

Y si esto mismo se ejecuta en un equipo con reglas, el resultado:

shell> iptables -L -v -n
Chain INPUT (policy DROP 2297K packets, 304M bytes)
pkts  bytes target prot opt in   out  source          destination
6319  421K  ACCEPT tcp  --  *    *    145.12.29.19/30 0.0.0.0/0 tcp dpt:22
26506 6993K ACCEPT all  --  lo   *    0.0.0.0/0       0.0.0.0/0
1451K 91M   ACCEPT all  --  *    *    192.168.0.0/16  0.0.0.0/0
3626K 210M  ACCEPT all  --  *    *    172.17.0.0/16   0.0.0.0/0
919K  117M  ACCEPT all  --  *    *    0.0.0.0/0       0.0.0.0/0 tcp dpt:530

Chain FORWARD (policy DROP 610K packets, 38M bytes)
pkts  bytes target prot opt in   out  source          destination
496M  319G  ACCEPT all  --  *    *    0.0.0.0/0       0.0.0.0/0 state RELATED,ESTABLISHED
279   21506 ACCEPT all  --  eth0 eth1 0.0.0.0/0       192.168.11.5
0     0     ACCEPT all  --  eth0 eth1 192.168.1.2       0.0.0.0/0
0     0     LOG    all  --  *    *    192.168.4.0/24    192.168.1.0/24 limit: avg 100/min burst 10 LOG flags 0 level 4 prefix `FORWARD Packet dropped: '
0     0     REJECT all  --  eth0 eth1 0.0.0.0/0       192.168.15.5 reject-with icmp-port-unreachable
2130  2071K ACCEPT all  --  *    eth1 192.168.0.0/16    192.168.97.0/24
1140  121K  ACCEPT all  --  *    eth1 192.168.0.0/16  192.168.97.0/24
2     96    ACCEPT tcp  --  *    eth1 0.0.0.0/0       192.168.17.34 tcp dpt:2222

Chain OUTPUT (policy ACCEPT 36M packets, 3439M bytes)
pkts  bytes target prot opt in   out  source          destination
4740K 2307M ACCEPT all  --  *    *    0.0.0.0/0       0.0.0.0/0 state RELATED,ESTABLISHED

Leer más

IPTables, filtrar por usuario

Una de las cosas más sorprendentes de IPTables, el gran firewall de linux, es sin dudarlo su enorme versatilidad. Permite hacer prácticamente cualquier cosa que te imagines y muestra de ellos es que las reglas se pueden definir por usuario o grupo. Antes de seguir, vamos a aclarar que para la única tabla que puede hacer match con un uid de usuario o de grupo es la de salida (output) y siempre tendremos que emplear el uid o el gid y no los nombres. Es lógico pensar que a un usuario se le pueda bloquear la salida, pero no tan fácil de hacer ni entender la entrada. Lo que viene del puerto 80, puede ir para uno u otro usuario, pero no se sabe para cual. GNU/Linux es multiusuario.

Para crear una regla de IPTables que bloquee la salida de un usuario por ejemplo al puerto 22, podemos hacer algo tal que así,

shell> iptables -A OUTPUT \
-p tcp --dport 22 \
-m owner --uid-owner 1002 \
-j REJECT

Y para hacer lo mismo para un grupo,

shell> iptables -A OUTPUT \
-p tcp --dport 22 \
-m owner --gid-owner 810 \
-j REJECT

Si ahora probamos a establecer una conexión ssh con diferentes usuarios, veremos que al usuario con uid 1002 no le estará permitido.

root@shell> ssh 192.168.1.35
root@192.168.1.35's password:
Last login: Sun Oct 7 20:03:34 2012 from 192.168.1.33

root@shell> getent passwd
...
javier:x:1000:1000:Javier Terceiro:/home/javier:/bin/bash

javier@shell> ssh 192.168.1.35
ssh: connect to host 192.168.1.35 port 22: Connection refused

Leer más

IPTables, identificando líneas

La salida que vimos en el post anterior de IPTables la verdad es que sirve para saber las reglas que están establecidas, pero para referenciar a una de dichas reglas, la verdad es que la cosa se complica. Para solucionar este problema, simplemente incluimos la opción --line-numbers. Con ello conseguimos que aparezca un nuevo campo num que identifica la regla y que posteriormente podremos referenciar para hacer alusión a dicha regla.

shell> iptables -n -L -v --line-numbers

Un ejemplo de ejecución,

shell> iptables -n -L -v --line-numbers
Chain INPUT (policy DROP)
num target  prot opt source     destination
1   DROP    all  --  0.0.0.0/0  0.0.0.0/0  state INVALID
2   ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
3   ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0
4   ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0
Chain FORWARD (policy DROP)
num target  prot opt source     destination
1   ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0
2   DROP    all  --  0.0.0.0/0  0.0.0.0/0  state INVALID
3   ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
4   ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num target  prot opt source     destination

Leer más

SSH escuchando en 2 puertos diferentes

Hay veces que es necesario poner un servidor ssh a la escucha en dos puertos diferentes. Léase por ejemplo el caso de un servidor ssh en un equipo de DMZ que interesa que tenga el puerto ssh (por defecto el 22) disponible para la red interna, pero que permita en un puerto no habitual la escucha de ssh para la IP pública.

Después de un intento de realizarlo con IPtables,

shell> iptables -t nat -A PREROUTING \
                -i eth0 -p tcp --dport 2222 \
                -j REDIRECT --to-port 22

Con ello logramos que todo lo que llegue al puerto 2222 se vaya al puerto 22 (ssh), teniendo así un 'fake' de ssh en dos puertos. Sin embargo, la solución es más sencilla que esa y está en la simple ejecución de ssh con el parámetro Port del fichero de configuración duplicado, quedando tal que así

# What ports, IPs and protocols we listen for
Port 2222
Port 22
...

Tras un pequeño restart del servicio, ya estará ssh a la escucha en dos puertos.

shell> netstat -punta | grep ssh
tcp   0   0 0.0.0.0:22     0.0.0.0:*   LISTEN   28580/sshd
tcp   0   0 0.0.0.0:2222   0.0.0.0:*   LISTEN   28580/sshd

Leer más

kippo, port redirect

Alguna gente me ha preguntado, a razón del post de cómo instalar kippo, cómo poder poner a kippo en el puerto 22 (tradicionalmente ssh), ya que al tener que ejecutarlo como usuario sin privilegios no deja levantarlo en dicho puerto. La solución no está en ningún fake en el código, simplemente está un poco de empleo de iptables. Así que si por defecto está arrancado en el puerto 2222, únicamente

shell> iptables -t nat -A PREROUTING \
       -i eth0  -p tcp --dport 22 \
       -j REDIRECT --to-port 2222

Como por cierto, muy bien recomiendan en la documentación. Otra forma de hacerlo que también se recomienda desde la documentación de kippo es el empleo de authbind, un software que permite levantar servicios a usuarios sin privilegios en puertos inferiores al 1024, tradicionalmente sólo permitido a root. Este paquete está disponible en los repositorios oficiales de debian, por lo que resulta sencilla la instalación.

shell> apt-get install authbind

Una vez está instalado nos queda configurar el acceso como usuarios normales al puerto 22. Para ello creamos el fichero /etc/authbind/byport/22 y lo establecer del usuario que vaya a ejecutar el software kippo. En mi caso, javier.

shell> touch /etc/authbind/byport/22
shell> chown javier:javier /etc/authbind/byport/22
shell> chmod 777 /etc/authbind/byport/22

Una vez que lo tenemos, únicamente queda modificar el fichero start.sh y añadir al principio de la línea que llame a authbind, quedando tal que así,

#!/bin/sh

echo -n "Starting kippo in background..."
authbind --deep twistd -y kippo.tac -l log/kippo.log --pidfile kippo.pid

Y lógicamente en la configuración (kippo.cfg) cambiar el puerto de 2222 (puerto por defecto) al 22, puerto en el que ahora ya tenemos permisos.

...
ssh_port = 22
...

Leer más

Comandos interesantes, netstat-nat

Si estás manejando un firewalll bajo GNU/Linux, este post te interesa. Si tu equipo de firewall realizar conexiones NAT y DNAT, es decir, hace de router a Internet para una o varias LAN's, el comando netstat-nat te puede ser de mucha utilidad.

Primero lo vamos a instalar,

shell> apt-get install netstat-nat

netstat-nat ahora ofrece la posibilidad de ver las conexiones NAT que están pasando por nuestro equipo. De forma limpia y transparente podemos ver el origen y el destino de una conexión sin problema alguno. De la misma forma también podremos ver si una IP está saliendo através del NAT y hacia dónde o si una está entrando y hacia quién.

shell> netstat-nat -p tcp #filtro tcp
Proto  NATed Address      Destination Address             State 
tcp    10.10.103.2:51865  rsvd-casa-moneda-210.0.104:www  ESTABLISHED
tcp    10.10.103.6:60235  addons-star.zlb.phx.mozi:https  CLOSE      
tcp    10.10.103.7:1432   par08s10-in-f21.1e100.ne:https  ESTABLISHED
tcp    10.10.103.7:1998   213.216.147.161:www             ESTABLISHED
tcp    10.10.103.8:65295  cdn-87-248-221-253.yhnpar.lln:www  TIME_WAIT  
tcp    10.10.103.8:65263  147.128.60.178.static.mund:www  ESTABLISHED
tcp    10.10.103.8:65258  147.128.60.178.static.mund:www  ESTABLISHED
tcp    10.10.105.53:1267  r-199-59-148-9.twttr.com:www    ESTABLISHED
tcp    10.10.113.2:60333  sjc-not4.sjc.dropbox.com:www    ESTABLISHED
tcp    10.10.113.4:1831   cds177.par.llnw.net:www         ESTABLISHED

shell> netstat-nat -s 192.168.1.33 #filtro de origen
shell> netstat-nat -d 213.95.68.12 #filtro de destino

Para más información, man netstat-nat.

Leer más