Dado que aspectos como la movilidad y el geoposicionamiento están poniéndose cada vez más de moda, en este post me gustaría repasar las diferentes tecnologías existentes y las implicaciones de privacidad, que en algunos casos son muy importantes. Veamos pues de qué estamos hablando.

• Métodos de posicionamiento por parte de “la red”
  • Posicionamiento por célula telefónica: La red de telefonía móvil sabe en cada momento dónde está cada teléfono móvil, con una precisión que varía según las células pero que puede estar entre 1 Km y 35Km. Así pues, la compañía de teléfonos sabe dónde estas, y si eso no fuese suficiente, esta información la almacenan, por lo que si llevas tu móvil encima, saben donde has estado en cada momento de tu vida. ¿Se puede acceder a esta información? Sí. Las Fuerzas de Seguridad del Estado están autorizadas para ello si lo solicitan a las operadoras mediante orden judicial. Por ejemplo, tras el atentado del 11-M, sea accedió a dicha información que fue clave para encontrar a los terroristas, ya que un móvil fue encendido antes del atentado en otra ubicación donde tenían su base.
    (Leer el resto de la entrada…)

He decidido poner el término Cloud computing en el titulo del post para tener mas visitas, ya que es un termino de moda, pero si me disculpan la pequeña “trampa”, en su lugar voy a hablar de la seguridad en Infraestructuras compartidas, que es un tema tanto o más interesante en seguridad.

Cuando hablamos de Infraestructuras compartidas nos referimos a la serie de infraestructuras TI que en cualquier organización son compartidas por diversos proyectos. Por ejemplo es habitual que se comparta la infraestructura de red, el almacenamiento en una cabina de discos, o los mismos servidores físicos mediante virtualización; si es un proveedor de servicios el que ofrece la infraestructura, estos elementos estarán compartidos además entre diversos clientes que en si mismo son organizaciones diferentes (vamos, el servicio de hosting de toda la vida).

Recientemente recibimos un curso de Seguridad en SAP durante el que se analizaron los aspectos más importantes en la seguridad de estos entornos y los errores más comunes que pueden encontrarse en una implantación SAP. SAP es un sistema de planificación de recursos empresariales o ERP que permiten, mediante módulos, la integración y control de todas las operaciones relacionadas con la compañía, y como podrán imaginarse una reducción de costes para ésta. Se compone de una serie de módulos que realizan una función en concreto, como la gestión de almacenes (WM), producción (PP-PI), gestión de calidad (QM), gestión de materiales (MM), etc. Cada uno de estos módulos proporcionan al entorno SAP un mayor número de funcionalidades. En esta entrada de Security Art Work se comentarán, de forma resumida, los procesos correctores más comunes en el ámbito de la seguridad dentro de un sistema de estas características.

Los aspectos más habituales de seguridad SAP se centran en la parametrización general del sistema, la configuración de transacciones incompatibles desde el punto de vista operativo en el entorno de los procesos de negocio, la segregación de funciones y la gestión de identificación y autenticación de usuarios. Pero antes de comenzar a tratar cada uno de los puntos expuestos con anterioridad, debemos presentar el concepto de mandante. Un mandante es un subsistema o unidad independiente dentro de un sistema SAP. Las acciones que se realizan dentro de cada mandante reciben el nombre de transacción. Éstas son órdenes que llaman a un programa escrito en ABAP, que a su vez realiza transacciones a través del core de SAP, consultando en la mayoría de los casos la base de datos.

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.