Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas

Cursos de Hacking del MIT

Leer más

PoC local de CVE-2015-0235

Como pequeña prueba de concepto para explotación local, la Universidad de Chicago ha liberado un pequeño código escrito en c que permite comprobar de forma sencilla si tu equipo es vulnerable al fallo en la librería glibc y que afecta a la función gethostbyname. Puedes leer más acerca de este fallo aquí.
Por el momento, vamos a ver en qué estado se encuentra el equipo y en caso de que sea vulnerable, la recomendación es actualizar lo antes posible. El código en cuestión es el siguiente:
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  size_t len = sizeof(temp.buffer) -
               16*sizeof(unsigned char) -
               2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name,
                           &resbuf,
                           temp.buffer,
                           sizeof(temp.buffer),
                           &result,
                           &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}
Tras copiarlo en un fichero de texto plano, por ejemplo /tmp/test_ghost.c, debemos compilarlo. Siendo código c:
shell> gcc /tmp/test_ghost.c -o /tmp/test_ghost
Y ejecutándolo ya podemos comprobar si el sistema está o no afectado por la vulnerabilidad Ghost in Linux (CVE-2015-0235).
shell> /tmp/test_ghost 
vulnerable
En caso de que no esté, la salida será tal que así,
shell> /tmp/test_ghost 
not vulnerable
Leer más

Ghost in Linux (CVE-2015-0235)

Investigadores de la empresa Qualys han reportada una grave vulnerabilidad en la librería glibc
(biblioteca C de GNU Linux), que permite obtener un acceso no lícito al sistema sin la necesidad de usuario y contraseña.
Dicha vulnerabilidad ya está reportada y se ha identificado como CVE-2015-0235 y afecta a la mayoría de los sistemas ya que lleva 14 años ahí. Afecta a todos aquellos sistemas que tenga glibc-2.2 instalado, liberado en el año 2000! En mucho sitios ya comparan esta vulnerabilidad a heartbleed, que también movió cielo y tierra en su momento.
Las principales distribuciones GNU/Linux ya fueron notificadas de este bug antes de que se publicase, y ya hay parches al respecto para ellas.

Bug y explicación

Este fallo de seguridad afecta a la función gethostbyname, presente en glibc. Dicha función es usada en casi todos los sistemas Linux cuando se intenta acceder a otro equipo conectado en red. O dicho de otra forma, cuando se intenta resolver un nombre de dominio vía DNS.
El fallo se puede aprovechar si el atacante provoca un desbordamiento de buffer al usar un argumento hostname no válido. Es ahí cuando se permite ejecutar código arbitrario y con los permisos del usuario que está ejecutando DNS.
Qualys creó una prueba de concepto sobre un servidor Exim al enviarle un comando SMTP inválido. Un simple correo electrónico mal intencionado permite abrir una shell remota en el sistema.

Solución

Aplicar las actualizaciones de seguridad de los sistemas y reiniciar.

Más información




Leer más

Fail2ban: proteger servidor SSH

Fail2ban es una aplicación, escrita en Python, con la intención de prevenir la intrusión en nuestros sistemas por fuerza bruta. Para hacerlo, penaliza el bloqueo de conexiones remotas que intenten accesos por fuerza bruta. Trabaja conjuntamente con un sistema de firewall, por ejemplo IPTables y lo que realiza es una consulta constante de los ficheros de logs del sistema para detectar ataques de fuerza bruta. Si detecta uno, bloquea la IP por un tiempo limitado o permanentemente.
Actualmente Fail2ban tiene soporte de filtros para apache, ssh, qmail, vsftp, lighttp, postfix y courier mail. Cada uno de estos filtros es llamado "jail" y en realidad no es más que una tupla de filtro + acción.
Hoy, vamos a ver cómo proteger nuestro sistema de ataques por fuerza bruta a SSH con Fail2ban y para cambiar un poco las reglas, vamos a ver cómo hacerlo en un sistema CentOS.

Instalación

La instalación en CentOS es muy similar a la realizada en sistemas Debian, ya que ambos sistemas tienen el paquete disponible en sus repositorios. En el caso de CentOS, lo primero que debemos es instalar el repositorio EPEL.
shell> yum install epel-release
Y tras ello, ya podemos instalar Fail2ban.
shell> yum install fail2ban
Y nos garantizamos de que arranque al inicio del sistema,
shell> chkconfig fail2ban on

Configuración

Por defecto, Fail2ban trae la configuración de varios "jail" por defecto, que deberemos de eliminar o sobrescribir para tener el funcionamiento que nos interesa. El fichero de configuración a manejar es /etc/fail2ban/jail.conf y en él tenemos la sección [DEFAULT], que contiene los parámetros por defecto y genéricos y luego cada una de las tuplas de los servicios a monitorizar. Puesto que nos interesa tener el servicio SSH controlado, tenemos que definir el "jail" [ssh-iptables] y un ejemplo, puede ser el siguiente,
[DEFAULT]
ignoreip = 127.0.0.1 192.168.1.0/24
bantime = 86400
maxretry = 5
findtime = 600
mta = sendmail

[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=you@local.com, sender=ban@local.com]
logpath = /var/log/secure
maxretry = 3
Acorde con la configuración anteriormente descrita, si alguien intenta acceder más de 3 (maxretry) veces al servicio SSH en 10 minutos (findtime), la IP origen será automáticamente bloqueada por el servicio y estará bloqueada durante 1 día (bantime).
Con la configuración ya lista, lo que debemos es de arrancar el servicio.
shell> /etc/init.d/fail2ban restart

Prueba

Inicial

Lo primero es saber que el sistema está funcionando correctamente. Para ello existe el comando fail2ban-client que nos asegura que el servicio Fail2ban está iniciado y funcionando. Al llamarlo, la respuesta esperada si todo está correcto es la siguiente,
shell> fail2ban-client ping
Server replied: pong

Check Fail2ban Status

[ssh-iptables] emplea IPTables para realizar los bloqueos, por lo que, para comprobar su estado, lo podemos hacer directamente desde IPTables.
shell> iptables --list -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-SSH  tcp  --  0.0.0.0/0         0.0.0.0/0           tcp dpt:22 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-SSH (1 references)
target     prot opt source               destination         
DROP       all  --  172.16.0.92          0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
Aunque también el propio Fail2ban tiene su propio status interno para saber el estado de una "jail".
shell> fail2ban-client status ssh-iptables
Status for the jail: ssh-iptables
|- filter
|  |- File list: /var/log/secure 
|  |- Currently failed: 0
|  `- Total failed: 0
`- action
   |- Currently banned: 1
   |  `- IP list: 172.16.0.92
   `- Total banned: 1

Desbloquear IP bloqueada

Si ahora nos interesa desbloquear una IP bloqueada, lo podemos hacer directamente desde IPTables,
shell> iptables -D fail2ban-SSH -s 172.16.0.92 -j DROP
Y desde el interfaz de Fail2ban sería...
shell> fail2ban-client set ssh-iptables unbanip 172.16.0.92
Leer más

Seguridad en postfix: Deshabilitar VRFY

Hoy es uno de esos días en los que te dedicas a leer documentación y manual de servicios y descubres, como no podía ser de otra forma, parámetros cuando menos interesantes y que suelen ser olvidados. Este olvido puede traer, como veréis, problemas de revelación de datos que debemos de evitar. Hablamos, concretamente del parámetro verify de postfix. Este parámetro sirve para lo siguiente,
shell> telnet local.com 25
Trying 192.168.0.25...
Connected to mail.com.
Escape character is '^]'.
220 mail.local.com ESMTP Postfix
vrfy javier@local.com
252 2.0.0 javier@local.com
vrfy empty@local.com
550 5.1.1 empty@local.com: Recipient address rejected: local.com
exit

Creo que tras ver el ejemplo, ya os imagináis para qué sirve el comando vrfy de postfix. Sí, efectivamente, para poder averiguar si un usuario existe en el servidor o no. Como puedes comprender, crear un pequeño script que se conecte a un servidor de correo de un dominio y liste las cuentas de correo que éste tiene, muy complicado no resulta.
Por lo tanto, si queremos evitar que alguien se nos conecte al servidor y haga un descubrimiento de las cuentas de correo en él configuradas, debemos de ir al fichero de configuración de postfix (/etc/postfix/main.cf) y deshabilitar el uso del comando vrfy.
disable_vrfy_command = yes
Tras incluir la línea aquí arriba citada y reiniciar el servicio, si intentamos la conexión ya se nos advertirá de que no es posible.
shell> telnet local.com 25
Trying 192.168.0.25...
Connected to local.com.
Escape character is '^]'.
220 mail.local.com ESMTP Postfix
vrfy javier@local.com
252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
expn root
502 5.7.0 Sorry, we do not allow this operation
Leer más

SSL suma y sigue: Poodle

Este año 2014 va a ser para recordar en la historia de la seguridad informática, sin dudarlo. SSL (heartbleed), bash (CVE-2014-6271 y CVE-2014-7169), y ahora nuevamente el protocolo SSL vuelve a ser noticia con una vulnerabilidad crítica que afecta, por lo que parece, al diseño del protocolo SSL 3.0. El código de fallo es el CVE-2014-3566 y está ahí pues más o menos desde hace 15 años que vio la luz.
El problema está en que a día de hoy la mayoría de los navegadores todavía le dan soporte y por lo tanto son vulnerables. El fallo se puede explotar en un ataque MitM (man-in-the-middle) en el que se fuerce al cliente a emplear el protocolo 3 para así acceder a los datos sin cifrar aunque la sesión esté cifrada.
La solución pasa por deshabilitar el soporte de SSL 3.0 o usar cifrados CBC-mode para dicha versión. El problema de esto no son los navegadores en sí, sino el resto de programas que pueden no tener estas compatibilidades.
Otra de las soluciones recomendadas es habilitar TLS_FALLBACK_SCSV, un mecanismo que soluciona los problemas causados por reintentar conexiones fallidas, previniendo que los atacantes puedan 'obligar' a los navegadores a usar SSL 3.0.

Más información:

Leer más

Filtradas contraseñas de Dropbox

Dropbox, popular servicio de alojamiento de ficheros en la nube ha anunciado en su blog oficial que en el día de ayer se ha producido una importante filtración de contraseñas. Concretamente se está hablando de más de 7 millones de cuentas en riesgo. Actualmente Dropbox ha optado por bloquear aquellas cuentas donde detecten algún tipo de actividad extraña.
Here is another batch of Hacked Dropbox accounts from the massive hack of 7,000,000 accounts
To see plenty more, just search on [redacted] for the term Dropbox hack.

More to come, keep showing your support
Según lo que dicen, la filtración no se produjo por un fallo en sus servidores, sino en equipos de terceros.
Se recomienda el cambio inmediato de contraseñas así como la posibilidad de habilitar la verificación en dos pasos del servicio.

Más información:



Actualización:

Se están publicando en pastebin diferentes entradas con las credenciales robadas, por lo que es más importante el cambio de contraseña.
Leer más

Debian Squeeze LTS

Hace unos meses os hablé de que por fin Debian iba a tener una versión LTS (Long Term Support) y cómo activar dicho repositorio de seguridad. Puedes leer el artículo entero aquí.
Pues bien, hoy se dió a conocer una vulnerabilidad  que afecta a GNU/Linux, sí la de bash, de la que os hablaré con más detenimiento en otro momento. Quiero aprovechar para recordar que actualicéis.
Eso es lo más importante, un sistema actualizado es menos vulnerable. Aun así, si estáis empleando Debian Squeeze acordaros de incluir la línea de LTS en vuestro fichero sources.list y también, como recomendación instalar el paquete debian-security-support.
Lo primero será actualizar el sources.list, añadiendo lo siguiente,
deb http://ftp.debian.org/debian squeeze-lts main contrib
Para a continuación,
shell> apt-get update
shell> apt-get upgrade
Si no tenías este nuevo repositorio verás que se actualizan bastantes paquetes de interés, según la finalidad del sistema.

Aun así, no todos los paquetes incluidos en Debian Squeeze van a tener soporte LTS, sino que algunos terminarán por dejar de mantenerse. Para tener un listado de aquellos paquetes instalados en el equipo y que pueden no tener soporte, está el comando check-support-status. Para instalarlo,
shell> apt-get install debian-security-support
shell> check-support-status
Ended security support for one or more packages

Unfortunately, it has been necessary to end security support for some
packages before the end of the regular security maintenance life cycle.

The following packages found on this system are affected by this:

* Source:libplrpc-perl, ended on 2014-05-31 at version 0.2020-2
  Details: Not supported in squeeze LTS
  Affected binary package:
  - libplrpc-perl (installed version: 0.2020-2)

Limited security support for one or more packages

Unfortunately, it has been necessary to limit security support for some
packages.

The following packages found on this system are affected by this:

* Source:php5
  Details: See README.Debian.security for the PHP security policy
  Affected binary packages:
  - libapache2-mod-php5 (installed version: 5.3.3-7+squeeze21)
  - php5 (installed version: 5.3.3-7+squeeze21)
  - php5-cli (installed version: 5.3.3-7+squeeze21)
  - php5-common (installed version: 5.3.3-7+squeeze21)
  - php5-curl (installed version: 5.3.3-7+squeeze21)
  - php5-gd (installed version: 5.3.3-7+squeeze21)
  - php5-mysql (installed version: 5.3.3-7+squeeze21)

Tienes más información acerca de lo aquí comentado en howtoforge.com.
Leer más

SSH terminal in web

Hoy os voy a mostrar una pequeña forma de tener accesible un servidor SSH desde un navegador. Supongo que a muchos de vosotros esto no os servirá de nada y a otras muchos les será de gran ayuda. Hay veces que tener una conexión segura SSH es más complicado, sin embargo, tener un servicio vía web que se encargue de ser servidor SSH, pues nos vendrá bien.
Por supuesto, lo que voy a contar ahora simplemente facilita la conexión a una máquina, pero para nada garantiza su seguridad. Así que un control de accesos y un extra de seguridad nunca está demás.

Instalación

Lo primero de todo es instalar el software necesario que vamos a emplear. En este caso usaremos shellinabox, que se define a si mismo como una línea de comandos encapsulada en código AJAX.
Puesto que está disponible desde los repositorios oficiales,
shell> apt-get install openssl shellinabox

Configuración de shellinabox

Una vez tenemos todo instalado, ya está el servicio prácticamente listo para arrancar. Lo único que nos queda pendiente es establecer el puerto por defecto en el que vamos a querer que se ejecute. En mi caso lo voy a poner en el 443 (https). Para ello, editamos el fichero de configuración, /etc/default/shellinabox y lo dejamos como sigue.
SHELLINABOX_DAEMON_START=1
SHELLINABOX_PORT=443
SHELLINABOX_ARGS="--no-beep"
Es decir, la configuración por defecto, únicamente cambiando el puerto de escucha.

Configuración avanzada

La configuración por defecto la verdad es que funciona perfectamente y nos permite ya de por sí abrir una consola en el equipo que está haciendo de servidor. Sin embargo, si nos interesa abrir una consola en otro equipo de la red local, también lo podemos hacer directamente empleando shellinabox. Un ejemplo de configuración para ello sería,
SHELLINABOX_PORT=443

# specify the IP address of a destination SSH server
SHELLINABOX_ARGS="--o-beep -s /:SSH:192.168.0.70"
En donde establecemos que se abra un túnel SSH hacia el servidor con IP 192.168.0.70.

Arrancando servicio

Una vez tengamos ya todo configurado simplemente tendremos que arrancar el servicio.
shell> /etc/init.d/shellinabox start
Y ya podremos conectarnos con un navegador al puerto descrito y tener nuestra shell en el equipo.
shellinabox example
shellinabox example

Certificado SSL

Por cierto, shellinabox trae por defecto un certificado autofirmado, pero lógicamente podemos crear nuestro propio certificado si así tenemos más confianza.
shell> cd /var/lib/shellinabox
shell> openssl genrsa -des3 -out server.key 1024
shell> openssl req -new -key server.key -out server.csr
shell> cp server.key server.key.org
shell> openssl rsa -in server.key.org -out server.key
shell> openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
shell> cat server.crt server.key > certificate.pem
Y con ello podemos conseguir, por ejemplo, que el certificado SSL que nos muestre sea de confianza para nuestro navegador, tras importar los certificados pertinentes, lógicamente.

Para más información acerca del servicio empleado o de cómo usarlo puedes ir a su página oficial o leer la página del manual en cuestión.
Leer más

Capturar tráfico HTTP

Aunque cualquier sniffer actual puede capturar el tráfico HTTP sin problemas, quizás el gran problema es que captura más cosas de las que suelen interesar. Aunque efectivamente existen filtros para que recoja únicamente lo que interesa, quizás opciones como tcpdumpwireshark sean más complejas que httpry, un software que únicamente sirve para capturar todo el tráfico HTTP, pero de forma muy organizada. Apoyándose en libpcap, misma librería que tcpdump, trae ya por defecto todos los códigos y protocolos del tráfico web, por lo que configurarlo resulta mucho más sencillo. Vamos a ver cómo funciona.

Instalación de httpry

httpry está disponible en las principales distribuciones GNU/Linux, por lo tanto para sistemas Debian y derivados...
shell> apt-get install httpry
Y para sistemas Red Hat y familiares,
shell> yum install httpry

Uso básico

Tras finalizar la instalación, la cual es realmente sencilla, ya podemos ponernos a jugar con la nueva herramienta. Lo único que necesitamos es indicarle sobre qué interfaz de red queremos que trabaje capturando el tráfico.
shell> httpry -i eth0
httpry version 0.1.7 -- HTTP logging and information retrieval tool
Copyright (c) 2005-2012 Jason Bittel jason.bittel@gmail.com
----------------------------
Hash buckets:       64
Nodes inserted:     10
Buckets in use:     10
Hash collisions:    0
Longest hash chain: 1
----------------------------
Starting capture on eth0 interface
2014-08-16 16:14:35   108.160.167.160  192.168.0.15    <  -    -  -  HTTP/1.1  200  OK
2014-08-16 16:14:35   192.168.0.15     108.160.167.160 >  GET  notify10.dropbox.com   /subscribe?host_int=
2014-08-16 16:14:48   192.168.0.15     173.194.41.250  >  GET  pagead2.googlesyndication.com... -
2014-08-16 16:14:48   173.194.41.250   192.168.0.15    <  -    -  -  HTTP/1.1  200  OK
2014-08-16 16:14:48   173.194.41.250   192.168.0.15    <  -    -  -  HTTP/1.1  200  OK
2014-08-16 16:15:03   192.168.0.15     173.194.34.252  >  GET  ad.doubleclick.net...
2014-08-16 16:15:03   173.194.34.252   192.168.0.15    <  -    -  -  HTTP/1.1  200  OK
...
Como se puede observar, desde el momento del arranque ya comienza a capturar tráfico HTTP y aparecen todas las peticiones que se hacen, así como el método que se emplea. Sale la IP origen de la conexión, así como la IP destino de la misma, seguida del método empleado y la URL completa que se envía o recibe.
Esto mismo lo podemos hacer con tcpdump o similares, pero la expresión necesaria para este filtro ya hace que quizás alguna persona se lo piense. Con httpry es muy sencillo.

Uso avanzado

Por supuesto, httpry permite hacer muchas cosas más. Algunas de las cuales vamos a ver a continuación, pero para saber todo su potencial os recomiendo la lectura de su página man.

Capturando métodos específicos

Los que sepáis del protocolo HTTP sabréis que existen multitud de métodos (POST, GET, HEAD, CONNECT, etc.) que éste tiene implementado. Algunos más vulnerables, otros menos. httpry nos permite definir qué método queremos que nos muestre, para así evitarnos tener que leer líneas que no nos van a ser de utilidad.
shell> httpry -i eth0 -m get,post

Captura a fichero para luego procesarlo

También, una de las utilidades más importantes es que la captura y el análisis de la misma no tiene por qué realizarse al mismo tiempo. Esta es una gran utilidad, puesto que nos permite almacenar todo el tráfico para su posterior análisis, con mucha más tranquilidad. Lo primero es, por supuesto, capturar el tráfico de red. Lo podemos hacer en formato binario (opción -b), o en formato texto (opción -o).
shell> httpry -i eth0 -b capture.dump
Una vez tengamos todo el tráfico capturado es hora de procesarlo. Para ello,
shell> httpry -r capture.dump

Esta entrada puede ser muy útil para análisis de tráfico, pero también para que mucha gente vea la facilidad con la que es posible capturar tráfico HTTP y leer lo que pasa por la red. Así que ya sabéis, no facilitéis tarjetas de crédito, contraseñas y demás datos de interés personal si, mínimo, no hay un https en la URL.
Leer más

arpWatch: Controlando los equipos de tu red

arpWatch es un daemon para sistemas GNU/Linux que nos permite de forma rápida tener un sistema de notificación de nuevos equipos conectados a la red. En realidad este pequeño daemon se dedica a observar el listado de correspondencias entre las entradas de la tabla arp y la dirección origen para comprobar su correspondencia. En el momento que un nuevo equipo es conectado a la red, automáticamente se notifica al administrador de ello vía correo electrónico.
arpwatch está en los repositorios de las principales distribuciones, por lo que su instalación resulta sencilla apoyándonos en las herramientas de los diferentes sistemas operativos (debian, red hat, etc.).
debian> apt-get install arpwatch
redhat> yum install arpwatch
Tras ello, y para ponerlo a funcionar, únicamente hay que editar el fichero de configuración (/etc/arpwatch.conf) e indicarle el interfaz de red que deseemos monitorizar, así como la red del mismo y también la dirección de correo electrónico a la que mandar los cambios detectados.
eth0   -m arpwatch@mi.dominio.com -n 192.168.0.0/24
eth1   -m arpwatch@mi.dominio.com -n 192.168.1.0/24
Efectivamente, arpwatch permite incluir varios interfaces de red que monitorizar. Una vez configurado, simplemente arrancamos el nuevo servicio,
shell> /etc/init.d/arpwatch start 
y comenzarán a llegar los correos de todos aquellos equipos accesibles en dicha red en ese momento. Un ejemplo del mail enviado sería,
hostname: backup.local.net
          ip address: 192.168.1.100
           interface: eth0
    ethernet address: 00:0f:51:XX:YY:ZZ
     ethernet vendor: Merit Li-Lin Ent.
           timestamp: Saturday, August 2, 2014 10:57:05 +0200
Hay que decir que en un primer momento enviará un correo por cada equipo que vaya detectando y a partir de ahí, únicamente los nuevos equipos que se conecten. Si la red es bastante estática, por ejemplo una intranet, estos cambios deben de ser mínimos y ante cualquier nuevo evento, habría que revisarlo, pues puede ser un equipo no autorizado.

arpwatch y cómo detectar ataques ARP Spoofing

Como ya dijimos, arpwatch se encarga de mantener un registro de la relación entre IP -> MAC junto a una marca temporal. Si dicho registro se altera, notifica de dicha alteración. Los ataques de ARP Spoofing se basan en el envío de falsos mensajes ARP (spoofed) con la finalidad de asociar una dirección MAC del atacante con una dirección IP.
En caso de intento de envenenamiento de la tabla arp, arpwatch notificaría de dichos cambios y aunque no permitiría detenerlos ni mitigarlo, sí cuando menos detectarlos.
Leer más

Deshabilitar los USBs en Linux

No todos los ordenadores con GNU/Linux tienen por que ser para uso personal, sino que puede darse el caso de que tengas la suerte de trabajar con un equipo de empresa que tenga instalado GNU/Linux. Puesto que los datos suelen ser un tema muy importante, y cada vez más, muchas empresas optan por evitar la fuga de información a través de dispositivos USB. Así que, si eres el administrador de estos equipos, lee esta entrada entera, que te podrá ser útil.
La verdad es que es un truco muy sencillo, pero a la vez muy útil, y por supuesto, fácilmente implementable con Salt o Puppet. Deshabilitar los USBs de un equipo es tan sencillo como crear el fichero /etc/modprobe.d/no-usb con el siguiente contenido,
install usb-storage /bin/true
Y tras ello, reiniciar el equipo para que surjan efecto los cambios. Una vez lo hayas hecho, al conectar un UBS tu sistema no lo reconocerá y por lo tanto no se podrá usar.
En realidad lo que acabamos de hacer es forzar la 'no carga' del módulo de manejo de USBs por parte del kernel, con lo que los dispositivos no están habilitados. Esto lo puedes comprobar con un sencillo,
shell> lsmod | grep -i usb
Donde el módulo usb-storage no podrá salir.

Habilitarlo temporalmente

Por supuesto, si eres root y deseas usar el USB en un momento dado, lo puedes hacer recurriendo a la técnica de:
  1. Cargar el módulo
    shell> modprobe usb-storage
    
  2. Usar el USB
  3. Descargar el módulo nuevamente
    shell> modprobe -r usb-storage
    

Otra forma de deshabilitar el USB

Esta forma no es más sencilla de realizar, pero sí más simple de alterar por el usuario si lo sabe, pero aquí la dejo también. Consiste en alterar la línea del Grub que hace referencia a la carga del kernel y agregar el parámetro nousb. Con ello hará que no se carguen los módulos del USB.
kernel /vmlinuz-3.11.0-12-generic ro root=LABEL=/ console=tty0 nousb
Leer más

OpenSSL break: Actualización de Zimbra

Hace unos meses ya publicamos una advertencia de fallo de seguridad grave en OpenSSL y Zimbra estaba afectado, por lo que dijimos cómo actualizarlo.
Esta última semana el mundo de la seguridad se volvió a ver un poco azotado ya que OpenSSL cayó nuevamente. Por supuesto esto implica, si tienes un sistema afectado, actualizar rápidamente, y Zimbra no se hizo esperar y sacó un parche de seguridad a dicha vulnerabilidad. Aplicarlo, como suele ser bastante habitual en Zimbra, es sencillo.
Lo primero, es descargarse el código de parche.
shell> cd /tmp
shell> wget http://files.zimbra.com/downloads/security/zmopenssl-updater.sh
shell> chmod a+rx zmopenssl-updater.sh
Tras ello, debemos de, como usuario zimbra, parar todos los servicios.
shell> su - zimbra
zimbra@shell> zmcontrol stop
Ahora, nuevamente como usuario root, debemos de ejecutar el script, que aplicará el parche y solucionará el problema.
shell> /tmp/zmopenssl-updater.sh
   Downloading patched openssl
   Validating patched openssl: success
   Backing up old openssl: complete
   Installing patched openssl: complete
   OpenSSL patch process complete.
   Please restart Zimbra Collaboration Suite
Una vez terminado, podemos volver a arrancar todos los servicios de Zimbra.
zimbra@shell> zmcontrol start
Y para quedarnos más tranquilos, podemos comprobar que la versión de OpenSSL que Zimbra emplea sí se actualizó, pasando de la 0.9.8k 25 Mar 2009 (en mi caso) a la 1.0.1h 5 Jun 2014.
zimbra@shell> openssl version
   OpenSSL 1.0.1h 5 Jun 2014

Referencias:

Leer más

Seguridad ante todo

En el mundo de la seguridad informática, tomarse los problemas con una sonrisa es una buena filosofía. Os dejo aquí la viñeta de Linux Hispano que ilustra esto perfectamente. Además, que hoy es viernes!
La solución más sencilla a heartbleed
Leer más

Filtrar países con IPTables

Una de las cosas que más nos llama la atención a los administradores de sistemas, especialmente si tenéis acceso a equipos de Firewall es siempre la cantidad de ataques que se están recibiendo. Es cierto que la red no es un lugar cómodo ni pacífico. A los 5 minutos de conectar un equipo a una IP pública, éste ya comienza a recibir ataques. Nos guste o no, tenga lógica o no, la mayoría de los ataques a los equipos provienen de determinados países, llamémosle conflictivos, como puedes ser China, Rusia, etc. Por suerte para nosotros, GNU/Linux tiene un sistema de Firewall modular que permite añadir pequeñas mejoras. Hoy vamos a ver cómo filtrar los paquetes de determinados países gracias a xtables_addons.
xtables_addons es un sistema modular para el kernel que permite añadir funcionalidades sin parchear éste, gracias a la creación de módulos dinámicos (dkms), lo que evita tener que compilar y reiniciar el sistema. En determinadas distribuciones (Ubuntu y derivados) está disponible ya para instalación, mientras que en otras hay que compilarlos desde las fuentes. Puesto que el funcionamiento una vez instalado es el mismo, vamos a partir de una Ubuntu desde la que podamos simplificar la instalación.
shell> apt-get install xtables-addons-dkms
La instalación de este paquete llevará un poco de tiempo, puesto que crea los módulos para la versión del kernel que tengamos instalada. Gracias a dkms, si se actualiza el kernel, los módulos se volverán a reconstruir automáticamente. Una vez instalado xtables_addons, debemos instalar el paquete que simplifica la forma de procesar los paquetes de rangos de IPs de los países. Para ello,
shell> apt-get install libtext-csv-xs-perl
Ahora ya estamos listos para comenzar a trabajar y filtrar las conexiones entrantes o salientes de IPTables a determinados países. Lo primero será descargar las bases de datos de rangos IP de cada país. Para ello,
shell> cd /tmp
shell> /usr/lib/xtables-addons/xt_geoip_dl
Esto nos descargará dos ficheros, GeoIPv6.csv.gz y GeoIPCountryCSV.zip, que los procesará y dejará en el directorio actual un fichero más llamado GeoIPCountryWhois.csv, que es el que realmente nos va a interesar. Ahora tenemos que procesar este fichero .cvs para darle el formato adecuado y que xtables_addons e IPTables lo entiendan. Para hacer esto,
shell> mkdir -p /usr/share/xt_geoip/
shell> /usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip/ \
       GeoIPCountryWhois.csv
91027 entries total
    0 IPv6 ranges for A1 Anonymous Proxy
  102 IPv4 ranges for A1 Anonymous Proxy
    0 IPv6 ranges for A2 Satellite Provider
  425 IPv4 ranges for A2 Satellite Provider
    0 IPv6 ranges for AD Andorra
    8 IPv4 ranges for AD Andorra
    0 IPv6 ranges for AE United Arab Emirates
      ...
  485 IPv4 ranges for ZA South Africa
    0 IPv6 ranges for ZM Zambia
   43 IPv4 ranges for ZM Zambia
    0 IPv6 ranges for ZW Zimbabwe
   47 IPv4 ranges for ZW Zimbabwe
Llegados a este punto ya estamos listos para emplear el filtrado por países en IPTables. Lo único que debemos de hacer es emplear "-m geoip" y "--src-cc XX", siendo XX el código ISO del país (código ISO en Wikipedia).
Por ejemplo, para bloquear las conexiones entrantes desde IPs del rango de China (ISO CN), tendríamos que hacer algo como,
shell> iptables -A INPUT -m geoip --src-cc CN -j DROP
También se puede emplear este truco de geoip con las opciones habituales de IPTables,
shell> iptables -A INPUT \
       -p tcp -m tcp -m multiport --dports 80,443 \
       -m geoip --src-cc CN \
       -j DROP
Tras ello, podemos ver cómo quedaría nuestro Firewall configurado,
shell> iptables -L -n -v
Chain INPUT (policy ACCEPT 1644 packets, 2796K bytes)
pkts B target prot opt in out source    destination         
0    0 DROP   all  --  *  *   0.0.0.0/0 0.0.0.0/0 -m geoip --source-country CN
0    0 DROP   tcp  --  *  *   0.0.0.0/0 0.0.0.0/0 tcp multiport dports 80,443 -m ...

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts B target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 1423 packets, 221K bytes)
pkts B target prot opt in out source destination

Leer más

Zimbra, Heartbleed - OpenSSL patch

Como bien sabéis, recientemente se descubrió un grave fallo de seguridad en el paquete OpenSSL que dejó más que en entredicho la seguridad de la mayoría de los lugares que se suponían seguros en Internet. El protocolo https, que hasta ahora se garantizaba seguro, ya no lo era. Por suerte, el software libre se mueve de prisa y no se tardó mucho en sacar un parche que corregía dicha vulnerabilidad.
Estos días, lo que nos tocó a la gente de sistemas fue realizar un update masivo del paquete OpenSSL. Por suerte, herramientas como Salt Stack y Puppet ayudan a llevarlo mejor ;-)
Hoy vamos a ver cómo parchear una instalación de Zimbra que esté afectada. Zimbra, trae en su instalación las librerías OpenSSL propias, no la del sistema base, y es por ello que es necesario aplicar el parche del fabricante y no actualizar el paquete del sistema. Por suerte, el Zimbra deja a nuestra disposición (aquí el link) un parche para descargar y aplicar al equipo. Así que la forma de hacerlo es sencilla.
Lo primero es descargarnos el script que se encarga de aplicar el parche y darle permisos de ejecución.
shell> wget http://files.zimbra.com/downloads/security/zmopenssl-updater.sh
shell> chmod +x zmopenssl-updater.sh
A continuación, lo ejecutamos como root. Con ello se descargará el parche real de OpenSSL y lo aplicará a nuestra instalación de Zimbra.
shell> ./zmopenssl-updater.sh
  Downloading patched openssl
  Validating patched openssl: success
  Backing up old openssl: complete
  Installing patched openssl: complete
  OpenSSL patch process complete.
  Please restart Zimbra Collaboration Suite as the Zimbra user
Al finalizar nos informa de que hay que reiniciar el servicio para que los cambios tenga efecto. Lo hacemos.
shell> su - zimbra
zimbra@shell> zmcontrol restart
Y comprobamos que todo quede correctamente funcionando y no haya problema ninguno.
zimbra@shell> zmcontrol status
Host zimbra.localhost
 antispam                Running
 antivirus               Running
 ldap                    Running
 logger                  Running
 mailbox                 Running
 mta                     Running
 opendkim                Running
 snmp                    Running
 spell                   Running
 stats                   Running
 zmconfigd               Running

Referencias:
Leer más

Comprobando fallos de seguridad con yum

Prácticamente todas las distribuciones actuales de GNU/Linux tiene un método de control para informar sobre los fallos de seguridad y poder aplicar los parches correspondientes que salen. Hoy vamos a ver cómo realizar esta tarea en Red Hat, apoyándonos en yum, su gestor de paquetes. Este truco es aplicable tanto para Red Hat como para Fedora, no así para CentOS, que cambia un poco la forma de emplearlo y el nombre de los paquetes.
Desde yum podremos obtener información acerca de los fallos de seguridad más recientes que hay, así como datos adicionales de los mismos. De la misma forma, también podremos lanzar una actualización que sólo afecte a aquellos paquetes con problemas de seguridad, que son los más urgentes. Para realizar todas estas tareas, vamos a emplear el paquete yum-plugin-security, que no es más que un plugin que se encarga de tratar desde yum los temas de seguridad. Lo primero, instalarlo.
shell> yum install yum-plugin-security
Una vez instalado, podremos ya pedirle al sistema que nos enumere aquellos fallos de seguridad que están presentes en nuestro sistema, es decir, aquellos a los que todavía no se les aplicó un parche. Por ejemplo, la salida de un servidor con Red Hat 6,
shell> yum updateinfo list security

RHSA-2014:0328 Important/Sec. kernel-2.6.32-431.11.2.el6.x86_64
RHSA-2014:0328 Important/Sec. kernel-firmware-2.6.32-431.11.2.el6.noarch
RHSA-2014:0328 Important/Sec. kernel-headers-2.6.32-431.11.2.el6.x86_64
RHSA-2014:0330 Moderate/Sec.  libsmbclient-3.6.9-168.el6_5.x86_64
RHSA-2014:0330 Moderate/Sec.  samba-common-3.6.9-168.el6_5.x86_64
RHSA-2014:0330 Moderate/Sec.  samba-winbind-3.6.9-168.el6_5.x86_64
RHSA-2014:0330 Moderate/Sec.  samba-winbind-clients-3.6.9-168.el6_5.x86_64
Una vez tengamos el listado de fallos de seguridad, podremos obtener más información acerca de cualquiera de ellos.
shell> yum updateinfo "RHSA-2014:0328"

====================================================================
Important : kernel security and bug fix update
====================================================================
Update ID : RHSA-2014:0328
  Release : 
     Type : security
   Status : final
   Issued : 2014-03-25 00:00:00
     Bugs : 921970 - CVE-2013-1860 kernel: usb: cdc-wdm buffer overflow ...
          : 1062577 - CVE-2014-0055 kernel: vhost-net: insufficient ...
          : 1064253 - CVE-2014-0069 kernel: cifs: incorrect handling of...
          : 1070705 - CVE-2014-0101 kernel: net: sctp: null pointer ...
     CVEs : CVE-2013-1860
          : CVE-2014-0101
          : CVE-2014-0055
          : CVE-2014-0069
 Descript : The kernel packages contain the Linux kernel, the core of any
          : Linux operating system.
          : 
          : * A flaw was found in the way the get_rx_bufs()
          :   function in the vhost_net implementation in the
          :   Linux kernel handled error conditions reported
          :   by the vhost_get_vq_desc() function. A
          :   privileged guest user could use this flaw to
          :   crash the host. (CVE-2014-0055, Important)
          ...

 Severity : Important
Es importante aquí destacar la información que el primero comando nos da, pudiendo diferenciar rápidamente los tipos de vulnerabilidades por su criticidad (Important, Moderate, bugfix, etc.).
Por supuesto, una vez obtenemos este listado, actualizar el paquete en cuestión es muy sencillo, aunque ir paquete a paquete no es lo más eficiente. Para actualizar todos aquellos paquetes con un bug de seguridad, simplemente,
shell> yum --security update-minimal
Ya no hay excusas para no estar informado de aquellos problemas de seguridad y cómo afectan a nuestros sistemas, ni por supuesto, tener los sistemas sin el adecuado parche. Una de las mejoras cosas que tiene GNU/Linux es que los parches de seguridad salen casi tan rápido como los fallos se publican.
Leer más

Explicación de la bomba fork()

Aunque por suerte ya casi todos los sistemas GNU/Linux actuales no se ven afectados por el exploit local que se conocía como la bomba fork(), sí todavía sigue siendo algo de mucho interés: cómo una simple línea capaz de causar una denegación completa de servicio y terminar con los recursos de una máquina.
:(){ :|:& };:
La verdad, es que si vemos la línea tal que así, puede resultar cuanto menos confuso comprender lo que hacer. Es lo bueno de la ofuscación. Así que vamos a desglosarla un poco para poder explicarla, pero sin cambiarle el significado.
bomba_fork() {
   bomba_fork | bomba_fork &
}; bomba_fork
Empleando nombre más descriptivos y usando más de una línea, creo que la cosa ya mejora algo. Esta última función y la anterior son la misma y tiene el mismo efecto, pero una está un poco más clara que la otra y por lo tanto, es más sencilla de explicar.
  • bomba_fork()
    Es el nombre de la función y cómo se define ésta en bash.
    En el código ofuscado, el nombre de la función es ":".
  • bomba_fork
    Es la llamada a la función. Cada vez que escribimos esto, lo que hacemos es una llamada a la función previamente definida y por lo tanto ejecuta lo que hay dentro de la misma.
    Recordar que en el código ofuscado, el nombre de la función es ":".
  • bomba_fork | bomba_fork
    Esta en una llamada a la función y puesto que está dentro de la función es recursiva. Acordaros lo que vimos en el punto anterior, bomba_fork es el nombre de la función, cada vez que la llamemos se ejecuta la función.
    Con el pipe, "|", lo que conseguimos es que en cada llamada a la función se llame a la misma dos veces.
  • &
    Esto hace que la función quede en segundo plano y no se muera, consumiendo recursos de la máquina.
Quizás así ahora esté ya más claro de por qué este código tan simple hace tanto daño. Como vemos, consume recursos infinitamente hasta que estos se agotan, ya que las llamadas recursivas nunca terminan.
Leer más

Ocultar los procesos a usuarios

En el último artículo de Debian Administration leo un sorprendente post que habla sobre cómo esconder los procesos a usuarios sin privilegios, mediante un parámetro presente desde el kernel 3.2.
Para hacer este tipo de protecciones la única forma que existía con antelación era emplear utilidades y parches aplicados en el kernel. Por suerte, con las últimas versiones del kernel de Linux, esto ya lo podemos hacer de forma nativa e inmediata, lo cual facilita, y mucho, el trabajo a la hora de proteger y ocultar datos a los administradores de sistemas.

¿Cuándo emplear este truco?

En los equipos de sobremesa habituales, desde luego no tiene sentido hacer este tipo de filtros, pues no es necesario ocultar los proceso de otros usuarios; entre otras cosas, suelen ser mono-usuario.
En servidores, quipos compartidos por varios usuarios a la vez (GNU/Linux es multi-usuario de verdad!) o equipos en los que se están a ejecutar procesos críticos, pues quizás sí tenga más sentido ocultar los procesos que no son del propio usuario. Por qué el usuario X tiene que saber lo que está a ejecutar el usuario Y. Si no interesa que lo sepa, empleamos este truco y listo.

Cómo configurar esta nueva utilidad del kernel

La nueva utilidad descrita está basada en un parámetro, hidepid, que se le pasa como parámetro de montaje a la partición /proc. Los posibles valores que puede tomar son:
  • 0 - Valor por defecto del sistema. Todos los usuarios pueden ver todos los procesos.
  • 1 - Esta opción ya ofrece algo de restricción a lo que un usuario normal puede ver. Ante la salida estándar de "ps aux", por ejemplo, no se pueden ver procesos de otros usuarios, pero bajo /proc todavía puede ver estos procesos.
  • 2 - Esta es la opción más restrictiva. Un usuario normal no puede ver nada que otros estén ejecutando ni siquiera accediendo a la carpeta /proc. Todo está oculto para él.
Y la forma de emplearla es, en tiempo real y sin hacer nada, volver a montar la partición /proc, pasándole como parámetro esta nueva opción.
shell> mount -o remount /proc --options=hidepid=2
Al realizarlo, el cambio es inmediato y según el valor que le pasemos, dentro de los posibles, veremos el resultado en usuarios sin privilegios de root. Por ejemplo, si ejecutamos la línea que os acabo de indicar, cualquier usuario que no tenga permisos dejará de ver todos aquellos procesos que no sean suyos y para él, el servidor sólo ejecutará cosas suyas.
Si nos interesa emplear esta funcionalidad de forma permanente, tendremos que aplicar el cambio en el fichero /etc/fstab y añadir la opción comentada a la partición /proc, tal como sigue.
proc   /proc   proc   defaults,hidepid=2   0   0
Las diferentes salidas se muestran a continuación. La primer, en ejemplo de lo que ve un usuario sin privilegios antes de bloquearle el acceso a los procesos que no son suyos,
javier@shell> ps aux
USER      PID %CPU %MEM   VSZ   RSS TTY  STAT START   TIME COMMAND
root        1  0.0  0.0  2776  2864 ?    Ss   mar12   0:00 /sbin/init
root        2  0.0  0.0     0     0 ?    S    mar12   0:00 [kthreadd]
root        3  0.0  0.0     0     0 ?    S    mar12   0:00 [ksoftirqd/0]
root        4  0.0  0.0     0     0 ?    S    mar12   1:22 [kworker/0:0]
root        5  0.0  0.0     0     0 ?    S<   mar12   0:00 [kworker/0:0H]
root        7  0.0  0.0     0     0 ?    S    mar12   0:00 [migration/0]
...
Y a continuación, el mismo usuario una vez pasada la opción hidepid=2.
javier@shell> ps aux
USER      PID %CPU %MEM  VSZ   RSS TTY  STAT START   TIME COMMAND
javier   2589  0.0  0.0 3352  7876 ?    Ssl  mar12   0:00 x-session-manager
javier   2649  0.0  0.0 4444   500 ?    S    mar12   0:00 /usr/bin/dbus...
javier   2650  0.0  0.0 1856  2048 ?    Ss   mar12   0:09 //bin/dbus-...
javier   2661  0.0  0.0 9360  2548 ?    S    mar12   0:00 /usr/lib/x86...
javier   2665  0.1  0.2 3284 17076 ?    S    mar12   5:12 xfwm4
javier   2669  0.2  0.2 2584 20508 ?    Sl   mar12   7:34 xfce4-panel
...
Sin dudarlo, una opción muy interesante para equipos compartidos que debería de estar presente en muchos, por no decir todos los servidores de producción. 

Referencia: debian-administration.org
Leer más

Debian squeeze: Error de GPG

La semana pasada se descubrió un interesante y grave fallo de seguridad en el paquete OpenSSL. Existía una función con la palabra reservada goto que podía aprovecharse para hacer cosas extrañas y entre otras, crear certificados SSL no válidos.
La verdad es que la primera vez que lo leí, me quedé bastante sorprendido, pues hacía años que no veía el goto, muy famoso en lenguajes deprecated, como pueden ser Pascal o Cobol. Pero cierto es que se usa también en lenguajes como C. Una vez apareció el bug, presente desde 2005, y la forma de explotarlo, era lógico que alguien lo hiciera. Imaginaros la sorpresa, y susto, que llevé cuando una buena amiga me pasa este fallo que le estaba dando una debian al intentar actualizar el listado de paquetes.
shell> apt-get update
...
W: Error de GPG: http://ftp.es.debian.org squeeze-updates Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 8B48AD6246925553
Lo primero que pensé, alguien accedió a los servidores de es.debian.org y está haciendo cosas raras. Ya bien hayan sido hackeados o bien alguien haya conseguido redireccionar todo el tráfico a otras máquinas. Por suerte, emplear paquetes firmados sirve de algo. Después de una búsqueda inicial y observar que el certificado de es.debian no había sido violado, tocaba arreglar el problema. Instalar paquetes desde servidores que no confías no es buena idea.
Comenzamos viendo el listado repositorios que tenía el servidor configurados.
shell> cat /etc/apt/sources.list
deb http://ftp.es.debian.org/debian/   squeeze main
deb http://security.debian.org/        squeeze/updates main
deb http://ftp.es.debian.org/debian/   squeeze-updates main
Los servidores era buenos y estaban bien. No había nada extraño y desde el equipo contestaba la IP que era de esperar a dicho DNS. Entonces, ¿qué es lo que podía estar pasando?
Se me ocurrió entonces ver dentro de los paquetes instalados, la versión del paquete de llaves de debian que tenía instalado. Por suerte, no hacía mucho que había actualizado un equipo a squeeze y me acordaba que ese paquete se había actualizado con nuevas claves. Así que antes de seguir pensando que hay algo extraño, vamos a lo sencillo,
shell> dpkg -l |grep debian-archive-keyring
ii  debian-archive-keyring  2010.08.28  GnuPG archive keys of the Debian
He aquí el problema. La versión del paquete que está instalada no es la última. Cuando alguien actualizó ese sistema a squeeze se olvidó de actualizar uno de los paquetes más importantes. Concretamente el paquete con las nuevas llaves de los servidores. Al usar las llaves antiguas, apt daba error de clave desconocida, pues efectivamente no tenía la correcta. Para solucionarlo, actualizamos el paquete debian-archive-keyring.
shell> apt-get install debian-archive-keyring
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias       
Leyendo la información de estado... Hecho
Se actualizarán los siguientes paquetes:
  debian-archive-keyring
1 actualizados, 0 se instalarán, 0 para eliminar y 96 no actualizados.
...
gpg: Cantidad total procesada: 7
gpg:               importadas: 2  (RSA: 2)
gpg:              sin cambios: 5
gpg: no se encuentran claves absolutamente fiables
Tras actualizar el paquete a su última versión, apt ya no da error y el funcionamiento es el esperado, ya que las claves GPG son reconocidas.
shell> apt-get update
...
Descargados 7137 kB en 4seg. (1622 kB/s)                       
Leyendo lista de paquetes... Hecho
Lo que fue un susto inicialmente, quedó en una breve anécdota y únicamente hizo falta actualizar uno de los paquete más sencillos y a la vez más importantes del sistema. Lo que sí, casualidades de la vida, justo pasó en el momento más inoportuno con un fallo que podía haber puesto en jaque a numerosos sistemas.
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios