seguridad

Permisos en disco duro USB bajo Win 7

 Lun, 28/09/2015 - 10:04     Sandor

Como ya os he contado en alguna otra ocasión, tengo un disco duro cifrado (durante años con Truecrypt y ahora, después de la polémica de los servicios secretos y demás, con Veracrypt, un digno sucesor que guarda compatibilidad con Truecrypt).

El caso es que al migrar uno de mis ordenadores a Windows 7, me dí cuenta que no podía ejecutar  programas desde la unidad montada a no ser que fuera ejecutado como administrador. También mi imprescindible wiki quedó como solo lectura y, en definitiva, era incapaz de realizar cambios en un montón de documentación con la que trabajo diariamente.

Tras leer un poco, me dí cuenta que era un tema de permisos, así que opté por otorgar al grupo "Todos" permisos totales. Al ser un volumen cifrado, tampoco consideré una operación de riesgo hacerlo así.

Para asignar al grupo "Todos" permisos de Control Total, lo podemos hacer desde la consola, o desde el entorno gráfico. Para hacerlo desde la consola, debemos ejecutar con permisos de administrador la utilidad cmd, y hacer uso del comando ICACLS. Un simple icacls /? nos ofrece la ayuda básica:

ICACLS nombre /save archivoACL [/T] [/C] [/L] [/Q]
    almacena las DACL para los archivos y carpetas cuyos nombres coinciden
    en archivoACL para su uso posterior con /restore. Tenga en cuenta que no
    se guardan las SACL, el propietario ni las etiquetas de identidad.

ICACLS directorio [/substitute SidOld SidNew [...]] /restore archivoACL
                  [/C] [/L] [/Q]
    aplica las DACL almacenadas a los archivos del directorio.

ICACLS nombre /setowner usuario [/T] [/C] [/L] [/Q]
    cambia el propietario de todos los nombres coincidentes. Esta opción
    no fuerza un cambio de propiedad; use la utilidad takeown.exe
    con esta finalidad.

ICACLS nombre /findsid Sid [/T] [/C] [/L] [/Q]
    busca todos los nombres coincidentes que contienen una ACL
    que menciona el SID de forma explícita.

ICACLS nombre /verify [/T] [/C] [/L] [/Q]
    busca todos los archivos cuya ACL no está en formato canónico o cuyas
    longitudes no son coherentes con los recuentos de la ACE.

ICACLS nombre /reset [/T] [/C] [/L] [/Q]
    reemplaza las ACL con ACL heredadas predeterminadas para todos
    los archivos coincidentes.

ICACLS nombre [/grant[:r] Sid:perm[...]]
       [/deny Sid:perm [...]]
       [/remove[:g|:d]] Sid[...]] [/T] [/C] [/L] [/Q]
       [/setintegritylevel nivel:directiva[...]]

    /grant[:r] Sid:perm concede los derechos de acceso al usuario
        especificado. Con :r, los permisos reemplazan cualquier permiso
        explícito concedido anteriormente. Sin :r, los permisos se agregan a
        cualquier permiso explícito concedido anteriormente.

    /deny Sid:perm deniega de forma explícita los derechos de acceso al
        usuario especificado. Se agrega una ACE de denegación explícita
        para los permisos indicados y se quitan los mismos permisos de
        cualquier concesión explícita.

    /remove[:[g|d]] Sid quita todas las repeticiones del SID en la ACL. Con
        :g, quita todas las repeticiones de derechos concedidos a ese SID. Con
        :d, quita todas las repeticiones de derechos denegados a ese SID.

    /setintegritylevel [(CI)(OI)]nivel agrega de forma explícita una ACE de
        integridad a todos los archivos coincidentes. El nivel se debe
        especificar como:
            L[ow] - para bajo
            M[edium] - para medio
            H[igh] - para alto
        Las opciones de herencia para la ACE de integridad pueden preceder al
        nivel y se aplican sólo a los directorios.

    /inheritance:e|d|r
        e - habilita la herencia
        d - deshabilita la herencia y copia las ACE
        r - quita todas las ACE heredadas

Nota:
    Los SID pueden tener un formato numérico o de nombre descriptivo. Si se da
    un formato numérico, agregue un asterisco (*) al principio del SID.

    /T indica que esta operación se realiza en todos los archivos o
        directorios coincidentes bajo los directorios especificados en el
        nombre.

    /C indica que esta operación continuará en todos los errores de archivo.
        Se seguirán mostrando los mensajes de error.

    /L indica que esta operación se realiza en el vínculo simbólico en sí
        en lugar de en su destino.

    /Q indica que icacls debe suprimir los mensajes de que las operaciones
       se realizaron correctamente.

    ICACLS conserva el orden canónico de las entradas ACE:
            Denegaciones explícitas
            Concesiones explícitas
            Denegaciones heredadas
            Concesiones heredadas

    perm es una máscara de permiso que puede especificarse de dos formas:
        una secuencia de derechos simples:
                N - sin acceso
                F - acceso total
                M - acceso de modificación
                RX - acceso de lectura y ejecución
                R - acceso de sólo lectura
                W - acceso de sólo escritura
                D - acceso de eliminación
        una lista separada por comas entre paréntesis de derechos específicos:
                DE - eliminar
                RC - control de lectura
                WDAC - escribir DAC
                WO - escribir propietario
                S - sincronizar
                AS - acceso al sistema de seguridad
                MA - máximo permitido
                GR - lectura genérica
                GW - escritura genérica
                GE - ejecución genérica
                GA - todo genérico
                RD - leer datos/lista de directorio
                WD - escribir datos/agregar archivo
                AD - anexar datos/agregar subdirectorio
                REA - leer atributos extendidos
                WEA - escribir atributos extendidos
                X - ejecutar/atravesar
                DC - eliminar secundario
                RA - leer atributos
                WA - escribir atributos
        los derechos de herencia pueden preceder a cualquier forma y se
        aplican sólo a directorios:
                (OI) - herencia de objeto
                (CI) - herencia de contenedor
                (IO) - sólo herencia
                (NP) - no propagar herencia
                (I) - permiso heredado del contenedor principal

Ejemplos:

        icacls c:\windows\* /save archivoACL /T
        - Guardará todas las ACL para todos los archivos en c:\windows
          y sus subdirectorios en archivoACL.

        icacls c:\windows\ /restore archivoACL
        - Restaurará todas las ACL para cada archivo dentro de
          archivoACL que exista en c:\windows y sus subdirectorios.

        icacls file /grant Administrador:(D,WDAC)
        - Concederá al usuario permisos de administrador para eliminar y
          escribir DAC en el archivo.

        icacls file /grant *S-1-1-0:(D,WDAC)
        - Concederá al usuario definido por el SID S-1-1-0 permisos para
          eliminar y escribir DAC en el archivo.

Este mismo proceso se puede hacer haciendo uso del entorno gráfico: botón derecho sobre la letra de la unidad, ir a la pestaña Seguridad -> Opciones avanzadas -> Permisos -> Cambiar permisos -> Agregar -> añadir grupo "Todos", seleccionar "Control total" y aplicar los cambios a "Esta carpeta, subcarpeta y archivos".

Tardará un poquito, en función del tamaño de vuestro disco, pero no volvereis a comeros la cabeza con este tema :-)

SSL - Certificado firmado por nuestra propia entidad certificadora

 Mar, 15/10/2013 - 11:34     Sandor

Recientemente nos ha caducado el certificado que corría el servidor Apache de la intranet oficina, lo cual me ha obligado a repasar la documentación para volver a generar unos nuevos certificados (como es algo que no suelo hacer habitualmente, ya había olvidado como hacerlo). El caso es que me he vuelto loco repasando mis enlaces antiguos, así que me he animado a crear una nueva entrada en el blog, que me sirva de ayuda en el futuro (y espero que a vosotros). Hasta ahora tirábamos con un certificado autofirmado, pero después de encontrar esta utilísima guia del blog Tecnología, Sistemas, Seguridad y Ethical Hacking, me he decidido a crear un nuevo certificado creando antes una entidad certificadora propia. Como ha salido todo bien :-), aquí dejo las instrucciones para guiarme en el futuro, gran parte de ellas copiadas directamente de la guia anteriormente comentada, que a su vez, por lo que cuenta el autor, ha sido extraida en gran parte del sitio web www.linuxito.com.ar.

Cómo crear un certificado para Apache, firmado por nuestra propia entidad certificadora, y con arranque automático (sin petición de contraseña al reiniciar el servicio)

Paso 1. Crear la estructura de directorios donde crearemos los certificados

Los certificados que crearemos sólo servirán para uso personal ya que no son firmados por una autoridad de confianza como Verising, como un mecanismo de proveer una forma segura de comunicarse con tus servicios, para que las contraseñas o cualquier dato no viaje plano por la red.
De más está decir que necesitamos OpenSSL instalado en el ordenador que utilizaremos para administrar los certificados o crear las solicitudes de certificado. Yo particularmente trabajo con Debian (stable), por lo que los comandos reproducidos serán los necesarios en la versión que utilizo. No obstante, las indicaciones aquí descritas deberían ser válidas en cualquier distribución Linux.

Para comenzar debemos crear la estructura de directorios donde se almacenará toda la información relativa a nuestra PKI (Public Key Infraestructure):

# mkdir –m 0755 /CA
# mkdir –m 0755 /CA/private
# mkdir –m 0755 /CA/certs
# mkdir –m 0755 /CA/newcerts
# mkdir -m 0755 /CA/crl
  • "CA" será el directorio de trabajo de la Autoridad Certificadora.
  • "certs" será el directorio donde se ubicarán los certificados.
  • "newcerts" es el directorio donde OpenSSL pone los certificados creados en formato PEM (sin encriptar) y en la forma [n° de serie].pem (por ejemplo: 15.pem).
  • "crl" es el directorio donde se coloca la lista de revocación de certificados.
  • "private" es el directorio donde se colocan las claves privadas (este directorio debe tener permisos extremadamente restrictivos, para que sólo sean leídos por root).

Las extensiones de archivos que se generarán en estos directorios serán las siguientes:

  • KEY: Claves privadas (deben tener permisos restrictivos).
  • CSR: Pedido de certificado (estos pedidos serán firmados por la CA para convertirse en certificados, luego pueden ser eliminados).
  • CRT: Certificado (puede ser distribuido públicamente).
  • PEM: Archivos que contienen tanto el certificado como la clave privada (deben tener permisos restrictivos).
  • CRL: Lista de revocación de certificados (puede ser públicamente distribuida).

Para la configuración inicial de OpenSSL, copiamos el archivo de configuración por defecto de OpenSSL (openssl.cnf) al directorio /CA. En Debian se encuentra en el directorio /etc/ssl/openssl.cnf:

# cp /etc/ssl/openssl.cnf /CA
# chmod 0600 /CA/openssl.cnf

Luego creamos dos archivos que funcionan como bases de datos para OpenSSL:

# touch /CA/index.txt
# echo '01' > /CA/serial

Debido a que utilizamos un directorio personalizado para nuestros certificados, se necesitan algunas modificaciones en el archivo /CA/openssl.cnf, así que lo abrimos con nuestro editor de texto preferido (ojo, siempre como root) y nos debe quedar así:

[ CA_default ]
dir = /CA # Directorio donde se guarda todo <== CAMBIAR ESTA LINEA
certs = $dir/certs # Directorio donde se guardan certificados emitidos
crl_dir = $dir/crl # Directorio donde se guardan crl enviados
database = $dir/index.txt # Archivo índice de la base de datos
#unique_subject = no # Setear en 'no' para permitir que se creen diferentes certificados con el mismo 'subject'
new_certs_dir = $dir/newcerts # Directorio donde se guardan nuevos certificados
certificate = $dir/ca.crt # Certificado de la CA <== CAMBIAR ESTA LINEA
serial = $dir/serial # Número de serie actual
#crlnumber = $dir/crlnumber # El número de crl actual debe comentarse para dejar una CRL V1
crl = $dir/crl.pem # La CRL actual
private_key = $dir/private/ca.key # La clave privada <== CAMBIAR ESTA LINEA
RANDFILE = $dir/private/.rand # Número aleatorio privado
x509_extensions = usr_cert # Extensiones a agregar al certificado

Se puede personalizar aún más para definir políticas para la creación y firmado de los certificados, o definir extensiones deseadas para nuevos certificados.
Los certificados que vamos a crear con esta configuración, son certificados de propósito general y su uso no se restringe sólo a autenticación de servidores. Debe notarse que las claves privadas no serán protegidas por una passphrase, para que cuando los servicios se reinicien no soliciten el ingreso de passphrases. Esto implica que se debe restringir cuidadosamente el acceso de lectura sobre las claves privadas, para que sólo el usuario root, o el usuario privilegiado utilizado por los servicios, pueda leer estos archivos.

¡Ya tenemos nuesta base para comenzar a crear nuestros certificados!

Paso 2. Crear nuestra propia Entidad Certificadora (CA)

Después de terminar la configuración inicial, podemos crear un certificado auto-firmado que será utilizado como el certificado de nuestra CA. Este será utilizado para firmar las solicitudes de certificados:

# cd /CA
# openssl req -config openssl.cnf -new -x509 -extensions v3_ca -days 3650 -keyout private/CA_nombre.key -out certs/CA_nombre.crt
Generating a 1024 bit RSA private key
................++++++
...............++++++
writing new private key to 'private/CA_nombre.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Tu provincia
Locality Name (eg, city) []:Tu ciudad
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Nombre de empresa, proyecto o lo que sea
Organizational Unit Name (eg, section) []:Nombre de departamento o lo que se te ocurra
Common Name (eg, YOUR name) []:Tu nombre
Email Address []:Tu dirección de correo electrónico

Se crearán dos archivos: certs/CA_nombre.crt, certificado de la CA públicamente disponible y con lectura para todo el mundo; private/CA_nombre.key, clave privada del certificado de la CA. A pesar de que está protegida por una contraseña se debe restringir el acceso:

# chmod 0400 /CA/private/CA_nombre.key

Paso 3. Creación del pedido del certificado

Para proceder con la creación de un certificado para un servidor, lo primero que hacemos es generar el pedido de certificado:

#cd /CA
#openssl req -config openssl.cnf -new -nodes -keyout private/apachessl.key -out apachessl.csr -days 3650
Generating a 1024 bit RSA private key
.......................++++++
.....++++++
writing new private key to 'private/apachessl.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]: Tu provincia
Locality Name (eg, city) []: Tu ciudad
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Nombre de empresa, proyecto o lo que sea
Organizational Unit Name (eg, section) []: Nombre de departamento o lo que se te ocurra
Common Name (eg, YOUR name) []: El nombre de tu dominio
Email Address []: Tu dirección de correo electrónico
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
  • La opción "nodes" es necesaria para que la clave privada no sea protegida con una passphrase. Si el certificado no se va a utilizarar para la autenticación de servidores, no se debería incluir en la opción anterior.
  • El "Common Name" (CN) es la información que identifica de forma única al servicio, por lo que debemos asegurarnos de escribirlo correctamente.
  • Personalmente, recomiendo rellenar todos los campos que nos pidan, ya que si los dejamos vacios, se nos rellenarán con los datos por defecto, y en ocasiones pueden inducirnos a pensar que hay algún error en ellos.

Al finalizar se crean dos archivos:

  • apachessl.csr: El pedido de certificado.
  • private/apachessl.key: La clave privada, que no ha sido protegida con una passphrase.

Como anteriormente, se deben crear permisos restrictivos sobre la clave privada, por ejemplo:

# chown root.root /CA/private/apachessl.key
# chmod 0400 /CA/private/apachessl.key

O (por ejemplo si el certificado es para un servidor Apache):

# chown root.apache /CA/private/apachessl.key
# chmod 0440 /CA/private/apachessl.key

Paso 4. Firma del pedido de certificado para generar el certificado para el servidor

A continuación firmamos el pedido de certificado para generar el certificado para el servidor:

# cd /CA
# openssl ca -config openssl.cnf -cert certs/CA_nombre.crt -policy policy_anything -out certs/apachessl.crt -infiles apachessl.csr
Using configuration from openssl.cnf
Enter pass phrase for /CA/private/CA_nombre.key:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Oct 16 07:36:10 2013 GMT
            Not After : Oct 14 07:36:10 2023 GMT
        Subject:
            countryName               = ES
            stateOrProvinceName       = Tu provincia
            localityName              = Tu ciudad
            organizationName          = Nombre de empresa, proyecto o lo que sea
            organizationalUnitName    = Nombre de departamento o lo que se te ocurra
            commonName                = El nombre de tu dominio
            emailAddress              = Tu dirección de correo electrónico
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                B5:9D:90:13:57:C7:3E:4B:5F:1A:41:B7:AA:A4:A2:DB:11:DB:03:F4
            X509v3 Authority Key Identifier:
                keyid:48:09:37:10:7E:A1:3E:42:17:4D:18:44:B6:13:FE:B9:AF:CD:CD:6F

Certificate is to be certified until Oct 14 07:36:10 2023 GMT (3650 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
  • La opción "-policy policy_anything" indica que no se requiere que los campos "Country", "State" o "City" coincidan con los de la CA.

Al finalizar se crean dos nuevos archivos:

  • certs/apachessl.crt: Certificado del servidor, que puede hacerse públicamente disponible.
  • newcerts/01.pem: El mismo certificado pero con el número de serie como nombre de archivo, no es necesario.

En este momento podemos eliminar el pedido de certificado, el cual no necesitaremos más (apachessl.csr):

# rm –f /CA/apachessl.csr

Paso 5. Creación de un archivo pkcs12 para instalar en navegadores

Como penúltimo paso, nos queda generar un archivo pkcs12, listo para ser cargado en los navegadores que necesitemos que tengan acceso a nuestro sitio.

# openssl pkcs12 -export -in certs/apachessl.crt -inkey private/apachessl.key -certfile certs/CA_nombre.crt -out apachessl_pck12.p12
Enter Export Password:
Verifying - Enter Export Password:

Paso 6. Copiando nuestros certificados a sus directorios destino

¡Recapitulemos! Con todos estos pasos, hemos generado un certificado autofirmado de Entidad Certificadora, un certificado para servidor firmado por esa Entidad Certificadora, y un archivo pkcs12 para instalar en navegadores. ¿Qué hacemos ahora?

En el servidor:

  • CA_nombre.crt y CA_nombre.key : estos dos archivos forman el certificado correspondiente a nuestra Entidad Certificadora (CA). En mi servidor Debian, hay que copiar el certificado público (extensión .crt) a /etc/ssl/certs y la clave privada (extensión .key) a /etc/ssl/private.
  • apachessl.crt y apachessl.key: estos dos archivos forman el certificado correspondiente al servidor, firmado por nuestra Entidad Certificadora. Como antes, debemos de copiar el certificado público (extensión .crt) a /etc/ssl/certs y la clave privada (extensión .key) a /etc/ssl/private.

Después tendríamos que configurar el servidor web para que usase esos certificados. En apache (el que yo uso), sería algo similar a esto:

SSLEngine on
SSLCACertificateFile '/etc/ssl/certs/CA_minombre.crt'
SSLCertificateFile '/etc/ssl/certs/apachessl.crt'
SSLCertificateKeyFile '/etc/ssl/private/apachessl.key'
SSLVerifyClient require
SSLVerifyDepth 10
# --- opciones varias (mirar en http://httpd.apache.org/docs/2.2/mod/mod_ssl$
SSLProtocol -all +SSLv3
SSLCipherSuite SSLv3:+HIGH:+MEDIUM

En cada navegador que querais que tenga acceso a vuestro sitio web:

  • Primeramente tendremos que importar el certificado de nuestra Entidad Certificadora. Por ejemplo, para hacerlo en Firefox hay que ir a Herramientas -> Opciones -> Avanzado -> Certificados -> Ver certificados -> Importar y una vez allí importar el archivo CA_nombre.crt que (recuerda) contiene la clave pública de nuestra Entidad Certificadora.
  • Acto seguido, tenemos que importar también el certificado pkcs12 que contiene el certificado de nuestro servidor (en el ejemplo que os he puesto: apachessl_pck12.p12)

Paso 7. Otras operaciones con los certificados generados

Si queremos consultar nuestro certificado, podremos consultarlo con el siguiente comando:

# openssl x509 –subject –issuer –enddate –noout –in /CA/certs/apachessl.crt

O el siguiente:

# openssl x509 –in certs/apachessl.crt –noout -text

Y verificar que el certificado sea válido para autenticación de servidores con el siguiente:

# openssl verify –purpose sslserver –Cafile /CA/certs/CA_nombre.crt /CA/certs/apachessl.crt

Algunos servidores o aplicaciones requieren que el certificado y la clave privada existan en el mismo archivo, esto se puede lograr con el comando:

# cat certs/apachessl.crt private/apachessl.key > private/apache-ssl-cert-key.pem

Entonces se debería restringir el acceso al archivo .pem resultante y borrar apachessl.crt y apachessl.key si no son necesarios.

# chown root.root private/apache-ssl-cert-key.pem
# chmod 0400 private/apache-ssl-cert-key.pem
# rm –f certs/apachessl.crt
# rm –f private/apachessl.key

Si deseamos que un certificado deje de ser válido debemos revocarlo. Esto se puede hacer con el comando:

# openssl ca –config openssl.cnf –revoke certs/apachessl.crt

Hecho lo anterior, ahora debemos generar una nueva CRL (Certificate Revokation List):

# openssl ca –config openssl.cnf –gencrl –out crl/CA_nombre.crl

El certificado de nuestra CA y nuestra lista de revocación (CRL) deben ser distribuidos a aquellos que confíen en nuestra CA para que puedan importarlos en el software cliente (web browser, clientes ftp, clientes de email, etc). Además la CRL debe ser pública. Si queréis mas información sobre el estándar de Infraestructura de Clave Pública, quizás os interese visitar el siguiente enlace: Wikipedia: Infraestructura de clave pública.


En fín, hasta aquí esta pequeña guía que espero os venga bien para, por ejemplo, acceder a vuestras intranets caseras desde cualquier sitio. Las posibilidad son amplias: podeis llevar en un pendrive un Firefox portable con los certificados instalados y ejecutarlo en cualquier PC seguro; podeis instalar en vuestra tablet o móvil android (es lo que yo uso, supongo que en otros sistemas también), los certificados y acceder también desde ellos. Incluso (es lo que yo tengo pensado hacer próximamente), podeis instalar en vuestra intranet algún servidor CalDav y CardDav, para así gestionar vosotros mismos vuestros calendarios y contactos, y compartirlos centralizadamente con los ordenadores de vuestra red local, al igual que con los móviles y las tablets a los que instalemos el certificado.

Si quereis más información, aquí se ha hablado un poco más sobre este tema:

Cifrado de particiones en Linux con LUKS

 Mié, 09/12/2009 - 22:09     Sandor

Desde que me pillé el Dell Mini 10v he estado intentando encontrar un rato para cifrar la partición /home, no vaya a ser que me lo tomen prestado un día y mi información personal acabe en malas manos. He estado investigando un poco y parece que lo que se lleva es hacerlo con LUKS y dm-crypt. En este artículo se explica la manera de hacerlo: Partición cifrada con dm-crypt en Debian. Al parecer, según se puede leer en la página de la Wikipedia referente a LUKS, LUKS pretende convertirse en un formato estándar de cifrado, independiente de la plataforma. Para acceder a particiones LUKS bajo Windows, por ahora nos tendremos que conformar con FreeOTFE.

LUKS (de las siglas en inglés, Linux Unified Key Setup) es una especificación de cifrado de disco creado por Clemens Fruhwirth, originalmente destinado para Linux. Mientras la mayoría del software de cifrado de discos implementan diferentes e incompatibles formatos no documentados, LUKS especifica un formato estándar en disco, independiente de plataforma, para usar en varias herramientas.

Esto no sólo facilita la compatibilidad y la interoperabilidad entre los diferentes programas, sino que también garantiza que todas ellas implementen gestión de contraseñas en un lugar seguro y de manera documentada. La implementación de referencia funciona en Linux y se basa en una versión mejorada de cryptsetup, utilizando dm-crypt como la interfaz de cifrado de disco.

En Microsoft Windows, los discos cifrados con LUKS pueden ser utilizados con FreeOTFE. Ha sido diseñado para ajustarse a la clave de configuración TKS1 de sistema seguro.

 

Apache SSL y acceso por certificado

 Jue, 17/09/2009 - 23:40     Sandor

Por fin, tras tres días volviéndome loco configurando humildepc (el pequeño servidor que tengo en casa), he logrado configurar el servidor web Apache, de manera que sea posible acceder desde el exterior de manera segura, usando SSL y siendo necesaria la instalación previa de un certificado en el navegador cliente. Hay decenas de tutoriales en la red que tratan la configuración SSL de Apache, como la propia documentación de mod_ssl o este artículo de Linux para Todos. Pero de toda la documentación que he ojeado, los dos documentos que más me han ayudado han sido los siguientes:

  • Lo hice y lo entendí: Crear los certificados SSL para nuestro servidor web HTTPS con Apache, OpenSSL y Debian Lenny. Estupenda guia, muy en la línea de su indispensable blog, en la que explica de manera amena (bueno, todo lo ameno que puede ser un tema de estos :-D) los pasos más importantes para tener nuestro servidor https serviendo páginas en un pispás. En particular, explica de una manera muy clara qué pasos tenemos que dar para crear nuestra propia Entidad Certificadora (CA), y firmar con ella nuestros propios certificados digitales. De igual manera, señala donde se ubican y el nombre por defecto de los diferentes archivos que se crean en el proceso, y que eran mi particular talón de aquiles (siempre me terminaba liando con ellos).
  • Shadowsland: Certificados digitales con OpenSSL II. Si bien la guia anterior está genial, siguiendo solamente los pasos indicados en ella he sido incapaz de echar a andar el invento. Tras volverme loco, he llegado a la conclusión de que el error no estaba en la configuración del servidor apache, sino en la instalación de los certificados en los navegadores clientes. La forma que la guia de LHYLE propone a mi la verdad es que no me ha funcionado, ni en Firefox ni el Explorer (ambos en un sistema XP). Por el contrario, siguiendo los pasos de Shadowsland, he creado el certificado en formato pkcs12 y, tras importarlo en los navegadores, todo ha funcionado correctamente. Digamos que era la puntilla que necesitaba para echar todo a andar :)

Si estás interesado en montar un servidor seguro que requiera la instalación de certificados en los navegadores clientes, con estos dos recursos probablemente tengas más que suficiente.

Apache SSL. Quitar peticion de clave en el arranque

 Lun, 22/06/2009 - 10:02     Sandor

¿Cansado de tener que estar siempre tecleando la clave del certificado SSL en cada reinicio de Apache? Una de las maneras de hacerlo la he encontrado en la propia FAQ de apache.org, concretamente en How can I get rid of the pass-phrase dialog at Apache startup time?.

En resumen, se trata de quitar el cifrado a nuestra clave, de manera que Apache al arrancar, pueda hacerlo del tirón. Lo primero es encontrar el fichero de la clave a la que apunta nuestra configuración. Por ejemplo, en mi sistema es el siguiente: SSLCertificateKeyFile /etc/apache2/SSL/server.keycopiamos la clave para tener una copia de ella en caso de necesitarla: cp server.key server.key.orgy ahora quitamos el cifrado a la clave original, de la siguiente manera: openssl rsa -in server.key.org -out server.key

Es importantísimo proteger debidamente el acceso a esta clave, ya que como digo ya no se encuentra cifrada, por lo que un posible atacante podría, en caso de tener acceso a ella, hacerse pasar por nosotros. Para ello, haremos que la clave solo sea accesible para el superusuario: chmod 400 server.key

Ahora, si reiniciamos nuestro servidor Apache, veremos que ya no nos pide la clave y que arranca como de costumbre. Si en algún momento queremos volver al estado anterior, con modificar la configuración para que apunte a server.key.org volveríamos al escenario anterior.

Trabajando cómodamente bajo windows como usuario sin privilegios

 Jue, 30/10/2008 - 13:13     Sandor

Si bien la seguridad no es algo que el típico usuario de windows tenga muy en cuenta, parece que al ser un sistema tan vulnerable sus usuarios vamos tomando conciencia, a fuerza de periódicos 'sustos', acerca de este importante asunto. Uno de los hábitos más aconsejados (y también menos practicados), es el de iniciar el sistema como un usuario normal (con cuenta limitada). Puede ser un incordio, porque hay bastantes programas que necesitan privilegios de administrador, pero para solucionar esto está la utilidad RunAs. Hay una guia estupenda en la página de Fernando Reyes López. Su título lo deja bien claro: Por favor, no inicies sesión como administrador, utiliza RunAs.

Etiquetas: 

Sorpresas te da la vida

 Sáb, 29/12/2007 - 23:56     Sandor

No os lo iba a contar pero, a raíz de leer esta noticia de Engadget, en la que se comenta que la conocida marca de centros comerciales americana Walmart, ha vendido a una niña de 10 años un reproductor digital lleno de porno, me he animado a comentar un reciente caso que me ha pasado. En el caso de la niña de 10 años, al parecer el reproductor que compró fue devuelto a su vez por algún cliente insatisfecho, aunque dejó el porno archivado en él... lamentable el poco control de la empresa en sus productos devueltos.

En lo que a mí respecta, hace un par de semanas compré un disco duro de 500gb en una conocida tienda informática de Deusto. Hace un par de días, al instalarlo en el servidor, comprobé que tenía una partición NTFS creada, por lo que me faltó tiempo para fisgar (uno es como es, qué le vamos a hacer :-D). Yo, la verdad, me esperaba encontrar el típico Windows XP piratilla que le meten ciertas tiendas a los ordenadores que venden, pero cual fue mi sorpresa al comprobar que, además de los archivos propios de Windows, había otros del tipo vacaciones en iparralde.avi y similares. Como supondréis, me faltó tiempo para inspeccionar más a fondo el contenido de la partición. Abreviando, os comentaré que encontré documentos privados de la persona en cuestión (su DNI y el de la mujer escaneados, el Carnet de conducir, su libro de familia, e-mails exportados, la libreta de la BBK... en fin, una pasada).

Luego profundicé un poco más, y pude ver la lista de búsquedas que había realizado en el programa P2P que usaba, algunos logs del messenger archivados y los avatares que usan sus contactos, el software que usaba... qué se yo, un montón de información personal. Y realmente, al finalizar ese análisis superficial del contenido de ese disco duro y darme cuenta de la cantidad de información personal que había sacado de su análisis, me dí cuenta de lo expuestos que estamos ante un robo, o ante el descuido imperdonable del responsable del servicio técnico de una tienda de ordenadores.

Yo desde luego lo tengo claro, no creo que lleve nunca un disco duro a reparar sin antes haberle pasado alguna utilidad de borrado total, del tipo PC INSPECTOR e-maxx, Clean Disk Security o seguir, en linux, algún procedimiento como el que se comenta en esta entrada de miguev.net.

Como colofón, el otro día me volví a pasar por la tienda y comenté lo que me había pasado. La única pregunta de quien me atendió fue si el disco duro me funcionaba. Apenas se inmutó por el hecho de haberme vendido un disco duro ya usado (ni se le ocurrió ofrecerme un cambio por uno nuevo), ni por supuesto cayó en las posibles implicaciones legales que el descuido que habían tenido podría haberles causado si lo hubiera denunciado en la Agencia de Protección de Datos, o el follón que hubiera podido montar el dueño original del disco duro si le hubiera llamado por teléfono (sí, el hombre también tenía un listado, a modo de backup, de los números de teléfonos de sus amistades). Por mi parte, volví a particionar el disco duro (¡¡¡tengo un /home de 500gb!!!) :-) y me olvidé del tema.

Ahora, al escribir esta entrada, pienso que si hubiera sido yo el dueño original del disco duro, me hubiera gustado que se denunciara esta negligencia. En fin, no se, supongo que no siempre uno actúa como debiera....

Asegurando el disco duro USB

 Mié, 06/04/2005 - 14:07     Sandor

Mi disco duro usb

Tengo uno de esos chismes tan de moda últimamente, un pequeño disco duro USB de la marca Trascend y 512 Mb de capacidad. La verdad es que hacía años que no encontraba algo tan útil, y puedo decir que todos los días lo llevo de casa a la oficina y de la oficina a casa. Incluso si alguna vez me voy de viaje, me gusta llevarlo encima ya que en un pequeño chisme de 6x2 cmt. aproximadamente llevo toda la información personal encima, desde los datos bancarios, los gastos de la casa (una hoja de cálculo OpenOffice.org), mi agenda de teléfonos, los datos de mi red casera y la del trabajo (logins, claves, etc) y un montón de pequeños archivos de texto con un montón de información que en ocasiones necesito tener a mano.

Claro, como supondreís, el peligro de llevar encima tanta información personal, más aún en simples archivos de texto, es que si alguna vez lo pierdo o me lo pierden :-) cualquiera tendrá acceso a mis datos personales.

Para evitar esto, he organizado un pequeño sistema de cifrado, válido tanto para sistemas windows como linux, que sin ser una maravilla a lo mejor a algun lector le puede ser de utilidad. La organización que tengo en el disco usb es la siguiente:

\datos
\doswin
   ccrypt.exe
   cifra.bat
   cygwin1.dll
   descifra.bat
\linux
   ccrypt
   cifra.sh
   descifra.sh
\privado
  • En datos guardo aquellos datos que no es necesario cifrar.
  • En doswin estan los binarios de cifrado para windows y algunas utilidades.
  • En linux estan los binarios de cifrado para linux y algunas utilidades.
  • En privado guardo aquellos datos que van a cifrarse.

El programa que utilizo para cifrar los datos es el ccrypt:

@echo off
echo ----------------------------------------------
echo  Script para cifrar toda la informacion
echo  privada de la carpeta PRIVADO
echo ----------------------------------------------
ccrypt.exe -e -q -s -t -r ../privado/*

descifra.bat, pues lo contrario:

@echo off
echo ----------------------------------------------
echo   Script para descifrar toda la informacion
echo   privada de la carpeta PRIVADO
echo ----------------------------------------------
ccrypt.exe -d -q -s -t -r ../privado/*

Y sus correspondientes gemelos en linux: cifra.sh

#!/bin/bash
./ccrypt -e -q -s -t -r ../privado/* 

y descifra.sh:

#!/bin/bash
./ccrypt -q -d -s -t -r ../privado/* 

Con esto tengo al alcance de un click el cifrado de todos mis ficheros con datos personales. Al estar en simples archivos de texto el proceso tarda realmente poco, aunque supongo que si tienes pensado meter archivos grandes en la carpeta Privadopuede ser un poco incordio tener que cifrar/descifrar todo el directorio cada vez que se quiera acceder a un archivo determinado, especialmente si tu sistema solo dispone de USB 1.1. Como ves, el sistema es muy mejorable O:-)

Servicios asegurados

 Lun, 14/03/2005 - 10:09     Sandor

Acabo de cambiar el sistema operativo de mi pequeño servidor humildepc(de Debian a Ubuntu, así que no hay mucho que aprender que digamos). El caso es que quería quitarme de encima un montón de paquetes instalados desde tiempos inmemoriales, un montón de dependencias de vete tú a saber donde (y el deborphanno me soluciona mucho) y dejar un sistema lo más pelado posible, sin perder la comodidad del apt-get install, al que me niego a renunciar :-)

El caso es que después de instalar los 350 megas del sistema mínimo de Ubuntu, el segundo punto en mi plan de acción es reinstalar los servicios que tenía en la anterior configuración (http, imap y smtp los más importantes), pero cambiados por su versión asegurada con ssl. Ayer comencé con Postfix-Tls, Cyrus, Sasl2, OpenSSL ... y tengo la cabeza como un bombo. [Actualización, tres días después] Bueno, parece que he conseguido poner en común postfix-tls con el cyrus-ssl-sasldb, y creo que sólo he perdido un par de años de vida en el intento :-) Hay algunas direcciones que me han venido bien para orientarme un poco:

En fin, por ahora ya tengo suficiente. Lo próximo será el apache (creo que instalaré la versión 2), sobre SSL, que creo que ya le voy pillando el truquillo :-) Ya os iré contando.

Categoria: 

Sobre PlanetaInopia

Sandor Inopia nació en Bilbao, un lunes cualquiera, justo 1904 años después de que Nerón se suicidara, diciendo ¡Qué artista muere conmigo!, y 192 años después de que Volta descubriera la pila eléctrica. Mientras celebraba su quinto cumpleaños, Elvis daba su último concierto, y celebrando los siete, Muhammad Ali se retiraba del boxeo.

Sobre PlanetaInoipa, blog personal de Sandor Inopia (Sandor Saiz Ortuondo)

Yo no tengo la ambición de Nerón, la inteligencia de Volta, la voz de Elvis, o la fuerza de Alí, pero a veces me gusta escribir y darme a conocer a los demás. Por eso este blog, que espero te guste.

Comentarios recientes