Sería interesante saber cuando hay actualizaciones disponibles para posteriormente entrar a mano y realizarlas bajo nuestra supervisión de forma manual. Para ello he elaborado un script de gran sencillez cuyo cometido es el de actualizar la lista de paquetes disponibles en Debian/Ubuntu y posteriormente realizar una simulación de actualización del sistema, en caso de que se necesite descargar algo nos avisa mediante correo electrónico.

El contenido del script es el siguiente:

#!/bin/bash
LOGFILE=/tmp/log_aptitude
aptitude update  > $LOGFILE
aptitude -sy upgrade >> $LOGFILE
grep -q "Necesito descargar 0B" $LOGFILE
if [ $? -eq 1 ]
then
      cat $LOGFILE | mail -s "Se necesita actualizar el servidor" mi@correo.com
fi

Sustituyendo mi@correo.com por nuestra dirección de correo electrónico donde recibir las notificaciones.
Para añadirlo al crontab de forma que se ejecute cada 3 horas habría que ejecutar como root

crontab -e

y añadir la siguiente línea:

0 */3 * * * /root/scripts/aptupdates

Una vez hecho esto en el momento en que haya alguna actualización pendiente de realizar se nos informarán por correo, evitando así tener que entrar periódicamente al servidor y comprobar esto de forma manual.

Esta práctica es muy recomendable, pero no significa que nos cubra completamente, ni mucho menos. Gran cantidad de bugs no se comunican a los creadores del software hasta pasados unos días, semanas e incluso meses posteriores a su descubrimiento, pero lo que sí se crean son los denominados xploits o-day que circulan dentro de los círculos privados de determinados grupos aficionados a la seguridad. Estos xploits permiten en multitud de casos aprovechar una vulnerabilidad remota para ganar acceso a la máquina, en algunos casos directamente como root y en otros casos como usuario normal, pero una vez dentro el conseguir acceso como root se basa en ejecutar otro xploit local, cosa que suele ser de menor dificultad una vez dentro del sistema.

Con el fin de minimizar la probabilidad de que nuestro servidor sea hackeado este artículo quiere presentar (para los que no los conozcan) y recomendar encarecidamente el uso del conjunto de parches denominados Grsecurity. La definición que aportan en su web es la siguiente:

Grsecurity is an innovative approach to security utilizing a multi-layered detection, prevention, and containment model. It is licensed under the GPL.
It offers among many other features:

• An intelligent and robust Role-Based Access Control (RBAC) system that can generate least privilege policies for your entire system with no configuration
• Change root (chroot) hardening
• /tmp race prevention
• Extensive auditing
• Prevention of arbitrary code execution, regardless of the technique used (stack smashing, heap corruption, etc)
• Prevention of arbitrary code execution in the kernel
• Randomization of the stack, library, and heap bases
• Kernel stack base randomization
• Protection against exploitable null-pointer dereference bugs in the kernel
• Reduction of the risk of sensitive information being leaked by arbitrary-read kernel bugs
• A restriction that allows a user to only view his/her processes
• Security alerts and audits that contain the IP address of the person causing the alert

Este conjunto de parches podría en gran cantidad de casos, aún ejecutando en nuestro servidor un proceso que tenga alguna vulnerabilidad conocida, que esta vulnerabilidad pueda ser explotada.  Los mecanismos que añade al kernel para aumentar la seguridad son de un nivel que se escapa del objetivo de este artículo. Por poner un ejemplo, para aquellos que conozcan en que se basan las vulnerabilidades de tipo stack overflow y que alguna vez hayan experimentado con un xploit de este tipo diremos que Grsecurity introduce aleatorización en la dirección EIP de ejecución de los procesos, de forma que un offset precalculado y almacenado en el xploit no serviría para nada en un servidor con estos parches.

La instalación de Grsec requiere parchear el kernel, aunque se pueden encontrar kernels ya parcheados por internet yo recomiendo bajarse los fuentes de la distribución y parchear uno mismo a mano el kernel.

Una característica que me gusta mucho también de Grsec es que si lo activas puedes permitir que los usuarios sólo vean los procesos que están ejecutando ellos mismos, así nunca podrán ver información sensible de los procesos que otros usuarios estén ejecutando en el sistema.

Como conclusión final podemos decir, al igual que en otros artículo que esto aumenta la seguridad de nuestros servidores, pero en ningún caso nos hemos de dormir ya que continuamente aparecen nuevas vulnerabilidades que podrían afectarnos.

Más enlaces de interés para aquellos que quieran profundizar en el tema:

Página oficial de Grsecurity

Packetstorm

SecurityFocus

Cuando un atacante explota un fallo en un servidor y logra acceso, lo primero que suele hacer es cubrir sus huellas mediante la instalación de un rootkit. Esto puede implicar modificar binarios o librerías del sistema con versiones creadas especialmente para el caso; por ejemplo se podría sustituir el binario /bin/ls del sistema con una versión que no mostrase los ficheros que empiecen por una cadena en especial, así el atacante podría dejar ficheros en el sistema cuyo nombre comenzasen por esa cadena y nadie más podría ver que existen usando el comando ls.

Aunque existen mecanismos más complejos y eficientes para ocultar ficheros en el sistema (como por ejemplo modificando la syscall table del kernel con una versión alternativa de una llamada al sistema), este método es bastante común. El problema radica en que el administrador no se ha dado cuenta de que un binario ha sido reemplazado por una versión alternativa troyanizada, si tuviera algún método de realizar una comprobación automática podría detectar a tiempo este tipo de intrusiones.

Para conseguir detectar estas modificaciones de forma automática existe una estupenda herramienta denominada Tripwire, que genera una base de datos con un hash digital de los ficheros del sistema. Lo ideal es generar esta base de datos con el sistema recien instalado, antes de conectarlo a la red, así estaremos seguros de que está totalmente limpio. Una vez generada la base de datos podremos realizar chequeos periódicos de forma automática añadiendolo en el crontab, pudiendo configurar el software para que envíe un email al administrador en caso de detectar modificaciones en algún fichero.

El primer paso que un atacante realiza cuando consigue explotar el fallo a través de la aplicación web es el de descargar en el servidor alguna aplicación que le permita acceder remotamente de forma cómoda, como por ejemplo mediante una shell. En el caso de los gusanos creados especialmente para este propósito el comportamiento es muy similar, explotan el fallo, descargan el mismo gusano en el sistema y lo ejecutan para seguir infectado otros servidores.

El usuario sube al servidor esta aplicación maliciosa en un directorio en el cual tenga permisos de ejecución el usuario que ejecuta el servicio web, pero como estos directorios pueden variar entre distintas distribuciones se recurre a utilizar en la mayoría de casos el directorio en el cual todos los usuarios pueden escribir, es decir, /tmp .

Para intentar minimizar las oportunidades de éxito de este tipo de ataques surge la idea de marcar de alguna manera el directorio /tmp como directorio donde no se puedan ejecutar aplicaciones, sin embargo esto no es posible aplicarlo directamente a directorios, sino que se debe realizar sobre particiones completas.

Para lograr conseguir este objetivo sin la necesidad de modificar la tabla de particiones de nuestro disco duro vamos a recurrir a dispositivos loop. Básicamente lo que haremos será crear un fichero del tamaño que deseemos que tenga el directorio /tmp, y posteriormente montaremos este sistema de ficheros en el mismo directorio, marcándolo como no ejecutable para conseguir así nuestro objetivo.

A continuación se puede ver un código de ejemplo que crea un directorio /tmp no ejecutable con un tamaño de 1GB:

cd /var
dd if=/dev/zero of=tmploop bs=1024 count=$((1024*1024))
/sbin/mke2fs tmploop
cp -R /tmp /tmpbak
mount -o loop,noexec,nosuid,rw /var/tmp0 /tmp
chmod 0777 /tmp
cp -R /tmpbak/* /tmp/

Esto nos dejaría /tmp preparado, ahora habría que borrar /tmpbak cuando hayamos comprobado que todo ha ido correctamente. Sin embargo cuando el servidor sea reiniciado estos cambios se van a perder. Para que esto no ocurra habría que añadir la siguiente línea al fichero /etc/fstab :

/var/tmploop       /tmp    ext2    loop,noexec,nosuid,rw  0 0

La biometría abarca el estudio de todos aquellos métodos que permiten reconocer de forma única a una persona, estos métodos son denominados técnicas biométricas. Para que este reconocimiento sea efectivo el método usado se ha de basar en alguna característica reconocible que sea totalmente diferente entre dos personas, como por ejemplo el reconocimiento de la huella dactilar.

Gracias a la biometría se pueden agilizar muchos procesos que se ejecutan miles de veces cada día y también garantizar que se mantengan unos ciertos niveles de seguridad, como por ejemplo fichar al entrar y salir del trabajo o controlar el acceso a zonas restrigidas.

Sin embargo estas técnicas no son socialmente aceptadas; gran cantidad de veces los usuarios de estos métodos no ven con muy buenos ojos la introducción de estos sistemas, ya que se pueden sentir amenazados de diversas formas. Por un lado estos métodos permiten tenerlos más controlados y así evitar que se produzca la picaresca y por tanto se pierdan horas de trabajo (como el caso en el cual se ficha mediante tarjetas y los compañeros se las dejan unos a otros cuando saben que van a faltar al trabajo o llegar tarde).

Por otro lado hay ciertos métodos biométricos mediante los cuales un usuario puede ver comprometida cierta información de la cual no quisiera que nadie tuviera constancia; en el caso concreto del análisis de ADN además de reconocer al usuario podríamos conocer también si ha consumido ciertos tipos de estupefacientes en los últimos días (debido a que uno de los métodos para la realización de este test es el de tomar una muestra de cabello) . Este tipo de información podría provocar, aunque las sustancias que el empleado consuma fuera del horario laboral no estuvieran interfiriendo en el trabajo, el despido del mismo en la empresa.

En el caso concreto del reconocimiento de iris, algunos usuarios pueden ser un tanto escépticos ante la (inocua) luz que se proyecta en el ojo en la fase de reconocimiento, esto provoca un recelo a la hora de usar el mismo.

En resumen podemos decir que la biometría por sí sola no sirve para nada sino está asociada a una educación de los usuarios finales en el uso de la misma, que son los que terminarán haciendo uso o no de ella y por tanto determinando su eficacia.

En varios blogs se pueden encontrar soluciones a este problema, un tanto radicales bajo mi punto de vista, que hacen que cuando un blog te enlace directamente una imágen esta sea sustituida por otra en tiempo de ejecución, o incluso que no se muestre nada, ahorrando así todo el ancho de banda.

Sin embargo si nos paramos a pensar un poco, lo que nos gustaría no es que nadie nos hiciera hotlinking de las imágenes, sino que ese blog acreditara en alguna parte que la imagen está extraída de nuestro blog. Como no podemos obligar al propietario del mismo a que nos enlace o nos nombre en algún sitio acerca de donde ha sido obtenida la imagen, vamos a aprovecharnos para incluir la URL de nuestro blog en la imagen enlazada, para ello haremos uso de los archivos .htaccess de Apache y de la librería GD de PHP. Lógicamente no queremos que las imágenes que incluyamos en nuestro blog tengan incrustada la URL del mismo.

La idea es simple, cuando un blog nos enlace una imágen directamente la petición GET llegará al servidor con un campo HTTP_REFERER que no corresponderá con la URL de nuestro blog, en ese momento se invocará un script PHP al cual le pasamos la ruta de la imagen solicitada. Este script PHP se encargá en tiempo real de abrir la imagen, incrustarle la URL de nuestro blog y mostrarla.

Este es un ejemplo de una imagen enlazada directamente por nuestro blog:

Este es un ejemplo de como se mostraría la misma imagen si alguien nos hiciera Hotlinking:

Para conseguir incluir este sistema en cualquier página web es necesario usar Apache, con soporte de archivos .htaccess y tener instalada la librería GD en PHP.

Paso 1: Editar el archivo .htaccess e incluir lo siguiente sustituyendo tudominio.com por tu dominio.

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?tudominio\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{REQUEST_URI} .*\.(jpe?g|gif|bmp|png)$
RewriteRule ^(.*)$ /nohotlink.php?i=$1 [L]

Paso 2: Crear un archivo en el directorio raiz de la web denominado nohotlink.php e incluir el siguiente contenido, sustituyendo www.tudominio.com por tu dominio

<?php
function imagecreatefromfile($path, $user_functions = false)
{
$info = @getimagesize($path);

if(!$info)
{
return false;
}

$functions = array(
IMAGETYPE_GIF => ‘imagecreatefromgif’,
IMAGETYPE_JPEG => ‘imagecreatefromjpeg’,
IMAGETYPE_PNG => ‘imagecreatefrompng’,
IMAGETYPE_WBMP => ‘imagecreatefromwbmp’,
IMAGETYPE_XBM => ‘imagecreatefromwxbm’,
);

if($user_functions)
{
$functions[IMAGETYPE_BMP] = ‘imagecreatefrombmp’;
}

if(!$functions[$info[2]])
{
return false;
}

if(!function_exists($functions[$info[2]]))
{
return false;
}

return $functions[$info[2]]($path);
}

header(”Content-type: image/png”);
$im        = imagecreatefromfile($_GET['i']);
$width    = imagesx($im);
$height    = imagesy($im);
putenv(’GDFONTPATH=’ . realpath(’.'));
$white = imagecolorallocate($im, 255, 255, 255);
$grey  = imagecolorallocate($im, 128, 128, 128);
$black = imagecolorallocate($im, 0, 0, 0);
$orange = imagecolorallocate($im, 220, 210, 60);
$tamano = 10;
$texto = “www.tudominio.com“;
$tb = imagettfbbox($tamano, 0, “arial”, $texto);
$altura = $tb[3] – $tb[5];
imagefilledrectangle  ($im  , 0  , $height-$altura-2  , $width  , $height, $black);
$x = ceil(($width – $tb[2]) / 2);
imagettftext($im, $tamano, 0, $x, $height-4, $orange, “arial”, $texto);
imagepng($im);
imagedestroy($im);

?>

Paso 3: Descargar en el directorio raiz de vuestra web la fuente arial.ttf, la podeis obtener desde aqui.

Y listo, ya tendríamos todo en funcionamiento. Podemos hacer una prueba de si el sistema funciona usando el siguiente comando desde wget:

wget http://www.tudominio.com/alguna_imagen.jpg –referer=http://www.otrodominio.com

Normalmente en los procesos de autenticación interviene lo que denomicamos un único factor, entendiendo como factor cualquier método de autenticación en el sistema, como podría ser una contraseña, un código PIN, una huella dactilar, una secuencia de ADN… Sin embargo si queremos que este proceso de autenticación en el sistema sea más robusto lo ideal es hacer que intervengan dos factores (tres sería mejor, pero el proceso sería demasiado tedioso) siendo a esto a lo que denominamos autenticación multifactor.

Al comienzo de este artículo se puede ver la imágen de un RSA SecurID, un pequeño aparato con forma de llavero que únicamente posee una pantalla LCD en la cual es muestra un número, lo primero de todo hay que destacar que este aparato no posee ningún método de comunicación con el exterior, ni puerto USB, ni Wi-Fi, ni bluetooth, ni infrarrojos ni nada parecido, funciona aislado del mundo exterior. Cada 30 segundos el número que aparece en pantalla cambia por otro generado aleatoriamente, es decir, incorpora un generador de números pseudoaleatorios en su interior y una semilla que permite que esta secuencia sea diferente en cada SecurID. Esta semilla también está almacenada en el servidor de autenticación y por tanto haciendo una serie de cálculos rápidos puede saber en cada momento que número muestra nuestro aparato por pantalla.

Cuando vamos a autenticarnos en el sistema introducimos nuestro nombre de usuario y un número PIN que sólo nosotros conocemos seguido del número que aparezca en ese mismo instante en la pantalla del SecurID, a continuación si esta primera fase de autenticación se realiza correctamente el sistema procede a solicitarnos nuestra contraseña de usuario para acceder al sistema.

¿ Por qué ganamos seguridad usando este sistema ? Sencillamente porque si usamos un método tradicional de usuario y contraseña un atacante que por fuerza bruta logre adivinar la contraseña tendrá acceso al sistema, sin embargo con este método si el atacante conoce el nombre de usuario y contraseña no concerá ni el PIN necesario ni tendrá el RSA SecurID en su posesión para ver el número que aparece en pantalla. El caso de que el usuario pierda el RSA SecurID tampoco es problema ya que un atacante no conocerá el PIN necesario aunque pueda ver en pantalla el número que aparece en el momento de la autenticación.

Este tipo de medidas se han de tomar debido a que no podemos dejar que toda la seguridad asociada al proceso de autenticación recaiga en el usuario del sistema ya que se convertiría en la mayor brecha potencial.

Un estudio de una universidad alemana afirma que Google está creando monopolios inaceptables en diversas áreas que le permiten controlar grandes cantidades de información y por tanto invadir la privacidad de millones de usuarios.

Este estudio revela que se producen diariamente 61000 millones de búsqueas diarias, siendo en Estados Unidos usado por el 57 % de los usuarios de forma habitual e incluso usado ocasionalmente hasta por el 95 %.

Un ejemplo que ha sido debatido ampliamente es el del correo de Google Gmail, en el cual cuando leemos un mensaje a través de la aplicación web se nos muestra en el lateral publicidad relacionada con el contenido del mensaje que estamos leyendo. Esto es posible debido a que la aplicación escanea el correo electrónico en busca de ciertas palabras clave y a continuación nos muestra la publicidad que él cree que más nos puede interesar. En base a esto podría obtener una base de datos de nuestro intereses y posteriormente mostrarnos por ejemplo en los resultados de búsqueda publicidad que más se adecúe a nuestros gustos (hay que recordar que Google nos ofrece su servicio de página web de inicio personalizada y por tanto cuando realizamos una búsqueda puede saber quienes somos si estamos loggeados en el servicio).

En el estudio también se insinúa que puede existir cierta cooperación entre Google y otras entidades como Wikipedia, por ejemplo Google comparado con otros buscadores premia de una forma más contundente a ciertas páginas web como la Wikipedia.

Google ha desmentido todo lo afirmado por el estudio basándose en que son teorías conspiranoicas de un cierto grupo de personas aisladas. Sin embargo es totalmente cierto que la cantidad de información que maneja esta empresa es tanta que puede convertirse en un riesgo de invasión de nuestra privacidad.

Fuente SMH

El parlamento alemán aprobó el pasado 9 de noviembre de 2007 una propuesta para el almacenamiento de las telecomunicaciones durante seis meses a partir del 1 de enero de 2008, entendiendo como telecomunicaciones las llamadas de teléfono, fax, mensajes sms, conexiones a internet y correos electrónicos.

Esta propuesta tiene como objetivo poder seguir la pista de actividades ilegales a través de internet o de intentar combatir el terrorismo, sin embargo medidas como esta no van a poder lograr erradicar estos actos ya que hay muchas formas de eludir este tipo de medidas, como el uso de cifrado de datos.

Las manifestaciones que han ocurrido durante los últimos meses no han logrado frenar que se apruebe esta medida que atenta contra la privacidad de las personas dando permiso al acceso hasta del contenido de los datos transmitidos, no sólo de su cabecera. Este tipo de decisiones son importantes porque pueden afectar a paises vecinos a la hora de su política en la seguridad de las telecomunicaciones.

Fuente: S21sec Blog

John Kenneth Schiefer, de 26 años nacido en Los Angeles podría ser declarado culpable de varios delitos relacionados con el robo de dinero de cuentas bancarias a través de internet. El método usado era la instalación de software en ordenadores de todo el mundo para convertirlos en zombies y posteriormente robar información de los mismos como los datos referentes a las cuentas de Paypal de las victimas.

Se estima que hasta en 250000 máquinas pudo instalar su software, permitiendo su control remoto mediante diferentes servidores contratados en empresas de alojamiento web. Con este método podría haber ganado hasta 35000$ realizando transferencias bancarias, e incluso parte de este dinero lo invirtió en la compra de dominios o en la venta de la información obtenida a terceras partes.

Según la corte federal de Los Angeles le podría caer una pena de hasta 60 años de carcel y multa de hasta 1.75 millones de dólares, el próximo 28 de noviembre se celebra el juicio.

Fuente: SecurityFocus