Compartir recursos con Samba sin usuario y sin password entre Linux y Windows

Para poder compartir recursos Samba desde Linux a Windows sin usar ningún login usuario/password de modo que sea un acceso invitado, debemos configurar una serie de directivas en el fichero de configuración de Samba.

Instalación de Samba (en el caso de distribuciones basadas en Debian).

sudo apt install samba samba-client smbfs

Creamos la carpeta que vamos a compartir. Un usuario externo que tiene acceso al equipo a través de Samba, el sistema le da como nombre de usuario nobody y como nombre de grupo nogroup, por lo que hacemos propietarios de esta carpeta a los usuarios externos.

sudo mkdir /mnt/publica
sudo chmod 777 /mnt/publica
sudo chown nobody:nogroup /mnt/publica

Editamos el fichero de configuración de Samba.

/etc/samba/smb.conf

Añadimos o modificamos las siguientes directivas. Workgroup será el nombre del grupo de trabajo (en caso de no formar parte de un entorno de dominio) y permitimos el acceso a invitados.

[global]
   workgroup = WORKGROUP
   usershare allow guests = yes

Establecemos el recurso compartido.

[NombreRecursoCompartido]
   comment = Mi recurso compartido
   path = /mnt/publica
   browseable = Yes
   writeable = Yes
   public = yes

security = SHARE

• browseable: Atravesar y navegar entre las subcarpetas del recurso compartido.
• writeable: Escribir en el recurso compartido.
• public: el sinónimo de "guest ok", permite el ver y acceder al recurso comapartido de manera pública.
• security: Por defecto suele estar comentado como ";   security = user", permite que se pueda acceder sin establecer ningún nombre de usuario.

La directiva "security" es la que realmente permita un acceso tipo invitado desde cualquier otro sistema que no sea Linux ya se Windows o MacOS.

Debe colocarse sin espacios y al final del fichero de configuración smb.conf, un salto de línea después del último recurso compartido.

Reiniciamos el servidor Samba para aplicar los cambios.

sudo systemctl restart samba

Hago referencia a uno de mis repositorios sobre un caso práctico de este ejemplo.

• https://github.com/adrianlois/rpi-proftpd-samba-apache2-nginx/tree/master/samba

Riesgo de seguridad

No se recomienda habilitar la directiva "usershare allow guests" por motivos de seguridad, la configuración por defecto estará deshabilitada con valor "No". 

• https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

Saludos!

Renovar certificados SSL: Comprabar si el certificado, clave privada y el CSR coinciden (OpenSSL)

Al renovar los certificados de un servidor web podemos encontrarnos con errores en el momento de sustitución de los ficheros de certificados.

Apache + configuración SSLCipher strong

# SSLCiphers strong encryption
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

# SSL certs config
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/web/public.crt
SSLCertificateKeyFile /etc/apache2/ssl/web/private.key
SSLCertificateChainFile /etc/apache2/ssl/web/intermediate.crt

Nginx + configuración SSLCipher strong

ssl on;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

# Fix 'The Logjam Attack'.

ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5;

ssl_prefer_server_ciphers on;

ssl_dhparam /etc/ssl/dh2048_param.pem;

#SSL certs config

ssl_certificate /etc/nginx/ssl/web/intermediate.crt;

ssl_certificate_key /etc/nginx/ssl/web/private.key;

 

CA Bundle

Si disponemos de un fichero CA Bundle no es otra cosa que un certificado intermediate y raíz de la CA en un solo archivo, uno detrás del otro, debes combinarlos en uno solo para tener un CA_bundle completo. Los certificados raíz no son necesarios cuando se instala el certificado, para la instalación es suficiente activar en el servidor el correspondiente certificado intermediate.

El orden de los certificados es partir del dominio y hacia la raíz. Intermedio cert1, intermedio cert2 por encima y así sucesivamente.

La cadena es necesaria para mejorar la compatibilidad de los certificados con los navegadores web y otro tipo de clientes para que los navegadores reconozcan su certificado y no aparezcan advertencias de seguridad.

Comprobar la integridad

Para Comprobar la integridad de los ficheros de certificados, debemos revisar que la suma de verificación (checksum) es la misma para el certificado, la clave privada y el CSR (Certificate Signing Request). Los tres deben coincidir para ser válidos entre sí.

Si se obtiene un valor MD5 o SHA256 diferente, significa que el certificado, la clave privada y el CSR no coinciden. De ser así podría ser que el certificado no se hubiese creado con el mismo CSR o el CSR se ha creado con otra clave privada. Para comprobar estos valores podemos hacerlo mediante modulus usando OpenSSL.

Usando OpenSSL: MD5 y sha256sum

Certificado, clave privada, CSR: 

# openssl x509 -noout -modulus -in public.crt | md5
# openssl rsa -noout -modulus -in private.key | md5
# openssl req -noout -modulus -in intermediate.csr | md5

# openssl x509 -noout -modulus -in public.crt | sha256sum
# openssl rsa -noout -modulus -in private.key | sha256sum
# openssl req -noout -modulus -in intermediate.csr | sha256sum

Saludos!