Publicado
Comentarios Ninguno

Hola a todos:

Para un proyecto desarrollado hace tiempo, me ví en la tesitura de trabajar con coordenadas GPS expresadas a modo de tuplas (latitud,longitud) y ubicaciones cercanas a ellas.

Para ello implementé un generador de coordenadas que a partir de una latitud y longitud inicial devuelve una lista de coordenadas no equidistantes pero si con una distribución uniforme con respecto a las iniciales.

Asi pues, aqui os dejo la implementación que he hecho para Python 3.x, por si os resulta de interés.


#!/usr/bin/env python3

“”“ Generador de coordenadas GPS uniformemente distribuidas. Luis González Fernández

Proyecto Samaritano. “”“

import math
import sys
from random import uniform
import urllib.request as req

GOOGLE_KEY = ‘’ # Introduce Aqui tu API Key.

def get_randpoints(start_lat, start_lon, num_points, distance): “”“ Get a tuple-list of num_points points using start_lat and start_lon as initial position “”“

points = [] radiusDeg = distance / 111300 for x in range(num_points): u = uniform(0, distance) v = uniform(0, distance) w = radiusDeg * math.sqrt(u) t = 2 * math.pi * v x = w * math.cos(t) y = w * math.sin(t) new_x = x / math.cos(start_lon) new_lon = new_x + start_lon new_lat = y + start_lat points.append((new_lat, new_lon)) return points

def get_static_map(points): “”“ Generate an URL to view markers in Google Maps “”“

center = ‘%s %s’ % (start_lat, start_lon) markers = ‘’ for marker in points: markers = ‘%s|%s %s’ % (markers, marker0, marker1) url_enc = ‘https://maps.googleapis.com/maps/api/staticmap?zoom=13&size=800×800&center=’ url_enc += ‘%s&&markers=%s&key=%s’ % (req.pathname2url(center), req.pathname2url(markers), GOOGLE_KEY) print(url_enc)

if name == ‘main’: start_lat = 40.4167754 start_lon = -3.7037901999999576 points = get_randpoints(start_lat, start_lon, num_points=25, distance=150) print(‘GPS Points:’) print(points)

if len(sys.argv) > 1 and sys.argv1 == ‘—googlemap’: get_static_map(points)

El resultado despues de su ejecución es el siguiente:


luisgf@spock:~/sources/randpoints$ ./randpoints.py
GPS Points:
[(40.40479968057609, -3.712111050118443), (40.41369828172601, -3.7099730047252133), (40.41043171218737, -3.695068873734699), (40.41067868047103, -3.691908811749225), (40.415521999421536, -3.7144828205662557), (40.41298456075798, -3.7168178121142614), (40.404110551594066, -3.7010959217114876), (40.41415267232443, -3.6938774321628465), (40.41371505118601, -3.6870846300836613), (40.40512085787757, -3.69130316024685), (40.40109972581277, -3.7021028110441585), (40.42127531091277, -3.702362360828427), (40.420400176012485, -3.7203642437292643), (40.42424868417277, -3.694165638052598), (40.4049746819123, -3.7049594045364715), (40.41997317083771, -3.6901029139034147), (40.425125170914626, -3.7103067154939557), (40.41951433402019, -3.6978724777633674), (40.41158077712336, -3.7059201357503113), (40.40960583055256, -3.700197078910183), (40.407166710868665, -3.690048922797546), (40.420609609863156, -3.703524163468323), (40.40319129257425, -3.713529530448146), (40.42447782238628, -3.693142567275283), (40.429153155633045, -3.7123922703351653)]

Si representamos las coordenadas en Google Maps, quedarían tal que así:

Un Saludo a todos y espero que os sea de utilidad.

Autor

Publicado
Comentarios Ninguno

Hola a todos:

Con la migración de los certificados que opero hacia let’s encrypt han aparecido una serie de inconvenientes que degradan la configuración SSL y por consiguiente la seguridad de la transmisión.

Todos mis sistemas emitian las cabeceras necesarias para soportar HSTS (HTTP Strict Transport Security) y HPKP (Public Key Pinning Extension for HTTP).

Para los neófitos la siguiente explicación rápida:
HSTS: Es un mecanismo por el cual el servidor web le indica a un navegador que las peticiones que realicen a un determinado sitio, deben ir siempre a través de HTTPS.

HPKP: Es un mecanismo que informa al navegador de los certificados autorizados que puede ver a la hora de conectarse a un sitio. Si vé otros certificados, podriamos ser victimas de un ataque tipo Man-in-the-middle, asi que impedirá tal conexion.

Con los certificados tradicionales, esto no suponia demasiado problema ya que su duración es elevada (1 o 2 años), lo cual me permitia generar pins con una duración un poco inferior a la caducidad de los certificados y darme un margn de maniobra amplio para renovarlos y generar los nuevos pins.

El problema surje con let’s encrypt (servicio fantástico!!!) ya que la duración de sus certificados actualmente es de 3 meses y en un futuro podría incluso reducirse.

Asi pues, para lidiar con la problematica he desarrollado un pequeño programa en Perl, (vaaaale es broma), en Python 3.5 que genera los pins HPKP de forma automática. El siguiente programa se ejecutará justo despues de la renovación del certificado y generará un PIN con una duración no superior a la del certificado con respecto a la fecha actual. Esto impedirá crear un pin que tenga validez una vez el certificado haya expirado.

La idea detrás de esto es que este programa se ejecute como hook o plugin del cliente let’s encrypt, no obstante y mientras esté en periodo de pruebas, vivirá como un programa independiente.

Configuración de Apache:

<IfModule mpm_itk_module>
    AssignUserID luisgf-web luisgf-web
</IfModule>
<IfModule mod_ssl.c>
    SSLUseStapling on
    SSLStaplingCache shmcb:/datos/webs/ocsp_stapling(512000)
    <VirtualHost *:443>
        ServerName www.luisgf.es
        ServerAlias luisgf.es
        DocumentRoot /datos/webs/luisgf.es
        ErrorLog ${APACHE_LOG_DIR}/www.luisgf.es_error.log
        CustomLog ${APACHE_LOG_DIR}/www.luisgf.es_access.log combined
        # Configuracion SSL
        SSLEngine on
        SSLCompression Off
        SSLProtocol all -SSLv2 -SSLv3
        SSLHonorCipherOrder On
        SSLCipherSuite EECDH+AES:ECDHE+ECDSA:ECDHE+RSA:ECDHE+AES:DHE+RSA:ECDH+AES:DHE+AES:EDH+AES:-SHA1:DHE+AES:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
        SSLCertificateFile /etc/letsencrypt/live/luisgf.es/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/luisgf.es/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/luisgf.es/chain.pem
        # Activamos HSTS
        Header always set Strict-Transport-Security "max-age=16070400; includeSubDomains"
        # Activamos HPKP leyendo la directiva generada por hpkp-python
        Include /etc/apache2/conf-available/hpkp-pin_python-vigo.es.conf
        # http://stackoverflow.com/questions/17092154/x-frame-options-on-apache
        Header set X-Frame-Options SAMEORIGIN
        # http://stackoverflow.com/questions/9090577/what-is-the-http-header-x-xss-protection
        Header set X-XSS-Protection "1; mode=block"
    </VirtualHost>
</IfModule>

Genero el pin con:

./hpkp.py -f /etc/letsencrypt/live/www.luisgf.es/cert.pem -u http://www.luisgf.es/hpkp_report -d > /etc/apache2/conf-available/hpkp-pin_www.luisgf.es.conf

Ya sólo queda reiniciar el apache para que tenga en cuenta los cambios.

Más información:
HPKP-Python: https://github.com/luisgf/hpkp-python
HSTS: http://tools.ietf.org/html/rfc6797
HPKP: https://tools.ietf.org/html/rfc7469

Autor
Categorías Linux

Publicado
Comentarios Ninguno

La entrada de hoy viene a hablaros sobre discos cifrados con LUKS y sobre como realizar un camuflaje
de los mismos para que a ojos de un simple mortal dicho disco simule estar vacío y/o recién formateado.

La idea detrás de esto es simple, básicamente consiste en “inocular” las estructuras de un sistema de ficheros en el disco de forma que cualquier intento de montarlo resulte exitoso y muestre como resultado un volumen vacío, cuando en realidad su contenido es el del volumen cifrado. Como sistema de fichero para el camuflaje he elegido FAT32 dado lo simple de su implementación y lo fácil que resulta manipularlo.

Este pequeño gráfico muestra de forma visual lo que trato de conseguir.

Para la realización de esta prueba de concepto he desarrollado un pequeño script en bash que realiza todo el procedimiento de forma desatendida. Ni que decir tiene que este procedimiento es destructivo e irreversible, así que antes de ponerte a jugar con el, haz un backup de tus datos.

Advertencia: Cualquier intento de escribir en la partición de camuflaje supondrá la corrupción de datos en el volumen cifrado. Estáis avisados!


luisgf@NCC1701B:~/camuflajeluks$ cat camuflaje.sh
#!/bin/bash

DISPOSITIVO=/dev/loop1
PARTICION=/dev/loop1p1
SECTOR_SIZE=512
SECT_RESERVADOS=32
NUM_FATS=1
LUKS_NAME=camuflaje1
LUKS_HEADER=camuflaje1_header.luks
MOUNTPOINT=/camuflaje

echo “Este programa crea un camuflaje para el volume LUKS en $DISPOSITIVO”
echo “Aviso! La operacion es terriblemente destructiva.”
echo “”

echo -n “>>> Destruyendo disco”
OUT=$(dd if=/dev/zero of=$DISPOSITIVO bs=1064976 count=1 2>/dev/null)
if [ $? -ne 0 ]; then echo “ ERROR” exit
else partprobe $DISPOSITIVO 2>/dev/null echo “ OK”
fi

echo -n “>>> Creando etiqueta MBR
OUT=$(parted -a optimal -s $DISPOSITIVO unit MB mklabel msdos)
if [ $? -ne 0 ]; then echo “ ERROR” exit
else partprobe $DISPOSITIVO echo “ OK”
fi

echo -n “>>> Creando particiones”
OUT=$(parted -a optimal -s $DISPOSITIVO unit MB mkpart primary 0% 100%)
if [ $? -ne 0 ]; then echo “ ERROR” exit
else partprobe $DISPOSITIVO echo “ OK”
fi

DEV_SECTORS=`blockdev —getsz $PARTICION`
if [ $? -ne 0 ]; then echo “ERROR detectando bloques disponibles de la particion” exit
fi

echo -n “>>> Creando Sistema de ficheros FAT32”
OUT=$(mkfs.vfat -F 32 -I -f $NUM_FATS -S $SECTOR_SIZE -R $SECT_RESERVADOS $PARTICION)
if [ $? -ne 0 ]; then echo “ ERROR” exit
else echo “ OK”
fi

  1. Tamaño de la FAT en sectores
    FATSZ=`od $PARTICION -j 36 -i -A n -N 4 | tr -d ‘ ‘`
    if [ $? -ne 0 ]; then echo “ERROR detectando tamaño de FAT” exit
    fi
  1. Primer sector de datos
    DATA_SECTOR=$(($SECT_RESERVADOS + $(($NUM_FATS*$FATSZ)) + 15))
  1. Offset donde empiezan los datos
    DATA_OFFSET=$(($DATA_SECTOR*$SECTOR_SIZE))

echo -n “>>> Creando cabecera aislada”
OUT=$(dd if=/dev/zero of=$LUKS_HEADER bs=4M count=1 2>/dev/null)
if [ $? -ne 0 ]; then echo “ ERROR” exit
else echo “ OK”
fi

echo “>>> Creando Cryptocontenedor LUKS
cryptsetup luksFormat $PARTICION —align-payload=$DATA_SECTOR —header=$LUKS_HEADER -b $FATSZ
if [ $? -ne 0 ]; then echo “ ERROR” exit
fi

echo “>>> Montando cryptocontenedor en $MOUNTPOINT”
cryptsetup luksOpen $PARTICION —header=$LUKS_HEADER $LUKS_NAME -b $FATSZ

echo -n “>>> Creando FS en cryptcontenedor camuflado”
OUT=$(mkfs.ext4 /dev/mapper/$LUKS_NAME -q)
if [ $? -ne 0 ]; then echo “ ERROR” exit
else echo “ OK”
fi

echo -n “>>> Montando cryptocontenedor camuflado”
OUT=$(mount /dev/mapper/$LUKS_NAME $MOUNTPOINT)
if [ $? -ne 0 ]; then echo “ ERROR” exit
else echo “ OK”
fi

echo “>>> Terminado. AVISO! Cualquier intento de escribir en el camuflaje implica una corrupcion del cryptocontenedor”

Autor
Categorías Linux

Publicado
Comentarios Ninguno

La siguiente entrada del blog trata de la implementación de HPKP y su configuración en el servidor Web Apache.

¿Qué es HPKP?

HPKP, acrónimo de “HTTP Public Key Pinning” es un sistema que permite especificar que “Entidad Certificadora” debe ser usada al comprobar el certificado del sitio web al que se intenta acceder. La idea detrás de HPKP es sencilla, a través de una cabecera HTTP (Public-Key-Pinning) se especifica una serie de fingerprints autorizados, de forma que si un navegador intenta acceder al sitio web y la cadena de validación SSL no emplea los de esta lista se impide el acceso a la web. Para los que estéis un poco al tanto en temas de seguridad, es un mecanismo que evita los ataques tipo MiTM.

La verificación se puede hacer en cualquier punto de la cadena de certificados, no obstante hay ciertos puntos más recomendables que otros, como ejemplo, es preferible hacer pinning sobre el certificado intermedio antes que sobre el certificado del propio servidor.

Estructura de la cabera Public-Key-Pins

Para formar una cabecera válida hacen falta 2 parámetros, pin-sha256 y expireTime.

pin-sha256: Debe contener el SPKI del certificado codificado en Base64.
expireTime: Tiempo especificado en segundos, en el cual el navegador recordará que a este sitio solo puede accederse a través de los certificados definidos en la cabecera.
includeSubdomains: Parámetro opcional. Extiende la validación a todos los subdominios.
report-uri: Parámetro opcional. URL donde se reportarán los errores HPKP.

Public-Key-Pins: pin-sha256=“base64==”; max-age=expireTime [; includeSubdomains][; report-uri=http://www.example.com
Extracción del SPKI y cálculo del HASH.
La extracción del SPKI es un proceso sencillo, para ello utilizaremos una Shell y el comando openssl.

openssl x509 -noout -in certificado.pem -pubkey | \
openssl asn1parse -noout -inform pem -out /tmp/public.key;
openssl dgst -sha256 -binary /tmp/public.key | openssl enc -base64

Para este sitio web que estás viendo, el pinning se ha realizado para el certificado siguiente:
“StartCom Class 1 Primary Intermediate Server CA”, el cual nos dá como resultado:

kb6xLprt35abNnSn74my4Dkfya9arbk5zN5a60YzuqE=

Con toda esta información, el proceso para activar HPKP en apache es muy sencillo, basta con añadir la siguiente directiva dentro de un . Advertencia, es necesario que el servidor web tenga activado “mod_headers”

Header set Public-Key-Pins "pin-sha256=\"kb6xLprt35abNnSn74my4Dkfya9arbk5zN5a60YzuqE=\"; max-age=2592000; includeSubDomains"

Para facilitar un poco esta tarea, he realizado el siguiente script, el cual recibe como parámetro la ruta hacia un certificado y devuelve en pantalla la sintaxis exacta a copiar en la configuración de Apache.

#!/bin/sh
if [ "$1" != "" ]; then
  openssl x509 -noout -in $1 -pubkey | openssl asn1parse -noout -inform pem -out /tmp/public.key
  pin=`openssl dgst -sha256 -binary /tmp/public.key | openssl enc -base64`
  rm -fr /tmp/public.key
  echo "Header set Public-Key-Pins \"pin-sha256=\\\"$pin\\\"; max-age=2592000; includeSubDomains\""
else
  echo "Uso: $0 certificado.pem"
fi

Autor
Categorías Linux

Publicado
Comentarios Ninguno

Hola a todos:

Una vez más he aqui con un nuevo problema a solventar a la hora de lidiar con linux en mi Macbook pro Retina (MacBook11,1). Una vez instalado el sistema rápidamente caigo en la cuenta de que un core del mismo está constantemente al 75% de carga y sorpresa, yo no estoy haciendo nada con el ordenador.

Abro una consola y me busco los procesos más activos en el sistema.

# top -n 2 -d 10 -b | head -n 20

Esto me muestra como resultado un thread del kernel “kworker/0:11”. Así que el siguiente paso es buscar que dispositivo está “ocupando tanto” al kernel, para ello, me doy un paseo por el sysfs con el siguiente comando y encuentro lo siguiente:

# grep . -r /sys/firmware/acpi/interrupts/

/sys/firmware/acpi/interrupts/gpe65:       0   invalid
/sys/firmware/acpi/interrupts/gpe66:492016902   enabled
/sys/firmware/acpi/interrupts/gpe5A:       0   invalid

Vaya, hay un dispositivo que está entreteniendo al kernel demasiado. Una búsqueda rápida por internet me lleva hasta el siguiente Bug de Bugzilla

Si bien, parece ser que hay unos cuantos parches en upstream como medida paliativa paso por desactivar ese dispositivo mientras investigo un poco más sobre que hace y en que me puede afectar esta desactivación.

# echo disable > /sys/firmware/acpi/interrupts/gpe66

Autor
Categorías Linux, Mac

← Anteriores Posteriores →