# rm-rf.es | Administración de sistemas

Blog de un SysAdmin Unix, Gnu/Linux, Windows y lo que haga falta.

Generar un certificado SSL con genkey (Red Hat Keypair Generation)

Hoy vamos a ver una alternativa a la generación de certificados SSL con OpenSSL. Genkey (Red Hat Keypair Generation) es un comando disponible como parte del paquete crypto-utils:

# yum whatprovides */genkey
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
....
....

crypto-utils-2.4.1-24.2.el6.i686 : SSL certificate and key management utilities
Repo        : base
Matched from:
Filename    : /usr/bin/genkey

Aprovechamos entonces para instalarlo:

# yum install crypto-utils

Echando un vistazo a la ayuda podemos ver las opciones del comando:

# genkey 
Usage: genkey [options] servername
    --test   Test mode, faster seeding, overwrite existing key
    --genreq Generate a Certificate Signing Request (CSR)
    --makeca Generate a self-signed certificate for a CA
    --days   Days until expiry of self-signed certificate (default 30)
    --renew  CSR is for cert renewal, reusing existing key pair, openssl certs only
    --cacert Renewal is for a CA certificate, needed for openssl certs only
    --nss    Use the nss database for keys and certificates
    --gdb    For package maintainers, to trace into the nss utilities

¡Qué motivo podríamos tener para utilizar genkey en lugar de openssl? Corregidme si hay algún otro más, pero en principio lo que yo veo es que no tenemos que acordarnos de los comandos de openssl ya que genkey es un asistente en modo text/gráfico desde línea de comandos que nos guía con todos los pasos.

Si quisieramos generar un certificado self-signed para ssl.rm-rf.es seguiríamos estos pasos:

# genkey ssl.rm-rf.es

Comienza el asistente, que ya nos indica donde van a guardarse los ficheros resultantes (llaves privadas, certificados, certificate requests, CA requests, etc.)

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 1

Indicamos el tamaño de la llave, a mayor tamaño en bits, mayor seguridad, también costará más tiempo generarla:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 2

Esperamos a la generación de los bits aleatorios:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 3

Y la generación de datos aleatorios. Se recomienda mover el ratón o escribir en la consola del servidor/máquina para acelerar el proceso:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 4

Si quisiéramos enviar una petición de CSR a una entidad certificadora autoritativa (CA) este sería el momento:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 5

Para mayor seguridad podemos encriptar la llave privada del certificado. La frase de paso (passphrase) que indiquemos tendrá que ser introducida cada vez que arranquemos el servicio web seguro.

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 6

Por último introducimos los datos de nuestro certificado:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 7

Una vez aceptado podremos ver en la línea de comandos la ejecución del proceso por genkey:

/usr/bin/keyutil -c makecert -g 1024 -s "CN=ssl.rm-rf.es, OU=IT, O=Rm-RF, L=Zaragoza, ST=Zaragoza, C=ES" -v 1 -a -z /etc/pki/tls/.rand.2492 -o /etc/pki/tls/certs/ssl.rm-rf.es.crt -k /etc/pki/tls/private/ssl.rm-rf.es.key
cmdstr: makecert

cmd_CreateNewCert
command:  makecert
keysize = 1024 bits
subject = CN=ssl.rm-rf.es, OU=IT, O=Rm-RF, L=Zaragoza, ST=Zaragoza, C=ES
valid for 1 months
random seed from /etc/pki/tls/.rand.2492
output will be written to /etc/pki/tls/certs/ssl.rm-rf.es.crt
output key written to /etc/pki/tls/private/ssl.rm-rf.es.key

Generating key. This may take a few moments...

Made a key
Opened tmprequest for writing
(null) Copying the cert pointer
Created a certificate
Wrote 882 bytes of encoded data to /etc/pki/tls/private/ssl.rm-rf.es.key 
Wrote the key to:
/etc/pki/tls/private/ssl.rm-rf.es.key

Y nuestra private key y certificado ya están disponibles para su uso.

Comprobar la integridad de las descargas de archivos con md5sum, sha256sum…

Cuando descargamos archivos a través de Internet, por ejemplo ISOs de sistemas operativos, o paquetes RPM, DEB, etc, vienen acompañados de un “código” (hash MD5 del archivo) que sirve para verificar, una vez descargado el archivo, que no ha sido alterado por terceras partes y que podemos confiar en que es lo que realmente buscamos.

Por ejemplo, si accedemos a uno de los mirrors de CentOS vermos que además de las ISOs podemos descargar sus correspondientes checksum MD5, PGP, SHA…(*.asc y *.txt):

0_README.txt 06-Jul-2012 06:01 2.0K
CentOS-6.3-x86_64-LiveCD.iso 07-Jul-2012 13:26 692M
CentOS-6.3-x86_64-LiveCD.torrent 09-Jul-2012 14:03 217K
CentOS-6.3-x86_64-LiveDVD.iso 06-Jul-2012 09:07 1.6G
CentOS-6.3-x86_64-LiveDVD.torrent 09-Jul-2012 13:50 263K
CentOS-6.3-x86_64-bin-DVD1.iso 06-Jul-2012 06:20 4.0G
CentOS-6.3-x86_64-bin-DVD1to2.torrent 09-Jul-2012 14:15 217K
CentOS-6.3-x86_64-bin-DVD2.iso 06-Jul-2012 06:20 1.4G
CentOS-6.3-x86_64-minimal-EFI.iso 21-Aug-2012 14:30 364M
CentOS-6.3-x86_64-minimal.iso 06-Jul-2012 06:23 330M
CentOS-6.3-x86_64-netinstall-EFI.iso 18-Sep-2012 05:39 234M
CentOS-6.3-x86_64-netinstall.iso 06-Jul-2012 06:14 200M
README.txt 06-Jul-2012 06:01 2.0K
md5sum.txt 18-Sep-2012 17:31 734 md5sum.txt.asc 18-Sep-2012 17:31 1.6K
sha1sum.txt 18-Sep-2012 17:31 822
sha1sum.txt.asc 18-Sep-2012 17:31 1.7K
sha256sum.txt 18-Sep-2012 17:31 1.1K
sha256sum.txt.asc 18-Sep-2012 17:31 1.9K

En el caso de los checksum MD5 el fichero tiene el siguiente contenido:

a991defc0a602d04f064c43290df0131  CentOS-6.3-x86_64-bin-DVD1.iso
410c1c5188e6076d62d6107153738a15  CentOS-6.3-x86_64-bin-DVD2.iso
087713752fa88c03a5e8471c661ad1a2  CentOS-6.3-x86_64-minimal.iso
690138908de516b6e5d7d180d085c3f3  CentOS-6.3-x86_64-netinstall.iso
9953ff1cc2ef31da89a0e1f993ee6335  CentOS-6.3-x86_64-LiveCD.iso
0d28b5f9c9f562bd3a17c68ef05b3998  CentOS-6.3-x86_64-LiveDVD.iso
21157a19ec6a32b4fd71f0e45b9aa951  CentOS-6.3-x86_64-bin-DVD1to2.torrent
9015d02b4e22efd547a6bd8b19bce0ec  CentOS-6.3-x86_64-LiveCD.torrent
3b9c1c463cfe8983c0835f46f2db39db  CentOS-6.3-x86_64-LiveDVD.torrent
4dd1ff9a521823e033dde6b152196de7  CentOS-6.3-x86_64-minimal-EFI.iso
c750ba06d83a38494dbf100bf33014d4  CentOS-6.3-x86_64-netinstall-EFI.iso

Cada línea hace referencia al checksum de cada descarga. Una vez descargado, en GNU/Linux debemos comparar ese hash con el del fichero que hemos descargado. Para ello utilizamos el comando “md5sum“:

~$ md5sum CentOS-6.3-x86_64-netinstall.iso
690138908de516b6e5d7d180d085c3f3  CentOS-6.3-x86_64-netinstall.iso

En este caso hemos visto que efectivamente coincide, por lo que es fiable hacer uso del archivo. En el caso de que el hash fuera distinto detectaríamos que el archivo ha sido comprometido y no es fiable su descarga o utilización:

~$ md5sum CentOS-6.3-x86_64-netinstall.iso
d41d8cd98f00b204e9800998ecf8427e  CentOS-6.3-x86_64-netinstall.iso

Podéis hacer lo mismo con los hash sha y los comandos sha1sum, sha256dum, etc:

~$ sha[TAB]
sha1pass sha224sum sha384sum shasum
sha1sum sha256sum sha512sum

! bad user (foo) en los cron jobs de Solaris

Suponiendo que tenemos un usuario en Solaris que debería estar ejecutando los cron jobs establecidos en su crontab pero no está siendo así, lo primero que debemos hacer es revisar los logs de cron para encontrar el origen del problema. Podemos consultarlos en /var/cron/log.

Si lo que vemos es entradas similares a la siguiente en el log…

! bad user (foo) Tue Sep 12 15:30:10 2012

… puede significar que el usuario foo no tiene privilegios para la ejecución de crontabs, habiendo sido denegado a través del fichero /etc/cron.deny (ver “Cron linux: autorizar o denegar su uso a usuarios“):

foo:~$ crontab -l foo
You (foo) are not allowed to use this program (crontab)
See crontab(1) for more information

Pero también es muy probable que el usuario se encuentre bloqueado a nivel de sistema operativo, ya sea porque su password ha expirado, bloqueo de cuenta por excesivos logins incorrectos, etc. Puede haber muchas causas. En este caso veremos que la cuenta está marcada como el prefijo \*LK\* en el password (locked) de su entrada en el fichero /etc/shadow:

foo:\*LK\*asd73jasd80kj:::::::

También podríamos averiguarlo sin mirar el fichero shadow, con el comando passwd -s:

# passwd -s foo
foo    LK

Para desbloquearla utilizamos el parámetro -u (unlock) de passwd:

# passwd -u foo
passwd: password information changed for foo
# passwd -s foo
foo       PS

Y ya podemos ejecutar crons. El prefijo LK ha desaparecido del fichero /etc/shadow:

foo:asd73jasd80kj:::::::

AIDE (Advanced Intrusion Detection Environment)

AIDE (Advanced Intrusion Detection Environment) es, como su nombre indica un sistema avanzado de detección de intrusiones a nivel de sistema operativo. Es muy sencillo de instalar y con una configuración estándar puede funcionar realmente bien.

El funcionamiento consiste en que se crea una base de datos basada en la configuración especificada en el fichero de configuración, una vez inicializada permite ser utilizada para verificar la integridad de los ficheros del sistema y muchas otras cosas como atributos de ficheros (tipo de fichero, permisos, nº de inodo, uid, gid, tamaño, bloques, mtime, ctime, atime…), Posix ACL, SELinux, XAttrs

AIDE se ofrece precompilado en paquete para la mayoría de distribuciones por lo que la instalación es sencilla:

Debian, Ubuntu, etc:

# apt-get install aide
# aptitude install aide

FreeBSD:

# pkg_add -r aide

Red Hat, CentOS, Fedora, Scientific Linux:

#  yum install aide

Una vez instalado debemos familiarizarnos con el fichero de configuración, en el caso de Red Hat se encuentra en /etc/aide.conf, probablemente será igual en el resto de distribuciones. También podemos revisar la página man (man /etc/aide.conf) para tener más idea de todas las posibilidades y personalización.

Como os decía, la instalación base nos permite funcionar sin problemas, lo primer que hay que hacer es generar una nueva base de datos, por defecto es un fichero comprimido pero veréis en el fichero de configuración que hay más opciones:

# /usr/sbin/aide --init

Una vez terminado tendremos la nueva base de datos en /var/lib/aide/aide.db.new.gz, para evitar sobreescribir la de producción se almacena ahí, luego la copiamos o movemos a la definitiva:

# cp -p /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

En la configuración se define así:

# The location of the database to be read.
database=file:@@{DBDIR}/aide.db.gz

# The location of the database to be written.
database_out=file:@@{DBDIR}/aide.db.new.gz

Una vez generada la base de datos ya podemos ejecutar un chequeo del sistema, no debería haber ningún problema ya que acabamos de generar la base de datos y es muy difícil tener algo distinto en pocos segundos:

# /usr/sbin/aide --check

El resultado que todos esperamos es el siguiente, todo correcto:

AIDE, version 0.14

### All files match AIDE database. Looks okay!

Este mismo chequeo es el que podríamos configurar periódicamente vía cron:

# crontab -e -u root
0 5 * * * /usr/sbin/aide --check

En el momento que se generara un problema veríamos en el informe algo así (también se guarda en /var/log/aide/aide.log). Por ejemplo he modificado el fichero /etc/passwd para que saltara en el escaneo:

AIDE found differences between database and filesystem!!
Start timestamp: 2012-08-10 09:58:03

Summary:
  Total number of files:	31858
  Added files:			0
  Removed files:		0
  Changed files:		1

---------------------------------------------------
Changed files:
---------------------------------------------------

changed: /etc/passwd

--------------------------------------------------
Detailed information about changes:
---------------------------------------------------

File: /etc/passwd
  Mtime    : 2012-08-06 12:11:53              , 2012-08-10 09:58:01
  Ctime    : 2012-08-06 12:11:53              , 2012-08-10 09:58:01
  Inode    : 22457                            , 22487

Hay que tener en cuenta que cuando tenemos un problema como este, mientras no actualicemos la base de datos de aide seguirá “cantando“. Una vez solucionado o revisado hay que generar un nuevo “snapshot” del estado del sistema para empezar de 0:

# /usr/sbin/aide --update

Os recomiendo revisar el manual si os resulta interesante para estar al tanto de todo lo que pasa en vuestros sistemas.

Nmap Online para tu IP o Clase C

Nmap Online nos permite utilizar Nmap directamente desde el navegador para poder analizar los puertos abiertos de nuestro equipo y toda la información que sabéis que puede ofrecer Nmap. Eso sí, la limitación es que podemos lanzarlo únicamente contra nuestra IP pública de salida y toda su clase C (/24) correspondiente.

Básicamente, la idea es utilizarlo como herramienta durante la securización de nuestro sistema cuando no tenemos la posibilidad de utilizar una máquina remota para lanzar pruebas de seguridad de red y escaneos de puertos, algo necesario cuando estamos realizando configuraciones en nuestro firewall. No voy a entrar en posibles usos maliciosos que se le puedan dar a la herramienta. Es recomendable leer los TOS para tener claro que y que no se puede hacer, lo que se guardan en los registros de ese servidor, el tiempo que permanecen ahí esos datos, si son públicos, etc.

Como veis en la imagen, podemos realizar un escaneo rápido, completo o personalizado, especificando los parámetros de Nmap igual que lo haríamos en la línea de comandos.

Nmap Online

Vulnerabilidad crítica en instalaciones de PHP basadas en CGI

Todas las instalaciones de PHP en modo CGI están afectadas, al parecer se trata de una vulnerabilidad de la cual nadie se había dado cuenta en nada menos que ocho años.

Básicamente, la vulnerabilidad consiste en que en este tipo de instalaciones (sólo CGI, FastCGI o DSO no se ven afectadas), si la petición/request contiene ?-s permite volcar por pantalla el código fuente PHP en lugar de interpretarlo.

Para verificar si la vulnerabilidad nos afecta, sólo es necesario añadir ?-s a la URL y ver si descargamos el código fuente, ejemplo:

dominio.com/test.php?-s

Por suerte, ya podemos descargar las versiones parcheadas desde el sitio web de PHP, concretamente la PHP 5.3.12 o PHP 5.4.2. Si no queremos o podemos actualizar tan sencillamente, podemos aplicar un workaround mediante el cual configuramos unos rewrite, ya sea en el virtualhost o a nivel de .htaccess para bloquear este tipo de peticiones. Para Apache con mod_rewrite:

         RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
         RewriteRule ^(.*) $1? [L]

Más información en www.php.net

Consultar y exportar certificados SSL en Sun Web Server (certutil y pkcs12)

Sun Web Server (en este artículo trabajamos sobre la versión 6.1) almacena los certificados y llaves privadas en ficheros .db (cert8.db y key3.db). Vamos a hacer uso de los comandos certutil y pkcs12 para poder hacer operaciones de listado y exportación de certificados (con o sin private key).

Para listar los certificados que tiene instalados el servidor web debemos usar el comando certutil, que se encuentra en la ruta /bin/https/admin/bin/. Los ficheros .db que comentaba antes se encuentran en la carpeta “alias” por defecto. Podéis copiarlos a una ruta temporal para trabajar con ellos en lugar de directamente en la ruta de producción. Una vez realizado, nos colocamos en esa carpeta y ejecutamos el siguiente comando:

$ certutil -L -d .

    CERTIFICADO-WEB                                                CTu,u,u

Como podéis comprobar, en este servidor web tenemos instalado el certificado CERTIFICADO-WEB. Si queremos exportarlo en formato ASCII sin su private key podemos usar el mismo comando pero especificado el certificado y el parámetro -a (ASCII). En formato binario usamos el parámetro -d (DER):

$ certutil -L -d . -n "CERTIFICADO-WEB" -a
    -----BEGIN CERTIFICATE-----
    MIICTjCCAbAxasdhljkads8akjasdolasdYjEfMB0GA1UEChMWU3Vu
    ...
    ...
    asd3asd23sadasdadsasdasd
    -----END CERTIFICATE-----
$ certutil -L -d . -n "CERTIFICADO-WEB" -d

Finalmente, si lo queremos exportar en formato legible:

$ certutil -L -d . -n "CERTIFICADO-WEB"
     Certificate:
         Data:
             Version: 3 (0x2)
             Serial Number: ...
             Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
             Issuer:
...
...

En caso de necesitar exportar también la private key del certificado, hacemos uso del comando pkcs12. En este caso necesitaremos la password del “NSS Certificate DB” para poder acceder a los certificados del servidor así como especificar una nueva para el fichero resultante PKCS12. Seguimos ubicados en la carpeta donde están los ficheros *.db. Especificamos el fichero de salida (certificado.p12, y el nombre del certificado.

$ pk12util -o certificado.p12 -n 'CERTIFICADO-WEB' -d .
Enter Password or Pin for "NSS Certificate DB":
Enter password for PKCS12 file:
Re-enter password:
pk12util: PKCS12 EXPORT SUCCESSFUL

Cómo limitar el acceso root de forma local y por tty

Pueden existir circunstancias en las que queramos, además de lo típico que es desactivar el acceso root por ssh, desactivar el acceso local para el usuario root.

Para ello tenemos el fichero /etc/securetty, en el cual aparece un listado de las consolas virtuales disponibles en el sistema (tty). Aparecerán todas las que puedan ser utilizadas, pero no tienen porque estar activas. En sistemas RedHat y derivados se especifican en /etc/init/start-ttys.conf.

Bien, para desactivar entonces el acceso root a cualquiera de esas tty, o a todas, únicamente hay que eliminarla o comentarla en ese fichero. A partir del momento que guardemos los cambios “root” ya no podrá acceder por los accesos locales/ttys desactivadas:

# cat /etc/securetty 
console
vc/1
vc/2
vc/3
...
vc/9
vc/10
vc/11
#tty1
#tty2
#tty3
#tty4
#tty5
#tty6
#tty7
#tty8
#tty9
#tty10
#tty11

Si necesitamos mayor detalle en las restricciones, o hacer lo mismo con otros usuarios, debemos revisar el fichero /etc/security/access.conf. Veréis que está perfectamente documentado y que podemos realizar configuraciones como las siguientes:

# Disallow non-root logins on tty1
#
#-:ALL EXCEPT root:tty1
#
# Disallow console logins to all but a few accounts.
#
#-:ALL EXCEPT wheel shutdown sync:LOCAL
#
# Same, but make sure that really the group wheel and not the user
# wheel is used (use nodefgroup argument, too):
#
#-:ALL EXCEPT (wheel) shutdown sync:LOCAL
#
# Disallow non-local logins to privileged accounts (group wheel).
#
#-:wheel:ALL EXCEPT LOCAL .win.tue.nl
#
# Some accounts are not allowed to login from anywhere:
#
#-:wsbscaro wsbsecr wsbspac wsbsym wscosor wstaiwde:ALL
#
# All other accounts are allowed to login from anywhere.
...
...
...