Existen algunas opciones de TOR que están destinadas únicamente para el uso de los clientes que desean construir circuitos TOR para posteriormente realizar peticiones al exterior de forma anónima, muchas de estas opciones permiten configurar la forma en la que estos circuitos van a ser construidos. Cuando se crea una instancia de TOR, en realidad solamente existe dos únicos parámetros que determina si dicha instancia actuará solamente como cliente de la red de TOR o si actuará como cliente y servidor, estas opciones son SocksPort y ORPort. Cuando no se indica explícitamente el valor de la propiedad SocksPort, el valor por defecto es 9050 y TOR intentará iniciar un servidor SOCKS en dicho puerto. Cuando se utilizar la opción ORPort con un valor superior a 0, este actuará como un servidor, un Relay para servir a otras peticiones que provienen de usuarios de la red de TOR.
De esta forma:
Instancia Cliente = SocksPort mayor a 0
Instancia Servidor = ORPort mayor a 0
Recordar que estas dos opciones no son excluyentes y se pueden utilizar ambas al mismo tiempo en una misma instancia de TOR.
OPCIONES TOR PARA CLIENTE
Estas opciones solamente son aplicables cuando la opción SocksPort es mayor a 0, (o cuando no es especificada y se deja el valor por defecto).
CircuitBuildTimeOut: Número de segundos que TOR esperará a que la petición de construcción de un circuito se lleve a cabo y que el circuito se encuentre abierto, una vez dicho tiempo se cumpla, TOR cancelará automáticamente la construcción de dicho circuito (por defecto son 60 segundos). Es necesario comprender que este valor, depende directamente de la opción LearnCircuitBuildTimeout
LearnCircuitBuildTimeout: Esta opción es importante ya que le permite a TOR adaptarse al entorno de red local en el cual se esta ejecutando, la principal característica de esta opción es que permite “modificar” de forma dinámica el tiempo que tomará TOR antes de cancelar la construcción de un circuito debido a la demora, esto quiere decir que dependiendo del “conocimiento” que adquiere TOR sobre el entorno de red, modificará de forma dinámica el valor de la opción CircuitBuildTimeout. Admite uno de dos valores (0 desactivada o 1 activada) Por defecto esta opción se encuentra activada. Si se encuentra activada, el valor de CircuitBuildTimeout servirá como valor inicial antes de que el primer “aprendizaje” sea adquirido, esto significa que después de que la instancia de TOR recolecte información sobre el segmento de red, este valor puede ser menor o mayor. En el caso de que esta opción se encuentre desactivada, el valor de CircuitBuildTimeout será el único valor empleado para cancelar peticiones de construcción de circuitos por demora (timeout)
CircuitIdleTimeout: Cuando un cliente permanece inactivo por el periodo de tiempo indicado en esta opción (número entero positivo representado en segundos) automáticamente se cerraran los circuitos y las conexiones expirarán, esto significa que si por ese periodo de tiempo el cliente de TOR no utiliza un circuito construido, este es cerrado y sus conexiones expiradas. El valor por defecto es de 1 hora, sin embargo es posible que este valor sea demasiado “amplio” y deba ser establecido a un valor más corto.
CircuitStreamTimeOut: Esta opción sobre-escribe el valor que tiene incluido TOR para planificar cuantos segundos debe esperar antes de renunciar a un circuito y probar con otro, este caso es distinto a las opciones anteriores de CircuitBuildTimeOut y CurcuidIdleTimeout de las cuales, la primera aplica cuando el circuito esta en proceso de construcción y la segunda cuando un circuito construido deja de ser utilizado por un periodo de tiempo, en esta opción se indica el tiempo que se debe esperar antes de cambiar de circuito por retardo en respuestas sobre peticiones enviadas.
NewCircuitPeriod: Indica cada cuanto tiempo (en segundos) se debe considerar construir un nuevo circuito (por defecto son 30 segundos).
Las opciones anteriores corresponden al comportamiento que tendrá TOR ante eventos de retardos relacionados con el circuito, algunos valores validos para estas opciones que permiten optimizar el rendimiento pueden ser los siguientes
|
Otras opciones interesantes están relacionadas con el control de los nodos que se utilizarán en la construcción de un circuito de TOR, estas opciones se describen a continuación
ExcludeNodes: Se trata de una lista de nodos que TOR debe evitar utilizar en el momento de construir un circuito, este listado puede ser una lista de “fingerprints” identificativos, Nicknames, códigos de estados y patrones de direcciones. Esta opción a efectos prácticos es solamente un “hint” o consejo que se le indica a TOR, sin embargo si por alguna razón TOR necesita conectarse a uno de los nodos indicados en esta opción esta posibilitado para hacerlo, por ejemplo en el caso de que se intente realizar una conexión a un Hidden Service cuyos nodos de entrada se encuentran excluidos utilizando esta opción, TOR realizará la conexión con cualquiera de ellos de igual forma, con lo cual la opción no tendría ningún efecto. Para que los nodos indicados en esta opción sean excluidos en todas las circunstancias y cambiar el comportamiento por defecto de TOR, se debe indicar también la opción StrictNodes.
ExcludeExitNodes: Funciona igual que la opción ExcludeNodes, es decir, se trata de una directiva aconsejada (un hint) a TOR para excluir determinados nodos del circuito que se construirá, no obstante, esta lista solamente aplica para los nodos de salida, TOR decidirá excluir dichos nodos si y solo si no afectan su funcionamiento del mismo modo que ExcludeNodes, para indicar a TOR que siempre se debe utilizar esta política de exclusión se debe incluir también la opción StrictNodes
EntryNodes: Listado de “fingerprints” identificativos y nicknames, (códigos de estados y patrones de direcciones no soportados en esta opción) que se deberán usar como primer nodo en la creación de circuitos. No tiene ningún efecto si se emplea la opción Bridge, que como se ha indicado en entradas anteriores es utilizada únicamente para especificar el servicio que se encargará de crear los circuito en entornos de red donde se encuentra establecido un proxy o firewall restrictivo, no tiene sentido utilizar la opción EntryNodes junto con las opciones UseBridges (con el valor 1) y la opción Bridges, dado que las direcciones incluidas en Bridges, actuarán como los primeros nodos en el circuito.
ExitNodes: Listado de “fingerprints” identificativos, nicknames, códigos de estados o patrones de direcciones que se deberán usar como nodos de salida. Notesé que las opciones anteriores se enfocaban en la exclusión de nodos, mientras que esta opción se enfoca en su inclusión y serán utilizados como nodos de salida para los circuitos creados por TOR. Es importante tener un “balance” entre el listado de nodos que se excluirán y los nodos que se incluirán, dado que si se excluyen demasiados nodos y se incluyen pocos se puede ver afectado el rendimiento e incluso la funcionalidad general de la instancia en ejecución. También es importante comprender que no todos los nodos del directorio de TOR actúan como nodos de salida y es muy frecuente ver nodos “non-exit” tales como los que son empleados para hacer pruebas sobre la disponibilidad de puertos de un Relay (ORPort, DirPort), para conectar Hidden Services o para realizar búsquedas en el directorio de TOR. Evidentemente este tipo de nodos no deben incluirse en este listado, sin embargo del mismo modo que las opciones anteriores, el uso de la opción StrictNodes obligará a la instancia de TOR el uso de este listado de nodos. Por otro lado, cuando se incluye uno o varios nodos en esta opción y al mismo tiempo se encuentran declarados en la opción ExcludeNodes o ExcludeExitNodes, la política de exclusión tiene mayor peso, por lo tanto el nodo será tratado como “excluido”.
StrictNodes: Esta opción cuando tiene el valor 1 le indica a TOR que trate a todos los nodos incluidos en las opciones de exclusión/inclusión de nodos como un requerimiento estricto a seguir para la construcción de circuitos, aunque estos afecten el desempeño o incluso la funcionalidad del mismo, esto quiere decir que todos los nodos excluidos serán realmente excluidos de la construcción de circuitos aunque esto conlleve a errores, por otro lado si esta opción tiene el valor 0, los nodos de exclusión/inclusión serán utilizados únicamente cuando sea necesario y cuando no conlleven a fallos, esto quiere decir, que TOR utilizará los nodos exclusión/inclusión cuando sean necesarios para conectar Hidden Services, realizar pruebas de conectividad de un Relay, actualizar/descargar información del directorio, etc. El valor por defecto es 0 y se recomienda no activar esta opción a menos que se tenga muy claro lo que se esta haciendo.
MapAddress: Con esta opción es posible establecer que una dirección determinada, sea resuelta por un nodo de salida concreto, es necesario que la opción AllowDoExit se encuentre activada para que esta opción funcione correctamente y no existan fallos a la hora de iniciar TOR.
AllowDoExit: Esta opción permite convertir las direcciones indicadas en la opción MapAddress a direcciones concretas pasando por el nodo de salida especificado, por ejemplo www.google.com.AdastraTORY.exit es traducida a www.google.com pasando por el nodo de salida con Nickname AdastraTORY. Esta opción se encuentra desactivada por defecto (valor 0), para activar valor 1.
Algunos valores validos para estas opciones pueden ser:
|
Los códigos de todos los países son una norma ISO estándar que pueden ser consultados aquí:
https://secure.wikimedia.org/wikipedia/en/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_elements
Existen otras opciones de configuración que permiten que Se trata de una lista de direcciones IP/mascaras de red y puertos que el firewall permite la conexión, esta lista también esta compuesta por una política que indica si para una dirección y un puerto el firewall permite o rechaza la conexión.
ReachableDirAddress: Funciona del mismo modo que ReachableAddress siguiendo el mismo formato, solamente que con esta opción se utilizarán estas restricciones para realizar búsquedas en el directorio de TOR utilizando las peticiones estándar HTTP GET. Si esta opción no se establece explícitamente, se utilizará el valor de ReachableAddress
ReachableORAddress: Funciona del mismo modo que ReachableAddress siguiendo el mismo formato, solamente que con esta opción solamente se utilizarán estas restricciones para realizar conexiones con Onion Routers (nodos del circuito) utilizando las peticiones estándar TSL/SSL. Si esta opción no se establece explícitamente, se utilizará el valor de ReachableAddress
Cabe anotar que las opciones ReachableDirAddress y ReachableORAddress son solamente interesantes cuando se realizan conexiones por medio de proxies, dado que muchos de estos limitan las conexiones TLS, las cuales en todas las conexiones que se realizan en un circuito de TOR
|
SocksPort: Indica el puerto que utilizará TOR para iniciar un servidor SOCKS para que de esta forma, aplicaciones que soporten protocolo SOCKS para realizar conexiones, puedan utilizar este servicio, si el valor establecido es 0, TOR no iniciará ningún servicio SOCKS en la maquina local, si el valor es “auto” escogerá un puerto aleatoriamente, si no se especifica esta opción el valor por defecto es 9050.
SocksListenAddress: Funciona igual que SocksPort, con la diferencia de que se puede indicar una dirección IP y un puerto donde iniciar el servicio SOCKS, esta opción se puede utilizar en múltiples ocasiones en un fichero torrc para asociar múltiples direcciones.
SocksPolicy: Permite especificar quienes pueden y quienes no pueden utilizar el servicio SOCKS iniciado por TOR, el formato de estas políticas siguen la misma estructura que las políticas de Salida que se establecen cuando se crea un Relay en una instancia de TOR.
SocksTimeout: Número de segundos que esperará el servidor SOCKS por un “hand-shaking” en una conexión (secuencia de mensajes de sincronización y reconocimiento SYN – SYN/ACK – ACK) por defecto son 2 minutos.
SafeSocks: TOR rechazará cualquier conexión de aplicaciones que utilicen variantes inseguras del protocolo SOCKS, por ejemplo aquellas que solamente proveen una dirección IP, lo que indica que la aplicación esta intentando hacer una resolución DNS, estas variantes son especificas en SOCKS4 y SOCKS5 por este motivo siempre es recomendable utilizar SOCKS4A. Esta opción por defecto esta desactivada (valor 0) por lo tanto también es recomendable activarla (valor 1) ya que permite evitar DNS Leaks.
TestSocks: Cuando esta opción se encuentra activada, genera un mensaje de log con nivel “notice” sobre cada conexión que se realiza al puerto Socks indicando si se trata de una conexión SOCKS segura o si es una variante insegura, Esta opción por defecto esta desactivada (valor 0) por lo tanto también es recomendable activarla (valor 1)
AllowNonRFC953Hostnames: Cuando esta opción se encuentra desactivada bloquea cualquier petición que incluya un hostname invalido (con caracteres inválidos como : y @), por defecto se encuentra desactivada (valor 0) no se recomienda activarla (valor 1).
|
VirtualAddrNetwork: Esta opción permite establecer un rango de direcciones virtuales sin asignar utilizadas proveer el servicio de “proxy” a otras maquinas (incluso la maquina local) . Esta opción es útil para crear un “Transparent Tor Proxy” tal como se ha visto en entradas anteriores de esta serie.
TransPort: si es un valor superior a 0, activa el funcionamiento del “Transparent Tor Proxy” en la instancia de TOR, por convención se suele utilizar el puerto 9040, sin embargo se puede utilizar cualquier otro, es obligatorio utilizar la opción VirtualAddrNetwork para la creación de un rango de direcciones virtuales.
TransListenerAddress: Esta opción funciona igual que TransPort, con la diferencia que es posible utilizarla para establecer una dirección IP y un puerto, con lo cual puede ser utilizada posteriormente por otras maquinas en el segmento de red y permitirá a TOR actuar como Proxy para otras máquinas.
AutomapHostsOnResolve: Cuando esta activada (valor 1) resuelve las peticiones que terminan con un sufijo determinado (aquellos que se incluyen en la opción AutomapHostsSuffixes) y se asocian automáticamente a una dirección virtual sin asignar (aquellas que se incluyen en la opción VirtualAddrNetwork) Esto es útil para un Transparent Tor Proxy ya que cada dirección virtual es asignada dinámicamente y para que las direcciones “.onion” funcionen con aplicaciones que resuelven una dirección y posteriormente se conectan a ella.
AutomapHostsSuffixes: Se trata de una lista de todos los sufijos separados por coma utilizados por la opción AutomapHostsOnResolve para la “traducción” y asignación dinámica de direcciones virtuales. Cuando se establece el valor de “.” indica todas las direcciones, el valor por defecto es “.exit,.onion”
DNSPort: Se trata de una opción interesante dado que TOR en sus recientes versiones tiene incluido un servicio DNS que permite resolver direcciones IP a nombres de dominio y viceversa de forma anónima, lo cual es sumamente útil para evitar completamente DNS Leaks, dado que las aplicaciones que requieran una resolución de nombres, podrán utilizar el servicio de TOR. El valor por defecto de esta propiedad es 0, no obstante se puede establecer el valor “auto” para que TOR automáticamente asigne un número de puerto para el servidor DNS (usualmente el 53) o bien se puede indicar un valor numérico superior a 0 para indicar cual será el puerto empleado para iniciar el servicio DNS.
DNSListenAddress: Funciona igual que la opción DNSPort solamente que permite establecer una dirección IP y un puerto para que otras maquinas puedan utilizar el servicio DNS de TOR para resolver nombres de dominio de forma anónima, el valor por defecto es 127.0.0.1:53
WarnPlaintextPorts: Se trata de una lista de puertos separados por coma que TOR monitorizará, cuando se realice una conexión anónima utilizando alguno de estos puertos, se generará un mensaje de warning indicando que se esta estableciendo una conexión por uno de estos puertos, esto es útil para advertir al usuario que se esta haciendo uso de un protocolo no seguro (como por ejemplo Telnet) y que posiblemente se esta enviando información sensible como passwords en texto claro. El valor por defecto de esta opción es: 23,109,110,143
RejectPlaintextPorts: Funciona igual que la opción WarnPlaintextPorts con la diferencia que esta opción en lugar de advertir sobre el uso de dichos puertos, automáticamente rechazará la conexión. No tiene un valor por defecto, por lo tanto en algunos casos se recomienda emplear esta opción
|
Estas han sido unas de las opciones más interesantes en TOR para una instancia que se ejecuta como cliente, en la próxima entrada se indicarán las opciones que aplican para servicios y Relays TOR.
Seguridad en Sistemas y Técnicas de Hacking. TheHackerWay (THW) 