Registrando IPs de nuestros dispositivos en una hoja de cálculo en la nube

Dirección Seguimos dándole vueltas al tema de la dirección IP de los dispositivos. En ¿Quién está en mi red? abordábamos el problema desde el punto de vista del escaneo de la red.

Otra posibilidad es, claro, mirar el router y mirar los dispositivos conectados.

Sin embargo, para los dispositivos que tenemos controlados (y que nos interesan más) una posibilidad puede ser establecer un registro: cuando se conectan informan de que se han conectado, su IP, y los datos que consideremos relevantes.

Seguro que hay alguna forma canónica de hacer esto (o no, porque igual lo suyo sería tener un router que nos proporcione esta información de manera conveniente -pista: que no haga falta un navegador-) pero me pareció un buen ejercicio. Descubrí Google Spreadsheets and Python y me pareció una buena forma de intentarlo: los dispositivos podrían registrar en una hoja de cálculo los datos que nos interesen. Para la instalación y configuración básica se puede seguir ese documento. Después, tenemos que hacer un programita que recabe los datos y los almacene. El mío se basa en el ejemplo que puede verse allí.

En nuestro caso, obtendremos la IP con:

def getIp():
    return([l for l in ([ip for ip in socket.gethostbyname_ex(socket.gethostname())[2] if not ip.startswith("127.")][:1], [[(s.connect(('8.8.8.8', 53)), s.getsockname()[0], s.close()) for s in [socket.socket(socket.AF_INET, socket.SOCK_DGRAM)]][0][1]]) if l][0][0])

En este caso seguimos lo que indicaban en Finding local IP addresses using Python’s stdlib, no comentaremos más.

Además guardamos el nombre de la máquina, que nos servirá para dar nombre a la pestaña de la hoja donde almacenaremos los datos:

    hostname = socket.gethostname()

Finalmente, ya sólo nos queda escribir en la hoja de cálculo:

    sheet_name = 'Registro IPs'

A continuación accedemos a la hoja de cálculo (cuidado con la gestión de credenciales, nosotros hemos almacenado en la variable client_secret el nombre del fichero donde están los datos necesarios:

    scope = ['https://spreadsheets.google.com/feeds']
    creds = ServiceAccountCredentials.from_json_keyfile_name(client_secret, scope)
    client = gspread.authorize(creds)
    
    sheet = client.open(sheet_name)

A continuación registramos la máquina. Si ya es una máquina conocida, simplemente accedemos a la pestaña correspondiente; si no, la creamos:

    try:
        worksheet = sheet.worksheet(hostname)
    except gspread.exceptions.WorksheetNotFound:
        worksheet = sheet.add_worksheet(hostname, 5, 5)

Finalmente, escribimos en la hoja, insertando una fila antes de la segunda (la idea es que la información más reciente estará arriba, más cerca para verla). Al añadir una fila tendremos un registro de conexiones.

El código (en su versión actual) se puede ver en scripts/registerIp.py.

En

podemos ver cómo se crea la pestaña y se rellenan los datos al invocar el programa.

Para mantener este registro podemos poner en /etc/rc.local una invocación al programa de manera que cuando se arranquen los distintos sistemas registren su presencia.

Inseguridad en las empresas de seguridad

Twitter Otra historia que no merecería mayor comentario sino fuera porque demuestra que incluso las empresas que se dedican a la seguridad hacen las cosas mal de vez en cuando: RSA asks for plaintext Twitter passwords on conference reg page. La realidad nos demuestra que es difícil (muy difícil) hacer bien las cosas en el contexto que nos movemos hoy en día: a lo mejor subcontratas una parte de tu proceso y quien lo hace no está preocupado por estos detalles, o se dedica a ello alguna parte de la empresa cuyo cometido no es tan técnico y no prestan atención a esos detalles, …. O directamentelos de marquetin deciden que hay que hacerlo así.

¿Lo mejor de todo? Los asistentes, también gente interesada en la seguridad y que en un número no despreciable escribieron sus credenciales sin mayor problema.

Principios de seguridad de Saltzer y Schroeder

C3PO Muchas veces se utiliza la palabra principios como algo grandilocuente y altisonante para justificar casi cualquier cosa. En el contexto de seguridad (y seguramente en la vida también) los principios deberían ser normas o reglas de caracter general que nos permiten tomar decisiones y actuar cuando no tenemos otras normas más claras y directas. Serían las que nos permiten pensar en los problemas de los que todavía no somos conscientes, o afrontar los que ya conocemos pero para los que hemos de adoptar una aproximación más o menos consistente.

En este caso tenemos The Security Principles of Saltzer and Schroeder.

This kind of arrangement is accomplished by providing, at the higher level, a list-oriented guard whose only purpose is to hand out temporary tickets which the lower level (ticket-oriented) guards will honor

Los principios serían:

  • Economía del mecanismo. Esto es, mantener el sistema tan pequeño y simple comoo sea posible.
  • Por defecto, fallar de forma segura. Basar las decisiones sobre acceso en lo que está permitido, en lugar de lo que está prohibido. De esta forma, si algo no está permitido por error es mejor (desde el punto de vista de la seguridad) que si está incorrectamente admitido.
  • Mediación completa. Esto es, siempre comprobar la autorización antes de conceder el derecho.
  • Mínimo privilegio. Tener permiso exclusivamente para hacer lo que necestia nuestro trabajo.
  • Mínimo común mecanimo. Minimizar la cantidad de información y otros artefactos compartidas entre diferentes usuarios o de la que dependen muchos usuarios.
  • Separación de privilegios. Cuando sea posible, un mecanismo de protección que necesita dos claves es más robusto y flexible que uno que sólo requiera una.
  • Diseño abierto. El diseño no puede ser secreto y la protección no debería basarse en el desconocimiento del atancante.
  • Sicológicamente aceptable. Si lo que se propone no entra en nuestros esquemas mentales puede que lo aceptemos, pero terminaremos tratando de saltarlas, aligerarlas o evitarlas.

Vale la pena leer el artículo porque utiliza ejemplso de la saga de películas de Star Wars.

Y vale la pena recordar los principios para cuando tengamos dudas sobre cómo realizar alguna tarea para la que no tenemos las reglas claras del todo.

Buscando código erróneo en foros de ayuda

Roto Los ejemplos de código son una fuente de alivio cuando solucionan nuestro problema y una fuente de disgustos cuando no entendemos muy bien lo que tenemos entre manos (o el que nos proporciona el código no entiende muy bien lo que tiene entre manos). Todavía peor es cuando el código mal hecho aparece en fuentes de referencia como pueden ser libros o tutoriales (o incompleto, que es algo que pasa muy frecuentemente: no tienen en cuenta la seguridad/robustez, por ejemplo).

En este caso traemos un estudio al que hacen referencia en Computer science students mine software developer forums to teach coding practices y el artículo se puede ver en [PDF] Automatically Mining Negative Code Examples from Software Developer Q & A Forums.

Se basaron en el análisis de lenguaje natural y las preguntas realizadas por foreros que, frecuentemente, aportan un fragmento de código que falla y el mensaje de error que han obtenido.

Curioso.

Identificación de programadores mediante su código

Iguales pero diferentes Seguimos con artículos de investigación que nos han llamado la atención. ¿Existe el estilo de programación? ¿Podemos identificar a alguien que desarrolla programas por su código? Parece que no sólo es cierto (siempre que tengamos código para comparar, claro) sino que también sería cierto con los binarios que se generan por el compilador a partir de ese código. Al menos, eso es lo que dicen en When Coding Style Survives Compilation: De-anonymizing Programmers from Executable Binaries. La preocupación de los autores se refiere a la privacidad y anonimato de los desarrolladores.

Del resumen, descompilando el código binario observan como algunas particularidades sintácticas se conservan y pueden obtenerse de nuevo:

We examine executable binary authorship attribution from the standpoint of machine learning, using a novel set of features that include ones obtained by decompiling the executable binary to source code. We show that many syntactical features present in source code do in fact survive compilation and can be recovered from decompiled executable binary.

La capacidad de atribución alcanzó un 92% de los 100 desarrolladores de una Google Code Jam:

We demonstrate this improvement on data from the Google Code Jam, obtaining attribution accuracy of up to 92% with 100 candidate programmers

Y parece robusta frente a intentos de ofuscación, intervenciones más agresivas del compilador, …

Muy interesante.

Estudio sobre el uso del goto en GitHub

Siga la flecha Parece que GitHub es una fuente inagotable de aprendizaje. Traemos hoy [PDF] An empirical study of goto in C code from GitHub repositories. En este caso estudian la utilización de esta conocida estructura de control que permite romper el flujo de cualquier programa cuando se cumplen determinadas condiciones (o dejan de cumplirse).

En general es una estructura de control que está mal vista desde el punto de vista del desarrollo estructurado de programas. Podemos recordar aquí el famoso [PDF] Edgar Dijkstra: Go To Statement Considered Harmful, de Edsger Dijkstra, uno de los padres de la programación estructurada. Sin embargo, es cierto que en algunos casos la estructura del programa puede mejorar mucho si se utiliza con ‘sabiduría’.

El artículo habla del uso del ‘goto’ por parte de los programadores (si lo utilizan y para qué) y su aparición en la correción de fallos después de lanzar una versión.

Se usa. A nivel de fichero:

Considerable use of goto at the file level: We find that 246,657 out of the 2,150,387 files (or 11.47%) examined in our study have at least one goto statement.

A nivel de proyectos:

We find that 3,093 out of the 11,627 projects (or 26.60%) have at least one file with a goto statement. We also find that more than half the projects have about 20% of the files that have at least one goto statement.

Se utiliza, fundamentalmente, para código de sistema y de red, pero también para otras cuestiones. Mirando en las funciones parece que el uso principal es para gestión de errores, limpieza (liberación de memoria, etc.). Otra característica interesante es que la mayoría de los saltos son hacia adelante y raramente se hacen hacia atrás.

We find that, in general, the use of goto is actually well disciplined. Most uses of goto statements are reasonably structured, filling the void of miss- ing higher-level constructs found in other languages. There are of course usages that are unstructured as Dijkstra feared, but they are overall in

Después de publicar una versión la tendencia era a que se mantengan más o menos el mismo número de ‘gotos’ en el código, por lo que los proyectos no parecen considerarlos como algo perjudicial y desaconsejable.

If we assume bugs in the post-release phase of a project as a measure of harm, then the small number of goto statements being removed/modified in bug fixes implies that goto statements were not consid- ered harmful enough to be removed/modified in the post-release phase of the project in most cases.

Interesante.

Seguridad de la gestión de acceso mediante SSH

Cerrado 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.

Traemos hoy aquí el informe [PDF] Security of Interactive and Automated Access Management Using Secure Shell (SSH) que habla del protocolo SSH desde el punto de vista de gestión en las organizaciones.

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.

Calidad del software y lenguajes de programación

Verificación de programas 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.

En todo caso, el efecto no es muy grande.

Puede que también tengan interés en leer los comentarios del hilo de Hacker News sobre el trabajo A Large Scale Study of Programming Languages and Code Quality in GitHub.

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.