En nuestro trabajo habitual, a menudo nos hemos encontrado con información muy útil sobre aplicaciones de backups, tales como problemas solucionados, scripts de uso, consejos de optimización, trucos, etc.

Para poder compartirla, nos gustaría saber cuales son los sistemas de backups más usados por nuestros lectores. Hemos incluido en la encuesta los más usados en entornos empresariales, aunque también nos pueden decir cual es el que usan ustedes. Si usan el xcopy de windows, o incluso no hacen copia….. ¡¡mejor pasen por aquí mas a menudo!!

¿Qué sistema de backup utilizas?

• Otros (54%, 34 Votos)
• Symantec Backup Exec (22%, 14 Votos)
• IBM Tivoli Storage Manager (TSM) (14%, 9 Votos)
• ARCserve Backup (8%, 5 Votos)
• Symantec NetBackup (5%, 3 Votos)
• EMC Legato (3%, 2 Votos)

Votantes: 63

 Loading ...

(Mañana comentaremos el resultado de la anterior encuesta —la que tienen a la derecha— y pasaremos esta al lateral…)

No sé cómo se habrán sentido ustedes tras observar la polémica suscitada por la publicación de la famosa fotografía de las hijas del presidente del gobierno en el Metropolitan de Nueva York, y observar —cada vez me sorprende más lo desocupados y aburridos que pueden llegar a estar mis congéneres— esa especie de “variaciones sobre el mismo tema” en que se ha convertido la generación de fotografías de las menores cambiando el escenario, los rostros y los aderezos de los retratados.

No voy a entrar en la disquisición de dónde termina el círculo privado y empieza el ámbito público, tema más propio de uno de estos “programas” de “prensa” rosa/morbosa. Con independencia de lo que se piense (¿era o no era un viaje privado? ¿Un presidente de gobierno y su familia son o no son personajes públicos?), personalmente me parece preocupante la falta de respeto general observada al tratar el tema después de leer/oír los comentarios vertidos en los medios de comunicación, partiendo de la base de que se trata de menores de edad.

Tal como vimos en la entrada anterior, estamos intentando contrastar la información respecto a un fallo de seguridad en el FTP del IIS. Nos hemos dado cuenta de que tras ejecutar el exploit en todas sus versiones, no ha funcionado pese a ejecutarse sin fallos.

Revisando los logs del ftp, comprobando el tráfico con el tcpdump, y revisando el código del exploit seguíamos sin saber el motivo por el cual éste no funcionaba. La última opción que nos faltaba era usar el ollydbg con el inetinfo.exe, así como todo aquel programa que tenga relación con el FTP e intentar averiguar por qué el exploit fallaba. Pero lógicamente esto requería de un tiempo del que no disponíamos.

Les voy a contar mi pequeña experiencia con un incidente ocurrido hace unas semanas atrás relacionado con una vulnerabilidad en el FTP del IIS. Ésta afecta tanto a la versión 5.0, 5.1, 6.0 y 7.0, provocando una denegación de servicios [Véase boletín de seguridad de Microsoft], pero es en la versión 5.0 donde la vulnerabilidad es más grave, debido a que hay suficiente espacio como para introducir código. Esto ha dado lugar a dos versiones adicionales del exploit: una permite crear usuarios en el sistemas y la otra la ejecución de una shell remota.

Era finales de agosto cuando comenzaron a llegar noticias de un zero-day en el ftp del IIS. Como todo lo que ocurre con vulnerabilidades de entornos Microsoft, siempre es difícil medir cuánto de toda la información que te llega es verdad. Lo primero es comprobar que realmente no es un bulo y efectivamente, no lo era; demasiadas fuentes apuntaban a este fallo de seguridad grave.

Cuando hablamos de la seguridad de los soportes rara vez le prestamos atención a la protección del medio en sí, sino que nos centramos -especialmente los que estamos más focalizados en seguridad de la información- en la seguridad de los datos que el soporte contiene, independientemente de su formato. Dicho de otra forma, si me roban un pendrive USB, no me suelo preocupar por el propio pendrive (¿cuánto cuesta? ¿10 euros?), sino por los datos confidenciales que pueda tener. Esto, que al hablar de pendrives parece obvio, no lo es tanto cuando el valor del soporte a proteger es muy superior al de la información que contiene. ¿Ejemplos? Un pergamino del siglo XIII, un cuadro, la versión manuscrita y original del Quijote… o unas pinturas rupestres.

Para acabar la semana, vamos a hablar en este post de esa “otra” seguridad de los soportes, la protección del medio en sí y no de los datos que contiene. Salvo que trabajemos en un museo, un archivo histórico o similar, rara vez tendremos que enfrentarnos a la protección de este tipo de medios; pero no hace falta tratar con material de hace siglos u obras de arte para proteger el soporte: en cualquier oficina existe -todavía- multitud de información en papel, de la que obviamente interesa garantizar su confidencialidad y disponibilidad, pero también su integridad… desde todos los puntos de vista.

“No News is Good News“. Todos hemos oído en alguna ocasión esta frase, un poco pesimista, si pensamos que implica que es más probable recibir malas que buenas noticias. Sin embargo, como directivo de una empresa, opino que lo peor es no enterarse de lo que está sucediendo. Como dice mi socio: “Ojos que no ven… batacazo que te pegas”.

Los ingenieros llevamos muchos años monitorizando los procesos industriales; son procesos con parámetros de funcionamiento bien definidos en el diseño, y cuya variación tiene consecuencias conocidas. Sabemos qué desviaciones se pueden permitir sin afectar negativamente al resultado final, vigilamos esos parámetros y establecemos sistemas de control que nos avisan cuando alguno se sale de lo establecido.

En términos generales, la gestión de una empresa consiste en controlar el funcionamiento de sus procesos manteniendo los parámetros de funcionamiento dentro de los límites admisibles, para garantizar que los resultados cumplen con el plan de operaciones. En este caso, los procesos no son sólo los industriales, sino también los logísticos, comerciales, financieros y, por supuesto, la seguridad, de la que a estas alturas no hace falta hablar; todos conocemos el mantra de Bruce Schneier: “Security is a process, not a product“. No hay más que echarle un vistazo a su blog Schneier on Security para comprobar su insistencia en esta idea.

Para acabar con esta serie de entradas sobre los ataques de buffer overflow, y una vez explicadas las bases, vamos a ejecutar el programa que vimos en la entrada anterior varias veces, para ver cual es la posición del EPI (dirección de la siguiente línea a ejecutar):

user1@base:~/Desktop> for i in `seq 1 5`; do ./prueba | grep Premio; done
Premio: Valor: 0x29 PosMem: 0xBFFFF04C
Premio: Valor: 0x29 PosMem: 0xBFFFF04C
Premio: Valor: 0x29 PosMem: 0xBFFFF04C
Premio: Valor: 0x29 PosMem: 0xBFFFF04C
Premio: Valor: 0x29 PosMem: 0xBFFFF04C

Tras el pequeño rollo teórico que vimos ayer, hoy toca entrar de lleno en las cuestiones prácticas, que espero que aclaren todas las dudas que ayer pudieran surgir. Veamos el siguiente trozo de código en C de 4 líneas. La primera instrucción asigna el valor 9 a la variable X, la segunda llama a una función, la tercera le asigna a X el valor 1 y la siguiente línea mostrará el valor de X:

Esta es mi primera (que no última) aportación al blog, y aunque es de un cierto nivel técnico, espero no aburriros. El artículo que presento a continuación trata de los ataques de desbordamientos de memoria (buffer overflow), y de una protección del núcleo Linux 2.6 contra éstos llamada “Virtual Address Space Randomization”, también llamado ASLR. Este último año la funcionalidad de esta protección se ha visto comprometida, como veremos en detalle mañana en la segunda parte de esta entrada.

En esta primera parte, creo necesario para comprender el funcionamiento de esta protección explicar las bases de los desbordamientos de memoria, que a partir de ahora llamaremos Buffer Overflow. De manera muy resumida, los ataques de buffer overflow aprovechan código donde no se comprueba correctamente la longitud de las cadenas de entrada, de manera que es posible introducir un dato de longitud mayor que el espacio reservado para ese dato. Es decir, si reservo un espacio de 10 bytes para la variable de la función, ésta recibe un dato de 25 bytes, y no compruebo correctamente el tamaño del dato recibido, escribiré en memoria los 10 bytes reservados más 15 bytes no legítimos. ¿Y esto para que sirve? Pues para entenderlo vamos a explicar el funcionamiento a nivel de memoria de un proceso.

Seguiendo con la serie de Seguridad Sectorial, que iniciamos en junio con el post sobre seguridad bancaria, me gustaría hablar hoy de las particularidades de seguridad en los puertos -en las instalaciones portuarias en general-. Los puertos son uno de los principales puntos de entrada y salida del territorio nacional, lo que de entrada ya implica dos cosas: son objetivos prioritarios para el terrorismo, y son un elemento clave para el tráfico ilícito, en especial de mercancías. Por ello, en el sector portuario es crítico garantizar la seguridad a todos los niveles (seguridad de la información, seguridad de las personas, seguridad de la cadena de suministro…).

El departamento de seguridad de cualquier instalación portuaria de magnitud (como los puertos de todas nuestras ciudades) se enfrenta a una serie de amenazas entre las que se encuentran el terrorismo, las amenazas industriales -vertidos tóxicos, fugas…- el tráfico ilícito de personas y mercancías, los disturbios o el robo, por citar sólo unos ejemplos. Y todo esto, por supuesto, sin menoscabo de amenazas comunes a todos los sectores, que por supuesto también pueden materializarse en un puerto: robos de información, desastres naturales -agravados en ocasiones por la ubicación natural de los puertos-… Aunque viendo algunas de estas amenazas puede parecer que el componente tecnológico de la seguridad portuaria es bajo, realmente no es así: desde los controles de acceso físico a recintos, hasta el cierre electrónico de contenedores mediante RFID, la seguridad “tecnológica” es, como siempre en estos tiempos, tan importante como la seguridad “clásica”.