Libro 'Manual de la Resilencia', de Alejandro Corletti, toda una referencia para la gestión de la seguridad en nuestros sistemas

  • February 6, 2021
  • cybercaronte
  • Hoy día, y más aún amplificado por la pandemia que azota al planeta, cada vez es más importante la robustez de nuestros sistemas y arquitecturas informáticas, sea cual sea el modelo de negocio. La capacidad de restablecer los servicios después de algún incidente (también llamado “resilencia”) es posiblemente la clave de supervivencia de una organización o empresa. Por que recuerda, no tenemos que pensar en si nos ocurrirá unos de estos incidentes de seguridad, si no cuándo y cómo nos recuperaremos. Por este motivo, que libros como el que vamos a presentaros ahora, que se centran precisamente en la “Ciberresilencia”. Y si además es gratuito, en su versión digital, pues mucho mejor.

    Manual de Resilencia

    Este libro de 384 páginas escrito por Alejandro Corletti Estrada (todo un experto en la materia con una gran experiencia en este campo a sus espaldas) es todo un compendio que cubre todas las necesidades de resilencia para una infraestructura informática. Además, su enfoque en la protección de la información más que de la misma infraestructura, hace que todo su contenido se centre en este elemento tan importante: los datos.

    Alejandro Corletti

    El libro abarca prácticamente todo lo que necesita el profesional responsable de la seguridad de las infraestructuras, como estrategias resilientes para redes y sistemas, proactividad forense, procesos relacionados con la resilencia (gobierno, recuperación ante desastres, etc), planificación y normas estándares técnicos asociados a la resilencia. Además, la experiencia como informático militar de Alejandro Corletti, hace que el contenido sea aún más robusto y enfocado a intentar llegar al máximo nivel de seguridad posible de los sistemas.

    Como podéis comprobar, la cantidad y calidad del contenido hace que este libro sea toda una referencia para cualquier profesional de las TIC que tenga entre sus prioridades, la resilencia de sus sistemas. Y si queréis aún más información, este libro se complementa (de hecho es una continuación) con otros tres llamados “Seguridad por Niveles” (2011), “Seguridad en Redes” y “Ciberseguridad, una estrategia Informático/Militar”. También podéis visitar su canal de Youtube donde se incluyen vídeos centrados en todo tipo de disciplinas dentro de la ciberseguridad.

    Enlace a la web del libro: https://darfe.es/index.php/es/descarga-nuevo-libro

    Alejandro Corletti (MyPublicInBox) https://mypublicinbox.com/acorletti

Mujeres hackers en ElevenPaths Radio

  • July 6, 2020
  • tuxotron
  • Fran y Rafa - RootedCon 2020

    Durante nuestro paso por la RootedCON de este año 2020, mi compañero de batalla Fran Ramírez y un servidor no sólo tuvimos las oportunidad de dar una presentación, sino también tuvimos el privilegio de ser entrevistado por Gonzalo Álvarez Marañón, para la segunda temporada del podcast de ElevenPaths Radio, un crack donde los haya y para nosotros un gran orgullo poder ser entrevistados por alguien a quién admiramos.

    El podcast lo grabamos en el Kinépolis en la tarde del sábado (último día de la RootedCON). En el mismo tuvimos la oportunidad de hablar sobre una de nuestras pasiones: la historia, o mejor dicho, las microshistorias de la informática. En esta ocasión el foco de la entrevista fue sobre la influencia que la mujer ha tenido en este campo, esas “hackers ocultas”.

Creando certificados X.509 caducados

  • May 9, 2020
  • tuxotron
  • Expired Certificate

    Ayer hice una presentación sobre TLS para desarrolladores, bueno más bien un taller, y uno de los ejercicios consistía en ejecutar un servicio con un certificado caducado para hacer algunas pruebas.

    Para ello tenía que crearme un certificado caducado, y yo que soy muy listo, me dije nada, cuando cree al certificado lo pongo el número de días de caducidad en negativo y listo. Así, si queremos crear un certificado que caducó hace 5 días:

    openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days -5
    req: Non-positive number "-5" for -days
    req: Use -help for summary.
    

    Pues eso, que al final no soy tan listo :D

    Así que a buscar se dijo. La mayoría de las soluciones que encontré requerían el cambio de la fecha del sistema por una fecha pasada y luego generando el certificado pasándole el número de días de su caducidad, que obviamente, sumando dicho valor a la fecha de sistema no pasara la fecha actual.

    La verdad que la idea de cambiar la fecha del sistema pues no me hacía mucha gracia, pero luego pensé, bueno si lo hago desde un contenedor ¿Qué más da? Así que levanté un contendor con ubuntu y ejecuté el comando date:

    docker run -it --rm ubuntu:18.04
    root@c09ad5d2689d:/# date +%Y%m%d -s "20200101"
    date: cannot set date: Operation not permitted
    20200101
    root@c09ad5d2689d:/#
    

    Otro batacazo :(. Claro esto tiene sentido. Los miles que os habéis leído el libro de Docker: SecDevOps XD sabréis que un contenedor Docker no es más que un proceso más en el sistema, y éste comparte el mismo reloj. Por lo tanto cambiar la fecha en el contenedor cambiaría también la fecha del sistema, además para ello, tendrías que correr el contenedor con privilegios elevados (–privileged).

    Volviendo a la casilla cero, la idea era el no cambiar la fecha del sistema, así que después de seguir buscando una solución al problema, finalmente encontré una utilidad llamada faketime. Esta utilidad de acuerdo a la documentación, es una simple capa encima de la librería libfaketime. Dicha librería permite la modificación de la fecha para una aplicación sin afectar al sistema. Esta librería intercepta algunas llamadas del sistema y faketime haciendo uso de LD_PRELOAD nos permite establecer la fecha y la hora para una aplicación específica.

    Por lo tanto, ejecutando el siguiente comando:

    faketime '2020-01-01' openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days 1
    

    Creamos un certificado cuya validez va desde el 1 de enero al 2 de enero del 2020. Verifiquémoslo:

    openssl x509 -in server.crt -text -noout
    
    ...
        Validity
            Not Before: Jan  1 00:00:05 2020 GMT
            Not After : Jan  2 00:00:05 2020 GMT
    ...
    

    faketime acepta varias formas de especificar la fecha como puede observarse en la documentación:

    faketime 'last Friday 5 pm' /bin/date
    faketime '2008-12-24 08:15:42' /bin/date
    faketime -f '+2,5y x10,0' /bin/bash -c 'date; while true; do echo $SECONDS ; sleep 1 ; done'
    ...
    ...
    

    Si quieres probarlo por ti mismo, puedes instalártela o puedes crearte un contenedor Docker. Para ello o bien te creas la imagen de forma manual, o puedes usar doig:

    doig -u -i mytools -t faketime
    

    Y luegos ejecutas el contenedor:

    docker run -it --rm mytools
    

    Por cierto si quieres jugar con “certificados con problemas”, https://badssl.com es un gran recurso.