Tags: seguridad

Infografía: Las tendencias en soluciones biométricas

17 Nov 2016

soluciones biométricas viafirma

La biometría es la tecnología que se basa en el reconocimiento automático de los individuos en función de sus características biológicas y de comportamiento.

Las soluciones biométricas están basadas en el reconocimiento de uno o varios factores físicos e intransferibles de las personas.

[…]

Infografía: 10 razones por la que usar firma electrónica en lugar de firma manuscrita

02 Ago 2012

Según la legislación española (y muchas latinoamericanas), la firma electrónica reconocida cuenta con la misma validez legal que la firma manuscrita, con lo que a partir de aquí me surgen algunas preguntas: ¿Por que la gente sigue teniendo reticencias para usar la firma electrónica en lugar de la tradicional en papel? ¿Cuál es su miedo? ¿O es desconocimiento? ¿Será por la falta de promoción publicitaria? Pues bien, sin ánimo de crear un debate en el que se vuelvan a estudiar las razones por las que la gente de a pie tiene estas reticencias, os dejo una infografía con 10 motivos por los que SÍ deberías de usar la firma electrónica en tu empresa.

firma electrónica vs firma manuscrita

UsernameToken en Jax-ws (1/2)

04 Jun 2010

El objetivo de este artículo es mostrar como usar UsernameToken según la especificación Web Services Security UsernameToken Profile 1.0. El artículo consiera que el lector ya tiene experiencia en Jax-ws y se centra sólo en la configuración del mecanismo de seguridad para publicar y consumir servicios que requieran la identificación del solicitante con usuario y password haciendo uso de Jax-ws.

Dependencias requeridas

Aunque las dependencias necesarias están incluidas en algunos servidores de aplicaciones, si lo deseamos podemos o bien bajar la implementación de referencia directamente desde su web:

https://jax-ws-commons.dev.java.net y https://jax-ws.dev.java.net

O definir la dependencia en caso de que el proyecto sea Maven.

Definir  un nuevo manejador JAX-WS

En primer lugar indicaremos sobre la clase que implementa el WS el handlerchain.xml que define el manejador de seguridad  mediante la anotación @HandlerChain.


@HandlerChain(file = "handlerchain.xml")
@WebService(serviceName = "IcmsWSAPIService", targetNamespace = "http://www.juntadeandalucia.es/icms", name = "IcmsWSAPIClient", portName = "IcmsWSAPIPort", endpointInterface = "es.juntadeandalucia.icms.IcmsPublisherClient")
public class IcmsPublisherWSImpl implements IcmsPublisher {..}

A continuación indicaremos en el fichero handlerchain.xml el nombre de la clase que implementa en manejador de seguridad.

Implementar un manejador para WSS

Se necesitará una clase que implemente SOAPHandler que haciendo uso de XWSSProcessor se encargue de procesar los mensajes SOAP con los header WSSE. Un ejemplo de esta clase podría ser:


/**
* Web Services Security UsernameToken Profile 1.0
*
*/
public class SecurityHandler implements SOAPHandler<SOAPMessageContext> {

XWSSProcessor securityProcessor = null;

/**
* Build the Security Handler
*/
public SecurityHandler() {

try {
// Creamos el procesador SOAP para WSS
final InputStream input = this.getClass().getResourceAsStream("/user-pass-authenticate-server.xml");
final XWSSProcessorFactory factory = XWSSProcessorFactory.newInstance();
securityProcessor = factory.createProcessorForSecurityConfiguration(input, new SecurityEnvironmentHandler());
input.close();
} catch (final Exception e) {
logger.error("No se puede inicializar El Handler", e);
}

}

/**
*  Recuperamos el bloque header.
*/
public Set<QName> getHeaders() {
final QName securityHeader = new QName("http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-   secext-1.0.xsd", "Security", "wsse");
final HashSet<QName> headers = new HashSet<QName>();
headers.add(securityHeader);
return headers;
}

public boolean handleFault(final SOAPMessageContext messageContext) {
return true;
}

public boolean handleMessage(final SOAPMessageContext messageContext) {
final SOAPMessage message = messageContext.getMessage();

try {
// Contexto WSS
final ProcessingContext context = securityProcessor.createProcessingContext(message);
context.setSOAPMessage(message);
SOAPMessage verifiedMsg = null;
verifiedMsg = securityProcessor.verifyInboundMessage(context);

// Obtenemos el usuario y pass indicado en la request
String username = null;
String pass = null;
final Subject subject = SubjectAccessor.getRequesterSubject(context);

final Set<Principal> principals = subject.getPrincipals();
if (!principals.isEmpty()) {
final Principal principal = principals.iterator().next();
// Obtenemos en CN: CN=userName
username = StringUtils.substringAfterLast(principal.getName(), "=");
}
final Set<Object> publicCredentials = subject.getPublicCredentials();
if (!publicCredentials.isEmpty()) {
pass = (String) publicCredentials.iterator().next();
}

// Verificamos el comportamiento user y pass
validateUser(username, pass);

messageContext.setMessage(verifiedMsg);
} catch (final XWSSecurityException e) {
logger.error("WSS validation problem. ", e);
throw SecurableSoapMessage.newSOAPFaultException("WS validation problem.", e);
}

return true;
}

/** Validación específica de la aplicación.
* @param username
* @param pass
* @throws XWSSecurityException
*/
private void validateUser(final String username, final String pass) throws XWSSecurityException {
// Verificación específica de la aplicación.
//throw new XWSSecurityException("Invalid user." + username);

}

public void close(final MessageContext messageContext) {
}

private static Logger logger = Logger.getLogger(SecurityHandler.class);

}

Esta clase será la encargada de procesar todos los mensajes, verificando que todos son válidos y contienen un usuario y pass correcto. Un ejemplo de un mensaje válido WSS sería:


<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"       S:mustUnderstand="1">
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1255949753848350309586">
<wsse:Username>usuario</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">****</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">9w+YwOatF9l1/otioQ75d5Yr</wsse:Nonce>
<wsu:Created>2009-10-19T10:55:54.418Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</S:Header>
<S:Body>
<ns2:ping xmlns:ns2="http://www.juntadeandalucia.es/icms" xmlns:ns3="http://www.juntadeandalucia.es/icms/data">
<ns2:request>test</ns2:request>
</ns2:ping>
</S:Body>
</S:Envelope>

Próximamente cómo crear un cliente Jax-ws que consuma servicios securizados con   UsernameToken.

Viafirma 2.5 – Soporte para PHP

23 Feb 2010

En los próximos días liberaremos nueva versión 2.5 de Viafirma caracterizada, principalmente, por el soporte para PHP y mejoras en el proveedor de servicios OpenID. Fueron constantes las peticiones y consultas recibidas por clientes en las que necesitaban de una Autenticación basada en el uso del DNIe desde portales públicos o restringidos (intranet) desarrollados éstos en PHP.

Con esta nueva versión, y con el uso del nuevo cliente desarrollado para PHP, se permitirá a los integradores incorporar en sus portales los servicios de Autenticación haciendo uso del DNIe y, por supuesto, del resto de Certificados Digitales que ya veníamos soportando.

En casa ya nos estamos beneficiando de esta nueva versión, integrando nuestras plataformas Moodle (e-learning para uso interno) y Drupal (cms) con Viafirma para autenticarnos con el DNIe. Otros desarrollos específicos en PHP, como TimeTracker (control de imputaciones horarias), también han sido integrados para permitir el acceso mediante DNIe.

Augi@s, sistema de gestión de residuos pionero en hablar E3L

22 Feb 2010

E3L son las siglas de Environmental Electronic Exchange Language y nace ante la necesidad de establecer un formato estándar de intercambio de datos ambientales entre las distintas comunidades autónomas. Se trata de un proyecto colaborativo, en el que las AA PP implicadas consensúan los flujos de información y los plasman en un lenguaje común con unas reglas definidas y aceptadas por todos. E3L proporciona no sólo las reglas para comunicar plataformas tecnológicas, sino que conforma el primer diccionario electrónico de datos ambientales (metadatos). E3L cubre por ejemplo la presentación telemática de la Memoria Anual de Gestores de residuos, la Declaración Anual de Productores de residuos, los Documentos de Control y Seguimiento de residuos, etc. Para más información sobre este proyecto se pueden visitar los portales del proyecto:

  • http://www.e3l.es/
  • http://www.eterproject.org/

La Consejería de Medio Ambiente de la Junta de Andalucía ha apostado fuerte por la iniciativa y como resultado de ello confió en VIAVANSI para construir Augi@s, un sistema integral de gestión de residuos pionero al hablar E3L. Augi@s permite completar el ciclo de un documento desde su creación hasta su presentación y firma. El sistema ha sido diseñado para hablar en lenguaje E3L; por ello, el equipo de proyecto, constituido por personal de la Consejería de Medio Ambiente y de VIAVANSI, ha participado en la definición del estándar durante su desarrollo. Esto supone al fin una garantía de futuro para el formato de los datos manejados por Augi@s.La aplicación está diseñada con la máxima flexibilidad posible, externalizando en un API independiente la gestión del formato E3L, permitiendo adaptarse a los cambios del mismo en poco tiempo, o integrar nuevos elementos como los servicios publicados en E3S, que ya se encuentran en fase de pruebas en Augias.Considerando la aceptación del formato E3L a nivel estatal y la posibilidad de exportar dicho formato a otros países de la UE, podemos decir que la plataforma Augi@s se encuentra en una posición privilegiada de cara al futuro y vuelve a demostrar que, en contra de lo que se supone en varios círculos de opinión, Andalucía suele liderar a nivel nacional la innovación en muchos proyectos tecnológicos.

Servidores de Correo y su Integridad

11 Sep 2008

No es noticia que te fastidien una aplicación que estaba corriendo bien porque otro servicio anda por ahí haciendo de las suyas y tú eres el último en enterarte.

Este caso es el que nos pasó recientemente, y lo peor de todo es que era en un entorno de producción.

El ejemplo en cuestión se trataba de un sistema que hacía uso de VIAFIRMA (nuestra plataforma de autenticación y firma digital). Cuando ésta enviaba los correos firmados digitalmente con el certificado instalado en producción, el “maravilloso” Exchange empezó a aplicar una regla para los correos cuyo destinatario fuese un correo externo.

Esta regla no era otra que interceptar el correo e inyectarle un disclaimer en el pie, del tipo “…este mensaje contiene información confidencial….”.

El catastrófico resultado en los correos que recibían los usuarios:


La firma no es válida
El mensaje incluye una firma digital, pero la firma no es válida.
La firma no coincide correctamente con el contenido del mensaje. El mensaje parece que ha sido manipulado después de que el remitente lo firmara. Usted no debería confiar en la validez de este mensaje hasta que verifique su contenido con el remitente.
Firmado por: "la empresa en cuestión"

Para hacer más difícil aún la detección del problema, y sin saber aún por qué, Exchange no siempre estaba aplicando esta regla y se escapaban correos sin el disclaimer.

Por tanto, en sistemas de información donde apuesten por la automatización del formato de los correos salientes desde el lado servidor siempre tendrán que tener en cuenta qué REGLAS de INTEGRIDAD podrían estar rompiendo.

Comunicación anónima por internet

23 Feb 2007

Un amigo que reside en China, país que controla toda la red, me contó recientemente que ha encontrado un buen método para saltarse al gran hermano chino.

Usa Tor, un sistema para navegar de forma anónima por internet, y de esta forma poder evitar la sinrazón china de censurar ciertos contenidos. También es útil para saltar los “analytics” que aprenden? de tus búsquedas.

Para más información sobre Tor, visitad su web: http://tor.eff.org/

Yo mismo he sufrido esta censura en cosas tan ridículas como no poder ver mi propio blog que escribí cuando estuve en el

T T- Í Í- BB -EE -TT (y lo pongo así para que no censuren este blog….faltaría má

Seguridad muy básica en Linux

26 Ene 2007

Después del artículo anterior sobre port knocking vamos con algo totalmente básico: los permisos en Linux. Hablar de seguridad es hablar de permisos y para ello tenemos el comando chmod de linux.

Anda el lumbreras este, viene a hablarnos de chmod. Pues no, para eso existen tutoriales muy buenos, empezando por poner un ‘man chmod’ ;-). Solo quiero aconsejar que los ficheros críticos de tu sistema no tengan más permisos de los debidos. Por ejemplo en (casi) toda instalación de Linux los siguientes ficheros vienen con permisos de lectura:
/etc/inittab
/etc/group
/etc/passwd
/etc/shadow (este quizás no)

Y digo yo, ¿qué necesidad tienen los usuarios de leer esos ficheros? Un chmod 700 a cal y canto y aquí pan y después gloria.

Puede parecer una tontería pero ¿sabías que la contraseña de Administrador de Windows puede romperse en menos de 30 segundos? ¿o que un Linux es vulnerable durante el propio proceso de arranque? Pues eso, toda precaución es poca.

P.D.: no dejes de leer el post de abajo.

Seguridad avanzada en Linux: Port Knocking

20 Ene 2007

Una de las principales vulnerabilidades en un sistema es el hecho de tener que dejar abiertos los puertos cuyos servicios desea proporcionar. Si bien servicios como el http o el smtp deben permanecer abiertos para ser funcionales, es posible hacer que los servicios neurálgicos de nuestro sistema solo sean accesibles cuando verdaderamente son necesarios.

– ¿A qué nos referimos? A la posibilidad de ofrecer un servicio sobre un puerto cerrado.
– ¿Mande? Dime qué has fumado que yo también quiero…
– No he fumado nada incrédulo, hablo de la estrategia del port knocking.
– Em, ¿me lo explica?
– Desde luego.

El port knocking es una estrategia que permite a un usuario solicitar la apertura de un puerto para disponer de un servicio inicialmente cerrado. Esta solicitud tiene la forma de secuencia de paquetes de autenticación enviados a puertos cerrados. Es posible enviar información a través de puertos cerrados y en ausencia de otro servicio de red, ya que nuestro cortafuegos y otras utilidades como tcpdump pueden configurarse para observar todos los paquetes que llegan sin importar si luego serán entregados a un servicio. La gran potencia del port knocking radica en el hecho de trabajar siempre con puertos cerrados, lo cuál no deja resquicios de seguridad.

Una forma de limitar los usuarios entrantes es por filtrado de IP, pero esta ténica tiene muchas debilidades: puertos abiertos, suplantación física, imposibilidad de movilidad de los usuarios… Port Knocking resuelve todos estos problemas y además aporta más seguridad.

El port knocking fue descrito por primera vez en la revista SysAdmin. Existen diversas formas de implementarlo, una bastante popular es doorman, aunque aquí haremos una implementación muy sencilla basada en tcpdump y en tan solo 4 pasos.

Paso 1: cerrar todo. Lo primero es usar una configuración muy restrictiva en nuestro iptables: lo cerramos todo. Un ejemplo simple sería:

#!/bin/sh
#firewall.sh
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP
iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP

Cabe destacar el uso de DROP, nunca de REJECT en nuestra política de rechazo ya que debe producirse una denegación silenciosa del servicio que no provoque respuesta al supuesto intruso. Esta configuración no permite nuevas conexiones sobre puertos cerrados pero sí permite continuar aquellas iniciadas.

Paso 2: apertura de puerto. Diseñamos un script que durante abra durante 10 segundos por ejemplo el puerto solicitado si recibe un paquete cuyo “santo y seña” es correcto.

#!/bin/bash
# guard.sh
# acepta los paquetes entrantes
/sbin/iptables -I INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2
sleep 10
# rechaza los paquetes entrantes
/sbin/iptables -D INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2

A los 10 segundos el puerto se cierra, pero nosotros ya hemos iniciado la conexión (SSH, FTP, etc) y el firewall permite continuar conexiones iniciadas. ¡Estamos trabajando sobre un puerto cerrado!

Paso 3: escucha activa. El port knocking se asemeja a las famosos santo y seña de las películas de espionaje donde abrimos una puerta llamando con “2 toques largos, 3 cortos y uno largo”. En nuestro caso la contraseña correcta podría ser que el paquete recibido tuviera una cabecera de valor 17. Debemos diseñar un script que permanezca a la escucha e identifique la llamada correcta. Cuando ésta se produzca lanzará guard.sh lo que abrirá el puerto durante 10 segundos, tiempo suficiente para entrar.

tcpdump -l -O "tcp[2:2]>=1000 and tcp[2:2]<=10999 and tcp[4:4]=17 and tcp[tcpflags] & tcp-syn!=0" | sed -u 's/.*IP \([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\).*\.10*\([0-9]*\): S.*/\1 \2/' | xargs -t -l -i bash -c "/root/guard.sh {} &"

tcpdump no permite especificar intervalos de puertos, cosa que suplimos con la sintaxis tcp[2:2] que indica un campo de 2 bytes en la cabecera TCP a partir del byte 2 (tcp[inicio:longitud]). Nuestra estrategia de implementación en esta ocasión consiste en eliminar la cabecera de 2 bytes y abrir el puerto resultante. Así por ejemplo con 1022 abriríamos el puerto 22 (SSH).

Paso 4: llamada. Nuestro sistema permanece atento, vamos a hacer la llamada correcta:

# Sintaxis:
# sendip ip_origen puerto_origen ip_destino puerto_destino
# 1000 < puerto_destino <=10999 sendip -p ipv4 -p tcp -is $1 -ts $2 -td $3 -tfs 1 -tn 17 $4

La contraseña 17 es correcta y solicitamos la apertura del puerto para nuestra IP.

Con estos sencillos pasos conseguimos que servicios tan útiles como el FTP, de los cuáles los administradores siempre son recelosos, puedan ofrecerse con riesgo nulo. El ataque de un intruso es prácticamente imposible.

Si deseas profundizar en el uso de port knocking recomiendo que te documentes sobre Doorman, de Bruce Ward, que se caracteriza por su original y elegante enfoque del port knocking.

Hasta la próxima entrega.

Las 14 principales vulnerabilidades de seguridad

17 Ene 2007

En vista que el señor dbejar nos está dejando en evidencia va siendo hora que los demás contemos algo. En esta ocasión voy a tirar hacia sistemas y voy a escribir el primero de una serie de artículos relacionados con seguridad que iré publicando en sucesivas entregas.

Como es la primera empecemos despacito para ir calentando motores. Lo leí en un libro bastante bueno (a ver si lo encuentro, solo conservo unos apuntes) y el punto se titula, como vuestras mentes lúcidas habrán deducido, “Las 14 principales vulnerabilidades de seguridad”. En ella repasamos los principales puntos por los que un hacker podría atacar nuestro sistema. Contempla tanto sistemas Windows como Linux, es un “vuelo rasante”. Vamos al turrón:

1) Control de acceso inadecuado al router: un ACL del router que se haya configurado erróneamente puede permitir la filtración a través de ICMP (Protocolo de Control de Mensajes de Internet), IP NetBIOS y permitir accesos no autorizados a determinados servicios en sus servidores DMZ (Zona DesMilitarizada).

2) Los puntos de acceso remoto no seguros y no vigilados proporcionan uno de los modos más sencillos de acceder a nuestra red. Es conveniente no exponer nuestros archivos sensibles.

3) La filtración de información puede proporcionar al atacante información sobre la versión de nuestro sistema operativo, aplicaciones, usuarios, grupos, servicios compartidos, información DNS a través de transferencias de zona y servicios en ejecución tales como SNMP, finger, SMTP, telnet, rusers, rcpinfo, NetBios…

4) Los host que ejecutan servicios innecesarios tales como RCP, FTP, DNS, SMTP, etc son una fuente innecesaria de puertos vulnerables.

5) Contraseñas reutilizadas, sencillas o fácilmente adivinables a nivel de estación de trabajo. Caer ante un ataque de diccionario es uno de los errores más frecuentes en un sistema si no se educa adecuadamente a sus usuarios.

6) Cuentas de usuarios con privilegios excesivos. En combinación con 5 es bajarse los pantalones ante el resto del mundo.

7) Sevidores de internet mal configurados, especialmente archivos de comandos CGI en servidores web y FTP anónimos con permisos de escritura.

8) Si un servidor DMZ queda comprometido un ACL mal configurado en el router puede dar acceso al intruso a la zona interna de nuestra red.

9) Aplicaciones que no estén convenientemente actualizadas con sus correspondientes parches de seguridad.

10) Excesivos controles de acceso en los recursos compartidos de NT y exportaciones mediante NFS en Unix.

11) Contar con excesivas relaciones de confianza tales como los Dominios de Confianza en NT y los archivos .rhost y hosts.equiv de UNIX puede orientar al atacante un acceso a sistemas sensibles.

12) Servicios no autenticados tales como X-Windows que permiten a los usuarios capturar pulsaciones de tecla realizadas de forma remota.

13) Capacidades de registro, detección y vigilancia inadecuadas, sin cruzar la frontera que puede suponer invadir la privacidad de los trabajadores.

14) Carencia de directivas, procedimientos, normativas y directrices de seguridad aceptadas y convenientemente elaboradas.

Y si me apuraís añadiría la 15, El arma más eficaz del hacker: la ingeniería social.

Bueno, ¿y todo este tostón para qué? Pues en principio solo para que te hagas preguntas sobre tu sistema. En próximos artículos iremos al grano con soluciones prácticas para cada apartado con la idea de amargar la vida al más perseverante de los hackers.

Sed buenos.