WTF???

Outro teste:

OK, já passou da hora usar OpenDNS!

Servidor/Cliente FTP usando raw socket.

Acho que este é o que será mais útil, principalmente aos meus colegas de Universidade.
Trabalho de redes1, a missão era implementar um cliente/servidor FTP baseado no Kermit utilizando raw sockets. Algumas pessoas fizeram utilizando UDP, mas ae fica sem graça né?! =)

Para controle de fluxo, foi implementado o pára-e-espera. Toda mensagem deve retornar um ack/nack. Obviamente, não há TCP nem IP, a “conexão” é feita sem endereçamento pelo cabo de rede. Os cabos devem ser ponto-a-ponto (até pode ser utilizado um hub, mas provavelmente ele mate todos os pacotes por serem inválidos).

Para detectar erros utilizo paridade-par (sux), e caso o cabo de rede seja removido e colocado depois de pouco tempo, o sistema deve continuar de onde parou. O arquivo final precisa ser consistente. Isto é muito complicado usando apenas paridade par, logo nas mensagens de fim de arquivo envio como dado o MD5, para garantir consistência.

O tamanho de cada arquivo nos pacotes está incorreto. Esta informação está sendo ignorada.

O resto está descrito no arquivo: Mensagens de atá 255 bytes, etc etc.

Como estava aprendendo GTK+ na época, fiz umas modificações para incluir uma interface gráfica. Ficou meio estranho pois incluí isto depois que o trabalho já estava pronto. De qualquer forma, para compilar esta versão, utilize o comando “make gui”

No Unix, o pacote deve ser puxado com o comando:

svn co http://danilocesar.com/svn/redes1

Outro dia publico outros códigos.
[]‘ s

Danilo Cesar

if (file_exists(realpath($_GET['teste'] . ".php"))){
echo 'OK';
}
else{
echo 'Fail';
}


Aparentemente esta verificação é bastante segura né?

Infelizmente não. O PHP usa o padrão de strings usado em C (aquelas terminadas com ‘\0′), o que gera um problema bastante conhecido chamado de Null Byte issue [1].

O que acontece se seu $_GET['teste'], aparentemente seguro, tiver um ‘\0′?
Sua função realpath vai verificar apenas o $_GET['teste'] e nem vai saber que existe um “.php”

Faça o teste:

http://localhost/labs/teste.php?teste=/etc/passwd%00

(%00 é o código hexadecimal aceito pelos browsers para o \0)

E o resultado:

OK

[1] http://en.wikipedia.org/wiki/Null_character

Depois de procurar um pouco, achei um artigo que poderia me ajudar a fazer um túnel SSH afim de proteger meus dados em pontos de acesso wireless públicos.

Mas eu queria mais; Não queria ficar pondo e removendo proxy de todas as aplicações só porque mudei de rede. Queria deixar isto transparente.

Depois de perder algumas horas com regras IPTABLES descobri o Tsocks, ou Transparent Socks para os íntimos.

Instalação

No Ubuntu/Debian como sempre é muito fácil:
apt-get install tsocks

_{Falar de instalação já não tem mais graça….}

Configuração

Basicamente é necessário editar o arquivo /etc/tsocks.conf. Particularmente, eu limpei este arquivo e coloquei apenas as seguintes linhas:

local = 192.168.0.0/255.255.255.0
path {
reaches = 0.0.0.0/0.0.0.0
server = 127.0.0.1
server_type = 4
server_port = 5151
}

Calma calma, vou explicar:

Local: é o endereço e a máscara de subrede da rede local. Afina, quando você digitar 192.168.X.X você geralmente deseja acessar a rede interna, correto? Algumas pessoas podem querer utilizar 10.0.0.0/255.0.0.0.

Fora isto, eu quero que TODA a conexão feita para QUALQUER outro endereço, seja encaminhada para o meu Túnel. Para isto, criei um path .

reaches: Da mesma forma que Local, indica o IP da rede para qual eu quero acessar. 0.0.0.0/0.0.0.0 significa aqui toda e qualquer rede (exceto a definida em Local).

server : Indica o endereço IP do servidor Socks. No caso estará em minha máquina local.

server_type: Indica a versão do servidor Socks.

server_port: Indica a porta onde o servidor estará rodando. No meu caso, será a porta 5151.

E agora Rapá?

E agora precisamos rodar o nosso túnel. O meu fica da seguinte forma:

ssh -C -D 5151 MEU_LOGIN@talisker.c3sl.ufpr.br cat -


E depois iniciar o tsocks com o comando:

tsocks -on

Agora, para rodar o Firefox ou Pidgin utilizando o tsocks, basta dar o seguinte comando:

tsocks firefox
tsocks gaim


E está aí, pronto para usar e sem configurações adicionais!

Qualquer dúvida, estamos aí!

[]‘s

Danilo Cesar

Update: Desafio para férias: Fazer um port do Tsocks para Maemo para usar encriptação nas redes do C3sl.

Hoje venho escrever sobre uma idéia que tive para solucionar um certo problema.

A algum tempo atrás necessitei trocar um site de um servidor para o outro, mas como este site servia algumas aplicações críticas (é, talvez nem tão críticas), o mesmo não poderia sair em nenhum momento do ar. Ou seja, deveria estar rodando perfeitamente tanto em um host quanto em outro.

Mas, como testar um sistema em um novo servidor? Substituindo as informações de DNS. Mas, no melhor dos casos demora uma hora. E se der errado? Substitui de volta? São pelo menos 3 horas de um sistema off-line. Acho que não é uma solução interessante para aplicações críticas né?

Solução inteligente.

Adicionar nova entrada no /etc/hosts. Simples assim.
Desta forma, você poderá testar sua aplicação no seu novo servidor, e todos os seus clientes continuarão acessando no antigo! Assim, quando você tiver certeza de que tudo está funcionando, você substitui oficialmente o DNS no seu registro de domínios. Legal né?

Passo a Passo

1) Primeiro pegue as informações de DNS de seu novo host.
Um exemplo seria o dreamhost: ns1.dreamhost.com

2) Com o comando ping, descubra qual o IP do servidor DNS

$ ping ns1.dreamhost.com
PING ns1.dreamhost.com (66.33.206.206) 56(84) bytes of data.
64 bytes from ns1.dreamhost.com (66.33.206.206): icmp_seq=1 ttl=44 time=233 ms

rtt min/avg/max/mdev = 233.172/233.172/233.172/0.000 ms

O Ip do servidor aqui é: 66.33.206.206

3) Abra o arquivo /etc/hosts (como root é claro), e adicione a linha

66.33.206.206 seu_site.com.br www.seu_site.com.br


4) Agora, no seu browser acesse o seu_site.com.br, e perceba que você estará acessando no novo servidor, e não mais no oficial.
Agora você pode testar a sua aplicação online, corretamente, sem colocar em risco a continuidade do seu serviço oficial. =)

Qualquer dúvida estamos ae!

Acho que esta solução não funciona para quem usa servidores proxy’s

[]‘s
Danilo Cesar

Hoje deixei o aiBur Framework de lado para fazer algumas coisas divertidas… =)

Um antigo camarada de programação ASP que está fazendo algumas brincadeiras com linux e SQUID me perguntou esses dias como ele poderia fazer um POST via linha de comando… Eu que não sabia exatamente o que ele queria indiquei:


echo "nome=danilo&idade=20" | lynx --post-data http://www.meusite.com.br/meu_post.php

Como muitos devem saber, este comando funciona perfeitamente para enviar POSTs via linha de comando. Mas meu amigo precisava de algo mais “bruto”. Ele precisava fazer, por exemplo, POST de um arquivo… Lá vai o Danilo arranjar uma solução…

Aqui vou conciliar uma dica que escrevi a muito tempo atrás para o vivaolinux, e a idéia sobre Headers HTTP que vi no BrunoTorres.net.

Ferramentas que vamos utilizar:

TCPUTILs -> Tcputils é um pacote que contém um conjunto de ferramentas para utilizar sockets diretamente pelo Shell… Na verdade é um servidor e cliente de echo… Quase como um telnet. Mas dá pra fazer algumas coisas bacanas com ele, que nós veremos agora…. =)

HTTP -> Hypertext Transfer Protocol ou Protocolo de transferência de hipertexto: é o formato da comunicação entre o Browser e o servidor. Por exemplo, é o cliente que envia cookies, o servidor que grava sessions, redireciona, etc etc etc… Seu padrão é definido pela W3C

LivehttpHeaders Extension: Extenção do Firefox que visualiza todos os headers de uma requisição http.

Bom, vamos brincar um pouco:

Precisamos primeiramente instalar o pacote TCPutil. Como eu uso Debian, é fácil:

apt-get install tcputil


Depois de instalado, virá uma lista de comandos. Iremos usar apenas o tcpconnect. Outros podem ser visto na documentação (man tcpconnect) ou no meu artigo citado acima…

A descrição do comando é a seguinte:
tcpconnect [HOST] [porta]

Após a conexão estabilizada, o cliente (no caso, você) poderá enviar suas strings de conexão. No caso, poderá mandar cabeçalhos HTTP para o servidor. Vamos fazer um teste?

tcpconnect danilocesar.com 80

Após a conexão com o servidor, você enviará os seguintes Headers do HTTP:

GET /blog/index.php HTTP/1.1
Host: www.danilocesar.com

Este é, talvez, o cabeçalho mais simples que uma requisição HTTP pode ter. Vamos entende-la:

GET -> É o método de envio de dados
/blog/index.php -> É a página que eu estou querendo
HTTP/1.2 -> É a versão do protocolo HTTP que estou usando
Host: -> É o Host que você está buscando.

E como respostas você vai ter os Headers vindos do Servidor e o código HTML específico da página.

Agora, nem todos os Headers que estaremos enviando possuem apenas 2 linhas. Para facilitar a nossa vida, colocaremos o cabeçalho HTTP agora em um arquivo texto e iremos enviar os headers assim:

tcpconnect danilocesar.com 80 < headers.txt

Creio que vá facilitar a nossa vida... Bom, vamos continuar.

_{Meus testes agora vão ser feitos no meu localhost… Por poder editar melhor os arquivos e tals….}

Creio que está na hora de enviar-mos alguns Headers mais “Pró”

Se você está com preguiça de ler a documentação do HTTP, podemos visualizar os Headers que o firefox envia utilizando a extenção LiveHTTPHeaders.

Vamos fazer um teste…. Com a extensão devidamente instalada, aperte ALT + L, e acesse uma página qualquer. Por exemplo, http://www.google.com.br

Os Headers que enviamos

GET / HTTP/1.1
Host: www.google.com.br
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060209 Debian/1.5.dfsg+1.5.0.1-2 Firefox/1.5.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: pt-br
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: KIDYMD=#243194:FBOB#

Cuidado: As propriedades dos headers devem ocupar apenas uma linha cada uma. Toda quebra de linha a mais é feita pelo browser e deve ser discartada

Os Headers que recebemos

HTTP/1.x 200 OK
Cache-Control: private
Content-Type: text/html
Content-Encoding: gzip
Server: GWS/2.1
Content-Length: 1556
Date: Sun, 19 Feb 2006 16:25:35 GMT


Se você enviar estes mesmos headers no pelo tcpconnect, talvez você receba apenas algumas Strings estranhas, pois a informação vem toda compactada do Servidor pelo gzip. Para ver as informações inteiras, retire a linha “Accept-Encoding: gzip,deflate ” do seu header.

Agora, dentro do seu LiveHTTPHeaders, dê um Clean, volte ao google e busque por HTTP:
Temos agora 2 diferenças nos Headers.

GET /search?hl=pt-BR&q=HTTP+Headers&btnG=Pesquisa+Google&meta= HTTP/1.1

Referer: http://www.google.com.br/


O get agora está bem mais incrementado certo? Ele contém as Strings de busca do google.
Um novo Header foi enviado pelo browser: Referer. Ele indica o caminho completo da página de onde você veio. Isto é muito utilizado para quebrar spammers de blog (método bem inseguro, mas quebra boa parte dos spammers), para estatisticas (quais sites possuem links para o seu).

E os prometidos arquivos?

Vamos agora aprender a enviar arquivos. Na verdade, não muda muita coisa.


POST /obj/teste.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060209 Debian/1.5.dfsg+1.5.0.1-2 Firefox/1.5.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: pt-br
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost/obj/teste.php
Content-Type: multipart/form-data; boundary=--BoRdEr_Signature-00253658974569--
Content-Length: 700

No caso, estou mandando o meu arquivo Source.list Vamos às descrições:
Content-Type: multipart/form-data; – Indica o tipo do conteúdo
boundary=–BoRdEr_Signature-00253658974569– Indica o separador de conteúdo.
Content-Length: 700 – Tamanho do seu arquivo.
A parte de dentro seria o seu arquivo propriamente dito…
Content-Type: text/plain – Tipo do conteúdo. No caso, texto plano, mas poderia ser uma imagem, um executável, etc et.

Da mesma forma, o código acima funciona com imagens, mas não mostro aqui com imagens pois seria inútil, pois provavelmente viria encriptada…

Bom, e termina aqui a descrição do problema e da solução.
Caso tenha problemas, ou sugestõe, comente abaixo.

[]s!

_{O tcpconnect tem um número máximo de caracteres de resposta. Isso pode dar algum problema com Headers muito grandes}