Skip to content
Snippets Groups Projects

TorRelayGuide ptbr

Last edited by Alexander Færøy

= Guia de Relay Tor =

A rede Tor depende da doação de conexão de internet por voluntários/as. Quanto mais pessoas estiverem rodando servidores Tor, mais rápida será a rede Tor.

Neste guia utilizaremos os seguintes termos para se referir aos servidores Tor: relays (em inglês) ou retransmissores, nós ou relés, em português.

Usando esse guia

Esse guia inclui as boas práticas que são essenciais para servidores saudáveis do Tor. Nós incluímos passos técnicos, considerações legais, e informações sobre como rodar nós da rede Tor. O guia está organizado em três partes:

Se você desejar pular diretamente para a configuração do relay, leia somente a parte dois.

=== Utilização das palavras "Tor" e "tor" nesse guia ===

Nós usamos "tor" (caixa baixa) sempre que falamos especificamente sobre o programa tor (daemon), em todos os outros casos nós usamos "Tor".

== Parte um: decidindo rodar um servidor Tor ==

=== Por quê rodar um servidor Tor? ===

Ao rodar um servidor você poderá ajudar a rede Tor se tornar:

  • mais rápida (e portanto mais utilizável)
  • mais robusta contra ataques
  • mais estável em caso de falta de energia
  • mais segura para os usuários (vigiar mais servidores é mais difícil do que alguns poucos)

Tipos de nós na rede Tor

Todos os nós ou servidores da rede Tor são importantes, mas eles tem diferentes requisitos técnicos e implicações legais. Entendendo os diferentes tipos é o primeiro passo para aprender qual é o melhor para você.

Servidor de Guarda/Intermediário (ou relay sem saída)

O servidor de Guarda é o primeiro nó na rede de 3 servidores que formam um circuito Tor. Um servidor Intermediário, ou do meio, não é nem um servidor de Guarda e nem de Saída, mas atua como uma conexão entre os dois servidores. Para se tornar Guarda, o servidor precisa ser estável e rápido (no mínimo 2 MByte/s), senão se tornará um nó Intermediário.

Os servidores de Guarda e Intermediário não recebem reclamações de abuso ou outras notificações jurídicas. Porém, todos os servidores são listados publicamente como parte da rede Tor, então podem ser bloqueados por serviços que não entendem como o Tor funciona ou deliberadamente quando querem censurar usuários/as do Tor. Se você está rodando um servidor em casa e tem um IP estático, talvez seja melhor considerar rodar uma Ponte (Bridge) para que o tráfego da sua rede comum, isto é, que não é da rede Tor, também não sofra algum bloqueio. Se você utiliza endereço IP dinâmico ou múltiplos IPs estáticos, isso não será problema.

Um servidor Intermediário requer uma manutenção mínima e o uso da banda larga pode ser altamente customizável pela configuração no tor (isso será descrito com mais detalhes nas próximas seções). A assim chamada "política de saída" do servidor decide se ele permite os clientes desse circuito gerado pelo Tor, “sair” pelo seu servidor. Um servidor Intermediário ou de Guarda tem como política negar a saída pela a sua rede.

==== Servidor de Saída (ou Exit relay, em inglês) ====

O servidor de Saída, ou do inglês Exit relay, é o último servidor do circuito Tor, o qual envia o tráfego de rede para o destino. Os clientes Tor que estão conectando a (websites, serviços de chat, provedores de email, etc) verão o endereço IP do servidor de Saída ao invés do endereço IP real do usuário Tor.

Os servidores de Saída tem a maior exposição legal e responsabilidade entre todos os servidores. Por exemplo, se um usuário baixar material com direito autoral enquanto utiliza um servidor de Saída, você enquanto operador pode receber uma notificação do DMCA (Digital Millennium Copyright Act, ou, em português, Lei dos Direitos Autorais do Milênio Digital). Qualquer reclamação de abuso sobre o servidor irá diretamente para você (via seu provedor, dependendo dos registro WHOIS). Geralmente, a maioria das reclamações podem ser facilmente lidadas com cartas modelo, que nós discutiremos mais a respeito na seção de considerações legais.

Devido à exposição legal você não deve rodar um nó de Saída do Tor na sua casa. Idealmente, operadores/as de servidores de Saída são ligados ou parceiros de alguma instituição, como uma universidade, uma biblioteca, um hackerspace ou uma organização privada. Geralmente uma instituição não só fornece uma boa conexão para o servidor de saída, mas também está melhor posicionada para lidar com reclamações de abuso ou das raras requisições por oficiais da lei.

Se você está interessado/a em rodar um servidor de Saída, por favor leia TorRelayGuide-ptbr#Partetr%C3%AAs:informa%C3%A7%C3%B5eslegaisinforma%C3%A7%C3%B5essociaisemaisrecursos para operadores/as de servidores de Saída.

Ponte (ou Bridge, em inglês)

Na arquitetura da rede Tor, os endereços de IP dos servidores Tor são públicos. Entretanto, uma das formas que o Tor pode ser bloqueado por governos ou provedores de internet é colocando todos os endereços IP dos servidores da rede Tor em listas de bloqueio.

As Pontes são servidoras que não são listadas no diretório público do Tor, o que torna mais difícil para provedores de internet e governos de bloqueá-las.

As Pontes são úteis para usuários Tor que estão sob regimes autoritários ou por pessoas que queiram uma camada extra de segurança se estiverem preocupadas com o fato de alguém descobrir que elas estejam se conectando num endereço IP da rede Tor.

Vários países, incluindo China e Irã, encontraram formas de detectar e bloquear as Pontes do Tor. Os Transportes Plugáveis, são um tipo especial de Ponte, contorna este tipo de situação acrescentando uma camada adicional de ofuscação.

As Pontes são servidores relativamente fáceis de operar, com baixo risco e utilizam pouco tráfego da sua banda larga, mas eles trazem um grande impacto nos usuários. Uma Ponte não tem nenhuma probabilidade de receber reclamação de abuso, e uma vez que as Pontes não são listadas em diretórios públicos, é muito improvável de serem bloqueadas por serviços populares. Os servidores de Ponte são uma ótima opção se você quiser somente rodar um servidor Tor na rede de sua casa, que tem apenas um IP estático, e não possui uma excelente conexão de internet para doar - nós recomendamos que a sua Ponte tenha no mínimo 1 Mbit/s.

=== Requerimentos dos servidores ===

Os requerimentos para os servidores Tor dependerão do tipo do relay e da velocidade da conexão de internet fornecida.

Banda larga e conexões

  • Um servidor que não seja de saída deve ser capaz de lidar com no mínimo 7000 conexões simultâneas. Isto pode sobrecarregar um roteador de baixo custo ou voltado para consumidor final. Se você quiser rodar um nó do Tor de um servidor (virtual ou dedicado) num data center está tudo bem. Mas se rodar numa rede em casa com esses roteadores, você terá que verificar se seu roteador poderá lidar com essa demanda ou se começará a ter problemas. Servidores de Saída velozes (>=100 Mbit/s) normalmente tem que lidar com muito mais conexões simultâneas (>100k).

  • É recomendado que um servidor tenha pelo menos 16 Mbit/s (Mbps) de upload de banda larga e 16 Mbit/s (Mbps) de download disponível para o Tor. Mais é melhor. O requerimento mínimo para um servidor é 10 Mbit/s (Mbps). Se tiver menos que 10 Mbit/s, e com pelo menos 1 Mb/s, nós recomendamos que você rode uma Ponte com suporte obfs4. Se você não sabe a velocidade da sua banda larga, meça pelo site: http://beta.speedtest.net

Tráfego de saída mensal

  • É recomendado que um servidor Tor tenha permissão de usar um mínimo de 100 GByte de tráfego de saída (e a mesma quantidade para o tráfego de entrada) por mês. Nota: Isso é somente cerca de 1 dia de tráfego em uma conexão de 10 Mbit/s (10 Mbps). Mais (>2 TB/mês) é melhor e recomendado. Idealmente o relay é executado num plano ilimitado. Se você possui um plano limitado, talvez você queira configurar o tor para usar apenas um dado volume de banda ou tráfego mensal.

Endereço IPv4 público

Todo servidor precisa de um endereço IPv4 - seja diretamente no host (recomendado) ou via NAT e redirecionamento de porta.

O endereço IPv4 não é obrigatório ser estático, porém, endereços IP estáticos são desejáveis. Seu endereço IPv4 deve permanecer inalterado por pelo menos 3 horas (se regularmente alterar com maior frequência do que isso, não faz muito sentido rodar um servidor Tor ou uma Ponte uma vez que levará muito tempo para distribuir a nova lista de IPs de servidores para os clientes - que acontece somente uma vez a cada hora).

Um endereço IPv6 adicional é muito bom e recomendado/encorajado, mas não é um requerimento (todos os servidores disponíveis comercialmente vem com pelo menos um endereço IPv4).

Nota: Você poderá rodar somente 2 servidores Tor por endereço público IPv4. Se você quiser rodar mais do que 2 servidores, você precisará de mais endereços IPv4.

Requerimento de memória

  • Um servidor Intermediário menor que 40 Mbit/s deve ter pelo menos 512 MB de memória RAM disponível.
  • Um servidor Intermediário mais rápido que 40 Mbit/s deve ter pelo menos 1 GB de memória RAM.
  • Para um servidor de Saída nós recomendamos pelo menos 1.5 GB de memória RAM por instância.

Espaço de Disco

O Tor não necessita de muito espaço em disco. Um servidor Tor típico precisa de um pouco menos que 200 MB para dados relacionados ao Tor.

CPU

  • Qualquer CPU moderno já está bom.
  • É recomendado utilizar CPUs com suporte AESNI (que tornará melhor a performance e permitir chegar entre ~400-450 Mbps em cada direção em uma única instância Tor com CPUs modernos). Se o arquivo /proc/cpuinfo conter a palavra aes seu CPU possui suporte a AES-NI.

==== Tempo online

  • O Tor não necessita de um tempo online alto, mas se seu servidor não conseguir rodar por mais de 2 horas ao dia, a sua utilidade estará limitada. Idealmente o nó do Tor deverá rodar num servidor que funcione 24/7. Não há problema em reiniciar a máquina e o processo tor.

==== Versão do Tor

Por motivos de segurança, os relays do Tor não devem mudar de uma versão org/teams/NetworkTeam/CoreTorReleases#Listofreleases do tor para uma versão não suportada. Algumas versões não suportadas são inseguras. Relays que tentarem mudar para uma versão insegura serão rejeitados da rede automaticamente.

Parte dois: Configuração técnica

Considerações para escolher um provedor de hospedagem

Se você tem uma conexão com a internet de alta velocidade (>= 100 Mbit/s de upload/download) e um computador físico, então essa é a melhor maneira de fazer um relay funcionar.

Ter completo controle sobre o hardware e a conexão garante um ambiente mais controlável e (se tudo feito corretamente) mais seguro. Você pode hospedar seu próprio hardware (computador) em casa ou em um data center, às vezes isso é chamado como instalar o relay numa "máquina dedicada" (bare metal).

Se não possuir o hardware necessário, você pode fazer um relay funcionar em um servidor dedicado ou "virtual private server" (VPS) alugado, isso pode custar entre R$19/mês até milhares de reais por mês, dependendo do seu provedor, configuração de hardware e da banda larga usada.

Muitos provedores não vão permitir que você hospede nós de saída do Tor, por isso você deve seguir os termos de serviço estabelecidos pelo provedor ou corre o risco de ter sua conta desabilitada.

Para mais informações sobre provedores de hospedagem e suas políticas de uso sobre permitir servidores da rede Tor, por favor, veja a lista mantida pela comunidade Tor: https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs.

Questões a serem consideradas antes de escolher um provedor

  • Quanto tráfego está incluso no plano? (O tráfego é "ilimitado"?)
  • O provedor oferece conexão usando IPv6? (É recomendado, porém não é obrigatório)
  • Qual virtualização/hypervisor (se houver) o provedor usa? (Qualquer uma exceto OpenVZ está OK)
  • O provedor começa a restringir a velocidade da conexão após um limite de tráfego usado?
  • O quão bem conectado está o sistema autônomo (AS) do provedor? Para responder à essa pergunta você pode comparar usando a classificação AS de sistemas autônomos: ​http://as-rank.caida.org/ (quanto menor o valor, melhor).

Se você pretende rodar um servidor de saída

  • O provedor permite hospedar servidores de saída da rede Tor? (pergunte explicitamente a eles antes de começar a instalar um nó de saída)
  • O provedor permite customizar registros WHOIS para seus endereços IPs? Isso ajuda a reduzir a quantidade de denúncias por abuso enviadas para o provedor ao invés de serem enviadas para você.
  • O provedor permite que você configure uma entrada DNS reversa customizável? (registros DNS PTR) Essas são coisas que você terá que perguntar ao provedor antes de realizar a compra do serviço.

Diversidade de AS/localização

Quando for escolher um provedor de hospedagem considere a diversidade de rede de Sistema Autônomo (AS, em inglês) e país. Uma rede mais diversa é mais resiliente a ataques e indisponibilidades. Muitas vezes não está claro qual AS você está comprando no caso de revendedores, então esteja certo de que é melhor perguntar ao provedor de hospedagem sobre o número do AS antes de comprar um servidor.

É melhor evitar provedores de hospedagem nos quais já existem muitos nós do Tor, mas com certeza é melhor adicionar mais um servidor do que não adicionar nenhum. Tente evitar as seguintes empresas:

  • OVH SAS (AS16276)
  • Online S.a.s. (AS12876)
  • Hetzner Online GmbH (AS24940)
  • DigitalOcean, LLC (AS14061)

Para descobrir quais provedores e países já estão hospedando relays (e que portanto devem ser evitados), busque em "Relay Search":

Escolhendo um sistema Operacional

Recomendamos que você use o Sistema Operacional com o qual você tem mais familiaridade. Por favor, tenha em mente que pela maioria dos servidores da rede Tor funcionarem com a distribuição GNU/Linux Debian, nós queremos evitar uma monocultura, então servidores funcionando com SOs baseados em *BSD são imensamente necessitados.

A tabela a seguir mostra quais as distribuições de sistemas operacionais existem atualmente na rede Tor, para dar uma ideia de quantos mais relays que não são baseados em GNU/Linux nós deveríamos ter:

Configuração na camada do Sistema Operacional

A configuração do Sistema Operacional está fora do escopo deste guia, porém os pontos a seguir são cruciais para um servidor da rede Tor, então vamos citá-los de toda forma.

Sincronização de Data e Hora

A configuração correta de data e hora é essencial para os servidores Tor. É recomendado que você utilize o Network Time Protocol (NTP) para fazer a sincronização da data e garantir que o seu fuso horário esteja configurado corretamente.

Um guia simplificado para configuração de NTP em sistemas baseados em Linux (ou sistemas operacionais BSD) está disponível aqui. Caso necessite de guias mais específicos, veja este guia.

Atualização automática de software

Uma das coisas mais importantes para manter o seu servidor seguro é instalar as atualizações de segurança na hora e idealmente de forma automática, assim você não se esquecerá disso. Nós reunimos os passos necessários para a atualização automática de software para os diferentes sistemas operacionais:

Configuração do servidor Tor: instalação e configuração

Essa seção cobre a instalação e configuração de um programa requerido para rodar o servidor Tor em vários sistemas operacionais. Esses passos são necessários para ter a última versão estável de cada sistema Operacional e no Ubuntu para a última versão LTS.

Nota: Para alguns SOs existe uma versão alpha de pacotes disponível (uma versão Tor com novas funcionalidades que ainda não é estável). Esses pacotes são recomendados apenas para pessoas ansiosas por testar e reportar bugs em funcionalidades/atualizações novíssimas. Se você está querendo fazer um servidor funcionar com mínimo esforço, recomendamos que você se mantenha nas versões estáveis.

Neste guia nós descrevemos como configurar um novo servidor intermediário (ou relay, do inglês), mas ao avançar na leitura você poderá facilmente mudar para tornar-se um servidor de saída.

Perguntas que devem ser respondidas antes de configurar o Tor:

  • Você pretende fazer funcionar um relay de saída ou intermediário?
  • Se você quer fazer funcionar um relay de saída: Quais as portas você quer permitir na sua política de saída? (Mais portas geralmente significam mais reclamações de abusos)
  • Qual porta TCP externa você quer usar para receber conexões? (Configuração "ORPort", recomendamos a portar 443 se ela já não for usada por nenhum serviço em seu servidor. ORPort 443 é recomendado pois é uma das poucas autorizadas em uma rede wifi pública. A porta 9001 é outra ORPort comumente usada).
  • Que endereço de e-mail você usará no campo de Informações de Contato do seu servidor? Nota: Essa informação será pública.
  • Quanto da banda larga mensal você quer disponibilizar para o tráfego da rede Tor?
  • O servidor possui um endereço IPv6?

Os comandos de instalação são mostrados no blocos de código e devem ser executados com privilégio root.

Certifique-se de que as portas do relay estão acessíveis

Se você estiver usando um firewall, crie uma regra para que o tráfego que chega possa acessar a porta que o relay utilizará (ORPort ou DirPort, se você tiver a habilitado). Também certifique-se de que há uma regra permitindo todo o tráfego saindo, assim seu relay Tor pode acessar os outros servidores Tor, clientes e destinos. Você pode encontrar o número da ORPort específica no exemplo de configuração torrc abaixo (na seção específica de cada SO).

Gerencimanto de configuração

O Tor não escala muito bem em máquinas multi-núcleos, então se você estiver executando um relay Tor em um servidor com uma conexão de internet rápida (>200 Mbit/s), você vai querer considerar executar múltiplas instâncias Tor em um único servidor com múltiplos núcleos. Nota: Você só pode executar duas instâncias Tor por IPv4 público.

Se você planeja executar mais que um único relay, ou se você quer executar um relay de alta capacidade (múltiplas instâncias Tor por servidor), ou então quer usar funcionalidades fortes de segurança como Offline Master Keys sem realizar manualmente os passos adicionais de segurança, você vai querer usar o gerenciamento de configuração para uma melhor manutenção.

Existem múltiplas soluções de gerenciamento de configuração paa SOs baseados em Unix (Ansible, Pupper, Salt, ...).

O seguinte "Ansible Role" foi especificamente projetado para operadores de relays Tor e suporta múltiplos SOs:

O script bash a seguir para Debian e Ubuntu não é um gerenciamento de configuração, mas pode também ajudar a automatizar os passos necessários para configurar um novo relay Tor. Isso deve ser executado em um servidor que é usado apenas para o Tor:

CentOS/RHEL

  1. Habilite o repositório RHEL.

Para instalar o pacote tor em distribuições CentOS/RHEL, você precisa primeiro instalar o repositório EPEL.

yum install epel-release
  1. Instale o pacote tor e verifique a chave de assinatura EPEL
yum install tor

Quando você instalar o primeiro pacote do repositório EPEL será solicitado que verifique a chave de assinatura GPG EPEL, por favor, assegure-se que a chave é a correspondente à chave disponível no website do Projeto Fedora ​https://getfedora.org/keys/

  1. Coloque no arquivo de configuração tor em /etc/tor/torrc:
#Troque o apelido "myNiceRelay" por um nome que você prefira
Nickname myNiceRelay
ORPort 9001
SocksPort 0
ExitRelay 0
#Troque o e-mail abaixo e esteja ciente de que ele será público
ContactInfo tor-operator@seu-dominio-de-email
  1. Habilite e reinicie seu relay tor:
systemctl enable tor
systemctl start tor

Debian/Ubuntu

  1. Habilite o repositório de pacotes do Torproject:

Isso é opcional no Debian, porém é obrigatório no Ubuntu. Não utilize os pacotes do tor no repositório Universe Ubuntu. Obtenha as fontes do repositório para adicionar ao seu arquivo de configuração /etc/apt/sources.list rodando o configurador aqui. Também lembre-se de importar as chaves GPG, isso garantirá que você está executando a última versão estável do Tor.

  1. Instale o pacote tor 
apt update && apt install tor
  1. Coloque no arquivo de configuração em /etc/tor/torrc:
# Troque o apelido "myNiceRelay" por um nome que você prefira
Nickname myNiceRelay
ORPort 9001
SocksPort 0
ExitRelay 0
# Troque o e-mail abaixo e esteja ciente de que ele será público
ContactInfo tor-operator@seu-dominio-de-email
  1. Reinicie o serviço do tor para que a configuração seja aplicada:
systemctl restart tor@default

DragonFlyBSD

  1. Descarregue o pkg:
# cd /usr
# make pkg-bootstrap
# pkg-static install pkg
# rehash
  1. Instale o pacote tor:
# pkg install tor
''**NOTA:** uma versão mais recente do Tor está disponível para DragonFlyBSD. caso deseje instalar esta versão, você deverá utilizar `DPorts`. consulte o [https://www.dragonflybsd.org/docs/howtos/HowToDPorts/#index5h1 guia oficial] do projeto.''
  1. Configure o arquivo /usr/local/etc/tor/torrc:
Nickname    meuRelayBSD # MUDE ESTE NOME
ContactInfo meu@email   # INSIRA SEU ENDEREÇO DE EMAIL E ESTEJA CIENTE QUE ELE SERÁ PUBLICADO
ORPort      443         # TENTE UTILIZAR UMA OUTRA PORTA CASO '443' NÃO FUNCIONE PARA VOCÊ
ExitRelay   0
SocksPort   0
Log notice  syslog
  1. Habilite/Inicie o serviço:
# echo "tor_enable=YES" >> /etc/rc.conf
# echo "tor_setuid=YES" >> /etc/rc.conf
# service tor start

Fedora

  1. Instale o pacote tor:

dnf install tor

  1. Coloque no arquivo de configuração em /etc/tor/torrc:
# Troque o apelido "myNiceRelay" por um nome que você prefira
Nickname myNiceRelay
ORPort 9001
SocksPort 0
ExitRelay 0
# Troque o e-mail abaixo e esteja ciente de que ele será público
ContactInfo tor-operator@seu-dominio-de-email
  1. Inicie o serviço do tor e certifique-se de que inicie no boot:
systemctl enable tor
systemctl start tor

FreeBSD

  1. Descarregue o pkg:
# pkg bootstrap
  1. Instale o pacote tor:
# pkg install tor
''**NOTA:** uma versão alpha do Tor está disponível para FreeBSD. caso deseje instalar esta versão, altere o nome do pacote para `tor-devel`.''
  1. Configure o arquivo /usr/local/etc/tor/torrc:
Nickname    meuRelayBSD # MUDE ESTE NOME
ContactInfo meu@email   # INSIRA SEU ENDEREÇO DE EMAIL E ESTEJA CIENTE QUE ELE SERÁ PUBLICADO
ORPort      443         # TENTE UTILIZAR UMA OUTRA PORTA CASO '443' NÃO FUNCIONE PARA VOCÊ
ExitRelay   0
SocksPort   0
Log notice  syslog
  1. Altere a variável net.inet.ip.random_id via sysctl:
# echo "net.inet.ip.random_id=1" >> /etc/sysctl.conf
# sysctl net.inet.ip.random_id=1
  1. Habilite/Inicie o serviço:
# sysrc tor_enable=YES
# sysrc tor_setuid=YES
# service tor start

HardenedBSD

  1. Instalar o pacote tor:
pkg install tor

ou a versão alpha:

pkg install tor-devel
  1. Coloque no arquivo de configuração /usr/local/etc/tor/torrc:
# Troque o apelido "myNiceRelay" por um nome que você prefira
Nickname myNiceRelay
ORPort 9001
SocksPort 0
ExitRelay 0
# Troque o e-mail abaixo e esteja ciente de que ele será público
ContactInfo tor-operator@seu-dominio-de-email
Log notice syslog
  1. Inicie o serviço tor e certifique-se de iniciar no boot:
sysrc tor_enable=YES
service tor start

NetBSD

  1. Configure o pkg_add:
# echo "PKG_PATH=http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/$(uname -m)/$(uname -r)/All" > /etc/pkg_install.conf
  1. Instale o pacote tor:
# pkg_add tor
''**NOTA:** uma versão mais recente do Tor está disponível para NetBSD. caso deseje instalar esta versão, utilize o `pkgsrc`. consulte o [https://www.netbsd.org/docs/pkgsrc/users-guide.html guia do usuário], e esteja atento para descarregar corretamente o ramo [https://www.netbsd.org/docs/pkgsrc/getting.html#getting-via-cvs current] do repositório.''
  1. Configure o arquivo /usr/pkg/etc/tor/torrc:
Nickname    meuRelayBSD # MUDE ESTE NOME
ContactInfo meu@email   # INSIRA SEU ENDEREÇO DE EMAIL E ESTEJA CIENTE QUE ELE SERÁ PUBLICADO
ORPort      443         # TENTE UTILIZAR UMA OUTRA PORTA CASO '443' NÃO FUNCIONE PARA VOCÊ
ExitRelay   0
SocksPort   0
Log notice  syslog
  1. Habilite/Inicie o serviço:
# ln -sf /usr/pkg/share/examples/rc.d/tor /etc/rc.d/tor
# echo "tor=YES" >> /etc/rc.conf
# /etc/rc.d/tor start

OpenBSD

  1. Configure o pkg_add:
# echo "https://ftp.openbsd.org/pub/OpenBSD" > /etc/installurl
  1. Instale o pacote tor:
# pkg_add tor
''**NOTA:** caso você deseje instalar uma versão mais recente do Tor para OpenBSD, existem 2 opções:''

  * utilize os pacotes binários da [https://stable.mtier.org/ M:Tier] (em inglês);
  * use a [https://www.openbsd.org/faq/ports/ports.html Coleção de Ports] do OpenBSD, de preferência em conjunto com [https://www.openbsd.org/anoncvs.html cvs].
  1. Configure o arquivo /etc/tor/torrc:
Nickname    meuRelayBSD # MUDE ESTE NOME
ContactInfo meu@email   # INSIRA SEU ENDEREÇO DE EMAIL E ESTEJA CIENTE QUE ELE SERÁ PUBLICADO
ORPort      443         # TENTE UTILIZAR UMA OUTRA PORTA CASO '443' NÃO FUNCIONE PARA VOCÊ
ExitRelay   0
SocksPort   0
DataDir     /var/tor
Log notice  syslog
  1. Habilite/Inicie o serviço:
# rcctl enable tor
# rcctl set tor flags "-f /etc/tor/torrc --User _tor"
# rcctl start tor

openSUSE

  1. Instalar o pacote tor:
zypper install tor
  1. Coloque no arquivo de configuração /usr/local/etc/tor/torrc:
# Troque o apelido "myNiceRelay" por um nome que você prefira
Nickname myNiceRelay
ORPort 9001
SocksPort 0
ExitRelay 0
# Troque o e-mail abaixo e esteja ciente de que ele será público
ContactInfo tor-operator@seu-dominio-de-email
  1. Inicie o serviço do tor e certifique-se que inicie no boot:
systemctl enable tor
systemctl start tor

Verifique se o seu relay funciona

Se o arquivo de log (syslog) contém a seguinte entrada depois de iniciar o serviço do tor no seu relay, então ele está online e funcionando como esperado:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

Após 3 horas que você iniciou o seu relay, ele deverá aparecer no Relay Search (​https://metrics.torproject.org/rs.html). Você poderá pesquisar por seu relay usando o apelido ou o endereço IP.

=== Obtendo ajuda

Se você tiver problemas durante a instalação do seu relay, você pode fazer perguntas na lista pública de e-mails tor-relays:

Esse é um ótimo meio para se fazer perguntas (e também de responder), e geralmente também para conhecer outros operadores/as de relay. Lembre-se de ler o nosso histórico da lista de e-mail!

Limitando o uso da banda larga (e tráfego)

O Tor não limitará o uso da banda por padrão, mas há várias formas para restringir o uso da banda larga e a quantidade de tráfego. Isso pode ajudar se quiser garantir que seu relay Tor não exceda uma certa velocidade ou quantidade total de tráfego por dia/semana/mês. As seguintes opções de configuração torrc podem ser usadas para restringir tráfego e velocidade:

É preferível ter um relay rápido por um período no mês do que um relay lento o mês inteiro.

Veja também a entrada sobre banda larga na nossa FAQ:

​https://www.torproject.org/docs/faq.html.en#BandwidthShaping

=== IPv6

Nós encorajamos todos a ativarem o IPv6 nos seus relays. Isso é de grande valor nos relays de saída e de guarda.

Antes de ativar o seu serviço tor para usar o IPv6 junto com o IPv4, verifique se a conectividade do IPv6 funciona do e para o seu servidor.

A seguinte linha executará um comando ping nos endereços IPv6 das Autoridades de Diretório do Tor no seu servidor:

ping6 -c2 2001:858:2:2:aabb:0:563b:1526 && ping6 -c2 2620:13:4000:6000::1000:118 && ping6 -c2 2001:67c:289c::9 && ping6 -c2 2001:678:558:1000::244 && ping6 -c2 2607:8500:154::3 && ping6 -c2 2001:638:a000:4140::ffff:189 && echo OK.

O resultado desse comando deverá mostrar um "OK.", se isso não ocorrer, não habilite o IPv6 no seu arquivo de configuração torrc enquanto não estiver funcionando. Se você habilitar IPv6 sem ter conectividade IPv6 o seu relay todo não será usado, mesmo que o IPv4 esteja funcionando.

Se isso funcionou corretamente, então, faça o seu relay Tor ficar acessível por IPv6 adicionando uma linha ORPort no seu arquivo de configuração (exemplo para ORPort 9001):

ORPort [IPv6-address]:9001

A localização dessa linha no seu arquivo de configuração não importa e você pode simplesmente adicionar próximo das primeiras linhas ORPort no seu arquivo torrc.

Nota: É necessário especificar explicitamente o seu endereço IPv6 entre colchetes, você não pode pedir para o tor fazer o bind de nenhum IPv6 (como você faz com o IPv4). Se você tem um endereço IPv6 global, é possível encontrá-lo através do seguinte comando:

ip addr|grep inet6|grep global

Se você tem um relay de saída com conectividade de IPv6, fale para o seu serviço tor continuar permitindo a saída via IPv6, assim os clientes podem acessar os destinos IPv6:

IPv6Exit 1

Nota: O Tor requer conectividade IPv4, você não pode rodar um relay com apenas IPv6.

Informação adicional referente ao IPv6 pode ser encontrada em: IPv6RelayHowto (EN).

=== Importante se você rodar mais que uma instância do Tor

Evite colocar clientes do Tor em risco. Quando você opera vários relays você necessita configurar a opção MyFamily corretamente e ter um ContactInfo válido na configuração do seu torrc. A configuração do MyFamily é uma forma simples de dizer para os clientes do Tor quais os relays do Tor são controlados por uma única entidade/operador(a)/organização, assim eles não são usados em mais de uma posição num único circuito.

Se você tiver dois relays e se, por exemplo, eles tivessem as impressões digitais AAAAAAAAAA e BBBBBBBB, você adicionaria a seguinte configuração no MyFamily:

MyFamily AAAAAAAAAA,BBBBBBBB

no arquivo dos dois relays. Para encontrar a impressão digital dos seus relays, você pode procurar nos arquivos de log quando o tor inicia ou procurar o arquivo chamado "fingerprint" dentro do diretório do Tor, o DataDirectory.

Ao invés de configurar manualmente, para grandes operadores/as, nós recomendamos automatizar a configuração do MyFamily usando uma solução de gerenciamento de configuração. Gerenciar manualmente a opção MyFamily para grandes grupos de relays é passível a erro e pode colocar clientes do Tor em risco.

Configuração do relay de saída

É recomendado que seja configurado relays de saída em servidores dedicados para esse propósito. Não é recomendado instalar relays de saída do Tor em servidores que você utiliza para outros serviços. Não misture o seu próprio tráfego com o tráfego de saída do seu relay.

DNS reverso e registro WHOIS

Antes de mudar o seu relay para virar um relay de saída, certifique-se que você tenha um claro registro de DNS reverso (PTR) para deixar claro para todo mundo que é um relay de saída. Algo como "tor-exit" no nome é um bom começo. Se o seu provedor oferece isso, verifique se o seu registro WHOIS contém indicações claras que esse é relay de saída do Tor.

Página HTML de Aviso de saída

Para tornar ainda mais óbvio que esse é um relay de saída do Tor, você pode servir uma página HTML de aviso de saída do Tor. O Tor pode fazer isso se a sua DirPort for a porta 80 TCP, você pode utilizar a funcionalidade do tor DirPortFrontPage para mostrar o arquivo HTML naquela porta. Esse arquivo será exibido para qualquer um que estiver navegando no endereço de IP do seu relay de saída.

DirPort 80
DirPortFrontPage /path/to/html/file

Nós fornecemos um exemplo de arquivo HTML de aviso de saída, mas talvez você queira ajustar para as suas necessidades: ​https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html

Aqui estão algumas dicas a mais para executar um relay de saída confiável: https://blog.torproject.org/tips-running-exit-node

DNS nos Relays de saída

Diferente dos outros tipos de relays, os relays de saída também fazem resolução de DNS nos clientes do Tor. A resolução de DNS nos relays de saída é crucial para os clientes de Tor, e deve usar cache para ser confiável e rápida.

  • A resolução de DNS pode ter um impacto significante na performance e na confiabilidade da saída que o seu relay fornece. Performance fraca de DNS resultará em menos tráfego passando por seu relay de saída.
  • Não use nenhum dos grandes resolvedores de DNS como seu DNS primário ou secundário para evitar centralização (Google, OpenDNS, Quad9, Cloudflare, 4.2.2.1-6).
  • Nós recomendamos rodar um resolvedor de cache local e validação de DNSSEC sem depender de serviços de terceiros (as instruções específicas seguem abaixo para cada sistema operacional).
  • Se você quiser adicionar um segundo resolvedor de DNS de reserva em sua configuração /etc/resolv.conf, tente escolher um resolvedor dentro do seu sistema autônomo e verifique se não está como a primeira linha nesse arquivo (a primeira entrada deve ser o seu resolvedor local).
  • Se um resolvedor local como unbound não é uma opção para você, tente usar um resolvedor que o seu provedor fornece no mesmo sistema autônomo (para descobrir se um endereço IP que está no mesmo AS que o seu relay, você pode procurar usando, por exemplo, https://bgp.he.net).
  • Tente evitar adicionar muitos resolvedores em seu arquivo /etc/resolv.conf para limitar a exposição no nível do sistema autônomo (tente não usar mais que duas entradas).

Existem várias opções de software de servidor de DNS, e unbound tornou-se uma opção popular, mas sinta-se livre para usar qualquer outro que você se sinta confortável. Ao escolher o software resolvedor de DNS, certifique-se que tenha suporte para validação DNSSEC e minimização de QNAME (RFC7816). Em todo caso, o software deverá ser instalado por um gerenciador de pacote para garantir as atualizações junto com o resto do sistema operacional.

Ao usar o seu próprio resolvedor de DNS, você estará menos vulnerável por censura baseada no DNS que o seu resolvedor upstream possa impor.

Siga aqui as instruções específicas como instalar e configurar o unbound no seu relay de saída - um programa de validação de DNSSEC e cache de resolvedor. O unbound tem muitas configurações e opções de ajustes, mas nós tentamos manter essas instruções tão simples e curtas quanto foi possível e a configuração básica estará ótima para a maioria dos/as operadores/as.

Após mudar para o unbound, verifique se funciona como esperado ao tentar resolver um hostname válido, se não funcionar, você pode restaurar o seu antigo arquivo resolv.conf.

Debian/Ubuntu

Os próximos três comandos instalam o unbound, fazem a cópia da sua configuração de DNS e falam para o seu sistema usar localmente o unbound:

apt install unbound
cp /etc/resolv.conf /etc/resolv.conf.backup
echo nameserver 127.0.0.1 > /etc/resolv.conf

Para evitar que essa configuração seja modificada (por exemplo, pelo cliente DHCP):

chattr +i /etc/resolv.conf

A configuração do Debian já vem com minimização QNAME (RFC7816) ativada por padrão, assim você não precisa ativá-la explicitamente. O resolvedor unbound que você instalou também faz validação de DNSSEC.

CentOS/RHEL

Instale o pacote unbound:

yum install unbound

Em /etc/unbound/unbound.conf substitua a linha

# qname-minimisation: no

por:

qname-minimisation: yes

Ative e inicie o unbound:

systemctl enable unbound
systemctl start unbound

Fale para o sistema usar o servidor local do unbound:

cp /etc/resolv.conf /etc/resolv.conf.backup
echo nameserver 127.0.0.1 > /etc/resolv.conf

Para evitar que a configuração seja modificada (por exemplo, pelo cliente DHCP):

chattr +i /etc/resolv.conf

FreeBSD

O FreeBSD disponibiliza o unbound no sistema básico, mas a versão disponível no ports geralmente está mais atualizada com a versão principal, assim nós instalaremos o pacote unbound:

pkg install unbound

Substitua o conteúdo do arquivo /usr/local/etc/unbound/unbound.conf com as seguintes linhas: server:

        verbosity: 1
        qname-minimisation: yes

Ative e inicie o serviço unbound:

sysrc unbound_enable=YES
service unbound start

Fale para o sistema usar o servidor local do unbound:

cp /etc/resolv.conf /etc/resolv.conf.backup
echo nameserver 127.0.0.1 > /etc/resolv.conf

Para evitar que a configuração seja modificada (por exemplo, pelo cliente DHCP):

chflags schg /etc/resolv.conf

Política de saída

Defina a sua política de saída. A política de saída define quais portas de destino você deseja reenviar. Isso tem um impacto na quantidade de e-mails sobre abusos que você receberá (menos portas significa menos e-mails de abusos, mas um relay de saída permitindo apenas poucas portas é também menos útil). Se quiser ser um relay de saída útil, você deve pelo menos permitir as portas de destino 80 e 443.

Como um novo relay de saída - especialmente se for novo no local de hospedagem - é bom começar com uma política de saída reduzida (para reduzir a quantidade de e-mails sobre abuso) e futuramente abrir as portas conforme você ficar mais experiente. A política de saída reduzida pode ser encontrada na seguinte página: https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy

Último passo: ativar a saída no seu arquivo de configuração

Para se tornar um relay de saída mude em seu arquivo de configuração torrc ExitRelay de 0 para 1 e reinicie o serviço do tor.

ExitRelay 1

=== O ciclo de vida de um relay do Tor===

Leva algum tempo até o tráfego de um relay aumente, isso é especialmente verdade para relays de Guarda, mas em menor medida para os relays de saída:

https://blog.torproject.org/lifecycle-new-relay

Mantendo um relay

Faça backup das suas chaves de identidade

Após a instalação inicial e início do serviço do tor, é uma boa ideia fazer o backup das suas chaves de identidade de longa duração do seu relay. Elas estão localizadas em “keys” no subdiretório do seu DataDirectory (simplesmente faça uma cópia do diretório inteiro e armazene numa localização segura).

Uma vez que seu relay leva um tempo para aumentar o tráfego, faz sentido fazer uma cópia da sua chave de identidade para ser capaz de restaurar a reputação do seu relay depois de uma falha de disco – senão terá que passar novamente por essa fase inicial de teste.

A localização padrão do seu diretório de chaves:

  • Debian/Ubuntu: /var/lib/tor/keys
  • DragonFlyBSD/FreeBSD/HardenedBSD: /var/db/tor/keys

Inscreva-se na lista de e-mail tor-announce

Essa é uma lista de e-mail com pouco tráfego e você receberá informação sobre novas versões estáveis do tor e importante informação de atualização de segurança. ​https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce

==== Configurar notificação de falhas ====

Uma vez configurado, provavelmente o seu relay dará pouco trabalho. Se alguma coisa der errado, é bom ser notificado automaticamente. Nós recomendamos usar um desses serviços gratuitos que permitem checar o acesso a ORPorts do seu relay e enviar um e-mail caso ela fique indisponível por qualquer razão.

O UptimeRobot é um desses serviços que permite monitorar portas arbitrárias de TCP. Esse serviço pode checar as suas portas configuradas uma vez a cada 5 minutos e enviar um e-mail caso seu processo do tor falhe ou torne-se indisponível. Ele checa apenas a disponibilidade, mas não se comunica com o protoloco do Tor.

Uma boa forma de monitorar a saúde do seu relay é observar os gráficos do consumo de banda larga.

Monitoramento da saúde do sistema

Para garantir que o seu relay esteja saudável e não sobrecarregado, faz sentido ter algum monitoramento básico do sistema para observar as seguintes métricas:

  • Tráfego e velocidade da conexão
  • Conexões TCP estabelecidas
  • Memória
  • Swap
  • CPU

Há muitas ferramentas para monitorar esse tipo de dados, o munin é uma delas e é relativamente fácil configurar.

Nota: Não torne público os gráficos de monitoramento de dados, uma vez que isso poderia ajudar atacantes a desanonimizar os/as usuários/as do Tor.

Algumas recomendações práticas:

  • Relatórios individuais de dados de relays é pior do que reportar o total para um grupo de relays. No futuro, o tor agregará de forma segura as estatísticas de uso de banda, portanto, qualquer relatório sobre o uso de banda de um relay será menos seguro do que as estatísticas do tor.
  • Períodos menores são piores.
  • Números são piores do que gráficos.
  • Dados em tempo real é muito pior do que dados históricos.
  • Dados por categoria (versão do IP, entrada/saída, etc) é pior do que dados totais.

==== Ferramentas

Essa seção listamos algumas ferramentas que você pode achar convenientes como um/a operador/a de servidor do Tor.

Nyx: Nyx é uma ferramenta do Projeto Tor (antigamente chamada arm) que permite ver dados em tempo real do seu relay.

vnstat: vnstat é uma linha de comando que mostra a quantidade de dados trafegados pela sua conexão de rede. Você pode gerar imagens em PNG mostrando os gráficos do tráfego. Documentação do vnstat e exemplo de imagem:

Parte três: informações legais, informações sociais e mais recursos

Considerações legais (para operadores de relay de saída)

Operadores de relay de saída devem compreender o risco potencial associado ao rodar um relay. Para a maioria dos operadores em quase todos os países, pontes e relays de guarda/intermediário são de risco muito baixo. Os de saída são os que apresentam preocupações legais, mas operadores sob a maioria das circunstâncias estarão aptos a lidar com os assuntos legais tendo uma carta de resposta à abuso, hospedando o relay de saída de um lugar que não é sua casa e lendo alguns dos recursos legais que advogados que apoiam Tor reuniram.

Recursos legais

As perguntas frequentes jurídicas do Tor (​https://www.torproject.org/eff/tor-legal-faq.html.en) escrita pela Electronic Frontier Foundation (EFF) respondem a muitas perguntas comuns sobre a operação de relays e a lei. Também indicamos a wiki do Noisebridge para recursos legais adicionais:

https://www.noisebridge.net/wiki/Noisebridge_Tor/FBI.

Em geral é uma boa ideia consultar um advogado antes de decidir operar um relay de saída, especialmente se você vive em um lugar onde operadores deste tipo foram incomodados ou se você é o único na sua região. Entre em contato com sua organização local de direitos digitais para verificar se eles tem recomendações sobre assistência legal, e se você não tem certeza quais organizações estão trabalhando na sua região, entre em contato com a EFF para ver se podem te ajudar a entrar em contato com elas: https://www.eff.org/about/contact.

Além disso, veja o guia de para relays de saída: https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines

Respondendo a reclamações de abuso

Operadores/as podem agregar ao seu modelo de resposta um dos vários modelos que o Tor criou:

https://trac.torproject.org/projects/tor/wiki/doc/TorAbuseTemplates.

É importante responder a essas reclamações num tempo razoável (geralmente em menos de 24 horas). Se o provedor ficar incomodado com a quantidade de abusos reportados, você pode reduzir a quantidade de portas permitidas pela sua política de saída. Por favor, documente sua experiência com novos provedores nesta página da wiki:

https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs

Outros documentos úteis:

Rodando um relay com outras pessoas

Rodar relays é mais divertido com outras pessoas! Você pode trabalhar com o departamento da sua universidade, o seu empregador ou instituto, ou uma organização como Torservers.net para rodar um relay.

Torservers.net

[| Torservers] é uma rede global de organizações independentes que ajudam a rede Tor rodando relays com alta taxa de banda. Ser um parceiro do Torservers é um bom jeito de ficar mais envolvido com a comunidade de operadores de relays, e podem ajudar a se conectar com operadores dedicados ao redor do mundo para solidariedade e suporte. Para virar um parceiro do Torservers, a coisa mais importante a se fazer é ter um grupo de pessoas (3-5 para começar) interessadas em ajudar com as várias atividades necessárias para se rodar um relay. Deve haver confiança mútua entre as pessoas do grupo, e os membros devem se comprometer a operar um relay por um longo prazo. Se você não conhece ninguém interessado no seu meio social em operar relays, um lugar para conhecer pessoas é num hackerspace próximo a você: ​https://wiki.hackerspaces.org/Hackerspaces

Quando você tiver um grupo confiável de pessoas, dependendo do seu país, é comum ser aconselhado criar algum tipo de organização sem fins lucrativos/não governamental. Isso é útil para ter uma conta bancária, propriedade compartilhada, submissão à editais, etc. Em muitos países, operar um relay como uma ONG ao invés de pessoa física pode dar alguma proteção legal.

Os próximos passos são procurar o hardware, conexão e hospedagem a serem utilizados. Dependendo do seu país e das conexões disponíveis pela comunidade técnica da área, essa pode ser a parte mais difícil. Pequenos provedores de internet (ISP) locais podem ter banda sobrando, e podem estar interessados em ajudar seu grupo provendo um pouco de banda ou um espaço físico no servidor. É extremamente importante manter boas relações com estes provedores.

Na sua universidade

Muitos departamentos de ciência da computação, bibliotecas universitárias, estudantes individuais e docentes operam relays a partir da sua rede universitára. Essas universidades incluem o MIT, Boston University, University of Waterloo, University of Washington, Northeastern University, Karlstad University, Universitaet Stuttgart e a Friedrich-Alexander University Erlangen-Nuremberg. Os links das universidades públicas brasileiras fazem parte do backbone da Rede Nacional de Ensino e Pesquisa (RNP), uma das melhores conexões disponíveis no país. Para saber mais sobre como conseguir suporte para um relay na sua universidade, verifique os documentos disponibilizados pela EFF: ​https://www.eff.org/torchallenge/tor-on-campus.html.

Na sua empresa ou organização

Se você trabalha em uma empresa ou organização simpatizante do projeto Tor, esse é um outro cenário ideal para operar um relay. Algumas empresas que rodam relay são: New York Internet (NYI), Brass Horn Communications, Quintex Alliance Consulting e OmuraVPN. Algumas organizações que também fazem: Digital Courage, Access Now, Derechos Digitales e Lebanon Libraries em New Hampshire.

Mais recursos

Parabéns, você é oficialmente um/a operador/a de um relay do Tor! E agora?

Como reportar um erro nesse guia

Por favor, abra um tíquete de erro e escolha o componente: Comunidade/Relay. Se você preferir não criar uma conta, pode usar essas credenciais para reportar o bug anonimamente:

  • usuário: cypherpunks
  • senha: writecode

== Tradução deste guia ==

Tradução organizada por [| cebolas]: André Almeida, serfron, zscaiosi e gus.

Versão do documento acessada e traduzida em 20180616.

Comments

    Please register or sign in to add a comment.