Guía de Seguridad en Red

Licencia y Garantía

Este documento se presenta sin ningún tipo de garantía. El uso de esta guía así como de sus consejos se encuentran bajo tu completa y exclusiva responsabilidad. El autor no se responsabiliza de los daños que se puedan ocasionar al seguir esta guía, sean del tipo que sean.

Los bugs y las imprecisiones en el texto están garantizadas (incluyo las faltas y errores gramaticales), sobre todo en esta primera versión.

La última versión de este documento la puedes encontrar aquí



Copyright Jesús Sutil (chacal) 2005 - versión 1.0



Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled \"GNU Free Documentation License\".

Requisitos

Como requisitos para el lector, espero que no sea necesario ninguno, al menos para entender la razón de las medidas tomadas, otra cosa sería ponerlas en práctica, para la cual se necesita un cierto manejo en el uso de un sistema GNU/Linux, puesto que voy a dar por supuesto que tenemos instalado lo que necesitamos, y en cuanto a las configuraciones, tampoco voy a hacer demasiado hincapié puesto que cualquiera con ayuda de la documentación del programa pertinente, podrá llevarla a cabo.

Prólogo

La seguridad, está tomando mayor importancia día a día, puesto que cada vez hay más conexiones a Internet y más prolongadas, y los servidores caseros, que están permanentemente conectados a la red, proliferan como setas. Y eso sin contar con los grandes servidores, aunque eso ya es otra historia puesto que muchos de ellos están detrás de un firewall implementado directamente en hardware, y estos no se cansan tanto. A estos se les suele llamar firewalls perimetrales, puesto que normalmente son los que cubren los primeros accesos de la red, a causa de su mayor robustez, por lo que muchas veces el peligro está dentro.



Al hablar de seguridad en red, nos referimos a seguridad remota es decir sin que el atacante tenga acceso físico al equipo atacado, porque entonces no hay seguridad que valga. Por lo tanto este aspecto no lo voy a tratar, no porque no sea interesante, sino porque tirando del cable de la luz o simplemente pulsando el botón de apagado, no hay mucho que hacer, salvo proteger la bios con contraseña para que la secuencia de arranque no permita al intruso arrancar otros sistema etc, etc, pero aún así, contra un destornillador todo está perdido, y eso si el ordenador no es pequeño, porque entonces sobra hasta el destornillador.

Introducción

A lo largo de esta guía, vamos a ver los principales aspectos a tener en cuenta a la hora de proteger un sistema. Vamos a usar un sistema GNU/Linux como banco de pruebas, es decir como equipo atacado, y en el vamos a probar y comprobar los distintos medios (software) que tenemos para proteger el equipo.



Hoy día al hablar de seguridad muchos lo asocian a un firewall, y la verdad que nada más lejos de la realidad. Es cierto que un firewall ayuda, pero no lo es todo. Los firewalls se deberían de poner como último recurso, esto no quiere decir que no se pongan, sino que se tienen que poner después de haber configurado correctamente la red. Un error que causa muchos disgustos es el dejar TODA la responsabilidad en cuanto a la seguridad a un firewall, y más cuando se trata de una red grande.



Nunca está de más dar un toque de atención, y recordar que por mucha seguridad que instalemos, si usamos passwords del tipo 12345, todo nuestro esfuerzo será en vano.

Reconociendo en entorno

Lo primero que vamos a hacer es echar un vistazo a la seguridad intrínseca de un sistema UNIX-like en nuestro caso GNU/Linux.



Antes de nada, dejar clara una cosa, el uso de la cuenta de administrador (root) queda restringida a tareas de administración. Lo normal si necesitamos permisos de root para realizar una tarea es utilizar \'su\' el cual abre un shell con identificadores distintos.



Una tarea común a realizar por root es la administración de usuarios y grupos. Comprender esto es fundamental. Aquí entran en juego varios archivos del sistema, y todos se encuentran bajo \'/etc\'. Esto archivos son passwd, shadow y group principalmente.



/etc/passwd

Cada línea de este fichero contiene la información relativa a un usuario. Y está estructurado de la siguiente forma:



nombre:clave encriptada:UID:GID:nombre completo:dirección personal:intérprete



un ejemplo típico podría ser este:



pepito:a$Zkjbh23JHu$432%&/:502:502:Pepito Grillo:/home/pepito:/bin/bash

/etc/shadow

Con \'shadow\' conseguimos una forma más segura de almacenar las contraseñas, un sistema que implemente shadow, no tendrá las contraseñas en /etc/passwd como vimos en el apartado anterior, sino que las tendrá en /etc/shadow, y en /etc/passwd se sustituirá la contraseña por una \"x\", quedándonos de la siguiente manera.



pepito:x:502:502:Pepito Grillo:/home/pepito:/bin/bash



El uso de shadow se ha extendido rápidamente por motivos de seguridad en los sistemas Unix-like, consiguiendo que además de no ser legible por todo el mundo, las claves shadow nos proporcionan opciones adicionales como expiración de claves.

/etc/group

Cada usuario, pertenece a uno o más grupos, y cada fichero tiene un grupo propietario. Los usuarios pueden pertenecer a uno o más grupos añadiendo sus nombres de usuario a los grupos que se requiera en /etc/group. Este archivo está estructurado de la siguiente forma



nombre de grupo:clave:GID:otros miembros



El campo clave, no se suele utilizar, pero sirve para poder usar una clave y así acceder a un determinado grupo. Esto suele estar deshabilitado para evitar escalado de privilegios, en este caso se pone el campo clave con un \'*\'.

Nota: en una clave no puede existir el carácter asterisco, por lo tanto si añadimos un asterisco a esa clave, ese usuario quedará deshabilitado.

/etc/gshadow

De forma análoga al shadow para los usuarios, también existe un shadow para los grupos, en este caso se llama \'gshadow\'

/etc/securetty

En este fichero se encuentran una lista con los tty desde los cuales root puede loguearse. Ya hemos comentado antes, que no es recomendable usar la cuenta de root, salvo para tareas de administración. Mi consejo es deshabilitarla, es decir NO permitir que root entre directamente en el sistema, es mucho mejor entrar como usuario, y una vez dentro hacer su o sudo.

Llegados a este punto, podemos plantearnos serias dudas en cuanto a la seguridad se refiere. Hace unos años no importaba que el archivo /etc/passwd pudiera ser leído por cualquiera, puesto que reventarlos era algo bastante difícil. La única forma era un ataque por diccionario o fuerza bruta. Por fuerza bruta, lo que hacemos es probar todas las combinaciones de palabras desde \'00000\' a \'zzzzz\', esto puede ser útil contra contraseñas de pocos caracteres, pero según llegamos a 7, se hace casi imposible usar este método. El ataque por diccionario, consiste en lo mismo pero con unas palabras ya definidas. ¿Como hacemos esto?, para esta ardua labor existen varios programas, entre ellos el que más me gusta es John the Ripper, el cual cifra y compara todas las palabras que le metamos por diccionario o en modo incremental con el password cifrado que nosotros queramos.



John the Ripper ofrece muchas opciones, y es muy rápido. Aunque parezca que este tipo de programas solo valen para hacer el mal, un administrador los encontrará muy útiles para buscar leak passwords, es decir contraseñas del tipo \'casa\', \'pepe\',\'12345\', etc. , de esta manera puede poner sobre aviso a ese usuario para que la cambie.



Aquí no voy a explicar el funcionamiento de este crackeador de contraseñas, por la red podéis encontrar numerosos manuales con ejemplos prácticos, pero lo mejor es intentar ponerlos en práctica aunque sea de forma local con las claves de nuestro propio ordenador.

Reconociendo en entorno II - Servidores y características.

Vamos a ver servicios de red típicos, como pueden ser de TFP, http, ssh, telnet ... y los problemas de seguridad intrínsecos que nos pueden plantear.



Telnet

Mediante el servicio de Telnet, accedemos remotamente a otra máquina, pudiéndola manejar como si estuviéramos delante de ella.

Este servicio plantea serios problemas de seguridad, sobre todo porque la autentificación de usuarios es a través de texto en claro. Esto permite que cualquiera con un sniffer capture nombres de usuario con sus respectivas contraseñas, con los problemas que eso supone.
Por eso resulta mucho más adecuado usar ssh, aunque si esto no es posible, lo más recomendable es restringir el acceso al puerto telnet (generalmente 23) mediante un firewall.

SSH

Al igual que telnet, ssh permite el acceso remoto a otra máquina. Pero en este caso la diferencia radica en la seguridad, puesto que la conexión es por canal seguro, y se encuentra cifrada. Aunque esto tampoco es infalible, y podemos ser víctimas de un replay entre otras. Pero siempre es mucho más seguro que un simple telnet.

FTP

(File Transfer Protocol) Este servicio permite transferir datos por la red, pero al igual que vimos con telnet, se pueden plantear problemas de seguridad puesto que las contraseñas también van en claro. Bien es cierto que el servicio ofrecido por un TFP dista mucho del ofrecido por telnet, pero no por ello nos libramos de los problemas de seguridad sobre todo si \'esa\' cuenta tiene permisos de escritura.



En cuanto a los servidores TFP disponibles, yo recomiendo el uso de vsftpd, que para mi es el más seguro. A la hora de configurarlo es recomendable que si lo vamos a usar como servidor multiusuario, es decir, vamos usar cuentas que no sean solo anonymous, prohibamos a los usuarios del sistema usar su login y password. Una guía concreta y detallada sobre la configuración de un servidor TFP con vsftpd, la podemos encontrar aquí

Secure FTP

Al igual que ocurría con telnet y ssh, tenemos el homólogo del TFP pero cifrado.

HTTP

Este es uno de los servicios más usados por los servidores. Existen muchos servidores, y muy buenos, aunque Apache a pesar de ser un poco más pesado es el más extendido gracias a su integración con php, cgi etc ...

Si fuera necesario, instalaríamos el módulo ssl correspondiente a nuestro servidor para crear un canal cifrado en nuestro servidor web, su uso está ampliamente extendido (como es lógico) en entidades bancarias, tiendas, servidores con información sensible, etc.

SMTP

Simple Mail Transfer Protocol, es el servicio de envío de correo. El servidor típico durante mucho tiempo fue el sendmail, actualmente desconozco su estado, pero es bien conocido por sus bugs y su costosa administración. Actualmente hay muchos servidores de correo y muy buenos.



Algo que no me gusta, es que se deje el puerto 25 (generalmente) abierto a todo el mundo y no solo a las máquinas desde las que se accede, esto posibilita el uso ilícito, por ejemplo como servidor fake-mail. Por lo tanto si nuestro servidor va a ser privado, es decir su uso se va a restringir únicamente para nuestra red interna es conveniente crear unas reglas adecuadas a nuestro firewall. Si nuestro servidor de correo va a ser público, podemos conseguir que SOLO los usuarios usen el servidor SMTP, para ello podemos obligarles a mirar su correo mediante POP antes de poder enviar nada, de esta manera conseguimos su IP, y podemos crear un firewall dinámico.

POP-IMAP

Post Office Protocol, es el complemento de SMTP, con pop podemos recibir, borrar y listar nuestros mensajes. IMAP, es algo parecido a POP, pero con más características, como por ejemplo descargar los mails sin attachments (archivos adjuntos) etc.
Aquí las contraseñas también van en claro, con el consecuente riesgo que eso conlleva. Para subsanar esto existe POP+SSL.

DNS

El DNS, es lo que realmente hace de Internet una palabra, puesto que en caso contrario necesitaríamos la IP del sitio al que queremos acceder. El servidor DNS más usado es BIND. Han aparecido vulnerabilidades críticos en BIND, pero se han resuelto sin mayores problemas, ya hace bastante tiempo que no ha aparecido ninguna. BIND es un servicio simple y rápido. Destacar que las direcciones privadas NO son enrutables, ej: 192.168.* o 10.*.

Samba

Este servicio se ha hecho muy popular, puesto que proporciona acceso a los ficheros e impresoras compartidos por sistemas Windows y viceversa. Una característica común en el uso de Samba es montar un servidor como PDC (Controlador Primario de Dominio). Aquí es recomendable usar la opción de cifrado de claves, como venimos comentando en otros puntos.

Existen muchos otros servicios (muchos de ellos obsoletos), como por ejemplo DHCP, NFS etc pero no los vamos a tratar de forma concreta. Solo daré cuenta de que un servidor DHCP, puede llegar a agotar sus recursos disponibles por medio de un ataque DOS.



Siendo paranoico habría que ejecutar los procesos servidor con chroot (los que pueden ...), aunque en algunos no es muy recomendable, pero no voy a entrar en casos concretos, para eso hay que leerse la documentación de cada servidor.

Nota: ejecutar un servidor como root y hacerle un chroot, lo podemos calificar casi como de estupidez.

También es lógico ejecutar esos procesos como usuarios NO privilegiados (y menos como root), por ejemplo como nobody. Tampoco hay que caer en la dinámica de hacer que nobody haga todo, puesto que muchas veces, y sobre todo en servidores administrados por varios admin, se usa a nobody (sin saberlo) para todo, convirtiéndolo en un usuario con muchos permisos. (Aunque hay algunos servicios que SI hay que ejecutarlos como root.)

Reconociendo en entorno III - Parches de Seguridad.

Desde hace tiempo, GCC incluye en el compilador las extensiones para compilar aplicaciones con protección extra y evitar así que las aplicaciones escriban en direcciones de memoria que NO deberían escribir.

la opción -fstack-protector, -fno-stack-protector habilita y deshabilita la protección.
la opción -fstack-protector-all, -fno-stack-protector-all habilita y deshabilita la protección.

En cuanto a los parches de seguridad disponibles para el Kernel, hay varios, destaco principalmente, el parche Skas, con el que conseguimos \"Separate Kernel Address Space\" es decir un espacio de direcciones separado.



Como comentario, hacer notar que SuSE desde hace tiempo trae de serie el parche skas.

Métodos avanzados de seguridad

De forma intuitiva, lo que voy a proponer, consiste en hacer que cada servicio (servidor), se ejecute con un kernel distinto. Esto lo vamos a conseguir mediante máquinas virtuales.



Existen varios proyectos, pero hay concretamente 2 que para nuestro cometido son mucho más flexibles, y consumen muy pocos recursos. Uno es User-Mode-Linux y el otro es VServer.



Con esto conseguimos aislar mejor cada servicio, teniendo que romper la seguridad de un kernel adicional, y en este podemos incrementar mucho la seguridad, concretamente con UML no necesitamos a root para (casi) nada.



Esta técnica cada día es más usada entre las empresas de hosting para ofrecer servidores virtuales a sus clientes.

Nota: La máquina en la que se ponga esto en práctica, necesitará tener unos recursos superiores a los que necesitaría sin usar estos métodos.

Configuración de red

Aquí vamos a ver los archivos típicos de configuración en un sistema GNU/Linux



/etc/inetd.conf

Con un man inetd.conf, obtenemos información adicional sobre inetd.
Durante la ejecución, inetd lee su configuración del archivo /etc/inetd.conf.
Para cada entrada (activa) en el archivo de configuración, le corresponde una línea, la cual consta de los siguientes campos.


service name/version
socket type
rpc/protocol
wait/nowait[.max]
user[.group]
server program
server program arguments




Como ejemplo, podemos ver una configuración para el puerto discard


discard stream tcp nowait root internal

discard dgram udp wait root internal




Por norma general NO es conveniente tener servicios en inetd, así que deshabilitaremos todos los que podamos.

/etc/services

En este archivo se definen los números de puerto, el protocolo, y el nombre del servicio asociado.
De forma genérica, se define así: nombre puerto/protocolo alias

Por ejemplo

www 80/tcp http # WorldWideWeb HTTP

/etc/hosts.allow y /etc/hosts.deny

Con un man hosts_access, obtenemos una gran cantidad de información, suficiente para poder configurar /etc/hosts.allow y /etc/hosts.deny. Aquí vamos a dar darle un vistazo comentando su funcionamiento y características importantes.



Cuando un cliente realiza una petición a un demonio (especificado en inetd), el software de control de acceso consulta estos dos archivos, y la consulta concluye cuando encuentra la primera coincidencia. Las acciones que realiza son:
- Acceso permitido cuando una pareja demonio-cliente coincide con una entrada en el archivo /etc/hosts.allow

- Sino, el acceso será denegado cuando una pareja demonio-cliente coincida con una entrada en el archivo /etc/hosts.deny

- En caso de que no se haya cumplido en ninguna de las dos opciones, el acceso será permitido

Al final del /etc/hosts.deny es bastante frecuente encontrarnos con líneas como estas


ALL: 0.0.0.0/0.0.0.0

ALL: PARANOID




Con las cuales sin la conexión no ha sido aceptada en /etc/hosts.allow, por defecto el acceso será denegado.



Si no existe archivo de control de acceso, se tratará como que existe un archivo vacío

Logs - Seguridad Pasiva

Esta es una parte fundamental de cualquier sistema que se precie, y un buen administrador debe de revisar a menudo los logs, para comprobar si se ha puesto en juego la integridad del sistema, (y otros aspectos que no vamos a tratar aquí).



En Linux, la herramienta de log es syslogd, el archivo de configuración principal se encuentra en /etc/syslog.conf, en el se indica que se loguea y donde se guardan estos logs. Para núcleo (kernel), el login se hace mediante klogd. Lo normal es que klogd envíe sus mensajes a syslogd, pero no siempre es así, sobre todo en los eventos de alta prioridad, que directamente salen por pantalla. Aunque bueno, esto siempre es configurable a gusto del consumidor.



Y como siempre podemos encontrar información adicional en los respectivos \'man\'.



Como regla general los logs se encuentran dentro del directorio /var/log. Muchos programas, manejan sus propios logs, y suelen crear una carpeta con el nombre del programa dentro de /var/log.



Una cosa muy importante a tener en cuenta en los logs, sean de la naturaleza que sean, es que la configuración que viene por defecto suele estar bien para ir tirando. Pero hay veces que un servicio necesita información adicional, pero ojo, no la vayamos a preparar. Los logs ocupan espacio, y podemos llegar a hacernos un DOS a nosotros mismos, así como llegar a saturar nuestro disco. Por ello hay que saber lo que se hace, y leer detenidamente la documentación de cada uno.

Nota: Crear una partición única para logs es una técnica muy empleada, de esta forma en caso de que un proceso de logging se ponga a escribir como un loco sea por la razón que sea, llegará un momento en el que el disco se llene y dejará de escribir. De otra forma, el disco también se puede llenar, pero el problema en si no es el quedarnos sin espacio, sino lo que esto conlleva.

Los logs aunque pueda parecer raro, contienen información valiosa. Hay veces en las que conviene enviar los logs a un servidor aislado que exclusivamente trate nuestros logs. De esta forma si un agresor se hace con nuestra máquina, podríamos seguir teniendo la baza de los logs, es decir, la certeza de que no han sido modificados o borrados, eliminando así cualquier rastro.
Por eso aunque sea más seguro el cifrar los logs, no tiene mucho sentido si en atacante tiene acceso a ellos, puesto que nos da igual no tener logs que tenerlos modificados. Realmente no nos da igual, porque si el atacante modifica los logs, podemos tenerle espiando nuestro sistema indefinidamente sin que nosotros nos demos cuenta. Aún así veo más conveniente el enviarlos a otro servidor.

Nota: Por supuesto la transmisión de logs al otro servidor lo haríamos a través de canal seguro. El envío de esos logs, lo podemos hacer a través de tuberías (man mkfifo)

Aunque creo que es evidente, dentro de nuestro sistema lo lógico es que nadie pueda ver nuestros logs, y menos modificarlos, por eso les daremos permisos únicamente a root y su grupo (man chown y man chmod).

Nota: Los logs se almacenan en archivos planos de texto, pero con el tiempo esos archivos se vuelven muy extensos. Por ello el sistema los va comprimiendo (y aplicando una rotación de archivos), y les va añadiendo la extensión .1.gz, .2.gz etc. A la hora de hacer scripts para visualizarlos, para ver los que están comprimidos, podemos usar zcat.

Ahora vamos a ver algunos de los log más comunes y útiles para nuestro propósito, y como habilitar otros. Por orden alfabético, nos encontramos con



/var/log/auth.log

Este archivo de log, es fundamental, en él se registran los login en el sistema, así como las veces que hacemos \'su\' etc. Los intentos fallidos, se registran en líneas con información del tipo invalid password o authentication failure, lo cual es muy útil a la hora de crear un script que compruebe todos los logs, puesto que con un simple grep \"invalid password\" filtramos las líneas que queremos.

/var/log/kern.log

Aquí se almacenan principalmente los logs producidos por klogd.

/var/log/lastlog

Este log nos muestra la información sobre el último acceso de un determinado usuario. La forma de ver esto es a través del comando lastlog, en este caso con un simple \'more\' no sirve, puesto que está en formato binario. Cuando hacemos un finger o un who, accedemos a lastlog.



La información contenida aquí es bastante importante, por eso, si tenemos cuentas shell en nuestro servidor, es conveniente no dar permisos para esos comandos, y así evitamos dar información adicional a los usuarios, (como los login de otros usuarios).

/var/log/messages

En este log podemos encontrar los logs que llegan con prioridad información o notificación. Lo más llamativo puede ser el log del netfilter.

Si en nuestro sistema se permite (por necesidad claro está) que los usuarios tengan cuenta shell en el servidor y se logueen, deberíamos tener activos tanto el faillog, cuyo log se encuentra normalmente en /var/log/faillog, para poder controlar las cuentas a las que se intenta acceder mediante \"try\'n\'error\" (ensayo y error), porque puede ser que el usuario haya olvidado su contraseña, pero también puede ser que alguien de forma malintencionada esté intentando acceder al sistema con esa cuenta.



En el archivo /etc/login.defs podemos definir que los intentos de log de superusuario se guarden en por ejemplo /var/log/sulog, sin más que editar el /etc/login.defs, y escribir (o descomentar) la línea SULOG_FILE /var/log/sulog, y SYSLOG_SU_ENAB yes. Esto al igual que lo comentado anteriormente, puede ser útil. Y en caso de sufrir múltiples intentos para escalar permisos, podemos bloquear temporalmente esta cuenta.

Notas (paranoicas de menor a mayor)



1 - Montar una red (honeynet) para cazar a los malos o al menos tenerlos entretenidos un buen rato. Sobre esto hablaremos más adelante.

2 - Llegando a rozar la línea entre la paranoia y la locura, puedes imprimir a la vez que suceden, los logs en papel, de esa manera a pesar de que el intruso los modifique una vez dentro siempre vas a tener las pruebas. (Pobre selva ...)

3 - También podemos crear un liveCD de nuestro sistema y arrancarlo desde ahí, de esta manera la escritura va a ser imposible :S (Esto es un poco fantasía, pero lo he leído varias veces)

4 - Una que me gusta, es el poder tirar todas las conexiones cada vez que ocurre una anomalía. (Se que esto es muy ambiguo, pero solo son ideas).

5 - Cualquier otra fumada que se te ocurra o se le haya ocurrido a otro ...

Controlar a los usuarios

Nota: Hay que tener especial cuidado con la shell de nuestros usuarios. Un aspecto importante es la opción historial en bash. Aquí se almacenan procedimientos de otros usuarios, nombres de archivo, etc. En caso de no ser necesario, simplemente porque las tareas que se realizan no lo requieren, se puede deshabilitar.

Controlar a usuarios con una cuenta shell es una tarea un tanto tediosa y pesada. Y aunque creamos tener controlados todos los aspectos posibles (el usuario no puede hacer nada no permitido), hay que tener en cuenta que ese usuario puede consumir mucha CPU, tiempo (y espacio) de disco, memoria, etc. etc., por eso hay que regularlo.



Mediante quote, podemos evitar que los usuarios nos saturen el disco. Para habilitar las quotas, necesitamos tenerlas habilitadas en el kernel, en caso de no tenerlas, toca recompilar.



Para controlar la memoria, el tiempo de acceso a disco y demás opciones, lo podemos hacer con ulimit, pero ya está obsoleta, así que lo hacemos con getrlimit, getusage y setrlimit. Para más información mirar las correspondientes páginas del man.

Herramientas I - Escaneadores de Red

Aunque hay muchos, los más destacables hoy día por sus múltiples funcionalidades que los hacen imprescindibles para cualquier administrador de red son Nesus y NMap (Network MAPper).



Nessus es un escaneador de redes un tanto peculiar, y es que consta de dos partes, cliente y servidor (aunque se pueden instalar los dos en el mismo sistema) y además, se pueden ver informes sobre la vulnerabilidad y como explotarla, pero como no todo es malo, también los hay para saber como evitarla. La parte servidor es la que escanea, y la parte cliente no es más que el interfaz de usuario.



NMap es quizás el escaneador de red más potente que existe, tiene una gran cantidad de opciones de escaneo como escaneo Stealth (lo cual es muy útil para escanear sin ser descubierto) o búsqueda de conexiones semiabiertas. Es ideal para comprobar nuestros sistemas (y a veces los de otro, pero solo por hacer un favor :)

Herramientas II - Herramientas de Detección de Intrusos

Un sistema de detección de intrusos (IDS - Intrusion Detection System), lo que hace es buscar patrones sospechosos previamente definidos. En principio no están diseñados para evitar un ataque solo para preverlo y monitorizarlo, estos son los llamados IDS pasivos. Los que si actúan sobre el \"presunto\" atacante son los IDS activos, estos lo que hacen es tirar la conexión o bloquearla (si es posible).



Como ejemplo de patrón sospechoso, principalmente tenemos un escaneo de puertos sea cual sea su magnitud.



Snort lo que hace es precisamente lo que hemos comentado, rastrea los paquetes que circulan por la red y al encontrar un paquete sospechoso lo loguea, de esa manera tendremos localizado el ataque. Snort puede funcionar como HIDS (Host) o NIDS (Network). Normalmente el uso como NIDS lo llevan a cabo gateways perimetrales que tienen otras funciones como firewall etc, y son configurados como IDS activos, puesto que la conexión tiene que pasar por ellos y de esa forma la pueden bloquear.



La configuración de Snort se puede llevar a cabo de manera fácil junto con mysql para guardar los logs en una base de datos y con ACID (Analisys Console for Intrusion Databases) para poder verlos de una forma cómoda.



Una ventaja de Snort es que tiene gran cantidad de filtros ya definidos, así como actualizaciones en las que se van añadiendo nuevos métodos que van apareciendo.



A la hora de configurar un IDS, hay que tener muy en cuenta la velocidad de la red y el tráfico que soporta, puesto que se puede saturar, y colapsar la red (o el segmento que controla).



PortSentry es un IDS especial con el cual podemos conseguir \"burlarnos\" del atacante. Lo que hace Portsentry es escuchar en un montón de puertos. Es decir que si un atacante nos escanea verá que hay un montón de puertos abiertos, pero NO es cierto, pero a ojos del atacante puede resultar tentador.



Si tenemos un servicio escuchando en un puerto, el Portsentry lógicamente no estará escuchando en ese puerto puesto que ya hay un servicio haciéndolo. Por eso cuanto mayor sea el número de servicios que tiene el servidor menos efectivo será el Portsentry. Por eso también es recomendable tenerlo en un router.



En cualquier caso a priori no se puede determinar que puertos son \"reales\" sin que salte la alarma, y es aquí donde radica el potencial de Portsentry. Si intentamos establece una conexión remota con un puerto abierto por Portsentry, automáticamente lo loguea y tira la conexión. Esto hace que aparezcan muchos logs, aunque si lo pensamos detenidamente nos damos cuenta que ese alguien ya está buscando \"algo más\".



En cambio, si el atacante envía un SYN y nosotros enviamos un SYN-ACK en nos mandará un RESET, y de esta manera no terminará la conexión (Three Way Handshake) y no llegará a existir log. Esta técnica se denomina Stealth Scan, y la podemos llevar a cabo con NMap con la opción \"-sS\".



Pero la historia no acaba aquí, porque Portsentry también puede detectar stealth scan, pero no a nivel de establecimiento de conexión, lo cual lo hace más difícil de detectar, pero aún así Portsentry se porta excepcionalmente bien.



Lo comentado es aplicable a escaneos TCP no a UDP. Comentar también que los escaneos UDP son menos fiables y además bastante más lentos al no ser un protocolo orientado a conexión. Existen muchas más formas de escaneo con los que se puede intentar engañar al IDS para que no loguee el escaneo de puertos, pero sea como sea si tenemos el Portsentry en modo no stealth, no hay forma de diferenciar los realmente abiertos de los que el Portsentry \"abre\", por lo que acabará siendo logueado.



Configurar unas buenas reglas de Firewall (Iptables) siempre es altamente recomendable aunque en el caso del Portsentry pueda interferir negativamente, es decir se puede ver que está el Portsentry activo. Pero con una configuración adecuada se puede subsanar. Básicamente consistiría en abrir los puertos en los que el Portsentry está escuchando.

Herramientas III - Sniffers

Hoy día Snort es uno de los sniffers más usados gracias al éxito que ha tenido con IDS como ya comentábamos en el punto Herramientas II, al ser un solución rápida y barata sobretodo si las comparamos con ISS RealSecure.



Ethereal es un sniffer capaz de reconocer casi todos los protocolos existentes. Tiene una gran potencia gracias a sus filtros que usan el mismo formato que el tcpdump. Comentar que su uso es bastante complejo.



Un sniffer por software necesita de un equipo bastante potente, para que pueda escanear todo lo que pasa.

HoneyNETs - HoneyPOTs

Para \"cazar\" a los malos podemos recurrir a los HoneyPOTs que no son más que ordenadores trampa, que se hacen pasar por sistemas vulnerables o por el servidor al que teóricamente se está lanzando el ataque.



Las configuraciones son múltiples y variadas, pero siempre dependientes de la cantidad de dinero empleada.



Los usos pueden ser muchos, desde guardar/loguear el tráfico de un posible ataque, hasta ralentizarlo.



En linux tenemos honeyd principalmente. Lo que hacen es simular nuevos hosts en la red con determinados servicios, para que se hagan pasar por lo que queramos. Como ya comentaba antes, la creación de honeypot-(nets) depende mucho del dinero invertido, programas como honeyd nos abaratan mucho los costes, pero no dan tanta versatilidad ni potencia como una red real



Una implementación bastante simple pero efectiva es usar un pequeño router de 4 u 8 puertos para segmentar la red en subredes, de esta forma podemos usar el router como firewall para esa pequeña red, y dentro de esa red poner un honeypot con los puertos típicos abiertos mediante NAT en el router. Después en los otros ordenadores, abrimos los servicios que necesitemos en puertos elevados, de esa forma cualquier escaneo que a priori no conozca los puertos será logueado.



A la hora de instalar un honeypot, podemos hacer que sea mucho más \"dulce\" simulando además que es un sistema operativo totalmente diferente o lleno de bugs conocidos, para lograr entretener más al atacante.



Si nuestra red en muy extensa viene muy bien centralizar los logs en una colmena, para que en caso de tener que hacer uso de ellos no sea una tarea excesivamente tediosa el tener que ir recolectando logs de todos los honeypots.

Copias de Seguridad

La copias de seguridad hay que acostumbrarse a hacerlas periódicamente. Por ejemplo cada 3 meses en un formato óptico (cds, dvds) y cada mes en una réplica (otros discos duros). Las cintas a pesar de ser más lentas tampoco están mal si la disponibilidad en caso de fallo no es inmediata.



Si eres de los que te preguntas, ¿por qué hacer copias de seguridad?, la respuesta es, \"por lo que pueda pasar\". Esto es un poco como la ley de Murphi, nunca pasa nada hasta que pasa. Ya sea por un \"rm *\" de forma accidental desde un mal sitio (por no poner otros parámetros...), pasando por un apagón o porque al disco duro le llegó la hora o como venimos viendo, por un ataque.



Para este propósito podemos usar bacula, con el cual podemos centralizar el backup. Esto es especialmente útil en redes heterogéneas.

¿Qué hacer si somos atacados?

Esto es una decisión que tiene que tener en cuenta muchos factores, pero sobre todo saber si ese ataque se sigue produciendo en ese momento o ya ha finalizado.



Si el ataque se está produciendo, es posible identificar al atacante, y también es recomendable sobre todo a la hora de tomar acciones legales contra el agresor. Pero lo más acuciante es comprobar la integridad del sistema y hasta el punto al que ha llegado la incidencia. Una vez hecho esto hay que parchear el agujero de seguridad, ya sea con una actualización (en caso de no existir actualización, reportarlo) o tirando el servicio hasta que se pueda actualizar.



En caso de no poder actualizar y no poder prescindir del servicio, habría que iniciar el servicio con un mínimo de opciones (si es posible) y optar por bloquear la IP del atacante y si pertenece a un ISP identificado, quizás convenga bloquear el rango completo de IP\'s de ese ISP, especialmente si el ataque viene desde otro país con un idioma distinto al que damos desde ese servicio, puesto que el número de clientes potenciales desde esas IP\'s será bajo y hay más posibilidades de librarnos de un segundo ataque.



Si el ataque ya se ha producido, tenemos que jugar con lo que tenemos que normalmente son los logs. Y digo \"normalmente\" porque no siempre los tenemos. Por este motivo toman un especial sentido las HoneyNETs.



Tomar medidas legales no siempre puede resultar adecuado, sobretodo en el caso de una empresa que haga gala de la seguridad, lo cual llevaría a una publicidad muy poco adecuada.

A tener en cuenta a la hora de conectar un PC a la red

Conectar un PC a Internet entraña sus riesgos. Normalmente un ordenador personal no está encendido las 24 horas como lo está un servidor por lo tanto la probabilidad de sufrir un ataque es menor. Pero esto no quiere decir que podamos descuidar la seguridad.



Si alguien toma el control del sistema y no nos damos cuenta, todo lo que se haga desde nuestro PC es como si lo hubiéramos hecho nosotros, lo cual puede traer desagradable sorpresas.



Si usamos un sistema \"unix-like\" tampoco hay que volverse paranoico con estos temas si el uso que le damos va a ser de PC de sobremesa.



A pesar de que la seguridad en sistema linux medianamente bien configurado es bastante alta, sigue sin ser un sistema adecuado para guardar información sensible. Para guardar información sensible, de forma simple y rápida, se puede recurrir al cifrado, ¡pero OJO! no dejemos las claves en el ordenador, si es posible las movemos a un CD o un lápiz USB.



NOTAS

En un PC de escritorio es muy común usar programas p2p. En el funcionamiento normal de este tipo de programas podemos suponer que son seguros. Pero nos tenemos que dar cuenta de que nuestra IP estará visible para cientos de usuarios, y siempre hay alguno que se aburre lo suficiente como para realizar ataques indiscriminadas por ssh a todos aquellos que por ejemplo usan el amule. Por lo tanto repito lo que comentaba al principio de la problemática de tener passwords débiles y/o servicios innecesarios.

También es muy común el uso de sudo o similares para dar privilegios a los usuarios. Desde mi punto de vista es totalmente desaconsejable puesto que normalmente sudo == password débiles

Conclusiones

Con esta guía pretendo dar una visión general sin entrar en demasiados detalles sobre métodos de seguridad en red con los que es estoy más familiarizado, concretamente con sistemas unix-like y más concretamente debian. La idea principal que quiero dejar patente es que la seguridad no es algo secundario y de lo que se pueda prescindir, sino que es muy necesario.



En estas breves conclusiones voy a comentar un par de aspectos por los que he pasado de puntillas en el resto de la guía.



- Un aspecto por el que no he pasado es el de los antivirus, y no lo he hecho por la simple razón de que no existen. Esta afirmación es un tanto arbitraria e incierta, porque si existen virus para sistemas Unix-like, pero tal y como está diseñado su impacto sería mínimo. De hecho el término virus en Unix se confunde con el de troyano. No obstante existen potentes antivirus para sistemas Unix-like por ejemplo el ClamAV, aunque su uso común es para buscar en busca de virus en un gateway que da salida a una red con sistemas NO Unix-like.



- Otro tipo de ataque del cual no he hecho una mención explícita, es un ataque DOS (Denial Of Service - Denegación de Servicio). La problemática de estos ataques es que son casi imposibles de evitar sin tener ningún tipo de secuelas, ya sea carga de cpu, una reducción del ancho de banda etc. Son un tipo de ataques muy molestos porque no tienen solución directa, es decir que cualquier sistema los puede sufrir, otra cosa es que ese sistema que lo sufre sea capaz de aguantar la embestida sin colgarse.

Referencias

Sería imposible llegar a nombrar todas las fuentes de información que directa o indirectamente he consultado, o he encontrado por el camino, durante todo el tiempo que estado escribiendo esta guía. Por lo tanto estas Referencias más bien se van a convertir en agradecimientos a todos aquellos que colaboran en la gran comunidad que se ha formado en torno a la red. Sobre todo a la comunidad OPEN SOURCE.