Sistema seguro de mensagens para Tor

Mais uma ferramenta útil disponível para rede Tor, o SMS4TOR. SMS4TOR é um sistema automatizado para encriptar mensagens que são destruídas logo após a sua picture29leitura. Depois que a mensagem é submetida ao sistema, ela é armazenada em um banco de dados, o usuário recebe uma URL que torna possível a recuperação da mensagem. Depois de lida, a mensagem é removida do banco de dados e não poderá mais ser recuperada. Mensagens com mais de 30 dias em estado de espera, também são eliminadas.

Os desenvolvedores da ferramentas tomaram algumas precauções para garantir a segurança e confiabilidade do sistema. As mensagens são criptografadas com o Bcrypt (Blowfish encryption – http://bcrypt.sourceforge.net/). Bcrypt é um utilitário de criptografia de arquivos e estes mesmos arquivos são portáveis para todos os sistemas operacionais e processadores. O serviço SMS4TOR está hospedado em um data center e com hardware dedicado. Nada de: “Em algum lugar na nuvem com backups dos dados em uma base regular”.

Trecho retirado do F.A.Q do SMS4TOR:

“If you’re curious, here’s what the phrase, “Hello World” looks like in our database:”
fUTAyJACtd9X4c9OEjftHfp01VgDKKjMJgB2Hgnsikk=$2a$08$FgkFXNvaqMu.fCHusoDsJu2H9Z7meUfwjtT1aRtG1T/Kw.bNUaEEm

Mas a motivação principal dos desenvolvedores foi a criação de um processo mais simples que os existentes para troca segura de mensagens em uma rede TOR.

picture30

http://sms4tor3vcr2geip.onion/ – Lembrando, este endereço só pode ser acessado via rede Tor.

E como podemos fazer um bom uso do serviço ? A primeira coisa que me veio a cabeça foi o compartilhamento de senhas. Administradores, sistemas, serviços e aplicações, podem fazer uso de troca de mensagens seguras, um exemplo seria o uso de credenciais por demanda. Vamos supor que uma empresa ou orgão tem um gateway Gnu Linux remoto e sempre que uma manutenção local é necessária, é fornecida ao operador da localidade a senha de um usuário, vamos dar como exemplo o user suporte. Suporte é um usuário devidamente personalizado para sempre que ele efetuar um logon, o password seja expirado, gerando a inatividade momentânea e controlada do usuário. Geralmente, sistemas do tipo geram um password automaticamente e o compartilha para um destino, neste caminho abrem-se falhas relevantes ao transporte da senha temporária. Se o sistema gerador de senha temporária tiver condições de usar a rede Tor, submeter a mensagem no site do SMS4TOR, capturar a URL de recuperação de mensagem e compartilhar, pode ser por e-mail ou qualquer outro serviço oculto, teremos um aumento na segurança do processo. Se o operador remoto me informa que ao acessar a URL não conseguiu recuperar a mensagem, alguém capturou.

Este é apenas um exemplo das vantagens oferecidas para serviços do segmento. Pessoas só imaginam o uso da rede Tor para fins errôneos, mas a exploração dos benéficos desta arquitetura por pesquisadores autônomos  ou não, tem ajudado a quebrar este preconceito.

Configurando serviço SSH oculto

Dando continuidade ao tema hidden services, Configurando serviço de http oculto para Tor usando Apache Web Server, daremos prosseguimento com o processo de ocultação de serviço, mas a bola da vez será o SSHD. SSHD ou OpenSSH Daemon, é o daemon para o programa ssh. Entretanto, outros programas como rlogin e rsh substituem o programa cliente e fornecem uma comunicação segura entre dois hosts confiáveis sobre uma rede insegura.

Primeiro iremos editar o arquivo torrc e adicionar a configuração necessária para o daemon sshd. Importante a leitura do primeiro artigo para o endentimentos dos parametros HiddenServiceDir e HiddenServicePort. Em seguida, precisaremos reiniciar/inicar o serviço Tor e obtermos o nosso hostname.

Nota mental: Como o nome é gerado a partir do par de chaves disponibilizado para o serviço oculto, é claro que cada HiddenService terá sua URL particular.

HiddenServiceDir ./tmp/ssh

HiddenServicePort 22 127.0.0.1:22

Qual o hostname ?

ncaio@notebook:~/tor-browser$ cat tmp/ssh/hostname
26qfpx2ahq7trree.onion

Assim o nosso sshd pode ser executado sem alterações extras no arquivo /etc/ssh/sshd.conf. Tome as precauções necessárias para ter um nível aceitável de segurança no sshd, mude a porta se achar prudente e deixe o serviço ouvindo apenas em localhost. Apenas lembre de replicar as mudanças de portas no torrc.

A configuração do lado servidor é tranquila. Já a do lado cliente, se faz necessário o uso de um middleware. Um programa escrito na linguagem de programação C por Shun-ichi GOTO, em junho de 2000, é o responsável no lado cliente de estabelecer conexões usando SOCKS 4/5 e HTTP como túnel. Isso é tudo que precisamos para conectarmos de forma anônima e resolver o endereço .onion via rede Tor.

–> Connect.c <–

Compilando e dando permissão de execução:

$ gcc connect.c -o connect

# chmod +x connect

Testando o connect:

Conectados na rede Tor iremos fazer um teste simples, utilizar o connect para de forma anônima criar uma conexão com um destino qualquer na porta 80, protocolo TCP.

bash-4.2# ./connect -S localhost:49864 http://www.google.com 80

Onde:

-S <– Conexão do tipo SOCKS – Por padrão a versão 5 é utilizada.

localhost:49864 <– Endereço do cliente Tor e sua porta SOCKS – Vide a imagem 1.

http://www.google.com <– Endereço destino.

80 <– Porta destino.

Você deverá ter um resposta do tipo:

bash-4.2# ./connect -S localhost:49864 http://www.google.com 80

GET / HTTP/1.1 <– você precisa digitar

HTTP/1.1 302 FoundLocation: http://www.google.ru/Cache-Control: privateContent-Type: text/html; charset=UTF-8

picture28

Imagem 1 – Uma forma de pegar as configurações Tor é consultando as propriedades do seu navegador seguro.

Configurando o cliente ssh:

No nosso caso, usaremos o usuário ncaio como exemplo. Perceba que teremos que fazer o seguinte dentro do home do usuário, editar ou criar o arquivo config (~/.ssh/config) e adicionando 2 parâmetros:

HOST      26qfpx2ahq7trree.onion

ProxyCommand  /tmp/connect -S localhost:49864 %h %p

Onde HOST é o endereço destino na rede Tor e ProxyCommand passamos o programa connect e suas opções de uso.

Testando o cliente SSH:

ncaio@notebook:~$ ssh 26qfpx2ahq7trree.onion

Se tudo ocorrer bem, você receberá a mensagem de fingerprint.

Assim como no post anterior, segue o material complementar em vídeo.

Configurando serviço de http oculto para Tor usando Apache Web Server

INTRODUÇÃO

The onion router permite que clientes e repetidores ofereçam serviços ocultos. O anonimato do endereçamento IP é o objetivo principal, já que o mesmo não pode ser revelado a origem. Este fato agrega valores de segurança da informação, tal como ao desenvolver um ataque de negação de serviço, a rede invasora não terá um destino estático, além de desconhecê-lo. Podemos também citar como exemplo uma empresa que pretende esconder segredos comerciais e precisa de um canal seguro de comunicação entre seus fornecedores, cliente e investidores. Mas se não revelo meu endereço IP, como o serviço oculto é acessado? Simples. Os serviços ocultos são acessados através do pseudo domínio: .onion TLD. O .onion é um hash de 16 caracteres (alpha-semi-numeric) que é gerado automaticamente baseado em uma chave pública quando um novo serviço oculto é configurado.  Esta técnica é também conhecida como Tor rendezvous points.

Podemos fazer uma pequena observação: é claro que os serviços ocultos manterão as suas falhas “naturais”. A versão do Word Press 3.4 tem uma falha de segurança que permite ataques XSS e o fato da aplicação rodar de forma oculta, não deixará imune a falha.

Iremos simular neste documento a ocultação do serviço http provido pelo Apache Web Server. Não iremos tratar da instalação do Tor e nem outro serviço, tal como o próprio Apache Web server. Todos os exemplos foram realizados em um notebook com a distribuição Gnu Linux Slackware 13.37- x86_64. Mas acredito que este documento seja facilmente adaptado para outras distribuições. E recomendo a leitura da introdução a invisible web.

Configurando o Tor

Existem 2 formas de configuração, gráfica via Vidalia e edição direta do arquivo de configuração torrc. Vamos adotar neste procedimento o segundo formato. Primeiro localize o seu arquivo torrc, geralmente encontrado no /etc/tor ou /path/tor-browser_xx-xx. O comando find e o locate são de grande ajuda neste momento.

Para o nosso caso teremos 2 parâmetros, uma linha HiddenServiceDir e uma ou mais linhas HiddenServicePort.

HiddenServiceDir: É o diretório onde o Tor irá armazenar informações sobre o serviço oculto. Um arquivo de nome hostname, contendo a URL .onion e um conjunto de chaves pública e privada para seu serviço oculto. O arquivo é o private_key. Claro, não compartilhe este arquivo com ninguém, caso queira manter seu serviço oculto.

HiddenServicePort: Determina uma porta virtual seguido de endereço IP e porta onde as conexões serão direcionadas quando o destino for a porta virtual.

Então adicionaremos as seguintes linhas ao arquivo:

HiddenServiceDir ./tmp/www
HiddenServicePort 80 127.0.0.1:80

Caminho de armazenamento e configuração das portas. Neste momento se faz necessário o reinicio do Tor, se tudo ocorrer bem, você terá o diretório www criado no caminho informado no HiddenServiceDir. Nele você encontrará os arquivos hostname e private_key, assim como ilustra imagem 1. Com isto já temos em mãos o endereço .onion do nosso serviço oculto, essencial para o nosso próximo passo.

$ cat hostname
m5lizi7a7nm3kjqf.onion

picture26

Imagem 1 – Arquivos criados após a configuração e reinicio do Tor.

Configurando o Apache Web Server

Aqui basicamente iremos criar um virtual host para o nosso endereço oculto. Segue o exemplo da configuração do ServerName m5lizi7a7nm3kjqf.onion. Onde o DocumentRoot é onde se encontra o meu blog ou o site da minha empresa.

<VirtualHost 127.0.0.1:80>
ServerName  m5lizi7a7nm3kjqf.onion
DocumentRoot /tmp/Tor/
<Directory />
AllowOverride none
Require all granted
</Directory>
</VirtualHost>

Com o virtual host configurado, é preciso iniciar ou reiniciar o servidor web. Para testar se o serviço está oculto iremos passar a URL encontrada no arquivo hostname para um navegador que esteja utilizando a rede Tor. O resultado deverá ser o conteúdo do DocumentRoot informado, assim como na imagem 2.

picture27

Imagem 2 – http://m5lizi7a7nm3kjqf.onion/

Para concluir, segue um vídeo exemplo dos procedimentos aqui mencionados.

Nos raros vagos momentos [- Satanic GNU -]

Satanic GNU é uma banda de rock, nerd gore, satanista, formada por apenas 1 humano e tem como tema principal tudo que é mais tosco e sem graça para boa parte da população terrestre. Formada em 2008 como uma terapia contra alguns problemas psicossomáticos que atingem o seu fundador, a banda faz parte de um desorganizado, mas bem articulado projeto paralelo a vida real.
Fazendo parte da gravadora Chorume Record, que tem como especialidade gravações em um único canal, a banda, em conjunto com outras grandes bandas como o Dr. Fossa e The First Moment of Decomposition, gravou o seu primeiro debut “make && make install”engressando assim na problemática família Chorume record.
A sua primeira obra prima foi kernel 2.2 que de acordo com a crítica especializada foi uma porcaria. Já no submundo da música foi declarado: “A música kernel 2.2 é tão boa com um ventilador na velocidade 3”. O debut foi totalmente gravado e editado (se é que isso pode ser dito) com o uso de software livre.

Audacity, Jack audio connection kit, hydrogen.

Lista de músicas:

for i in *; do echo $i;done
01-A_KGB_LEU_MEU_LOG.mp3
01-Kernel2.2.mp3
demonic-printer.mp3
howard_o_pato_robou_meu_pense_bem.mp3
ibm_e_o_holocausto.mp3
rm-rf.mp3

http://www.4shared.com/file/RJeBAm_a/satanicgnutar.html


Creative Commons License
Stanic Gnu by Band is licensed under a Creative Commons Attribution 3.0 Unported License.
Based on a work at ncaio.ithub.com.br.

Benchmarks de leitura II

Um detalhe crucial que acabei deixando passar, foi a configuração da máquina realizadora dos testes.

Processador: Pentium(R) Dual-Core  CPU      E5200  @ 2.50GHz

Memória RAM: 2 GB

HD I: SAMSUNG SP0812C 80GB SATA Hard Drive (Serial ATA, 7,200 RPM, 8MB) pic

HD II: Western Digital 80 GB SATA (Detalhes…)

A segunda parte do teste, é uma continuação do realizado anteriormente. O mesmo procedimento. A mudança foi o uso da tecnologia RAID nível 0 e nível 1 (mais detalhes em RAID.edu). O procedimento de criação das partições, formatação, criação do arquivo e teste de leitura, foi o mesmo.

Teste número 3, RAID nível 0:

“Quem vai ler um arquivo de forma incremental (inicio até o fim) de 4.8GB mais rápido ?”

Detalhes:

  • Realmente, RAID nível 0 é o poder !? Aumento considerável de performance de leitura.
  • O minreadperf do EXT2 teve um ganho maior que os demais da família EXT.
  • O ReiseFS teve queda no minreadperf.
  • E o XFS ? Bem, manteve a melhor de todas as médias de leitura.

Continua no próximo post …

Benchmarks de leitura

Existem vários benchmarks de sistemas de arquivos espalhados pela net, uns realizados a muito tempo. Na maioria dos casos, temos testes realizados sobre a árvore de diretório do sistema operacional. Testes como, criar 10000 arquivos(touch), consultar por arquivos (find), criação de diretórios(mkdir), descompactar e desempacotar fontes do kernel (gzip/tar), entre outros. Na maioria das vezes temos um ou mais discos rígidos separados, afim de desvincular os nossos dados e aplicações, que na maioria das vezes sai do padrão de diretórios Unix (POSIX). Exemplo, separar um diretório chamado DB que fica na raiz (/DB). Nele ficarão meus arquivos de banco do SGDB Mysql, diferente do padrão /var/lib/mysql, por exemplo. Nota mental: “Sim, sempre que possível devo separar o meu /var em uma partição de preferência expansível (LVM)”. Mas no meu caso,  quero tudo separado do padrão. Os teste realizados foram realizados diretamente no(s) disco(s) que não contém o OS.

A metodologia utilizada para disco com ou sem RAID, foi a mesma. Preparar partição (cfdisk, fdisk), formatar (mkfs), mountar (mount), criar arquivo (dd), realizar teste de leitura do arquivo criado . Basicamente, apenas isso, acrescenta alguns detalhes de configuração nos testes com RAID. O intuito inicial não é fazer teste de estresse, é pegar o sistema de arquivo no teu estado inicial, fresquinho e sem buffer, para realizar os testes. Claro, não deixarei este tipo de teste fora do contexto, eles virão mais na frente. O arquivo de teste tem 4.8GB de tamanho e sempre criado com o seguinte comando e opções:

dd if=/dev/zero of=arquivo bs=1k count=4700000

A forma de formatação foi a mais padrão possível, apenas mkfs.<sistema de arquivo> /dev/disco.partição. Nada de especificar tamanho de blocos.

Os teste de I/O foram feito pelo VDT (Disk Visual Test), vdt -r arquivo –read –incr , ele me forneceu tudo que eu tinha em mente, antes de realizar os teste. Que era: “Ler um arquivo N a partir  do inicio, do fim, randomicamente e convergente”. Lembrando, o tópico diz “Benchmarks de leitura”. E outro grande detalhe, é: “Realizei os testes para não ficar apenas no “eu li isso em uma página de internet”. Não estou aqui julgando nada e ninguém.

Teste número 1:

“Quem vai ler um arquivo de forma incremental (inicio até o fim) de 4.8GB mais rápido ?”

Concorrentes: Ext2, Ext3, Ext4, ReiseFS, XFS.

Onde:

minreadperf = Performance mínima de leitura

avgreadperf = Performance média da leitura

maxreadperf = Performance máxima de leitura

elapsed = Tempo de duração

Teste número 2:

“Quem vai ler o mesmo arquivo de forma aleatória mais rápido ?”

Concorrentes: Ext2, Ext3, Ext4, ReiseFS, XFS.

Não temos como ter uma conclusão definitiva, mas já temos as primeiras características.

  • No requisito leitura incremental, a família Ext(2,3,4) se comportou praticamente igual. Diferença na leitura mínima, o EXT2 foi o menor de todos.
  • No requisito leitura aleatória, O EXT2 mostrou ser mais rápido. Ext3 teve o maior pico na leitura.
  • O XFS se comportou bem melhor que a família EXT nos testes.
  • O ReiseFS mostrou o melhor desempenho, sempre com boas médias.
  • Nota mental I: “1 segundo faz total diferença”.
  • Nota mental II: “Este foi o resultado de apenas uma operação por disco, imagine várias ? Nota mental I entra em ação.”

Continua no próximo post …