29 julio 2008

Sacándole el jugo a los IDS/IPS (II) - Configuración y afinamiento

En posts anteriores explicamos cómo llevar a cabo un despliegue de sondas IDS/IPS de la forma más óptima posible. Como lo prometido es deuda, en este post detallaremos cómo conviene configurar dichos elementos para que la información generada en forma de eventos de seguridad sea aprovechada por los Departamentos de Seguridad de las organizaciones.

La colección de dispositivos IPS/IDS con la que sembramos nuestra arquitectura de red anteriormente son capaces de enviar alarmas en caso de detectar/bloquear tráfico malicioso. En el momento de la configuración de dichos dispositivos (que traen una base de firmas genérica) se suele poner a registrar toda la actividad de la red durante un tiempo suficiente para obtener una muestra de suficiente calidad (generalmente una semana, aunque este tiempo puede variar). Esto se hace con el fin de evaluar los diferentes eventos detectados por las sondas IDS/IPS. A partir de aquí surgen dos posibles filosofías de afinamiento:

  • La primera sugiere afinar la política de alertas de red eliminando todos los falsos positivos, y eventos de severidad baja, de manera que solamente genere alertas en caso de ataques que puedan suponer un impacto importante para la organización. Esta filosofía también es conocida como “anomaly detection”. Así los operadores que reciban las alertas deberán poner en marcha un plan de contingencia para mantener el ataque bajo control.
  • La otra posible forma de configurar los IDS/IPS es afinar únicamente los falsos positivos y dejar todos los demás eventos activos, de manera que en caso de una intrusión, a la hora de realizar un análisis forense, contar con mucha más información para poder analizar los prolegómenos del ataque.

Ambas filosofías son muy opuestas en cuanto a la funcionalidad práctica (la segunda se hace ingestionable por recursos limitados en redes con mucha actividad), el mantenimiento y los costes de almacenamiento (a mayor verbosidad en el registro de eventos mayores necesidades de espacio en disco y mayor frecuencia de rotado de logs para poder manejar la información). Sin embargo la segunda posee como única ventaja el poder contar con un nivel de detalle excelente en casos post-mortem.

Según el ejemplo con el que contábamos en el posts anterior, teniendo mecanismos diferentes de IDS y de IPS, mi experiencia en estas lides me hace recomendar configurar los IPS de forma abnomally detection y los IDS en modo logging completo. De esta manera los IPS no tendrán que analizar una base de datos de ataques tan grande, priorizando también el rendimiento de los mismos, y los IDS guardarán datos de toda la actividad de red con un primer nivel de filtrado (por los IPS en caso de tráfico entrante/saliente).

En la siguiente entrega, aprovecharé para introducir un "juguete" nuevo en la infraestructura de seguridad de la compañía: los centralizadores/correladores de eventos.
Leer más...

28 julio 2008

apache-scalp

Ya hemos escrito sobre PHPIDS como solución para la detección de intentos de intrusión, pero hoy queríamos ampliar esta información con una herramienta de Romain Gaucher, llamada scalp, que permite en base a un fichero de registros de un servidor web detectar ataques, usando las propias reglas de PHPIDS.

Su uso es muy sencillo, consiste en un script programando en Python, (aunque está anunciada una futura versión en C++ multithread) que se ha de ejecutar pasándole como argumento el archivo a analizar, como por ejemplo, el archiconocido "access_log" de un Apache. A partir de ahí, generará un informe con las coincidencias detectadas.

Para instalarlo, basta con descargar el script de esta dirección: http://apache-scalp.googlecode.com/files/scalp-0.2.py, así como las reglas en formato XML actualizadas de PHPIDS, de la siguiente URL: https://svn.php-ids.org/svn/trunk/lib/IDS/default_filter.xmly dejarlas en el mismo directorio.

La siguiente imagen muestra la pantalla de ayuda al ejecutar sin argumentos la herramienta.


Mediante el argumento "-l" se indica cual es el fichero de logs, generando la salida en el formato deseado, por defecto en texto.


El siguiente ejemplo muestra un informe del resultado.



Leer más...

Gmail + DNI-E

Recientemente tuve que darme de baja en un servicio que me requería un correo electrónico para confirmar mi baja.

Enviando el correo electrónico, pensaba en que este tipo de procedimientos, en pleno 2008, deberían ser mucho mas fiables y que desde la llegada del DNI-e, no hay demasiadas excusas para no implantar mecanismos mas seguros. Al hilo de eso y dado que soy usuario habitual de Gmail, se me pasó por la cabeza que sería genial poder emplear mi Dni-e directamente en la interface web de Gmail (hasta ahora estaba usando Thunderbird para el firmado digital). Así que me puse a ver "el estado del arte" con respecto a firmado S/MIME en Gmail, al final di con esta extensión que hace justamente lo que yo buscaba.

La extensión aun está en etapas tempranas de desarrollo y no es plenamente funcional, en concreto Si puede hacer:
  • Firmar digitalmente un correo electrónico
  • Cifrar un correo electrónico
  • Descifrar un correo electrónico que nos haya llegado
Por contra, se echa y mucho de menos la verificación de firmas digitales, es decir, si alguien nos envía un correo firmado digitalmente no sera posible verificar la firma, ni a nivel certificado digital ni mucho menos comprobando CRLs.

Tal vez en este punto algún que otro lector este pensando en jubilar sus vetustas claves GPG y pasarse al apasionante mundo de los certificados digitales, antes de eliminar sus claves ha de saber que, el dni electrónico, provee dos certificados en el chip, Firma y Autenticación ¿que significa esto? básicamente que los certificados digitales NO están preparados par cifrar información, por tanto, con el estándar PKI en la mano, ningún certificado del DNI-e debería ser usado para cifrar correos electrónicos. Para el que se haya perdido y le resulte incongruente la situación, aclarar un par de puntos sobre certificados digitales, todos ellos contienen una clave publica y otra privada RSA plenamente funcional "para cualquier cosa" adicionalmente, cada certificado lleva inscritas sus extensiones que definen su propósito de uso y es ahí donde se define si un certificado sirve para firmar digitalmente, para autenticarse o para cifrar información (entre otras muchas opciones). En el caso del DNI-e, los certificados sirven para autenticación y firma. Obviamente tu eres libre de extraer las claves RSA de los certificados y usarlas "a pelo" para lo que te de la gana, pero estarías violando el estándar PKI

No obstante, si pretendes usar certificados digitales para cifrar y firmar correos electrónicos, Firefox tiene una extensión que te permite crear tus propios certificados a medida que deberían funcionar perfectamente con la extensión S/MIME.

Aclarado este punto, prosigo con un mini how-to usar el dni-e para firmar digitalmente correos en Gmail.

Dando por hecho que ya tienes configurado el dni-e en tu Firefox (existen ya muchos tutoriales escritos sobre el tema) esta guía debería funcionar tanto en Windows como en Linux.

La integración de Gmail S/MIME con Gmail es total, y el uso, de lo mas sencillo, una vez hayamos abierto el editor de correos para enviar un correo, podemos observar que aparece a la derecha, un símbolo de firmado (resaltado con el cuadrito en rojo), y un candado para cifrar. (las imagenes son 'clicables' para verlas completas)

Simplemente hemos de marcar esa opción para activar el firmado digital del correo, como consejo, es recomendable activar el uso de "solo texto" y de esa forma eliminar los tags HTML que pueden provocar warnings durante el procesado del correo. Una vez marcada esa casilla y escrito el texto, simplemente pulsamos enviar.

Al hacer esto, nos aparecerá una ventana indicando con cual de los dos certificados del DNI-e queremos firmar el correo, como hemos dicho antes, PKI en la mano, deberemos seleccionar el certificado de firma y no el de autenticación.

En esta ventana, habremos de introducir el PIN de nuestro DNI-e.

Si todo ha ido bien, nos aparecerá otra ventana que nos pedirá confirmación para el proceso de firmado

Una vez aceptada la ventana, se lanza el proceso de envío, que, en este caso, se hace mediante la interface SMTP de Gmail, por lo que nos pide que introduzcamos nuestra contraseña (la misma que para acceder via web a Gmail)


Si la petición de envío ha ido bien, veremos en la parte superior de Gmail un mensaje indicando que nuestro correo electrónico ha sido firmado y enviado


Espero que el tutorial os haya resultado útil y, si sois usuarios de Gmail, no tenéis excusa para no agregar a nuestro bot
Leer más...

24 julio 2008

DNS, pasaté al TCP

Mucho se ha hablado ya del famoso bug que afecta al DNS y del que recientemente se han conocido los detalles "mas íntimos" sobre la forma y manera de sacarle partido (con su correspondiente exploit).

De una forma muy resumida y digerible el asunto estriba en dos características del protocolo DNS tal y como está desplegado actualmente :


·La comunicación se realiza con un protocolo NO orientado a conexión (UDP) y por tanto susceptible de ser "spoofeado"
· Las transacciones (peticiones-respuestas) están marcadas con un ID que, si bien se han hecho esfuerzos por dotarlo de aleatoriedad, como se ha podido comprobar, no ha sido suficiente.

El protocolo DNS, tal y como está definido en la RFC 883 debería de ser capaz de atender querys tanto en el puerto 53-UDP como en el 53-TCP. Erróneamente mucha gente asocia únicamente la comunicación del protocolo DNS en formato TCP a las transferencias de zonas entre DNSs primarios <-> secundarios y cuando una petición excede los 512 bits. Incluso no es descabellado encontrar documentos de hardening en el que se propone como medida de seguridad bloquear el acceso al puerto TCP del DNS.

Lo cierto es que un servidor DNS debería de prestar servicio por el puerto 53-TCP de forma "normal" el problema está en que consuetudinariamente la gente ha usado siempre 53-UDP alegando motivos de eficiencia, motivos que, en origen, cuando se diseñó el protocolo DNS tenían mucho peso, el problema es que esos conceptos forman parte de la época del Gopher y la www por texto, donde unos pocos bits eran un lujo. En los tiempos actuales en los que cualquiera puede incluso emplear su ADSL para colgar enormes vídeos en formato flash de varios megas, no tiene demasiado sentido seguir con esas premisas.

A nivel seguridad, ¿que supondría pasar el protocolo DNS a TCP? En pocas palabras: adiós al spoofing de conexiones (parte básica en todos los ataques al protocolo DNS), cuando hablamos de conexiones TCP estamos hablando de un protocolo orientado a conexión, donde interviene en cada conexión lo que se conoce como "TCP Sequence Number" que es un numero aleatorio por cada conexión. Hace años (principio de los 90) el protocolo TCP adoleció de fallos en este sistema que permitía predecir dichos números volviéndolo vulnerable a ataques de tipo IP-Spoof. Actualmente y tras muchos esfuerzos, unánimemente se considera un mecanismo robusto y fiable ya que prácticamente todos los sistemas operativos cuentan con mecanismos muy probados para obtener la suficiente entropia.
Podemos usar Hping para comprobar la aleatoriedad del ISN sobre cualquier host de la siguiente forma:
hping -S -p 80 www.security-projects.com -Q
HPING www.security-projects.com (eth0 208.88.52.63): S set, 40 headers + 0 data
bytes
1144894739 +1144894739
1147953489 +3058750
1136625600 +4283639406
1137798400 +1172800
1150024660 +12226260
1147708505 +4292651140
1138715293 +4285974083

Como se puede observar, la forma en la que se altera el ISN no tiene ningún patrón predecible.
Con el cambio de UDP a TCP, un potencial atacante tendría que deducir el ISN de TCP y el DNS-query-ID para falsear una respuesta, algo prácticamente imposible.

A nivel rendimiento, ¿que supondría pasar el protocolo DNS a TCP? En este punto toca disfrazarse del Sr Solbes y sacar la calculadora para manejar correctamente los datos, Wireshark en mano, una consulta DNS por el protocolo UDP, de www.google.com en un Windows XP sp2 sale en:

4 Paquetes / 461 Bytes

Misma query usando TCP:

22 Paquetes / 1557 Bytes

Evidentemente, bajo UDP, el consumo de ancho de banda es infinitamente menor, y visto porcentualmente, puede que el dato sea demoledor, pero si nos fijamos en las cifras y sobre todo en el orden de magnitud que nos estamos moviendo (Bytes) ¿realmente supone tanta diferencia?
He buscado algún tipo de métrica online con datos fiables a-la-mrtg para tratar de hacerme una idea de lo que puede suponer multiplicar por dos el trafico DNS. Y si, estudios del estilo "El p2p ocupa el 80% del tráfico" hay cientos, pero con datos para ver, pocos. Finalmente he encontrado un proyecto de la organización CAIDA (si, un nombre poco apropiado para los hispanohablantes) que se basa en obtener métricas de "puntos neutros" al estilo de nuestro Espanix.

Ojeando dichos datos me llama la atención que el DNS no está entre los protocolos con mas consumo de ancho de banda, de hecho, ni sale en la lista ordenada por consumo de bytes hay que ir a las listas de flujos de datos (normal, el DNS se supone que ha de generar múltiples hits) para encontrar los datos de consumo que, según esas estadísticas, suponen un 0,18 %

Con esos datos en la mano (que no tienen porque ser ni parecidos a los de, por ejemplo, un ISP como telefónica) queda bastante claro que el cambio TCP por UDP no tiene que resultar especialmente traumatico.

¿Soluciones? A dia de hoy no resulta obvio ni trivial alterar los parámetros del sistema operativo para forzar que las consultas DNS se hagan mediante TCP, en Linux-Unix, el 'resolver' (la base donde se sustenta el mecanismo para resolver direcciones), está preparado para hacer consultas vía TCP empleando la opción RES_USEVC, pero sorprendentemente, esta opción no se puede configurar desde el fichero /etc/resolv.conf (otras muchas, si). Resultaría trivial hacer unas pequeñas modificaciones para soportar esta funcionalidad. En el caso de sistemas Windows no costaría mucho adaptar el sistema y dejar al usuario la opción de añadir una clave en el registro para activar-desactivar esa opción.

A nivel servidores, (Bind, DJB y cía) como ya hemos visto, nativamente soportan querys vía 53-tcp, no costaría demasiado adaptarlos para que empleen un mecanismo al estilo "primero intento TCP, si falla, lo envío por UDP", ajustando muy muy bien los 'timeouts' para identificar con suficiente celeridad que servidor DNS esta dispuesto a resolver por TCP y cuales no.

Queda un ultimo punto: el desempeño en enlaces con poco ancho de banda (PPP, GSM, y similares) obviamente esta claro que ese tipo de conexiones iban a sufrir bastante por la falta de rapidez en realizar las transacciones DNS, por eso, la solución necesariamente tendría que ser como he comentado antes, dejar al usuario los mecanismos para decidir si necesita UDP o TCP.

¿Que se puede hacer ahora? Con todo lo expuesto anteriormente, si se puede hacer algo, al menos, para securizar nuestro entorno (Red local, nuestro PC). Después de investigar bastante el tema, buscar y probar varias implementaciones de DNS Cache e incluso plantearme hacer mi propio DNS-proxy, di con un software que hace justo lo que yo tenia en la cabeza: Admite querys en formato UDP (necesario para la comunicacion PC<->DNS) y re-envía la petición al DNS principal en formato TCP, su nombre: Pdnsd (Para linux).

La configuración que se puede hacer con este programa corresponde a este esquema:


Como se puede ver, la comunicación desde nuestro PC / un equipo de nuestra red, hacia el cache DNS va en formato UDP "atacable" pero la comunicación hacia el servidor DNS principal, en internet, va en formato TCP con lo que restringimos el riesgo de ataque a nuestra propia red, cosa bastante menor ya que si alguien pretende atacarnos desde nuestra intranet o nuestro PC, tendríamos bastantes mas problemas de los que preocuparnos.

Un ejemplo de configuración para Pdnsd de cara a usarlo en local (para tu propio PC, no como DNS cache para toda tu intranet) sería ésta

En este punto solo nos hace falta localizar un servidor DNS recursivo que acepte querys por el puerto TCP, como ya hemos dicho anteriormente, muchos ISPs cierran ese puerto o impiden que se acepten querys por el 53-TCP. Para comprobar si un servidor DNS acepta peticiones al 53-tcp podemos usar la herramienta dig con los parametros +vc

dig +vc www.google.com @dns.ya.com

; <<>> DiG 9.2.3 <<>> +vc www.google.com @dns.ya.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38295 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 7, ADDITIONAL: 7 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 577445 IN CNAME www.l.google.com. www.l.google.com. 245 IN A 66.102.9.99 www.l.google.com. 245 IN A 66.102.9.104 www.l.google.com. 245 IN A 66.102.9.147

Como se puede ver, el DNS de ya.com acepta y resuelve bien por el puerto 53-TCP
Leer más...

21 julio 2008

Sacándole el jugo a los IDS/IPS

Conocidos como mecanismos de detección o prevención de intrusiones, los IDS/IPS se han convertido en un "must" en el SIMO de dispositivos que han de tener las organizaciones como mecanismos de seguridad en su infraestructura.

Dependerá del uso que se les vaya dando a estos dispositivos, que se conviertan en herramientas útiles que aporten valor en el proceso de la seguridad de las organizaciones, o se conviertan en unos "cacharros" más, cuyo mantenimiento engrose la lista de tareas de los administradores. Ya que todos los dispositivos que forman parte del stuff de una compañía requieren un mantenimiento (backups, actualizaciones, parches, licencias,...) por lo menos vamos a dar las pautas para que la utilización de sondas de detección/prevención de intrusiones puedan resultar útiles en su funcionalidad.

Antes que nada, quiero dejar claro que las sondas IDS son dispositivos que se posicionan offline del flujo de las redes, de manera que reciben una copia del tráfico de cada VLAN (mediante la utilización de TAPs físicos o con la creación de un port mirroring o port span de una VLAN de un switch capaz de hacerlo). Por un interfaz sin pila TCP/IP reciben el tráfico en formato RAW y lo analizan enfrentándolo contra una base de datos de firmas de ataques conocidos, de manera que, a través de otro interfaz, cuando detectan tráfico malicioso, envían señales de alarmas a una base de datos centralizada. Estos dispositivos solamente son capaces de detectar tráfico y, en ciertas ocasiones, pueden llevar a cabo reacciones activas que eviten males mayores en la infraestructura de producción. En este caso nos referimos a IDS de red, puesto que existen (o existieron hace unos cuantos años) los llamados IDS de host. Estos eran agentes software que se instalaban de forma directa en cada uno de los servidores a monitorizar y que enviaban alertas sobre ataques contra los mismos.

Los IPS sin embargo, funcionan de una forma diferente, puesto que se emplazan en modo inline entre las diferentes redes, de modo que el tráfico que pasa hacia y desde una red los ha de atravesar, pudiendo discriminar si el tráfico es malicioso o no. Al encontrarse en modo transparente e inline, este tipo de dispositivo sí que es capaz de bloquear todo tipo de tráfico que se considere un ataque. En líneas generales (aunque los IPS han evolucionado mucho), el funcionamiento principal de los IPS a la hora de identificar ataques es idéntico al de los IDS. Se basan en firmas de ataques conocidos y envían por un tercer interfaz las alertas a una base de datos centralizada.

Como diferencias principales entre ambos, aparte de las ya comentadas referidas a la capacidad de detectar únicamente o de bloquear los ataques, es la cantidad de tráfico a monitorizar por parte de ambos. En el caso de los IPS, sólo son capaces de identificar ataques dentro del tráfico que los atraviesa en ambos sentidos. Sin embargo, los IDS de red van más allá, puesto que al analizar el tráfico de una VLAN completa, es capaz de clasificar ataques entre máquinas de la VLAN, no sólo la que pasa de una red a otra.

Inicialmente, todo despliegue de una plataforma de sondas IDS/IPS, cómo si del apostamiento de francotiradores se hablase, requiere planificar con cierta inteligencia.

Como tónica habitual en la gestión de proyectos de este tipo lo que manda principalmente es el presupuesto asignado para invertir en el análisis de la seguridad de las redes.

Suponiendo que disponemos de algo de presupuesto para equipos con licencias comerciales, mi recomendación sería diversificar entre software comercial y software libre. Si bien como iniciativas libres disponemos del ultraconocido Snort (que puede funcionar como IDS y como IPS inline). Como soluciones comerciales más recomendables podemos contar con ISS (adquirida por IBM), Tipping Point (adquirida por 3Com), McAfee Intrushield (solución IPS basada en ASIC), Sourcefire (spin-off comercial de Snort que se integra sobre máquinas Nokia, aparte de sus propios appliances),...

No obstante, y dependiendo en mayor medida de si se tiene proyectado efectuar cambios en la estructura de cortafuegos de red principales, existen los llamados UTMs (Unified Threat Management) o MFA (Multi Functional Appliances) que son en realidad cajas que aunan las funcionalidades de cortafuegos de red, gestor de túneles VPN, antivirus, proxy, gestor de contenidos e IDS/IPS (dependiendo si solo registran las alarmas detectadas o si bloquean los ataques), entre otros... por lo que no es nada desechable la idea de implantar como pilar central de la seguridad un dispositivo de estas características que sea capaz de detectar y bloquear los ataques que lo atraviesen en dirección desde/hasta cualquiera de las redes que delimitan. Por poner ejemplos de fabricantes de dispositivos comerciales UTM, podríamos indicar: Fortinet, Juniper, NetASQ, Checkpoint, Radware,... De esta manera es posible evitar la inclusión de dispositivos IPS puros en los segmentos más importantes de la red. Huelga decir que si tenemos presupuesto ilimitado para llevarlo a cabo, lo más recomendable es situar elementos de diferentes fabricantes por lo que utilizar uno o varios UTM con la función de IPS activa para separar diferentes redes, y además la inclusión de IPS puros en los segmentos de red que necesitemos.

Supongamos que no contaremos con un dispositivo de estas características como eje central distribuidor de las redes principales de nuestra organización. Lo más normal en estos casos es dimensionar la cantidad de sondas a desplegar en caso de los IDS. Si contamos con instalar Snort como IDS (opción recomendada por ser gratuito y de gran calidad), de manera que podemos darnos el lujo de tener una sonda por cada red que posea la organización. En caso de tener limitación en el número de sondas por el coste del hardware, habremos de priorizar sobre las redes en las que tengamos elementos más críticos para nuestro negocio. Se suelen seguir criterios como "la red con más servicios expuestos a Internet" o "la red donde más información confidencial haya".

En cuanto al despliegue de IPS, supongamos que hemos destinado el grueso del presupuesto del proyecto a comprar equipos comerciales IPS. Lo más recomendable es situar un dispositivo (o clústers en alta disponibilidad si el presupuesto lo permite) justo en el punto de acceso a la red (puede ser en la salida/entrada de cada interfaz del firewall que delimita esa red).

Con esta disposición lograremos tener monitorizado el tráfico que entra a cada una de las redes que separa el firewall principal (y bloquearlo con los UTM o los IPS) y el tráfico que se intercambian las máquinas de cada red entre ellas (mediante el análisis del tráfico interno entre máquinas de un mismo segmento), pudiendo detectar actividad vírica que pudiera dejar fuera de combate una VLAN completa.

En posteriores entregas intentaré detallar lo mejor posible cómo configurar los diferentes elementos de seguridad que hemos incluido en nuestra arquitectura de red.

Leer más...

Syslog 2 Twitter

Mucho se ha hablado ya sobre Twitter y del fenómeno social que ha supuesto el micro-blogging, fenómeno que cuenta con legion de seguidores y otro inmenso grupo de detractores.

Personalmente, no acabo de encontrarle utilidad a, por ejemplo, saber que Lorenzo se está comiendo una manzana, o que yo, ando en mitad de un atasco en la A-2 (mas allá del hecho que me estaría jugando los puntos suficientes como para tener el Iphone gratis por twittear con el móvil en el coche).

El caso es que sea o no sea una moda pasajera, twitter, indudablemente si tiene una cosa muy favorable y es el hecho de poder "broadcastear" información de una forma muy sencilla desde un único punto hacia múltiples clientes. Existen clientes-twitter (mas allá de la web) de todos los colores y sabores, solo hay que ojear Genbeta para confirmarlo.

Desde SbD no hemos querido dejar pasar la oportunidad para contribuir al ecosistema Twitter y hemos desarrollado una pequeña aplicación que permite exportar los archivos de log que genera syslog a twitter. Syslog, para el que no lo sepa, es el mecanismo de logging que tiene Unix, algo así como el primo hermano mayor, con barba y gafas gruesas del Eventlog de windows.

El programa, en forma de script, hace uso de un par de curiosos módulos Perl que permiten monitorizar ficheros y "hablar" a Twitter. Para usarlo, obviamente, has de haber creado una cuenta en twitter.

Además Twitter permite hacer tus logs privados solo-para-la-gente-que-tu-quieras, cosa bastante útil de cara a publicar ese tipo de logs, ya que a mi me puede interesar que las personas que co-administran una maquina lean los logs, pero no el común de los mortales. Otra cosa que hace de twitter interesante para esta labor, es el hecho de que tiene una potentisima interface de busqueda que hará muy fácil buscar entre los eventos del syslog. Y como bonus, twitter también permite sindicarse vía RSS a un usuario, con lo que para aquellos que se encuentren mas cómodos con un lector RSS, también pueden tener sus logs disponibles desde cualquier parte.

¿Como funciona sys2twit? vayamos por partes, primero, la instalación de los módulos necesarios:

Como root ejecuta :

#perl -MCPAN -e shell

Esto debería llevarte a otra pseudo-shell desde la que poder instalar los módulos de la siguiente forma:

cpan> install File::Tail
cpan> install Net::Twitter

Una vez tengas todo lo necesario, puedes descargarte sys2twit desde aquí

Los parámetros que acepta la aplicación son:

-u (usuario que has creado en twitter)
-p (contraseña)
-f (fichero de log a monitorizar)
-d (daemon)

Un ejemplo para monitorizar /var/log/messages

# perl sys2twit.pl -u twitterlog -p 12345 -f /var/log/messages

De esta forma todo lo que se genere en /var/log/messages sera transmitido a twitter a la cuenta del usuario 'twitterlog'. Si no quieres que el comando sea interactivo y se 'daemonice' simplemente añade -d al final





Leer más...

19 julio 2008

Boletin Enigma

Con bastante e injustificado retraso por nuestra parte, nos gustaría anunciar que ya está disponible el último boletín Enigma en la calle.

Para el que no lo conozca, el boletín Enigma es, sin duda, el referente nacional sobre documentación técnica en criptografía en lengua castellana. Lleva desde el 2002 siendo editado gracias a la labor del profesor Arturo Quirantes.

En este ultimo numero, Arturo referencia de una forma muy pedagógica nuestro post sobre la FNMT.

Así que ya sabéis, si tenéis inquietud por la criptografía, y todavia no estaís suscritos, no dudéis en daros de alta en su boletín

Leer más...

18 julio 2008

NetSearch Ezine busca colaboradores

Hace tiempo que los 'ezines' de habla hispana quedaron un tanto en el olvido, sitios como el ya mítico SET estan de capa caída y practicamente huerfanos de staff y contenidos, por eso, cuando nos hemos enterado que uno de nuestros Ezines favoritos está en la tarea de re-lanzarse, nos hemos querido sumar a su esfuerzo y reseñar aquí su 'call for papers'.

Este ezine, cuyo primer numero fue lanzado en 1999 ha destacado siempre por la calidad de sus artículos y el nivel de sus editores, por poner un ejemplo, escondido tras un simpático nick, en ese ezine ha escrito bastante material el que hoy día es uno de los lideres / desarrolladores del famosisimo proyecto OSSIM.

Así que ya sabéis, si tenéis inquietud por alguno de los temas sobre los que versa el Ezine y os apetece escribir sobre el tema, no dudéis en responder a la llamada !
Leer más...

17 julio 2008

Sobre el contenido de SbD

Después de ver por ahí algún copy / paste de contenido generado en este blog, en muchos casos sin poner la fuente, en otros sin mencionar la autoría del articulo por su correspondiente autor, y ya en el paroxismo del cachondeo, poniendo la URL original sin un href, "escrita" únicamente, hemos decido registrar el contenido de SbD con licencia Creative Commons del tipo Reconocimiento - No comercial

¿Que significa esto? Básicamente que el contenido se puede copiar y reproducir en su totalidad siempre y cuando se mencione expresamente la autoría y, nota importante, no exista animo de lucro. Con animo de lucro se entiende fusilar el contenido entre cientos de banners publicitarios.

Nosotros creemos firmemente en la filosofía de compartir, en mi caso concreto, por ejemplo, mantengo Unhide el cual está licenciado bajo GPL y forma parte de Ubuntu y Debian.

Lo que no nos parece bien son actitudes parásitas cuyo único valor es copiar y pegar el contenido, entre banners publicitarios. No es que tengamos particularmente nada en contra de los blogs con publicidad, simplemente es un tema que no hemos abordado y que probablemente no lo hagamos en mucho tiempo. Lo que no es de recibo es que mientras la fuente original se mantiene "virgen", el contenido sea copiado con un claro animo de lucro.

Dicho lo cual, disculpas a los lectores habituales por este super offtopic.
Leer más...

16 julio 2008

¿Como de fiable es un SMS?

Para la gente que lleve relativamente "tiempo" en esto de la seguridad, el termino 'spoofing' le resultara familiar. Originalmente, el termino estaba asociado a falsear una dirección IP en ataques de IP spoofing, todo consistía en abrir una sesión contra un host haciéndose pasar por un tercer sistema del que no se tiene acceso y con el que el host A tiene un vinculo de confianza. El termino, posteriormente, ha sido adoptado a cualquier cosa que signifique falsear-algo.

A todos nos ha llegado en alguna ocasión un correo de una dirección que nos resulta conocida pero cuyo remitente nada sabe de ese correo, normalmente en forma de SPAM o con algún virus que se re-envía usando la agenda de la persona que se había infectado. Por lo tanto, todos le concedemos una fiabilidad relativa al correo electrónico. Los mas avezados, en este punto, ya tendrán en la cabeza palabras como PGP o Certificados Digitales y estarán en el camino correcto ya que hasta la fecha, pese a todas las iniciativas generalistas, la única forma de asociar unívocamente remitente / cuenta de correo es el firmado digital con clave publica.

Pero ¿ que pasa con los sms ? si un SMS llega a nuestro móvil y el numero del remitente está asociado en nuestra agenda a, por ejemplo, "Manuel primo" ¿ alguien pensaría que ese mensaje no ha salido del móvil de nuestro estimado primo Manuel ? supongo que la mayoría de la gente no, tal vez movidos por el desconocimiento de como se puede falsear un SMS.

¿ Y como se puede falsear un sms ? tal vez, ¿ empleando infraestructuras privadas de la compañía telefónica ? Si, esa es una manera, pero en realidad no hay que irse tan lejos, los SMS no son algo tan esotérico ni oculto, en Internet hay muchos sitios que ofrecen ese tipo de servicios, como por ejemplo BromaSMS que de una forma sencilla y fácil, al coste de un sms premium, nos permite enviar un mensaje con el remitente que nos plazca.

¿ Implicaciones ? aparte de las obvias: bromas, malentendidos y cierto caos en general, no hay que olvidar que, en determinados sitios, se emplea autenticación vía móvil por SMS y lo que autentica, es el numero origen.

En este punto se plantea la cuestión de como asegurar la identidad de alguien vía SMS. Bueno, la solución es obvia: exportar el modelo empleado en los correos electrónicos, la firma digital. Ya existen diferentes soluciones que van por esa linea, con sus pros y sus contras. Por ejemplo el servicio de Vodafone o el de Lleida.NET

Proximamente nos pondremos a hacer un análisis mas "in deep" de ambos servicios.

PD: ¿ Alguien de Vodafone que se preste a dejarnos una de esas SIMs ? :)
Leer más...

14 julio 2008

Siempre con acceso.... estés donde estés

En el siglo XXI, la feroz competitividad de las empresas obliga a que los empleados, en sus momentos de tranquilidad, relax o viaje se teletransporten a la oficina estén donde estén (always-on).

Afortunadamente (en otros tiempos sería mandatorio desplazarse a la oficina a horas intespestivas) existen diversas maneras de poner a disposición de los empleados los recursos de la empresa de forma segura desde Internet. Lograr este tipo de conectividad "como si estuvieras en la oficina" implica la implementación de lo que se conoce como Red Privada Virtual o VPN por sus siglas en inglés (Virtual Private Network).

Es objeto de este post el mencionar las posibilidades más utilizadas, con sus virtudes e inconvenientes. Lo haremos cronológicamente:

* Acceso RAS: En los tiempos iniciales (los más nostálgicos nos emocionamos al escuchar los pitidos de un módem), la única forma de conexión a las empresas se basaba en una transmisión de módem a módem. Como desventajas podemos mencionar la lentitud (el caudal máximo de transferencia de datos se medía en bps), inseguridad (relativa, puesto que no estaban tan extendidos los conceptos de cómo hacer hacking como actualmente), limitación de acceso a datos,... Eran los orígenes y era la única forma de no tener que ir a la oficina a comprobar si los backups se habían hecho correctamente, comprobar o reparar un servicio caído, etc... Posteriormente se dotó de más seguridad esta forma de acceso mediante mecanismos de call-back para evitar spoofing en el número de llamada, etc,...

* PPTP (Point-to-Point Tunneling Protocol): Nació como evolución de los anteriores. Se trataba de universalizar los accesos mediante cualquier tipo de conexión física en el extremo cliente de la conexión (módem, enlaces X.25, RDSI, Frame Relay, Ethernet...). La comunicación se establecería utilizando un mecanismo lógico que abstraería del tipo de artilugio físico para la comunicación: La pila TCP/IP. Eran los tiempos en los emergieron las arquitecturas cliente/servidor, por lo que PPTP era implementado como un servicio que corría en una máquina que, daba acceso a una red (LAN, MAN o WAN) con una autenticación previa o simplemente de forma anónima. Se puede establecer una analogía de servicios de red, de manera que PPTP es comparable a un DHCP remoto, de manera que cuando un usuario requiere los servicios de PPTP, éste le dota de una dirección IP válida, gateway por defecto, incluso en algunos casos DNS y rutas internas de comunicación. En definitiva, un mecanismo más preciso, más moderno que RAS y más seguro (dependiendo de las vulnerabilidades intrínsecas de TCP/IP así como fallos en las implementaciones de los diferentes fabricantes). Versiones más avanzadas de PPTP permitían incluso el cifrado de los datos como mecanismo de protección de la comunicación. Como implementaciones conocidas de servidor PPTP podemos citar la de Microsoft, PopTop ,...

* IPSEC (Internet Protocol Security): Es el protocolo de comunicación con el que todos asociamos a las VPNs Existen dos subtipos de VPNs basadas en IPSEC: Site-to-Site y Roaming Clients. Ambas se basan en utilizar un medio público y peligroso de transmisión como es Internet, para establecer un túnel cifrado entre los extremos, que permite establecer una comunicación segura y autenticada.
Las VPNs IPSEC Site-to-Site se crean mediante dos dispositivos cuyas direcciones IP son conocidas y fijas para ambos. Se utilizan de forma masiva para conectar oficinas principales con sucursales situadas a muchos (a veces de miles) kilómetros de distancia. Los usuarios acceden de forma transparente a recursos remotos sin ni siquiera conocer el entramado de redes que hay que pasar para llegar a los mismos.
Respecto a las VPNs Roaming, siguen un modelo cliente/servidor como el indicado anteriormente. Se hace necesaria la utilización de un mecanismo software cliente que establece una conexión contra un servidor de túneles VPN (del mismo fabricante que el software cliente) que proporciona la puerta de acceso a la red de la empresa. De la misma manera que en PPTP, el servidor nos proveerá de dirección IP interna en un interfaz virtual, gateway por defecto y/o rutas para acceder a recursos internos, mecanismos DNS (incluso en algunas ocasiones se fuerzan todas las resoluciones DNS a través del túnel). En este tipo de VPNs se garantiza la confidencialidad (túneles cifrados encapsulados a través de Internet), la integridad (los datos no pueden ser modificados puesto que se detectaría mediante las comprobaciones de integridad pertinentes), la autenticación (ya sea mediante usuario/contraseña o certificados importados en el software cliente) y el no repudio (los gestores de túneles VPN, descifran el tráfico y registran las trazas de la actividad de cada usuario de forma unívoca).
Como implementaciones de servidores de túneles IPSEC, podemos citar Microsoft, Cisco, Fortinet, Stonegate, NetASQ, Checkpoint, FreeSwan, OpenSwan...

* VPN-SSL: La necesidad de conectividad en cualquier parte, incluso en los que no contamos con el incómodo y pesado portátil de la empresa (donde tenemos nuestro cliente IPSEC), ha hecho que las empresas ofrezcan acceso a recursos internos (que no se encuentran per se publicados al exterior) mediante lo que se ha llamado VPNs SSL. Para ello se apoyan en un protocolo que es "clientless", puesto que cualquier navegador Web "habla" SSL.
Existen varias filosofías dentro del mundo de las VPN SSL, dependiendo del hardware utilizado y de la posibilidad de instalar software en la máquina cliente.
Se puede acceder a contenido interno de las empresas mediante una transformación de los recursos establecida por el propio gestor de túneles SSL, de manera que un contenido que no es publicado al exterior (no se hace NAT requeriendo autenticación previa, sino que se establece una traducción de direcciones en el dispositivo VPN, pero no hay rutas directas).
Si podemos instalar software en la máquina cliente, el propio portal de acceso por VPN-SSL puede detectarlo y ofrecernos la descarga e instalación de un software (relativamente ligero) que permite el establecimiento de una VPN de similares características a las mencionadas en las VPNs IPSEC en cuanto a confidencialidad, integridad, autenticación y no repudio, levantando un interfaz virtual con direccionamiento IP interno a la organización para permitir el acceso a los recursos autorizados “como si estudiéramos en la oficina”.
Como implementaciones de VPN-SSL la más extendida en el mundo libre es OpenVPN. Fabricantes comerciales que implementen este tipo de solución podemos destacar: Stonesoft, Aventail, Juniper, Cisco, Checkpoint, entre otros…

Leer más...
Para cualquiera que siga listas como Bugtraq o se de una vuelta por packetstorm le resulta común encontrarse diariamente con cientos -literalmente- de vulnerabilidades asociadas a desarrollos web basados en PHP.

Generalmente el tipo de bug suele estar asociado a un mal filtrado del 'input' que proviene del usuario, ejemplos típicos son construir una sentencia SQL empleando un campo obtenido en algún formulario, o mostrar íntegramente y sin filtrar algún mensaje empleando un dato ofrecido por el usuario, lo que nos daría un bonito SQL Injection y un XSS.

Evidentemente este tipo de ataques son fruto de malas practicas de seguridad a la hora de programar, pero para ser justos no es menester culpar siempre al programador. Todos somos humanos y cometemos fallos.

Incluso proyectos tan robustos como WordPress han sido victimas de este tipo de fallos y por ende, sitios de la talla de Alt1040 han sido hackeados

Por eso, siempre es bueno que nos echen una mano a la hora de filtrar patrones maliciosos. Un proyecto que tiene como objetivo fortalecer aplicaciones PHP es PHPIDS.

El funcionamiento de PHPIDS es bastante curioso, no requiere instalar módulos en Apache ya que el proyecto en si es tan solo código PHP. Lo que hace es posicionarse "delante" del código PHP que se va a ejecutar y analizar los parámetros, si todo esta bien, se los envía al script, si encuentra alguna violación de seguridad, lo bloquea y muestra un mensaje de error. El concepto sería análogo a un Firewall pero a nivel aplicaciones-PHP

Existe un how-to bastante completo aquí donde explica paso-a-paso como instalar PHPIDS


Leer más...

10 julio 2008

El protocolo DNS, de nuevo, en boca de TODOS

El protocolo DNS es el encargado de traducir a nombres de internet las direcciones IP. Gracias a esto, nos evitamos tener que escribir http://72.14.207.99 cada vez que querramos buscar algo, y podemos utilizar algo más fácil de recordar, como es http://www.google.com.

Se sobreentiende que actualmente, con la expansión de la red de redes a todos los rincones del planeta, este servicio resulta de vital importancia. Y el hecho de que salga algún tipo de incidencia en este protocolo de 3 letras, provoca una alarma social a nivel mundial, sobretodo cuando empiezan a aparecer palabras como phising, o frases como “¡se podría incluso redirigir el dominio www.google.com a cualquier otro sitio!”.

¿ Y en que consiste la vulnerabilidad? Bueno, realmente, parece ser que son varias vulnerabilidades que han sido recopiladas y han sido investigadas de nuevo más a fondo.

Todo se basa en la facilidad que dan dichas vulnerabilidades en poder llevar a cabo con éxito un envenenamiento de los sistemas DNS, pudiendo engañarles para que apunten a donde no deberían apuntar, aunque el usuario haya introducido correctamente la dirección de internet a la que quería dirigirse.

En el 2002, se reportó que mediante métodos probabilísticos, como es por ejemplo el famoso ataque de cumpleaños, se conseguía reducir drásticamente el número de intentos necesarios para conseguir con éxito un ataque de suplantación de DNS o DNS spoofing, por lo que la fuerza bruta…resultaba un poco menos “bruta”.

En 2007, salió a la luz de nuevo (digo de nuevo, porque ya antes del 2000, se conocían los problemas) una vulnerabilidad para la cual hubo informes de seguridad o advisories apareciendo tanto la implementación de DNS de Microsoft, como el BIND del ISC en sus versiones 8 y 9. ¿El fallo? Algo que debería ser aleatorio, al final resultaba que no lo era tanto…

¿Por qué estos fallos que son de sobra conocidos ya durante casi una década, de repente generan titulares tan alarmistas en todos los medios, ya sean tecnológicos o no, ya sean prensa escrita, digital o incluso informativos de televisión? Juntando varios factores como por ejemplo a) que el autor de este último informe sobre todos estos fallos de implementación, Dan Kaminsky, es el mismo que descubrió el famoso rootkit que Sony incorporaba a sus CDs, que si b) el autor predica que lleva 6 meses en secreto contactando con las principales empresas tecnológicas para poder diseñar una solución conjunta y una actualización también nivel mundial y de manera coordinada y masiva, y que podría haber ganado mucho dinero con este hecho pero que ha preferido ponerse el “sombrero blanco”… lo que son los medios.

En la próxima conferencia de hackers, Defcon, Dan tiene su hueco, el domingo 10 de Agosto de 11:00 a las 11:50 de la mañana, y ha prometido que contará más detalles de todo. En la sección de la página de Defcon sobre los conferenciantes de este año, bajo su nombre sigue apareciendo un TBA (“To Be Announced"), pero ya sabemos de que hablará... y también sabemos que su conferencia será de las más seguidas y comentadas.

Fuente : http://www.kb.cert.org/vuls/id/800113
Leer más...

09 julio 2008

¿First Tuesday? Que no cuenten conmigo

Este post es bastante offtopic con respecto a la temática del blog, si la pongo es porque imagino que por aquí además de gente interesada en la seguridad, también tiene un interés mas general en "el mundillo Internet" y les puede resultar interesante .

Una vez hecho el disclamer, intentare relatar un poco mi vivencia en el First Tuesday del 8-julio.

Nosotros no es que seamos demasiado pródigos en ese tipo de eventos, pero si tenemos experiencia en "eventos generales". De entrada, al llegar, una simpática señorita nos dice que ni Lorenzo ni yo estamos acreditados, cosa que es bastante extraña puesto que ambos teníamos los correos-confirmatorios. Bueno, nada relevante, al final todo se aclaró y pudimos entrar.

Lo primero que me chocó bastante es lo poco "currado" que estaba todo, yo, que conozco eventos promovidos por mayoristas, fabricantes, revistas y similar tenia un prototipo de evento bastante mas elaborado, me parece estupendo darle un punto desenfadado e incluso puedo entender que no haya presupuesto para atenciones varias (léase café, coca-cola o similar) e incluso que no haya ni un pequeño folletito o guía. Imagino que, el acuerdo que llegaron con la gente que ponía el pub, sería del tipo "convoco gente, tu haces caja, yo no pago" bueno, como formula para un LUG o un evento mas low profile, vale, pero para un evento de 'inversores' resulta bastante casposo. Yo, en la época .com había visto varias versiones del first tuesday y su evolución WAP 'WAPWednesday', era la ampulosa época del todos-a-internet y obviamente todo estaba organizado con mucho nivel.

La mayor parte del discurso fue centrado en tecnicismos varios, contratos, porcentajes y cosas varias de interés relativo (para mi). Hubiera preferido algo mas orientado a crear un plan de negocio y alguna parte mas de componente humano por parte del emprendedor invitado que hubiera dinamizado bastante mas el asunto (ya sabéis, algo como "la idea nació en la terraza de un starbucks cuando mi socio y yo ...").

La parte final y a mi juicio mas triste fue cuando se activó el modo perdonavidas por parte de los representantes de los fondos de inversión, si no recuerdo mal, la CAN y la Caixa. Básicamente lo que dijeron fue "los proyectos vienen sobrevalorados, pedís demasiado" todo en un tono como diciendo "encima que os vamos a dar dinero, harapientos busca-vidas" que me pareció de todo punto inaceptable y el colofón final fue una frase (no la recuerdo de forma literal) que venia a decir algo como "y ahora, cuando finalicemos, no os echéis todos encima, no tenemos tiempo para ver demasiados proyectos, y tampoco queremos que agobieis a los inversores y no vuelvan". En ese punto tanto Lorenzo como yo ya teníamos la mirada fija en la puerta de salida. Me quedé con ganas de abordar a alguno de los inversores y explicarles que ellos, en este juego son únicamente un elemento improductivo de la cadena cuyo único activo es el hecho de poseer un recurso (dinero) que, no siempre es la clave de todo. Esta gente parecía no entender que, en ese evento nadie estaba ahí para pedir limosna o que le regalen el dinero, si están ahí es porque se supone que tienen una idea que LES PUEDE HACER GANAR MAS DINERO. El planteamiento lejos de ser "emprendedores, os valoramos y queremos ser vuestros aliados" era mas bien "me hubiera gustado otro puesto en mi empresa pero maldita mi suerte, me ha tocado lidiar con esta gente-de-internet"

Mi humilde consejo para todo aquel que pueda tener una idea interesante es que se la juegue, invierta su capital, si hace falta venda su coche pero que el solito consolide su idea de forma que, cuando les toque hablar con este tipo de empresas-inversoras el tipo que se dirija a ellos esté entre 3 o 4 escalones por encima de los First-tuesdistas :)
Leer más...

08 julio 2008

El primer DNI electrónico

Zapeando por la TV me encuentro con 'Identity' un programa-concurso que, groso modo, se supone que va de adivinar identidades en función de algún dato relevante a la identidad.

Hasta aquí, nada que ver con nuestra temática, (no, no le vamos a hacer competencia a la chica de la tele) pero ... resulta que esta noche una de las invitadas tenía como elemento distintivo "tener el Primer DNI Digital". La persona en concreto, es Ana Isabel Vicente, y si le preguntamos a google en sus primeras respuestas nos lleva hasta aquí, la nota oficial del supuesto primer DNI electrónico. ¿supuesto? si, digo bien, porque se da la casualidad que servidor participó directamente en ese proyecto y obviamente puedo asegurar que ese dato no es correcto.

El DNI Digital fue un proyecto de la policía nacional que se desarrolló integramente en las instalaciones que la policía nacional tiene en El Escorial, que como imagino todo el mundo sabe, se encuentra en Madrid. Por tanto, el primer centro de expedición 'oficial' del DNI Digital, fue en dichas instalaciones, no en Burgos y como es lógico, no fue esa persona el primer poseedor del DNI Digital. Si no recuerdo mal, la primera persona que se le hizo oficialmente ese DNI fue el director técnico del proyecto, después de el, el resto de integrantes del proyecto y antes de la puesta de largo, varias personas con vinculaciones a ministerios y organismos oficiales.

Como nota curiosa, mi DNI tiene fecha de expedición el 14-03 y la noticia ahí referenciada, es del 16-03 (Y eso que en concreto mi DNI dió algunos problemas y fue de los últimos que se expidieron al equipo).

Todo esto me lleva a preguntar ¿son siempre así de fiables los concursos de la Tele? porque en este caso concreto que me atañe directamente, puedo hablar en primera persona, pero, a saber cuantos 'goles' nos habrán colado en otros temas ...
Leer más...

04 julio 2008

Llegan los widgets 3.0; SbD en tu Gtalk !

Todos estamos acostumbrados ya a lo que se han denominado "widgets 2.0", pequeñas aplicaciones que se integran en paginas web, los hay para la pagina principal de google, los hay que se pueden usar en Facebook, unos son mas "ricos" en funcionalidad y otros menos.

Desde SbD hemos querido ir un pasito más hacia delante sacando nuestro propio widget, pero como nos gusta presumir de originalidad, lo hemos hecho de forma diferente, mucho mas interactiva y con bastantes mas posibilidades que los tradicionales widgets-para-la-web.

Nos complacemos en presentar nuestro bot para mensajería instantánea 'sbd.bot'. Un bot accesible por cualquiera que tenga una cuenta en Gtalk desde sbd.bot@gmail.com

Como cualquier nuevo servicio que se precie, se encuentra en fase Beta y esperamos ampliar la funcionalidad con el feedback que nos vayáis aportando.

Los comandos de uso (texto escrito al bot) son:
  • ultimos : Te informa de los últimos 5 posts publicados en www.securitybydefault.com con las correspondientes URLs
  • busca: Hemos llevado el API de google a la mensajería instantánea implementado este comando que permite realizar búsquedas en los posts publicados en SbD desde el bot, por ejemplo, para buscar temas relacionados con certificados digitales el comando sería 'busca certificados'
  • virus: Te informa de los últimos 5 virus detectados por el CATA
  • noticias: Lista las 5 ultimas noticias publicadas por el CATA
  • incidencias: Te informa de las estadísticas sobre incidencias publicadas por el CATA
  • blogs: Hemos hecho un compendio de los mejores blogs de seguridad en castellano y con este comando, puedes acceder a los últimos 5 posts publicados por: Kriptopolis, Port666, Seguinfo y Dragonjar
  • envia: Este comando permite dejar sugerencias, enlaces o cualquier cosa que nos queráis contar. Para usarlo simplemente hay que escribir algo como: 'envia oye me gustaría compartir www.unapagina.com' y nos llegara el aviso
Adicionalmente, el bot te informa en su PSM (Personal Message) del ultimo post publicado en SbD y, cuando se publique un nuevo post, si te encuentras conectado y tu status es 'online' (no queremos molestarte si estas ocupado :P), te envía un mensaje notificandote que hay un nuevo post.

Este es solo el principio, la idea es que el bot evolucione gracias a las sugerencias de vosotros, si creéis que debería estar otro blog, tenéis alguna noticia, inquietud o similar, no dudéis en hacérnosla llegar.

Ah ! y proximamente ... sbd.bot en MSN

-Keep tuned-


Leer más...

03 julio 2008

Modelo de Seguridad Positiva vs. Modelo de Seguridad Negativa

Una de las grandes preguntas que se llevan a cabo los expertos de seguridad a la hora de decidir cómo van a proteger el acceso a cualquier infraestructura es el modo de razonamiento que seguirán. La filosofía elegida condicionará de forma directa los diferentes mecanismos a utilizar para garantizar la protección de los recursos internos de una compañía. De hecho todos los sistemas de seguridad que conocemos en el mundo de las redes y comunicaciones puede clasificarse en uno de los dos modelos.

Modelo de Seguridad Negativa: Se basa en la idea de que todos los accesos a los recursos decididos están permitidos, excepto aquellos que sean prohibidos de forma explícita. Es decir: "todo lo que no está prohibido, está permitido". En esta filosofía podemos encuadrar a los antivirus (permito pasar todos los ficheros adjuntos a un correo electrónico excepto aquellos que contienen virus); los mecanismos antispam (todos los correos están permitidos excepto aquellos que lleven determinado contenido molesto); IDS/IPS (Intrusion Detection/Prevention Systems), algunos WAF (Web Application Firewalls, mediante la utilización de listas negras o de scoring, evitando los ataques conocidos a aplicaciones basadas en web: SQL Injections, Cross-Site Scripting, etc...)

Modelo de Seguridad Positiva: Consistente en justo la idea contraria al anterior: "todo aquello que no está explícitamente permitido, está prohibido". Un ejemplo muy claro de este modelo es un cortafuegos de red "bien configurado" (aquél en el que permitimos el tráfico necesario mediante reglas explícitas y denegamos todo lo demás con la regla de limpieza al final de la configuración); los mecanismos de autenticación (permiten el acceso a aquellos usuarios cuya contraseña/token/certificado es válido y deniegan a todos los demás); algunos WAF o Cortafuegos de Aplicaciones Web (definiendo una plantilla para una aplicación web en la que los parámetros han de tener un riguroso formato, de manera que si el usuario introduce valores no permitidos, se bloquea el acceso)...

Como indicaba anteriormente, en todas las organizaciones se suele seguir una u otra filosofía para decidir cómo será de restrictiva la política de accesos a los diversos recursos. En líneas generales, no se puede decir que una corriente es mejor que la otra, sino que como decía Aristóteles "En el término medio está la virtud" de manera que desde aquí recomendamos la utilización de ambas modalidades siempre y cuando sea posible. Para las aplicaciones que sean inmutables en cuanto a la forma de acceder, así como los servicios expuestos, se puede recomendar utilizar el Modelo de Seguridad Positiva. No obstante, emplear mecanismos que implemente el Modelo de Seguridad Negativa para proteger que esos accesos que tienen el formato correcto no son víctima de ataques conocidos tampoco estará de más. Sin embargo, para aplicaciones que tienen mayor posibilidad de dar falsos positivos (en forma de bloqueos) sólo será posible utilizar mecanismos del Modelo de Seguridad Negativa afinándolos y adaptándolos a las aplicaciones y/o servicios de la organización para evitar dichos falsos positivos.
Leer más...