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 😉


Super User DO

SuDO es una herramienta que, como comentamos en esta entrada anterior, nos permite realizar una buena gestión de privilegios e implementar una administración compartida de los sistemas. En general, lo que nos permite es ejecutar las órdenes deseadas con los identificadores de usuario (UID y EUID) y grupo (GID y EGID) necesarios para su correcta ejecución, no es necesario que sea solo para  root. En el caso (bastante deseable) de que se necesite autenticar al usuario, esta acción se realizará con la contraseña del usuario que ejecuta la orden y no con la del usuario objetivo (es decir, NO con la de root).

La instalación es sencilla (sistemas Debian):

apt-get install sudo

Para la configuración: /etc/sudoers

Este es un fichero de texto en el que, cada línea, debe seguir la siguiente sintaxis:

[usuario/%grupo] [equipo] = [(id:gid del usuario objetivo)] órdenes

También admite alias con esta sintaxis:

alias nombre = elemento_alias

Los alias pueden ser de órdenes: Cmnd_Alias para lista de órdenes; User_alias para listas de usuarios; Host_alias, para listas de equipos

Un ejemplo de /etc/sudoers que usamos en la EPS es:

Cmnd_Alias CMDADMIN = /sbin/shutdown, /etc/init.d/sshd, /etc/init.d/network, /etc/init.d/rsysklog, /etc/init.d/nscd, /etc/init.d/tomcat, /etc/init.d/httpd, /etc/init.d/apache2
User_Alias USRWWWDATA = www-data, wwwadm
USRWWWDATA ALL= NOPASSWD: CMDWWWDATA

En este ejemplo se han definido 2 alias: CMDADMIN con la lista de comandos que van a poder ejecutar los usuarios listados en USRWWWDATA.

La última línea habilita la ejecución de las órdenes listadas en CMDWWWDATA por los usuarios definidos en USRWWWDATA como si las estuviera ejecutando el usuario root (no pone usuario objetivo por lo que es root). La expresión “como si las estuviera ejecutando” es una forma de expresarme. Como he comentado antes, la ejecución es con UID, EUID, GID y EGID de root (para este caso, en otros, con el del usuario objetivo.

De esta forma, los usuarios wwwadm y www-data pueden parar, reiniciar, lanzar Apache, Tomcat, nscd, ssh,… sin necesidad de conocer la contraseña del administrador.

También podríamos usar la directiva Defaults con la que podríamos definir determinadas opciones globales de comportamiento de sudo. Un uso interesante es:

Defaults env_reset, timestamp_timeout=1,passwd_timeout=2,passwd_tries=1

que implica que los usuarios tendrán:

  • Un solo intento de autenticación (passwd_tries=1),
  • tiempo de sesión sin solicitar de nuevo la contraseña de 1 minuto (timestamp_timeout=1),
  • timeout de 2 minutos.

Con la opción env_reset lo que se pretende es eliminar todas las variables de entorno del usuario salvo LOGNAME, SHELL, USER, USERNAME, MAIL y las de SUDO_*

Referencias:

  1. man 8 sudo
  2. man 5 sudoers
  3. Hardening de servidores GNNU/Linux, Carlos Álvarez Martín y Palo González Pérez, 0xWord, 2013

Administración de sistemas compartida

En mis clases de Administración de sistemas operativos en Red me gustaba recalcar, dentro del tema de gestión de usuarios, la importancia del usuario administrador (root) y cómo llegar a serlo. Su importancia radica, como sabemos, en que es el encargado de la ejecución de las tareas de administración, instalación, configuración, monitorización y seguridad de los sistemas de tal forma que, en infraestructuras de cierto tamaño, es fácil que existan varios administradores.

En estas circunstancias ¿cómo se reparten el trabajo? ¿por equipos/servidores? Y si el responsable de un servidor no está, ¿el resto se desentiende?  Para responder a esta última pregunta como un equipo profesional, debemos permitir la administración compartida y colaborativa  entre varios administradores y que puedan, cualquiera de ellos, administrar (ejecutar tareas de un administrador) un mismo sistema.

Una manera es conociendo todos la contraseña de root. En mi opinión no es una buena opción ya que diluye la responsabilidad. En GNU/Linux existe una utilidad que nos permite, precisamente, obtener las bondades mencionadas anteriormente sin necesidad de que todos los administradores conozcan la contraseña de root: sudo.

El uso de sudo tiene las siguientes ventajas:

  • Alta contabilidad: se registra las órdenes y quién las ejecutó en los registros de eventos del sistema (los logs)
  • Como ya he comentado: se limita el conocimiento del passwd de root a una única persona y sin limitar la labor de los operadores, por ejemplo, a los que les podemos dar autorizaciones concretas.
  • No se necesitan establecer sesiones de trabajo de root.
  • Los privilegios pueden ser revocados cuando se necesite.
  • Tenemos una lista de todos los usuarios con privilegios de root y qué es lo que pueden hacer con esta responsabilidad (está en la configuración del comando).
  • Las restricciones de acceso son dependientes del host, un fichero simple puede ser usado para el control de acceso a una entidad de red.

Como no es oro todo lo que reluce, también tenemos varias desventajas:

  • Una brecha en la seguridad de la cuenta de usuarios es equivalente a una brecha en la de root (para las acciones autorizadas)
  • Una mala configuración, como es el uso de path relativos para describir las órdenes autorizadas, puede provocar problemas debido a engaños con ejecuciones del “programas no controlados” como si fuera un programa permitido. Se arregla con el uso sin path absolutos en las configuraciones.

Para utilizarlo, debemos instalarlo y configurar el fichero /etc/sudoers, pero esto, será otro día…

 


Autenticación con LDAP en Alfresco

En /opt/alfresco-4.2.f/tomcat/shared/classes/alfresco-global.properties debemos añadir la cadena de conexión del LDAP:

authentication.chain=ldap1:ldap,alfrescoNtlm1:alfrescoNtlm

Una recomendación es dejar, como última cadena alfrescoNtlm1:alfrescoNtlm para la autenticación nativa de Alfresco*.

Después debemos configurar el acceso a nuestro directorio para lo que necesitamos un fichero con los valores de LDAP. Para ello podemos partir de uno existente ejecutando la orden**:

sudo cp $ALFRESCO_DIR/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/Authentication/ldap/ldap-authentication.properties 
$ALFRESCO_DIR/tomcat/shared/classes/alfresco/extension/subsystems/Authentication/ldap/ldap1/ldap-authentication.properties

En mi caso, el valor de $ALFRESCO_DIR es el directorio por defecto en la instalación /opt/alfresco-4.2.f/

En el fichero copiado: $ALFRESCO_DIR/tomcat/shared/classes/alfresco/extension/subsystems/Authentication/ldap/ldap1/ldap-authentication.properties

podemos configurar el uso y conexión al sevidor LDAP. Si solo queremos autenticar, debemos insertar las líneas:

  • ldap.authentication.active=true
  • ldap.authentication.userNameFormat=uid=%s,dc=midominio,dc=dominio_primer_nivel
  • ldap.authentication.java.naming.provider.url=ldap://servidorLDAP.midominio.es:puerto

Si no queremos sincronizar la información de los usuarios y grupo: ldap.synchronization.active=false

Para que el sistema funcionara con cierta seguridad, deberíamos configurar la conexión bajo SSL. Otra opción es que la comunicación entre el servidor Alfresco y el directorio se realice por un túnel cifrado con, por ejemplo, IPSec y, en este caso, desde el punto de vista del servicio, no tenemos que hacer nada más.

Por último, que no se nos olvide desactivar el usuario invitado. En el mismo fichero de configuración del LDAP: ldap.authentication.allowGuestLogin=false

*Para desactivar los accesos anónimos/invitados también en la autenticación nativa de Alfresco, en el fichero $ALFRESCO_DIR/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/Authentication/alfrescoNtlm/alfresco-authentication.properties

alfresco.authentication.allowGuestLogin=false

** Es posible que tengas que crear algunos subdirectorios intermedios. Yo lo tuve que hacer.

Referencias:

  1. Información sobre los subsistemas de Alfresco: http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems
  2. Configurando LDAP: http://docs.alfresco.com/4.1/concepts/auth-ldap-intro.html

 


¿Estamos bajo un ataque DoD o DDoS?

Esta tarde he estado leyendo esta entrada (y a la que le “he robado el título”). Como bien comenta el autor, una de las características que un ataque de denegación de servicio (DoS) presenta, ya sea distribuido o no, es el gran número de conexiones que recibirá nuestro sistema. En esta entrada, podéis consultar una serie de órdenes de shell que nos permiten obtener información sobre las conexiones de nuestro servidor y, en función de ésta, detectar un posible ataque.

Algo parecido hace el guión de Python que os copio debajo. Si le introducimos uno de los estados en los puede estar una conexión, nos indica, para cada IP que ha establecido contacto con nuestro servidor, cuantas conexiones están en ese estado (y para cualquier puerto). El guión da para mucho y, evidentemente, también para detectar situaciones anómalas en las que tenemos muchas conexiones “SYN_REC” que denotaría un posible DoS (o DDoS, dependiendo del número de IPs) e, incluso, un posible escaneo de puertos.

#!/usr/bin/python
#encoding:utf-8
try:
 import optparse, sys, re, socket
except:
 print("Error executing 'import optparse, sys, re, socket' command")
 exit(1)
try:
 import socket
 from socket import AF_INET, SOCK_STREAM, SOCK_DGRAM
 import psutil
 from psutil._compat import print_
except:
 print "Error importing socket & psutil module. It is possible you need running 'apt-get install python-psutil'"
 exit(1)
def main():
 parser = optparse.OptionParser("usage%prog " + "-s <state>")
 parser.add_option('-s', dest = 'state', type = 'string', help = 'Please, specify the connection state to analize', default="ESTABLISHED")
 (options, args) = parser.parse_args()
 ipConnected = { }
 for conn in psutil.net_connections(kind='inet'):
 if conn.status == options.state:
 ip=conn.raddr[0]
 if (ip in ipConnected):
 ipConnected[ip]= ipConnected[ip]+1
 else:
 ipConnected[ip]=1
 print "Remote IPtt|# " + options.state + " connections"
 print "---------------------------------"
 for ip in ipConnected.keys():
 print "%stt|%s" % (ip, str(ipConnected[ip]))
if __name__ == '__main__':
 main()

El guión admite muchas mejoras. Por ejemplo, y para el caso comentado, poner un límite a partir del cual nos avise o active un filtro para esa IP. También podríamos comprobar lo mismo, pero solo para un servicio (puerto) determinado y que podríamos introducir como parámetro de entrada.

¡Espero que os sea útil!

 


IGMP: tráfico multicast y filtros

Cuando diseñamos una red una de las tecnologías/infraestructuras que planificaremos será la instalación de un cortafuegos*. En estas circunstancias tenemos que tener claro qué paquetes dejamos pasar, cuales desechamos, y todo en función de nuestra política de seguridad y sin perder la funcionalidad para la que estamos diseñando nuestra red.

Si utilizamos OSPF o, en general, si queremos manejar tráfico multicast, debemos habilitar los paquetes IGMP en nuestros filtros (suponiendo que tenemos la estrategia de denegar todo lo que no está explicitamente habilitado) ya que es el protocolo que utilizaran hosts y routers para establecer los miembros de los grupos de multicast. De este protocolo, debemos tener en cuenta, sobre todo, que se encapsula en datagramas IP con el número 2 de protocolo (esto implica que NO utiliza UDP ni TCP ni, por tanto, tiene puertos). Otro detalle que debemos tener en cuenta es que el TTL de los paquetes de IGMP, por defecto, es 1, lo que implica que no “atravesarán” los routers y no saldrán de la subred en la que se genera, aunque puede aumentarse para localizar servidores lejanos utilizando este campo como “barrera” y configurando los routers para que sean transparentes y no decrementen el TTL**.

La ejecución de las siguientes órdenes provocará que nuestro router de filtrado acepte y saque mensajes IGMP:

iptables -A INPUT -p igmp -j ACCEPT
iptables -A OUTPUT -p igmp -j ACCEPT

Para el caso de los grupos multicast relacionados con OSPF que comentábamos en la entrada anterior, podríamos limitar las reglas habilitando solo los grupos relacionados con OSPF:

iptables -A INPUT -p igmp -d 224.0.0.5 -j ACCEPT
iptables -A INPUT -p igmp -d 224.0.0.6 -j ACCEPT
iptables -A OUTPUT -p igmp -d 224.0.0.5 -j ACCEPT

Referencias

  1. Building Internet Firewalls, de Elizabeth D. Zwicky, Simon Cooper y D. Brent Chapman
  2. https://tools.ietf.org/html/rfc3376, RFC para IGMP versión 3
  3. http://tools.ietf.org/html/rfc2236, RFC para IGMP versión 2

* Prefiero usar el concepto de cortafuegos para la infraestructura de protección de red que diseñamos y que puede estar compuesta por varios elementos donde, uno de ellos, el dispositivo de red que filtra paquetes y que -casi- todo el mundo denomina cortafuegos, yo prefiero denominarlo router de filtrado.

** Una orden genérica para este caso es: iptables -A FORWARD -p igmp -j ACCEPT Si queremos, por ejemplo, especificar que el tráfico que queremos es el relacionado con el audio/vídeo: iptables -A FORWARD -p udp -m udp -d 239.0.0.0/16 –dport 5001 -j ACCEPT

 


Filtros de red para OSPF (Open Shortest Path First)

Si en nuestros routers utilizamos la estrategia de denegar todo por defecto y permitir expresamente lo que deseamos, en el caso de que estos equipos tengan configurado que aprendan sus rutas con OSPF, debemos habilitar dicho protocolo. Para ello, debemos tener en cuenta que OSPF

  • se encapsula en datagramas IP con el número 89 de protocolo (esto implica que NO utiliza UDP ni TCP ni, por tanto, tiene puertos),
  • usa tanto paquetes multicast (los grupos 224.0.0.5 y 224.0.0.6 y lo que nos obliga a configurar, usar y habilitar en nuestros filtros IGMP*) como unicast,
  • el TTL de sus paquetes es 1, por lo que no atravesarán un cortafuegos, salvo que configuremos un túnel (http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml),
  • y por último, dispone de un identificador de tipo de paquete (nos permite mejorar las reglas, aunque dependemos del software de filtrado).

Con iptables, la forma más fácil es ejecutar las siguientes ordenes**:

iptables -A INPUT -p 89 -j ACCEPT
iptables -A OUTPUT -p 89 -j ACCEPT

Si queremos ser más “finos”, debemos indicar las IPs de origen, destino y, si lo permite el software de filtrado, el tipo de paquete de OSPF. Las reglas en este caso***:

#hello ospf between rt_ext and rt_int
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
#database description, link state request, asking for information about a particular link and request/update link state
iptables -A INPUT -s rt_ext -d rt_int -p 89 -j ACCEPT
iptables -A OUTPUT -d rt_int -s rt_int -p 89 -j ACCEPT
#link state update, flooding all link states from rt_ext router
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
#rt_int router link state update from rt_ext router
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT

Referencias

  1. Building Internet Firewalls, de Elizabeth D. Zwicky, Simon Cooper y D. Brent Chapman

* Es muy sencillo, pero lo dejo para otra entrada 😉

**Estamos considerando que NO queremos reenviar (forward). Si quisiéramos hacerlo, ver el punto 3 de las consideraciones de OSPF que he escrito en la entrada. Además, estas reglas deben ejecutarse en los routers designados.

***Las reglas se deben de ejecutar en los router afectados (en rt_ext cuando ‘-s rt_ext’ o en rt_int si ‘-s rt_int’), salvo que dispongamos de un cortafuegos específico y, en ese caso, se ejecutan todas en él. Recordad que debe disponer de un túnel (ver **)


¿Hay algo que no pueda hacer root?

Pues si y no. Y no es por quedarme con el personal. Es que, directamente, hay cosas que NO puede hacer, aunque siempre puede buscar otro camino para conseguirlo.
Si empezamos con los ficheros y sus permisos y atributos, nos encontramos con:

  • Si un fichero está protegido ante cambios (atributo inmutable ‘i‘), root no podrá escribir en él (ver imagen).
  • Si un fichero está protegido con el atributo ‘a‘, solo “crece”, añade contenido y root no podrá borrar datos de él.

Captura de pantalla de 2014-04-14 22:55:50

Aunque, en ambos casos, siempre podrá quitar el atributo, independientemente de a quien pertenezca el fichero y hacer lo que considere.

Además, si queremos desmontar un sistema de archivo (FS) que está siendo utilizado, por ejemplo, porque un proceso que tiene abierto un fichero de este FS, root no podrá desmontarlo. Para conseguir su objetivo deberá, para el ejemplo, buscar qué proceso tiene abierto el fichero (lsof le ayudará), pararlo (kill)y, entonces, podrá desmontar el FS. Si, por otra parte, este FS es de solo lectura (porque se ha montado así, y no porque sea un CD-R), root no podrá escribir o hacer cualquier cambio en él aunque, para lograrlo, podrá

  • acceder directamente al dispositivo
  • remontarlo como RW

Por otra parte las contraseñas de los usuarios se guardan cifradas en el sistema por lo que root no conoce las contraseñas de los usuarios, aunque siempre podrá:

  • emplear mecanismos de fuerza bruta, no hay que olvidar que tiene acceso a la contraseña cifrada,
  • emplear mecanismos que la obtengan (captura de pulsaciones del teclado,…) ya que tiene acceso a todo el sistema,
  • cambiarla por otra…

Y por último, una acción que tampoco podrá hacer root es parar un proceso que entre en modo de espera en el núcleo (aunque sí que podrá parar TODO el sistema, que para chulo,…)

Referencias:

  1. Administración de sistemas operativos Windows y Linux. Un enfoque práctico, de Juan Antonio Gil, Julio Gómez y Nicolás Padilla.
  2. Linux system Administration, de Tom Adelstein y Bill Lubanovic

Sistema de archivo remoto accesible mediante SSH

Si queremos compartir o acceder a un directorio de un equipo al que ya accedemos mediante SSH, una buena opción es usar el mismo servicio (ssh) para conseguir este objetivo. Para ello necesitamos:

  • Que el núcleo incluya FUSE. Si no lo está: basta con instalar fuse-source e instalarlo con module-assistant.
  • Que el usuario local pertenezca al grupo fuse.
  • Instalar sshfs: apt-get install sshfs.
  • Tener correctamente configurado el servidor SSH en el equipo en el que queremos montar el directorio.

Hecho lo anterior ya podemos montar cualquier directorio y utilizarlo en nuestro equipo como si fuera un directorio local. La orden debería seguir el patrón:

sshfs [email protected]_del_sevidor:<directorio a exportar> <directorio local>

  • usuario será el del servidor al que tenemos que acceder,
  • ip del servidor en el que se encuentra el directorio a exportar,
  • y directorio local será el punto de montaje a partir del cual estarán disponibles los ficheros del directorio exportado del servidor desde el punto de vista del “cliente”

Si queremos que esté disponible en el arranque, tenemos que configurar el montaje en el fichero /etc/fstab. Para ello, debemos añadir una línea al fichero /etc/fstab que siga la siguiente sintaxis:

sshfs#[email protected]:<directorio a exportar>   <directorio local>   fuse   defaults 0 0

  • donde, al igual que con la orden dada anteriormente, tenemos que indicar el usuario del servidor con el que debemos conectarnos para acceder al directorio, el directorio y el punto local de montaje.
  • Aquí debemos indicar también el tipo de sistema de archivo (fuse). Como opciones de montaje podemos dejar las “defaults” o utilizar cualquier otra de las que disponemos (ro, rw, nosuid, async, noexec, noauto, …).
  • El penúltimo campo (dump) indica si se quiere o no realizar un volcado de los errores (0 ó 1) .
  • El último indica si no queremos (0) realizar un chequeo del sistema de archivos o y, en este caso, 1, 2, marcará el orden en el serán comprobados*. En nuestro caso, creo que es mejor usar la opción 0 y no chequear (ya lo haremos, en todo caso, en el propio servidor donde se encuentra el directorio).

Una vez introducida la línea en /etc/fstab, para probarla sin necesidad de reiniciar, podemos ejecutar mount -a.

Debemos tener en cuenta que si queremos montar automáticamente en el arranque, lo más lógico es autenticar mediante clave pública** para que se monte correctamente en el inicio del equipo y que no tenga que pedirnos la contraseña, además de guardar la clave pública del servidor en el fichero known_hosts de ssh para que no solicite confirmación.

Para desmontar/desasociar el directorio, debemos ejecutar la orden

 fusermount -u directorio_local

¡Ojo! Este mecanismo NO te cifra el directorio. Te da privacidad en la comunicación estableciendo una conexión cifrada. ¡Y tampoco lo puedes usar con Dropbox!

Todas las técnicas de protección que usemos para el servidor SSH, influirán positivamente en la seguridad de nuestro “servicio de disco”, pero esto, lo dejamos para otro día.

Referencias:

  1. Hardening de servidores GNU/Linux, de Carlos Álvarez Martín y Pablo González Pérez
  2. Administración de sistemas operativos Windows y Linux. Un enfoque práctico, de Juan Antonio Gil, Julio Gómez y Nicolás Padilla.

* Normalmente se utiliza 1 para el sistema de archivos raíz, 2 para el resto. La comprobación, por defecto, se realiza cada 29 desmontajes y se puede modificar por sistema de archivo (ver la orden tune2fs).

** Debemos copiar la clave pública de los usuarios al servidor (la podemos generar mediante la orden ssh-keygen) en la ruta que esté indicada por la directiva AuthorizedKeysFile del fichero /etc/ssh/sshd_config Por defecto, indica que está en el directorio HOME del usuario ($HOME/.ssh/authorized_keys) Es importante para la automatización, que NO activemos un PIN a la clave privada.


Timeouts de TCP en GNU/Linux y opciones para “afinar” un servidor

Los tiempos de espera de TCP vistos en la entrada anterior se pueden consultar y modificar en GNU/Linux a través de los ficheros apropiados del /proc y, para afinar un servidor y mejorar sus prestaciones en base a estos timeout, podremos modificar sus valores en este sistema de archivos sin necesidad de recompilar el núcleo. Pero, antes de nada, si lo que queremos es afinar nuestro sistema, lo que debemos es de plantearnos es esta pregunta: ¿cuántos puertos concurrentes podemos tener abiertos? Para ello:

Leer más


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