This publication assists organizations in understanding the basics of SSH interactive and automated access management in an enterprise, focusing on the management of SSH user keys.
Los primeros capítulos pueden ser interesantes para alguien que todavía no se haya preocupado de estos temas (a veces los informes sobre temas más complejos nos sirven para entender mejor las cuestiones básicas porque las tratan en los capítulos introductorios). Los siguientes, tendrán interés si queremos ir más allá en los temas de gestión de la seguridad.
En [PDF] A Large Scale Study of Programming Languages and Code Quality in Github nos muestran una investigación realizada examinando el código de los repositorios de GitHub: analizan para diversos tipos de lenguajes la cantidad de fallos, basándose en los ‘commits’ que contienen etiquetas relacionadas con errores (‘error’, ‘bug’, ‘fix’ , ‘issue’, ‘mistake’, ‘incorrect’, ‘fault’, ‘defect’ and ‘flaw’).
El resumen sería (de manera muy básica) que los lenguajes fuertemente tipados son algo mejores que los débilmente tipados. También que los lenguajes funcionales son algo mejores que los demás.
… we report that language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat bet- ter than dynamic typing. We also find that functional languages are somewhat better than procedural languages.
También me gusta destacar el valor que tiene un sitio como GitHub (internet, para el caso) para poder realizar este tipo de estudios que serían bastante difíciles de realizar con el código disponible en ‘casa’ de cada uno que lo tenga.
Es una presentación que ya tiene unos años pero vale la pena guardarla. En Developing Secure Mobile Applications se habla de los diversos aspectos que se pueden tener en cuenta, incluyendo el Top 10 Mobile Risks pero también otros aspectos como los descompiladores, y otros aspectos que podemos transportar directamente del desarrollo seguro genérico.
Traemos un par de lecturas sobre cómo podemos reforzar el acceso a nuestros sistemas, añadiendo seguridad de dos formas (que podrían combinarse entre sí, puesto que se ocupan de diferentes partes: acceso y autentificación a un sistema).
La otra posibilidad es habilitar los servicios cuando los necesitemos, de forma que cuando no los vayamos a usar no estén disponibles. En este caso podríamos utiliar Latch. Tal y como cuentan en Fortificar GNU/Linux Ubuntu con Latch: Vídeo Tutorial se puede usar en cualquiera de los sistemas más comunes.
Siguiendo la línea de publicaciones anteriores, y tratando de alcanzar mayor difusión de las entradas de este sitio (y otro) decidimos probar el API de publicación de Telegram. Como siempre, es sencillo si encontramos las bibliotecas adecuadas y tenemos un poco de paciencia.
Pero primero tenemos que crear el bot. Siguiendo las instrucciones del BotFather. En este caso le pedimos el nuevo bot con:
/newbot
El botfather nos pide un nombre para nuestro bot, y un nombre de usuario (que deberá terminar en ‘bot’). Como respuesta nos envía el ‘token’ que nos servirá para identificarnos y poder interactuar con él. A partir de allí nuestra misión es mandarle cosas al bot.
Yo he elegido hacer un programita en Python, utilizando telepot. Las instrucciones están en telepot documentation El código que se muestra allí es muy sencillo.
import telepot
bot = telepot.Bot('***** AQUÍ VA EL TOKEN *****')
Y mandar un mensaje sería algo así como:
bot.sendMessage(999999999, 'Hola mundo')
En este caso ‘999999999’ es el identificador del bot, se puede utilizar el nombre asignado anteriormente.
En nuestro caso, como queremos que el bot avise automáticamente a sus seguidores cuando haya novedades utilizamos la fuente RSS del blog y algunos módulos de Python como feedparser.
Nos vamos a saltar esta parte porque ya la hemos contado en otro sitio y también la parte de obtener el título, el contenido y el enlace a la última entrada.
En este caso hay ciertos límites, no se pueden superar los 4096 caracteres en UTF8. Además, para que el texto tenga algo de gracia nos permiten algunas etiquetas de formato (que pueden ser HTML o Markdown). Como estamos leyendo la fuente RSS habremos leido HTML y la única prevención que hay que tener es utilizar sólo las etiquetas permitidas (negrita, cursiva, enlaces, código y texto pre-formateado). Para esto hice una chapucilla, consistente en eliminar todas las etiquetas que no le gustan al sistema:
Extraemos todas las etiquetas de nuestro texto:
tags = [tag.name for tag in soup.find_all()]
Y luego las recorremos:
for tag in tags:
Eliminando las que no son válidas:
if tag not in validTags:
con unwrap. Previamente hemos tenido una consideración especial con las citas añadiéndoles delante y detrás unas comillas para que se refleje adecuadamente en el resultado final.
El código está integrado en mi proyecto rssToSocial que no es un código para sentirse especialmente orgulloso. Pero permite hacer estas publicaciones sin tener que hacerlo a mano.
La explicación del código para publicar en otras redes sociales está en:
El National Institute of Standards and Technology publica informes de lo más variado y de vez en cuando le dedica atención a la seguridad informática.
