Implementando Content Security Policy en el blog (WordPress)

Content-Security-Policy (CSP) no es más que un header más (como X-XSS-Protection o X-Frame-Options) que ayuda a mejorar la seguridad de nuestro sitio web. Básicamente con CSP especificamos qué origen puede tener cada tipo de recurso servido en nuestra página.

CSP divide los tipos de recursos que puede cargar una web con una serie de directivas: default-src (por defecto), img-src (imágenes), font-src (fuentes), style-src (estilos), script-src (scripts), etc… en cada directiva especificamos el posible origen del recurso. Un ejemplo en Apache para un blog WordPress:

Header set Content-Security-Policy \
"default-src 'self' *.github.com *.wordpress.org secure.gravatar.com w.org s.w.org;\
 font-src 'self' 'unsafe-inline' data: *.googleapis.com fonts.gstatic.com;\
 style-src 'self' 'unsafe-inline' data: *.googleapis.com assets-cdn.github.com;\
 media-src 'self' *.youtube-nocookie.com;\
 frame-src 'self' *.youtube-nocookie.com;"

Un ejemplo en Nginx:

add_header Content-Security-Policy \
"script-src 'self' 'unsafe-inline' 'unsafe-eval' *.youtube.com *.googleapis.com *.google-analytics.com;\
 frame-src 'self' *.youtube.com;\
 font-src 'self' https://themes.googleusercontent.com;\ 
 object-src 'self'";

Sigue leyendo

Supervisión del sistema con psacct/acct y audit

Las herramientas audit y psacct/acct son de gran utilidad para tener controlado qué ocurre en nuestro sistema: qué usuarios han entrado a la máquina, acciones realizadas, procesos lanzados, etc… Aunque por el nombre puedan parecer lo mismo no lo son:

  • Audit mediante un componente integrado como subsistema del Kernel Linux se encarga de capturar las llamadas a sistema de las aplicaciones para posteriormente mandar la información de dichas llamadas al demonio auditd. Éste se encarga de procesar dicha información y generar los logs de auditoría que podemos consultar con comandos como aureport, ausearch, aulast…
  • La segunda herramienta tiene un nombre distinto según la distribución: psacct (Process Accounting) en RHEL/derivadas y acct (Accounting) en Debian/derivadas. Con esta herramienta podemos ver fácilmente qué usuarios entran a la máquina, qué comandos lanzan, etc… pudiendo detectar acciones u operaciones que comprometan la integridad del sistema.

Sigue leyendo

Clúster JGroups independiente para cada Server Group en Jboss EAP 6.x+ modo dominio

Si utilizamos Jboss en modo dominio seguramente tengamos aplicaciones agrupadas en distintos Server Groups. Éstos a su vez estarán asociados a un Profile en concreto. En caso de ser HA podría ser:

<server-groups>
    <server-group name="server-group-1" profile="ha">                                                                                                                                                     
        <jvm name="default">
            <heap size="1000m" max-size="1000m"/>
        </jvm>
        <socket-binding-group ref="ha-sockets"/>
    </server-group>
    <server-group name="server-group-2" profile="full-ha">
        <jvm name="default">
            <heap size="1000m" max-size="1000m"/>
        </jvm>
        <socket-binding-group ref="full-ha-sockets"/>
    </server-group>
</server-groups>

Sigue leyendo

Certification Authority Authorization (CAA) para nuestro dominio

Cuando intentamos emitir un certificado SSL para un dominio, suele existir un mecanismo por el cual tenemos que demostrar que somos propietarios de dicho de dominio. Resulta obvio ya que de lo contrario cualquiera podría emitir certificados para dominios ajenos.

Para reforzar este mecanismo de garantías ya presente en las principales Autoridades Certificadoras, la IETF elaboró el RFC 6844. En él se establece cómo implementar un nuevo tipo de registro DNS llamado Certification Authority Authorization (CAA). Este registro especifica qué Autoridades Certificadores están autorizadas a emitir certificados para un dominio en particular. El resumen del RFC es bastante claro:

Sigue leyendo

Caso práctico de stack ELK + Metricbeat

Desde hace un tiempo tenía pendiente monitorizar los nodos virtualizados con KVM que tengo para el proyecto World Community Grid. Hay muchas maneras de hacerlo, pero me decidí por montar un stack ELK (Elasticsearch, Logstash y Kibana) en la máquina que tengo como servidor y recoger métricas con Metricbeat de cada nodo.

Por tanto, para empezar el entorno que tengo es:

  • Servidor jota-pc (Debian Stretch, IP 192.168.1.39) con ELK instalado. En el propio servidor también tengo instalado Metricbeat para tener métricas de rendimiento.
  • Máquinas virtualizadas wcg-node1, wcg-node2 y wcg-node3 con Ubuntu Server 16.04 que envian métricas a jota-pc. Como estas máquinas envían métricas al servidor jota-pc las consideraré clientes.

Sigue leyendo