El fichero torrc es el principal recurso que utiliza TOR para inicializar determinadas variables y establecer comportamientos que, si bien en algunos casos resultan beneficiosos, en otros casos pueden afectar el rendimiento o la estabilidad del sistema, por esto es necesario conocer todas las implicaciones que traen consigo para evitar situaciones “desagradables”. Desde las primeras versiones de TOR, el número de opciones de configuración ha aumentado de una forma bastante acelerada, lo que es un claro indicativo de que es un software que esta en un proceso de evolución y maduración constante. Desde el sitio oficial de TOR es posible ver el manual oficial donde se incluye una explicación de todas las opciones que se pueden indicar en el fichero de configuración torrc con el fin de que TOR se comporte de una determinada manera, en esta entrada se establece como objetivo, explicar y enseñar los resultados obtenidos sobre la implementación de las características más llamativas e importantes de configuración. Las opciones en TOR, se separan por contexto de ejecución, es decir, algunas de ellas son útiles solamente cuando TOR va a ser ejecutado como cliente o como servidor, otras opciones son validas para ambos casos, sin embargo es importante entender cuales opciones aplican dependiendo del contexto de ejecución de una instancia de TOR.
A continuación se explican las opciones que son relativas a ambos contextos de ejecución (cliente y servidor)
Opciones para configurar el uso de Banda Ancha empleada por un Relay en TOR
En ocasiones es normal olvidar ajustar los valores relacionados con el uso de banda ancha que estará disponible a cualquier relay que este configurado en una instancia de TOR, aunque frecuentemente con los valores que se establecen por defecto es suficiente, es importante conocer cuales son las opciones relacionadas con el uso de banda ancha en TOR, en concreto interesan dos opciones:
BandwidthRate y BandwidthBurst, la primera establece la banda ancha máxima promedio permitida (bytes por segundo) que utilizará un cliente de TOR, este valor debe ser como mínimo de 20 KB por segundo, el valor de BandwidthBurst puede verse como un pool de bytes que es usado para completar peticiones durante periodos cortos de tiempo que superan el valor establecido en la opción BandwidthRate. Por ejemplo, asumiendo que se establece la opción BandwidthRate a un valor de 50 KB y la opción BandwidthBurst 1MB, si una petición consume un ancho de banda superior a 50 KB, los bytes restantes (la diferencia entre el valor consumido por la petición y el valor de la opción BandwidthRate) serán tomados de BandwidthBurst. Los valores recomendados, dependen directamente del ancho de banda disponible en el router y el porcentaje que se desee compartir en la red de TOR.
Además de las opciones anteriormente indicadas también se pueden establecer opciones de “accounting” que son muy útiles para nodos que se ejecutan durante largos periodos de tiempo, estas opciones establecen la cantidad total de Bytes que un Relay consumirá en el periodo de tiempo definido. Dichas opciones son AccountingStart y AccountingMax la opción AccountingStart establece el “contador” de tiempo que indica cuando deben reiniciarse los valores de consumo de banda ancha, mientras que el valor de la propiedad AccountingMax indica la cantidad máxima de banda ancha compartida en la red de TOR.
Por ejemplo:
|
Aunque el ejemplo anterior sobre el uso de opciones para configurar el uso de banda ancha es muy simple, la opción AccountingStart puede ser personalizada de muchas formas, pareciéndose en cierta medida a los procesos CRON de sistemas operativos basados en UNIX. Por ejemplo:
|
Es importante anotar algunas características que deben ser tenidas en cuenta a la hora de utilizar estas propiedades:
-
Es posible que el valor de AccountingStart no se aplique de forma “exacta”, ya que TOR se encarga de registrar el consumo de banda ancha máximo del periodo inmediatamente anterior, en el caso de que este valor haya sido consumido ANTES de finalizar el periodo de tiempo definido, TOR calculará automáticamente un punto de reinicio apropiado para iniciar el proceso de Accounting, esto quiere decir que aunque se establezca la propiedad AccountingStart es posible que no se aplique de forma estricta y que TOR decida en que punto de tiempo se debe aplicar, esto es así para evitar que la red tenga “posiblemente” cientos de Relay’s funcionando perfectamente al principio, pero que no llegan al final de cada mes debido al consumo. Es un mecanismo de control que tiene TOR implementado y que es necesario tener en cuenta. De hecho el mensaje que arroja la consulta cuando se inicia TOR con estas opciones es similar al siguiente:
Configured hibernation. This interval begins at 2011-10-31 00:00:00 and ends at 2011-11-01 00:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
En este caso, indica que no se ha realizado un registro previo sobre el uso de banda ancha, no obstante, registrará el próximo ciclo y realizará las estimaciones oportunas.
-
Se recomienda utilizar Accounting diario si se desea compartir pequeñas cantidades de banda ancha, principalmente porque al utilizar rangos de tiempo más amplios, puede conducir a que se consuma antes de que se inicie el siguiente periodo de tiempo, con lo cual, TOR reiniciará el valor de consumo a cero en un punto que consideré adecuado, por lo tanto la opción AccountingStart no se ejecutará cuando se espera y se perderá el control de los intervalos de tiempo sobre los limites máximos de uso de banda ancha.
-
Finalmente, es necesario tener cuidado con el uso de las opciones AccountingMax y BandwidthRate dado que AFECTAN AL CLIENTE Y AL RELAY, esto quiere decir que si por alguna razón se ha alcanzado dichos limites de consumo de banda ancha, por el cliente y/o por el relay de TOR, el cliente ya no podrá navegar más por la red hasta que se reinicie el valor de Accounting a 0 nuevamente. El lector debe prestar atención a este punto, dado que puede traerle problemas a la hora de ejecutar su propio Relay en una máquina de uso personal. Cuando una instancia de TOR excede los limites de banda ancha, entra en un estado de hibernación evitando que cualquier proceso asociado pueda seguir ejecutándose normalmente.
La solución a esto es ejecutar 2 instancias distintas de TOR, cada una con sus propios parámetros de configuración (cada una con su propio fichero torrc). Para hacer esto se recomienda seguir los siguientes pasos:-
Crear dos ficheros de configuración de TOR independientes, el primero de ellos contendrá las opciones relacionadas con el Relay, tales como HiddenServices, limites de Banda Ancha, Puerto de control (ControlPort), Políticas de Salida, etc. Además el fichero de configuración del relay deberá contener la opción SocksPort con valor 0, con el fin de que no se inicie un servidor SOCKS que pueda ser utilizado por clientes. En el fichero de configuración del cliente, se podrán establecer otras opciones relacionadas con el proceso cliente (de las cuales se hablará más adelante). Para partir de un ejemplo, se puede ver la plantilla del fichero torrc que viene incluida en TOR ubicada en <TOR_DIR>/src/config/torrc.sample
-
Iniciar cada uno de los procesos utilizando TOR, teniendo en cuenta que no se utilicen opciones de cliente en el fichero destinado al relay y viceversa, para ello se podría ejecutar algo como:
>tor -f /path/torrc.relay
>tor -f /path/torrc.cliente
-
Por otro lado, en recientes versiones de TOR, existen dos propiedades adicionales que permiten separar los limites de consumo de banda ancha de un Relay y un Cliente aunque se ejecuten en la misma instancia de TOR, con esto, no seria necesaria la separación de dos procesos independientes tal como se ha indicado lineas anteriores, estas opciones son: RelayBandwidthRate y RelayBandwidthBurst, ambas opciones asumen el mismo significado que las opciones anteriormente mencionadas BandwidthRate y BandwidthBurst la única diferencia radicará en que las Relay* aplicarán solamente para el trafico del Relay.
Opciones para configurar el acceso remoto a una instancia de TOR
Aunque este punto ya se ha mencionado con anterioridad, solamente se ha mostrado el uso de unas pocas opciones disponibles en TOR, en concreto existen dos mecanismos de autenticación con una instancia de TOR, por un lado se encuentra el mecanismo de password (que se ha explicado en anteriores entradas y se define con la opción ControlPort) y por otro lado se encuentra el mecanismo de fichero de cookie, el cual permitirá autenticar de forma automática a un cliente que disponga de dicho fichero. Las opciones relacionadas con el acceso remoto a una instancia TOR son las siguientes:
ControlPort: El valor de esta opción es el puerto por el cual TOR escuchará peticiones en la maquina local para administración de la instancia, es necesario establecer las opciones HashedControlPassword o CookieAuthentication para establecer un mecanismo de autenticación dado que en otro caso, cualquier proceso podrá acceder a la administración de TOR.
ControlListenAddress: El valor de esta opción es la dirección IP y el puerto mediante el cual TOR escuchará peticiones locales y remotas para administración de la instancia, del mismo modo que ocurre con ControlPort es necesario establecer de forma explicita un mecanismo de autenticación, ya sea por password o por fichero de cookie.
ControlSocket: Funciona del mismo modo que la opción ControlPort solamente que en lugar de abrir un puerto en la maquina local, utiliza un socket UNIX para abrir las conexiones.
ControlSocketsGroupWritable: Esta opción debe ir acompañada con la opción ControlSocket para que tenga algún sentido, ya que solamente permite/rechaza la lectura y escritura del socket UNIX creado por el ControlSocket por parte del grupo al que hace parte el sistema de archivos, si esta opción tiene el valor de 0 rechaza la lectura/escritura, si tiene el valor de 1 el socket puede ser leido/escrito por el GID por defecto.
CookieAuthentication: Cuando se establece el valor 1 a esta opción, el mecanismo de autenticación con el “control port” se realizará cuando el proceso de conexión disponga del contenido del fichero “control_auth_cookie” el cual es creado automáticamente por TOR en el “Data Directory”
CookieAuthFile: Esta opción permite declarar la ruta absoluta donde se almacenará el fichero de cookie para la autenticación con el proceso de administración de TOR, si esta opción no se establece, el valor por defecto será la ruta de Data Directory (opción de TOR DataDirectory)
CookieAuthFileGroupReadable: Si se establece a 0, no permitirá que ningún proceso asignado al grupo del sistema de archivos pueda leer el fichero de Cookie-Auth, estableciendo el valor de 1, permitirá que el GID por defecto pueda leer dicho fichero.
Ahora bien, con las opciones anteriormente explicadas, se pueden tener dos mecanismos distintos de autenticación, por fichero de Cookie o por clave, en ambos casos, el conjunto de opciones en el fichero de configuración será similar a los siguientes:
Autenticación por Password
|
Autenticación por Cookie-File
|
Opciones de Configuración de Proxy en red local.
Se trata de opciones que establecen la forma en la cual se van a tratar las conexiones en el segmento de red local, son útiles en lugares donde existe un servidor proxy que brinda acceso al exterior y que actúa como filtro y como gateway para las conexiones cuyo destino es una red externa. Este tipo de mecanismos son muy frecuentes en organizaciones de tamaños medianos y grandes, donde todas las conexiones entrantes y salientes son monitorizadas y filtradas. Estas opciones no intenta “saltar” estos filtros, simplemente le indican a TOR que existe un proxy en la red y que esta es la pasarela de salida de las conexiones necesarias para establecer correctamente un circuito. Las opciones son:
HTTPProxy: Si se incluye esta opción, TOR intentará consultar el directorio de servidores de TOR para establecer un circuito valido y comenzar la transmisión de paquetes, como parámetros se esperan el host+puerto en el caso de que no se indique de forma explicita el puerto, se asume el puerto 80 por defecto.
HTTPProxyAuthenticator: Si se establece esta opción, es necesario que la opción HTTPProxy también se encuentre definida, ya que es valida solamente para especificar el usuario y la clave necesarias para realizar la autenticación con el proxy (en el caso de que lo requiera)
HTTPSProxy: Funciona exactamente igual que la opción HTTPProxy pero se utiliza cuando un proxy funciona sobre HTTPS.
HTTPSProxyAuthenticator: Funciona exactamente igual que la opción HTTPSProxyAuthenticator pero se utiliza cuando un proxy funciona sobre HTTPS.
Algunos ejemplos sobre el uso de estas opciones en el fichero de configuración de TOR son:
|
También es posible especificar que todas las conexiones OR hacia los directorios de TOR se realizaran por medio de un proxy SOCKS.
Socks4Proxy: Todas las conexiones se llevaran a cabo por medio del proxy SOCKS4 indicado.
Socks4Proxy: Todas las conexiones se llevaran a cabo por medio del proxy SOCKS5 indicado.
Socks5ProxyPassword: En el caso de que el proxy requiera autenticación por medio de contraseña esta propiedad debe ser establecida.
Opciones de Arranque y configuración del comportamiento de TOR
Estas opciones son útiles para personalizar el comportamiento de TOR al momento de su arranque y posterior ciclo de ejecución:
KeepAlivePeriod: Es útil para evitar que un firewall expire conexiones, este mecanismo envía paquetes con “KeepAlive” cada X segundos sobre una conexión abierta en uso, si la conexión no tiene ningún circuito abierto, en lugar de mantener la conexión, esta será cerrada después de X segundos de inactividad, el valor por defecto de esta propiedad es de 5 minutos.
Log: Permite especificar como se comportará TOR con respecto a los mensajes que generá durante su arranque y ejecución, se trata de una opción bastante completa que permite especificar el nivel de mensajes (nivel de severidad) y el destino de dichos mensajes (consola estándar, consola de errores o fichero). Los niveles de Log reconocidos en TOR son: debug, info, notice, warn y err, el nivel de severidad sigue este mismo orden, desde el más “informativo” que es debug, hasta el más severo que es err. Dada la gran cantidad de trazas que se generan en los estados debug e info se recomienda establecer el nivel de Log a notice.
Algunos valores validos son:
|
ProtocolWarnings: Si su valor es “1” TOR marcará como warn varios eventos producidos en el contexto de ejecución del servicio que no siguen la especificación de TOR, de otro modo son marcados como info el valor por defecto es 0.
PidFile: Permite especificar un fichero donde se almacenará el PID del proceso creado por TOR.
User: Cuando TOR arranca establece el setuid y el setgid del proceso principal de TOR al UID establecido en esta opción.
AvoidDiskWrites: Si su valor es distinto de 0, el proceso de TOR intentará escribir con menor frecuencia en disco, esto es útil cuando TOR se ejecuta desde dispositivos USB o Flash que son de lento y limitado acceso el valor por defecto es 0.
Estos valores pueden ser validos en un fichero torrc
|
Seguridad en Sistemas y Técnicas de Hacking. TheHackerWay (THW) 