Mostrando entradas con la etiqueta network. Mostrar todas las entradas
Mostrando entradas con la etiqueta network. Mostrar todas las entradas

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

Limitar velocidad de descarga para APT

Con los nuevos métodos de trabajo que se están implantando en entornos grandes, cada vez resulta más necesario tener un método de control que limite ciertos problemas de colapso de red. Uno de ellos es la instalación/actualización de paquetes en los servidores. Imaginaros que tenemos una red de 100 ordenadores con Debian/Ubuntu y decidimos instalar un nuevo paquete en todos. Herramientas como salt stack  hacen esta trabajo realmente sencillo y rápido,
shell> salt -G 'os:Debian' pkg.install vim
y mandar a 100 equipos descargar un mismo paquete en un mismo momento, puede provocar un colapso de red y ésta afectaría a todos los equipos y personas que estén en ella.
Para evitarlo, si empleamos herramientas de orquestación, por ejemplo para sistemas Debian, es muy recomendable configurar un máximo de velocidad de descarga desde los repositorios APT. Así evitaremos un sobre saturar de la red. Hacerlo es tan sencillo como crear el fichero /etc/apt/apt.conf.d/99limit con el siguiente contenido,
Acquire
{
   Queue-mode "access";
   http
   {
      Dl-Limit "25";
   };
};
Tras guardarlo, la próxima vez que empleemos apt, la velocidad de descarga se limitará a los kbs aquí establecidos (más o menos).
Leer más

IP de salida en Postfix

Seguimos hablando de Postfix y de variables de configuración que, según qué instalación, pueden ser interesantes. Hoy vamos a ver cómo indicarle al servidor de correo la IP para el correo de salida que debe emplear (variable smtp_bind_address). Por defecto, dicha variable no se suele configurar y es el propio servicio el que se encarga de salir por el interfaz que mejor le convenga. En caso de que teniendo un servidor con más de una IP de salida, nos interese que el correo salga por una concreta, simplemente con indicarlo en el fichero de configuración (/etc/postfix/main.cf) nos llegaría.
smtp_bind_address = 192.168.0.2
Una vez reiniciado Postfix, la salida de correos se producirá por dicha IP y, por lo tanto, por el interfaz en el que esté configurada.
Leer más

Soporte VLAN en Debian

El concepto VLAN se emplea para separar através de una misma red física, varias redes virtuales. Esta separación, aunque sencilla de entender, no es tan sencilla a nivel de red. Para dar soporte VLAN, el equipo que se quiere conectar a dicha VLAN, debe marcar aquellos paquetes que se envían por el interfaz de VLAN con el tag correspondiente. A mayores, los equipos intermedios deben también de soportar esta característica, aunque a día de hoy, esto no suele ser ya un problema.

Soporte a VLAN

En sistemas Debian, para añadir el soporte para manejar VLANs, únicamente requiere instalar el paquete vlan.
shell> apt-get install vlan
A continuación necesitamos cargar el módulo que da soporte a VLANs, 8021q.
shell> modprobe 8021q
Y puesto que nos interesa que cada vez que el equipo arranque, dicho soporte exista, hacemos que se cargue.
shell> echo 8021q >> /etc/modules

Creando VLAN

Con el soporte para VLAN añadido, crear una nueva VLAN en el sistema es tan simple como añadir la VLAN y crear el interfaz por el que dar salida a dicha VLAN.
shell> vconfig add eth0 700
shell> ifconfig eth0.700 10.100.10.77/24
Como se puede observar, la VLAN 700, tiene como interfaz asociado el eth0.700, el decir, el interfaz virtual 700. Con esto conseguimos que todos los paquetes que salgan por dicho interfaz se marquen con el tag 700.

Solución estática

Por supuesto, lo escrito hasta aquí hace únicamente que la VLAN esté presente en el sistema hasta que éste se reinicie. Si queremos que este nuevo interfaz quede presente, tendremos que añadirlo al fichero de interfaces, junto con su configuración.
auto eth0.700
iface eth0.700 inet static
 address 10.100.10.77
 netmask 255.255.255.0

Borrando VLAN

Si llegado el momento, por lo que sea debemos de borrar una VLAN, vconfig tiene también forma de hacerlo,
shell> vconfig rem eth0.700
Leer más

Limitando ancho de banda con wondershaper

Hace tiempo hablamos en este blog sobre trickle, una herramienta que servía para controlar el ancho de banda que se consume. O dicho de otra forma, limitar la velocidad de subida o descarga de un equipo.
Lo bueno de GNU/Linux es su heterogeneidad, y hoy voy a comentar sobre wondershaper, un pequeño script (si bash script) que sirve para lo mismo, limitar el ancho de banda. Internamente wondershaper emplea la herramienta tc, que se comunica directamente con el kernel para gestionar el tráfico de red. La idea de emplear este tipo de herramientas es poder priorizar el tráfico en una red de equipos, dejando máxima prioridad para conexiones SSH y navegación web, por ejemplo, y bajando prioridad a  las descargas. Esto justamente es lo que se consigue con herramientas de control de tráfico (tc).
wondershaper lo que hace es abstraer la complejidad de tc y dejar un simple script para controlar el límite de ancho de banda de entrada y salida a un equipo por una interfaz. Así que vamos a ver un poco esta herramienta.

Instalación

wondershaper está disponible desde los repositorios oficiales,
shell> apt-get install wondershaper

Uso

El uso básico, donde nos muestra si hay algo activo y qué hace es únicamente pasándole el interfaz de red a controlar.
shell> wondershaper eth0.3

Limitar ancho de banda

Para limitar el ancho de bando que un interfaz de red puede consumir,
shell> wondershaper eth0.3 40 10
Donde pasamos el interfaz a controlar, el velocidad de descarga (40 kbps) y la velocidad de subida (10 kbps).

Comprobar limitaciones activas

shell> wondershaper eth0.3
qdisc cbq 1: root refcnt 2 rate 10000Kbit (bounded,isolated) prio no-transmit
 Sent 2020 bytes 12 pkt (dropped 0, overlimits 4 requeues 0) 
 backlog 0b 3p requeues 0 
  borrowed 0 overactions 0 avgidle 12500 undertime 0
qdisc sfq 10: parent 1:10 limit 127p quantum 1514b depth 127 divisor 1024 perturb 10sec 
 Sent 1170 bytes 11 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 234b 3p requeues 0 
...

Borrar limitaciones

shell> wondershaper clear eth0.3
Wondershaper queues have been cleared.
Una herramienta en esencia sencilla, pero que simplifica la creación de limitaciones de forma muy eficaz.
Leer más

Monitorizar señal WiFi

wavemon es una utilidad cuyo propósito es mostrar en tiempo real la calidad y la potencia de la señal WiFi a la que estamos conectados, así como una serie de estadísticas como el volumen de datos recibidos/enviados o la dirección MAC del dispositivo y otros muchos detalles.
Además, una de las cosas que más me gustan de este software es que es capaz de mostrar en una gráfica la calidad de señal a la que estás conectado, simplificándote así el mejor lugar dónde poner el punto de acceso para mejorar la comunicación, por ejemplo, en tu casa.

Instalación

wavemon está disponible en la mayoría de distribuciones, por lo que la instalación es sencilla,
shell> apt-get install wavemon

Ejecución

shell> wavemon -i wlan0
Tras ejecutar el comando en la consola, saldrá una ventana similar a la que se muestra a continuación. En ella hay 5 partes claramente diferenciadas.
  • Interface
    Indica el interfaz de red sobre el que estamos ejecutando el comando.
    Generalmente wlan0 para sistemas Linux.
  • Levels
    Indica la calidad y potencia del enlace1.
  • Statistics
    Muestra las estadísticas del enlace: paquetes enviados, recibidos, erróneos, etc.
  • Info
    Información acerca de la conexión (modo, MAC del AP, etc.).
  • Network
    Detalles de la tarjeta de red empleada (MAC e IP).

Todo el código del proyecto se almacena en github: wavemon

1 Cuanto mayor es el número negativo, mejor señal del enlace.
Leer más

Capturar tráfico HTTP

Aunque cualquier sniffer actual puede capturar el tráfico HTTP sin problemas, quizás el gran problema es que captura más cosas de las que suelen interesar. Aunque efectivamente existen filtros para que recoja únicamente lo que interesa, quizás opciones como tcpdumpwireshark sean más complejas que httpry, un software que únicamente sirve para capturar todo el tráfico HTTP, pero de forma muy organizada. Apoyándose en libpcap, misma librería que tcpdump, trae ya por defecto todos los códigos y protocolos del tráfico web, por lo que configurarlo resulta mucho más sencillo. Vamos a ver cómo funciona.

Instalación de httpry

httpry está disponible en las principales distribuciones GNU/Linux, por lo tanto para sistemas Debian y derivados...
shell> apt-get install httpry
Y para sistemas Red Hat y familiares,
shell> yum install httpry

Uso básico

Tras finalizar la instalación, la cual es realmente sencilla, ya podemos ponernos a jugar con la nueva herramienta. Lo único que necesitamos es indicarle sobre qué interfaz de red queremos que trabaje capturando el tráfico.
shell> httpry -i eth0
httpry version 0.1.7 -- HTTP logging and information retrieval tool
Copyright (c) 2005-2012 Jason Bittel jason.bittel@gmail.com
----------------------------
Hash buckets:       64
Nodes inserted:     10
Buckets in use:     10
Hash collisions:    0
Longest hash chain: 1
----------------------------
Starting capture on eth0 interface
2014-08-16 16:14:35   108.160.167.160  192.168.0.15    <  -    -  -  HTTP/1.1  200  OK
2014-08-16 16:14:35   192.168.0.15     108.160.167.160 >  GET  notify10.dropbox.com   /subscribe?host_int=
2014-08-16 16:14:48   192.168.0.15     173.194.41.250  >  GET  pagead2.googlesyndication.com... -
2014-08-16 16:14:48   173.194.41.250   192.168.0.15    <  -    -  -  HTTP/1.1  200  OK
2014-08-16 16:14:48   173.194.41.250   192.168.0.15    <  -    -  -  HTTP/1.1  200  OK
2014-08-16 16:15:03   192.168.0.15     173.194.34.252  >  GET  ad.doubleclick.net...
2014-08-16 16:15:03   173.194.34.252   192.168.0.15    <  -    -  -  HTTP/1.1  200  OK
...
Como se puede observar, desde el momento del arranque ya comienza a capturar tráfico HTTP y aparecen todas las peticiones que se hacen, así como el método que se emplea. Sale la IP origen de la conexión, así como la IP destino de la misma, seguida del método empleado y la URL completa que se envía o recibe.
Esto mismo lo podemos hacer con tcpdump o similares, pero la expresión necesaria para este filtro ya hace que quizás alguna persona se lo piense. Con httpry es muy sencillo.

Uso avanzado

Por supuesto, httpry permite hacer muchas cosas más. Algunas de las cuales vamos a ver a continuación, pero para saber todo su potencial os recomiendo la lectura de su página man.

Capturando métodos específicos

Los que sepáis del protocolo HTTP sabréis que existen multitud de métodos (POST, GET, HEAD, CONNECT, etc.) que éste tiene implementado. Algunos más vulnerables, otros menos. httpry nos permite definir qué método queremos que nos muestre, para así evitarnos tener que leer líneas que no nos van a ser de utilidad.
shell> httpry -i eth0 -m get,post

Captura a fichero para luego procesarlo

También, una de las utilidades más importantes es que la captura y el análisis de la misma no tiene por qué realizarse al mismo tiempo. Esta es una gran utilidad, puesto que nos permite almacenar todo el tráfico para su posterior análisis, con mucha más tranquilidad. Lo primero es, por supuesto, capturar el tráfico de red. Lo podemos hacer en formato binario (opción -b), o en formato texto (opción -o).
shell> httpry -i eth0 -b capture.dump
Una vez tengamos todo el tráfico capturado es hora de procesarlo. Para ello,
shell> httpry -r capture.dump

Esta entrada puede ser muy útil para análisis de tráfico, pero también para que mucha gente vea la facilidad con la que es posible capturar tráfico HTTP y leer lo que pasa por la red. Así que ya sabéis, no facilitéis tarjetas de crédito, contraseñas y demás datos de interés personal si, mínimo, no hay un https en la URL.
Leer más

arpWatch: Controlando los equipos de tu red

arpWatch es un daemon para sistemas GNU/Linux que nos permite de forma rápida tener un sistema de notificación de nuevos equipos conectados a la red. En realidad este pequeño daemon se dedica a observar el listado de correspondencias entre las entradas de la tabla arp y la dirección origen para comprobar su correspondencia. En el momento que un nuevo equipo es conectado a la red, automáticamente se notifica al administrador de ello vía correo electrónico.
arpwatch está en los repositorios de las principales distribuciones, por lo que su instalación resulta sencilla apoyándonos en las herramientas de los diferentes sistemas operativos (debian, red hat, etc.).
debian> apt-get install arpwatch
redhat> yum install arpwatch
Tras ello, y para ponerlo a funcionar, únicamente hay que editar el fichero de configuración (/etc/arpwatch.conf) e indicarle el interfaz de red que deseemos monitorizar, así como la red del mismo y también la dirección de correo electrónico a la que mandar los cambios detectados.
eth0   -m arpwatch@mi.dominio.com -n 192.168.0.0/24
eth1   -m arpwatch@mi.dominio.com -n 192.168.1.0/24
Efectivamente, arpwatch permite incluir varios interfaces de red que monitorizar. Una vez configurado, simplemente arrancamos el nuevo servicio,
shell> /etc/init.d/arpwatch start 
y comenzarán a llegar los correos de todos aquellos equipos accesibles en dicha red en ese momento. Un ejemplo del mail enviado sería,
hostname: backup.local.net
          ip address: 192.168.1.100
           interface: eth0
    ethernet address: 00:0f:51:XX:YY:ZZ
     ethernet vendor: Merit Li-Lin Ent.
           timestamp: Saturday, August 2, 2014 10:57:05 +0200
Hay que decir que en un primer momento enviará un correo por cada equipo que vaya detectando y a partir de ahí, únicamente los nuevos equipos que se conecten. Si la red es bastante estática, por ejemplo una intranet, estos cambios deben de ser mínimos y ante cualquier nuevo evento, habría que revisarlo, pues puede ser un equipo no autorizado.

arpwatch y cómo detectar ataques ARP Spoofing

Como ya dijimos, arpwatch se encarga de mantener un registro de la relación entre IP -> MAC junto a una marca temporal. Si dicho registro se altera, notifica de dicha alteración. Los ataques de ARP Spoofing se basan en el envío de falsos mensajes ARP (spoofed) con la finalidad de asociar una dirección MAC del atacante con una dirección IP.
En caso de intento de envenenamiento de la tabla arp, arpwatch notificaría de dichos cambios y aunque no permitiría detenerlos ni mitigarlo, sí cuando menos detectarlos.
Leer más

Comandos interesantes, iperf

En esta entrada del blog voy a explicar de forma breve cómo medir la velocidad de conexión entre dos equipos. Aunque en redes locales no suele ser un problema, en algunos cosas, especialmente en equipos virtualizados, la red puede ser un cuello de botella importante en los servidores, así que para comprobar y garantizar que esto no es así, qué mejor que asegurarse, pero con números. Para realizar estas comprobaciones vamos a emplear iperf, un  sencillo programa que sirve para medir el ancho de banda entre dos nodos. Aunque esta es la funcionalidad básica, es capaz de hacer más cosas, así que no dudéis en leer la ayuda.
Lo primero es instalar el software, tanto en el servidor como en un par de clientes, ya que para comprobar las velocidades, lo mejor es hacer varias pruebas.
shell> apt-get install iperf
Luego, arrancamos el servidor en el equipo que queramos medir su ancho de banda, tal que así.
shell> iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

Y desde cualquier de los clientes, lanzamos una conexión contra el servidor. Por cada conexión nos ofrecerá un report, ya que no hemos indicado nada de que nos lo deje en un fichero.
shell> iperf -c 192.168.1.101
------------------------------------------------------------
Client connecting to 192.168.1.1.1, TCP port 5001
TCP window size: 22.9 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.33 port 44888 connected with 192.168.1.101 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3] 0.0-10.0 sec   1.04 GBytes  892 Mbits/sec
Por defecto, el tiempo de conexión es de 10 segundos. Si lo queremos ampliar para ver cómo se comporta el equipo con más carga de red durante más tiempo,
shell> iperf -t40 -c 192.168.1.101
------------------------------------------------------------
Client connecting to 192.168.1.101, TCP port 5001
TCP window size: 22.9 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.33 port 45317 connected with 192.168.1.101 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3] 0.0-40.0 sec   4.22 GBytes  906 Mbits/sec
Por supuesto, si os interesa saber todas las opciones que están disponibles, aquí os dejo la ayuda.
shell> iperf --help
Usage: iperf [-s|-c host] [options]
       iperf [-h|--help] [-v|--version]

Client/Server:
  -f, --format    [kmKM] format to report: Kbits, Mbits, KBytes, MBytes
  -i, --interval  #      seconds between periodic bandwidth reports
  -l, --len       #[KM]  length of buffer to read or write (default 8 KB)
  -m, --print_mss        print TCP maximum segment size (MTU - TCP/IP header)
  -o, --output    file   output the report or error message to this specified file
  -p, --port      #      server port to listen on/connect to
  -u, --udp              use UDP rather than TCP
  -w, --window    #[KM]  TCP window size (socket buffer size)
  -B, --bind      host   bind to host, an interface or multicast address
  -C, --compatibility    for use with older versions does not sent extra msgs
  -M, --mss       #      set TCP maximum segment size (MTU - 40 bytes)
  -N, --nodelay          set TCP no delay, disabling Nagle's Algorithm
  -V, --IPv6Version      Set the domain to IPv6

Server specific:
  -s, --server           run in server mode
  -U, --single_udp       run in single threaded UDP mode
  -D, --daemon           run the server as a daemon

Client specific:
  -b, --bandwidth #[KM]  for UDP, bandwidth to send at in bits/sec
  -c, --client    host   run in client mode, connecting to host
  -d, --dualtest         Do a bidirectional test simultaneously
  -n, --num       #[KM]  number of bytes to transmit (instead of -t)
  -r, --tradeoff         Do a bidirectional test individually
  -t, --time      #      time in seconds to transmit for (default 10 secs)
  -F, --fileinput name   input the data to be transmitted from a file
  -I, --stdin            input the data to be transmitted from stdin
  -L, --listenport #     port to receive bidirectional tests back on
  -P, --parallel  #      number of parallel client threads to run
  -T, --ttl       #      time-to-live, for multicast (default 1)
  -Z, --linux-congestion set TCP congestion control algorithm (Linux only)

Miscellaneous:
  -x, --reportexclude [CDMSV] exclude Connec, Data, Multicast, Settings, Vserver
  -y, --reportstyle C         report as a Comma-Separated Values
  -h, --help                  print this message and quit
  -v, --version               print version information and quit
Espero que si os hace falta comprobar vuestra conexión de red, esta entrada os haya ayudado.
Leer más

Levantar red en inicio del sistema CentOS

Hoy Susi me preguntó por qué una máquina virtual con CentOS no levantaba automáticamente la red como el resto, máquinas Ubuntu. Lo cierto es que a mi esto mismo también me pasó en alguna instalación de CentOS sobre VirtualBox. No se por qué, pero durante la instalación el sistema decide que es mejor que el interfaz de red no se levante cuando la máquina arranca. Pero puesto que trabajando con máquinas virtuales para ofrecer servicios tener levantada la red es algo esencial, vamos a ver qué hacer para que el interfaz de red se levante cuando la máquina arranca.
CentOS tiene la configuración de las tarjetas de red por defecto bajo /etc/sysconfig/network-scripts y ahí, en un fichero de configuración ifcfg-iface, donde iface es el nombre dela tarjeta de red, por eejmplo eth0. Cuando instalas el sistema, si este detecta una tarjeta y se configuró, crea un fichero ifcfg-eth0, por ejemplo, con el siguiente contenido.
DEVICE="eth0"
BOOTPROTO="dhcp"
HWADDR="XX:XX:XX:XX:XX:XX"
NM_CONTROLLED="yes"
ONBOOT="no"
TYPE="Ethernet"
UUID="465985d0-ab5b-..."
El problema de que tras el reinicio del sistema el equipo no levante el interfaz de red radica en este fichero y concretamente en la variable
...
ONBOOT="no"
...
que como podemos observar indica que el interfaz no se levante por defecto en el arranque del sistema. Para solucionarlo, simplemente cambiamos el valor de la variable a yes,
...
ONBOOT="yes"
...
Y en el próximo reinicio ya no deberíamos de tener problemas.
Puesto que me parece algo interesante, mejor compartirlo con todos, pues no creo que nos pase únicamente a nosotros.
Leer más

Deshabilitar IPv6 en RedHat

¿Estás en una red con IPv6?

Si la respuesta es NO, entonces para qué sigues teniendo habilitado el soporte para IPv6.
La forma de deshabilitar dicho soporte en RedHat/Centos es tan simple como editar el fichero /etc/sysctl.conf y establecer a 1 las siguientes variables,
shell> vi /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
En caso de que éstas no existan, las creamos.
Una vez tengamos el fichero guardado, obligamos al sistema a volver a leer dicha configuración,
shell> sysctl -p
Con esto ya tenemos deshabilitado el soporte IPv6. Sencillo e rápido.
Los cambios son permanentes al reinicio, por lo que si vuelves a querer tener soporte IPv6, acuérdate de lo que tienes que tocar.

La entrada Deshabilitar IPv6 en RedHat la puedes leer en El mundo en bits.
Leer más

Comandos interesantes, netstat I

netstat es una herramienta de red que todo el mundo debería de conocer más o menos en profundidad. Aunque es simple de entender y de usar, la verdad es que nos puede dar una cantidad importante de información sobre el estado de la red en nuestro equipo.
Gracias a netstat se pueden imprimir desde estadísticas de red a tablas de rutas, pasando por todas aquellas conexiones de red activas que tiene el equipos. Aunque, por ejemplo, en sistemas GNU/Linux hay comandos específicos que hacen  dichas tareas de forma aislada, netstat es multiplataforma (Windows, Linux y MAC) y permite, variando las opciones, también extraer dicha información.
  • Estadísticas e interfaces
    shell> netstat -i
    Kernel Interface table
    Iface  MTU  Met  RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP...
    eth0  1500    0  10262      0      0      0  79922      0      0...
    lo    5536    0   1392      0      0      0  10392      0      0...
    
    El significado de cada una de estas columnas es el siguiente:
    • Iface: Representa el interfaz de red conocido por el sistema para el que se presentan las estadísticas.
    • MTU: Unidad Máxima de Transmisión que el interfaz puede enviar de una sola vez.
    • RX: Representan las estadísticas sobre los paquetes recibidos en el interfaz.
    • TX: Representan las estadísticas sobre los paquetes recibidos en el interfaz.
      • OK: Recibido/enviado correctamente
      • ERR: Recibido/enviado con error
      • DRP: Eliminado por que el buffer estaba lleno.
        Esto sucede si se envían/reciben muchos paquetes en muy poco tiempo.
      • OVR: Eliminado por que el paquete no pudo ser manejado por el kernel.
        Si hay paquetes aquí significa que la máquina tuvo mucha carga.
    • FLG: Flags activos en el interfaz. Pueden ser:
      • B: Presenta capacidad de broadcast
      • M: Presenta capacidad de multicast
      • L: Interfaz de loopback
      • U: UP/Activa
      • R: Running/Ejecutándose
  • Tabla de rutas
    shell> netstat -r
    Kernel IP routing table
    Destination      Gateway    Genmask Flags  MSS Window  irtt Iface
    default      192.168.0.1    0.0.0.0    UG    0      0     0 eth0
    10.0.0.15    *        255.255.255.0     U    0      0     0 eth0
    192.168.1.32 *        255.255.255.0     U    0      0     0 eth1
    
    Y a continuación una breve explicación de qué significa cada una de las columnas que componen la salida.
    • Destination: Indica el destino, o la ruta que cogerá este paquete. Cada vez que se envía un paquete se examina esta tabla y se decide por donde enviar el paquete con aquella ruta que cumpla la condición. En caso de que no haya una más específica, se envía por la 'ruta por defecto'.
    • Gateway: Indica a dónde mandar el paquete, o lo que es lo mismo, el siguiente salto del paquete.
      Un '*' significa que queda dentro de la misma red.
    • Genmask: Máscara de red.
    • Flags: Los flags que se van a aplicar.
      • U: UP
      • G: Gateway
      • H: Dirección de host completa.
    • MSS: Maximum Segment Size.
      Parámetro TCP usado para dividir los paquetes en partes más pequeñas, en caso de que el destino no sea capaz de trabajar con tamaños estándar.
      En la actualidad casi no se emplea y está prefijado a 0.
    • Window: Al igual que MSS, permite alterar un parámetro TCP Default Windows Size, que indica el número de paquete máximo a enviar antes de que uno de ellos sea de ACK.
    • irtt: Initial Round Trip Time.
      Lo puede usar el kernel para adivinar la mejor configuración de parámetros TCP.
    • Iface: Indica el interfaz por el que se envían los paquetes
Leer más

Cisco NO Password Recovery

Fijo que a muchos de los que me leen alguna vez se les pasó por la cabeza saber cómo proteger un router o switch de acceso físico. Si estos dispositivos no están perfectamente aislados, y dependiendo del modelo, el acceso a la consola puede ser bastante sencillo y por lo tanto, averiguar la configuración e incluso alterarla, más todavía.
Para evitar este tipo de problemas de acceso físico a los dispositivos, podemos establecer unas contraseña seguras, lo cual dificultará mucho que alguien acceda por la consola, pero como prácticamente todo aparato físico, existe un método de recuperación de contraseña, o "password recovery", lo cual puede ser un problema.
Los equipos Cisco tienen una opción, muy interesante para habilitar, que permite que en caso de que alguien intente resetear la contraseña se borre toda la configuración. Aunque puede resultar un método un poco drástico, es sin duda bastante eficaz, ya que conseguimos que nadie que no tenga acceso sepa la configuración de red del equipo. Para habilitarlo,
Switch# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)# no service password-recovery
Switch(config)# end

Switch# show version | include recovery
The password-recovery mechanism is disabled.

La entrada Cisco NO Password Recovery la puedes leer en Puppet Linux.
Leer más

Nmap idle-scan

Hoy os voy a hablar sobre una técnica de escaneo de puertos con nmap que intenta evitar el filtrado de firewall's. Es lo que se conoce como nmap idle-scan. idle-scan es el nombre con el que se conoce a la técnica de escaneo que haciendo uso de hosts zombies oculta completamente la IP origen del escaneo. No ofusca la IP origen de la conexión, sino que ni siquiera envía un sólo paquete al destino. Esta técnica es una de las mejores para saltarnos firewall's e IDS.
El funcionamiento de idle-scan es realmente una técnica compleja en cuanto a escaneos de puertos se refiere, pero se basa en las siguientes premisas (a groso modo):
  • Un sistema operativo escucha en determinados puertos TCP al igual que un servidor web escucha en el 80 o uno de correo en el 25.
  • Un puerto se considera abierto si un servicio está escuchando en dicho puerto, cerrado sino.
  • Para establecer una conexión a un puerto, se envía un paquete "SYN" al puerto. Si el puerto está abierto y a la escucha, enviará un "SYN/ACK", en caso contrario un "RST".
  • Una máquina que reciba un paquete "SYN/ACK" no solicitado responderá con un "RST". Un "RST" no solicitado será automáticamente ignorado.
  • Cada paquete IP tiene un número de identificación (identificación de fragmento). Muchos de los SO actuales incrementan este número por cada paquete que envían, por lo que la observación es este número puede indicar cuántos paquetes se enviaron desde la última conexión.
Realizando una combinación de todos las características anteriormente descritas es a nivel general en lo que se basa la técnica idle-scan, representada gráficamente a continuación.
nmap - idle-scan
Para poder usarlo tal como se muestra en la figura, debemos de seguir un par de sencillos pasos.
  1. Seleccionar un host 'zombie'
    Este host que debemos de seleccionar, para que la técnica funcione, debe tener el IPID incremental. Existen numerosas formas de averiguar si un equipo tiene o no el IPID incremental, una de ellas es directamente con el propio nmap (plugin ipidseq.nse). Otra es empleando metasploit. Para completar el ejemplo, vamos a emplear metasploit.
    shell> msfcli scanner/ip/ipidseq RHOSTS=192.168.0.0/24 E
    
    En ejecutar el comando anterior tardará un tiempo, así que sed pacientes. Cuando termine nos dará un listado de aquellos host's con el IPID incremental que haya en la red.
  2. Lanzar nmap
    Ahora que ya tenemos la víctima puente para poder lanzar el ataque y estar perfectamente camuflados, únicamente hay que lanzarlo.
    Vamos a suponer que el host zombie empleado sea el 192.168.0.201 y el equipo a escanear el 192.168.0.15. Si lanzamos un nmap directamente contra ese equipo, aparte de dejar rastros de la IP que hace el escaneo, puede que un posible firewall nos detecte e impida la conexión.
    shell> nmap -PN -P0 -p445 192.168.0.15
    PORT     STATE     SERVICE
    445/tcp  filtered  microsoft-ds
    
    Sin embargo, si empleamos el zombie, veremos los sigueinte,
    shell> nmap -PN -P0 -p445 -sI 192.168.0.201 192.168.0.15
    PORT     STATE     SERVICE
    445/tcp  open      microsoft-ds
    

¿Qué ventajas ofrece idle-scan?

  • Sigilo
    No se envía ningún paquete con la IP del atacante, por lo que su identidad está completamente a salvo.
  • Evasión
    Al no realizar ninguna conexión directa, tanto firewall como IDS tienen más difícil detectar como filtrar el escaneo. No existe una IP origen que bloquear, ya que puede que la IP "origen" sea un equipo de la propia red, el cual sí está permitido.
Más información sobre idle-scan en nmap.org

La entrada Nmap idle-scan la puede leer en Puppet Linux.
Leer más

Cambio de nombre del interfaz de red en GNU/Linux

El otro día la tarjeta de red integrada de la placa base de mi desktop dejó de dar señales de vida, por lo que para seguir conectado, tuve que adquirir una nueva. Tras el cambio y al encender mi sistema, Debian, la tarjeta de red ahora se llamaba eth2. Esto no me suponía ningún tipo de problema, pero la mayor parte del software que empleo, por defecto usa eth0 para operar y si quieres indicar otro interfaz de red, debes indicárselo manualmente (típica opción -i ethX). Como mi tarjeta eth0 estaba 100% muerta y no iba a volver, opté por cambiarle el nombre a eth2 y ponerle el de la anterior, para así tener un sistema sin cambios.
Debian, al igual que la mayoría de los sistemas Linux actuales emplean udev para controlar los dispositivos, por lo que la solución para cambiarle el nombre era ir al fichero de configuración (/etc/udev/rules.d/70-persistent-net.rules) y cambiar el nombre eth0 <-> eth2. Un pequeño cambio que tras un rápido reinicio, me permite volver a disfrutar de eth0 en mi sistema.
shell> ifconfig
eth0      Link encap:Ethernet  HWaddr 00:e0:4c:66:98:20  
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::2e0:4cff:fe66:9820/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:157686 errors:0 dropped:0 overruns:0 frame:0
          TX packets:163422 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:93148464 (88.8 MiB)  TX bytes:35958264 (34.2 MiB)
          Interrupt:20 Base address:0x2000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:110 errors:0 dropped:0 overruns:0 frame:0
          TX packets:110 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:11731 (11.4 KiB)  TX bytes:11731 (11.4 KiB)

Leer más

nmap, netbios scan hostname

Hay veces que por alguna razón, bien interés, bien por que estemos haciendo una auditoría de red, sabemos que hay un equipo, una IP, que tiene un servicio NETBIOS corriendo, pero de él todavía no sabemos el nombre.
Por suerte, nmap nos puede ayudar a averiguarlo de una forma bastante rápida,

shell> nmap -script smb-os-discovery.nse -p445 192.168.0.35

Starting Nmap 6.00 ( http://nmap.org ) at 2013-04-06 18:36 CEST
Nmap scan report for 192.168.0.35
Host is up (0.0022s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds

Host script results:
| smb-os-discovery: 
|  OS: Unix (Samba 3.5.6)
|  Computer name: samba
|  Domain name: domain.com
|  FQDN: samba.domain.com
|  NetBIOS computer name: 
|  NetBIOS domain name: HOME
|_ System time: 2013-04-06 18:36:08 UTC+2

Nmap done: 1 IP address (1 host up) scanned in 0.43 seconds

La entrada nmap, netbios scan hostname la puedes leer en El mundo en bits.
Leer más

hp, backup automático

En un post anterior explicamos cómo programar un pequeño script que se encargue de hacer el backup de los router's Enterasys. Hoy vamos a aplicar el mismo procedimiento, apoyándonos en expect, para realizar dicho proceso en equipamiento HP.
A mayores en este caso, vamos a pasar el nombre DNS o la IP del router al que conectarnos en línea de comandos, para así poder ejecutarlo contra varios equipos sin tener que alterar el código.
#!/usr/bin/expect -f

set router [lindex $argv 0]

spawn telnet "$router"
set timeout 60
match_max 100000
expect -exact "Password:"
send -- "my_passwd\n"
expect -- "#"
send "copy running-config tftp server.local $router.cfg unix\r"
expect -- "#"
send "exit\r"
expect -- ">"
send "exit\r"
expect -- "log out"
send "y\r"
send_user "\nSaliendo...\n"
Leer más

Copia de seguridad de routers Enterasys

Que la mejor forma de tener algo seguro es tenerlo apagado eso se sabe desde hace mucho tiempo. Sin embargo, si eso no es posible por que lo necesitas para trabajar en el día a día, como puede ser un router o un switch, tener un backup de la configuración es necesario e importante.
Así que si en tu empresa hay equipos Enterasys, el pequeño script que viene a continuación te puede interesar y mucho. Haciendo uso de expect, se conecta al equipo, se autentica, hace un backup y lo envía a un servidor tftp para que quede seguro.
#!/usr/bin/expect -f

spawn telnet router.local.net
match_max 100000
expect "Username:"
send -- "admin\n"
expect -exact "Password:"
send -- "YOUR_PASS\n"
expect -- "->"
send "delete configs/config.cfg\r"
expect -- "->"
send "show config outfile configs/config.cfg\r"
expect -- "->"
send "copy configs/config.cfg tftp://YOUR_TFTP_SERVER/config.cfg\r"
expect -- "->"
send "exit\r"
send_user "\nSaliendo...\n"
En caso de que algo le pase al equipo y tengamos que emplear una nuevo, ya tendremos de dónde sacar el estado de cada una de las bocas ;-)
Leer más

Uso avanzado de ifenslave

Hace ya un tiempo hablamos en este blog de cómo crear un bonding en Debian, o en cualquier otro sistema Linux, ya que el proceso es prácticamente el mismo. Lo primero que se citó fue la necesidad de instalar un paquete llamado ifenslave, que era el que daba soporte para la creación del bond.
A mayores, este paquete ofrece más alternativas que dar soporte para la creación del nuevo interfaz, sino que permite en tiempo real modificar un bond ya existente, pudiendo alterar su modo e incluso añadir o sacar interfaces de red.
A continuación veremos algunos de los usos y del potencial de dicho comando.
  • Creación de un bond en tiempo real
    Si necesitamos crear un bond en nuestra máquina, pero no nos interesa crear todos los ficheros de configuración ya que es para poco tiempo, podemos hacerlo tal que así:
    shell> modprobe bonding
    shell> ifconfig bond0 192.168.0.1 netmask 255.255.0.0
    shell> ifenslave bond0 eth1 eth2
    
  • Cambiar la tarjeta de red esclava
    Un bond (según la configuración) puede estar enviado todos los paquetes por un interfaz de red y tener el otro como slave, por si algo pasa. Si nos interesa cambiar el orden de los interfaces por algún motivo,
    shell> ifenslave -c bond0 eth2 eth1
    
  • Añadir una nueva tarjeta de red
    Para añadir una nueva tarjeta de red al sistema simplemente necesitamos indicar el bond al que irá y la interfaz a añadir. La tarjeta comenzará a trabajar según la configuración del bond.
    shell> ifenslave bond0 eth2
    
  • Sacar una tarjeta de red
    Puede ser que por algún motivo necesitemos sacar una tarjeta de red momentáneamente. Si este es el caso,
    shell> ifenslave -d bond0 eth2
Leer más

Cómo crear un bonding en Debian

Si estás trabajando con equipos de sobremesa únicamente, quizás este post no te sea de gran utilidad/ayuda, pero si trabajas con servidores, desde luego te interesa! En muchos casos accedes a un equipo y ves que aunque teniendo varias tarjetas de red, éste sólo está a emplear una (eth0, por ejemplo). Crear un bond entre varias tarjetas de red debería ser como emplear un RAID para el disco, algo casi 100% necesario. Si los datos son importantes, tenerlos disponibles también debe ser importarte.
Hay que recordar que poner las tarjetas de red en bond puede hacerse para conseguir mayor velocidad (emplear 2 tarjetas como una sola) o también para tener redundancia (si una tarjeta 'cae', la otra asumirá el trabajo). Por lo tanto, vamos a ver cómo conseguir hacer lo aquí descrito de forma muy sencilla en sistemas debian/ubuntu. Antes de comenzar, tenemos que instalar el software necesario,
shell> apt-get install ifenslave-2.6
A continuación, habrá que crear la definición de la tarjeta de red compartida, bond0, que por ejemplo una eth0 y eth1. Para ello, agregamos la siguiente configuración en /etc/network/interfaces:
auto bond0
iface bond0 inet static
   address 192.168.1.2
   netmask 255.255.255.0
   network 192.168.1.0
   broadcast 192.168.1.255
   gateway 192.168.1.1
   slaves eth0 eth1
   bond-mode balance-rr # mode 0
   bond-miimon 100
   bond-downdelay 200
   bond-updelay 200
Y a continuación levantamos el nuevo interfaz, con lo que debería automáticamente cargar el módulo del kernel con las opciones descritas.
shell> ifup bond0
En caso de que no se levante correctamente el interfaz por culpa del módulo del kernel, debemos crear un nuevo fichero bajo /etc/modprobe.d/ a que podremos llamar bonding.conf con el siguiente contenido,
alias bond0 bonding
   options bonding mode=0 miimon 100 downdelay 200 updelay 200
Las opciones que pasamos como parámetros son:
  • mode
    Representa el modo de funcionamiento del interfaz, según la siguiente tabla.
    Modo Tolerancia Balanceo Descripción
    0 [balance-rr] - Balanceo Round-Robin
    1 No [active-backup] - Backup Activo
    2 [balance-xor] - Según MAC
    3 No [broadcast]
    4 [802.3ad] - Crea grupos esclavos con la misma configuración
    5 [balance-tlb] - Transmit Load Balancing
    6 [balance-alb] - Adaptative Load Balancing (con una única MAC)
  • miimon
    Es la frecuencia de monitorización de los interfaces, en ms.
  • downdelay
    Tiempo en ms para dar de baja un link caído.
  • updelay
    Tiempo en ms para dar de alta un link caído.
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios