martes, 27 de febrero de 2018

Guía paso a paso para configuración de certificados Let’s Encrypt en Apache HTTPD sobre Windows Server

Para poder configurar nuestro servidor web Apache con SSL lo primero que vamos a hacer es obtener los cerficados Let's Encrypt.

Descargamos y descomprimimos la última versión de la utilidadletsencrypt-win-simple.v1.9.8.4.zip

Dentro una ventana de comandos con permisos de administrador ejecutamos letsencrypt.exe y nos aparece el siguiente menú:


Elegimos la primera opción M y nos aparece el siguiente menú:


Ahora elegimos la opción 4 para introducir el nombre de nuestro servidor manualmente (www.ejemplo.com):


En este apartado es posible introducir varios nombres de dominio de virtual hosts configurados en tu servidor pero yo no he conseguido que instale en todos ellos el fichero de comprobación de la propiedad del dominio, por ello he realizado estos pasos de instalación para cada virtual host.

En el siguiente menú nos pregunta que procedimiento utilizar para la instalación del fichero de comprobación de propiedad del dominio.


Como se puede apreciar elegimos la opción 3 en la que proporcionamos la ruta de nuestro DocumentRoot según lo tenemos configurado en Apache.

Seguidamente nos pregunta si se realiza la copia del fichero de comprobación de propiedad del dominio y decimos que sí.


Una vez realizado esto la utilidad letsencrypt-win-simple ya está en disposición de comprobar que vamos a instalar el certificado en un servidor del que somos propietarios por ello pregunta si queremos comenzar el proceso de instalación (más bien creación) de certificados.


Elegimos la opción 2 pues no necesitamos ejecutar acciones adicionales mediante un script, tal y como se ve en el pantallazo de arriba.

Ya finalizando podemos ver estos mensajes de confirmación de la creación del certificado y la creación de la tarea programada para la renovación.


Podemos ver los ficheros de certificado que se han creado en la carpeta:
C:\ProgramData\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org
Seguidamente vamos a configurar Apache HTTPD Server para que utilice los certificados.

En el fichero httpd.conf tenemos que realizar las siguientes modificaciones:


  • Añadir un listener para el puerto 443 de HTTPS
  • Activar el módulo de SSL



El fichero donde tenemos configurados los virtual hosts httpd-vhosts.conf quedará de esta manera para cada uno de los virtual hosts:


<VirtualHost *:80>
    ServerAdmin miemail@miserver.es
    DocumentRoot "C:/miWebRoot"
    ServerName www.midominio.es

RewriteEngine On
# Redirect to the HTTPS site
RewriteCond %{HTTPS} off
RewriteRule ^/?(.*)$ https://www.midominio.es/$1 [NE,L,R=301]

</VirtualHost>


<VirtualHost *:443>
    ServerAdmin miemail@miserver.es
    DocumentRoot "C:/miWebRoot"
    ServerName www.midominio.es

RewriteEngine On
    # Redirect to the correct domain name
    RewriteCond %{HTTP_HOST} !^www.midominio.es$ [NC]
    RewriteRule ^/?(.*)$ https://www.midominio.es/$1 [NE,L,R=301]

SSLEngine on
SSLCertificateFile "C:/ProgramData/letsencrypt-win-simple/httpsacme-v01.api.letsencrypt.org/www.midominio.es-crt.pem"
SSLCertificateKeyFile "C:/ProgramData/letsencrypt-win-simple/httpsacme-v01.api.letsencrypt.org/www.midominio.es-key.pem"
SSLCertificateChainFile "C:/ProgramData/letsencrypt-win-simple/httpsacme-v01.api.letsencrypt.org/ca-VALORESHEXADECIMALES-crt.pem"

</VirtualHost>




Como vemos además de los certificados hemos añadido redirecciones desde el puerto 80 al 443 por lo que todas las url no seguras funcionarán siendo redirigidas a su equivalente en HTTPS.

En caso de tener conectores AJP para servir páginas desde TOMCAT copiaríamos la configuración de AJP al virtualhost con el puerto 443 y nos seguirá funcionando correctamente también con páginas seguras.

Si todo es correcto ya tenemos nuestro servidor sirviendo páginas en HTTPS y solo nos quedaría estar atentos a que las renovaciones automáticas de los certificados se realicen correctamente.







miércoles, 26 de abril de 2017

Hispasec @unaaldia: Corregida vulnerabilidad crítica en Drupal

El equipo de seguridad de Drupal ha publicado un boletín de seguridad calificado como crítico, en el que se soluciona una vulnerabilidad que podría permitir a un atacante evitar los controles de acceso.

El problema, con CVE-2017-6919 y considerado crítico, consiste en un salto del acceso. Un sitio solo se ve afectado si se cumplen las siguientes condiciones: el sitio tiene activo el módulo RESTful Web Services, permite peticiones PATCH y el atacante puede tener o registrar una cuenta de usuario en el sitio.

Se ven afectadas las versiones 8.x anteriores a 8.2.8 y 8.3.1. Se recomienda la actualización a las versiones Drupal 8.2.8 o 8.3.1.



Hispasec @unaaldia: Corregida vulnerabilidad crítica en Drupal

martes, 11 de octubre de 2016

What Yahoo's NSA Surveillance Means for Email Privacy - ProtonMail Blog

Two weeks ago, we published a security advisory regarding the mass hacking of Yahoo. Unfortunately, due to recent events, we are issuing a second advisory regarding all US email providers.

What happened?

This week, it was revealed that as a result of a secret US government directive, Yahoo was forced to implement special surveillance software to scan all Yahoo Mail accounts at the request of the NSA and FBI.
Sometime in early 2015, Yahoo secretly modified their spam and malware
filters to scan all incoming email messages for the phrases in the court
order and then siphoned those messages off to US intelligence. This is
significant for several reasons:

  • This is the first known incident
    where a US intelligence directive has indiscriminately targeted all
    accounts as opposed to just the accounts of suspects. Effectively, all
    500 million+ Yahoo Mail users were presumed to be guilty.
  • Instead of searching stored messages, this directive forced Yahoo to scan incoming messages in real-time.
  • Because ALL incoming email messages
    were targeted, this program spied on every person who emailed a Yahoo
    Mail account, violating the privacy of users around the world who may
    not even have been using a US email service.

What does this mean for US tech companies?

This is a terrible precedent and ushers in a new era of global mass surveillance. It
means that US tech companies that serve billions of users around the
world can now be forced to act as extensions of the US surveillance
apparatus.
The problem extends well beyond Yahoo. As was
reported earlier, Yahoo did not fight the secret directive because Yahoo
CEO Marissa Mayer and the Yahoo legal team did not believe that they
could successfully resist the directive.


What Yahoo's NSA Surveillance Means for Email Privacy - ProtonMail Blog

lunes, 10 de octubre de 2016

El CCN-CERT publica Informe sobre los riesgos en el uso de WhatsApp

El CCN-CERT ha publicado un informe sobre los riesgos en el uso de WhatsApp en el que da a conocer los problemas de seguridad más conocidos y habituales del conocido programa de mensajería.
También ofrece recomendaciones de seguridad para ayudar a prevenir cualquier posible incidente.
El documento, de 21 páginas, incide en los siguientes problemas de seguridad del servicio:
  • Secuestro de cuentas aprovechando fallos de la red
  • Borrado inseguro de conversaciones
  • Difusión de información sensible durante la conexión inicial
  • Robo de cuentas mediante SMS y acceso físico
  • Robo de cuentas mediante llamada y acceso físico
  • Peligros de la descarga de WhatsApp de markets no oficiales
  • Ataques de phishing utilizando WhatsApp web
  • Almacenamiento de la información en la base de datos
  • Intercambio de datos personales entre WhatsApp y Facebook
  • Otros fallos de seguridad anteriores 
Por último se incluye un apartado con unas breves recomendaciones adicionales útiles para cualquier usuario de teléfonos móviles.

Hispasec @unaaldia: El CCN-CERT publica Informe sobre los riesgos en el uso de WhatsApp

jueves, 15 de septiembre de 2016

Obteniendo el valor de un checkbox en Struts

El checkbox es un control que tiene un comportamiento un poco especial. Cuando el checkbox está activado la propiedad asociada es modificada a true, pero cuando se desactiva el checkbox no se realiza ninguna acción.
Así que para funcione correctamente la propiedad del checkbox debe estar inicializada a false. Pero hay otro problema, si solo lo inicializarmos en el constructor del ActionForm no se actualizará en sucesivos cambios del checkbox, por ello debemos inicializar el valor en la función reset.

Código del ActionForm:

public class EncuestadoVOForm extends ActionForm{

private boolean activado; //propiedad asociada al checkbox

//constructor
public EncuestadoVOForm() {


activado = false; //inicializamos en el constructor
 

}


public void reset(ActionMapping mapping,
HttpServletRequest request) {

activado = false; //inicializamos en el reset


}


Como podéis deducir el constructor ya no es necesario una vez añades la función reset por lo que se podría quitar y el ActionForm funcionaría bien.

Sino lo realizamos así la propiedad "activado" siempre devuelve true sea cual sea el estado del checkbox.