Reutilización del mismo puerto en el lado del cliente

La entrada anterior está escrita desde el punto de vista de los servidores, aunque en el lado del cliente, también podemos reutilizar puertos. ¿Cómo? Pues añadiendo, antes de la función connect de, por ejemplo, este código de cliente, las siguientes órdenes:

sock.setsockopt(socket.SOL_SOCKET, SO_REUSEPORT, 1)
sock.bind((«0.0.0.0»,3000))

la primera orden es la misma que hemos comentado ya y es la que nos activa el flag que permite reutilizar el puerto; la segunda es necesaria para «forzar» el puerto y que no sea uno aleatorio. Si lanzamos 2 conexiones, nos queda:

Screenshot from 2015-03-23 10:59:20

¡Espero que os sea útil!


Reutilización de puertos en GNU/Linux

Para todos los sistemas operativos, una conexión (comunicación) entre dos equipos está definida por cualquier combinación de la tupla formada por la dirección IP origen y destino, el puerto de origen y destino y el protocolo de transporte (TCP o UDP).  Así, en cualquier nodo de nuestra red, podremos utilizar la función bind para «anclar» nuestro servidor a cualquier puerto libre. Si el puerto ya está en uso, y si nuestro nodo dispone de más de una dirección IP, podremos unir nuestro proceso utilizando otra IP que no tenga «ocupado» el puerto que nos interesa. Si el puerto y la dirección están en uso, siempre podremos usar el otro protocolo de transporte, suponiendo, nuevamente, que esté libre (y nos interese, claro).

En definitiva, esta tupla (recordemos: ip origen, puerto origen, ip destino, puerto destino, protocolo de transporte) le permiten al sistema operativo identificar unívocamente, el proceso que debe encargarse de los datos de aplicación.

Así que, ¿a qué viene el título de la entrada? ¿Qué es reutilizar puertos?

Pues para responder, debemos ver las opciones SO_REUSEADDR y, sobre todo, SO_REUSEPORT cuyo comportamiento es distinto en función del sistema operativo donde las utilicemos (ver [1]).

La opción SO_USEADDR ya la mencioné en esta entrada en la que comentaba los timeouts de TCP; en ella indicaba que, en general, interviene en el tiempo de espera…

antes de poner disponible, de nuevo, un puerto tras su cierre y el objetivo es dejar tiempo suficiente para que los segmentos de esta conexión saliente desaparezcan del sistema

aunque hay más y es lo que voy a tratar en el resto de la entrada junto con la opción SO_REUSEPORT. Ambas son importantes para la programación de Sistemas Distribuidos; y podemos usarlas cuando nos convenga, pero sin olvidarnos que debemos disponer de una versión del núcleo igual o superior a la 3.9.

SO_REUSEADDR, en GNU/Linux (así como en BSD y otros sistemas operativos) introduce, tal y como podemos comprobar en la página man de la función socket [2], la posibilidad de reutilizar la misma combinación IP-Puerto en un servidor, siempre y cuando el puerto no esté en escucha activa (es decir, se haya ejecutado la función listen para ese puerto). Básicamente, nos permite reutilizar puertos UDP, teniendo un comportamiento diferente en otros sistemas como por ejemplo BSD (ver [1]).

SO_REUSEPORT, en GNU/Linux, permite asociar un número arbitrario de sockets a la misma pareja IP-puerto, tanto para TCP como para UDP. Esto solo tiene una limitación (además de que el flag debe estar activo, antes de ejecutar bind, en todos los procesos): todos los sockets deben de pertenecer a procesos con el mismo EUID (identificador de usuario efectivo) para evitar el secuestro de puertos (port hijacking).

¿Qué ventaja aporta? Si consultamos la página man de socket:

this option allows accept load distribution in a multi-threaded 
server to be improved by using a distinct listener socket for each 
thread.  This provides improved load distribution as compared to 
traditional techniques such using a single accepting thread 
that distributes connections, or having multiple threads that 
compete to accept from the same socket.
UDP sockets, the use of this option can provide better distribution
of incoming datagrams to multiple processes (or threads) las compared
to the traditional technique of having multiple processes compete 
to receive datagrams on the same socket.

¿Cómo lo implementamos? Veamos un ejemplo. Si tomamos el código del servidor sencillo descrito en esta entrada y le añadimos la siguiente orden, justo antes de invocar la función bind*:

s.setsockopt(socket.SOL_SOCKET, SO_REUSEPORT, 1)

tras varias ejecuciones del programa, tendremos el resultado de la imagen 1 :

Screenshot from 2015-03-20 10:53:54

Y ¿qué proceso recibe los datos de aplicación? ¿Todos? Pues no. Tanto en TCP como en UDP, el núcleo de GNU/Linux trata de repartir equitativamente el trabajo entre los procesos: las conexiones entrantes para TCP (las reparte equitativamente entre los procesos que están con la ejecución de la función accept en ese puerto) y los datagramas para UDP. En el caso específico de multicast, SO_REUSEADDR tiene el mismo comportamiento que SO_REUSEPORT en conexiones unicast.

Para el ejemplo visto, tras 2 conexiones (una desde el propio equipo y otra desde otro nodo de la red) tenemos que estas se asignan a 2 procesos diferentes (ver imagen 2)

Screenshot from 2015-03-20 10:56:55

¡Espero que os sea útil!

*Solo nos falta definir: SO_REUSEPORT=15

Referencias

1.- Muy completa la respuesta dada en: http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

2.- man socket

3.- man setsockopt


ownCloud y Raspberry PI

Tras un aviso de Dropbox para que reduzca los muchísimos GB que me sobran al haber «caducado la oferta» por pertenecer a la UA, he decidio crearme mi «ownCloud» con un disco duro de 1TB que tenía y una Raspberry PI.

Sobre como instalarlo hay muchas entradas en la red (I, II, III, IV,  …) así que poco más que añadir o comentar, salvo:

Leer más


Qué hacer para conectar un disco USB sin alimentación externa a una Raspberry PI

En las Raspberry PI  la corriente está limitada a 1.2A en los USB de modo que solo es posible conectar un disco duro USB, sin alimentación externa o sin HUB, si modificamos el fichero /boot/config.txt añadiéndole:

max_usb_current=1
safe_mode_gpio=4

Tras esto y reiniciada la Raspberry  podremos conectar y utilizar el disco USB sin necesidad de alimentación extra.

¡Espero que os sea útil!

PD: Falta un detalle: la alimentación debe ser de 5V y 2A.

 


Transparencias «viejunas» sobre IDS

Hace muchos años (en el 2006) impartí unas clases en la Universidad de Almería sobre sistemas de detección de intrusos en el curso anunciado aquí.

Las transparencias que hice las he subido a Slideshare y he hecho un collage para presentarlas en este blog como anuncié hace unos días. Aquí lo tenéis.

Sobre SNORT, teoría:

Y prácticas:

Sobre Honeyposts, teoría:

Y práctica:

Y, por último, sobre Tripwire:

¡¡¡Espero que os sean útiles a pesar del tiempo que tienen!!!


Transparencias de clase sobre DHCP

Tal y como comentaba ayer en esta entrada, voy a ir dejando todas mis transparencias de clases, ponencias, conferencias y cursos en Slideshare.

Hoy toca el turno del servicio DHCP, clase que impartía en la asignatura de Administración e Instalación de Redes de Computadores en las titulaciones de Informática.

De las diferentes versiones (en función de los años) que tengo, he decidido publicar estas:


Contraseñas, esas grandes desconocidas e ignoradas…

La forma en la que nos identificamos ante los gestores de nuestra identidad digital hará que esta sea más o menos fiable y, además, que no puedan «robárnosla» fácilmente. Aunque nada es imposible, como en muchos otros ámbitos de nuestra vida, nuestra seguridad digital reside en una serie de obstáculos que debemos situar entre los posibles atacantes y nosotros; complicarles en trabajo, sin complicárnoslo a nosotros mismos.

Al acceso a casi todos nuestros servicios reside, como mínimo, en una contraseña y la seguridad de esta empieza en una correcta selección de la misma:

Una buena contraseña:

  • Debe tener, al menos, seis caracteres alfanuméricos y uno o dos signos de puntuación, carácter numérico o especial o una mezcla de letras mayúsculas y minúsculas. Es decir, longitud más variedad.
  • Si se está cambiando una contraseña, la nueva debería tener al menos tres caracteres que no estuvieran en el password anterior.
  • Puede basarse en la concatenación de dos o más palabras o partes de palabras. Puede basarse en la inclusión de una palabra dentro de otra palabra. Por ejemplo, cladificilve que tiene la palabra difícil dentro de la palabra clave. Puede basarse en el intercalado de las letras de una o más palabras: por ejemplo, ‘glaotroo’ intercala ‘loro’ y ‘gato’.
  • Por supuesto, NO usar la misma contraseña para distintos servicios.
  • Importante: que siga un patrón fácil de recordad para nosotros y que implique el cumplimiento de las características anteriores y ninguna de las siguientes.

Y lo que no debe ser es:

  • Cualquier parte del nombre del usuario o el nombre de algún miembro de su familia o amigos.
  • No debe ser un número significativo para el usuario o para alguien cercano al usuario como números de la seguridad social, matricula del coche, número de teléfono, fechas de nacimiento, etc.
  • No debe formar parte de un diccionario.
  • No debe estar escrita en ningún sitio, solo debe residir en nuestra memoria y por supuesto, nunca, pero nunca, nunca, deberíamos comunicársela a otra persona.

Si tenemos dudas de lo buena que es, existen comprobadores como este

Si estamos interesados en mejorar nuestra seguridad digital, además, deberemos exigir, configurar y utilizar mecanismos MFA además de cambiar, periódicamente, de contraseña.

¡Ah! Y cuidado con los mecanismos de recuperación de contraseñas. Si la fortaleza de nuestra identidad recae en un elemento, debemos fortificar lo.

PD: Si no queremos calentarnos la cabeza, siempre podemos usar una aplicación de gestión de contraseñas. Haberlas, haylas…


Fortificando el acceso con SSH: 2FA con Google Authenticator

Como comentaba al final de la entrada anterior, quien disponga de un hosting propio al que se conecte con sesiones de trabajo también debería estar interesado en fortificar este acceso utilizando un mecanismo 2FA en el servicio SSHGoogle Authenticator es una buena opción, entre otros argumentos, nos centraliza en la misma herramienta el acceso a múltiples servicios: los de Google, Redes Sociales,…

Para el caso que nos ocupa, debemos, para CentOS:

  • Instalar en el servidor el software necesario para la autenticación.
yum install pam-devel make gcc-c++ wget 
wget http://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2
tar xvf libpam-google-authenticator-1.0-source.tar.bz2 && cd libpam-google-authenticator-1.0
make
sudo make install
  • Este sistema está basado en el tiempo y, por tanto, debemos asegurarnos que la fecha y hora de nuestros sistemas estén sincronizadas. Es un paso MUY IMPORTANTE y, si no lo hacemos, NO FUNCIONARÁ. Para ello, debemos instalar el servidor ntp y configurarlo para que se sincronice con algún servicio accesible desde nuestra red:
yum install ntp
En el fichero /etc/ntp.conf añadimos la información de nuestro servidor de tiempos: server servidor_ntp
service ntpd start
  • Ejecutamos google-authenticator con el usuario que queremos proteger (no tienen que ser todos) Nos generará un enlace al sitio de Google donde encontraremos el código QR con el que debemos, en nuestro móvil y con la app Google Authenticator, crear una cuenta para nuestro acceso SSH igual que comentamos en la entrada anterior para WordPress. Además, nos proporcionará los códigos de un solo uso que debemos usar cuando no tengamos disponible dicha app.
  • Además de la ejecución, deberemos responder a 4 preguntas: mejor ‘Y’ a todas ;).
    • Con la primera, le estamos indicando que queremos que los tokens estén basados en el tiempo y que actualice el fichero HOME/.google_authenticator que es donde almacenará información importante como el enlace y los código mencionados en el punto anterior.
    • En la segunda nos pregunta si queremos deshabilitar el uso del mismo token por diferentes usuarios
    • En la tercera nos indica el tiempo por defecto (30″) para compensar posibles diferencias temporales entre cliente y servidor
    • Y en la última, limita el número de intentos a 3 cada 30″ para evitar ataques de fuerza bruta
  • En el siguiente paso, debemos configurar el módulo PAM del servicio SSH. En el fichero /etc/pam.d/sshd debemos añadir
auth   required  pam_google_authenticator nullok secret=/home/${USER}/.google_authenticator

nullok permite que los usuarios para los que no tengamos configurado el segundo factor de autenticación, puedan entrar al sistema sin solicitarles el código. Con secret le indicamos dónde está el fichero con la información de autenticación.

  • En el fichero /etc/ssh/sshd_config debemos activar (escribir  YES) la opción ChallengeResponseAuthentication.
  • También debemos asegurarnos, en el mismo fichero, que esté UsePAM yes y PubKeyAuthentication no
  • Y finalmente, reiniciar el servicio ejecutando:
service sshd restart

Existen más opciones que nos pueden interesar para afinar el sistema 2FA. Por ejemplo una idea es que cuando accedamos desde determinados sitios (nuestra red local), no nos solicite el segundo factor. Esto se consigue con la instalación (si no está ya) del módulo pam_access y configurando las PAM:

auth [success=1 default=ignore] pam_access.so accessfile=/etc/security/access-local.conf
auth       required     pam_google_authenticator.so nullok secret=/home/${USER}/.google_authenticator

Además, en el fichero /etc/security/access-local.conf debemos escribir algo parecido a esto (donde 10.0.0.0/24 es la red local):

# only allow from local IP range
+: ALL :10.0.0.0/24
+: ALL : LOCAL
-: ALL : ALL

Si queremos que el 2FA NO se aplique a los usuarios de un grupo determinado:

auth [success=1 default=ignore] pam_succeed_if.so user ingroup sudo
auth       required     pam_google_authenticator.so nullok secret=/home/${USER}/.google_authenticator

Si quisiéramos que se aplicara solo a ese grupo, basta con sustituir «user ingroup» por «user notingroup»

La información de esta entrada sirve también para proteger otros servicios de sesión de usuario como login, su, sudo, lightdm

¡Espero que os sea útil!

Referencias

  1. https://code.google.com/p/google-authenticator/wiki/PamModuleInstructions

 


Fortificando la autenticación de usuarios en WordPress

Al margen de la elección de contraseña, es una opinión, y cada vez más generalizada, que para aumentar la seguridad en la autenticación de los usuarios, debemos recurrir a sistemas MFA (Multi-Factor Authentication). Estos sistemas consisten en incluir diferentes factores de autenticación (2 o más): uno basado en algo que conocemos (por ejemplo, el clásico de la contraseña); otro en algo que poseemos (el móvil, por ejemplo) y/o algo que solo es el usuario (por ejemplo, su huella o cualquier característica biométrica).

Si queremos mejorar la seguridad de nuestro blog, existen pluggins que implementan un mecanismo 2FA (doble factor de autenticación) basado en Google Authenticator. En este blog estoy probando: WP Google Authenticator.

Es muy fácil de utilizar:

  1. Lo instalamos (Plugins>Añadir Nuevo y tras esto: Activar)
  2. Tras este proceso, en Ajustes, tendremos las opciones del plugin. En mi caso activé que el número máximo de veces que se puede autenticar un usuarios sin 2FA sea de 3)
  3. En Usuarios>Tu Perfil, abajo aparece información importante. Por un lado, el botón Get QR Code al que pulsaremos para obtener el código QR  sincronizará la aplicación Google Authenticator de nuestro móvil con el plugin. Para esto:
    • Arranqueremos en nuestro móvil Google Authenticator,
    • En Menú: Configurar Nueva cuenta,
    • Escanear código ¡et voila!
  4. Además en Usuario>Tu perfil tendremos el código de recuperación y tu clave secreta que no debes compartir con nadie.

Ahora, cada vez que queremos acceder al control de nuestro WordPress, nos encontraremos con:

Captura de pantalla de 2014-07-30 12:57:32

Quien disponga de un hosting propio al que se conecte con sesiones de trabajo que quiere fortalecer, también podemos utilizar Google Authenticator para implementar  un 2FA en el servicio SSH. Esto, en otra entrada que publicaré en breve 😉


Mecanismos de comunicación entre procesos (y V)

En esta última entrada dedicada a los mecanismos IPC veremos las tuberías con nombre o FIFO (First in, First out). El mecanismo se basa en abrir y utilizar el fichero nombrado igual que haríamos con cualquier otro fichero ordinario, donde unos procesos lo abren en modo lectura y otros en modo escritura.

Un ejemplo de proceso lector:

#include <fcntl.h>
#include <stdio.h>
#include <sys/stat.h>
#include <unistd.h>
#define MAX_BUF 1024
int main(){
 int fd;
 char *procPipe = "/tmp/fifo";
 char msj[MAX_BUF];
 /* Open the file*/ 
 fd = open(procPipe,O_RDONLY);
 /* We read the message*/
 read(fd,msj,MAX_BUF);
 /*We show the read message*/ 
 printf("Received message: %sn",msj);
 /* We close the named pipe*/
 close(fd);
return 0;
}

Un ejemplo del escritor:

#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
int main(){
 int fd;
 char *procPipe = "/tmp/fifo";
/*we make de FIFO file*/
 mkfifo(procPipe,0666);
 /*We open the file */
 fd = open(procPipe,O_WRONLY);
 /*We write the message*/ 
 write(fd,"Writer process messagen",sizeof("Writer process messagen"));
 /* We close the named pipe*/
 close(fd);
 /*We delete pipe*/
 unlink(procPipe);
 return 0;
}

Referencias:

  1. Advanced Linux Programming, de Mark Mitchell, Jeffrey Oldham y Alex Samuel

 

 


Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.