31 octubre 2011

Anonymous modifica la web de Rubalcaba

Desde un comentario en el blog de Chema, llego a la web de Rubalcaba (www.rubalcaba.es), donde han colado un texto sobre el 11-M y una  imagen y con la conocida máscara.

Leer más...

30 octubre 2011

Enlaces de la SECmana - 95


Leer más...

28 octubre 2011

Vulnerabilidad grave en TOR que permitiría exponer a sus usuarios

En el blog del proyecto TOR, el conocido sistema de comunicación anónima, se anuncia una actualización crítica de seguridad correspondiente con la versión 0.2.2.34, que solventa una vulnerabilidad que permitiría a un usuario desanonimizar otros usuarios de la red.

Al parecer, el ataque se podría llevar a cabo siguiendo las siguientes premisas, y lo que se corrige con esta actualización son los dos primeros puntos descritos a continuación:

1) Los clientes reutilizan sus certificados TLS cuando se comunican con diferentes relays, por lo que los relays podrían identificar al usuario atendiendo a la clave de identidad de su certificado.

2) Un usuario que conociese la clave de identidad de un cliente podría realizar consultas a cada relay para averiguar si la víctima se encuentra conectada a ese relay en ese instante. 

3) Un buen conjunto de ataques teóricos (como el explicado en "Low-Cost Traffic Analysis of Tor" por Murdoch y Danezis en el 2005) permitirían que una web con contenido malicioso pudiera obtener el relay al que se encuentra conectado un usuario de TOR al visitarla. 

4) Los clientes, normalmente, escogen tres servidores aleatoriamente, por lo que el conjunto de relays para un usuario podría servir de identificación. 

Esta vulnerabilidad, según el autor del post Erinn Clark, no tendría relación alguna con las noticias que saltaron a los medios la semana pasada sobre varios comunicados acerca de que la red TOR podría haber sido comprometida. Para desmentir dichos ataques (uno relacionado con la operación de Anonymous contra la pedofilia y otro que vino de Eric Filiol y una charla en la Hackers to Hackers), phobos escribió otro post llamado Rumors of Tor's compromise are greatly exaggerated en el que se pretendía analizar y dejar claro lo que realmente estaba ocurriendo.

Debido a la criticidad de esta vulnerabilidad, sobretodo porque "atenta" contra lo que verdaderamente se asume al utilizar este servicio, se recomienda a los usuarios actualizar la versión de TOR instalada lo antes posible. Se puede descargar la nueva versión en esta dirección.
Leer más...

27 octubre 2011

Gestionando, de forma artesanal, una flota de vehículos


Allá por Marzo de 2009, tenía en la cabeza reutilizar mi vieja Qtek 9100 con sus capacidades GPS y su arcaico e inestable Windows Mobile, para ejecutar una aplicación del proyecto OpenDTM/OpenGTS, a fin de enviar las coordenadas via GPS a un servicio en Internet que me permitiera saber dónde está mi coche en cada momento.

Por un lado, uno de los problemas que planteaba a nuestros lectores de aquella época, radicaba en la privacidad que ofrecían ese tipo de servicios en los que puedes enviar de forma gratuita, la posición de tu dispositivo y monitorizar si se ha llevado el coche la grúa, o algún amigo de lo ajeno. Es decir, ¿por qué el administrador, la empresa patrocinadora del servicio, o en caso de tener una seguridad deficiente, cualquiera con cierta curiosidad, pueden saber qué recorrido hago para ir a trabajar, dónde aparco todos los días o dónde he estado yo el último fin de semana?

Así pues, y como además me llamaba mucho la atención la idea, decidí montármelo yo mismo. Lo primero que elegí fue el software que iba a desplegar en casa para poder almacenar las coordenadas, así como su visualización en un mapa. El proyecto libre que más me gustó fue OpenGTS. Ahora tocaba elegir un dispositivo que fuera compatible al 100% con el proyecto y que vendieran en España. A través de la propia web, dí con el SANAV GC-101FA. En La Casa del GPS lo distribuían por unos 250 euros. Debido a que en esa época estaba potenciando un foro de coches creado por un amigo, propuse a la gente de La Casa del GPS, la posibilidad de vender un montón de ellos a los miembros de un foro y acordé un precio más conveniente con ellos. No os creáis que salió mucho más barata la broma, pero bueno. Si me roban el coche y no lo encuentro, el desembolso para hacerme con otro vehículo, seguro que es mayor.

En los estudios llevados a cabo por La Casa del GPS, el operador más rentable (en España) para utilzar con este tipo de dispositivo es Simyo. Incluso configurando el equipo para que envíe cada minuto su posición, costaba menos de 5 euros al mes hace dos años. Así pues, con la compra del GC-101FA, adquirí una tarjeta SIM de Simyo con un plan de datos. En estos dos últimos años, creo que el mes que más he pagado ha sido 3,3 euros, así que es todo correcto.

La instalación
  • Antes del do-it-yourself, probé el servicio al que tenía derecho con la compra del dispositivo y, sinceramente, amén de las trabas que hemos comentado anteriormente, la interfaz no me gustó en exceso.
  • En mi caso, la plataforma elegida fue mi CentOS Linux. Seguí los pasos dispuestos en el tutorial de instalación y configuración del proyecto OpenGTS. Me parece una tontería repetiros aquí los pasos. La documentación es bastante buena y como veréis requiere, entre otras cosas, de un servidor web Tomcat para que la aplicación funcione.
  • En mi caso, tengo Tomcat en la red interna y, para evitar publicar el servicio completo a Internet, tuve que hacer una sección en un Apache actuando como proxy inverso hacia el Tomcat cuando se llama a determinada localización. Nada que no haya explicado también otras veces en SbD.
  • El dispositivo GPS se configura, o mediante un cable USB y un software que viene con él, o mediante SMS, enviando un código de comando y determinados parámetros para que envíe la localización detectada al servidor correspondiente.
  •  Una vez que está correctamente parametrizado, las peticiones recibidas por Tomcat desde el dispositivo tienen el siguiente formato: GET /proxyquesea/Data?imei=[IMEI_del_GC-101FA]&rmc=[Posición_en_formato_$GPRC]. En este post viene explicado estupendamente los detalles del formato GPRC. Como bien podéis imaginar, si alguien falsea las peticiones conociendo las rutas y el IMEI del dispositivo GPS, podría generar posiciones aleatorias enviadas por mi coche y falsearían la posición donde se encuentra el mismo. No hay autenticación de ningún tipo en la petición; son meras GET en las que distinguimos el vehículo gracias al IMEI sumistrado como parámetro.
  • El GC-101FA trae una batería compatible con la de un móvil Nokia 8210 y tiene un par de horas de autonomía. Sin embargo, para monitorizar un vehículo en modo 24x7, es necesario suministrarle corriente de forma permanente. Así enviará la posición del mismo cada minuto sin problemas con la duración de la pequeña batería interna. Además, el dispositivo debería ir oculto dentro del vehículo, por lo que lo mejor es conectarlo a una toma de mechero del coche directamente a la batería. Otra opción es hacerlo a través de la caja de fusibles. Para ello, tomaremos la corriente mediante un fusible que sepamos que nos entrega energía de forma permanente, aunque no exista contacto bajo llave. Este es un blog de seguridad, por lo que las clases de electricidad y mecánica del automóvil, si alguien se anima y necesitáis ayuda, me lo comentáis en un correo y os explico cómo proceder para dar con un fusible válido. OJO: Añadir un dispositivo que está permanentemente conectado genera un consumo fijo esté o no el coche andando, por lo que la vida útil de la batería disminuirá. Este disclaimer tengo que ponerlo, aunque también os digo que en mi caso tengo varios cacharros conectados siempre y no he tenido problemas de momento.
  • La aplicación en el servidor Tomcat, se despliega en un fichero .war, y recibe las peticiones web del dispositivo, almacenando la información relativa a la posición enviada por el mismo en el formato GPRC (como la latitud, longitud, altitud, etc,...) en una base de datos MySQL dentro de la misma máquina (por defecto).
  • El GC-101FA es capaz de guardar además la altura a la que está el dispositivo (o en mi caso el coche). Utilidad para mí no tiene ninguna, pero siempre es interesante el poder ver de qué altura era el puerto por el que pasaste si no tienes la wikipedia a mano. Sin embargo, OpenGTS no implementaba la funcionalidad necesaria para quedarse con este dato, aunque la base de datos sí que lo contemplaba en su parámetro "altitude". Así que, ya que estaba, me pegué un rato navegando entre todo ese código Java para implementar lo necesario y poder parsear el parámetro de la altura y que lo insertara en mi base de datos también. Una vez hecho esto, lo empaqueté en un .war nuevo y lo desplegué en mi tomcat de nuevo. Las modificaciones que hice son tan complicadas como las siguientes en la aplicación gc101:
[root@Carmen gc101]# diff Data.java Data.java.orig
328d327
<         double  altitude  = isValid? StringTools.parseDouble(fld[12], 0.0) : 0.0;
364d362
<         evdb.setFieldValue(EventData.FLD_altitude    , altitude);
  • Luego, el interfaz web que proporciona OpenGTS, procesa las coordenadas GPS almacenadas, resolviendo mediante Google Apps, localizaciones entendibles por humanos (es decir, nombre de calle, número, ciudad, etc…), así como calculando la velocidad del dispositivo entre un punto y la posición anterior. Lo podéis ver en la imagen siguiente:

  • Una pena que no exista una aplicación para Iphone que permita acceder a este fantástico interfaz en tiempo real. Para casos en los que aparcas en un lugar en el que, ya sea por la grúa o los amigos de lo ajeno, puedas tener la tranquilidad que al salir de la reunión en la que estás, no tengas que volver a casa en taxi, haciendo una escala en la comisaría para denunciar un robo.
  • Así pues, ya que guardo en una base de datos de mi servidor las coordenadas e información necesaria, me decidí a implementar un sistema que, esté donde esté, pueda saber si todo sigue donde lo dejé. Para ello, aproveché el bot controlable por mensajería instantánea que utilizo para otras mil cosas como encender/apagar el aire acondicionado/calefacción de casa y/o la alarma , o para monitorizar si la roomba está limpiando, entre otras locuras,…  y le añadí una nueva funcionalidad. Ahora si, vía mensajería instantánea, a mi bot le escribo el comando "dnd N" me devuelve las N últimas posiciones registradas por el dispositivo GPS en las que ha estado mi coche. Como envía la posición cada minuto, puedo ver la posición en "formato humano" de los N últimos minutos registrados. Sorprendentemente, Google devuelve la dirección con bastante precisión.


El código perl necesario para lograr esto es el siguiente:

  if ($message =~ /^dnd/i)
  {               
        my $dbh = DBI->connect($dsn, $db_user_name, $db_password);
        my $num=1;
        if ($#fields >= 1 ) {$num=$fields[1];}
        my $tosend="";
        my $sth=$dbh->prepare("select address, deviceID,creationtime,longitude,latitude from EventData order by creationtime desc limit 0,$num");
        $sth->execute();
        my @longs,@lats;
        my $cuantos=$sth->rows;
        my $voypor=0;
        while (my ($donde,$device,$creationtime,$longitude,$latitude)=$sth->fetchrow_array())
        {
            utf8::decode($donde);
            my $dt = DateTime->from_epoch( epoch => $creationtime, time_zone => "Europe/Madrid" );
            if ($voypor > 0)
            {
                 if ( (@longs[$voypor-1] ne $longitude) && (@lats[$voypor-1] ne $latitude) ) 
                 {#No son iguales que la anterior, meto esa posicion en el array
                       my $dmy = $dt->dmy;
                       my $hms = $dt->hms;
                       $tosend.="El $dmy a las $hms el dispositivo $device estaba en $donde\n";
                       @longs[$voypor]=$longitude;
                       @lats[$voypor]=$latitude;
                 }
            }
            else
            {#Es la 0, pa dentro
                  my $dmy = $dt->dmy;
                  my $hms = $dt->hms;
                  $tosend.="El $dmy a las $hms el dispositivo $device estaba en $donde\n";
                  @longs[$voypor]=$longitude;
                  @lats[$voypor]=$latitude;
            }
      $voypor++;
    }

  • Ya puestos, por si no tengo claro dónde estoy a nivel de dirección, y ya que desde la mensajería instantánea, no puedo ver el mapa como para hacerme una idea, ideé otro mecanismo que, gracias a la API de Google, me envíe un enlace web con un mapa con las posiciones requeridas. Para eso, ejecuto el comando "dndm N" y así pido un mapa de las últimas N posiciones.



En el bot, el código necesario que tuve que hacer fue:


            
       if ($message=~ /^dndm/i)
       {#Donde con Mapa
           if ( ($cuantos > 1) && ($cuantos <= 5)) {$zoom=15;}
           elsif ( ($cuantos >5 ) && ($cuantos <= 10)) {$zoom=14;}
           elsif ( ($cuantos >10 ) && ($cuantos <= 15)) {$zoom=13;}
           elsif ( ($cuantos >15 ) && ($cuantos <= 20)) {$zoom=12;}
           elsif ( ($cuantos >20 ) && ($cuantos <= 25)) {$zoom=11;}
           else {$zoom=10;}
           my $urlbase="http://maps.google.com/maps/api/staticmap?zoom=$zoom&size=640x640&maptype=roadmap&markers=color:green";
           my $puntos; 
           for (my $i=0;$i<$cuantos;$i++)
           {
               $puntos.="|$lats[$i],$longs[$i]";
           }    
           my $url=$urlbase.$puntos."&path=color:0xff0000ff|weight:".$puntos."&sensor=true";
           my $urlapi = 'http://tinyurl.com/api-create.php?url=';
           my $ua = LWP::UserAgent->new;
           my $response = $ua->get($urlapi.$url);
           if ($response->is_success) 
           {
               $tosend.=$response->content;
           } 
           else
           { 
               $tosend.=$url;
           }
       }

  • Al pinchar en el enlace que nos envía el bot, podemos ver una representación en google maps como la siguiente:


Leer más...

26 octubre 2011

Entrevista a Klondike

Klondike a la izquierda, foto por
Juan Traverso Viagas 
Si eres asiduo a acudir a eventos de tecnología, cómo puede ser Campus Party, es posible que conozcas a Klondike. Klondike es un interesante Valenciano que, entre otras cosas, se dedica a colaborar con el proyecto Gentoo Hardened y a dar charlas de seguridad en eventos de tecnología.

Le hemos hecho unas cuantas preguntas "de lo suyo" y nos ha contestado gustosamente.

- Antes de nada, cuéntanos. ¿Quién es klondike y a qué se dedica?

Klondike es un ser, según algunos humano, que se dedica a trabajar de "puta". Bromas aparte soy una persona a la que le gustaban todas las ramas de la informática y cuando tuvo que tomar la decisión de cual coger fue por la de seguridad por ser la más extensa. A partir de ahí todo ha sido cosa de dedicarle horas.

- Te vimos en Campus Party Valencia 2011 ofreciendo una ponencia en la que se trataban vulnerabilidades, mitigaciones y algo de kernel hacking. ¿Cuándo podremos volver a verte?

Cuando queráis, por lo general no suelo rechazar invitaciones.

- ¿A qué se dedica tu empresa?

Como cualquier empresa a tratar de conquistar el mundo, un mercado cada vez. Queremos ofrecer soluciones basadas en virtualización clarificando las medidas de seguridad que implementamos, cosa que se echa de menos en el resto de proveedores.

- ¿Qué hace exactamente un Valenciano en el proyecto Gentoo Hardened?

Pues bastantes cosas, me encargo de fomentar el diálogo en la comunidad y de los medios sociales, también de ir actualizando y escribiendo nueva documentación lo que implica tener muy claro como funciona todo (y he de reconocer que en esto el resto de desarrolladores y el equipo de PaX me ayudan). También arreglo problemas con ensablador que no cumple con PIC en Gentoo Hardened (entre otros paquetes que han pasado por mis manos está aircrack). También me dedico a evangelizar sobre las "bondades" de Gentoo y Gentoo Hardened y por último ayudo al resto del equipo en sus tareas de desarrollo cuando me necesitan.

- Para entorno de escritorio, entre Gentoo Hardened, Debian con grsecurity instalado y bien configurado, o la última versión de Ubuntu con las protecciones que ellos se encargan de implementar, ¿cuál eligirías y por qué?

Gentoo Hardened, no porque sea desarollador sino porque es mucho más seguro. Debian no tiene binarios con PIE por lo que cosas como ASLR no funcionarían tan bien. El caso es similar en Ubuntu. Para muestra un pequeño estudio hecho aún cuando el proyecto tenía serios problemas con el toolchain (por eso SSP no sale activado en Gentoo).

- ¿Qué opinas de QubesOS? Ése sistema operativo que está desarrollando el equipo de Joanna Rutkowska y que, desconfiando de todo, crea y destruye máquinas virtuales a modo de sandbox para correr las aplicaciones.

Personalmente me parece una idea genial para fomentar el aislamiento entre dominios pero creo que cometen un par de errores bastante graves, no hablan de como endurecen el Dom0 (lo que es un serio problema pues una máquina virtual podría ser capaz de saltar a través del hipervisor), por otro lado usan xen que trabaja a un nivel más alto que por ejemplo KVM por lo que parches como grsec serán más difíciles de ver y un fallo de seguridad puede ser más malévolo.

Por cierto, me hace gracia ver como en su página web hablan de líneas de código. Generalmente los fallos más graves están en el diseño de la aplicación no en el código.

- Cinco aplicaciones que sean imprescindibles en tu PC.

Te diré 6 :P

KDE, firefox, thunderbird, ssh, wireshark y nmap.

- ¿Crees que la protección en la creciente cantidad de dispositivos móviles también pasa por las mitigaciones?

Mitigar el daño de un ataque es casi tan importante como evitarlos, por lo que no me extrañaría que empiecen a tomarse esto en serio. Al fin y al cabo es preferible que un hacker te cuelgue el móvil a que pueda instalarte un keylogger ¿no crees?

- Hace no mucho Apple implementó ASLR en sus dispositivos móviles, ¿crees que será la tendencia?

Es un buen comienzo y probablemente empiece a ser la tendencia. Lo que no entiendo es como no han pillado los parches de PaX en android todavía ;)

- ¿A qué se dedica klondike cuando no tiene un PC entre manos?

Entre otras cosas a mezclar música con... Oh wait un PC! Y a dirigir la asociación estudiantil en mi edificio utilizando un... PC. Vaya, quizás nunca deje de tener un PC entre manos más que cuando duermo.

- Tres libros técnicos, y tres no técnicos.

No voy a recomendarte ningún libro técnico ni ninguna revista, alguien me dijo alguna vez que los libros tienen esa costumbre de quedarse obsoletos y lo mejor es estar al día usando medios como Internet.

Libros no técnicos:

* Copia este libro de David Bravo puesto que explica las burradas hechas en nombre del copyright.

* Cualquiera de las aventuras de Jerónimo Stilton para los peques ya que es de los pocos que convencen a mi hermano pequeño para que lea.

* Mundo Artificial : Internet, Ciberpunk, Clonación y Otras Palabras Mágicas, de Antonio Dyaz. La verdad es que es un must read aunque tiene más de ficción que de realidad.
Leer más...

25 octubre 2011

Análisis de Jynx (Linux Rootkit)

Últimamente poco se había innovado en el campo de los Rootkits para sistemas Linux, muy atrás quedaron los tiempos en los que 'adore' (LKM) o 'SuckIT' (parcheo de la memoria en caliente) marcaban el paso en cuanto a rootkits para sistemas Linux.

Poco a poco el Kernel de Linux ha ido evolucionando y haciendo bastante mas compleja la labor de modificarlo para esos fines, así que actualmente la forma mas efectiva de instalar un rootkit en un sistema Linux es ir hacia la parte 'userland'

De esta clase de rootkits existen dos tipos, o bien los que cambian los típicos binarios del sistema asociados a obtener información (ps y amigos) y los rootkits más sofisticados que inyectan una librería en los procesos.

Desde hace tiempo han existido rootkits que actuaban de esa forma, pero habían permanecido un tanto ocultos, hace relativamente poco se ha hecho pública una implementación completa y funcional de un rootkit con capacidad para infectar un sistema Linux actual, su nombre: Jynx

Este tipo de rootkits actúan inyectando una librería compartida (.so) en todos los procesos del sistema.

Aun a riesgo de que un purista encuentre objeciones, podemos decir que este tipo de vectores en Linux serían análogos al 'API Hooking' en Windows, las librerías .so serían el análogo a las Dlls y el fichero /etc/ld.so.preload sería el análogo a la clave de registro

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

En resumen, lo que hacen este tipo de rootkits es añadir una línea en el fichero /etc/ld.so.preload apuntando hacia la librería del rootkit en la que se encuentran 're-escritas' ciertas funciones asociadas a la obtención de información del sistema. Luego, será el propio sistema Linux el que se encargue de hacer que cada proceso creado en el sistema lleve cargada esa librería con las funciones alteradas. La única salvedad son los binarios compilados de forma estática.

Si miramos en el fichero ld_poison.c de Jynx podemos ver claramente que funciones del sistema van a ser re-escritas:

static int (*old_fxstat)(int ver, int fildes, struct stat *buf);
static int (*old_fxstat64)(int ver, int fildes, struct stat64 *buf);
static int (*old_lxstat)(int ver, const char *file, struct stat *buf);
static int (*old_lxstat64)(int ver, const char *file, struct stat64 *buf);
static int (*old_open)(const char *pathname, int flags, mode_t mode);
static int (*old_rmdir)(const char *pathname);
static int (*old_unlink)(const char *pathname);
static int (*old_unlinkat)(int dirfd, const char *pathname, int flags);
static int (*old_xstat)(int ver, const char *path, struct stat *buf);
static int (*old_xstat64)(int ver, const char *path, struct stat64 *buf);

static DIR *(*old_fdopendir)(int fd);
static DIR *(*old_opendir)(const char *name);

static struct dirent *(*old_readdir)(DIR *dir);
static struct dirent64 *(*old_readdir64)(DIR *dir);

Y ahora un ejemplo real, he infectado con este rootkit un sistema linux ocultando dos procesos a la vista de ps y derivados, he creado un proceso bash y otro nc ocultos.

[campus@... ~]$ ./nc -l 9000

Si interrogamos a ps en busca de procesos nc:

[root@... ~]# ps aux | grep -i nc
[root@... ~]#

El comando ps no ve nada.

Ahora vamos a usar Unhide para detectar estos procesos. De entrada, si Unhide está compilado estáticamente (como se recomienda en el manual) es totalmente inmune a esta clase de rootkits, no obstante vamos a usar una versión de Unhide compilada de forma normal debido a que -lamentablemente- la mayoría de distribuciones Linux lo empaquetan así.

Empezamos con un escaneo empleando syscalls

[root@... unhide-20110113]# ./unhide-linux26 sys
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through getpriority() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through getpgid() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through getsid() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getaffinity() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getparam() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getscheduler() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_rr_get_interval() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through kill(..,0) scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through  comparison of results of system calls

[*]Searching for Hidden processes through sysinfo() scanning

HIDDEN Processes Found: 2       sysinfo.procs = 143   ps_count = 142

¡¡ Bingo !! los procesos son detectados, el comando identificado y también la ruta en la que se encuentra.

Ahora vamos a probar un escaneo empleando los tests proc

[root@... unhide-20110113]# ./unhide-linux26 procall
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through /proc stat scanning

[*]Searching for Hidden processes through /proc chdir scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through /proc opendir scanning

[*]Searching for Hidden thread through /proc/pid/task readdir scanning

En este caso el rootkit ha bloqueado y ocultado la presencia de los procesos ante stat, readdir, opendir y readdir pero como Unhide también emplea chdir ha caído en ese test.

Conclusión: Este tipo de rootkits son bastante efectivos a la hora de hacer su trabajo, pero no son infalibles.
Leer más...

24 octubre 2011

Create tu pequeño HAL para el cracking de contraseñas con GPU

La semana pasada comentaba que gracias al sistema monetario de bitcoin ya hay decenas de granjas de alto rendimiento de procesado basadas únicamente en tarjetas GPU (generalmente AMD/ATI) domesticas.

Hoy vamos a ver los componentes para replicar uno de estos equipos. Teniendo en cuenta las siguientes características:
  • El  presupuesto ha de ser lo más ajustado posible
  • Componentes como la memoria RAM, CPU o el  disco duro, ya que no afectarán al rendimiento de la GPU, serán lo mínimo imprescindible.
  • Alta potencia eléctrica para alimentar las tarjetas gráficas.
  • Las tarjetas estarán basadas en tecnología AMD/ATI, ya que tienen mucho mayor rendimiento/coste en esta tarea que nVidia.
  • Este equipo no aplicaría a otros tipos de cracking de contraseñas, como las que usan rainbow tables.
  • El equipo propuesto es un ejemplo y no he comprobado que todo rula como debería. 
Placa base
Generalmente se eligen placas base sin tarjeta gráfica integrada, ya que al instalar más de una aceleradora estas pueden tener problemas. Lo más importante es el número de buses PCI-e que soporte, ya que como mínimo debería tener tres GPUs.

Una opción interesante es Gigabyte MA770T-UD3, que permite conectar hasta 4 tarjetas utilizando cables prolongadores (slot riser). Esta placa debe tener un precio que ronde los 85€, más los 2€ por cada uno de los cables.

CPU
Como hemos comentado anteriormente la CPU apenas es utilizada y los costes de estas son muy altos por lo que es recomendable irse a lo más económico posible en socket AM3, como el Seprom 140 ó 145, no debería superar los 40€.


RAM
Al igual que ocurre con la CPU, la RAM y sus características no mejorarán el rendimiento del cracking de contraseñas con la GPU. Aun así, se puede tirar la casa por la ventana y comprar un DIMM de Patriot de 2Gb DDR3-1066, que ronda los 13€.

Tarjeta Gráfica
Aquí es donde realmente está toda la ciencia. Si se observan y estudian los datos, no merece ni de lejos irse al último modelo de ATI, siendo mucho más rentable tener 4 tarjetas con un 5850, que por ejemplo solo 2 6990. El problema está más bien en encontrarlas en el mercado a día de hoy. La alternativa en cuanto a la mejor relación de velocidad/coste es la 6950 y no debería disparar demasiado el precio. Sobre los 200€-220€ por tarjeta. Eso sí, toca multiplicar por 4. Modelos de Nvidia ni los comento. ¡Esas tarjetas para los gamers!


Fuente de alimentación
Darle "chicha" a 4 tarjetas gráficas no es una tarea sencilla, este es otro factor crítico y caro. 1000W y  conectores para 8 PCI-e (2 por tarjeta), por ejemplo: Cooler Master Silent Pro Gold 1000W. El precio debe acercarse a  los 215€.


Disco Duro
Apenas hará falta disco duro, el sistema operativo y la herramienta. El más pequeño y barato que exista. Por poner un ejemplo, Samsung 500GB HD502HM, que se aproxima a los 40€.

Caja
El último componente es la caja donde se mete todo esto y no son fáciles de elegir y acertar. Una opción es Antec DF-85 que dispone de mucho espacio interior. Está disponible por aproximadamente 150€ en su panadería más cercana. Otra de las opciones que más se ve, es hacerse una caja a mano.... Aunque eso es, sin duda alguna, demasiado elaborado para mi.


En definitiva, si sumamos todo, tendremos el equipo listo por unos 1500€.

¿Me he ganado un puesto como comercial dependiente de MediaMarkt o no?
Leer más...

23 octubre 2011

Enlaces de la SECmana - 94

Leer más...

22 octubre 2011

Kevin Mitnick - The Art Of Deception (libro)

Hoy quiero hacer la crítica literaria a un libro que NO me he leido: "The art of deception (Controlling the Human Element of Security)" de Kevin Mitnick. Digo en este caso que no me lo he leído, porque realmente lo he disfrutado en otra modalidad: Escuchado en audiolibro. Debido a diferentes viajes que he tenido que hacer, me ha dado tiempo a completar casi entera una de las obras del conocido Mitnick.

He de decir que si el inglés escuchado (en este caso leído por Nick Sullivan y bastante entendible) no se os da mal, es una muy buena opción, si hacéis muchos kilómetros y os toca conducir, por lo que el formato ebook, PDF o el clásico papel no se contempla como una posibilidad viable.

Después de este pequeño offtopic paso a contaros mis impresiones. Mitnick deja claro en esta obra que en las organizaciones, muchas veces da igual cuánto se invierta en dispositivos de seguridad para cumplir normativas o para que los responsables de la información puedan dormir mejor por la noche. Así como las máquinas hacen aquello para lo que han sido diseñadas o programadas, las personas que forman parte de las organizaciones y las empresas, son el punto débil.

¿Por qué? pues porque las personas siguen su instinto, y dependiendo del grado de paranoia con el que hayan sido educados o formados, serán más o menos fáciles de manipular. En el libro (a partir de ahora, aunque haya sido audio), se dan varios ejemplos de situaciones (reales o no, pero podrían serlo perfectamente) por las que un Ingeniero Social, contando con un pequeño hilo del que tirar, con un mínimo de información inicial, generalmente pública, es capaz de "engañar" a una persona aprovechándose de vulnerabilidades intrínsecas a su personalidad. Desde despertar sensaciones como la confianza, el colegueo, la admiración o la falsa sensación de seguridad, entre otras,... llevan a una persona a divulgar información muy valiosa a un completo desconocido. Muchas veces ese desconocido, simula ser un compañero nuevo de otro departamento o simplemente ofrece datos a la persona a engañar que la lleven a pensar que efectivamente, el ingeniero social dice la verdad. Muchas veces el "pedir un favor a un colega" o el "ofrecer un favor a cambio de nada", pueden dar lugar a este tipo de engaños.

A veces, el atacante provoca un problema a la víctima y le llama preguntando si le falla algo en el ordenador, simulando ser el chico nuevo de IT y se ofrece a arreglarlo. Evidentemente a cambio de ello, se hace con su objetivo de obtener una contraseña de un usuario "para probar si desde aquí puedo acceder" o indicarle de dónde ha de descargar un programa que a otros compañeros le ha solucionado el problema y cosas de ese estilo, implicando la instalación de un bonito troyano. 

Por cada "caso o llamada", Mitnick hace un análisis explicando por qué la víctima ha picado y cómo el atacante ha aprovechado un punto débil de una organización, por exposición pública de información interna que podría considerarse inofensiva en un primer momento, y cómo el ingeniero social ha hecho correctamente los deberes, adelantándose a las diferentes respuestas del interlocutor a engañar. Evidentemente, además de saber aprovecharse de la falta de agudeza (por decirlo suavemente) de las víctimas, el ingeniero social ha de tener la destreza suficiente para improvisar, así como el desparpajo y rapidez para llevar a su víctima donde él quiere.

Además, de análisis de cada caso, hay diversos "Mensajes Mitnick" en los que se indica cómo educar y formar a los empleados suficientemente para desconfiar de aquellas llamadas que incluso viniendo de un origen que puede ser real, mitigando los riesgos de dar directamente información sensible, como contraseñas o números de tarjetas de crédito o de la seguridad social a alguien que no se conoce personalmente.

Asimismo, en cada caso se indica el Lingo necesario para cada caso. Es decir, qué palabras clave se han utilizado dependiendo de cada entorno, para dar una mayor sensación de control y crear confianza en la víctima.

La cuarta parte de la obra se parece más a lo que esperamos de un libro de seguridad. Es más una guía de cómo entrenar al personal de nuestra organización, cómo auditar si dicho personal ha sido convenientemente entrenado y evaluar su reacción ante este tipo de ataques, etc, etc,...

El libro en general es bastante ameno y, aunque en ocasiones dices: "Anda ya! cómo va a picar alguien con eso,…" si se piensa fríamente en alguien que no ha recibido esa dosis de perspicacia ante preguntas que provienen de alguien que ya ha generado confianza suficiente, y que inicialmente parecen de lo más normales, puede resultar perfectamente posibles.

No quiero destripároslo más, simplemente puedo decir desde aquí que recomiendo su lectura. En la formación de cualquier persona expuesta a un riesgo por parte de un Ingeniero Social, es decir, todo el mundo, nunca está de más aprender o simplemente recordar conceptos, aunque en muchos de los consejos y situaciones, pensemos que es algo que ya sabemos o que simplemente, no picaríamos.
Leer más...

21 octubre 2011

Mining de Bitcoins - El mundo de las GPU

Ya casi todo internauta y aficionado a la economía conoce  Bitcoin, la divisa basada en el sistema monetario electrónico, que mantiene independencia de un emisor central, (como el Banco de España) y permite almacenar y transferir sumas de forma anónima.

Bajo un modelo P2P y de cifrado asimétrico,  es necesaria la generación de nuevas monedas en base a trabajo computacional denominado "mining". Lo que sería el equivalente en el mundo real a la búsqueda de oro. Aunque yo si os soy sincero, más bien recuerdo el WarCraft y los mineros que andaban con el pico en las minas. 

Este proceso finalizará cuando todas las monedas existentes sean encontradas y se ha diseñado para que con el paso del tiempo y desde su creación, buscar o minear Bitcoins sea haga más complejo y requiera cantidades mayores de cálculo. A día de hoy, un PC normal y corriente es prácticamente imposible que encuentre nada, pese a que tan solo 7.5 millones de los 21 posibles, están en el mercado.



Aunque parezca mentira, los Bitcoins desde hace tiempo se pueden utilizar para pagar en algunas tiendas online, hostings, servidores de VPN y hay sitios donde incluso lo cambian por dolares. Lo que ha generado que sea rentable la obtención de la moneda. Tanto legal e ilegalmente.

Ilegalmente ya se han detectado bichos de malware dónde el propósito era generar una botnet de ordenadores con potentes GPU para hacer mining y encontrar monedas. O más rápido aún, bichos que directamente mandan tus monedas a una dirección de correo electrónico.

Legalmente decenas de usuarios han montado clusters domésticos de ordenadores llamados bitcoins rigs, que tienen hasta media decena de potentes GPUs que única y exclusivamente "pican piedra digital".

Uno de estos ejemplos se puede ver en el foro bitcointalk, donde muchos usuarios ponen algunas de sus fotos:




¿Qué harán todos estos cyber gold finders cuando terminen de buscar monedas? ¿y cómo serán sus rigs dentro de 5 años? Lo mismo les da por participar en equipo en concursos para factorizar RSA y nos da a todos la risa.
Leer más...

20 octubre 2011

Seguridad en Redes Wireless

Este artículo tratará de explicar cómo funcionan las redes Wireless basadas en 802.11g y 802.11i y en particular se centrará en el estándar de protección WPA2 basado en EAP y que dará la base para un segundo artículo donde se muestra un ejemplo práctico de configuración.

Antes de entrar en harina comentar que la información se ha obtenido de varias fuentes, de la experiencia propia y de compañeros y amigos de profesión y en particular del documentos "(In)seguridad en redes 802.11b", sirva, esto último, como homenaje al documento que cayó en mis manos hace muchos años y me introdujo en la seguridad de este mundillo sin cables.

La naturaleza de las redes wireless hace que cualquier persona pueda tener acceso a los datos que son enviados, debido a que estos utilizan como medio de transmisión el aire (ondas electromagnéticas). Esto plantea un problema añadido con respecto al cable. Para tener acceso a los datos transmitidos por cable se ha de tener acceso al mismo o a los dispositivos asociados. Para las redes wireless no es necesario, basta con que la señal viaje hasta nosotros.

Por tanto teniendo en cuenta esta perspectiva se han de implementar los mecanismos necesarios para mantener el nivel de seguridad que se requieren en muchos proyectos.

Actualmente existen varios estándares para la implementación de redes inalámbricas. En este documento se va a escoger el más extendido en Europa, 802.11b y 802.11i. La velocidad máxima de transmisión que permite el estándar es de 54 Mbps, aunque para que ésta se produzca se deben mantenerse unas condiciones óptimas (como apunte decir que el estándar 802.11n tiene un límite teórico de que puede llegar hasta 600 Mbps). Se debe tener en cuenta que a mayor distancia entre el emisor y el receptor menor velocidad de transmisión. Otro problema que se puede plantear son los elementos intermedios que pueden interferir en la señal, como pueden ser paredes, campos magnéticos o electrónicos, etc. El estándar 802.11b utiliza la frecuencia 2.4 Ghz que es la misma que utilizan otros dispositivos móviles, como GPS, Bluetooth, etc. Esto puede incidir (para mal) en la calidad de la señal. Las interferencias hace que se reduzca la velocidad.

Otro aspecto que puede producir reducción de la transmisión es la saturación del espectro debido al número de usuarios.

Por último comentar que existen dos tipos de antenas, omni-direccionales y direccionales. En las primeras, la emisión de la onda se produce en todas las direcciones, a discreción, útil para entornos abiertos donde la ubicación de las estaciones no está definida o es susceptible de ocupar cualquier situación física. El segundo tipo dirige la señal a un punto determinado, fuera del mismo la señal no es "audible". Ideal para conectar dos puntos.

Las redes wireless pueden funcionar de dos modos (topologías) diferentes.
  • Ad hoc: No hay ningún dispositivo de control. Directamente se conectan las estaciones entre si (peer-to-peer). La cobertura está limitada por el alcance de cada estación.
  • Infraestructura: Hay un dispositivo central de gestión denominado Punto de Acceso. Todo el tráfico pasa por este dispositivo (a modo de hub) y la limitación de la cobertura la marca el Punto de Acceso y todas las estaciones deben poder verlo.
  • Redes Mesh: Sólo a título informativo. Hay un modo de transmisión (desarrollado en entornos militares) que utilizan las dos topologías anteriormente descritas. Su cometido es poder llegar hasta nodos o estaciones que no son capaces de verse directamente. Por tanto se utiliza una topología en malla (de ahí que se denominen redes acopladas) por la que los mensajes son transmitidos directamente entre las estaciones aunque estás no estén gestionadas por el mismo Punto de Acceso.
Como se ha visto en el apartado anterior, existen dos elementos que se repetirán a lo largo del documento, Punto de Acceso (o Access Point) y estación (a partir de ahora cliente).

Para que un cliente se asocie a un Punto de Acceso debe autenticarse primero y asociarse después. Para que todo esto se produzca, el Punto de Acceso emite Beacom Frames con una frecuencia determinada con el SSID (Service Set IDentifier) o bien el Cliente puede enviar "Prove Request" con un determinada SSID, aquel Punto de Acceso que tenga el SSID responderá a la petición. Una vez identificado el Punto de Acceso, se pasa al estado de autenticación mediante los siguientes métodos:
  • OSA (Open System Authentication): Es un proceso de autenticación nulo, las tramas se envían en texto plano aun teniendo activado cualquier cifrado
  • SKA (Shared Key Authentication): Este método utiliza una clave compartida entre el Punto de Acceso y el cliente. El cliente envía un Authentication Request, el Punto de Acceso responde con un Authentication Challenge. El cliente a su vez, responde con un Authentication Response (cifrado) y finalmente el Punto de Acceso responde con Authentication Result. Es dentro del SKA donde se pueden utilizar los diferentes sistemas de cifrados existente para redes Wireless.
  • WEP (Wired Equivalent Privacy): De sobra conocido. No se va a hacer más mención del mismo por ser inseguro.
  • WPA (Wired Protected Access): Nació para paliar las deficiencias de seguridad de WEP. Está a medio camino entre el sistema WEP y el sistema WPA2, versión certificada del estándar 802.11i.
  • WPA 2 (Wired Protected Access 2): Sistema de cifrado creado a partir del WPA y que corrige vulnerabilidades del anterior.

ESTÁNDAR WPA2 (basado en EAP)

Directamente se va a pasar a describir el sistema WPA2 (802.11i) de autenticación. Huelga decir que no se describen ni WEP ni WPA por encontrarse bastantes vulnerabilidadesm, sobre todo, en el primer caso y porque WPA es parte de la implementación de WPA2.

El protocolo está basado en la capa 2 del estándar OSI y describe el modo de autenticación basado en EAP (Extensible Authentication Protocol). Define tres elementos:

  • Suplicante: Es el elemento que solicita la autenticación. Generalmente el Cliente.
  • Autenticador: Elemento al que se conectará el suplicante. Pasa la información al servidor de autenticación. Generalmente el Punto de Acceso.
  • Servidor de autenticación: Elemento que evalúa la autenticación del suplicante enviando una respuesta al autenticador. En este caso será un servidor RADIUS.
El protocolo EAP (que es una estructura de soporte, no un mecanismo específico de autenticación) puede transportar diferentes protocolos de autenticación, como TLS (Transport Layer Security), TTLS (Tunnel Transport Layer Security), MD5 (Message Digest 5), PEAP (Protected EAP), LEAP (Lightweight EAP), etc.

Definición de los tipos de mensajes de intercambio:
  • Request: Petición desde el Punto de Acceso al cliente
  • Response: Mensaje del cliente al Punto de Acceso
  • Success: Autorización del acceso
  • Failure: Denegación del acceso.
El transporte de los mensajes se realiza a través del protocolo EALPOL (EAL over LAN), protocolo desarrollado para entornos Ethernet. En dicho protocolo se pueden encontrar cinco tipos de mensajes:
  • Start: El cliente envía, a la dirección MAC multicast, a la espera de que el Punto de Acceso responsa.
  • Key: Una vez obtenido el acceso, el Punto de Acceso usa este mensaje para enviar las claves al cliente.
  • Packet: Los mensaje EAL que son transmitidos se encapsulan en este mensaje EALPOL
  • Logoff: Mensaje de desconexión enviado por el cliente
  • Encapsulated-ASF-Alert: No utilizado en la actualidad.
EAP-TLS está basado en el uso de certificado digitales X.509 para la autenticación del cliente y del servidor. En el protocolo TTLS, sólo se autentica el cliente.

WPA2 tiene dos modos de funcionamiento:
  • WPA2-ENTERPRISE: basado en el protocolo 802.1x explicado anteriormente, que utiliza los tres elementos ya descritos (suplicante, autenticador, servidor de autenticación).
  • WPA2-PSK (Pre-Share Key): Pensado para entornos personales, evita el uso de dispositivos externos de autenticación. Se han descrito ataques off-line contra los mismos basado en ataques de diccionarios o contraseñas débiles.
La gestión de claves en el protocolo WPA2 en modo ENTERPRISE se realiza siguiendo las siguientes pautas:

Tanto el servidor de autenticación como el suplicante generan dos claves aleatorias denominadas PMK (Pairwise Master Key) durante la fase de autorización y autenticación de 802.1x. Una vez finalizada la fase de autenticación, el servidor de autenticación y el cliente tienen PMK idénticas, pero el Punto de Acceso no, por lo tanto a través del uso de RADIUS copia la clave del servidor de autenticación al Punto de Acceso. El protocolo no especifica el método de envío de la clave entre ambos dispositivos.

Llegados hasta este punto aún no se permite la comunicación si no que deben generar nuevas claves, en función de la PMK, para ser usadas en relación al cifrado y a la integridad, formando un grupo de cuatro claves llamado PTK (Pairwise Transient Key) con una longitud de 512 bits.

Para asegurar el tráfico broadcast, se crea claves de grupos de 256 bits llamadas GMK (Group Master Key) usado para crear la GEK (Group Encryption Key) y la GIK (Group Integrity Key) de 128 bits de longitud cada una. Las cuatro claves forman GTK (Group Transient Key).

La última parte es demostrar que el Punto de Acceso tiene PMK idéntico, para ello lo valida el servidor de autenticación.

Este proceso se realiza cada vez que es asociado un cliente con un Punto de Acceso.

Y hasta aquí hemos llegado.

Espero que el artículo haya resultado interesante.

--------------------------

Contribución por Ricardo Ramos
Leer más...

19 octubre 2011

WinUnhide

Desde hace algún tiempo tenía en mente el portar Unhide a plataformas Windows, Unhide está muy ligado a plataformas Unix/Linux y el hacer un port a una plataforma como Windows suponía un reto interesante.

Finalmente he conseguido un port plenamente funcional sobre el que poder trabajar más adelante y añadir más funcionalidad.

Unhide es una herramienta orientada a detectar inconsistencias en el sistema operativo a la hora de mostrar los procesos que se están ejecutando y los puertos TCP/UDP que están en uso, este tipo de comportamiento suele estar asociado a sistemas troyanizados con 'rootkits'. Unhide consta de dos partes, una orientada a localizar procesos ocultos y otra para puertos TCP/UDP igualmente ocultados empleando algún tipo de rootkit.

La versión Unix de Unhide emplea el comando 'ps' para hacer un listado de procesos y ejecuta una serie de pruebas para discernir la fiabilidad de la información mostrada por ese comando. En el caso de Windows, existe una herramienta idéntica llamada 'tasklist' pero he preferido emplear la interface WMI para Windows con el comando 'wmic'.

En concreto estoy usando el comando 'wmic process get ProcessId' para hacer un listado de procesos visibles a través de este comando, posteriormente empleo openprocess() y Toolhelp para barrer un amplio espacio de PIDs intentando localizar procesos que sean accesibles mediante estas APIs pero no aparezcan con el comando wmic.

En el caso de Unhide-TCP, he preferido 'saltarme' la filosofía empleada en entornos Unix debido a que la idea de parsear el comando 'netstat' en Windows sin ayuda de sed / awk, me pareció bastante titánica. Probablemente usando pcre hubiese sido factible, pero me pareció complicar sobremanera el código así que usé otra aproximación al problema.

Lo que he hecho con WinUnhide-TCP es listar los puertos TCP/UDP visibles mediante las llamadas GetTcpTable() y GetUdpTable(), y luego emplear bind() sobre todo el espacio de puertos posible para detectar puertos que no aparecen listados con las llamadas anteriores y en los que no se puede hacer bind(), señal de que esas funciones han sido troyanizadas.

Existen herramientas 'anti-rootkits' para entornos Windows como por ejemplo GMER, que son bastante mas completas y complejas, mi idea es simplificar el concepto ejecutando una serie de tests que indiquen si el sistema se encuentra comprometido o no, en caso de encontrar indicios, sería el momento de entrar a usar herramientas más complejas para identificar exactamente el problema

Leer más...

18 octubre 2011

Cómo diseñar una política de cortafuegos

Aunque he de confesar que llevaba tiempo pensando en escribir un artículo con este título, ha sido a raíz de los comentarios que nuestros lectores dejaron en la encuesta que realizamos para conocer los intereses sobre los posts que os gustaría leer en SbD, lo que me ha impulsado a hacerlo ahora.

Muchas son las veces que me ha tocado analizar políticas de cortafuegos  de clientes con problemas, en los que he tardado más en hacerme un esquema mental de cómo es la topología de la red e imaginar en qué tienda ha comprado el criterio quien lo haya diseñado, que en dar realmente con el fallo de configuración.

Procesos tan vitales como aplicar una política de cortafuegos partiendo de una base ordenada, así como seguir unas buenas prácticas a la hora de hacer modificaciones, hacen que la política de seguridad sea más legible a la hora de entenderla, así como más eficiente en cuanto al procesamiento de las reglas.

Aquí van pues mis pasos y/o recomendaciones:
  • Suponemos que comenzamos partiendo de un dispositivo (o un clúster) que segmenta de forma correcta las redes que la organización desea separar. En este ejemplo, y como dicen los libros de matemáticas: "Sea un cortafuegos con cuatro redes diferentes: Una LAN, una DMZ de servicios públicos, una red DMZ de servicios privados (o accesibles sólo desde dentro) y la red de salida a Internet".
  • Un cortafuegos es, generalmente, un software implementado en un sistema operativo muy securizado y optimizado para tener un rendimiento óptimo en procesado y filtrado de paquetes, que interpreta las reglas que implementemos en modo Top-Down, es decir, por orden de definición. Si un paquete/conexión/sesión (dependiendo del cortafuegos) hace match con una regla, no se sigue procesando por las siguientes.
  • La regla 1 a definir en una política de cortafuegos que vamos a administrar de forma remota, es precisamente añadir una regla para permitirnos el acceso a los servicios de administración del propio cortafuegos, desde las direcciones IP de administración (sea SSH, HTTPS o el servicio cliente/servidor que corresponda). Ni sabéis la de veces que me habré autodenegado el servicio al aplicar una política de seguridad sin tener en cuenta esto, y la de paseos al CPD que me he pegado a modificar la política por consola o puerto serie.
  • Una vez definida la regla que permite la administración remota, habrá que crear la regla 2, que precisamente niega el acceso a los servicios de administración a TODAS las direcciones IP. Como las reglas se procesan de arriba a abajo, si la petición viene de una dirección IP permitida, entrará por la regla 1 y en caso contrario seguirá por la 2 hasta que haga "matching" en alguna. Si con estas dos reglas se abarca todas las posibles conexiones a la administración del equipo, siempre entrará por una de ellas. Esta regla es lo que se conoce como la "Stealth Rule"
  • A partir de aquí, para ser lo más eficiente posible, hay que pensar qué conviene más. Antiguamente, con dispositivos hardware limitados de recursos, había que tener en cuenta que los servicios más prioritarios a ofrecer (pensad en un servicio web o alguno en tiempo real o streaming), debían ir procesados al principio para dar una mejor satisfacción de usuario. Otra filosofía es poner al principio las reglas más utilizadas (tráfico web saliente o de correo, por ejemplo), dejando en últimos lugares aquellos servicios que se usan menos. En este caso, por estadística, un mayor porcentaje del tráfico se procesará antes. En dispositivos con una base de reglas a procesar "grande" o "muy grande" con mucho tráfico, el tener en cuenta este tipo de consideraciones, se nota en la carga del sistema. Actualmente, y dado los equipos hardware mastodontes de procesamiento que se utilizan, se nota menos. Un buen ejemplo lo tenéis en cómo, antiguamente, un programador se preocupaba de optimizar el número de variables a utilizar, así como la memoria a reservar en cada momento, dando lugar a verdaderas "joyas" con poco consumo de recursos. Ahora mismo, desde un Windows a un navegador se comen toneladas de memoria,…
  • Mi sugerencia es definir al principio las reglas para permitir los servicios prioritarios o, de negocio, de la organización. Lo más normal será dar acceso desde el Internet a las máquinas de la DMZ de servicios públicos. El orden a seguir es de mayor a menor prioridad, y de mayor a menor necesidad de "Tiempo Real". Por cada máquina (o grupo de máquinas) que dan un servicio habrá que crear una regla con los servicios a publicar. Yo sugeriría el siguiente orden (quitad aquellos servicios que la organización no ofrezca, claro está): HTTP/HTTPS, SSH, VNC, Terminal Server, FTP, VPN, SMTP. Nunca en la vida, a no ser que el cliente me obligara con una pistola en la cabeza, publicaría hacia Internet servicios de una organización como SSH, VNC y/o Terminal Server, pero en caso que se me requiera y, siempre y cuando se haga desde un número finito de direcciones IP, lo haría en ese orden para optimizar la experiencia del usuario que accede, al ser servicios interactivos.
  • Una vez se definen los accesos desde el exterior a la DMZ de servicios públicos, habrá que definir, al final de esa sección, una regla que prohiba el acceso desde Internet a cualquier servicio de dicha red. Es mejor prohibir accesos a la red completa, que comprenda todas las IPs de esa red, en vez de negar solo a las IPs de las máquinas existentes, de manera que si un día alguien sin avisar pincha una máquina nueva, queda correctamente filtrado.  
  • Si es necesario que desde la DMZ pública se acceda a servicios de la red DMZ privada (típico acceso a Sistema Gestor de Base de Datos, servidor de aplicaciones o accesos a servidor de correo con sus buzones desde un Mail Relay en la DMZ pública por ejemplo), será ahora cuando haya que crear dichos permisos. Importante es que se creen reglas específicas de máquinas origen de la DMZ pública a máquinas destino de la DMZ privada, exclusivamente a los servicios necesarios. Una vez terminada esa sección, habrá que definir una regla que prohiba acceso a cualquier servicio desde la red DMZ pública completa a la red DMZ privada también completa. Si nos compromenten una máquina en la DMZ pública, sólo podrán acceder a algunas máquinas a algunos servicios de la DMZ privada… no habiendo "barra libre". Habrá que tener en cuenta también qué servicios se permiten desde las redes DMZ privada y pública hacia Internet, hacia la LAN y desde la privada hacia la pública. Permitimos lo necesario explícitamente y negamos todo lo demás, evitando así, en la medida de lo posible canales de envío de shell inversas a través de servicios salientes innecesarios.
  • Las siguientes reglas a crear, por orden de importancia, serían las que permiten accesos desde la red interna LAN a la DMZ privada y a la red DMZ pública. Habrá que aplicar los mismos principios que antes, distinguiendo en este caso por redes origen (a no ser que el cortafuegos permita identificar a los usuarios de una forma más específica, no sólo por la IP origen, que en cualquier caso se puede cambiar para obtener mayores privilegios de acceso) para permitir lo justo y necesario a las DMZ, prohibiendo en una última regla todo lo demás a estas redes.
  • Finalmente habrá que definir las reglas de tráfico permitido desde la LAN hacia Internet. Al final de la sección, otra regla que prohiba todo lo no estrictamente permitido anteriormente.
  • Al final del todo, es típico y recomendable crear una regla llamada "Cleanup rule" o regla de limpieza que prohiba el tráfico desde Cualquier sitio hacia Cualquier sitio a Cualquier servicio. Es importante puesto que si hemos olvidado definir alguna de las reglas parciales de fitlrado entre redes, habrá tráfico que pase por aquí.
  • Hasta ahora, sólo he hablado de cómo definir reglas y qué permitir y qué negar. Sin embargo, me gustaría hacer un apunte a la hora de loggear o dejar un registro de aplicación de las reglas según el tráfico procesado. Los logs son sólo útiles si puedes leerlos y seguirlos. Si loggeamos TODO no habrá manera de monitorizar qué esta pasando en un momento dado, porque "los árboles no nos dejarán ver el bosque". Sin embargo, yo recomiendo loggear prácticamente todo lo que podamos que no sea absolutamente innecesario, como tráfico de broadcast, multicast, Netbios, DHCP, ARP, etc,.. que el firewall procese. Para ello, y si es un tráfico que entra por las reglas de prohibición de tráfico, recomiendo siempre crear una regla previa a esa, con las IPs de broadcast de la red o de broadcast genérico (255.255.255.255) en el destino, denegando el tráfico y marcando la casilla de NO Loggear el tráfico.
  • Si os dais cuenta, al principio del artículo he dicho cuál es la regla 1 a definir en el cortafuegos. Sin embargo, en la mayoría de los firewalls, existe un grupo de primeras reglas a procesar previa a la regla 1. Son las que se llaman reglas implícitas o "Regla 0", que suelen permitir o denegar "de fábrica" accesos a servicios de administración, o aquellos proporcionados por la propia máquina, como VPNs IPSEC/SSL/PPTP, DHCP, etc,...
  • Una parte muy importante en la definición de reglas es el rellenar el campo "Comentarios" que va al final de cada regla en casi todas las GUIs y que permite añadir una descripción para indicar qué hace concretamente dicha regla. Una vez más: documentación!
  • Una buena práctica después de definir una política de reglas es auditar desde las diferentes redes, los accesos hacia las demás, comprobando que la política está bien definida. Igualmente se aconseja monitorizar con especial dedicación los logs producidos, al menos al principio, corrigiendo en caso contrario la política si hemos dejado algo en el tintero.
Por cierto, que quiero agradecer desde aquí a Enrique Martín, mi buen amigo y ex-compañero de SGI,  que me enseñó las bases y me dió estas mismas guías cuando empecé a trabajar, implementando y posteriormente diseñando, políticas de seguridad en cortafuegos y otros dispositivos.
Leer más...