Posted in SSOO, Tips on June 10th, 2009 by m313
Fedora 11 acaba de salir con el sobrenombre de Leónidas. Entre sus grandes novedades destacan la autenticación mediante huella digital, mejoras en el sonido con pulseaudio, en la paquetería con Presto, modesetting, etc.
Este sencillo post pretende exponer tres sencillos comandos necesarios para actualizar nuestros sistemas a Fedora 11:
yum update
yum install preupgrade
preupgrade-cli “Fedora 11 (Leonidas)”
Posted in Forensic on June 8th, 2009 by m313
Los chicos de la distribución forense DEFT Linux han publicado recientemente la herramienta Deft Extra. Este conjunto de herramientas vienen a rellnenar el hueco dejado por las herramientas de Helix para Windows.
La apariencia de este toolkit es muy buena, tenemos las herramientas clasificadas en pestañas según la funcionalidad:
La pestaña de “Forensics Tools” aglomera una gran cantidad de programas:
Al igual que en la Helix se puede navegar el sistema de ficheros y escanear el sistema en busca de imágenes. Por último tenemos una pestaña dedicada a multitud de software diverso que puede resultarnos util en una investigación:
DEFT Extra se puede descargar desde la siguiente dirección.
Posted in Fraude on June 5th, 2009 by m313
La red de anonimato de TOR se basa fundamentalmente en dirigir el tráfico a través de una serie de nodos o repetidores que forman parte de la red TOR y que encapsulan el paquete en sucesivas capas, de manera que “nadie” sabe el destino del mismo hasta que el paquete llega a un repetidor de salida. Para ello se utiliza el concepto de Onion Routing.
No voy a explayarme porque no creo que pueda expresarlo mejor que la página oficial, con gráficos y demás. Analizar en profundidad esto queda fuera del objeto de este post pero quisiera remitir a los interesados unas URL’s para profundizar sobre el tema:
https://wiki.torproject.org/noreply/TheOnionRouter
https://git.torproject.org/checkout/tor/master/doc/design-paper/tor-design.pdf
https://git.torproject.org/checkout/tor/master/doc/spec/tor-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/control-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/rend-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/dir-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/path-spec.txt
Entre las características interesantes que esta red ofrece destacan de manera especial los “servicios ocultos”, que son distintos tipos de servicios (web, irc, etc) que sólo son accesibles para y desde la red TOR, y que tienen la propiedad de que teóricamente no es posible saber el sitio físico o PC concreto en el que está alojado dicho servicio. En próximos post crearemos uno y hablaremos de ellos.
Una de las cosas importantes a tener en cuenta es que la “calidad” de la privacidad es directamente proporcional al número de repetidores que haya en la red. Este post se centrará en explicar brevemente cómo crear de manera sencilla un nodo repetidor de TOR sobre un sistema Linux, concretamente sobre un Fedora Linux 10.
Primero hay que destacar que hay dos tipos de repetidores, los internos y los de salida. Configurar un nodo de salida puede traer algunas complicaciones que explicaremos en un futuro post, y veremos cómo hacerlo. De momento nos centraremos en un repetidor interno, que basicamente sirve para marear peticiones con el objeto de conseguir una privacidad aceptable.
La página oficial de TOR tiene abundante documentación, recomiendo mirar la guía para configurar repetidores, aunque aquí explicaré brevemente como hacerlo en dos patadas.
== Instalando TOR ==
Tor está en los repositorios de Fedora por lo que instalar el software es tan sencillo como ejecutar el siguiente comando con privilegios de administración:
yum install tor
== Configurando TOR como repetidor interno ==
El fichero de configuración de TOR se encuentra en /etc/tor/torrc y para crear un sencillo repetidor interno basta con las siguientes opciones:
SocksPort 9050 # puerto para las conexiones locales
SocksListenAddress 127.0.0.1 # aceptar conexiones de localhost
Log notice file /var/log/tor/notices.log # fichero de log notice
Log debug file /var/log/tor/debug.log # fichero de log de depuracion
Log notice syslog # facility del syslog
RunAsDaemon 1 # ejecutar el servicio como demonio
DataDirectory /var/lib/tor/.tor # directorio de datos
Nickname mordor # nombre del repetidor
RelayBandwidthRate 50 KBytes # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 50 KBytes # But allow bursts up to 200KB/s (1600Kbps)
ORPort 9001 # puerto en el que se esperan conexiones
DirPort 9030 # puerto para solicitar conexiones, ideal si tienes mucho ancho de banda para compartir
Group toranon # grupo con el que se ejecutará
User toranon # usuario con el que se ejecutará
hay que destacar que si tienes una conexión ADSL normal y corriente tendrás que hacer NAT contra tu sistema para los puertos definidos en las variables ORPort y DirPort.
== Comprobar que funciona ==
Para comprobar que está en ejecución sin problemas debemos recurrir al log, que se encuentra en la ruta /etc/tor/torrc, para que funcione debería tener un aspecto similar a esto:
May 02 01:12:06.368 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
May 02 01:12:06.368 [notice] Now checking whether ORPort 83.44.185.90:9001 and DirPort 83.44.185.90:9030 are reachable… (this may take up to 20 minutes — look for log messages indicating success)
May 02 01:12:11.307 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
May 02 01:12:11.528 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
May 02 01:12:30.024 [notice] Performing bandwidth self-test…done.
Adicionalmente una vez que el servidor es accesible a la red sus datos serán subidos a los llamados “descriptores de servidor” y en ellos podremos comprobar que nuestro nodo forma parte de la red TOR, en mi caso he usado un descriptor (http://moria.seul.org:9032/tor/status/authority) para comprobar que mi nodo “mordor” forma parte de la red:
== Funcionando ==
Una vez que funcione hay varias recomendaciones que pueden leerse en la guía oficial. Por mi parte simplemente he querido ver un poco qué es lo que se mueve en esta red y para ello he levantado un sniffer (tcpdump) y he inspeccionado el tráfico que pasa por mi nodo.
Tenemos por tanto un fichero .cap con el tráfico interceptado. Para analizarlo utilizaremos Wireshark. Vamos a distinguir dos tipos de comunicaciones:
1. Tráfico de solicitud de conexiones.
Este tipo de tráfico se transmite entre los nodos internos y los servidores de directorio y es necesario para poder calcular las rutas por las que viajarán los paquetes. Este tráfico utilza el puerto que hayamos definido en la variable DirPort, en nuestro caso el 9030, asique aplicaremos el siguiente filtro al Wireshark:
tcp.port == 9030 || udp.port == 9030
Si ensamblamos la comunicación TCP tenemos dos tipos de comunicaciones, en el primer tipo tenemos una comunicación parcialmente cifrada
La IP de nuestro repetidor es la 192.168.1.33 y por lo que podemos ver una IP perteneciente a otro repetidor (podemos contrastarlo consultando en el descriptor de servidor comentado anteriormente) realiza una petición http GET a la que nuestro repetidor contesta con un 200 OK.
El contenido de dicha respuesta está cifrado.
En el segundo tipo de petición tenemos algo similar a la anterior, pero con una respuesta negativa (400 NOT FOUND):
2. Tráfico entre repetidores.
Este es el tráfico más abundante y se realiza mediante el puerto definido en la variable ORPort, en nuestro caso el 9001, asique aplicaremos el siguiente filtro al Wireshark:
tcp.port == 9001 || udp.port == 9001
Como podemos comprobar en las siguientes capturas el tráfico va cifrado y se produce únicamente entre IP’s que pertenecen a repetidores (podemos contrastarlo consultando en el descriptor de servidor comentado anteriormente):
En las próximas entradas configuraremos un nodo de salida y comprobaremos cómo en este caso sí pueden inspeccionarse los datos de salida.