lunes, 17 de junio de 2013

Herramientas imprescindibles para analizar procesos en Windows (I)

 Todos estamos acostumbrados a dar el comando netstat o ver la lista processo como primera acción cuando algo no va bien en el equipo.




Lo primero que se hecha en falta es poder relacionar la información de ambas pantallas que es como decir: ¿que programa a arrancado esa conexión? o su inversa ¿cuantas conexiones ha arrancando un programa?

El Gestor de Tareas de Windows y el comando netstat son claramente insufucientementes y necesitamos de algunas herramientas para poder extraer más información.


La solución a estas preguntas y otras muchas más viene de la mano de la suite Sysinternals que Microsoft pone a nuestra disposición en esta direción http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx

En sus origenes sysinternals fue desarrollado por programadores independientes y más tarde Microsoft adquirió no solo estas herramientas si no tambien su compromiso de mantenimiento.

Una de las ventajas, y es una gran ventaja, es que los programas de sysinternals son portables, es decir que no necesitan ser instalados en el equipo para funcionar. Lo que nos permite que sean añadidos al pen drive de herramientas que a modo de navaja suiza, todos los profesionales de la informática debemos llevar encima.

En un futuro post comentaré que llevo en mi pendrive-navajasuiza

Aunque son muchas herramientas y orientadas a diversos fines en este post vamos a tratar con las herramientas que nos pueden ayudar a analizar los procesos en ejecución en un sistema:
Tenemos:

• TCPView
• Process Explorer
• Process Monitor
• Handles
• ListDLL
• Autoruns

Cuyos nombres dice bastante acerca de lo que podemos esperar de cada una de ellas.

TCPView.
Nos permite ver la conexiones de red que tenemos en nuestro equipo:

Esta es una pantalla general de la aplicación:


Se puede limitar la salida a sólo aquellas conexiones activas:


Mediante Ctrl+R podemos activar / desactivar la resolución de nombres


Las filas pueden estar coloreadas:
  • Amarillas - Conexiones que han cambiado de estado entre dos inspecciones
  • Rojas - Conexiones que han desaparecido
  • Verdes - Nuevas conexiones.
Una de las cosas que en mi opinión son mas útiles es la posibilidad de identificar al proceso que tiene la conexión.

Mediante nombre y su PID. Además si seleccionamos el proceso y vamos al menú y seleccionamos: Process --> Process Properties nos identifica en el fichero del programa:


Permitiéndonos incluso cancelar el proceso.

No alargo más este post y en los próximos iremos viendo y todos y cada uno de estos programas y finalizaremos con un ejemplo de uso de todos ellos para analizar un malware.



miércoles, 5 de junio de 2013

Denegación de servicio en las Base de Datos

A medida que han ido haciéndose los servidores más y más potentes las bases de datos han ido desarrollando modelas mas conceptuales y las capas de abstracción cada vez son más profundas. La consecuencia inmediata de ello es que cada vez menos programadores realmente conocen como son las sentencias SQL que hay detrás de esos conceptos y la consencuencia de ello es un descuido total hace las cuestiones de rendimiento.
El hecho de que los sistemas se hayan hecho más resistentes a los ataques DoS clásicos ha forzado a que las organizaciones que están detrás de estos ataques suban un escalon en los niveles OSI y dirijan sus esfuerzos en diseñar ataques a nivel de Aplicación.



La idea básica es construir ataques basados en consultas que sean veroces consumidoras de recursos en los servidores: ejecutar pesadas select desde diversos sitios (ataque distribuido), generar carritos de compra con varios cientos (o miles de productos) y realizar pequeñas variaciones en ellos para obligar a recalcular todo.
También puede aprovecharse las limitaciones de los sistemas de bases de datos que dan servicio a la aplicación. Incluso se puede llegar a realizar ataques de SQL Injection que no tienen porque ser demasiado elaborados porque el objetivo de un ataque DoS no es comprometer al equipo, si no colapsarlo. Un sencillo ataque de SQL Injection  que cause un inesperado consumo excesivo de recursos es suficiente.

La cosa se puede agravar más porque gran parte de estas aplicaciones se construyen con herramientas ya conocidas y siempre es posible realizar simulaciones offline para analizar el rendimiento de las consultas generadas y seleccionar las más pesadas.


Evitar estos ataques se hace difícil para los sistemas tradicionales. Pueden no ser necesarias tantas peticiones para bloquear una base de datos por lo que los sistemas de detección basados en volumen no garantizan que puedan detectarlos.
Por otro lado la detección de SQL Injection se basa en la comparación de patrones para detectar ataques y en este caso se va a trabajar en su mayor con peticiones legítimas. Basarnos en estos sistemas necesitarán un ajuste muy fino o nos podemos estar bloqueando peticiones legítimas.

Se pueden hacer sistemas mixtos que  ciertos tipos de consultas con incrementos en peticiones, pero todo es encaje fino y sin garantías.

La solución pasa por una vuelta atrás y volver a hacer énfasis en el rendimiento. Antes era obligado porque las máquinas eran menos potentes y ahora porque las pueden sobrecargar. Diseñar la basa de datos muy ajustada al tipo de consultas que se espera. Optimizar la consultas para que funcionen de la manera mas eficiente. Olvidar un poco los modelos generalistas y centrarse en entornos específicos. Mas caro, más lento de desarrollar pero que a la larga puede ahorrar más de un quebradero de cabeza.