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 »

Older Posts »

A %d blogueros les gusta esto: