protected * void

Agora pouco digitei um endereço errado e tive acesso à uma infeliz página:

WTF???

Outro teste:

OK, já passou da hora usar OpenDNS!

Estou prestes a me formar, e lembrando-me de um convite do Arthur Furlan, decidi que estava na hora de liberar alguns trabalinhos legais que escrevi na faculdade.

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

Há muito tempo que eu queria saber um pouco mais sobre os tais túneis SSH.

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.

Olá pessoas,

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

Olá pessoal…

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.

(more…)