Redirección al acceder a la web
- Detalles
- Publicado el Viernes, 07 Octubre 2011 14:38
- Escrito por Texpaok
Hola a todos.
En el día de hoy los que habéis intentando acceder a protegetuordenador.com (y no tenéis noscript u otro componente que deshabilite javascript) habéis sido redirigidos a la web sweepstakesandcontestsinfo.com. Esto es debido a una modificación no autorizada de ficheros del servidor, por lo que estamos investigando el incidente con nuestro proveedor de hosting.
Puesto que no guardamos ningún dato personal no hay información comprometida, sólo la pu***** del que haya sido redirigido a la página de marras. En los próximos días os contaré cómo ha sucedido este incidente y os informaré de las tácticas utilizadas en cuanto analice los logs y los ficheros comprometidos.
Siento muchísimo las molestias que hayamos podido causaros.
Ver actualizaciones Ubuntu + CentOS + OpenSuSE
- Detalles
- Publicado el Martes, 27 Septiembre 2011 14:00
- Escrito por Juan José
Justamente en la entrada anterior veíamos una de las posibles consecuencias de no actualizar el software que utilizamos. Si bien es cierto que actualizar indiscriminadamente puede ser un tanto riesgoso en entornos de producción, (podríamos romper alguna dependencia y dejar inútil una aplicación) actualizar ES NECESARIO!!!
Actualizar puede ser una tarea simple y hasta divertida cuando se tratan de unos pocos servidores, pero ya no tanto cuando el número comienza a ascender! Por lo tanto la idea de esta entrada es definir un mecanismo que nos permita:
-Identificar entre actualizaciones de seguridad y el resto.
-Automatizar los avisos de actualizaciones.
El modelo es el siguiente:
-Utilizamos nagios para recolectar y presentar la información.
-No buscaremos actualizaciones cada 5 minutos, las actualizaciones no salen con tanta frecuencia por lo tanto estaríamos consumiendo ancho de banda de manera innecesaria. En el esquema planteado los servidores buscaran sus actualizaciones una vez en el día, y el resto del día mostraran los datos de esa recolección hasta que sean actualizados.
-Tendremos 2 scripts:
- updateNombreDelSO.pl que dependerá del sistema operativo y será el que se ejecute automáticamente una vez al día para recolectar las actualizaciones disponibles. Este script generará el segundo.
- check_actualizaciones.sh que será el script que ejecuté nrpe en los servidores, bajo la demanda del servidor corriendo nagios. Este script es la salida del primero, solo imprime la cantidad de actualizaciones pendientes de seguridad y extra, y un código de salida acorde a la situación.
-Definimos como CRITICAL la situación en la que existen actualizaciones de seguridad sin aplicar, y como WARNING cuando solamente existen actualizaciones extras (no de seguridad) por aplicar.
updateUbuntu.pl
$STATUS_OK=0;
$STATUS_WARNING=1;
$STATUS_CRITICAL=2;
$STATUS_UNKNOWN=3;
$PATCHS=`/usr/lib/update-notifier/apt-check 2>&1`;
@A=split(';',$PATCHS);
$SALIDA="#!/bin/bash\n";
$EXIT=$STATUS_UNKNOWN;
$FILE="/usr/lib/nagios/plugins/check_actualizaciones.sh";
if($A[0] eq "0" and $A[1] eq "0")
{
open(F,">$FILE");
print F "$SALIDA"."echo \"Existen ".$A[0]." actualizaciones.\"\n";
print F "exit $STATUS_OK";
close(F);
chmod (0777,$FILE);
exit;
}
if($A[0] > 0)
{
$SALIDA = $SALIDA . "echo \"ERROR - Existen ".$A[0]." actualizaciones de seguridad y ".$A[1]." extras\"\n";
$EXIT = $STATUS_CRITICAL;
}
else
{
$SALIDA = $SALIDA . "echo \"WARNING - Existen ".$A[1]." actualizaciones extras.\"\n";
$EXIT = $STATUS_WARNING;
}
open(F,">$FILE");
print F $SALIDA;
print F "exit $EXIT";
close(F);
chmod (0777,$FILE);
Prueba de concepto CVE-2011-3200 rsyslog
- Detalles
- Publicado el Lunes, 19 Septiembre 2011 07:00
- Escrito por Juan José
Es una tendencia y una muy buena práctica la centralización de los logs de los equipos. Existen varias opciones, siendo las mas difundidas rsyslog, syslog-ng y syslogd.
En esta entrada vamos a comprobar una vulnerabilidad (debilidad o falta de un control) que fue encontrada hace un par de semanas en el servidor de logs rsyslog.
La vulnerabilidad es básicamente un desbordamiento de pila, provocado por un excesivo tamaño del campo TAG. Este, es uno de los campos que compone un mensaje tipo syslog (RFC3164 http://www.ietf.org/rfc/rfc3164.txt).
El contexto de pruebas es el siguiente:
-Servidor rsyslog remoto en la dirección 192.168.206.160 (OpenSuSE 11.3)
-Cliente rsyslog en la dirección 192.168.206.1 (Ubuntu 9.10)
Software utilizado:
-rsyslog 5.4.0 en el servidor
-rsyslog 4.2.0 en el cliente
-logger en el cliente
-hping3 en el cliente
Configurar el servidor rsyslog:
Primeramente configuramos nuestro servidor rsyslog para que reciba mensajes remotos, esto se hace editando el archivos /etc/rsyslog.d/remote.conf y descomentando las siguientes líneas:
$ModLoad imudp.so
$UDPServerRun 514
Luego reiniciamos rsyslog, y abrimos el puerto 514 UDP en el firewall para poder recibir los mensajes.
Configurar el cliente rsyslog:
En este ejemplo vamos a indicar al rsyslog que corre en la pc cliente, que envíe al servidor remoto los logs que tengan facility local7 y severity warn (o mayor a warn); agregamos la siguiente linea a /etc/rsyslog.d/50-default.conf
local7.warn @192.168.206.160
Probando la configuración con logger:
Logger es una interface de comandos que nos comunica con el sistema de loggin del equipo local. Es decir, logger NO enviará los mensajes al servidor remoto, sino al rsyslog local y este los enviará a donde correspondan.
logger -p local7.err -d -t Prueba "esto es una prueba"
Y en la red vemos:
Y del lado del servidor, con tail -f /var/log/messages veremos como llega nuestro mensaje:
Entonces ya tenemos andando nuestro servidor de logs centralizado (.... por decirlo de una manera :P).
Ahora veamos qué pasa si rompemos la barrera de los 32 caracteres en el campo TAG del mensaje, utilizando logger.
# logger -p local7.err -d -t PruebaPruebaPruebaPruebaPruebaTTX "esto es una prueba"
Más Artículos...
