Gran parte de los ataques que acaban con el acceso por parte del atacante a un equipo con permisos de Administrador, suelen seguir el siguiente patr�n de comportamiento:
El atacante realiza un barrido de puertos (escaneo) buscando equipos vulnerables que est�n ejecutando un servidor con alg�n fallo de seguridad conocido y que se ha comentado ampliamente en listas de seguridad, por ejemplo los fallos de desbordamiento de buffer en el servidor de FTPwuftp, el servidor bind de DNS o en el proceso rpc.statd.
Estos fallos de seguridad son anunciados en diversas listas de seguridad de proposito general, como Bugtraq
La mayor�a de los vendedores de distribuciones Linux disponen de listas de anuncios, donde indican las actualizaciones por motivos de seguridad, de los programas que componen su distribuci�n.
En algunas listas de seguridad, aparecen incluso programas que demuestran esta vulnerabilidad y que pueden ser empleados por los atacantes, estos programas se suelen denominar "exploits".
El atacante emplea un exploit contra el equipo, consiguendo instalar una puerta de acceso en el sistema, muchas veces el exploit genera directamente un interprete de comandos con privilegios de root, o a�ade una linea en el fichero /etc/inetd.conf para lanzar una shell en un puerto dado. El m�todo puede variar, aunque el objetivo del ataque suele ser siempre el mismo, obtener un acceso a una sesi�n interactiva o "shell remoto" en el equipo desde el cual proseguir el ataque.
El atacante instala o compila un "rootkit", conjunto de programas de nombre y comportamiento similar al de comandos del sistema operativo, que sin embargo no muestran informaci�n sobre determinados estados del sistema[1]
Estos rootkit han ido evolucionando, siendo cada vez m�s complejos. Existen m�dulos del kernel que permiten ocultar diversos procesos, de forma que el atacante pueda ocultar su acceso sin modificar los binarios instalados en el equipo.
El atacante instalar� y/o compilar� algunas herramientas de ataque, para escanear y atacar otros equipos y redes empleando la maquina reci�n atacada como puente.
Esta situaci�n se reproduce hasta que alguien detecta un comportamiento an�malo en el equipo. Algunas veces esta detecci�n se realiza por el propio administrador del equipo debido a una carga de procesamiento anormal, accesos extra�os, etc., pero en la mayor�a de los caso la detecci�n del equipo atacado se produce desde el exterior: Llega un correo a la organizaci�n indicando que el equipo en cuesti�n esta escaneando o ha sido empleado para atacar otros sistemas y al contactar con el administrador del equipo se descubre que la maquina ha sido a su vez atacada.
Sin entrar en el grave problema que es la ausencia de administraci�n y actualizaci�n de estos equipo, [2] los pasos a seguir suelen ser tambi�n siempre los mismos y es lo que se conoce como "recuperaci�n" ante un incidentes de seguridad.
| [1] | As� la versi�n modificada del comando ls no listar� los ficheros creados por el intruso, ps no mostrara determinados procesos o netstat no mostrara las conexiones del atacante} Adem�s con el rootkit se suelen instalar "puertas traseras" en el equipo, programas que permitan acceder de f�cilmente en otras ocasiones al equipo. As� una modificaci�n en el programa tcpd de los tcpwrapper, cuando el programa tcpd recib�a una conexi�n con origen un puerto determinado (421/TCP), se ejecutaba un interprete de comandos, teniendo acceso al equipo. |
| [2] | Pocas usuarios instalan alg�n programa como Cops , System Scanner de ISS o Nessus para comprobar las posibles vulnerabilidades de sus equipos. |