Feeds:
Entradas
Comentarios

Posts Tagged ‘redes’

Aquí os dejo una presentación muy interesante sobre seguridad e IPv6. Dado que es el futuro de Internet (y así lleva siendo desde hace tantos años…), nos conviene ir preparándonos para lo que está por venir.

Hacking IPv6 Networks (PDF)

Se trata de una presentación del DEEPSEC 2011, que tuvo lugar el pasado mes de noviembre en Viena.

Read Full Post »

El chipset RTL8111/8168B de Realtek parece no llevarse demasiado bien con Linux.

Aún cuando la tarjeta es detectada, parece imposible establecer la conexión. La primera solución y más efectiva, por lo que parece, es deshabilitar la opción de Wake on LAN en la BIOS. Si la placa en cuestión no lo permite, o si necesitáis dicha funcionalidad, podéis acudir a la herramienta mii-tool.

$ sudo mii-tool –reset

Dado que el problema persiste al reiniciar, podemos añadir la siguiente línea al fichero “/etc/rc.local“:

/sbin/mii-tool –reset

En cualquier caso, el comportamiento sigue siendo raruno, pues tras invocar el comando anteriormente citado, la conexión funciona en modo 10baseT/Half… lo cual es francamente penoso.

Para averiguar qué tipo de conexión soporta vuestra tarjeta, así como los modos habilitados, acudimos a la herramienta ethtool.

ramiro@cormanthor:~$ sudo ethtool eth0
Settings for eth0:
    Supported ports: [ MII ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Speed: 100Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 1
    Transceiver: external
    Auto-negotiation: on
    Supports Wake-on: g
    Wake-on: d
    Link detected: yes
ramiro@cormanthor:~$

Al intentar modificar la velocidad de conexión a 100baseT (ethtool -s eth0 speed 100), la tarjeta se vuelve a quedar en estado catatónico y sin conexión. He leído por ahí algunas supuestas soluciones, pero casi todas terminan acudiendo a parches del kernel e incomodidades equivalentes.

Como solución temporal, y si no es un problema estar conectado a 10 Mbps, invocar mii-tool en el rc.local hace el apaño.

Read Full Post »

Todo el que se haya pegado mínimamente con las redes, sabrá la utilidad del comando traceroute (tracert en Windows).

El programa MTR (inicialmente Matt’s traceroute, hoy en día My traceroute) es una vuelta de tuerca sobre el mismo concepto, pero combinándolo con el ping de toda la vida, y llevando a cabo un muestreo sobre el tiempo. El resultado es la capacidad de obtención de ciertas métricas de la red, incluyendo porcentaje de pérdida de paquetes, así como la media y valores extremos de retardo, y su desviación estándar.

De esta forma, obtenemos una especie de herramienta de diagnóstico de red, capaz por ejemplo de darnos pistas sobre el punto exacto donde está teniendo lugar una congestión. Cuando la conexión a un servidor no esté funcionando como debe, podremos determinar si el problema está en el servidor remoto, o en algún punto intermedio en la ruta que nos une.

Diagnóstico de red con MTR

Diagnóstico de red con MTR

Read Full Post »

La técnica de detección remota de la huella de un sistema operativo, más conocida por su término inglés OS fingerprinting, permite determinar con cierto grado de precisión qué sistema operativo y qué versión del mismo se está ejecutando en un sistema remoto. Siendo más precisos, de hecho, deberíamos hablar de un conjunto de técnicas, pues el fingerprinting comprende una gran variedad de pruebas.

Personalmente, la primera vez que hablé en serio de estas técnicas fue en el relativamente conocido texto de Sabuesos en la Red: El escaneo de puertos, allá por el 2004 (¡cómo pasa el tiempo!). Pero para encontrar los primeros precedentes de las modernas técnicas de fingerprinting, debemos remontarnos a 1998, cuando el mítico hacker español Savage (al que pude ver en la pasada Rooted Con) desarrolló el programa QueSO. Para saber más sobre la historia de este conjunto de técnicas, os remito a esta página del sitio de nmap.

Fijando la vista en el presente, posiblemente la herramienta más utilizada para estos menesteres sea nmap, cuyas pruebas de fingerprinting podemos conocer aquí: TCP/IP Fingerprinting Methods Supported by Nmap. Sea como fuere, y dado que estas técnicas siempre pasan por el análisis del tráfico en conexiones TCP/IP, la medida más obvia de protección es no exponer tráfico a la red. Pero fuera de los mundos de Yupi, es imposible evitar exponer un sistema a la red, y no digamos ya cuando hablamos de servidores. Así que, como dijera Vegecio, si vis pacem, para bellum: hay que contraatacar.

Y aquí entran en juego las medidas proactivas de falsificación de fingerprint (OS fingerprinting spoofing), destinadas a falsear los resultados obtenidos por las diversas pruebas del fingerprinting. Buscando por Internet encontraréis de todo, y casi todas las respuestas pasan por la aplicación de parches al kernel. Ciertamente, y dado que la efectividad del fingerprinting tiene relación directa con las particularidades de implementación de la pila TCP/IP, modificar dicha implementación en el kernel es la forma más segura de obtener buenos resultados en la falsificación. Pero también es cierto que, en la mayoría de las ocasiones, esto supone poco menos que matar moscas a cañonazos.

Antes de nada, vamos a ver qué opina nmap de mi propio sistema. Y vamos a hacerlo usando la interfaz de loopback, para evitar que el firewall o la infraestructura de red altere los resultados (que ésa es otra…):

ramiro@cormanthor:~$ sudo nmap -O localhost

Starting Nmap 5.21 ( http://nmap.org ) at 2010-12-06 12:21 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000043s latency).
Hostname localhost resolves to 2 IPs. Only scanned 127.0.0.1
rDNS record for 127.0.0.1: localhost.localdomain
{lista de puertos abiertos que no voy a revelar, ¡marujas!}
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.31 – 2.6.32
Network Distance: 0 hops

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.01 seconds
ramiro@cormanthor:~$

Nmap opina que se trata de un Linux 2.6.31 ó 2.6.32. En realidad se trata de un 2.6.35, pero falla por poco, y seguramente por la falta de actualización de las huellas de la base de datos.

Ahora lo que queremos es falsificar ese resultado, y no queremos hacerlo pegando cañonazos a las moscas. Sólo necesitamos tunear la información que escupe nuestro sistema a la red. ¿Se os ocurre alguna forma? ¡Exacto! Para eso se inventó iptables

Las tablas más conocidas en iptables son FILTER y NAT, dado que son utilizadas respectivamente en la implementación de cortafuegos y de redirecciones de red. Pero hay dos tablas más: MANGLE y RAW. La primera de ellas, que es la que nos interesa a nosotros, se utiliza -según reza el manual- para la alteración especializada de paquetes. Justo lo que queremos. :-)

Vamos a ver cómo cambiando un único parámetro chorra, el fingerprinting ya no arroja resultados con tanta seguridad. El parámetro chorra en cuestión es el TTL de los paquetes que salen de nuestro sistema. Dado que vamos a alterar la información saliente, debemos incluir nuestra regla en la cadena OUTPUT de la tabla MANGLE:

ramiro@cormanthor:~$ sudo iptables -t mangle -I OUTPUT -j TTL –ttl-set 200

Lo único que hacemos es modificar el TTL de los paquetes salientes en nuestro sistema, fijando el valor a 200 (completamente arbitrario, podéis poner cualquier otra cosa). Veamos cómo ha quedado la regla:

ramiro@cormanthor:~$ sudo iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

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
TTL all — anywhere anywhere TTL set to 200

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

ramiro@cormanthor:~$

Lancemos de nuevo nmap:

ramiro@cormanthor:~$ sudo nmap -O localhost

Starting Nmap 5.21 ( http://nmap.org ) at 2010-12-06 12:28 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000052s latency).
Hostname localhost resolves to 2 IPs. Only scanned 127.0.0.1
rDNS record for 127.0.0.1: localhost.localdomain
{lista de puertos abiertos que no voy a revelar, ¡marujas!}
No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=5.21%D=12/6%OT=21%CT=1%CU=35223%PV=N%DS=0%DC=L%G=Y%TM=4CFCC8F3%P=
OS:x86_64-unknown-linux-gnu)SEQ(SP=CC%GCD=1%ISR=D0%TI=Z%CI=Z%II=I%TS=7)OPS(
OS:O1=M400CST11NW7%O2=M400CST11NW7%O3=M400CNNT11NW7%O4=M400CST11NW7%O5=M400
OS:CST11NW7%O6=M400CST11)WIN(W1=8000%W2=8000%W3=8000%W4=8000%W5=8000%W6=800
OS:0)ECN(R=Y%DF=Y%T=35%W=8018%O=M400CNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=35%S=O%A=
OS:S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=35%W=8000%S=O%A=S+%F=AS%O=M400CST11
OS:NW7%RD=0%Q=)T4(R=Y%DF=Y%T=35%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=35
OS:%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=35%W=0%S=A%A=Z%F=R%O=%RD=0%Q
OS:=)T7(R=Y%DF=Y%T=35%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=35%IPL=164
OS:%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=35%CD=S)

Network Distance: 0 hops

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.02 seconds
ramiro@cormanthor:~$

Parece que ya no lo tiene tan claro. ;-)

Si os fijáis, no obstante, sigue habiendo por ahí información, pues en el churro que escupe nmap podemos leer “x86_64-unknown-linux-gnu“. Pero claro, ¡sólo hemos cambiado el TTL! Podríamos cambiar otro tipo de parámetros con iptables, introducir un sistema proxy que modificara la información completa… y, por supuesto, parchear el kernel. A partir de aquí, la imaginación de cada uno.

Read Full Post »

A través de un twitt de vierito5 (¿qué tal el frío germánico, tronco?), encuentro el siguiente artículo: NetGrok, InetVis, Scapy y Nmap. Detección y visualización scan de puertos. Parte I.

En él, el autor nos enseña a utilizar NetGrok e InetVis para la detección gráfica de determinados ataques en una red, que son simulados utilizando Scapy y Nmap. Un artículo muy interesante y, de hecho, un blog muy interesante. Habrá que estar atentos a las siguientes entregas.

Read Full Post »

En el mundo de las redes, uno de los fenómenos menos deseados es el de la congestión. Pese a que existen varias causas, la más común posiblemente sea la excesiva utilización del canal, que deriva en una degradación de la calidad del servicio. Y al igual que existen varios motivos para la congestión de red, existen distintos tipos de soluciones y algoritmos proactivos (de prevención) y reactivos (de solución).

Pero, aunque una red no sufra de congestión, es posible que un equipo sí la sufra. Para ello, existen otra serie de algoritmos de control de congestión en los extremos de una comunicación. En concreto, y en un sistema Linux, podemos ver cuáles son los algoritmos habilitados con la siguiente orden:

ramiro@cormanthor:~$ sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = cubic reno

En este caso, los algoritmos habilitados serían CUBIC TCP y Reno TCP. ¿Echas alguno de menos? No pasa nada, podemos cargar el módulo pertinente, siempre que éste se encuentre compilado. En este caso, añadiremos H-TCP.

ramiro@cormanthor:~$ sudo modprobe tcp_htcp
ramiro@cormanthor:~$ sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = cubic reno htcp

Si queréis cambiar el algoritmo de control por defecto, podéis hacerlo con la siguiente orden:

ramiro@cormanthor:~$ sudo sysctl -w net.ipv4.tcp_congestion_control=cubic

Por último, para echar un vistazo a los módulos disponibles, podéis cotillear directorio que los contiene:

ramiro@cormanthor:~$ ll /lib/modules/2.6.32-25-generic/kernel/net/ipv4/ | grep tcp_
-rw-r–r– 1 root root  9920 2010-09-18 01:34 tcp_bic.ko
-rw-r–r– 1 root root  6152 2010-09-18 01:34 tcp_highspeed.ko
-rw-r–r– 1 root root  9192 2010-09-18 01:34 tcp_htcp.ko
-rw-r–r– 1 root root  7304 2010-09-18 01:34 tcp_hybla.ko
-rw-r–r– 1 root root  8248 2010-09-18 01:34 tcp_illinois.ko
-rw-r–r– 1 root root  6024 2010-09-18 01:34 tcp_lp.ko
-rw-r–r– 1 root root 13520 2010-09-18 01:34 tcp_probe.ko
-rw-r–r– 1 root root  5168 2010-09-18 01:34 tcp_scalable.ko
-rw-r–r– 1 root root 10392 2010-09-18 01:34 tcp_vegas.ko
-rw-r–r– 1 root root  6272 2010-09-18 01:34 tcp_veno.ko
-rw-r–r– 1 root root  6792 2010-09-18 01:34 tcp_westwood.ko
-rw-r–r– 1 root root  6704 2010-09-18 01:34 tcp_yeah.ko
ramiro@cormanthor:~$

Ahí podemos reconocer los algoritmos BIC TCP, HighSpeed TCP, H-TCP, TCP Hybpa, TCP Illinois, TCP-LP, TCP Probe, TCP Scalable, TCP Vegas, TCP Veno, TCP Westwood y TCP YeAH. Como podéis ver, hay variedad.

Read Full Post »

Continuamos hablando de port knocking usando el demonio knockd. Al configurar las reglas de apertura y de cierre (o de apertura y cierre automático), por defecto se utiliza una secuencia simple de puertos TCP:

sequence = 7000,8000,9000

Podemos utilizar secuencias algo más complejas, asignando el tipo de protocolo (entre TCP y UDP):

sequence = 6500:tcp,2700:tcp,60000:udp,25346:tcp

Incluso, podemos indicar qué flags validarán la llamada a un puerto TCP. Cualquier paquete TCP recibido, en caso de no tener activados exactamente los flags indicados, será ignorado por el demonio.

tcpflags = psh,!urg

Imaginación al poder. El ejemplo de activar el flag PSH y no el flag URG es útil porque difícilmente se genera en comunicaciones estándar (ambos flags suelen ir de la mano). Usar el flag SYN tiene el inconveniente de ser uno de los más utilizados (obviando ACK, por supuesto), e incluso generar llamadas falsas (al menos en un primer estado) con las técnicas de escaneo de puertos más habituales: TCP connect() y SYN scan, al tener ambas técnicas su base en el inicio de una conexión TCP al estilo “three-way handshake“. Como decía, imaginación al poder.

Pero la técnica de port knocking tiene dos grandes problemas asociados. El primero es su vulnerabilidad a los ataques de repetición, muy simples si un atacante puede interponerse de alguna forma en uno de los extremos de la comunicación y analizar el tráfico. El segundo, como indicó Javi en su comentario, es lo vulnerable que queda el sistema en caso de caída del demonio knockd.

Frente a lo segundo, poco podemos hacer, aparte de monitorizar y levantar el demonio de alguna forma ($DEITY save the cron). En cuanto al primer problema, y sin acudir aún a la criptografía, podemos utilizar secuencias de llamada de un solo uso, para lo cual configuraremos la regla de la siguiente forma:

one_time_sequences = /ruta/fichero

Obviamente, esto es bastante más incómodo para el usuario, aunque evita el problema de los ataques de repetición. En cualquier caso, no debemos olvidar que port knocking es interesante como una capa más de la seguridad, pero en ningún caso sustituye a la seguridad perimetral (cortafuegos, IDS…) o a la criptografía (telnet usando port knocking, sigue siendo telnet).

Read Full Post »

Older Posts »

A %d blogueros les gusta esto: