Linux es un Sistema multiusuario real. Puede haber varios usuarios distintos trabajando a la vez cada uno desde su terminal. El sistema tiene la obligación de proteger a unos usuarios frente a otros y protegerse a sí mismo. También es una excelente Estación de trabajo aislada, pero lo habitual es que cada máquina linux esté conectada a una red y además esté prestando servicios de red. El sistema tiene la obligación de garantizar los servicios que presta.

Además la generalización de las conexiones con Internet y el rápido desarrollo del software, la seguridad se está convirtiendo en una cuestión cada vez más importante. Ahora, la seguridad es un requisito básico, ya que la red global es insegura por definición. Mientras sus datos estén almacenados en un soporte informático, mientras sus datos vayan desde un sistema X a otro sistema Y a través de un medio físico, Internet, por ejemplo, puede pasar por ciertos puntos durante el camino proporcionando a otros usuarios la posibilidad de interceptarlos, e incluso alterar la información contenida. Incluso algún usuario de su sistema puede modificar datos de forma maliciosa para hacer algo que nos pueda resultar perjudicial. Con el acceso masivo y barato a Internet se han reducido notablemente los costes de un atacante para asaltar un sistema en red, a la vez que ha aumentado paralelamente el número de potenciales atacantes.

También queremos remarcar el carácter dinámico de la seguridad de los sistemas en red. Continuamente aparecen nuevos métodos para conseguir accesos indebidos o comprometer el correcto funcionamiento de la red. Esto obliga a estar actualizado permanentemente, y consultar las publicaciones electrónicas que informan de los últimos sucesos detectados.

Se debe tener en cuenta que ningún sistema es "completamente" seguro. Por lo tanto lo único que puede hacer es aumentar la dificultad para que alguien pueda comprometer la seguridad de su sistema. Tampoco todos los usuarios tienen las mismas necesidades de seguridad en sus entornos. Por ejemplo, los usuarios domésticos de Linux, no necesitan demasiado trabajo para mantener alejados a los crackers ocasionales, mientras que para los usuarios muy especializados de Linux, como por ejemplo servidores de Internet, bancos, compañías de telecomunicaciones, etc., se necesita un trabajo mucho más detallado para garantizar la seguridad en los términos previstos.

¿Qué desea Proteger?

Generalmente se deseará garantizar el funcionamiento de forma adecuada, que nadie pueda obtener o modificar una información a la que no tiene derecho legítimo y contar con comunicaciones seguras. Una buena planificación ayuda a conseguir los niveles de seguridad que pretendemos.

Antes de intentar asegurar su sistema debería determinar contra qué nivel de amenaza quiere protegerse, qué riesgo acepta o no y, como resultado, cómo de vulnerable es su sistema. Para ello debemos saber que Riesgo es la posibilidad de que un intruso pueda intentar acceder con éxito a su equipo.

La amenaza proviene de alguien que tiene motivos para obtener acceso sin autorización a su red o equipo. Debe decidir en quién confía para dotar de acceso a su sistema y qué amenaza puede representar.

Proceden de varios Tipos de Intrusos

· El Curioso - está interesado básicamente en qué tipo de sistema y datos posee.

· El Malicioso - pretenderá, hacerle caer su sistema, modificar su página web o cualquier otra cosa que le cueste tiempo y dinero recuperar.

· El Intruso muy personalizado - trata de usar su sistema para ganar popularidad o mala fama. Puede usar su sistema para promocionar sus habilidades.

· La Competencia - está interesado en los datos que tiene en su sistema. Puede ser alguien que piense que tiene algo que le puede interesar financieramente o de otra forma.

La vulnerabilidad describe el nivel de protección de su equipo frente a otra red, y la posibilidad potencial para alguien que pueda obtener acceso no autorizado.

Requisitos de Seguridad

· Disponibilidad: consistente en mantener la información y los recursos de acuerdo con los requisitos de utilización que pretende la entidad que utiliza la red informática. La disponibilidad de la información pretende garantizar que no se limite el acceso autorizado a la información y el correcto funcionamiento de los recursos.

· Integridad: la información que se almacena en los sistemas o que circula por las líneas de comunicación debe estar protegida contra la modificación no autorizada. Requiere que la información sólo pueda ser modificada por las entidades autorizadas.

· Autenticidad: la información que se almacena o circula por una red debe permanecer protegida ante falsificaciones. La autenticidad requiere mecanismos de identificación correctos, asegurando que las comunicaciones se realizan entre entidades legítimas.

· Confidencialidad: pretende evitar la difusión no autorizada de la información. Requiere que la información sea accesible únicamente por las entidades autorizadas.

No rechazo: establecer los mecanismos para que nadie pueda negar que ha realizado una determinada comunicación.

Seguridad Local

Temas a desarrollar

Como ya mencionamos anteriormente Linux es un sistema operativo multiusuario real: puede haber varios usuarios trabajando simultáneamente con él, cada uno en su terminal. Esto obliga a tener en cuenta medidas de seguridad adicionales. Además, según hablan las estadísticas, el mayor porcentaje de violaciones de un sistema son realizadas por usuarios locales. Pero no sólo hay que protegerse de las violaciones intencionadas, sino que el sistema debe protegernos de operaciones accidentales debidas a descuidos o ignorancia de los usuarios.

En este aspecto de la seguridad, Linux dispone de todas las características de los sistemas Unix: un control de acceso a los usuarios verificando una pareja de usuario y clave, ademas cada fichero y directorio tienen sus propietario y permisos.

Por otro lado, la meta de la mayoría de los ataques es conseguir acceso como root, lo que garantiza un control total sobre el sistema. Primero se intentará conseguir acceso como usuario "normal" para posteriormente ir incrementando sus niveles de privilegio utilizando las posibles debilidades del sistema: programas con errores, configuraciones deficientes de los servicios o el descifrado de claves cifradas. Incluso se utilizan técnicas denominadas "ingeniería social", consistentes en convencer a ciertos usuarios para que suministren una información que debiera ser mantenida en secreto, como sus nombres de usuario y contraseñas.

En este apartado de seguridad local pretendemos dar unas ideas generales de los riesgos existentes, mecanismos para su solución y unas directrices de actuación que deberían convertirse en hábitos cotidianos.

Cuentas de usuario, grupos

Cada usuario del sistema está definido por una línea en el fichero /etc/passwd y cada grupo por otra línea en el fichero /etc/group. Cada usuario pertenece a uno o varios grupos y cada recurso pertenece a un usuario y un grupo. Los permisos para un recurso se pueden asignar al propietario, al grupo y a otros (usuarios). Ahora bien, para mantener un sistema seguro, pero funcional, tendremos que realizar las combinaciones necesarias entre el propietario y grupo de un recurso con los permisos de los propietarios, grupos y otros. Un usuario (cualquiera), podrá escribir en la unidad, si lo incluimos en el grupo floppy.

El administrador tiene que conocer las necesidades de cada uno de sus usuarios y asignarle los mínimos privilegios para que pueda realizar su trabajo sin resultar un peligro para otros usuarios o el sistema. Los valores por defecto de Linux son suficiente para mantener el sistema seguro. Otro peligro potencial para el sistema es mantener cuentas abiertas.

Seguridad de las claves

La seguridad de una sola cuenta puede comprometer todo el sistema. Por un lado tenemos que asegurarnos de que nuestros usuarios utilizan claves sólidas:

No deben ser palabras conocidas, deberían contener letras, números y caracteres especiales, deben ser fáciles de recordar y difíciles de adivinar.

Existen varios programas que van probando varias palabras de diccionario, claves habituales y combinaciones de caracteres, que son cifrados con el mismo algoritmo que usa el sistema para mantener sus claves; si coincide un valor cifrado con alguna clave, se notifica al usuario que su clave es débil y le solicitaremos que la modifique, (cifrador John the Ripper). Usando este mecanismo, al menos podemos garantizar que no estaremos en inferioridad de condiciones con respecto a los atacantes locales.

Por otro lado, las claves cifradas se almacenan en el fichero /etc/passwd. Cualquier usuario del sistema tiene permiso de lectura sobre este fichero. Lo que es peor, agujeros en los navegadores permiten que se puedan leer ficheros arbitrarios de una máquina. Para solucionar esta vulnerabilidad, podemos recurrir a contraseñas en la sombra (shadow passwords), un mecanismo consistente en extraer las claves cifradas del fichero /etc/passwd y situarlas en otro fichero llamado /etc/shadow, que sólo puede leer el root y dejar el resto de la información en el original. El fichero /etc/shadow sólo contiene el nombre de usuario y su clave, e información administrativa. En alguna situación olvidar una clave puede ser un serio problema.

El bit SUID/SGID

En muchas ocasiones un proceso necesita ejecutarse con unos privilegios mayores (o menores) que el usuario que lo lanzó. Por ejemplo, un usuario puede modificar su propia clave con el mandato passwd, pero esto implica modificar el fichero /etc/passwd, y para esto un usuario no tiene permiso. ¿Cómo se soluciona? Pues activando el bit SUID del comando passwd.

Esto quiere decir que cuando se ejecute, el proceso correspondiente va a tener los privilegios del propietario del comando (es decir, el root), no del usuario que lo lanzó. En otras palabras, el proceso generado por passwd pertenece a root. A primera vista, esto puede parecer una seria brecha de seguridad. Y lo es. Si el programa funciona correctamente, no tiene por qué dar problemas; pero pequeños defectos en el programa pueden ser utilizados por alguien para tratar de ejecutar otro código distinto con los privilegios de este proceso. Un atacante que haya entrado al sistema de forma ilegítima intentará dejar una shell con el bit SUID para mantener ese nivel de privilegio cuando vuelva a entrar en el sistema. SGID es lo mismo que SUID, pero aplicado al grupo. Tenga cuidado con los programas con el bit SUID/SGIG, como el passwd con bit SUID. Nunca debe permitir que quede una shell SUID corriendo en el sistema. Si el root deja desatendida la consola durante unos instantes (recuerde, debe utilizar siempre xlock), un intruso podría crear una versión SUID de la shell. En el futuro, cuando el atacante ejecute ese programa, se convertirá en root.

El Root

Los peores destrozos de un sistema es probable que no vengan de ningún cracker, o de un malévolo intruso. En muchísimas ocasiones el propio administrador el que ha destrozado el sistema. Evitar este problema no es difícil.

Existen herramientas como sudo que permiten a ciertos usuarios utilizar comandos privilegiados sin necesidad de ser root, como montar o desmontar dispositivos. Además registra las actividades que se realizan, lo que ayuda a determinar qué hace realmente este usuario.

Seguridad del Sistema de Archivos

Temas a desarrollar

Una norma básica de seguridad radica en la asignación a cada usuario sólo de los permisos necesarios para poder cubrir las necesidades de su trabajo.

· ¿Como se puede poner en riesgo al sistema?

Apuntar algunas ideas: violar la privacidad de la información, obtener privilegios que no correspoden a un usuario, hacer uso desmedido de los recursos o modificar información legítima contenida en una máquina, como pueden ser el contenido de una página web o una base de datos.

· ¿Cómo podemos mantener un almacenamiento seguro?

Se pueden tomar ciertas medidas que garanticen un mínimo de seguridad y funcionalidad para administrar un sistema Linux para dar servicio a diversos usuarios.

El árbol de directorios

Se organizan en un único árbol de directorios. Cada soporte, disco, partición, disquete o CD tiene su propia organización lógica, un sistema de ficheros. Para poder usar uno de estos soportes tendremos que "montarlo" en un directorio existente. El contenido de la partición nos aparecerá como el contenido del directorio.

Un primer criterio para mantener un sistema seguro debemos hacer una correcta distribución del espacio de almacenamiento. Esto limita el riesgo de que el deterioro de una partición afecte a todo el sistema. No hay normas generales aplicables; el uso al que vaya destinado el sistema y la experiencia son las bases de la decisión adecuada.

Permisos

Linux, como sistema multiusuario, asigna un propietario y un grupo a cada fichero (y directorio) y unos permisos al propietario, al grupo y al resto de los usuarios. En los sistemas de ficheros pensados para entornos monousario, como msdos o vfat, no tenemos esta característica, su uso no es aconsejable bajo Linux. Es conveniente tener claros los permisos que se pueden asignar a un fichero o directorio.

Puede que algunas aplicaciones no funcionen bien si algún fichero no tiene el permiso o el propietario correctos, bien por falta de permisos o bien por exceso. Algunas aplicaciones son delicadas en este aspecto. El programa se configura en el fichero .fetchmailrc, donde tendremos que indicar la clave que usamos en el servidor; pues bien, si este fichero tiene permiso de lectura para otro usuario que no sea el propietario, fetchmail no funcionará.

Otras aplicaciones, como por ejemplo inn tampoco funcionará si el propietario de sus ficheros es otro usuario distinto a news. Todo esto está perfectamente documentado en cada uno de los programas, por lo que es conveniente leer la documentación que aporta y las páginas del manual.

Permisos de ficheros y directorios

Asegurarse de que los ficheros del sistema y los de cada usuario sólo son accesibles por quienes tienen que hacerlo y de la forma que deben, hay que protegerse de acciones accidentales.

En general, cualquier sistema UNIX divide el control de acceso a ficheros y directorios en tres elementos: propietario, grupo y otros. Tanto el propietario como el grupo son únicos para cada fichero o directorio. Eso sí, a un grupo pueden pertenecer múltiples usuarios.

Otros hace referencia a los usuarios que ni son el propietario ni pertenecen al grupo. Todas estas características se almacenan en el sistema de ficheros, en particular en un elemento que describe las características de un fichero en disco (salvo su nombre).

Una rápida explicación de los permisos Unix:

Propiedad:

Qué usuario y grupo posee el control de los permisos del i-nodo. Se almacenan como dos valores numéricos, el uid (user id) y gid (group id).

Permisos:

Bits individuales que definen el acceso a un fichero o directorio. Los permisos para directorio tienen un sentido diferente a los permisos para ficheros. Más abajo se explican algunas diferencias.

Lectura (r):

Fichero: Poder acceder a los contenidos de un fichero

Directorio: Poder leer un directorio, ver qué ficheros contiene

Escritura (w):

Fichero: Poder modificar o añadir contenido a un fichero

Directorio: Poder borrar o mover ficheros en un directorio

Ejecución(x):

Fichero: Poder ejecutar un programa binario o guion de shell

Directorio: Poder entrar en un directorio

Estos permisos se pueden aplicar a:

· usuario (u): El propietario del fichero

· grupo (g): El grupo al que pertenece el fichero

· otros (o): El resto de los usuarios del sistema

Los directorios que tengan permiso de escritura. Pueden ser borrados por cualquier usuario que ingrese.

Otros bits de permisos

Sticky bit:

El sticky bit tiene su significado propio cuando se aplica a directorios. Si el sticky bit está activo en un directorio, entonces un usuario sólo puede borrar ficheros que son de su propiedad o para los que tiene permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está pensado para directorios como /tmp, que tienen permiso de escritura global, pero no es deseable permitir a cualquier usuario borrar los ficheros que quiera. El sticky bit aparece como 't' en los listados largos de directorios.

drwxrwxrwt 19 root root 8192 Jun 24 14:40 tmp

Attributo SUID: (Para Ficheros)

Este bit describe permisos al identificador de usuario del fichero. Cuando el modo de acceso de ID de usuario está activo en los permisos del propietario, y ese fichero es ejecutable, los procesos que lo ejecutan obtienen acceso a los recursos del sistema basados en el usuario que crea el proceso.

· No asignar el bit SUID salvo cuando sea necesario.

· Comprobar que cualquier programa con este bit activo no tiene ningún desbordamiento de buffer (conocido).

· No asignarlo jamás si el programa permite salir a la shell.

Atributo SGID: (Para ficheros)

Si está activo en los permisos de grupo, este bit controla el estado de "poner id de grupo" de un fichero. Actúa de la misma forma que SUID, salvo que afecta al grupo. El fichero tiene que ser ejecutable para que esto tenga algún efecto.

Atributo SGID: (Para directorios)

Si activa el bit SGID en un directorio ( con "chmod g+s directorio"), los ficheros creados en ese directorio tendrán puesto su grupo como el grupo del directorio.

Normalmente un fichero tendrá una combinación de los siguientes permisos:

-r-------- Permite acceso de lectura al propietario
--w------- Permite modificar o borrar el fichero al propietario
---x------ Permite ejecutar este programa al propietario, (los guiones de shell también requieren permisos de lectura al propietario)
---s------ Se ejecutará con usuario efectivo ID = propietario
-------s-- Se ejecutará con usuario efectivo ID = grupo
-rw------T No actualiza "instante de última modificación". Normalmente usado para ficheros de intercambio (swap)
---t------ No tiene efecto. (antes sticky bit)

A continuación se describen los significados de los permisos de acceso individuales para un directorio. Normalmente un directorio tendrá una combinación de los siguientes permisos:

dr-------- Permite listar el contenido pero no se pueden leer los atributos.
d--x------ Permite entrar en el directorio y usar en las rutas de ejecución completas.
dr-x------ Permite leer los atributos del fichero por el propietario.
d-wx------ Permite crear/borra ficheros.
d------x-t Previene el borrado de ficheros por otros con acceso de escritura. Usado en /tmp
d---s--s-- No tiene efecto

Los ficheros de configuración del sistema (normalmente en /etc) es habitual que tengan el modo 640 (-rw-r-----), y que sean propiedad del root. Dependiendo de los requisitos de seguridad del sistema, esto se puede modificar. Nunca deje un fichero del sistema con permiso de escritura para un grupo o para otros. Algunos ficheros de configuración, incluyendo /etc/shadow, sólo deberían tener permiso de lectura por root, y los directorios de /etc no deberían ser accesibles, al menos por otros.

SUID Shell Scripts

Los scripts de shell SUID son un serio riesgo de seguridad, y por esta razón el núcleo no los acepta. Sin importar lo seguro que piense que es su script de shell, puede ser utilizado para que un cracker pueda obtener acceso a una shell de root.

Enlaces

Los sistemas de ficheros de tipo Unix permiten crear enlaces entre ficheros. Los enlaces pueden ser duros o simbólicos. Consiste en asignar más de un nombre a los mismos datos en disco. Un enlace duro no consume más espacio adicional que el que pueda representar el nuevo nombre que le damos a unos datos y sólo es válido para ficheros que estén en el mismo sistema de ficheros, es decir, la misma partición. Los enlaces simbólicos son ficheros que apuntan a otro fichero o directorio. Crean un nuevo fichero pequeño que contiene la ruta del fichero destino.

Verificar la integridad con Tripwire

Una forma cómoda de detectar ataques locales y de red en su sistema, es ejecutar un programa que verifique la integridad de la información almacenada en los ficheros, el programa que lo haca es Tripwire. El programa Tripwire ejecuta varios cheksums de todos los binarios importantes y ficheros de configuración y los compara con una base de datos con valores de referencia aceptados como buenos. Detecta cualquier cambio en los ficheros.

Es bueno instalar tripwire en un disquete y protegerlo físicamente. De esta forma no se puede alterar tripwire o modificar su base de datos. Una vez que tripwire se ha configurado, es bueno ejecutarlo como parte de de los deberes habituales de administración para ver si algo ha cambiado.

Limitar el espacio asignado a los usuarios

Una ataque a cualquier sistema, es intentar consumir todo el espacio del disco duro. Una primera protección contra este ataque es separar el árbol de directorios en diversos discos y particiones. Pero esto puede no ser suficiente y por eso el núcleo del sistema proporciona la posibilidad de controlar el espacio de almacenamiento por usuario o grupo.

Para verificar las particiones que se han realizado en el dicos, existen dos métodos:

El primero consiste en editar la cuota de cada usuario.

El sistema de cuotas de Linux permite limitar el número de bloques y el número de i-nodos que un usuario puede tener. Los valores a modificar son los límites que están puestos entre paréntesis (que ahora valen 0).

El límite soft es un límite de aviso y el límite hard es un límite insalvable, es decir, el sistema ya no le asigna más espacio.

Normas prácticas para aumentar la seguridad

Todas las distribuciones de Linux traen valores por defecto que son más razonables para cubrir necesidades normales.

· nosuid, nodev, noexec.

Salvo casos excepcionales, no debería haber ninguna razón para que se permita la ejecución de programas SUID/SGID en los directorios home de los usuarios.

· Sistemas de ficheros en red

Si se exporta sistemas de archivos vía NFS, esté seguro de configurar /etc/exports con los accesos lo más restrictivos posibles.

· umask

Configurar la máscara de creación de ficheros para que sea lo más restrictiva posible.

El comando umask se usa para determinar el modo de creación de ficheros por defecto en su sistema. Si los ficheros se crean sin ningún de estado de permisos, el usuario, de forma inadvertida, podrá asignar permisos de lectura o escritura a alguien que no debería tenerlos.

· Limitar recursos

Ponga el límites al sistema de ficheros en lugar de 'ilimitado' como está por defecto. Puede controlar el límite por usuario utilizando el módulo PAM de límite de recursos.

· wtmp, utmp

Los ficheros /var/log/wtmp y /var/run/utmp contienen los registros de conexión de todos los usuarios de su sistema. Se debe mantener su integridad, ya que determinan cuándo y desde dónde entró en su sistema un usuario o un potencial intruso.

· Sticky bit

El sticky bit se puede usar para prevenir borrados accidentales o proteger un fichero para sobreescritura.

· SUID y SGID

Los ficheros SUID y SGID de su sistema son riesgos de seguridad y deberían ser controlados. Como estos programas garantizan privilegios especiales al usuario que los ejecuta, es necesario estar seguro que no haya instalados programas inseguros.

Encontrar todos los programas SUID/SGID de su sistema y mantener la pista de lo que son, para que esté prevenido de cualquier cambio que podría indicar un potencial intruso.

· Permisos de escritura

Los ficheros con permiso de escritura global, particularmente los del sistema, pueden ser un agujero de seguridad, porque cualquier usuario tiene acceso al sistema y los modifica. Además, los directorios con permiso de escritura global son peligrosos, ya que permiten añadir y borrar los ficheros.

· Ficheros extraños

Los ficheros sin propietario nos indican que un intruso ha accedido a nuestro sistema.

Seguridad del Núcleo

Temas a desarrollar

Linux tiene la gran ventaja de tener disponible el código fuente del núcleo; en realidad Linux propiamente dicho es sólo el núcleo. Esto nos permite la posibilidad de crear núcleos a medida de nuestras necesidades. Y parte de nuestras necesidades será la mejora de la seguridad.

Como el núcleo controla las características de red de su sistema, es importante que el núcleo tenga las opciones que garanticen la seguridad y que el propio núcleo no pueda ser comprometido. Para prevenir algunos de los últimos ataques de red, debe intentar mantener una versión del núcleo actualizada.

Una de las características más interesantes del núcleo Linux es la posibilidad de realizar enmascaramiento de direcciones. Con esta técnica podremos dar acceso a Internet a una red local con direcciones privadas de forma transparente, es decir, sin

ningún tipo de modificación en la configuración de las aplicaciones clientes, a diferencia de los proxies clásicos. Consiste en que el sistema Linux que posee la conexión hacia el exterior recibe las peticiones de conexión desde los equipos de la red local que tienen direcciones no válidas para Internet. El equipo Linux rehace la petición poniendo su propia dirección IP y modificando el puerto al que tiene que responder el equipo remoto. Cuando Linux recibe la respuesta del equipo remoto, mira el puerto al que va destinado y vuelve a rehacer el paquete para enviarlo al equipo concreto de la red local que solicitó la conexión. De esta forma podemos mantener un nivel aceptable de protección para los equipos de la red local, ya que sólo podrán recibir respuestas a peticiones que ellos mismos originaron.

Opciones de compilación del núcleo

IP: Drop source routed frames (CONFIG_IP_NOSR)

Esta opción debería estar activada. Source routed frames contienen la ruta completa de sus destinos dentro del paquete. Esto significa que los enrutadores a través de los que circula el paquete no necesitan inspeccionarlo, y sólo lo reenvían. Esto podría ocasionar que los datos que entran a su sistema puedan ser un exploit potencial.

IP: Firewalling (CONFIG_IP_FIREWALL)

Esta opción es necesaria si va a configurar su máquina como un cortafuegos, hacer enmascaramiento o desea proteger su estación de trabajo con línea telefónica de que alguien entre a través de su interfaz PPP. Con esta opción activa podremos usar el filtrado de paquetes en el propio núcleo del sistema, decidiendo el tráfico que llega o sale de nuestro equipo.

IP: forwarding/gatewaying (CONFIG_IP_FORWARD)

Si activa reenvío IP (IP forwarding), su Linux esencialmente se convierte en un encaminador (router). Si su máquina está en una red, podría estar enviando datos de una red a otra, y quizás saltándose un cortafuegos que esté puesto allí para evitar que esto suceda. A los usuarios con un puesto aislado y conexión telefónica les interesará desactivar esta característica. Otros usuarios deberían pensar en las implicaciones de seguridad de hacer esto en su caso concreto. Las máquinas que actúen como cortafuegos tendrán que activar esta característica y usarla junto al software cortafuegos.

IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE)

Esta opción le suministra información sobre los paquetes que su cortafuegos como remitente, destinatario, puerto, etc. Así podremos rastrear los orígenes de los posibles intentos de ataque.

IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG)

Generalmente esta opción está desactivada, pero si está construyendo un host cortafuegos o para enmascaramiento, deberá activar. Cuando se envían paquetes de un host a otro, no siempre se envían como simples paquetes de datos, sino que se fragmentan en varios trozos. El problema es que los números de puerto sólo se almacenan en el primer fragmento. Esto significa que alguien puede insertar información en el resto de los paquetes para su conexión que se supone que no deberían estar allí.

IP: syn cookies (CONFIG_SYN_COOKIES)

El ataque SYN es un ataque de denegación de servicio (denial of service, DoS) que consume todos los recursos de su máquina forzando un reinicio. No podemos encontrar ninguna razón por la que no debiera activar esto.

Dispositivos del núcleo

Hay algunos dispositivos de bloque y carácter disponibles en Linux que también le resultarán utiles para mantener la seguridad de sus sistema. Los dos dispositivos /dev/random y /dev/urandom los proporciona el núcleo para generar datos aleatorios en cualquier instante. Por ejemplo, se utilizan para iniciar un número de secuencia para conexiones TCP/IP.

Ambos, /dev/random y /dev/urandom, deberían ser suficientemente seguros como para generar claves PGP, SSH y otras aplicaciones donde son un requisito números aleatorios seguros para generar claves válidas para una sesión. Los atacantes no deberían ser capaces de determinar el siguiente número dada cualquier secuencia de números con este origen. Se han dedicado muchos esfuerzos para garantizar que los números que se obtienen de esta fuente son pseudoaleatorios en todos los sentidos de la palabra pseudoaleatorio. La única diferencia es que /dev/random suministra bytes aleatorios y le hace esperar para que se acumulen más.

Seguridad de Red

Temas a desarrollar

La seguridad de las conexiones en red merecen en la actualidad una atención especial, incluso por medios de comunicación no especializados, por el impacto que representan los fallos ante la opinión pública. El propio desarrollo tanto de Linux, como de la mayoría del software que lo acompaña, es de, es de fuentes abiertas. Podemos ver y estudiar el código. Esto tiene la ventaja de que la seguridad en Linux no sea una mera apariencia, sino que el código está siendo escrutado por muchas personas distintas que rápidamente detectan los fallos y los corrigen con una velocidad asombrosa. Si además comprendemos los mecanismos que se siguen en las conexiones en red, y mantenemos actualizados nuestros programas, podemos tener un nivel de seguridad y una funcionalidad aceptables. Tampoco tienen las mismas necesidades de seguridad un equipo doméstico, con conexiones esporádicas a Internet, que un servidor conectado permanentemente y que actúe como pasarela entre una intranet e Internet.

inetd

Para atender las solicitudes de conexión que llegan a nuestro equipo existe un demonio llamado inetd que está a la escucha de todos los intentos de conexión que se realicen a su máquina. Cuando le llega una solicitud de conexión irá dirigida a un puerto, cuando llegue una solicitud de conexión al puerto se ejecutará el programa.

TCP Wrapper

El siguiente paso es el tcp_wrapper: un servicio que verifica el origen de las conexiones con su base de datos y los divide en dos categorías: equipos autorizados y equipos a los que se les deniega la conexión. tcpd anota todos los intentos de conexión que le llegan para que tenga la posibilidad de saber quién intenta conectarse a su máquina y si lo consigue. Si tcpd autoriza la conexión, ejecuta ipop3d que es el programa que realmente atiende la conexión, ante el cual se tiene que validar el usuario mediante una clave. Con este ya llevamos tres niveles de seguridad: prestar un servicio, autorizar una conexión y validar un usuario.

Un consejo que es conveniente seguir: No tenga abiertos los servicios que no necesita; esto supone asumir un riesgo a cambio de nada. Tampoco limite la funcionalidad del sistema, si tiene que usar un servicio, hágalo sabiendo lo que hace.

También hay que asegurarse de que el programa ipop3d no tenga ninguna vulnerablidad, es decir, que esté actualizado. Existen numerosos medios para estar al día de las vulnerabilidades que aparecen. Una buena lista de correo o una revista electrónica tal vez sean la forma más rápida de conocer los incidentes, las causas y las soluciones.

Pero esto no es todo, además puede filtrar las conexiones que le lleguen desde el exterior para que ni siquiera alcancen a los tcp_wrappers. Esto lo hacemos colocando una línea en el fichero, añadiendo un filtro de entrada que deniega desde cualquier sitio de Internet dirigidas a nuestro equipo; y además las anota en el registro de incidencias.

El mecanismo de filtrado de conexiones se realiza en el núcleo del sistema operativo y si ha sido compilado con estas opciones. Normalmente lo está. Este filtrado se realiza a nivel de red y transporte: cuando llega un paquete por un interfaz de red se analiza siguiendo los filtros de entrada. Este paquete puede ser aceptado, denegado o rechazado, en este último caso se avisa al remitente. Si los filtros de entrada aceptan el paquete, pasa al sistema si era su destino final o pasa por los filtros de reenvío o enmascaramiento, donde se vuelve a repetir una de las acciones. Por último, los paquetes que proceden del propio sistema o los que han sido aceptados por los filtros de reenvío o enmascaramiento pasan al filtro de salida. En cualesquiera de estos filtros se puede indicar que lo anote en el registro de incidencias.

Registro y conocimiento de incidencias

Puede conocer las incidencias que ocurren durante el funcionamiento del sistema. Por un lado conviene familiarizarse con los procesos que se ejecutan habitualmente en una máquina. Cualquier cosa extraña deberíamos aclararla. Puede matar cualquier proceso con la orden kill -9 pid . Pero en caso de ataque activo, lo mejor es desconectar de la red inmediatamente, si es posible, claro está.

Después tenemos los registros de incidencias (las ubicaciones pueden ser diferentes dependiendo del sistema, pero no radicalmente distintas). Trabajando en modo texto se puede hacer en una consola virtual (como root) y de esta forma podemos ir viendo las incidencias del sistema. Conviene también familiarizarse con las anotaciones que aparecen habitualmente para diferenciarlas de las que puedan presentar un problema.

En modo gráfico hay un programa llamado ktail que le muestra las incidencias de una forma similar al otro programa llamado ps axu.

Comunicaciones seguras

Por último, nos interesará mantener unas comunicaciones seguras para garantizar la privacidad e integridad de la información. Actualmente existen las herramientas necesarias para cada necesidad.

Podemos usar cifrados simétricos como pgp y gpg para documentos, correo electrónico y comunicaciones sobre canales inseguros

Podemos crear canales de comunicación seguros de distinto tipo:

SSH (Secure Shell), stelnet: SSH y stelnet son programas que le permiten efectuar conexiones con sistemas remotos y mantener una conexión cifrada. Con esto evitamos, entre otras cosas, que las claves circulen por la red sin cifrar.

Cryptographic IP Encapsulation (CIPE): CIPE cifra los datos a nivel de red. El viaje de los paquetes entre hosts se hace cifrado. A diferencia de SSH que cifra los datos por conexión, lo hace a nivel de socket. Así un conexión lógica entre programas que se ejecutan en hosts diferentes está cifrada. CIPE se puede usar en tunnelling para crear una Red Virtual Privada. El cifrado a bajo nivel tiene la ventaja de poder hacer trabajar la red de forma transparente entre las dos redes conectadas en la RVP sin ningún cambio en el software de aplicación.

SSL: o Secure Sockets Layer, fue diseñado y propuesto en 1994 por Netscape Communications Corporation junto con su primera versión del Navigator como un protocolo para dotar de seguridad a las sesiones de navegación a

través de Internet. Sin embargo, no fue hasta su tercera versión, conocida como SSL v3.0 que alcanzó su madurez, superando los problemas de seguridad y las limitaciones de sus predecesores. En su estado actual proporciona los siguientes servicios:

·         Cifrado de datos: la información transferida, aunque caiga en manos de un atacante, será indescifrable, garantizando así la confidencialidad.

·         Autenticación de servidores: el usuario puede asegurarse de la identidad del servidor al que se conecta y al que posiblemente envíe información personal confidencial.

·         Integridad de mensajes: se impide que modificaciones intencionadas o accidentales en la información mientras viaja por Internet pasen inadvertidas.

·         Opcionalmente, autenticación de cliente: permite al servidor conocer la identidad del usuario, con el fin de decidir si puede acceder a ciertas áreas protegidas.

Algunos Consejos para tener en cuenta

Limite las acciones que realice como root al mínimo imprescindible, y sobre todo no ejecute programas desconocidos. Por ejemplo, en un juego (el quake) que distribuía una revista había un programa llamado runme que enviaba por mail las características de la máquina a una dirección de correo. En este caso se trataba de un troyano inofensivo, pero ofrece una idea de lo que puede hacer un programa ejecutado sin saberse lo que hace.

Linux también tiene la posibilidad de proporcionar acceso transparente a Internet a una red local. En este caso, si usamos direcciones de red privadas, nos aseguramos que los equipos de la red interna no son accesibles desde Internet si no es a través del equipo Linux.

También podemos instalar un servidor proxy con caché, que a la vez que actúa de filtro de conexiones a nivel de aplicación, puede acelerar el acceso a servicios desde la red local.

Seguridad del Root

Temas a desarrollar

Generalmente, el mayor enemigo del sistema es su propio administrador ya que tiene todos los privilegios y cualquier acción puede ser irreversible y hacerle perder posteriormente mucho más tiempo que el que hubiera perdido por realizar las tareas de forma segura. Puede borrar cualquier fichero e incluso destruir el propio sistema, mientras que un usuario «normal» sólo puede perjudicarse a sí mismo. Por estos motivos, conseguir privilegios de root es la meta de cualquier ataque. De igual manera en un sistema operativo monousuario cualquiera podría darle formato al disco duro y perder toda la información almacenada o borrar cuaquier fichero necesario para el funcionamiento del sistema. En un sistema estilo Unix, como Linux, esto sólo lo podría hacer el usuario root.

La seguridad del administrador es simple, consiste principalmente en tener unos hábitos seguros y también en utilizar herramientas seguras. Una primera norma que siempre debería tener presente es usar la cuenta de root sólo para realizar tareas concretas y breves y el resto hacerlo como usuario normal. Es una costumbre muy peligrosa usar todo el tiempo la cuenta de root. Al principio, a los usuarios de Linux les gusta sentir todo el poder de la cuenta de root, les molesta que su propio sistema les deniegue el permiso para hacer algo, pero van cambiando de opinión cuando se van familiarizando con el sistema o cuando han realizado un destrozo. Piense que cuando el sistema le deniega alguna operación es porque puede conllevar algún riesgo.

En los casos de tareas que necesiten privilegios de administrador para realizar una operación concreta, podemos usar la orden «su» (Super Usuario) o también «sudo». Accediendo de esa forma a los privilegios de root sólo cuando nos interese.

Algunos consejos para tener en cuenta

Asegurarse de que en los borrados de ficheros por parte del root se pide confirmación.. Pero si en alguna ocasión tiene que borrar muchos ficheros y no quiere pedir confirmación para cada uno de ellos, puede usar una opción para no pedir confirmación, bien usar la orden «yes», para ir confirmando automáticamente cada una de las orden.

Procurar prever los resultados de una orden, sobre todo si usa comodines.

Vigilar la variable de entorno «PATH». Limite la búsqueda automática de ejecutables a las ubicaciones estándar del sistema. También se debe evitar incluir el directorio actual en esta búsqueda.

Evite tener directorios con permiso de escritura en la ruta de búsquedas, ya que esto puede permitir a un posible atacante modificar o poner nuevos binarios que se puedan ejecutar como root la próxima vez que ejecute una determinada orden. No utilizar las herramientas rlogin/rsh/rexec como root. Ya que pueden ser objeto de diversos tipos de ataques y es peligroso ejecutarlas como root.

Trate de evitar que la clave del root circule por la red sin cifrar. Si quiere ofrecer servicios de shell o ejecución remotas sobre un canal inseguro utilice herramienta que no cifre los datos de las conexiones.

Limitar las ubicaciones desde donde alguien se puede conectar como root al sistema. Especificando dichas terminales en el fichero(etc/security). Si tuviera que conectarse como root desde una ubicación distinta a la consola, hágalo como usuario normal primero y luego utilice «su» para acceder a los privilegios de root. Poniendo de está forma más dificultades para obtener privilegios remotos en nuestro sistema, ya que de está forma el atacante debería conocer el nombre de usuario del sistema, su clave y la clave del root.

Evitar siempre dar la clave de root a alguna persona. Si tiene que otorgar privilegios a un usuario para realizar alguna tarea de administración, , utilice “sudo” para permitirlo con la propia clave del usuario. Pudiendo de está forma decidir qué usuario tiene acceso a una determinada orden.

No modifique los permisos de un fichero o directorio si no sabe realmente qué está haciendo. Ya que los valores que trae la instalación de las distintas distribuciones suelen ser adecuados; jamás conectarse a un servicio IRC como usuario Root.

Preparación para la seguridad

Temas a desarrollar

La seguridad es un proceso continuo, que requiere tener previsto hasta lo imprevisible. Tener unos buenos hábitos y tomar unas pequeñas precauciones nos ayudarán mucho.

Determinar los servicios activos

Desactive todos los servicios que no vaya a prestar, en particular revise los ficheros /etc/inittab, /etc/inetd.conf y los demonios que se lanzan durante el arranque. Las distribuciones más modernas incorporan unos mínimos de seguridad aceptables para un usuario medio.

Puede usar un analizador de puertos para ver qué parte de su sistema es visible desde el exterior. Existen utilidades como SATAN, NESSUS, o Nmap que realizan esta labor.

Trinux es una minidistribución de Linux totalmente portable, que se puede usar desde cualquier equipo para la red. Se arranca desde el disquete y no utiliza el disco duro para nada. Contiene las últimas versiones de algunas herramientas muy prácticas enfocadas a la seguridad en redes. Nos permitirá analizar el tráfico de la red, analizar puertos e incluso ver el contenido de los paquetes que circulan por la red.

Maneras de proteger los ficheros importantes

Existe un parche para el núcleo Linux que impide que ciertos ficheros puedan ser modificados, incluso por el propio root. El núcleo parcheado de esta forma puede garantizarnos la integridad de la información almacenada incluso en el caso de que alguien consiguiera privilegios de root en nuestro sistema. Si no queremos aplicar el parche, sí que deberíamos vigilar los permisos de ficheros y directorios.

Software actualizado

La gran mayoría del sofware que acompaña a Linux es de código fuente público, como el propio núcleo. Esto es una garantía de seguridad en sí, debido a que cientos de expertos analizan minuciosamente el código. De esta forma nos garantizamos un software de calidad y no una mera seguridad aparente. Esto por otro lado nos obliga a ir sustituyendo las versiones defectuosas por otras corregidas y que mejoran las prestaciones. En cualquier sistema operativo, mantener un software que ha demostrado tener fallos supone asumir un riesgo innecesario.

Prevenir pérdidas de información

Existen acontecimientos de los que nos puede resultar muy difícil protegernos como son los desastres naturales o los desastres que pueda ocasionar un intruso en nuestro sistema, de cualquier ataque a la disponibilidad o integridad de la información del sistema.

Si los datos tienen un tamaño inferior a 650Mb, puede ser una buena opción grabarlos en un CD permanente o regrabable. Las cintas y otros medios sobre los que se puede escribir deberían protegerse tan pronto como se completa la copia y se verifica para evitar la falsificación. Hay que tener cuidado y almacenar las copias de seguridad en un sitio seguro. Una buena copia de seguridad le asegura que tiene un buen punto desde el que restaurar su sistema.

Características de las copias de seguridad

Cuando se realice una copia de seguridad es conveniente seleccionar un método que garantice la conservación de las características de la información como son derechos y permisos. Si realizamos una copia de seguridad de una forma o sobre un soporte que no contemple esta posibilidad, si tenemos que restaurar los datos sobre el sistema el resultado sobre la seguridad y funcionalidad globales puede ser impredecible.

Es necesario tener un política de copias de seguridad adecuada a las características de la entidad que estamos gestionando. Quizás el mejor método es el de rotación de cintas.

Copiar las Bases de Datos del Sistema

Existe cierta información del sistema que es imprescindible para su correcto funcionamiento. Es conveniente tener una copia de estos ficheros. En particular resulta conveniente tener una copia del contenido del directorio /etc., ya que tiene copias de los ficheros /etc/passwd y /etc/shadows, entre otros que puedan contener claves de usuarios que no están cifradas.

También en cada sistema se puede tener una base de datos de las aplicaciones que hay instaladas en el servidor. Cada distribución dispone de alguna herramienta que nos realiza el mantenimiento de la base de datos a la mism vez que instala o

desinstala aplicaciones. La pérdida de esta base de datos nos haría perder el control sobre qué aplicaciones tenemos instaladas.

En muchas situaciones también será necesario tener copia de seguridad de los ficheros de registro de incidencias, para tener constancia de las distintas actividades del sistema.

Recomendaciones para tener en cuenta:

Suscribirse a las listas de correo de alertas de seguridad para estar actualizado.

Prestar atención a los ficheros de registro.

Actualizar el software inseguro.

Verificar regularmente la integridad de los ficheros con algún software como tripwire.

Tener unas copias de seguridad adecuadas.

Utilizar PGP o GnuPG para garantizar la autenticidad y la privacidad.

Verificar con periodicidad los puertos de los equipos.

Revisar periódicamente las cuentas de usuario.

Asignar cuotas de uso de recursos del sistema.

Mantener los terminales seguros.

Asegurarse de tener claves sólidas.

Mantener el sistema de ficheros con propietarios y permisos adecuados.

Una vez vistas las características generales de seguridad, deberíamos armar nuestro sistema en base a los siguientes puntos:

·         Lo primero que tenemos que determinar es lo que queremos proteger. No será lo mismo una estación de trabajo personal aislada con conexiones a Internet esporádicas que un servidor web con conexión permanente.

·         También tendremos que considerar el coste de lo que queremos proteger: posible coste económico, tiempo de restauración o instalación, prestigio, perdida de clientes, etc. También el coste de la seguridad en unos términos parecidos a los anteriores. Sería absurdo que invirtiéramos más en protección que el coste de lo protegido.

·         Hay que considerar que existe una relación inversa entre seguridad y funcionalidad. Cuanto más seguro hacemos un sistema, menos funcional resulta, ofreciendo menos servicios y más limitaciones de acceso. Esto también constituye otro coste adicional: facilidad de uso.

·         Después de saber qué y de qué tenemos que protegernos, de quiénes y cuáles son sus posibles objetivos, y viendo los servicios que necesariamente hay que prestar o usar, obtendremos un esquema elemental de nuestra situación y de las medidas que tenemos que tomar.

Ruptura del Sistema

Temas a desarrollar

En caso de haber sufrido o estar sufriendo un ataque, conviene tener en mente una serie de normas que nos permitan una actuación rápida y certera que disminuya las consecuencias del incidente. Vamos a distinguir una serie de situaciones posibles y cómo se debe actuar.

Detección de un ataque activo

Se detecta un ataque que está actualmente en curso. El ataque puede ser de diversa naturaleza.

Ataque local

Cuando detectamos un ataque local tendremos que verificar la identidad del atacante. Se pude confundir a alguien de atacar el sistema cuando sólo puede que sea una negligencia a la hora de seleccionar una clave o abandonar abierta una consola.

Hay que verificar el origen de la conexión, los registros del sistema y los procesos que tiene activos. Tendremos que comprobar si son los habituales y qué es lo que se sale de lo normal. Averiguando datos sobre la persona que lo está haciendo. Si no tiene una conexión activa, habrá que profundizar en la investigación porque cabe la posibilidad de que alguien haya utilizado esa cuenta de forma ilegítima.

No hay que precipitarse para hacer acusaciones. Recopile todas las pruebas que haya detectado en los registros, procesos, modificaciones de información, etc. Sea rápido, pero seguro.

Ataque en red

Si el ataque se produce a través de la red podemos tener distintas situaciones. Puede ser conveniente espiar un poco al intruso para obtener más pruebas y después desconectar el interfaz de red si es posible. Si no fuera posible desconectar el interfaz, deberíamos usar algún filtro para las conexiones procedentes de la dirección del atacante. Existen programas como ipchains que pueden realizar esta labor. Si desconectamos el interfaz o denegamos los paquetes procedentes de esa dirección el intruso lo podría interpretar como un error de red, más que una detección del ataque. Si no se pudiera limitar el acceso a las direcciones que usa el intruso, intente cerrar la cuenta del usuario. Observe que cerrar una cuenta no es una cosa simple. Tiene que tener en cuenta algunos ficheros y otras posibles puertas traseras.

En general no es aconsejable apagar el sistema, esto podría hacernos perder la información que tenemos en memoria. En Linux podemos ver la lista de procesos que hay en ejecución y matar aquellos que puedan estar dañando al sistema.

Destino del ataque

Se puede dar la situación que nuestra máquina no sea el destino final del ataque. Puede que el intruso la haya utilizado como punto intermedio para atacar a otros sistemas e intentar dificultar el seguimiento de las pistas. En este caso, además de limitar las acciones del atacante deberíamos notificarlo al administrador del destino del ataque y conservar todas las pruebas existentes por si se pudieran reclamar judicialmente.

En cualquier caso, si queremos dar validez legal a las pruebas obtenidas, sería conveniente la intervención judicial.

Es habitual que durante los próximos minutos el atacante vuelva a intentar continuar con sus acciones, tal vez usando una cuenta diferente y/o una dirección de red distinta.

El ataque ha concluido

Ahora deberiamos dejar el sistema mejor que estaba antes de que ocurriera. Para ello determine los medios que usó el atacante para acceder a su sistema. Deberá analizar cuidadosamente los ficheros de registro del sistema. En ellos debería haber una información valiosa para seguir la pista de las actividades del intruso en nuestra máquina. Las causas más habituales son una mala configuración de algún servicio, un programa defectuoso o la negligencia de algún usuario con respecto a su clave de acceso.

Compruebe la existencia de nuevos «exploits» que pueda ser la causa u otros fallos que tenga que corregir. Si no elimina al atacante, probablemente volverá. No sólo a su máquina, sino a cualquiera otra de la red. Durante sus incursiones ha podido utilizar algún «sniffer», y disponer de información suficiente para tener acceso a otras máquinas locales.

Si sospecha que el atacante ha obtenido copias de algunos ficheros que contengan datos de usuarios y claves, sería conveniente modificarlas todas. Si tiene distintos usuarios en su máquína, oblígueles a cambir su clave. En general es preferible cambiar siempre las claves después de un incidente, una vez que sepamos que lo hacemos de una forma segura.

Verifique si se han modificado las limitaciones al acceso a distintas herramientas de administración remota. Puede que el atacante trate de abrir alguna puerta trasera para continuar aprovechándose de nuestras máquinas.

En algunos casos puede interesar antes de nada, hacer alguna copia de todo el disco duro para seguir investigando el incidente en otra máquina distinta que no esté conectada a la red y no perder una información que puede ser valiosa.

Evaluación de los efectos del ataque

El siguiente paso que hay que realizar es la evaluación de los efectos que ha tenido el ataque. Tiene que tener en mente la naturaleza del ataque para evaluar los efectos. Si ha sido una denegación de servicio es probable que el atacante no haya tenido acceso a la información local. Si tenía instalado algún programa, que verifica la integridad, el trabajo será menor. En caso contrario tendrá que verificar todos sus datos importantes. Verifique las fechas de creación de los ficheros binarios y si

detecta alguna incongruencia con la fecha de instalación puede empezar a sospechar. Si tiene la posibilidad, compare los tamaños de los ficheros con otro sistema «limpio».

Unas buena alternativa es volver a instalar el sistema. Guarde los ficheros de configuración para tener una funcionalidad idéntica a la previa al ataque. En Linux, los ficheros de configuración se almacenan en modo texto por lo que no son susceptibles de contener caballos de Troya. Eso sí, debería verificar que las configuraciones son las originales y no han sido manipuladas por el atacante. Reinstale el sistema y utilice las copias de seguridad para reponer los datos de los usuarios.

Hay que tener especial cuidado con las copias de seguridad. Tiene que estar seguro de que las copias de seguridad que está utilizando son previas a cualquier ataque. No se arriesgue a restaurar unas copias de seguridad que pudieran tener algún caballo de Troya; tenga un cuidado especial con los ficheros binarios que restaura.

Si cree que ha sido objeto de un ataque que no está documentado, debería notificarlo a alguna organización de seguridad como CERT o similar para que se pueda solucionar lo antes posible y evitar que otros sistemas lo puedan padecer.

Si ha conseguido información sobre el atacante, se lo debería notificar al administrador del dominio del intruso. Puede buscar este contacto con whois, con la base de datos del Internic o en RedIris.

Los buenos hackers con frecuencia usan sistemas intermedios. Algunos (o muchos) puede que ni sepan que han sido comprometidos. Intentar seguir la pista de un cracker hasta su origen puede ser difícil. Siendo educado con los administradores, le puede facilitar la obtención de la ayuda necesaria.