Archive

Archive for the ‘FileSystem’ Category

Tahoe-LAFS Sistema de almacenamiento en la nube privado y seguro – Parte 1

junio 30, 2015 Deja un comentario

El “cloud storage” o almacenamiento en la nube, se ha vuelto muy popular debido a la flexibilidad y beneficios que aporta a los usuarios. La habilidad de subir documentos a un servicio en Internet y poder acceder a ellos desde cualquier lugar y en cualquier momento, es algo muy atractivo para cualquiera, sin embargo en muchas ocasiones, al utilizar algunos de estos servicios en Internet, los usuarios se exponen a varias amenazas que pueden afectar directamente la confidencialidad e integridad de su información. Es cierto que muchos de los proveedores de los servicios de almacenamiento en la nube intentan asegurar los recursos de sus usuarios de la forma más rigurosa posible, pero en algunos casos, con la excusa de mantener la información de sus usuarios “segura” y confidencial, acceden directamente a dicha información, vulnerando de esta forma su privacidad.
Una buena forma de utilizar estos servicios es por medio del cifrado de los documentos desde el origen y de esta forma, evitar que un tercero tenga acceso directo a la información de los documentos almacenados en la nube, pero aun así, es necesario un registro y posterior entrega de datos personales al proveedor. Para los usuarios de redes anónimas tales como I2P, existe una solución que puede resultar mucho más interesante y que no exige el registro de datos personales ni de ningún tipo, permitiendo de esta forma almacenar documentos de forma distribuida y privada. Dicha solución es Tahoe-LAFS.

Tahoe-LAFS (The Last Authority File Store) es un sistema descentralizado y abierto que se encarga de distribuir los documentos de un usuario por múltiples servidores Tahoe. De esta forma, es posible seguir accediendo a la información de forma transparente aunque uno o varios de los servidores se encuentren caídos o comprometidos por un atacante. Solamente el propietario de los documentos o con los permisos adecuados puede ver sus contenidos, esto en Tahoe es lo que se conoce como “Provider Independent Security”, que es justo lo contrario a lo que suele verse en los principales proveedores de almacenamiento en la nube, ya que en este caso, el proveedor del servicio nunca tendrá acceso ni podrá leer y/o modificar la información de ninguno de sus usuarios. Justo lo opuesto a los proveedores de almacenamiento convencionales.

Funcionamiento básico de Tahoe-LAFS

El funcionamiento de Tahoe-LAFS se basa en el concepto de “Storage Grid”, que no es más que un conjunto de servidores de almacenamiento que se encargan de mantener los documentos de los usuarios del sistema. Un servidor de almacenamiento es simplemente un repositorio de datos, el cual no tiene la habilidad de actuar directamente sobre ellos, solamente se encarga de almacenarlos y brindar acceso a uno o varios “gateway”. Un gateway es un sistema independiente que se encarga de comunicarse con los servidores de almacenamiento y proveer acceso a la información que se encuentra almacenada en ellos por medio de protocolos de comunicación comunes tales como HTTP/S, SFTP o FTP. De esta forma un cliente, se comunicará con un gateway y éste a su vez, se comunicará con los servidores de almacenamiento para permitir el acceso a sus documentos. Un cliente en este caso puede ser un navegador web, un programa que se ejecuta por línea de comandos un cliente SFTP, etc. Tal como se mencionaba anteriormente, los servidores de almacenamiento tienen acceso a la información de sus usuarios y la información que se transfiere entre dichos servidores, el gateway y el cliente, se encuentra cifrada, impidiendo que cualquier “entidad” intermedia pueda manipular directamente los datos transferidos.
El procedimiento de instalación de Tahoe-LAFS se detalla a continuación.

Instalación de Tahoe-LAFS

Para instalar una instancia de Tahoe, es necesario tener Python instalado en el ordenador, preferiblemente la versión 2.7 ya que la última versión de Tahoe no funciona correctamente sobre la versión 3.x de Python. Una vez descargada la última versión estable del proyecto desde el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs se procede a instalar ejecutando el siguiente comando:

>python setup.py build

El comando anterior se encargará de instalar todas dependencias necesarias para poder arrancar correctamente Tahoe en uno de los modos descritos anteriormente (server o gateway) y además, se encargará también de generar un fichero ejecutable en el directorio <TAHOE_INSTALL>/bin.
En el caso de que exista algún problema ejecutando el script anterior, es posible que falte alguna dependencia necesaria en el sistema y no se ha podido obtener de manera automática por algún motivo. En tal caso, es necesario instalar manualmente la dependencia en cuestión, aunque son programas que suelen venir instalados por defecto en las en las últimas versiones de sistemas basados en Debian.

Por otro lado, para verificar la disponibilidad de todas las funciones que incluye Tahoe, se puede ejecutar el script setup.py con el argumento “trail”

>python setup.py trial

En tal caso, se podrán ver por pantalla, cada una de las funciones de Tahoe y si se ha podido comprobar que se encuentran correctamente instaladas y configuradas.

Uso de Tahoe-LAFS

Después de instalar el programa, es el momento de comenzar a utilizarlo y ver cuales son las opciones que se encuentran disponibles a los usuarios. En primer lugar, es posible crear clientes o un storage grid completo, todo esto ejecutando la utilidad “tahoe” que se ha generado automáticamente en el directorio “<TAHOE_INSTALL>/bin” tras ejecutar el proceso de instalación.

El primer paso para comenzar a utilizar el programa, consiste en crear un cliente simple, para ello se ejecuta el siguiente comando:

>./tahoe create-client Node created in ‘/home/adastra/.tahoe’

Please set [client]introducer.furl= in tahoe.cfg!

The node cannot connect to a grid without it.

Please set [node]nickname= in tahoe.cfg

Como se puede apreciar, con el comando anterior se ha creado un cliente simple y se ha creado también el directorio “~/.tahoe”. Tal como se enseña en la salida del comando, se debe establecer la propiedad “introducer.furl” en el fichero de configuración del nodo recién creado (tahoe.cfg) para que de esta forma, sea posible conectar al cliente con un storage grid de servidores.
Para probar las funcionalidades del sistema, existe un storage grid público que se encuentra activo para que los usuarios puedan interactuar con el sistema y opcionalmente con otros usuarios, para encontrar más detalles sobre dicho storage grid, se recomienda ver el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid
Tal como se explicaba anteriormente, es necesario establecer las propiedades “introducer.furl” y “nickname” en el fichero de configuración del cliente creado anteriormente, para ello se debe editar el fichero de configuración “<TAHOE_INSTALL/.tahoe/tahoe.cfg” y definir los valores adecuados en la sección “[client]”. Ahora bien, los valores de estas propiedades dependerán de si el usuario utiliza el storage grid de pruebas o uno propio. En el caso de utilizar uno propio, se debe indicar el valor del introducer de dicho storage grid en la propiedad “introducer.furl”, en el caso de utilizar el de pruebas, dicho valor se encuentra en el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid#HowToConnectToThePublicTestGrid

Después de establecer las dos propiedades de configuración anteriores, se puede arrancar el cliente con el siguiente comando.

>./tahoe run ~/.tahoe STARTING ‘/home/adastra/.tahoe’

running node in ‘/home/adastra/.tahoe’

2015-06-21 18:29:16+0200 [-] Log opened.

2015-06-21 18:29:16+0200 [-] twistd 13.2.0 (/usr/bin/python 2.7.6) starting up.

2015-06-21 18:29:16+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor.

2015-06-21 18:29:16+0200 [-] Listener starting on 37384

2015-06-21 18:29:16+0200 [-] NevowSite starting on 3456

2015-06-21 18:29:16+0200 [-] Starting factory <nevow.appserver.NevowSite instance at 0x7f36175311b8>

2015-06-21 18:29:16+0200 [-] My pid: 13852

2015-06-21 18:29:16+0200 [-] DatagramProtocol starting on 57219

2015-06-21 18:29:16+0200 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88>

2015-06-21 18:29:16+0200 [-] (UDP Port 57219 Closed)

2015-06-21 18:29:16+0200 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88>

Ahora que el cliente se ha ejecutado sin errores, lo primero que hará será conectarse con el “introducer” y obtener un listado de storage servers. Es importante tener en cuenta que con lo anterior, solamente se crea un cliente plano, sin ninguna capacidad de almacenar y compartir archivos de otros usuarios, algo que desde luego, es una de las principales potencialidades del sistema y como se verá en un próximo artículo, no es demasiado difícil de instalar y configurar.

A partir de aquí, el usuario puede interactuar con el grid de varias formas, una de ellas es por medio de una interfaz web muy simple que se levanta automáticamente en el puerto 3456. La siguiente imagen enseña dicha interfaz.

tahoe1Interfaz web del cliente Tahoe.

Como se puede ver, aparece la dirección del “Introducer”, los servidores de almacenamiento conectados y a la izquierda, un panel muy simple para subir directorios o descargar ficheros al sistema de almacenamiento. Cuando se sube un fichero o directorio, automáticamente se generará una URI única del fichero, la cual seguirá el siguiente formato

URI:SSK:xxx:xxxx

Dicha URI debe ser utilizada para acceder al documento y se debe ingresar en el campo de texto de la interfaz web que pone “OPEN TAHOE-URI”.

La interfaz web es solamente uno de los mecanismos disponibles en Tahoe para interactuar con los servidores de almacenamiento, pero no es el único, ya que también es posible interactuar con el grid por medio de los comandos disponibles en la utilidad “tahoe” o incluso también es posible utilizar una API Rest para interactuar con el sistema por medio de peticiones HTTP(S).

El objetivo de esta primera entrada era el de introducir al lector en los conceptos básicos de Tahoe-LAFS y en las próximas dos publicaciones, se hablará sobre configuración avanzada del sistema, creación de un grid, uso de la web api y cómo desplegar Tahoe-LAFS en I2P.

Un saludo y Happy Hack!
Adastra.

Intentando evadir mecanismos y restricciones de Seguridad – Creando una puerta trasera y accediendo a información de usuarios usando un DEB malicioso – Parte IV

febrero 17, 2012 Deja un comentario

En la entrada anterior se ha indicado como crear un instalador DEB malicioso utilizando msfpayload, lo que ha permitido obtener una consola en la máquina remota que se deseaba atacar.

Partiendo de la publicación anterior, se intentará crear un programa simple que acceda a la información de todos los usuarios del sistema y dicha información se intentará enviar a una máquina remota por medio de un socket. A continuación se indica paso a paso, el uso de algunas librerías propias en C/C++ (en concreto, contenidas en el paquete libc y build-essentials) y como se ha codificado está pequeña puerta trasera. El objetivo de lo que se indica a continuación, es solamente para fines ilustrativos, no se tienen en cuenta factores de seguridad vitales en la máquina atacada tales como firewalls, AV y/o IDS, de esta forma, un hacker con conocimientos medios en programación puede darse una idea de la cantidad de operaciones que puede llevar a cabo en una máquina objetivo con un vector de ataque como este.

Leer más…

Bind a puertos reservados utilizando usuarios sin privilegios de Root

octubre 7, 2011 14 comentarios

Una de las tareas mas comunes de un administrador de sistemas consiste principalmente en la correcta configuración y arranque de diversos servicios tales como servidores web, servidores de correo, servidores DNS, etc. En todos los casos, alguien consciente de que la seguridad en los servicios expuestos al publico tendrá como referencia determinadas políticas de seguridad entre las cuales, sin lugar a dudas, se debe incluir la ejecución de dichos servicios con un usuario con privilegios limitados, es decir, el usuario ROOT no debería iniciar servicios como Apache o SendMail, ya que si existe algún problema con dichos servicios, como por ejemplo una vulnerabilidad que le permita al atacante acceder de forma remota (como por ejemplo el aprovechamiento de una vulnerabilidad de Buffer Overflow) este automáticamente tendrá privilegios de ROOT sobre el sistema, no hace falta indicar las nefastas consecuencias que conllevan incidencias como estas.

Leer más…

Conceptos Básicos de Rootkits en Procesos de Post-Explotación de Sistemas – Hacker Defender

julio 29, 2011 Deja un comentario

Un rootkit es un sistema que oculta la presencia de un atacante sobre un sistema comprometido, facilitando enormemente las actividades del hacker sobre dicho sistema. Para conseguir esto un rootkit permite esconder archivos, procesos y claves del registro en un sistema previamente comprometido por un atacante, el potencial de este tipo de enfoque tiene connotaciones muy importantes desde la perspectiva del atacante, principalmente porque le permite establecer backdoors no detectables por AV’s (en la mayoría de los casos) dado que los procesos se asocian con procesos que en principio son “confiables” y que procesos son confiables? Aquellos que se encuentran asociados a binarios importantes del sistema operativo, procesos o claves del registro, un rootkit se encarga de crear copias modificadas de estos binarios, procesos y claves del registro para que su posterior ejecución parezca legitima y permita a un atacante realizar operaciones administrativas.

Leer más…

Recuperar Ficheros Borrados y Reparar sistemas de archivos

marzo 30, 2011 Deja un comentario

Para recuperar ficheros o reparar sistemas de archivos basados en Ext, es necesario utilizar la herramienta e2fsck, la cual espera como parámetro el dispositivo que se desea chequear, es necesario que este se encuentre desmontado:

e2fsck /path/filesystemExt

Recuperando ficheros borrados:

En primer lugar, un fichero es una relación de disco y enlace, de esta forma el sistema operativo puede acceder al fichero por medio del enlace que apunta a la ubicación física en el disco duro, (llamado inode) cuando se emplea el comando rm para eliminar un fichero, solamente se elimina el enlace al que apunta, sin embargo el fichero permanece en el disco duro por un periodo de tiempo, vamos a ver una practica habitual cuando un fichero es eliminado y un proceso hace uso de el (un proceso zoombie)

Leer más…

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.536 seguidores

A %d blogueros les gusta esto: