Como cada día 1 de septiembre desde hace unos años, volvemos a la carga con el blog; y como cada día 1 de septiembre desde hace unos años esperamos que las vacaciones hayan sido provechosas en todos los sentidos, que hayan descansado y que vuelvan con las pilas cargadas para los meses que nos quedan (sólo 11) hasta el próximo periodo de descanso estival. Tras el mes de agosto, vamos a comenzar con la marcha habitual en Security Art Work, en este caso con un post de José Luis acerca del filtrado en los dispositivos ASA de Cisco. Vamos allá…

Si en nuestra organización disponemos de un IPS, cuando éste detecta un ataque suele filtrar de forma inmediata el tráfico proveniente de la dirección IP atacante; no obstante, si simplemente tenemos un IDS, una vez que nuestros sistemas de detección han detectado y notificado una actividad potencialmente sospechosa, la primera función que suele llevar a cabo el personal de seguridad es el filtrado manual de las conexiones en el firewall corporativo para, posteriormente, realizar un análisis más minucioso del ataque, una análisis forense e incluso, en caso de ser necesario, proceder a denunciar el hecho ante las FFCCSE. En cualquier caso, la velocidad de respuesta a la hora de llevar a cabo el filtrado de la dirección IP que nos ataca es crítica, ya que cuanto más tiempo pueda tener acceso el atacante a nuestros sistemas, mayor será el daño que nos cause, por ejemplo dejando puertas abiertas para conexiones futuras o directamente robando información.

Hace algunos meses oí hablar de Dropbox, un servicio de respaldo de archivos de seguridad basado en web. El servicio se basa en la posibilidad de acceder a un directorio de archivos (MyDropbox), con capacidad desde 2GB (gratuito) hasta 100GB ($19.99 al mes) desde cualquier equipo con sólo instalar el cliente de Dropbox. Por tanto, permite sincronizar archivos automáticamente entre múltiples equipos, por ejemplo el PC de sobremesa, el portátil o el iPhone, de forma realmente fácil. Tan sólo dejando caer un archivo en MyDropbox desde uno de los equipos con el cliente instalado se sincroniza automáticamente en la nube o disco virtual y en el resto de equipos.

Los usuarios de la aplicación pueden acceder a una cuenta de administración para compartir directorios a determinados usuarios, subir ficheros, restaurar versiones anteriores o recuperar archivos borrados. Tiene por tanto soporte para historial de revisiones, de forma que los archivos borrados de la carpeta de Dropbox pueden ser recuperados desde cualquiera de los equipos. También existe la funcionalidad de conocer la historia de un archivo en el que se esté trabajando, permitiendo que una persona pueda editar y cargar los archivos sin peligro de que se puedan perder las versiones previas. El historial de los archivos está limitado a un período de 30 días, aunque en la versión de pago que ofrece el historial ilimitado; el historial utiliza la tecnología de delta encoding.

Aprovechando que se acerca el periodo estival en el cual es posible que decidamos realizar algún viaje, me gustaría comentar ciertas medidas de protección implantadas en diversos sistemas de login relacionados con la ubicación geográfica del usuario. Para empezar, comentar que existen BBDD de IPs que las relacionan con su posición física, de manera que puedes consultar dónde esta ubicada una dirección IP con bastante precisión, hasta el punto de que en el mejor de los casos es posible acertar con la población en la que te encuentras; en el peor de los casos, el acierto se limita al país.

Esto es aprovechado hoy en día por cada vez mas aplicaciones, como por ejemplo para ofrecer servicios específicos para la población en que te encuentras. Por ejemplo en mi caso Google hace publicidad ofreciéndome comercios y servicios por ejemplo de la ciudad de Valencia. Esta información se viene utilizando también de manera habitual para orientar, limitar y prohibir el acceso a los contenidos en función de la ubicación física de la persona. Un ejemplo de ello son las cadenas de televisión que emiten video por Internet, limitando dichos contenidos al país en el que tienen licencias para emitir ciertos contenidos (por ejemplo, eventos deportivos concretos). En España esto es utilizado por La Sexta o Telecinco en sus emisiones de TV Online, ya que no tienen licencias de emisión universales. Por supuesto, estas técnicas le quitan universalidad a Internet, pero eso un tema para otro día. Siguiendo con las prohibiciones (que es casi el uso más habitual), existen BBDD de direcciones IP para poder limitar por países enteros; en http://ip.ludost.net/ tenemos herramientas que permiten incorporar estos límites de países a las ACLs de Apache o iptables, lo que puede ser util si queremos interaccionar solo con un país. Como aspecto positivo, también se utiliza para mejorar la seguridad, en módulos de login o transacciones de compras, siendo una medida habitual en los módulos anti-fraude.

A la hora de hablar de detección de intrusos, un modelo dentro de los NIDS que no es muy habitual es la detección en el cortafuegos (o en los cortafuegos) corporativo; digo que no es muy habitual -al menos por mi experiencia- y no sé muy bien por qué, ya que bajo mi punto de vista se trata de algo bastante sencillo de implantar en la mayor parte de firewalls, con un mantenimiento simple y, sobre todo, con una tasa muy baja de falsos positivos. Además, creo que le ahorraría bastante trabajo a los sistemas de detección ubicados en las redes internas, algo que en el caso de seguridad pasiva (IDS) se traduce directamente en un ahorro de costes en el personal dedicado a revisar las alertas de un SNORT o similar.

Un cortafuegos suele manejarse muy bien con las cabeceras de los paquetes y menos bien (o simplemente, muy mal) con los campos de datos; así, para hablar de detección en el cortafuegos, podemos centrarnos en los ataques -o en las anomalías, por no hablar aún de ataques- de dichas cabeceras. ¿Y qué información hay en los campos de cabecera de protocolos como TCP o IP? Direcciones origen y destino, puertos origen y destino, información del protocolo, bits URG, FIN, etc. Un montón de información que, correctamente analizada, permitirá bloquear tráficos anómalos que tratan de entrar en nuestra red y nos proporcionará información útil de eventos cuanto menos sospechosos.

Como llevo algunas noches de insomnio me ha dado por refrescar, tras algunos años olvidados en un cajón, aspectos de monitorización de usuarios en Solaris (Solaris 10, para ser exactos); y la verdad es que de lo que conocía -dejé de administrar máquinas Solaris “en serio” en su versión 7- a lo que me he encontrado en las nuevas versiones del operativo, hay alguna que otra diferencia que sorprende gratamente, y es que a pesar de que ahora sea un producto de Oracle, Solaris sigue siendo Solaris :)

Como siempre, para generar trazas “en serio” de la actividad de los usuarios podemos utilizar el Basic Security Module, habilitado mediante bsmconv(1M) y que nos dirá hasta qué usuario pestañea demasiado delante de la consola :) ¿Problemas? Alguno que otro… para empezar, requerimos reiniciar el sistema, cosa que ya de por sí a nadie le gusta mucho… y para continuar, tenemos el problema histórico del volumen de datos que generamos: por muy bien que configuremos el módulo de auditoría, incluso si lo hacemos por usuario, la cantidad de registros que se almacenan en la máquina no deja de ser considerable… y lo peor de todo: la marcha atrás tras habilitar BSM en nuestro sistema implica de nuevo detener servicios (la orden bsmunconv hay que lanzarla en runlevel 1).

Uno de los problemas a los que nos enfrentamos en organizaciones con una complejidad de red media o alta es la gestión de los permisos que implican a elementos de comunicaciones (switches, cortafuegos, routers, etc.); me gustaría esbozar algunas de las cosas hay que tener en consideración para que la gestión sea posible.

Primero de todo, ante la solicitud de una petición de acceso desde un servidor a otro por parte de algún responsable técnico de algún proyecto TIC de la compañía, hay que tener en consideración dos tipos de aspectos bien diferenciados:

• Aspectos funcionales: Si alguien solicita por ejemplo acceso al puerto de Oracle de un servidor de BBDD, lo primero que hay que evaluar es si desde el punto de vista de negocio, ese permiso debe de ser concedido. Este tipo de accesos deben ser validados por un responsable o autorizador funcional, que puede o no coincidir con el propietario del activo dentro de la organización. Es muy habitual que por agilidad en las gestiones, compañerismo mal entendido, o ausencia de procedimientos formales, este punto se pase por alto y se pase a los aspectos técnicos directamente, sin entrar a considerar la conveniencia de la solicitud desde el punto de vista del negocio.
• Aspectos técnicos: Una vez la autorización funcional ha sido concedida, hay que revisar los aspectos técnicos de los permisos solicitados, para detectar sus implicaciones técnicas sobre otros servicios, el perímetro de la red, problemas de seguridad, etc. Algunas de las cuestiones son: ¿la red origen esta controlada por la organización, o es una dirección externa ajena sobre la que no tenemos información? ¿El protocolo utilizado para la conexión es seguro? ¿Va cifrado? ¿Implica este acceso abrir accesos con redes no confiables? ¿Afectan a la DMZ? ¿Es posible utilizar soluciones alternativas? En cualquier caso, la recomendación es que si el cambio es de cierta relevancia, tiene que haber una auditoria, tanto de caja blanca como de caja negra; esto debería ser obligatorio para cualquier acceso externo a la red corporativa, como por ejemplo el de un nuevo proveedor.

Como todos los veranos, este año se ha celebrado la Black Hat, un conjunto de conferencias donde se desvelan las ultimas tendencias en seguridad, cubriendo con detalle la parte técnica aunque también cada vez mas la parte organizativa y social. Aunque desgraciadamente no he podido asistir a estas charlas, tantos los papers comos los slides están disponibles en la web en la parte de archivos Blackhat.

Muchos equipos investigadores esperan a este evento para desvelar sus descubrimientos, por lo que creo que son de lectura obligatoria para aquellos que quieren ver por dónde van las ultimas tendencias y el “state of the art” en el mundo de la seguridad.

Tras echar un vistazo a las presentaciones, uno tiene la impresión que nada es seguro, ya sean teléfonos móviles, parquímetros, infraestructuras eléctricas, medidas antihacking, certificados SSL, la virtualización, la nube, o cualquier tipo de hardware que puedan imaginar. Los malos pueden incluso leer tu teclado desde el enchufe de tu ordenador, así que la única opción parece ser volver a las cuevas. En fin, que para cualquier “maldad” que puedan imaginar ya hay quien se dedica a aplicarla… y en estas charlas se pueden ver muchas de ellas.

Después de ver los enemigos de los parches, esta vez toca hablar de los enemigos de la seguridad perimetral. En principio, todo apunta a que esto debería de ser una tarea muy sencilla, basada en la regla “sólo se deben de habilitar los permisos que sean necesarios”. Sin embargo, con rascar un poco sobre la superficie, es habitual ver grandes errores en la configuración y problemas en la gestión perimetral de las organizaciónes. En esta entrada vamos a comentar los enemigos técnico, estructurales y organizativos que hacen que aparezcan problemas en la seguridad perimetral de las organizaciones. En otras palabras, cómo es posible que se llegue, sin darse cuenta, a situaciones en las que la arquitectura de la red, o la reglas y ACLs implantadas no son correctas desde el punto de vista de la seguridad.

— Las prisas. Este es un problema típico de la seguridad en todos los niveles, y por tanto, también de la seguridad perimetral, que produce situaciones como “Esto tiene que salir a producción ya”, “Tú abre los puertos para que funcione para ver si es eso y luego ya veremos”, “Tú dale usuario y contraseña de la VPN y luego lo gestionamos como toca”, etc.

Solución: Debe considerarse la parte de comunicaciones y seguridad perimetral como una parte de cualquier proyecto de implantación.

El Nmap Scripting Engine (NSE) es una potente funcionalidad del Nmap que permite la ejecución de scripts, que además permite que los usuarios puedan escribir y compartir scripts para realizar multitud de tareas. El propio Nmap en sus últimas versiones incorpora varios scripts, algunos de los cuales me han resultado muy útiles últimamente. Las tareas que se pueden realizar con el NSE se agrupan en:

• Descubrimiento de red.
• Detección de versiones de servicios mejorada.
• Detección de vulnerabilidades.
• Detección de gusanos y backdoors.
• Explotación de vulnerabilidades.

El pasado 15 de Mayo dos miembros del equipo de seguridad lógica de S2 Grupo nos desplazamos a Barcelona para asistir al V OWASP Spain Meeting, donde como siempre pudimos asistir a conferencias de gran interés con ponentes de muy alta calidad:

1. Sintonizar la función de seguridad con el negocio (PDF). Alberto Partida, miembro del Advisory Board de SANS Institute y poseedor de un impresionante curriculum de certificaciones GIAC (entidad de certificación del SANS Institute), nos explicó la manera de compatibilizar los requisitos de seguridad con las necesidades del negocio, y nos explicó algunos trucos para aprender a mostrar la información a los directivos no tecnólogos de tal manera que entiendan a que riesgos se exponen, y nada mejor que ejemplificarlo con ejemplos de incidentes “sonados”. Una charla muy útil para cualquiera que se encuentre en una empresa no tecnológica o que ofrezcan servicios a empresas no tecnológicas.