Feeds:
Entradas
Comentarios

Posts Tagged ‘sistemas operativos’

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 »

De Google en Google, y tiro porque me toca. Parece que la comidilla de hoy en la red (I, II, III… etc.) es la publicación de las primeras imágenes oficiales de (redoble de tambores…) Google Chrome OS.

Como todo aquello tocado por este moderno Rey Midas que es Google, parece que Chrome OS está llamado a convertirse en oro. ¿O no? En mi opinión, y valga la redundancia, aún es muy pronto para opinar. El propio navegador Google Chrome prometía mucho, pero parece que no termina de arrancar, pese a que su única competencia “real” es Firefox, que adolece de ciertos problemas, y que se ha convertido poco a poco en un software mastodóntico y pesado, al más puro estilo OpenOffice.org.

Desde luego, el esfuerzo tecnológico y la innovación que conllevan los avances presentados por Chrome OS prometen bastante, y resulta especialmente impresionante la velocidad del proceso de arranque del sistema completo. Por supuesto, hasta que no lo vea en vivo y en directo no me lo creeré, que he visto muchos Windows “arrancar rápido” y luego tirarse cinco minutos cargando mierda en el systray

Como siempre en estos casos, lo mejor es ver las cosas por uno mismo, así que allá van los vídeos. Vean, valoren, y opinen, damas y caballeros.

Read Full Post »

Leo en barrapunto que la versión 2.6.31 del núcleo Linux incluirá un nuevo sistema de gestión de memoria principal y de memoria de intercambio, destinado principalmente a mejorar el rendimiento en equipos viejunos con recursos más limitados. Las pruebas, realizadas con un sistema con 512 Mb de RAM, arrojan resultados prometedores, al darse sólo la mitad de operaciones de intercambio que en el sistema antiguo.

Ahora, yo reflexiono.

Linux siempre ha sido un sistema bastante generoso con equipos de recursos limitados. Personalmente, utilizo un ordenador de sobremesa de más de siete años de antigüedad (Menzoberranzan), y el funcionamiento es francamente bueno para los recursos de que dispone el sistema. Incluso, ejecuto máquinas virtuales con un rendimiento aceptable. Aún así, la nueva versión de Linux introduce un sistema completamente nuevo, y destinado únicamente a equipos viejos, pues no resulta útil (o al menos no tanto) en los más modernos.

Por su parte, la nueva versión de Mac OS X (Snow Leopard) ha mejorado sustancialmente el rendimiento con respecto a la anterior. En mi experiencia, un equipo portátil de algo más de un año de antigüedad (Suldanessellar) funciona ahora de forma más fluida que cuando lo compré.

La pregunta es, ¿soy el único que piensa que Windows es el único sistema operativo mayoritario cuyo rendimiento decae constantemente? Como máximo acercamiento, parece que Windows 7 tendrá unos requisitos similares a los de Windows Vista, así como un rendimiento algo mejor; lo cual no es mucho decir, habida cuenta de lo abultados que resultaban dichos requisitos cuando se lanzó Vista, así como su nefasto rendimiento.

Vale, hay que mover el mercado del hardware. Vale, los equipos nuevos funcionan mucho mejor y permiten hacer muchas virguerías (mi core 2 quad con 4 Gb de RAM del curro le da cien mil vueltas a mi anciano pentium 4 con 1 Gb de RAM).

Pero, ¿es buena esta tendencia a renovar constantemente equipos con características ya de por sí sobredimensionadas? Es más, ¿es necesaria?

Read Full Post »

Hace aproximadamente una semana se publicó una entrada bastante interesante en Slashdot, donde se enlaza un paper de investigación titulado A Tale of Four Kernels, que ha sido presentado en la última edición del ICSE (International Conference on Software Engineering).

El artículo se centra en el estudio de la calidad de código en cuatro de los núcleos más utilizados actualmente en el terreno de los sistemas operativos: FreeBSD 6.1, Open Solaris, Linux 2.6.18 y Windows Research Kernel 1.2 (basado en el núcleo NT 5.2, del sistema Windows Server 2003).

Es muy importante tener en cuenta que el estudio se refiere exclusivamente a la calidad de código, es decir, a cómo de bien está escrito o estructurado el código fuente, y en ningún caso a la eficiencia o rendimiento desempeñado por el núcleo en sí mismo, lo cual requeriría de otro estudio muchísimo más complejo.

Las conclusiones vienen a decir que no existen diferencias notables en la calidad de construcción del código entre los sistemas abiertos o cerrados, lo cual francamente no me sorprende, habida cuenta de las estrictas guías de estilo utilizadas en cualquier desarrollo de gran envergadura. Como nota curiosa, llama la atención (o no) que el núcleo con mayor número de puntuaciones negativas sea Windows Research Kernel.

Read Full Post »

Leo en Kriptópolis esta entrada sobre una aplicación muy, pero que muy curiosa. Se trata de andLinux, una distribución Ubuntu modificada que ejecuta una versión el núcleo Linux portada para Windows, llamada coLinux.

El resultado es que podemos ejecutar aplicaciones de Linux en ventanas independientes del entorno gráfico de Windows, como si de aplicaciones nativas se tratara. Para comprender mejor cómo funciona, podéis echar un ojo al vídeo que hay empotrado en esta entrada.

Puede resultar muy útil para disponer de aplicaciones de Linux sin necesidad de arrancar una máquina virtual completa. Creo que para mi máquina del trabajo me va a venir de perlas…

Eso sí, ojo porque tiene una pega de seguridad, que en la página de requisitos nos dejan bien clara:

Security warning: It is recommended to use andLinux only on single-user-PCs or in a trustworthy environment because the communication with the X-Server and the launcher is not secured, i.e., every user who can login to Windows can access andLinux.

Read Full Post »

A %d blogueros les gusta esto: