Documental sobre la construcción de un submarino de la clase Astute

Repasando mis bookmarks he encontrado un documental realizado por la BBC sobre la construcción de un submarino nuclear de la clase Astute, nacida para adaptase a los nuevos teatros de operaciones resultantes del fin de la Guerra Fría:

Infraestructuras y construcción

Aunque el tema principal del artículo de viernes de Alberto Artero en el Confidencial son las corruptelas alrededor de la venta de los terrenos sobre los cuales se construyeron las carreteras de peaje radiales, desde mi punto de vista el primer párrafo que sirve de introducción al artículo es clave para entender muchas cosas.

España es probablemente el país con mejores infraestructuras del mundo. Aeropuertos, trenes y carreteras tienen una obsolescencia mínima, fruto de los excesos cometidos durante los años de vino y rosas, cuando el dinero parecía caer del cielo y se prefería atender la demanda de un político local antes que seguir un modelo económico racional

Otro opinión interesante es la afirmación que realiza Alberto Recarte en su artículo Indignados:

Desde 1975 hasta 2008 más de dos terceras partes de los empleos creados en esos años, alrededor de siete millones, lo fueron por el sector público y el sector de la construcción. El resto de la economía creó apenas dos millones de empleos

Y ahora las preguntas que me hago.

• España es un país que envejece. Su pirámide de población empieza a estar invertida. La crisis económica ha hecho que un porcentaje importante de inmigrantes vuelvan a sus países de origen. ¿De verdad una salida a la crisis económica puede ser que el estado invierta más en infraestructuras, cuando hay una exceso de capacidad?. Sólo tenemos que ver como han quebrado las radiales de Madrid, los aeropuertos fantasmas o el la ocupación de ciertas líneas ferroviarias.
• ¿Cómo puede pensarse en la recuperación de la construcción en un escenario de caída de población?.
• ¿Es posible salir de ese modelo de ladrillo, grandes constructoras pegadas al presupuesto público y generar empleo, a ser posible en sectores de alto valor añadido?

La pequeña historia detrás de las S-Boxes de DES

Ahora que están siendo publicadas noticias sobre el conocimiento por parte de la NSA del fallo de seguridad de openssl conocido como Heartbleed, y que ha sido usado durante un tiempo indeterminado para poder leer la memoria de los servidores que usaban esa versión vulnerable de openssl (incluyendo la clave privada), uno puede tener la curiosidad de preguntarse, ¿Qué información tienen los servicios secretos de los países sobre fallos de seguridad del software que usamos?. Bien, sirva esta pequeña introducción para contar un pequeño detalle del viejo algoritmo de cifrado DES

Data Encryption Standard o DES es un algoritmo de cifrado simétrico estandarizado en el año 1979. Uno de los componentes del algoritmo son las llamadas S-Boxes, que se encargan de realizar operaciones de sustitución. A su entrada se le presentan con un número de bits determinados, m, y su salida es un número n de bits, no necesariamente igual al de entrada. Durante las fases de diseño del algoritmo, como puede leerse en el artículo de la Wikipedia, la NSA modificó la estructura de estas cajas de sustitución. A lo largo de los años, se especuló mucho si dichas modificaciones no serían una puerta trasera en el algoritmo.

En realidad estas modificaciones lo que buscaron es hacer DES más robusto a un tipo de ataque llamado criptoanálisis diferencial, que a grandes rasgos consiste en ver como diferentes entradas de un algoritmo modifica las salidas del mismo. Esto, era conocido por IBM - donde se diseñó el algoritmo - y la NSA - que se encargó de auditarlo y en este caso mejorarlo en el año 1974. Sin embargo, esta técnica no se redescubrió y se hizo pública por Eli Biham y Adi Shamir , a finales de los años 80. En 1994 IBM publicó un artículo, The Data Encryption Standard (DES) and its strength against attacks, donde se reconocía, entre otras cosas, el conocimiento de esta técnica para atacar algoritmos criptográficos casi 20 años antes.

Dentro del mundo de la seguridad informática y la criptografía, hay ciertas noticias, que no deben de cogernos por sorpresa, entre ellas que los llamados 0-days estén en manos de los servicios secretos mucho tiempo antes de que se publiquen.

Convertir una imagen VMWARE a formato RAW para usar en Proxmox

Hace unos días tuve la necesidad de usar el disco duro virtual de una máquina virtual de vmware en un entorno de virtualización Proxmox. El formato de disco que utiliza vmware es VMDK, pero Proxmox no permite su uso de manera nativa. Hay que convertirlo a formato RAW. Este formato sería el equivalente a una imagen exacta si dicha máquina virtual se hubiese instalado en un disco físico.

Para realizar dicha conversión se usa una de las utilidades de qemu, qemu-img que permite convertir la imagen entre distintos formatos. La conversión se lleva a cabo en los siguientes pasos

gunzip imagen.vmdk.gz # Sólo si la imagen está comprimida con gzip
qemu-img convert -O raw imagen.vmdk imagen.raw # -O especifica el formato de conversión

Una vez que termine el proceso, el fichero imagen.raw tendrá una imagen de disco equivalente a la información que estaba almacenada en la vmware, y podrá usarse en una máquina virtual definida en Proxmox

Como curiosidad, una imagen de este tipo puede montarse a través del loopback de Linux. Sólo hay que ver donde empieza cada partición y de qué tipo es. Puede obtenerse dicha información con el comando fdisk

fdisk -l imagen.raw
 
Disk imagen.raw: 1073.7 GB, 1073741824000 bytes
255 heads, 63 sectors/track, 130541 cylinders, total 2097152000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000de2fb

Device      Boot      Start         End      Blocks   Id  System
imagen.raw1   *        2048  2012336127  1006167040   83  Linux

Puede verse de la salida del fdisk cual es el sector donde empieza la partición , 2048 y que el tamaño de cada sector es de 512 bytes. Por tanto, el offset en bytes donde empieza la partición es 2048 * 512 = 1048576 . Se puede montar dicha partición en Linux con

mount -o loop,offset=1048576 imagen.raw /mnt

Controlar el registro de consultas de MySQL (II)

En la primera entrada sobre el control del registro de consultas de MySQL describía las variables que controlan la configuración del mismo.Ahora voy a explicar como consultarlas y modificarlas para configurar el registro de consultas según queramos.

Una vez conectado a través de la herramienta de línea de comandos a un servidor MySQL se puede ver cual es la configuración actual del registro de consultas a través de la siguiente consulta:

mysql> select @@general_log,@@general_log_file,@@Log_output;
+---------------+--------------------+--------------+
| @@general_log | @@general_log_file | @@Log_output |
+---------------+--------------------+--------------+
|             0 | /tmp/mysql.log     | FILE         |
+---------------+--------------------+--------------+
1 row in set (0.00 sec)

En este caso:

• El registro general está desactivado.
• El fichero de registro es /tmp/mysql.log.
• La salida de los registros es un fichero FILE.

Si se quiere activar el log general, en una configuración com la anterior, bastaría con introducir la orden:

mysql> set global general_log=1;
Query OK, 0 rows affected (0.00 sec)

Se puede configurar el registro de consultas para que almacene la información en una tabla de la base de datos. Esta tabla es fija , se llama general_log y está en la base de datos mysql. La estructura de la misma puede consultarse con la siguiente orden:

mysql> desc mysql.general_log;
+--------------+------------------+------+-----+-------------------+-----------------------------+
| Field        | Type             | Null | Key | Default           | Extra                       |
--------------+------------------+------+-----+-------------------+-----------------------------+
| event_time   | timestamp        | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| user_host    | mediumtext       | NO   |     | NULL              |                             |
| thread_id    | int(11)          | NO   |     | NULL              |                             |
| server_id    | int(10) unsigned | NO   |     | NULL              |                             |
| command_type | varchar(64)      | NO   |     | NULL              |                             |
| argument     | mediumtext       | NO   |     | NULL              |                             |
+--------------+------------------+------+-----+-------------------+-----------------------------+

6 rows in set (0.00 sec)

Las siguientes órdenes activarían el registro a la tabla mysql.general_log

mysql> set global general_log=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set global log_output='TABLE';
Query OK, 0 rows affected (0.00 sec)
mysql> set global general_log=1;
Query OK, 0 rows affected (0.00 sec)

Ahora con la siguiente orden se puede ver los resultados almacenados en dicha tabla de registros:

mysql> select * from mysql.general_log;
+---------------------+---------------------------+-----------+-----------+--------------+----------------------------------------------------------------------------------------------------------------------+
| event_time          | user_host                 | thread_id | server_id | command_type | argument                                                                                                             |
+---------------------+---------------------------+-----------+-----------+--------------+----------------------------------------------------------------------------------------------------------------------+
| 2014-04-05 00:43:14 | root[root] @  [127.0.0.1] |    109942 |         0 | Query        | select @@version                                                                                                     |
| 2014-04-05 00:43:16 | root[root] @  [127.0.0.1] |    109942 |         0 | Query        | set global general_log=0
+---------------------+---------------------------+-----------+-----------+--------------+----------------------------------------------------------------------------------------------------------------------+

Todas estas operaciones suponen que la versión del servidor MySQL que se está usando es al menos la 5.1.12

Referencias

• 5.2.3 The General Query Log