miércoles, 28 de noviembre de 2018

Configurar HTTPS en Apache



Cómo configurar Apache para que sirva una página web por HTTPS con un certificado SSL.

HTTP es un protocolo inseguro y está sujeto a ataques man-in-the-middle y eavesdropping que pueden permitir a un atacante obtener acceso a información confidencial enviada de un cliente (PC de un usuario) a un servidor (página web) o viceversa.

HTTPS, por su parte, combina HTTP con el protocolo de seguridad SSL/TLS, creando un canal cifrado que hace que la información que se pueda conseguir si se intercepta una petición sea indescifrable, y por lo tanto, inusable por un atacante.

Si servimos páginas web, lo ideal es servirlas por HTTPS, sea cual sea el software de servidor web que usemos. Si estamos usando Apache, deberemos configurarlo para que sirva contenido por el puerto 443 (HTTPS), ya que por defecto, Apache solo escucha por el puerto 80 (HTTP).

Para servir contenido por HTTPS, primero cargamos el módulo de SSL:

HOST# a2enmod ssl

Para que Apache escuche por el puerto 443, lo configuramos en el siguiente archivo:

/etc/apache2/listen.conf

Añadimos el puerto 443:

Listen 80 Listen 443

Recordar que deberemos dejar pasar el puerto 443 en el firewall de la máquina.

A continuación, creamos un Virtual Host nuevo que escuche por ese puerto. Nos situamos en:

/etc/apache2/vhosts.d/

Y creamos un archivo con extensión .conf y el siguiente contenido:

<VirtualHost _default_:443> DocumentRoot "/srv/www/htdocs" ServerName web.com SSLEngine on SSLCertificateFile /etc/apache2/ssl.crt/archivo.crt SSLCertificateKeyFile /etc/apache2/ssl.key/archivo.key SSLCertificateChainFile /etc/apache2/ssl.crt/gd_bundle-g2-g1.crt </VirtualHost>

Veamos qué significa cada parámetro:

- <VirtualHost _default_:443>: el dominio por defecto responde por el puerto 443 (HTTPS).
- DocumentRoot "/srv/www/htdocs": ruta donde están los archivos que conforman la página web.
- ServerName web.com: dirección de la web.
- SSLEngine on: activamos SSL.
- SSLCertificateFile /etc/apache2/ssl.crt/certificado.crt: clave pública del certificado.
- SSLCertificateKeyFile /etc/apache2/ssl.key/archivo.key: clave privada del certificado.
- SSLCertificateChainFile /etc/apache2/ssl.crt/gd_bundle-g2-g1.crt: certificado intermedio (certificado de la autoridad certificadora).

Los archivos .crt y .key son los que conforman el certificado SSL de la página web y los debemos tener de antemano. Podemos obtener un certificado SSL de esta forma.

Para aplicar la nueva configuración, debemos reiniciar Apache. Antes de hacerlo, podemos verificar que la sintaxis del archivo .conf que acabamos de crear sea correcta con el comando:

HOST# apachectl configtest Syntax OK

Si la sintaxis está OK, podemos reiniciar Apache para aplicar los cambios:

HOST# apachectl restart

A partir de este momento, Apache ya sirve contenido por HTTPS. Podemos verificarlo accediendo a nuestra web por https://. El navegador debería indicarnos que el sitio es seguro.
0

miércoles, 21 de noviembre de 2018

Cómo generar CSR para obtener certificado SSL



Cómo generar un archivo .csr para obtener un archivo .crt (certificado SSL).



Hoy en día es básico que una página web sea accesible por HTTPS de forma segura con un certificado válido. Para que eso sea posible, debemos disponer de un certificado SSL válido y vigente para el dominio de la página web en cuestión.

Para obtener un certificado SSL para un dominio, primero debemos crear un archivo que contenga una "solicitud de firma de certificado". A continuación, debemos enviar este archivo a una empresa que se dedique a expedir certificados SSL para que lo valide y lo devuelva firmado por ellos, en forma de certificado SSL público. A partir de este momento, ya tendremos un certificado SSL válido, firmado por una entidad certificadora, listo para ser usado en nuestro servidor web.

La solicitud de firma de certificado, en inglés Certificate Signing Request, es un código que se guarda en un archivo de extensión .csr. Este archivo, se envía a una entidad certificadora y esta lo usa para generar un archivo .crt, el cual será la parte pública del certificado SSL. En el interior de un CSR quedan registrados datos tales como la empresa que lo pide, la localidad desde donde se pide y el dominio para el que se genera el certificado, entre otros.

Para generar un CSR, la opción más común es usar la utilidad openssl. Las distribuciones Linux lo suelen traer instalado por defecto, mientras que en Windows habrá que instalarlo explícitamente. Podemos obtener la última versión de OpenSSL para Windows desde aquí.

Una vez instalado OpenSSL, nos situamos en un directorio y generamos el CSR:

C:\temp>openssl req -nodes -keyout clave_privada.key -out pedido_certificado.csr -newkey rsa:2048 Generating a 2048 bit RSA private key ..........................................+++ ..........................................+++ writing new private key to 'clave_privada.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]:Barcelona Locality Name (eg, city) []:Barcelona Organization Name (eg, company) [Internet Widgits Pty Ltd]:Empresa Organizational Unit Name (eg, section) []:IT Common Name (e.g. server FQDN or YOUR name) []:dominio.com Email Address []:hola@email.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

Vemos que al generar un CSR se crean dos archivos:

- archivo.csr: el Certificate Signing Request del que ya hemos hablado.
- archivo.key: la clave privada del certificado -> es importante guardarlo bien.

Una vez generados estos dos ficheros, mandamos nuestro archivo CSR a una entidad certificadora (p.e. GoDaddy.com) y pagamos el precio que nos pidan por el certificado SSL. Recordemos que este certificado tiene una vigencia determinada, siendo esta 1 año, 2 años, 3 años o los que queramos pagar.

Una vez realizado el pago, la entidad nos devolverá un archivo con extensión .cer o .crt que ya podremos usar en nuestro servidor web para asegurar las comunicaciones vía HTTPS.
1

miércoles, 14 de noviembre de 2018

Sudo o no sudo, esa es la cuestión



Qué diferencias hay entre ejecutar comandos en Linux como root, ejecutar comandos como usuario común, ejecutar comandos como usuario con sudo o ejecutar comandos con su.



Sudo. Soy humano y los humanos tenemos glándulas sudoríparas en el cuerpo que nos hacen sudar. Esta podría ser una respuesta válida al título de esta entrada, pero no van por ahí los tiros (lo siento, no he podido resistirme a hacer la broma xD).

Con el título de la entrada me refería a la pregunta que todo sysadmin que maneje Linux se ha planteado en algún momento: si es aceptable acceder a un servidor vía SSH como root y trabajar bajo ese usuario o si es mejor acceder con un usuario "limitado" y usar sudo cada vez que queramos ejecutar un comando que requiera permisos de superusuario. Y es que cada vez son más las distribuciones de Linux que, por defecto, no nos permiten conectarnos a una máquina como root.

Veamos algnos ejemplos:

Debian: en Debian, el acceso por SSH al sistema con el usuario root viene deshabilitado por defecto (PermitRootLogin no). Si queremos trabajar como root, tenemos que configurar el acceso de root vía SSH previamente o configurar sudo.

Ubuntu: en Ubuntu, durante la instalación, no se nos pregunta en ningún momento por el password de root, por lo que, directamente, no es posible conectarse a la máquina como root por SSH (es posible si lo configuramos nosotros posteriormente, obviamente).


¿Por qué no es aconsejable usar la cuenta root?



La respuesta a esta pregunta no es otra que el principio de mínimo privilegio, por el cuál cada usuario debería poder acceder solamente a los recursos que necesite. No más.

Me explico.

Si una persona no tiene que reiniciar servicios de un sistema, no tiene por qué acceder a ese sistema con la cuenta root. Si una persona no tiene que instalar paquetes en el sistema, no necesita poder acceder como root. Si una persona sólo va a subir imágenes por SFTP a una carpeta, no necesita la cuenta root, basta con que tenga acceso a la carpeta en cuestión.

¿Y si un usuario necesita poder reiniciar un servicio, por ejemplo nginx, por si el servicio cae?

La respuesta es sencilla: usar sudo.


Beneficios e inconvenientes de sudo



Para empezar, con el uso de sudo podemos especificar qué comandos puede ejecutar un usuario determinado usando privilegios de root, así como impedirle el uso de otros comandos como root. Así, si no queremos que un usuario pueda parar Apache, por poner un ejemplo, podemos impedirle explícitamente que ejecute el comando "sudo service apache2 stop". Y sin privilegios de root, no podrá parar el servicio. Por si esto fuera poco, podemos logear todos los comandos que un usuario realiza como root para ver quién y cuándo, ha hecho qué cambios.

Además, sudo nos puede salvar de catástrofes. Imaginemos que accedemos a un sistema como root y ejecutamos algo como "rm -rf /tmp/*" y por error ponemos un espacio entre / y * o entre / y tmp; el resultado será desastroso. Si ejecutamos la instrucción como usuario normal (no root o sin usar sudo), un mensaje nos dirá que no tenemos permisos para borrarlo todo.

Por otro lado, usar sudo es algo incómodo. Para empezar, debemos escribir "sudo comando" cada vez que queramos ejecutar un comando con privilegios de root, cuando normalmente sólo escribiríamos "comando". Muchas veces nos olvidaremos de escribir sudo y debremos recurrir a "sudo !!" para ejecutar el comando anterior con sudo o deberemos volver a escribir los comandos que queramos ejecutar. Algunas veces no hay problema, repetimos el comando y listo. Otras veces, veremos cosas "raras" en pantalla cuando no usemos sudo.

Con "cosas raras" me refiero a, por ejemplo, el caso siguiente. Queremos ver el estado de Apache:

HOST# service httpd status httpd dead but subsys locked

Ahora bien, si lo ejecutamos con sudo:

HOST# sudo service httpd status httpd (pid 4703) is running...

Esto ocurre porque un usuario sin privilegios no puede monitorizar ciertos servicios, mientras que usando sudo vemos el mismo output que vería root en la terminal.


¿Qué diferencias hay entre sudo y su?



Desde un usuario limitado, podemos usar dos formas para ejecutar comandos con privilegios de root:

sudo comando
su - root -c comando

La diferencia entre ambos es la siguiente:

- sudo nos pedirá el password de la cuenta que estemos usando para ejecutar un comando como root (podemos especificar que no nos pida password, aunque no es aconsejable desde el punto de vista de la seguridad).

- su nos pide el password del usuario "destino" con el que queremos ejecutar el comando. Eso significa que si no conocemos el password de root, no podremos usar "su - root".

Por lo tanto, si acceden varios usuarios a una misma máquina y queremos que usen su, deberemos comunicarles a todos el password de root para que accedan a una shell de root, mientras que usando sudo, los usuarios sólo deben conocer su propio password. Usando sudo, el password de root queda más protegido ante posibles robos de credenciales.


Conclusión



Por todo lo mencionado anteriormente, es desaconsejable usar la cuenta root en un servidor, y entre sudo y su, es claramente más recomendable usar sudo para ejecutar comandos con privilegios de root.


Fuentes:

https://www.howtoforge.com/tutorial/sudo-vs-su/
https://askubuntu.com/questions/16178/why-is-it-bad-to-log-in-as-root
https://security.stackexchange.com/questions/119410/why-should-one-use-sudo
0