¿Nos vamos de vacaciones? Será porque estamos a finales de julio. Será por el título del post. O será por la foto de esta entrada, que es la de todos los años por estas fechas y significa una cosa: que nos vamos de vacaciones. Pero a diferencia de otros, este año el que se va NO es Security Art Work sino algunos de los autores, que iremos repartiéndonos unos días de descanso como buenamente podamos (algo es algo). Seguiremos publicando entradas en agosto, aunque obviamente a un ritmo menor que durante el resto del año…

Como en agosto no “cerramos” el blog no vamos a repasar qué ha sucedido de relevancia durante estos once meses -en lo que a seguridad se refiere-, a recordar algunos posts de este periodo o a despedirnos hasta septiembre. Lo que sí queremos hacer es, como cada año por estas fechas, dar las gracias a todos los colaboradores y lectores de Security Art Work, en especial a los que han participado de una u otra forma en el blog durante este tiempo.

Habitualmente, cuando hablamos de enrutamiento ya sea en un router, un firewall o un servidor conectado a varias redes, siempre se hace referencia a enrutamiento por destino, es decir, si quiero llegar desde el nodo A hasta el nodo B, miro en mi tabla de rutas la forma más rapida (mejor métrica) de alcanzar el nodo B y envío el tráfico por la ruta especificada. Si no tengo ninguna ruta especifica al destino, usaré la ruta por defecto, no obstante, hay ocasiones en que esto no es suficiente.

Seguramente muchos de ustedes estarán pensando que tras esta entrada se esconde el humosoft o vaporware que tanto gusta en estos días, pero créanme que no hablaré de sinergia, aportar valor, retorno de la inversión ni de ninguna de esas coletillas que tan bien suenan pero que tan difíciles son de apreciar. En su lugar, vamos a explicar de forma sencilla que es realmente la correlación exponiendo sus ventajas e inconvenientes. De manera muy resumida ésta consiste en, dadas una serie de fuentes de información, ser capaces de obtener los datos más relevantes para nuestra infraestructura, así como ser capaces de detectar una acción que por si sola cada una de las fuentes de información no serían capaces de detectar. Aquellos datos relevantes correlados se notificarán mediante alertas a una consola centralizada.

Como ven hemos introducido un elemento adicional: la fuente de información. Pero, ¿qué es realmente y que tipo de fuente nos interesa? La fuente de información no es más que “un algo” que aporta información al correlador de los acontecimientos ocurridos en nuestra infraestructura. Por ejemplo una herramienta de detección de intrusos, monitorización de los recursos, registros de un servidor, control de acceso físico, estación meteorológica, etc. Cuanto más fuentes de información dispongamos y cuanto más distinta sea la información aportada por cada una de éstas respecto al resto de ellas mejor visión de los acontecimientos tendrá el correlador, y por tanto, mejor funcionará. Como verán no nos interesa tener veinte fuentes de información que aporten casi lo mismo sino tres que aporten información totalmente distinta.

(You can find the English version of this post clicking here, or scrolling down some paragraphs)

Desde hace algún tiempo hemos estado trabajando en el desarrollo de un preprocesador para la sonda de detección de intrusos de Snort capaz de aprender de una red el conjunto de activos que la conforman, así como los servicios que estos ofrecen, de una forma totalmente pasiva. Esta aproximación nos otorga la ventaja de poder obtener un mapeo de puertos sin interactuar con las máquinas del entorno. A su vez y dependiendo de la topología de red, esto nos permite obtener información de hosts sobre los que posiblemente no tengamos visión directa sobre ellos, bien porque estén desconectados o bien porque existen reglas de filtrado que no nos permitan llegar a ellos. Este puede ser el caso de una gran red donde gestionamos un Sistema de Detección de Intrusos basado en Snort, capaz de observar todo el tráfico de red, pero donde el segmento del equipo del administrador de seguridad carece de visibilidad sobre ciertas subredes de la organización. Otra de las capacidades es la de observar de forma rápida el conjunto de activos y servicios de nuestra red con tan solo consultar su base de conocimiento. Un ejemplo de la misma se muestra a continuación:

Para finalizar la semana traemos la segunda entrada de Cristina Martínez Garay, de la firma Rocabert & Grau Abogados, bufete que colabora con Security Art Work, y en este caso al respecto de la Ley 18/2011, de 5 de julio, reguladora del Uso de las Tecnologías de la Información y de la Comunicación en la Administración de Justicia.

Esperamos que les resulte interesante.

Hace apenas unos días, en la era de las Tecnologías de la Información y Comunicación, otra norma más se ha promulgado promoviendo el uso de las TIC´S, y esta vez le ha tocado a la Administración de Justicia, así como a todos los profesionales que trabajamos, ejercemos y lidiamos en la misma.

Siendo la Administración de Justicia independiente al poder Ejecutivo no estaba sujeta a la famosa, en la teoría, Ley 11/2007, de 22 de junio, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos, en adelante LAESCP, por lo que era inevitable que se promulgara tarde o temprano una Ley especifica como ha sido la Ley 18/2011, de 5 de julio, reguladora del Uso de las Tecnologías de la Información y de la Comunicación en la Administración de Justicia.

En relación con el post de ayer que hablaba sobre los peligros que supone compartir fotos a través de redes sociales, hoy vamos a entrar en materia con una aplicación que recopila forma sencilla información sobre la geolocalización que la mayoría de smartphones almacenan en las fotos. Cree.py es un script en python con una interfaz muy sencilla. Le indicas la cuenta de twitter a la que quieres recopilar información, y listo. Puedes bajarte el programa, para Windows o Linux, en su web.

La aplicación recoge la información de las fotos colgadas en twitter, y de los “check-in” que haces con la aplicación foursquare. Una vez que creepy acaba con la busqueda, utiliza la API de Google Maps para situar cada posición encontrada en el mapa en forma de hitos. De esta forma podemos ver con un simple vistazo por donde ha estado nuestra “víctima”.

No estamos hablando de esteganografia (ver la definición que hicimos en otro post), ni de ninguna técnica compleja desarrollada por un experto en tecnología. Hablamos de algo mucho más simple. Hablamos de la información que algunos dispositivos, entre ellos buena parte de los smartphones, almacenan sobre la geolocalización de las fotos tomadas sin que en muchos casos seamos conscientes de ello. La almacenan en la información oculta de las fotos que con determinado tipo de programas resulta sencillo extraer (exif reader por ejemplo). Normalmente estos dispositivos tienen una opción que nos permite configurar si se almacena o no la posición con sus coordenadas en la información oculta de la foto. En la Blackberry hay una opción denominada GeoTag, en las opciones de la cámara, que cumple precisamente esta función.

Como siempre el hecho de que un smartphone pueda geolocalizar una foto no es ni bueno ni malo en sí mismo. El uso que se puede hacer de esta información es lo que puede convertirlo en un potencial peligro, por lo que es importante que todos, sobre todo los más jóvenes, sepamos lo que hacemos y que uso se puede hacer de esa información. Hay que tener en cuenta que la mezcla entre la geolocalización de una foto y los sistemas de información en tiempo real como es el caso de twitter, pueden llegar a ser una mezcla explosiva. Podemos hacernos una idea visitando la url http://icanstalku.com/ que podríamos traducir por “puedo acosarte”. Yo creo que simplemente viendo el contenido se te ponen los pelos de punta.

Para hoy martes, tenemos una entrada de Sergio Galán, alias @NaxoneZ, que inicia su andadura como colaborador de este blog.

Pueden encontrarle en su blog naxonez.wordpress.com o seguirle en Twitter.

Cuando hablamos de monitorización el primer software que nos suele venir a la cabeza es Nagios. Según la Wikipedia y para quien no lo sepa, “Nagios es un sistema de monitorización de redes de código abierto ampliamente utilizado, que vigila los equipos (hardware) y servicios (software) que se especifiquen, alertando cuando el comportamiento de los mismos no es el deseado. Entre sus características principales figuran la monitorización de servicios de red (SMTP, POP3, HTTP, SNMP…), de los recursos de sistemas hardware (carga del procesador, uso de los discos, memoria, estado de los puertos…), independencia de sistemas operativos, posibilidad de monitorización remota mediante túneles SSL cifrados o SSH, y la posibilidad de programar pluggins específicos para nuevos sistemas.”

Como en todo software opensource, existe la versión enterprise, que en el caso de Nagios se denomina Nagios XI. En este post vamos a ver algunos fallos de seguridad que ya han sido notificados al equipo de desarrollo de esta herramienta y en la nueva release dejaran de estar, afortunadamente. Vamos a comenzar a buscar posibles puntos de fallo, para lo que usaremos la demo que podemos visitar en su sitio web: http://nagiosxi.demos.nagios.com/.

Hace ya algún tiempo, un familiar recibió uno de sus mayores disgustos por un robo: un día previo a la época de exámenes fue a estudiar a en la universidad, concretamente a una de sus bibliotecas. Solía llevarse el portátil para no ir cargado, ya que prefería estudiar directamente en la pantalla en formato electrónico. Durante la mañana, decidió ir a tomar un café, era sólo un momento, enseguida volvería… Pues bien, a la vuelta, el portátil ya no estaba, y la pérdida no fue poca porque, para mayor desgracia, el portátil sustraído era un macbook, que como sabéis no es especialmente lo más barato del mercado.

Pensando en este caso, quiero explicar alguna de las opciones que tenemos a día de hoy para evitar que esto mismo nos pueda pasar. En primer lugar, y adaptado al caso, es decir, para un macbook, disponemos de una aplicación llamada iAlertU. Esta aplicación es una alarma que podemos activar en esos momentos en los que vamos a dejar el portátil descuidado, aunque en presencia de otras personas. La alarma se arma y desarma mediante una contraseña. Una vez armada, la alarma se puede configurar para que suene ante cualquier movimiento del equipo, gracias al sistema SMS (que no tiene nada que ver con envío de mensajes, es un sensor de movimiento: Sudden Motion Sensor) que lleva incorporado el MacBook. Gracias a este sensor, la alarma puede configurarse para que siga sonando hasta que el movimiento pare, y el ladrón se vea obligado a dejar el equipo donde estaba. Otras opciones permiten disparar la alarma ante otras situaciones, como por ejemplo, si alguien toca el trackpad, el teclado, si cierra la tapa o se desconecta la alimentación e incluso, y lo que puede resultar aún más útil, si se desconectan dispositivos del equipo, como por ejemplo un reproductor mp3.

Cada vez más las tecnologías de virtualización están más extendidas y prácticamente no se suelen encontrar servidores físicos dedicados. Es por ello que a la hora de gestionar un incidente que requiera de análisis forense detallado es necesario conocer el funcionamiento de cada tecnología de virtualización existente para poder tomar las evidencias necesarias para el estudio del caso.

Normalmente, dentro del grupo de gestión de incidentes solemos encontrarnos con casos donde la tecnología de virtualización empleada es VMWare o Hyper-V. Pero en otras ocasiones, como la que veremos a continuación, nos encontramos con otro tipo de tecnología de virtualización que no es tan común. Para esta entrada explicaremos de forma sencilla y resumida los pasos necesarias para tomar las evidencias del sistema de ficheros de un entorno de virtualización XEN, el cual presenta la particularidad de disponer de volúmenes lógicos LVM.