En el sistema propuesto, el terminal dispone de un modo de funcionamiento privado donde este envía una petición PER (Privacy Enabling Registration) a la red del operador; dicha petición consiste en un mensaje de certificación que valida al usuario y un valor aleatorio denominado RET (Random Equipment Tag), que se incluirá en los registros VLR (Visitor Location Register) y HLR (Home Location Register) del operador, los cuales permiten enrutar y mantener las llamadas, pero sin asociarlos a un usuario determinado (los siguientes mensajes de registro incluyen peticiones PET en lugar del número de télefono).

En España, la Ley de conservación de datos relativos a las comunicaciones electrónicas y a las redes públicas de comunicaciones (Ley 25/2007 de 18 de octubre) indica que los operadores de telefonía móvil con servicios prepago deberán registrar la identidad de los clientes que acceden a la red. Aparte de esta ley, cada vez es más habitual que la privacidad y el anonimato en la red se muestren como una problemática real, y ya comienzan a aparecer servicios de Internet integrados con sistemas de identificación como el DNI electrónico, como por ejemplo ha hecho Tuenti recientemente.

Sin entrar en detalles técnicos que seguro que hay muchos que se me escapan y a la vista de un entorno legislativo y político cada vez más preocupado por trazar y registrar todo tipo de comunicaciones, ¿piensan que un sistema así podría ser factible? Y desde otro punto de vista, ¿es necesario o deseable?

La posibilidad de que ataques cibernéticos afecten al normal funcionamiento de infraestructuras claves para el sostenimiento de las sociedades modernas es una causa creciente de preocupación entre todos los agentes implicados. Prueba de ello son los recientes desarrollos normativos que están teniendo lugar y que en nuestro país se sustancian en la Ley de Protección de Infraestructuras Críticas y el Reglamento que la desarrolla.

Una de las características del temor que produce esta amenaza proviene del hecho de que no sigue una de las reglas establecidas de los enfrentamientos a que la sociedad está acostumbrada: identificar al enemigo. En efecto, hasta este momento los ataques contra una sociedad se producían en el contexto de una guerra o un ataque terrorista. El enemigo, por tanto, era conocido (incluso en el caso de ataques terroristas, ya que estas acciones buscan que la parte atacada sepa quién infringe el daño). Ahora, sin embargo, se toma conciencia de que elementos claves de una sociedad pueden ser atacados inadvertidamente y por un enemigo sin rostro, del cual, además, se desconocen sus motivaciones y por tanto no podemos prever su forma de actuar. Incluso se nos puede atacar de forma remota sin necesidad de encontrase físicamente entre nosotros.

Sin embargo, por muy novedoso que nos pueda resultar esto, en una fecha tan temprana como 1961, mucho antes de los ordenadores personales y las redes de comunicación, ya se previó que una eventualidad como ésta se podría producir. Hablamos de A por Andrómeda, una serie de televisión de la BBC que posteriormente se trasladó a novela, escrita por Fred Hoyle (físico especialista en cosmología) y John Elliot (productor de televisión).

¿Y cómo tenía lugar un ataque de este estilo en la infancia de las TIC? Avancemos el argumento aunque sin revelar el final, por si alguien siente interés en acudir a las fuentes por sí mismo.

En el radiotelescopio más avanzado del mundo, recién construido en Inglaterra, se recibe de pronto una señal cíclica procedente de un punto del cielo en la constelación de Andrómeda. Tras descartar un origen terrestre o incluso un satélite artificial (el Sputnik I se lanzó en 1957 y en 1961 el total de artefactos en órbita se podían contar con los dedos de una mano) los científicos responsables llegan a la conclusión de que se trata de una señal de origen genuinamente extraterrestre. Tras realizar un análisis del mensaje con los medios informáticos de la época (toneladas de equipo a base de válvulas y cables con interfaz por medio de tarjetas perforadas) se concluye que éste consta de tres partes: la primera son las instrucciones para construir un computador de potencia desconocida en la Tierra, la segunda parte es el programa que se ejecutará en ese computador y la tercera los datos sobre los que el programa debe trabajar.

Con toda la parafernalia de secretismo, instalaciones militares, etc. habituales se lleva a cabo la construcción y puesta en marcha del supercomputador (que naturalmente necesita un edificio completo para alojarlo y cuya sala de control se encuentra en el interior de la propia máquina). Y sin embargo, tan pronto se comienza a proporcionar datos a la máquina y recibir sus respuestas John Fleming, el investigador principal, siente que el supercomputador tiene un interés propio, representando la voluntad de los emisores de la señal desde un lugar tan remoto como desconocido…La máquina ejecuta un programa con un fin ignoto mientras los científicos proporcionan los recursos físicos que va demandando. En ese momento Fleming toma conciencia de que posiblemente se enfrentan a un dispositivo destinado a tomar el control de la Humanidad.

La serie/novela avanza interesantes cuestiones relativas a la inteligencia artificial, computadores, ataques cibernéticos y guerra biológica a pesar de que la materialización de la tecnología pueda resultarnos actualmente absolutamente arcaica. De hecho, posiblemente sea la primera descripción detallada de un ataque deliberado mediantes medios cibernéticos, a distancia y sin conciencia de peligro por la parte atacada. Y es que, realmente, no hay nada nuevo bajo el sol…

Una nota final para los interesados. Lamentablemente sólo se conserva uno de los episodios de la serie original y no existen ediciones actuales en castellano por lo que, si queréis conocer el resto de la historia, deberéis recurrir a una de las versiones en inglés que se hicieron posteriormente o leer el libro “A for Andromeda” (Amazon).

Parece un mal endémico del personal técnico el no tener una buena capacidad de redacción y síntesis; podemos hablar sobre multitud de conceptos técnicos, utilizando una infinitud de palabras en inglés pero parece que no seamos capaces de sintentizar y trasladar a un lenguaje más coloquial un incidente de seguridad que hayamos detectado.

Repasando un documento de ENISA sobre ejercicios para la gente de un CERT, revisé el que habla del contacto con terceros para la notificación de un incidente. En este ejercicio se practica la forma en que se avisa a los interesados de algo que ha ocurrido, cuáles han sido las posibles consecuencias y qué deseamos que hagan para solucionarlo.

Esto que parece tan simple, en ocasiones se convierte en un correo electrónico con un texto “copy-pasteado” hecho con retales de otros correos, con información sin aclarar muy bien de dónde sale o qué representa y con unas instrucciones un poco vagas. Por esto, quería recoger las ideas que propone ENISA para la redacción de una buena notificación.

Por mi experiencia, el correo debe ser breve y conciso en lo que se desea transmitir, y ajustarse al perfil del destinatario del correo, normalmente personal técnico pero sin grandes conocimientos de seguridad, para que este correo no genere rechazo.

Lo primero de todo es presentarse. En un par de líneas, debemos decir quiénes somos. Este paso tendrá que omitirse si ya nos conocen porque no queremos resultar repetitivos ni queremos que se vea nuestro correo como algo automático que redactamos sin pensar. No podemos dejar que la información empiece en el tercer o cuarto párrafo, que es lo que realmente queremos transmitir del incidente.

Lo segundo es una descripción clara de lo que ha ocurrido. Debemos dejar de lado los tecnicismos, las definiciones extensas o referencias a otros sitios. “Ha recibido un ataque al servidor web tal desde tal, cuyas consecuencias han sido/han podido ser…” sería una forma aceptable. Pensadlo un momento. A un responsable de departamento le dará igual si ha sido una inyección SQL en el parámetro id del recurso vulnerable.php, poniendo nosequé cosa o si se trata de un RFI apuntando a un servidor de Rusia o Botswana. Esto puede ir más adelante, pero no en este momento, donde queremos transmitirle lo que ha ocurrido y el impacto que haya podido tener. Debemos evitar extendernos demasiado. También facilitará la lectura y evitará que confundamos al receptor. Un párrafo únicamente a modo de resumen ejecutivo será más que suficiente.

Ahora las evidencias. Una vez ha comprendido lo que ha ocurrido, podemos explicarle el cómo. Ya podemos nombrar qué técnica o herramienta se ha utilizado o qué vulnerabilidad ha sido explotada; podemos hablar de siglas y aportar cuantas evidencias tengamos de nuestros registros de cortafuegos, IDS o cualquier sistema de monitorización que ayude a entender técnicamente lo ocurrido. Qué impacto y consecuencias ha podido tener, por qué ha ocurrido ahora (algún servidor desactualizado, por ejemplo); pero tampoco sin llegar a aburrir. Ofrecer la mayor información posible no significa aportar la mayor cantidad de datos. Copiar una captura del registro de alertas del IDS repetidas, aunque sea una docena, no aporta nada y puede causar un efecto disuasorio. Si tenemos más datos, se puede entregar como adjunto pero las evidencias técnicas deben ser las mínimas necesarias para comprender el alcance y su impacto. En un par de párrafos con referencias a los archivos adjuntos podemos dejarlo claro.

Por último, tenemos las acciones que queremos que tomen. Quizá sea necesario que nos aporten más información para conocer el alcance o efectividad del incidente; o quizá queramos que reinstalen un sistema por completo, pero debe quedar lo más claro posible aquello que queremos que hagan. Hay que evitar ambigüedades o acciones poco precisas, teniendo en cuenta que quizá no tengan muchos conocimientos de seguridad. También hay que dejarles a ellos un poco de margen de maniobra, ya que ellos conocerán mejor que nadie sus sistemas y qué acciones pueden ser las mejores, pero habrá que asegurarse de que hayan comprendido el problema y cómo solucionarlo.

Un vez hemos transmitido el mensaje que queríamos debemos despedirnos con información sobre nosotros mismos. Se debe incluir un pie de firma con los datos de contacto y firmar digitalmente el correo. Siempre se habla de la poca seguridad de los correos y debemos transmitir una imagen de profesionalidad, utilizando firmas que certifiquen la autenticidad y la integridad del mensaje. Si enviamos información confidencial, deberemos cifrar el mensaje con un mecanismo acordado previamente entre las partes.

Como conclusión, quiero remarcar que los correos deben ser concisos y aportar la mayor información sin parecer un correo automático o una captura de un log del sistema, ya que estos crean poco interés en el receptor y puede que se le dé menos importancia de la que tenga en realidad. Utilizar un lenguaje entendible por personas con poco conocimiento en seguridad y huir de texto pegado de registros de sistemas. Esto último puede ir en archivos adjuntos.

Se debe transmitir la importancia en este primer correo y, si fuera necesario, enviar tantos correos como nos solicite el destinatario para aclararle sus dudas, pero que no caigan en saco roto por parecer siempre iguales.

Se trata de programas para generar pequeños virus que una vez infectan un equipo permiten controlar remotamente el ordenador de la víctima permitiendo robar contraseñas, hacen las funciones de keylogger, pueden cargar o descargar ficheros, matar procesos, gastar bromas, grabar webcams, ver escritorios remotos, etc.

Su popularidad vino motivada en gran parte por su facilidad de uso ya que no son necesarios conocimientos avanzados de informática más allá de saber algo de inglés, saber que es una IP y poco más, lo cual provocó que muchos script kiddies se lanzaran a la caza de equipos para infectar. A pesar de su sencillez de uso los usuarios medios pueden llegar a conseguir un parque de equipos infectados decente y usable ya que disponen de opciones avanzadas como la gestión de equipos infectados desde IRC, ocultar el proceso en otros procesos o servicios del sistema, o camuflar el fichero ejecutable dentro de fotos o ficheros ofimáticos.

Por suerte los RAT no utilizan técnicas novedosas de infección por lo que sigue siendo necesario que el usuario ejecute un fichero para quedar infectado así que la mayoría de antivirus nos protegerán de este tipo de software, especialmente de los más conocidos, aunque como siempre, la mejor defensa contra los virus seguirá siendo el sentido común y sospechar de ficheros poco fiables.

Estos programas o virus se han visto obligados a evolucionar en el tiempo para adaptarse a las sucesivas versiones de Windows, principal plataforma que explotan, aunque tras hacer ligeras adaptaciones para funcionar en Windows 7 (con algunas limitaciones) parece que muchos desarrolladores han abandonado su mantenimiento. Desconocemos si este abandono se debe a la dificultad para ejecutarse en equipos con el control de cuentas de usuario, la llegada de Windows Defender para proteger a los incautos sin antivirus, o a que los desarrolladores han perdido el interés, pero el caso es que es complicado que veamos nuevas versiones de grandes glorias como SubSeven, Poison Ivy, o Bifrost, si bien han surgido algunos proyectos interesantes como Flu.

Para los curiosos que nunca hubiesen oído hablar de estos programas os invitamos a descargarlos y probarlos ya que son cuanto menos curiosos y se pueden utilizar incluso para escarmentar a algún usuario descuidado. Eso sí, probarlo en entornos lo más aislados y controlados posibles (máquinas virtuales, equipos de prueba, etc…) ya que a fin de cuentas estaréis infectando vuestros propios equipos con un software que no sabemos a ciencia cierta qué hace.

Solo queda pues esperar a ver si realmente es un “género muerto” o si el tema está en letargo a la espera de volver a florecer en nuevos sistemas operativos o incluso dispositivos.

Hace algo más de un año, en Security Art Work se habló sobre la esteganografía y algunos de los métodos utilizados en esta disciplina (entradas una, dos y tres).

Con el artículo de hoy toca rememorar este tema, ya que tal y como está últimamente todo el tema de la privacidad con leyes como PIPA y SOPA, uno se puede preguntar si nos veremos “obligados” a tener que comunicar cierta información mediante técnicas más elaboradas de cifrado. ¿Podría ser la esteganografía una de ellas?

Esta vez no vamos a publicar un escrito ampliando la información ya dada. En vez de esto, proponemos un reto para aquellos que queráis dedicarle algo de tiempo e intentar resolverlo. Con los anteriores artículos se puede tener un conocimiento de algunas de las técnicas que pueden ser usadas en la esteganografía, pero como el propio título dice, es solo una introducción, así que: ¿qué mejor manera de aprender y practicar todo esto que con un reto?

Para este reto, partimos del siguiente escenario: hemos obtenido un archivo de una compañía de videojuegos, de la cual se rumorea que se ha realizado una nueva versión de un juego ya conocido. Ciertas personas aseguran que este archivo (ver adjunto debajo) contiene información ultra secreta referente a ello. ¿Seríais capaces de decir de qué juego están hablando estos rumores?

La solución del reto la publicaremos dentro de una semana, así que aquellos que lo intentéis y no lo consigáis, o simplemente aquellos que tengáis curiosidad, estad atentos al blog ;)

Archivo: NewEnd.
MD5: 134c4aa557833d650822e679670d1957

¿De qué trata este evento?

El día de Protección de Datos en Europa es una jornada que tiene como objetivo de promover el conocimiento entre los ciudadanos acerca de cuáles son sus derechos y responsabilidades en materia de protección de datos. Esta jornada está respaldada por las autoridades de Protección de Datos de los estados miembros de la Unión Europea (por ejemplo, la AEPD), el Consejo de Europa y la Comisión Europea.

¿Por qué se celebra el día 28 de enero?

El Comité de Ministros del Consejo de Europa eligió esta fecha para conmemorar el aniversario de la firma del Convenio 108 del Consejo de Europa para la protección de personas con respecto al tratamiento automatizado de datos de carácter personal. Dicho convenio se firmó el 28 de enero de 1981 y establece las bases para la protección de datos en Europa.

¿Qué podemos esperar de estas jornadas?

Tal y como hemos comentado, el objetivo es informar a todos los ciudadanos sobre sus derechos y responsabilidades en materia de protección de datos. Desde mi punto de vista se trata de una cuestión importante que nos afecta a todos. En principio es previsible que a título individual poco o nada podemos hacer que tenga repercusión sobre el marco regulatorio actual. Pero esto no es del todo cierto. Vivimos en un contexto muy cambiante en el que las leyes parecen quedarse obsoletas de hoy para mañana. En mi opinión, la adaptación del marco legal debe contar con la participación de todos los interesados (y afectados) es decir, de todos nosotros.

Sin ir más lejos, el pasado 28 de diciembre la AEPD abrió una consulta pública para conocer la opinión y experiencia de prestadores de servicios, usuarios y expertos sobre Computación en Nube.

¿Cómo participar?

La seguridad de la información en general y la protección de datos en particular no son cuestiones puntuales para tener en cuenta un día y dejarse de lado el siguiente. Aún teniendo esto en cuenta, se pretende impulsar y difundir la importancia de estos temas promocionando el día de la Protección de Datos.

La AEPD ha puesto a disposición de los usuarios material gráfico (banners) para que todos aquellos organismos, entidades, asociaciones o particulares que así lo deseen puedan incluir en sus páginas web un elemento para apoyar la difusión del Día de la Protección de Datos.

Nos despedimos respaldando esta iniciativa desde Security Art Work y les deseamos que pasen un buen fin de semana.

La herramienta en cuestión es XSSer, un Framework que detecta, explota e informa de vulnerabilidades XSS en aplicaciones Web. Supongo que las vulnerabilidades XSS no son desconocidas para nuestros lectores, aunque si tienen alguna duda pueden visitar esta entrada para refrescar conceptos.

Como comenta el propio autor en la web del proyecto, contiene diversas opciones para evadir ciertos filtros y diferentes técnicas de inyección de código.

Para empezar a usar la herramienta, basta con descargar la última versión del repositorio:

$ svn co https://xsser.svn.sourceforge.net/svnroot/xsser xsser

Una vez realizado esto, podemos ejecutarlo de dos formas distintas, desde consola o mediante su interfaz:

$ ./xsser [Opciones]
$ ./xsser --gtk

Un ejemplo de uso sería el siguiente:

$ ./xsser -u http://host.com --proxy http://127.0.0.1:8118 --auto --Hex --verbose --save

En este caso, analizaríamos la web host.com a través de Tor. Además utilizaríamos diferentes payloads codificados en hexadecimal. El resultado que obtendríamos sería detallado y estaría guardado en el archivo XSSlist.dat

Para disfrutar de todas las opciones, ejecutad ./xsser –help y obtendréis una larga lista de opciones para auditar XSS en aplicaciones web.

Una vez mostrado el funcionamiento básico de la herramienta, os animamos a que la probéis y comentéis como os ha funcionado. Y si sois de los afortunados que tienen entrada para la próxima Rooted, podréis comentar con el autor vuestras dudas, sugerencias o felicitaciones.

P.D: Nos vemos en Madrid el 1, 2 y 3 de Marzo.

Aunque la entrada de hoy no es totalmente original como suele ser habitual, ya que fue publicada en su mayor parte ayer en su blog personal “Apuntes de seguridad de la información”, hemos creído interesante traerla también a nuestros lectores ya que guarda relación con dos de los aspectos en los que S2 Grupo está especializada: la Seguridad de la información y la Gestión de procesos (o eventos, en este caso) en tiempo real.

Vamos pues con ella y esperemos que les guste.

Todas las organizaciones, grandes o pequeñas, disponen de sistemas de recogida de eventos que guardan en ficheros de log datos sobre lo que está sucediendo en el funcionamiento de los sistemas de información. Esta materia prima permite establecer un puesto de vigilancia y conocer de primera mano qué ocurre en sus sistemas de información. En algunos casos por tiempo, en otros por desconocimiento sobre las problemáticas a analizar, esos datos no sirven para tomar decisiones que en un momento dado pueden luego costar una factura muy cara. El ejemplo en el mundo físico es como quien coloca cámaras de vigilancia y sensores volumétricos en todos los rincones a vigilar de su empresa, centralizando toda esa información en un cuarto de control y luego no pone vigilantes las 24 horas del día para que monitoricen lo que sucede en esas pantallas y centrales de alarma.

El Ejército Americano tiene publicado un manual sobre cuáles son las herramientas a utilizar en el campo de las operaciones de información (Information warfare) que en conflictos bélicos son uno de los escenarios más relevantes donde se deciden las batallas. Es imprescindible leer el Capitulo I, de Introducción porque aporta una nueva perspectiva al concepto de “información” y sus dimensiones. Y tal como deja claro el manual, la información esencial, la importante donde se pueden perder batallas, es aquella que se emplea en la toma de decisiones. Este fue el mensaje que quedó en mi mente tras leer el documento americano.

No podemos llamar “información” sino “datos” a aquello que no sirve para tomar decisiones. Y ese es el verdadero problema/drama de los logs, que no llegan a ser información sino datos sobre la situación de seguridad de la Organización que son guardados o borrados sin que de ellos se extraigan conclusiones o decisiones que pueden evitar o mejorar en mucho la seguridad de los sistemas. Como mucho los logs se utilizan una vez sucedido el incidente para tratar de esclarecer los hechos perdiendo así una oportunidad de ser proactivos y preventivos.

Hace unos meses Anton Chuvakin, un “information security warrior” publicó un post con el top 7 de informes de seguridad.

Tal como establece el maestro Sun Tzu al hablar de los elementos a gestionar en el Arte de la Guerra, “La tierra puede ser alta o baja, ancha o estrecha, lejana o cercana, desnivelada o plana, propicia para la muerte o para la vida“. Todo General debe estudiar el contexto en el que se plantea el conflicto y tratar de moldearlo o dirigirlo para que le proporcione las mejores opciones y decisiones. El terreno tiene ciertas restricciones que no pueden alterarse, pero se debe ser consciente de todas estas limitaciones a la hora de plantear la táctica de combate. En nuestro caso, el terreno viene condicionado por la infraestructura TI de nuestra organización, pero también por los eventos y servicios que ésta suministra. En este sentido, una de las fuentes que mejor describen el campo de batalla son los eventos del sistema. Como decía el agente Mulder de Expediente-X, “la verdad está ahí fuera“. Todo administrador de sistemas o responsable de seguridad debería adecuar esa frase a “la realidad de lo que pasa en nuestros sistemas está en los logs“.

Juntando esto con las diferentes áreas que aparecen en ese top de informes de seguridad se puede construir el siguiente escenario de vigilancia e inteligencia de red.

Para empezar también me parece interesante comentar, tal como establece la norma “ISO/IEC 27035:2001 sobre gestión de incidentes” publicada el año pasado, la separación entre evento de seguridad e incidente. Todo incidente es generado por un evento de seguridad pero no todo evento de seguridad se transforma en un incidente. En el terreno de los logs nos movemos básicamente sobre el análisis de eventos que posteriormente hemos de decidir si son clasificados como incidentes. Ahora veamos los diferentes campos de batalla a gestionar. Los he separado en tres grandes áreas como ilustra este gráfico que atiende también a los diferentes tipos de escenarios y su hostilidad:

Personas:

• Escenario de la gestión de usuarios: en este terreno los eventos a vigilar de cerca están relacionados con el ciclo de vida del usuario (alta, baja y modificación de permisos), los registros de acceso fallidos y con éxito, la elevación de privilegios y las conexiones con usuarios con los máximos privilegios.
• Escenario de accesos a recursos: en este terreno los eventos a vigilar tienen que ver con los registros de auditoría de acceso del personal legítimo o interno sobre elementos muy protegidos que deben notificar cada intento de acceso a ellos para disponer de trazabilidad sobre el uso del recurso.

Recursos:

• Escenario del cambio en recursos TI: en este escenario los eventos más relevantes son los relacionados con la instalación de software, la actualización, los cambios relevantes para la seguridad sobre parámetros de configuración, la modificación de las directrices de auditoría y la deshabilitación de las medidas de seguridad instaladas. También se pueden controlar desde este escenario el funcionamiento de las medidas de seguridad como pueden ser la actualización de las firmas de patrones del antivirus, la aplicación de parches sobre los sistemas y los resultados de los chequeos de vulnerabilidades.
• Escenario de los problemas detectados: los eventos vinculados con este escenario están relacionados con la monitorización del funcionamiento de los recursos, su disponibilidad, incidencias de caída o fallo de componentes, errores en los sistemas, errores en sistemas de copia de seguridad, alertas sobre la gestión de la capacidad, eventos de reinicio y parada de sistemas, etc.
• Escenario de la actividad interna de nuestra red: en este terreno, los eventos a vigilar están relacionados con los patrones de comportamiento de nuestra red y nuestros usuarios, los protocolos más utilizados, el consumo de ancho de banda, el volumen de tráfico demandado y recibido, la carga de nuestras conexiones, etc.

Enemigos:

• Escenario del malware detectado: en este escenario, los eventos a vigilar deben provenir de las medidas de protección perimetral y antivirus. Se debe vigilar el número de infecciones recogido, los archivos en cuarentena, las estadísticas sobre el tipo de malware que se detecta (gusanos, troyanos, virus, hacking tools) así como la fuente de infección (descargas en la red, dispositivos USB, correo electrónico).
• Escenario de la actividad externa sobre nuestra red: en este terreno, la información relevante proviene de las medidas de protección perimetral que inspeccionan el tráfico y que detienen aquellas peticiones que no superan la política de filtrado de tráfico y contenido. Sirve para poder detectar intentos de ataque, abusos sobre recursos accesibles desde el exterior, vulneración de las medidas de seguridad. Es necesario también atender a los volúmenes de información recibidos y salientes para detectar si hay elementos en la red interna comprometidos y que están siendo controlados desde el exterior.

Sobre todos estos campos de batalla, con una visión global y estratégica de lo que está sucediendo debe trabajar una pieza esencial en la línea de defensa de toda organización: la monitorización y gestión de eventos de seguridad.

Los siguientes puntos se van a centrar únicamente en la seguridad de la máquina, sin extenderse en los elementos externos que se pueden utilizar para securizar el equipo, como NIDS, IPS, firewalls, auditorías periódicas o cañones de fotones.

• Software siempre actualizado. Imprescindible mantener el sistema siempre a la última en parches de seguridad. No hacerlo es el método más sencillo para que te vulneren o tumben el equipo. La mayoría de malware actual se basa en vulnerabilidades conocidas de un servicio o aplicación para infectar la máquina.
• Configuración deficiente de las aplicaciones. De nada serviría un servidor altamente bastionado si uno de los servicios disponibles tiene una configuración que permita a un atacante vulnerar su seguridad. Como es imposible abarcar todo lo que esta implicación supondría, enumeraré algunas indicaciones generales, aplicables a la mayoría de aplicaciones:
1. Ocultar en la medida de lo posible información “jugosa”. Ponerle difícil la recopilación de información a un posible atacante. Por poner unos pocos ejemplos, banners del servidor web, trazas de errores de un Tomcat, metadatos en documentos, transferencia de zona en los servidores DNS, demasiada información visible en los nodos de un servidor LDAP, etc.
2. Cifrados débiles. Evitar que se puedan utilizar algoritmos de cifrado crackeables a la hora de almacenar contraseñas o en el intercambio de información.
3. Permisos de usuario y administrador. Ojo con qué se puede ver o hacer con usuarios limitados o invitados.
4. Política de contraseñas.
   1. Aplicar una política restrictiva cuando se vaya a almacenar una contraseña, como el tamaño mínimo, el uso de mayúsculas, números, caracteres especiales.
   2. Controlar el acceso a la aplicación, con un máximo de intentos, o un delay entre intentos.
   3. Evitar que se pueda utilizar una palabra de diccionario. Se puede usar un agente que lo detecte: http://www.debian-administration.org/articles/59
   4. Y sobre todo, nunca nunca usar la misma contraseña para cada cuenta o servicio o máquina. Vulneran una contraseña, y pueden tomar el control del resto de servicios o máquinas. Como acordarse de todas ellas es imposible para un mortal medio, es recomendable usar herramientas como KeePass o Password Gorilla.
   5. Usar herramientas específicas de hardening, como WAFs o PHPIDS
• Permisos de ficheros. Comprobar qué permisos tienen ciertos ficheros o directorios críticos, para evitar que usuarios no autorizados puedan leer o escribir en él. Por ejemplo, no se debería tener permisos de escritura a los ficheros inetd.conf, innittab, passwd, crontabs, o la estructura de directorios del servidor web. Éste último es más delicado y tiene sus excepciones y sus restricciones propias cuya explicación se sale del propósito de este post.
• Monitorizar o restringir el acceso a cuentas privilegiadas. En un servidor crítico, no suele ser habitual que alguien se loguee como root. Puede ser una buena idea que nos llegue una notificación cuando esto ocurra para controlar posibles accesos ilegítimos. También se pueden tomar medidas como denegar el acceso root desde SSH, o permitir solamente a un rango de ips concreto el acceso administrador de una aplicación web.
• Eliminar servicios innecesarios. Comprobar con netstat -putan qué servicios están a la escucha, y para los que no sean imprescindibles. Podrían ser un potencial vector de ataque. Un ejemplo de servicios que suelen estar a la escucha en una instalación por defecto son RPC, Zeroconf, samba. Si no estás seguro si necesitas ese servicio, la recomendación que escuché en su día fue: detén el servicio, y atento a ver qué explota ;)
• Eliminar aplicaciones instaladas innecesarias. Una vez se haya pasado el servidor a producción, no es necesario, por ejemplo, mantener ningún compilador. Se puede instalar un sistema base mínimo y a partir de ahí instalar lo imprescindible.
• Aislar la máquina del resto de equipos. Si el resto de máquinas pertenecientes a una DMZ no necesitan ningún servicio de ti, impídeles el acceso. En caso de que una máquina sea vulnerada, no podrá saltar a otro equipo y la intrusión quedará contenida.
• Usar un HIDS. Monitoriza el acceso o modificación de ficheros clave, como /sbin, /etc, /var/www para prevenir cambios ilegítimos.
• Uso de syslog remoto. Podemos enviar los logs a un servidor de syslog remoto. Con esto conseguimos monitorizar los servicios y poder correlar eventos. La herramienta OSSEC es muy recomendada para esto último. También se gana trazabilidad, haciendo más difícil para un intruso borrar su rastro.
• Usar parches del kernel como SELinux, AppArmor, o PaX. Estas características implementan políticas de acceso a recursos, o protección de espacios de memoria.
• Protección en el arranque. Establecer una contraseña a la bios y a grub para evitar la modificación del arranque. Sin estas protecciones, un acceso físico ilegítimo al cpd haría que se pudiera arrancar desde una LiveCD o conseguir una shell de root, arrancando el sistema en modo monousuario.
• Particionar para aplicar distintas directivas de seguridad. Al dividir el sistema en varias particiones se pueden establecer diferentes restricciones a la hora de crear el punto de montaje. Por ejemplo, poner el parámetro noexec a la carpeta /tmp, o ro, nosuid, nodev a /usr, etc.
• Uso de sudo. Permite granular los permisos privilegiados de una cuenta. Se puede establecer qué ficheros concretos se pueden ejecutar como root. Se consigue con esto fijar unos permisos concretos a operadores o DBAs con únicamente las herramientas que necesiten, y evitar así compartir la clave de root.
• Otros:
  1. Monitorización de recursos, como RAM, CPU, espacio en disco, o servicios levantados. Imprescindible para un sysadmin conocer en todo momento el estado de un servidor. La herramienta más popular para esta tarea es Nagios.
  2. Backups y plan de contingencias: de nada habría servido todo este bastionado si un fallo de disco duro hace que se pierda toda la información y el servicio quede inaccesible. Para eso es imprescindible un sistema de copias de respaldo y si el servicio que ofrece es crítico, pensar en implantar un sistema de alta disponibilidad que redunde el servicio inmediatamente en caso de que éste caiga.

Obviamente, estas son unas indicaciones generales de securización de un servidor. Cada responsable deberá valorar qué medidas serán adecuadas y cuales serán excesivas de implantar por no ser necesario o por no merecer la pena la implantación por el coste en recursos que ello supondría. Por supuesto, tampoco están todas. Os animo a que comentéis que medidas usáis para bastionar vuestros equipos que no estén contempladas anteriormente.

Respecto a la encuesta anterior, los resultados se dividen entre los optimistas, que consideran que podremos mantener la privacidad en el futuro siempre que queramos renunciar a ciertos servicios, y los pesimistas, que piensan que hagamos lo que hagamos, es una batalla perdida. Como tercera alternativa, la idea de que la pérdida de la privacidad es algo positivo que es inherente al progreso que incorporan las nuevas tecnologías no parece tener demasiados seguidores, ya sea porque nadie considera en realidad que tal pérdida pueda ser considerado un avance, o porque las otras opciones estaban más definidas.

¡Esperamos sus respuestas!