Blog elhacker.NET: Cabeceras de Seguridad HTTPS en el servidor web Nginx y Apache

Cabeceras de Seguridad HTTPS en el servidor web Nginx y Apache

miércoles, 30 de marzo de 2016 | Publicado por el-brujo | Editar entrada

Las cabeceras de seguridad que se configuran a nivel del servidor, lo que nos dará una capa extra de seguridad en nuestra sitio web, evitando ataques del estilo clickjacking, XSS, CSRF, Inyección de código, etc .Para dotar de una capa de cifrado a las comunicaciones electrónicas que utilizan típicamente el protocolo HTTP, los dos protocolos más utilizados son SSL (Secure Sockets Layer) y TLS (Transport Layer Security). Ambos, son protocolos criptográficos que utilizan criptografía de clave pública (o asimétrica) para autenticar a una de las partes (obligatoriamente al servidor) o ambas, siendo opcional la autenticación del cliente.

Otro concepto importante dentro de la criptografía es que un algoritmo se considera seguro, si el tiempo y el esfuerzo necesarios para romperlo y descifrar el contenido sin el conocimiento de la clave, es mayor que el valor del contenido de los datos en sí.

Por esto, cada implementación de SSL/TLS, va mejorando de una versión a otra, soportando cada vez algoritmos considerados más seguros, ya sea por mayor longitud de clave, como por la complejidad criptográfica del algoritmo en sí.

Cabeceras de Seguridad (HTTP Headers)

Las Cabeceras HTTPS son parámetros que se envían en una petición o respuesta HTTPS entre el cliente y el servidor para proporcionar información esencial sobre la transacción que se esté llevando a cabo.

Content-Security-Policy (CSP): allows the website to define a policy concerning which domains external javascripts, css, images, etc, can be imported and rendered from. Prevents XSS and other cross-site injections.
X-Content-Type-Options: prevents IE and Google Chrome from MIME-sniffing a response away from the declared content-type.
X-Frame-Options: protects against clickjacking attacks.
X-XSS-Protection: essentially useless; it comes enabled by default in modern browsers.
Strict-Transport-Security (HSTS): tells your browser to always connect to a particular domain over HTTPS. Attackers aren’t able to downgrade connections, and users can’t ignore TLS warnings.
Feature Policy
Public-Key-Pins (HPKP): tells your browser to associate a specific public key fingerprint with a particular domain. Prevents against an attacker getting a valid certificate from one of the hundreds of other Certificate Authorities out there.

Existen varias maneras de establecer las cabeceras de seguridad en nuestro sitio web:

Cabeceras que envía servidor web (apache, nginx)
Código fuente HTML, añadiendo código tag
Mediante PHP (con header, init_set o define)

Para apache hay tres opciones (maneras) de añadir cabeceras (add,set,append)

Header always add
Header always set
Header always append

add
The response header is added to the existing set of headers, even if this header already exists. This can result in two (or more) headers having the same name. This can lead to unforeseen consequences, and in general set, append or merge should be used instead.

append
The response header is appended to any existing header of the same name. When a new value is merged onto an existing header it is separated from the existing header with a comma. This is the HTTP standard way of giving a header multiple values.

set
The response header is set, replacing any previous header with this name. The value may be a format string.

Herramienta configuración SSL/TLS para administradores de sitios webs:

https://ssl-config.mozilla.org

Opciones Básicas de seguridad según Observatorio de Mozilla:

Cookies (Secure, HttpOnly, and SameSite)
Content Security Policy (no 'unsafe' declarations)
HTTP Strict Transport Security (being preloaded)
Subresource Integrity
X-Frame-Options (done via Content Security Policy)

CSP (Content Security Policies)

CSP tiene dos modos de funcionamiento diferentes: hacer cumplir y de informes. Si utiliza la cabecera Content-Security-Policy header, CSP operará en modo de aplicación; si utiliza Content-Security-Policy-Report-Only de sólo funcionará en el modo de informe

CSP es bastante complejo, y recomiendo que le informe en el modo en primer lugar, ya que permitirá a entender los cambios que necesita hacer para permitir la aplicación más adelante. También debe leer sobre las diferentes directivas de política CSP.

Con la ayuda de la consola de desarrollador de Chrome, fija el color rojo-advertencias uno por uno, lo que resulta en esta política final:

add_header Content-Security-Policy "default-src 'self'; 
script-src 'self' 'unsafe-eval' https://ssl.google-analytics.com https://ajax.cloudflare.com; 
img-src 'self' https://ssl.google-analytics.com ; 
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; 
font-src 'self' https://fonts.googleapis.com https://fonts.gstatic.com; 
object-src 'none'";

Para obtener una puntuación de A+ en Security Headers:

add_header Strict-Transport-Security max-age=0;
add_header X-Frame-Options "ANYTHINGREALLY";
add_header X-Content-Type-Options anythingreally;
add_header X-XSS-Protection "0";
add_header Content-Security-Policy "default-src *";
add_header Public-Key-Pins max-age=0;

Son los headers que se usan para configurar de forma completa cómo debe ser la ejecución de los contenidos de una web. Desde carga de contenido script, plugins o servidores a utilizar.

La cabecera HTTP Content-Security-Policy en la respuesta permite a los administradores de un sitio web controlar los recursos que el User-Agent puede cargar a una pagina. Con algunas (Poquísimas) excepciones, las políticas implican principalmente especificar el servidor de origen la protección de puntos finales del script. Esto ayuda a protegerse contra ataques Cross-site scripting (XSS).

Política de Seguridad del Contenido o ( CSP ) - del inglés Content Security Policy - es una capa de seguridad adicional que ayuda a prevenir y mitigar algunos tipos de ataque, incluyendo Cross Site Scripting ( XSS ) y ataques de inyección de datos. Estos ataques son usados con diversos propósitos, desde robar información hasta desfiguración de sitios o distribución de malware .

default-src: Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback)
script-src: Define which scripts the protected resource can execute, object-src: Define from where the protected resource can load plugins
style-src: Define which styles (CSS) the user applies to the protected resource
img-src: Define from where the protected resource can load images
media-src: Define from where the protected resource can load video and audio
frame-src: Define from where the protected resource can embed frames, font-src: Define from where the protected resource can load fonts
connect-src: Define which URIs the protected resource can load using script interfaces
form-action: Define which URIs can be used as the action of HTML form elements
sandbox: Specifies an HTML sandbox policy that the user agent applies to the protected resource
script-nonce: Define script execution by requiring the presence of the specified nonce on script elements
plugin-types: Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded
reflected-xss: Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header
report-uri: Specifies a URI to which the user agent sends reports about policy violation

Para habilitar CSP, necesitas configurar tu servidor web para que devuelva la cabecera HTTP Content-Security-Policy (en ocasiones verás menciones de la cabecera X-Content-Security-Policy, pero se trata de una versión antigua y no necesitas especificarla más). Alternativamente, el elemento "meta" puede ser usado para configurar una política, por ejemplo:

Ejemplos:

meta http-equiv="Content-Security-Policy" content="default-src https:"

meta http-equiv="Content-Security-Policy" content=Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'

meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

HTTP Referrer

HTTP Referrer que se envía desde los navegadores que cada vez que se hace clic en un hipervínculo de un documento HTML. Tiene una fuerte implicación en la seguridad, y alguien podría plantear un ataque de CSRF (Cross-Site Request Forgery), XSPA (Cross-Site Port Attack), o simplemente de phishing, a través de las direcciones URL que quedaran filtradas en las cabeceras HTTP Referrer que envían los navegadores de Internet.

Referrer-Policy para evitar ataques CSRF

Tipos:

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

Opciones (Directivas)

no-referrer: La cabecera Referer se omitirá en su totalidad. No se enviará ningún dato de referente junto con las solicitudes.
no-referrer-when-downgrade (predeterminado): Este es el comportamiento predeterminado del agente de usuario si no se especifica ninguna directiva. El origen se enviará como referente cuando el nivel de seguridad del protocolo permanece igual (HTTPS → HTTPS), pero no se enviará a destinos menos seguros (HTTPS → HTTP).
origin: Se enviará únicamente el origen del documento como referente en todos los casos. El documento https://ejemplo.com/pagina.html enviará el referente https://ejemplo.com/.
origin-when-cross-origin: Se enviará un URL completo al realizarse una solicitud de origen equivalente, pero únicamente el origen para otros casos.
same-origin: Se enviará un referente para orígenes de sitio equivalente, pero las solicitudes de origen transversal no contendrán ningún dato de referente.
strict-origin: Solo se enviará el origen del documento como referente a destinos que a priori son igual de seguros (HTTPS → HTTPS), pero no lo recibirán destinos menos seguros (HTTPS → HTTP).
strict-origin-when-cross-origin: Se enviará un URL completo al realizarse una solicitud de origen equivalente, se enviará únicamente el origen del documento a destinos igual de seguros a priori (HTTPS → HTTPS) y no se enviará ninguna cabecera a destinos menos seguros (HTTPS → HTTP).
unsafe-URL: Se enviará un URL completo al realizarse una solicitud de origen equivalente o de origen transversal.

La primera forma de configurar el comportamiento del navegador con los campos Referrer es a nivel de documento HTML con el uso de una META Tag llamada Referrer donde se establece una política para todos los hipervínculos que se generen - tanto de forma estática como de forma dinámica - desde esa URL.

Ejemplo:

meta name=”referrer” content=”origin”

O en el servidor web apache

Header always set Referrer-Policy "origin"

O se puede utilizar un HTTP Header llamado Referrer-Policy a nivel de servidor web:

https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-header

X-Frame-Options

Con X-Frame-Options evitamos que nuestra web sea cargada como un iframe en otra web. Esto nos ayuda a protegernos frente a ataques de tipo Clickjacking. Estos son los tres posibles ejemplos de uso:

X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://elhacker.net/

Ejemplo Servidor web Apache

Header always append X-Frame-Options: "DENY"

O con "sameorigin"

Header always set X-Frame-Options "SAMEORIGIN"

Código en scripts PHP

header("X-FRAME-OPTIONS: DENY");

O en servidor web nginx

add_header X-Frame-Options “DENY”;

add_header X-Frame-Options SAMEORIGIN always;

Recuerda que en éste caso no puedes hacer uso de la etiqueta meta, será ignorada, no funcionará:

<meta http-equiv="X-Frame-Options" content="deny">

Más ejemplos:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

X-XSS-Protection

X-XSS-Protection nos ayuda en la defensa frente a ataques de tipo Cross-Site Scripting (XSS). Con esta le decimos al navegador como actuar si durante la carga de la web se detecta un ataque de tipo XSS reflejado.

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report= (Solo Chromium)

X-Content-Type-Options

Para evitar ataques basados en la confusión del tipo de MIME podemos utilizar la cabecera X-Content-Type-Options. Si el navegador recibe esta cabecera no intentará interpretar el tipo de MIME en ningún caso y utilizará el indicado en el Content-Type. La cabecera solo puede configurarse de la siguiente manera:

X-Content-Type-Options: nosniff

Apache

Header set X-Content-Type-Options nosniff

Nginx

add_header X-Content-Type-Options nosniff;

X-Permitted-Cross-Domain-Policies

¿Utiliza productos de Adobe como PDF, Flash, etc.?

Puede implementar este encabezado para indicarle al navegador cómo manejar las solicitudes en un dominio cruzado. Al implementar este encabezado, restringe la carga de los activos de su sitio desde otros dominios para evitar el abuso de recursos.

Hay algunas opciones disponibles.

none -> no policy is allowed
master-only -> allow only the master policy
all -> everything is allowed
by-content-only -> Allow only a certain type of content. Example – XML
by-ftp-only -> applicable only for an FTP server

Apache

Header set X-Permitted-Cross-Domain-Policies "none"

Nginx

add_header X-Permitted-Cross-Domain-Policies master-only;

Expect-CT

Un nuevo encabezado aún en estado experimental es indicar al navegador que valide la conexión con los servidores web para la transparencia del certificado (CT). Este proyecto de Google tiene como objetivo corregir algunas de las fallas en el sistema de certificados SSL / TLS.

Las siguientes tres variables están disponibles para el encabezado Expect-CT.

max-age -> En segundos, durante cuánto tiempo el navegador debe almacenar en caché la política.
enforce -> Una directiva opcional para hacer cumplir la política.
Report-uri - > Browser para enviar un informe a la URL especificada cuando no se recibe una transparencia de certificado válida.

Apache

Header set Expect-CT 'enforce, max-age=43200, report-uri="https://elhacker.net/report"'

Nginx

add_header Expect-CT 'max-age=60, report-uri="https://elhacker.net/report"';

Feature Policy

El encabezado Feature-Policy le dice a los navegadores modernos qué características del navegador están permitidas. Por ejemplo, si desea asegurarse de que solo se permitan las funciones de geolocalización y vibración, puede configurar el encabezado Feature-Policy en consecuencia. También le permite controlar el origen de cada característica especificada. Aquí hay un ejemplo que muestra cómo agregar un encabezado Feature-Policy a través de Apache.

Permite a los propietarios de sitios habilitar y deshabilitar ciertas funciones de la plataforma web en sus propias páginas y en las que incorporan. Poder restringir las funciones que su sitio puede usar es realmente útil, pero poder restringir las funciones que los sitios que insertas puede ser una protección aún mejor.

Directivas

accelerometer
autoplay
battery
geolocation
midi
notifications
push
sync-xhr
microphone
camera
magnetometer
gyroscope
speaker
vibrate
fullscreen
payment (PaymentRequest)

Acciones

*
'self'
'none'
'src'
origin(s)

Header set Feature-Policy "geolocation 'self'; vibrate 'none'"

Más información

Cross-Origin Opener Policy (COOP)

Cross-Origin Opener Policy (COOP)

COOP está disponible en Chrome 83 y Firefox 79.

Directivas

unsafe-none (por defecto)
same-origin-allow-popups
same-origin

Cross-Origin-Opener-Policy: same-origin

COEP: Cross Origin Embedder Policy

Cross-Origin-Embedder-Policy: require-corp

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) es un encabezado HTTP que notifica a los agentes del usuario que solo se conecten a un sitio determinado a través de HTTPS, incluso si el esquema elegido fue HTTP. Los navegadores que han configurado HSTS para un sitio determinado actualizarán de manera transparente todas las solicitudes a HTTPS. HSTS también le dice al navegador que trate los TLS y los errores relacionados con el certificado de manera más estricta al deshabilitar la capacidad de los usuarios de omitir la página de error.

Directivas

max-age
includeSubDomains
preload

Ejemplos:

# Only connect to this site via HTTPS for the two years (recommended)
Strict-Transport-Security: max-age=63072000

Testing SSL/TLS with SSL Breacher

HeartBleed
ChangeCipherSpec Injection
BREACH
BEAST
Forward Secrecy support
RC4 support
CRIME & TIME (If CRIME is detected, TIME will also be reported)
Lucky13
HSTS: Check for implementation of HSTS header
HSTS: Reasonable duration of MAX-AGE
HSTS: Check for SubDomains support
Certificate expiration
Insufficient public key-length
Host-name mismatch
Weak/Insecure Hashing Algorithm (MD2, MD4, MD5, SHA1)
SSLv2 support
Weak ciphers check (Low, Anon, Null, Export)
Null Prefix in certificate
HTTPS Stripping
Surf Jacking
Non-SSL elements/contents embedded in SSL page
Cache-Control

Requerimientos SSL Labs (2014):

Support for TLS 1.2 is now required to get an A. If this protocol version is not supported, the grade is capped at B. Given that, according to SSL Pulse, TLS 1.2 is supported by only about 20% servers, we expect this change to affect a large number of assessments.
Keys below 2048 bits are now considered weak, with the grade capped at B.
Keys below 1024 bits are now considered insecure, and given an F.
MD5 certificate signatures are now considered insecure, and given an F.
We introduce two new grades, A+ and A-, to allow for finer grading. This change allows us to reduce the grade slightly, when we don’t want to reduce it to a B, but we still want to show a difference. More interestingly, we can now reward exceptional configurations.
We also introduce a concept of warnings; a server with good configuration, but with one ore more warnings, is given a reduced grade A-.
Servers that do not support Forward Secrecy with our reference browsers are given a warning.
Servers that do not support secure renegotiation are given a warning.
Servers that use RC4 with TLS 1.1 or TLS 1.2 protocols are given a warning. This approach allows those who are still concerned about BEAST to use RC4 with TLS 1.0 and earlier protocols (supported by older clients), but we want them to use better ciphers with protocols that are not vulnerable to BEAST. Almost all modern clients now support TLS 1.2.
Servers with good configuration, no warnings, and good support for HTTP Strict Transport Security (long max-age is required), are given an A+.

Configuración en Nginx

Ten en cuenta que no debes copiar-pegar las directivas de seguridad directamente en tu fichero de configuración sin antes entender lo que realmente estás haciendo o añadiendo. Debes antes consultar la documentación oficial para ver la compatibilidad con tu versión o las posibles notas de funcionamiento.

Directivas para añadir en el fichero de configuración de Nginx

Configuración SSL

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 
EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

o bien:

ssl_prefer_server_ciphers On;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3
DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5;

Añadir directiva cabeceras:

add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header Content-Security-Policy "default-src 'self';";

HSTS (HTTP Strict Transport Security (HSTS))

3 meses edad

add_header Strict-Transport-Security max-age=7776000;

En configuración Apache httpd.conf para conseguir un A+ en SSL Test de Qualys

Header always add Strict-Transport-Security "max-age=15768000"

Header always set Strict-Transport-Security "max-age=31536000"

Según Mozilla

# HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
Header always set Strict-Transport-Security "max-age=63072000"

SSL Qualys Lab Test:

This server supports TLS 1.3.
HTTP Strict Transport Security (HSTS) with long duration deployed on this server.
DNS Certification Authority Authorization (CAA) Policy found for this domain.

DNS Certification Authority Authorization (CAA)

1) Añade una entrada DNS del tipo CAA en la gestión de DNS de cPanel:

Zone Editor => Administrar => Agregar Registro => Add CAA Record.

Esta entrada debe tener los siguientes parámetros:

Tipo	Valor
Domain	elhacker.net. (cambia tu dominio.com por tu dominio real, con un punto al final)
TTL	14400
Record Type	CAA
Flags	0
Tag	issue
sslissuer.tld	letsencrypt.org

Valor CAA

0 issue letsencrypt.org

bind (named.conf)

elhacker.net. IN CAA 0 issue "letsencrypt.org"
elhacker.net. IN CAA 0 iodef "mailto:webmaster@elhacker.net"

Opciones CAA

issue Permite autorizar explícitamente a una única entidad de certificación a emitir certificados para ese dominio o subdominio. De ser necesario autorizar a más de una, se deberán crear múltiples registros CAA.
issuewild Permite autorizar explícitamente a una única entidad de certificación a emitir certificados de comodín (wildcard) para ese dominio/subdominio. Ningún otro certificado que no sea wildcard podrá ser emitido por esa entidad, salvo que esté expresamente configurado.
iodef Especifica a dónde deben enviarse los reportes de intentos de emisión de certificados por una entidad no autorizada (El formato debe ser “mailto:webmaster@elhacker.net”).

Los registros CAA con las etiquetas issue y issuewild son aditivos; Si se devuelve más de uno como respuesta a una consulta de DNS para un nombre de host determinado, las CA especificadas en ambos registros se consideran autorizadas.

Configuración en Apache (Fortificando, Hardening Apache)

Directivas para añadir en el fichero de configuración httpd.conf

HTTP Request Methods

Default apache configuration support OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT method in HTTP 1.1 protocol.

deny from all

Web Application Security

Disable Trace HTTP Request

TraceEnable off

Set cookie with HttpOnly and Secure flag

En PHP

ini_set("session.cookie_httponly",1); // solo funciona si usamos PHP >= 5.2.0.

ini_set('session.cookie_secure',1);

Requiere mod_headers

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

Clickjacking Attack

https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

Opciones:

X-Frame-Options

DENY, SAMEORIGIN, ALLOW-URL url

Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff

Cross Site Scripting (XSS)

Opciones

0 --> XSS filter disabled
1 --> XSS filter enabled and sanitized the page if attack detected
1;mode=block --> XSS filter enabled and prevented rendering the page if attack detected
1;report=http://example.com/report_URI --> XSS filter enabled and reported the violation if attack detected

Valor recomendado Apache:

Header set X-XSS-Protection "1; mode=block"

Nginx

add_header X-XSS-Protection "1; mode=block";

HTTP Strict Transport Security (HSTS)

https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

Opciones:

max-age -> Duration (in seconds) to tell a browser that requests are available only over HTTPS.
includeSubDomains ->The configuration is valid for the subdomain as well.
preload -> Use if you would like your domain to be included in the HSTS preload list

Recomendado Apache

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Nginx

add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';

Configuración SSL

Según:

https://ssl-config.mozilla.org/

Apache 2.4.x

Configuración vieja (navegadores antiguos)

SSLProtocol             all -SSLv3

Configuración intermedia (recomendada)

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1

Configuración Moderna (TLS 1.3)

 SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2

SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3
DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5
SSLCompression Off

nginx

# modern configuration nginx
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;

# intermediate configuration nginx
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

# old configuration nginx
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
ssl_prefer_server_ciphers on;

OCSP Stapling

Apache

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

nginx

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

SSLUseStapling --> El "grapado" OCSP alivia el cliente de consulta de la respuesta OCSP por sí solo, pero hay que señalar que con la especificación RFC 6066, CertificateStatus la respuesta del servidor sólo puede incluir una respuesta OCSP para un solo certificado. Para los certificados de servidor con certificados CA intermedios en su cadena (el caso típico de hoy en día), grapado en su implementación actual, por tanto, sólo alcanza parcialmente el objetivo declarado de "ida y vuelta y el ahorro de recursos" - véase también el RFC 6961 (TLS Título Múltiple de estado de extensión).
SSLStaplingCache --> Configura la memoria caché que se utiliza para almacenar las respuestas OCSP, que sean incluidos en el acuerdo de TLS si está habilitada la SSLUseStapling. La configuración de una memoria caché es obligatorio para el grapado OCSP. Con la excepción de none y nonenotnull, los mismos tipos de almacenamiento que son compatibles con SSLSessionCache.

Todo junto fichero configuración Apache httpd.conf

CoreDumpDirectory /tmp

# bajar timeout, por defecto 300
Timeout 80

# Maximum size of the request body.
#LimitRequestBody 10000
# Maximum number of request headers in a request.
LimitRequestFields 40
# Maximum size of request header lines.
LimitRequestFieldSize 4094
# Maximum size of the request line.
#request failed: URI too long (longer than 500)
#LimitRequestLine 500

#nuevo antidos
#RLimitCPU 10 20
#RLimitCPU 100 100
#RLimitMEM 10000000 10000000
#RLimitNPROC 25 25

# esconder versión Apache, aka version banner
ServerTokens Prod

#seguridad
# http://httpd.apache.org/docs/2.2/mod/core.html#traceenable
TraceEnable off

#seguridad

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
#https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
Header always append X-Frame-Options SAMEORIGIN
Header set X-XSS-Protection "1; mode=block"
Header set X-Content-Type-Options: "nosniff"
Header always set Referrer-Policy "origin"
Header always set Feature-Policy "geolocation 'self'; vibrate 'none'"
#activar HSTS
Header always add Strict-Transport-Security "max-age=15768000"

# https ssl

SSLRandomSeed startup file:/dev/urandom 1024

# enable SSLv3 and TLSv1, but not SSLv2
#SSLProtocol all -SSLv2
#SSLProtocol -ALL +SSLv3 +TLSv1
# https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-#secrecy
# new 2014
# https://www.ssllabs.com/ssltest/analyze.html?d=foro.elhacker.net
# Grade A, antes Grade F
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
#SSLCipherSuite ALL:!ADH:!NULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+TLSv1 SLv2:+EXP:+eNULL

# mozilla
# https://wiki.mozilla.org/Security/Server_Side_TLS
# SSLCipherSuite AES256+EECDH:AES256+EDH:!aNULL:!eNULL

#
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+AESGCM EECDH EDH+AESGCM EDH+aRSA HIGH !MEDIUM !LOW !aNULL !eNULL !LOW !RC4 !MD5 !EXP !PSK !SRP !DSS"

Configuración segura para el servidor web Lighttpd

ssl.honor-cipher-order = "enable"
ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"
ssl.use-compression = "disable"
setenv.add-response-header = (
    "Strict-Transport-Security" => "max-age=63072000; includeSubdomains; preload",
    "X-Frame-Options" => "DENY",
    "X-Content-Type-Options" => "nosniff"
)
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"

Fuentes:

https://geekflare.com/http-header-implementation/
https://diogomonica.com/2015/12/29/from-double-f-to-double-a/
https://foro.elhacker.net/desarrollo_web/seguridad_y_hardening_en_apache-t429857.0.html

Etiquetas: apache , CAA , cabeceras , Clickjacking , CSRF , hardening , https , manual , nginx , OCSP , secure socket layer , seguridad , servidor web , ssl , sysadmin , tls , tutorial

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.

Tienda Wifi

Tutoriales y Manuales

Entradas Mensuales

Síguenos en:

Blogroll

Etiquetas

Entradas populares

Cabeceras de Seguridad HTTPS en el servidor web Nginx y Apache

Cabeceras de Seguridad (HTTP Headers)

CSP (Content Security Policies)

HTTP Referrer

X-Frame-Options

X-XSS-Protection

X-Content-Type-Options

X-Permitted-Cross-Domain-Policies

Expect-CT

Feature Policy

Cross-Origin Opener Policy (COOP)

COEP: Cross Origin Embedder Policy

HTTP Strict Transport Security (HSTS)

Testing SSL/TLS with SSL Breacher

Configuración en Nginx

HSTS (HTTP Strict Transport Security (HSTS))

DNS Certification Authority Authorization (CAA)

Configuración en Apache (Fortificando, Hardening Apache)

Disable Trace HTTP Request

Set cookie with HttpOnly and Secure flag

Clickjacking Attack

Cross Site Scripting (XSS)

HTTP Strict Transport Security (HSTS)

Configuración SSL

OCSP Stapling

Configuración segura para el servidor web Lighttpd

0 comentarios :

Publicar un comentario