slowloris: um novo ataque DoS para servidores Web

Posted in seguranca, sysadmin with tags , , , , , , , , , , on 30-06-2009 by sirboderafael

depois de muito tempo sem postar… lah vai:

ha pouco tempo, surgiu um novo tipo de ataque DoS (Denial of Service), que afeta varios servidores Web utilizados amplamente no mercado… ele se destaca dos demais, pelo fato de voce nao precisar dispor de uma rede com inumeros computadores zumbis para parar o serviço http, por exemplo… com esse script, escrito em pearl, eh possivel degradar um servidor Web com apenas uma maquina, sem utilizar muita banda… eh realmente sinistro…

ele funciona enviando, atraves de um processo multi-thread, varias requisiçoes parciais ao servidor Web alvo, que na verdade, nunca sao completadas… servidores como o apache, mantem por um determinado tempo as conexoes tcp, entao o que acontece eh o seguinte: ele manda inumeras dessas requisiçoes maliciosas, nao as completando, espera um pouco mais e vai mandando mais varias levas de novas requisiçoes dessas… e por ai vai, esse processo fica se repetindo ateh que voce peça para ele parar… e o resultado? voce acaba atingindo o numero maximo de requisiçoes que o servidor Web suporta e a performance se torna altamente degradada, pois voce segura grande parte dessas conexoes consigo mesmo (pra nao dizer todas)… os demais visitantes vao ficar esperando, esperando, esperando e nada! pronto… voce acaba de ferrar com um servidor Web usando somente uma maquina e usando pouca banda… nao eh maravilhoso? (brincadeira pessoal…)

quando voce para o processo, depois de um tempinho o servidor Web volta a responder normalmente, pois ele manda pro espaço as conexoes que ficaram pra tras… mas isso acontece somente se voce enjoar de manter o servidor “fora do ar”… ele nao fica exatamente fora do ar, o que acontece eh que ele nao consegue por “time-sharing” encontrar meios de responder a todas as requisiçoes… geralmente uma ou outra requisiçoes externas, durante o ataque, sao sempre respondidas corretamente, mesmo que isso demore muito mais que o normal…

esse ataque degrada somente o servidor Web, diferente de muitos outros ataques DoS, que fazem com que a maioria (ou todos) os serviços parem de responder… tanto que se voce parar o processo de envio dos pacotes, o servidor volta a responder as requisiçoes… =D

o fato dele nao enviar uma requisiçao completa, e sim parcial, faz com que essas requisiçoes nao sejam registradas imediatamente nos logs… ou seja, voce pode estar “mandando ver” em um servidor ha alguns minutos e isso nao ser registrado em lugar algum… caracteristicazinha do mal essa, que ao meu ver, dificulta a vida dos administradores… quando o ataque para, dae sim sao registradas gazilhoes de requisicoes falhadas (status 400) nos logs… pode ser que nas futuras versoes do script se implementem uma maneira de completar as requisiçoes, quando o ataque parar, assim serao registrados codigos de status 200, ou seja, de sucesso (o que eh absolutamente normal, dependendo do servidor… hehehehe)… quem quiser, pode dar uma olhada nas lista de codigos de status http

quer testar a bagaça? (assuma seus riscos, recomendo testar em um servidor que seja seu…)

1) certifique-se que voce possui os seguintes modulos pearl instalados em sua maquina: IO::Socket::INET e IO::Socket::SSL, caso nao os tenha instalado, rode o seguinte (com privilegios apropriados, eh claro…)

root@bodacious:~ perl -MCPAN -e 'install IO::Socket::INET'
root@bodacious:~ perl -MCPAN -e 'install IO::Socket::SSL'

2) mande bala no seu alvo (um usuario nao-privilegiado convencional, roda isso numa boa):

bode@bodacious:~$ ./slowloris.pl -dns http://www.oenderecodoservidorquequeiraatacar.com

bom, dae voce pode entrar em seu navegador e pedir pra ele carregar alguma pagina do servidor alvo… se ele estiver na lista negra dos servidores afetados, com certeza o slowloris vai dar conta de degradar o serviço… recomendo a todos que leiam o link anterior, pois ele contem informaçoes extremamente relevantes e com certeza se mantera mais atualizado, ao longo do tempo, com relacao a este post… alem do que, foi a primeira referencia que tive contato para saber da existencia desse ataque…😉

vi hoje que teve mais gente do brasil comentando sobre esse ataque… lah fora teve mais caras comentando, como em darknet.org.uk, wooga.drbacchus.com, hackaday.com e ha.ckers.org (que volto a frisar, recomendo a leitura, tem mais posts sobre o ataque)… teve inclusive um cara que re-implementou esse ataque em python e afirma oferecer mais controle sobre ele, o que pode tornar-lo ainda mais venenoso que o original…

nessa thread, o autor da mensagem afirma ter escrito um patch, denominado como ‘prova de conceito’ e que eh capaz de minimizar o efeito do ataque…

ja nessa thread, fala-se sobre o antiloris, que eh um shell-script feito pra rodar a cada minuto no servidor (tah, nao eh uma soluçao muito elegante, mas foi uma maneira que encontraram de se resolver o problema) como cron-job… o duro eh ter que ficar reiniciando o apache… analisando o script, se ve facilmente que ele identifica o IP do atacante (caso ele atinja um numero superior ao permitido de conexoes) e manda uma regra de iptables que começa a droppar todos os pacotes que vierem desse cara… bom, acompanhe a thread que voce ira tirar suas proprias conclusoes…

particularmente nao testei essas soluçoes, mas acredito que pelo menos para o apache, tudo se resolva tranquilamente limitando-se o numero de requisiçoes por endereço de IP, atraves do modulo mod_limitipconn… eis os links para apache 1.x e para apache 2.x

se puder vou postar, em breve, alguma coisa sobre essas diferentes soluçoes… se alguem souber alguma maneira melhor de se evitar esse tipo de DoS, as sugestoes com certeza serao bem apreciadas…

[]’s!
t++!

uma aplicaçao cliente/servidor com monitoramento web para gps

Posted in aleatorios, hardware, projetos, utilitarios with tags , , , , , , , , , , on 01-03-2009 by sirboderafael

ja faz algum tempo que retomei o contato com o meu amigo Mateus Mendes, que atualmente esta desenvolvendo um projeto de monitoramento utilizando o sistema global de posicionamento, famoso GPS

fui convidado para participar do projeto para facilitar as coisas, computacionalmente falando… e tambem por ja ter fritado bastante em projetos passados, quando ainda moravamos em STZ, interior de SP…

as metas iniciais do projeto foram:

  • pegar as informaçoes do modulo GPS
  • comunicar o modulo GPS com o modulo GPRS
  • transmitir e capturar dados via internet atraves dos dois modulos conectados
  • capturar as informaçoes enviadas atraves de um serviço instalado em uma maquina, utilizando o protocolo UDP
  • gravar os dados recebidos em algum local
  • exibir os 10 ultimos dados gravados, atualizados de 5 em 5 segundos em uma pagina da web

bom… eh ai que entra a historia do cliente/servidor que gostaria de compartilhar… utilizei varias fontes espalhadas pela web para conseguir as informaçoes necessarias… fiz algo bem simples, que eh somente um alfa para conseguirmos testar as coisas, sem pensar em segurança e em nada demais… conseguimos um esqueminha de comunicaçao bem simples e legal…

tudo foi escrito em C e isso nos traz o beneficio de ser algo realmente rapido… entao nao teremos a preocupaçao com gargalos assim tao cedo… hahahah! (jah to falando como se tivessemos milhoes de acessos! hehehe)

para os interessados, aqui estao os codigos fonte do servidor e do cliente

a ideia eh abrir uma porta (no caso foi a 25000) e utilizar o protocolo UDP para a comunicaçao… mas porque UDP? eh porque o modulo GPRS vai enviar os dados de 5 em 5 segundos aproximadamente… e pouco me importa saber se o dado chegou ou nao, assim como a ordem de trasmissao dos pacotes… entao, eh por isso que nao escolhemos TCP, que no caso seria como matar uma mosca com uma bazuca… (alem de consumir mais banda e consequentemente custar mais caro pra transmitir os dados, uma vez que atualmente, as operadoras de telecomunicaçoes cobram a mensalidade de acordo com o volume de dados transmitidos)

para compilar eh simples… basta fazer:

bode@bodacious:~/projetos/gps$ gcc -o server udpserver.c
bode@bodacious:~/projetos/gps$ gcc -o client udpclient.c

agora temos um cliente, que maravilhosamente se chama: client e um servidor, que milagrosamente se chama server… beleza na montanheza?

para botar seu servidor para rodar, utilize o comando:

bode@bodacious:~/projetos/gps$ ./server >> log 2>&1 &


obs-1.: isso significa que estamos redirecionando com este comando, a saida padrao e a saida de erros padrao para um arquivo de logs (atraves de uma concatenaçao com seu conteudo atual)… tambem estamos lançando o processo em background… se quiser saber mais sobre os redirecionamentos, aconselho voce a dar uma olhada em um post escrevi sobre isso

o monitoramento via web eh feito com uma pagina contendo um script php, que tambem esta disponivel para download


obs-2.: como voces podem observar, o esquema em geral eh beeeem simples… o monitor nao tem formataçao CSS nem atualizaçao AJAX… na verdade nao estamos nem ai pra isso (por enquanto)… o refresh eh feito com meta-tag mesmo…. enfim… acho que nao preciso explicar pra ninguem o sentido da palavra alfa…

olhando o codigo vemos que o log eh gravado no mesmo diretorio que o servidor reside e o script pega esse mesmo log, que esta no mesmo diretorio em que reside este tambem… entao chegamos a brilhante conclusao de que tudo foi jogado no mesmo diretorio que um virtual host tenha acesso… entao… “crianças, soh façam isso em casa se forem testar alguma coisa… do tipo experimento sem compromisso…”

se voce montou seu ambiente, que deve de alguma forma se parecer com o que descrevi, jah eh possivel acessar seu monitor PHP atraves de seu servidor web e ativar seu cliente UDP no console… quando digitar alguma coisa e pressionar enter, a informaçao ira viajar ateh o socket de seu servidor UDP, que esta escutando na porta 25000, uma informaçao sera gravada no log e como seu monitor PHP se atualiza mostrando os 10 ultimos dados recebidos a cada 5 segundos… logo logo, emocionantemente, sua informaçao estara pipocando em seu navegador…

soh pra constar… o hardware jah eh capaz de se comunicar com esse serviço que implementamos… o proximo passo que darei em minha vertente do projeto eh integrar as coordenadas capturadas com o google maps… dai a coisa vai começar a ficar mais interessante… mas… como dizem, isso vai ser suave na nave!

eis a previa do nosso prototipo fisico:
Free Image Hosting at www.ImageShack.us

assim que tiver mais novidades sobre o projeto postarei aqui… ok?

[]’s!
t++!

testando sua memoria ram com o memtest86

Posted in hardware, kernel, utilitarios with tags , , , , , , , , , , , , on 28-02-2009 by sirboderafael

para aqueles que desejam verificar se sua memoria ram esta funcionando corretamente, existe um utilitario chamado memtest86.

ele deve ser carregado na hora do boot, no lugar do sistema operacional… para aciona-lo pode-se utilizar disquete, cdrom, pendrive ou mesmo o gerenciador de boot (como o grub ou o lilo — que verificaremos mais adiante)…

os testes realizados, podem expor falhas de maquinas cujo comportamento se pareça normal, mas que vez ou outra mostram problemas, que aparentemente sao vindos do alem…

uma vez que os endereços defeituosos sao identificados, é mostrada uma saida formatada para um patch que se aplica no kernel do linux, chamado BADRAM, cujo intuito eh permitir o uso de pentes de memoria defeituosos, excluindo-se da faixa de endereços disponiveis aquelas porçoes identificadas como defeituosas… mas isto eh uma tarefa dedicada somente aos corajosos de plantao…

seu funcionamento se da atraves da escrita de inumeros padroes de dados em cada endereço de memoria… entao o dado escrito eh comparado com o dado esperado e assim ocorre a verificaçao de erro… eh um processo exaustivo, e como jah foi bem frisado, o intuito eh checar cada porçao da memoria e encontrar areas defeituosas… claro, o algoritmo nao eh simples assim, foi soh uma tentativa de dizer a voces: “olha, ele testa a parada pra caramba e se ele nao achar defeitos, provavelmente nenhuma outra ferramenta os achara…” quem quiser saber quais os algoritmos utilizados e as politicas de asserçao de erros, tudo esta bem documentado em uma seçao especial no site do projeto.

a titulo de curiosidade, mas soh para os fritoes de plantao… esses testes tambem podem revelar se sua memoria continua funcionando bem quando overclockada… hahaha! o memtest86 permite que voce mude a frequencia de trabalho de sua memoria… entao… nao perca tempo e prepare um omelete em cima de seu pente de memoria ram!

de boa na canoa? vamos logo para a parte da hora do negocio, que eh testar esse testador maluco! =)

baixe o codigo fonte:

bode@bodacious:~/pacotes$ wget http://www.memtest86.com/memtest86-3.5.tar.gz

extraia, entre no diretorio do pacote e compile, pois ele jah vem com o Makefile:

bode@bodacious:~/pacotes$ tar vxf memtest86-3.5
bode@bodacious:~/pacotes$ cd memtest86-3.5
bode@bodacious:~/pacotes/memtest86-3.5$ make

apos terminada a compilaçao (sem erros), iremos colocar nosso memtest86 como uma opçao de inicializaçao em nosso lilo… para isso, basta copiar o arquivo (imagem de boot) memtest.bin que foi gerado, para o diretorio /boot… arrume suas permissoes, por questoes esteticas — hahaha, essa foi boa heim galera! (soh root pode ler e escrever, os demais soh podem ler…) ok?:

root@bodacious:/home/bode/pacotes/memtest86-3.5# cp memtest.bin /boot
root@bodacious:/home/bode/pacotes/memtest86-3.5# chmod 644 /boot/memtest.bin

para que a bagaça seja efetivada, vamos colocar as devidas linhas, responsaveis pela opçao de inicializaçao do memtest86, no final do arquivo /etc/lilo.conf:


image = /boot/memtest.bin
    root = /dev/hda2
    label = memtest86
    read-only


obs.: hda2 eh a partiçao onde se encontra a raiz do meu Slackao, por isso substitua de acordo com sua instalaçao (olha, rimou!)… mas sem lambanças, por favor! =)

reconstrua seu MBR com as modificaçoes que adicionamos agora… para isso, rode:

root@bodacious:/home/bode/pacotes/memtest86-3.5# lilo

bom, depois disso o resto eh historia!!! reinicie sua maquina e escolha no menu de boot do lilo a opçao memtest86… durante os testes voce ira se deparar com uma tela semelhante a esta:

caso seu pente de memoria ram esteja baleado, a tela ficara deste jeito… eh… ¬¬ eu realmente espero que voce nao passe por isto:

mas se passar… ja sabe… o titulo de corajoso pode servir depois de aplicar o patch em seu kernel, recompilar, colocar os endereços invalidos em blacklist… dae sim, pode se sentir suave na nave!!!

[]’s!
t++!

pacotes no slackware, parte 1: pkgtools

Posted in bash, slackware, sysadmin with tags , , , , , , , , , , on 23-02-2009 by sirboderafael

o Slackware possui uma visao extremamente simplista de tudo, e como era de se esperar, nao seria diferente com seus pacotes…

irei explicar, atraves exemplos praticos, como funciona seu gerenciamento de pacotes…

vamos verificar a primeira das ferramentas, o pkgtool:
root@bodacious:/home/bode# pkgtool

as opcoes que ele nos oferece sao:

  • Current: se voce tem pacotes alojados no diretorio de onde chamou o pkgtool, ele os identifica e, pacote por pacote, vai perguntando se deve ou nao instalar no sistema
  • Other: busca os pacotes a serem instalados, mas que estejam localizados em outro diretorio, que no caso, voce deve informar… se comporta assim como Current, durante a identificacao e instalacao dos pacotes
  • Floppy: assim como em Current e Other, busca por pacotes a serem instalados, mas espera que estejam localizados dentro de um disquete…
  • Remove: exibe uma lista contendo todos seus pacotes instalados, onde voce pode marcar quais serao removidos (utilizando a barra de espacos) e com certeza os que estiverem marcados irao virar poeira cosmica, caso deseje…
  • View: exibe a lista com todos os pacotes que estao instalados no sistema, mas seu diferencial eh que permite visualizarmos tanto a descricao completa de um pacote quanto quais sao os arquivos contidos no mesmo (junto de sua localizacao no sistema)
  • Setup: opcao interessante… permite executar novamente os scripts de configuracao que sao rodados durante a instalacao do sistema… soh para exemplificar, temos scripts que configuram a rede, o mouse, quais serao os servicos ativados por padrao… etc…
  • Exit: adivinha? sim… ele sai do pkgtool =)

veremos destas opcoes, somente a que visualiza as coisas, por ser algo mais intuitivo de se fazer logo de cara, ao inves de remover ou instalar alguma coisa… para isso, selecione View e observe a tela contendo a listagem de pacotes:

malandramente, irei conduzir as coisas para nosso proximo passo, mostrando um pouco de como as coisas funcionam por dentro… para isso encontre na lista um pacote chamado pkgtools-12.1.0-noarch-7… sim, se voce apertar o “p”, ele jah posiciona a seleçao da lista para onde existem pacotes cujo nome começa com a letra “p”… =) assim que encontra-lo, de um OK e daremos uma passada rapida pelas informacoes que obtemos com isso:

como pudemos observar, existem algumas seçoes distintas, dentre as quais PACKAGE DESCRIPTION e FILE LIST sao, para nos, as mais importantes no momento…

logo de cara olhando na lista de arquivos, podemos identificar que o proprio pkgtool faz parte desse pacote, o pkgtools… hummm, interessante… vemos tambem que existem mais scripts alem do pkgtool, os quais possuem nomes muito sugestivos, tendo como principais figuras estes caras:

  • installpkg: instala novos pacotes
  • upgradepkg: faz o upgrade de um pacote instalado no sistema para um pacote mais novo, substituindo os arquivos contidos no antigo pacote pelos arquivos contidos no novo pacote
  • removepkg: serve para remover pacotes
  • explodepkg: nao, nao eh um comando explosivo, sua funçao eh simples e direta… descompacta o conteudo de todos os pacotes (compativeis com o padrao do Slackware, que eh .tgz == tar + gz) informados para o diretorio corrente… avisa se algum script de instalaçao foi encontrado nesse pacote apos descompacta-lo…
  • makepkg: muito bacana este utilitario… ajuda a montarmos nosso pacote, que ja deve estar com sua hierarquia montada corretamente dentro de um diretorio, apos sua compilaçao ter sido bem sucedida, obviamente… =)

a parte mais legal de tudo isso eh realmente utilizar esses utilitarios de linha de comando, afinal nos somos slackers ou sacos de batatas? …nao responda! hahahaha!

como nosso exemplo pratico de uso, vamos utilizar o htop de cobaia… trata-se de uma versao “mais completa”, “mais rock-n-roll”, e que na minha opiniao, eh mais legal que o top, que jah vem instalado no sistema…

baixaremos do Linux Packages, uma versao do htop que esta defasada, para primeiro treinarmos como funciona o processo de instalaçao, usando o installpkg… depois, iremos atualiza-lo para a versao corrente (pelo menos, ateh a data de publicaçao deste post, eh claro) disponivel no portal italiano Slacky, com o upgradepkg… no final das contas, acionaremos o removepkg que ira manda-lo diretamente para o Pelé… nao restando instalado em nosso sistema, apos este exercicio, um arquivo sequer, proveniente deste teste…

obs.: sim, eu sei que ele eh um pacote de Slackware 12.1 e estamos na versao 12.2, mas este eh apenas um exercicio onde jah averiguei a compatibilidade de versoes entre os pacotes… vai ser mais legal assim, acredite… qualquer coisa, voce vai sentir o removepkg necessario, alem de achar da hora a maneira que o upgradepkg atualiza os pacotes…

vamos lah, em seu diretorio de pacotes, ou em qualquer outro que queira, baixe o htop defasado e renomeie o bicho para que tenha o final .tgz, senao o installpkg nao vai rodar direito com ele, caso voce esteja com o Slackware 12.2 instalado, assim como eu:

bode@bodacious:~/pacotes$ wget http://mirror.slackwarebrasil.org/linuxpackages/Slackware/Slackware-12.1/Console/htop/htop-0.8-i486-1ant

bode@bodacious:~/pacotes$ mv htop-0.8-i486-1ant htop-0.8-i486-1ant.tgz

agora sim… vamos instalar essa bagaça velha?

root@bodacious:/home/bode/pacotes# installpkg htop-0.8-i486-1ant.tgz

beleza na represa… se tudo correu bem, sua saida foi bem parecida como esta:

Installing package htop-0.8-i486-1ant...
PACKAGE DESCRIPTION:
htop: htop 0.8
htop:
htop: This is htop, an interactive process viewer for Linux.
htop:
htop: Package Created By: Anton Dobkin
Executing install script for htop-0.8-i486-1ant...

agora que sabemos como se instala (viram como foi facil?) pacotes, veremos como se atualiza pacotes…

baixe a versao corrente do htop, ainda em seu diretorio de pacotes…

bode@bodacious:~/pacotes$ wget http://repository.slacky.eu/slackware-12.2/hardware/htop/0.8.1/htop-0.8.1-i486-2sl.tgz

mande um upgradepkg no danado para ver que belezinha!
root@bodacious:/home/bode/pacotes# upgradepkg htop-0.8.1-i486-2sl.tgz

se tudo correu bem, sua saida foi essa:

+==============================================================================
| Upgrading htop-0.8-i486-1ant package using ./htop-0.8.1-i486-2sl.tgz
+==============================================================================

Pre-installing package htop-0.8.1-i486-2sl...

Removing package /var/log/packages/htop-0.8-i486-1ant-upgraded-2009-02-23,18:31:13...
--> Deleting /usr/doc/htop-0.8/AUTHORS
--> Deleting /usr/doc/htop-0.8/COPYING
--> Deleting /usr/doc/htop-0.8/ChangeLog
--> Deleting /usr/doc/htop-0.8/INSTALL
--> Deleting /usr/doc/htop-0.8/NEWS
--> Deleting /usr/doc/htop-0.8/README
--> Deleting /usr/doc/htop-0.8/TODO
--> Deleting /usr/share/man/man1/htop.1.gz
--> Deleting empty directory /usr/doc/htop-0.8/

Installing package htop-0.8.1-i486-2sl...
PACKAGE DESCRIPTION:
htop: Htop (Process Viewer)
htop:
htop: This is htop, an interactive process viewer for Linux. It is a text-mode
htop: application (for console or X terminals) and requires ncurses.
htop: Tested with Linux 2.4 and 2.6.
htop:

Package htop-0.8-i486-1ant upgraded with new package ./htop-0.8.1-i486-2sl.tgz.

viu soh? divertido saber que o upgradepkg reconheceu que estamos lidando com uma versao mais nova do pacote htop e substituiu os arquivos velhos pelos novos… ele olha o nome dos pacotes (que devem ser iguais e no nosso caso eh htop mesmo), depois ele olha o numero da versao entre os pacotes… caso os numeros de versao sejam iguais, ele ira decidir qual eh o pacote mais novo baseando-se no numero da compilacao do mesmo, que no caso, em nosso novo pacote chama-se: 2sl… e se estivessemos com htop 0.8.1 instalado e sua versao de compilaçao fosse 1sl, este seria substituido da mesma maneira como foi substituido, pois o upgradepkg iria saber como proceder…

prontos para remover nosso recem-instalado pacote, htop?

ah, se fosse voce dava uma olhadinha esperta no htop para ver como ele eh… tah ai um utilitario legal:

bom, se mesmo assim voce estiver realmente empenhado em metralhar o infeliz, basta fazer o seguinte com o coitado:

root@bodacious:/home/bode/pacotes# removepkg htop

a saida da remoçao eh a seguinte:

Removing package /var/log/packages/htop-0.8.1-i486-2sl...
Removing files:
--> Deleting /usr/bin/htop
--> Deleting /usr/doc/htop-0.8.1/COPYING
--> Deleting /usr/doc/htop-0.8.1/INSTALL
--> Deleting /usr/doc/htop-0.8.1/NEWS
--> Deleting /usr/doc/htop-0.8.1/README
--> Deleting /usr/doc/htop-0.8.1/htop.SlackBuild
--> Deleting /usr/doc/htop-0.8.1/slack-desc
--> Deleting /usr/man/man1/htop.1.gz
--> Deleting /usr/share/applications/htop.desktop
--> Deleting /usr/share/pixmaps/htop.png
--> Deleting empty directory /usr/doc/htop-0.8.1/

chegamos facilmente a conclusao de que as funcoes do pkgtool sao baseadas em varios scripts independentes… e realmente, lidar com pacotes no Slackware eh algo simples de se fazer… ao contrario do que reza a lenda em alguns cantos sombrios da web…

ainda nao falei sobre os problemas de resoluçao de dependencias entre pacotes, pois pretendo escrever isso em um futuro post…

sendo o primeiro da saga, acredito que esteja de bom tamanho o que vimos ateh agora e em breve estaremos destrinchando as inumeras possibilidades e assuntos relacionados ao gerenciamento e criacao de pacotes para o Slackware! ufa! =D

sussa na montanha russa galera?
[]’s!
t++!

tunelamento ssh direto no proxy com o corkscrew

Posted in bash, seguranca, sysadmin with tags , , , , , , , , , , , , , , , , on 21-02-2009 by sirboderafael

vamos supor que seu administrador de rede nao seja um cara legal… e que por isso ele passou a permitir somente o trafego de dentro pra fora na porta 80, ou 8080, como se faz normalmente quando se tem um proxy…

soluçao? hahahaha! nada de utilizar programinhas amadores para fazer isso… vamos “sacar essa rolha” logo… apresento a voces meu mais novo amigo, conhecido como corkscrew!

sem mais delongas, vamos ao que interessa… baixe logo essa paçoca!
bode@bodacious:~/pacotes$ wget http://www.agroman.net/corkscrew/corkscrew-2.0.tar.gz

extraia:
bode@bodacious:~/pacotes$ tar vxzf corkscrew-2.0.tar.gz

entre no diretorio onde ele foi extraido e faça o “metodo padrao” para compilar seu pacote:

bode@bodacious:~/pacotes$ cd corkscrew-2.0
bode@bodacious:~/pacotes/corkscrew-2.0$ ./configure && make

se deu tudo certo, o make apos compilar o corkscrew, gerou um binario cujo nome eh… adivinha? corkscrew!

voce tem duas opcoes agora, ou criar seu pacote ou instala-lo dentro de seu filesystem… vou adotar a maneira mais simples que é instalar direto do filesystem, afinal, é um binariozinho de nada e nao um catatau de arquivos, mas quem quiser, basta fazer o pacote como descrito aqui. Claro, o link trata da criaçao de um pacote para Slackware Linux

instalando no filesystem (ira cair em /usr/local/bin):
root@bodacious:/home/bode/pacotes/corkscrew-2.0# make install
observaçao: sim, estou ciente que /usr/local/bin nao eh o local padrao de instalacao no Slackware (/usr/bin), no entanto estou somente “copiando” um unico binario para lah, ou seja, nao estou instalando um pacote inteiro, portanto eh perfeitamente aceitavel coloca-lo neste local, pois assim ele irah se diferenciar dos demais, “gerenciados pelo sistema”, e se voce quiser pode simplesmente remove-lo “na unha”, isso nao ira prejudicar seu sistema….

utilizando o corkscrew:
beleza, ele ja esta instalado em seu sistema, entao para realizarmos o tal do tunelamento via proxy basta configurar alguns aspectos de seu cliente de SSH:

arquivo ~/.ssh/conf.ssh/config:
adicione as seguintes linhas:

Host *
ProxyCommand corkscrew seu-proxy-http 8080 %h %p

teste:
root@bodacious:/home/bode/pacotes/corkscrew-2.0# ssh usuario@host.com

se rolar certinho, maravilha! mande um Pedro de Lari que esta tudo de boa e voce pode viver como se as regras de firewall para ssh nao existissem…

meu proxy requer autenticacao: entao voce precisa alterar o arquivo ~/.ssh/conf.ssh/config para que fique como:

Host *
ProxyCommand corkscrew seu-proxy-http 8080 %h %p ~/.ssh/proxyauth

crie o arquivo ~/.ssh/proxyauth com o seguinte conteudo:

usuario:senha

e agora sim voce pode mandar um Pedro de Lari nessas restricoes que soh nos atrapalham!

segundo o site do projeto, o corkscrew funciona para os seguintes proxys:

  • gauntlet
  • cacheflow
  • junkbuster
  • apache’s mod_proxy
  • squid

eu particularmente, testei no squid e funcionou na maior tranquilidade!

[]’s a todos!
t++!

monitorando os sensores instalados com o ‘lm_sensors’

Posted in bash, kernel, sysadmin with tags , , , , , on 06-11-2008 by sirboderafael

falhas de hardware podem acontecer por diversos motivos, mas temos a opcao de monitorar o sistema e tomar as providencias quando necessario.

as informacoes de monitoramento de sensores chegam ateh nos devido a captura de seus status, o que eh fornecido por alguns modulos que sao carregados junto ao kernel mas que muitas vezes nao estao rodando…

assumindo que em seu sistema ja encontra-se devidamente instalado o pacote lm_sensors, partiremos para sua configuracao…

o primeiro passo, consiste em detectar quais modulos seu kernel deve carregar… isso obviamente depende do hardware instalado e se este oferece a capacidade de ser monitorado…

para isso, execute no shell o utilitario sensors-detect com uma conta privilegiada:
bode@bodacious:~$ sudo sensors-detect

ele ira perguntar quais partes de seu hardware deverao serao escaneadas, responda Yes para as que achar importantes… essa eh a maneira tipica de se perguntar qual o hardware em questao que deve ser escaneado:


This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.


We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no):

considere escanear completamente seu hardware e responda Yes para todos os testes… sao muito raros os casos onde pode ocorrer alguma falha durante a execucao dos testes…

ao final da deteccao, sera gerado um arquivo de configuracao em /etc/sysconfig/lm_sensors, que contem os nomes dos modulos que devem ser carregamentos no kernel…

uma vez gerado o arquivo, voce eh lembrado que os modulos devem ser carregados atraves de um script de inicializacao, que no caso pode ser tanto /etc/init.d/lm_sensors.init (RedHat’s) quanto /etc/rc.d/rc.lm_sensors (Slack’s)… no entanto, eh comum nao se encontrar esse script instalado na raiz do sistema, mesmo que o pacote lm_sensors esteja instalado… neste caso faca o download do script e o armazene em /etc/rc.d/rc.lm_sensors (esse eh o padrao do Slack, adapte ele para o local onde sua distro o organizaria normalmente)… e nao se esqueca de marca-lo como executavel:
bode@bodacious:~$ sudo chmod +x /etc/rc.d/rc.lm_sensors

coloque a seguinte entrada no arquivo /etc/rc.d/rc.local:
/etc/rc.d/rc.lm_sensors
assim, durante a proxima inicializacao do sistema, logo que o rc.local rodar, tambem serao carregados os modulos que foram detectados… a vantagem desse script eh a separacao do instante de carregamento com relacao aos dos demais modulos… observe que nele uma serie de checagens especiais sao realizadas antes do carregamento de cada modulo (atraves de um processo iterativo), o que certamente nos pouparia de eventuais distracoes se nossa escolha fosse carrega-los diretamente com o modprobe

agora, assumindo que os modulos estao carregados apos uma reinicializacao, ou simplesmente pela execucao de nosso novo script, podemos monitorar o status dos sensores executando:
bode@bodacious:~$ sensors

voce ira obter informacoes do tipo:

Adapter: SMBus ALI1535 adapter at e800
VCore 1: +1.73 V (min = +1.49 V, max = +1.90 V)
VCore 2: +1.74 V (min = +1.49 V, max = +1.90 V)
+3.3V: +3.26 V (min = +2.96 V, max = +3.63 V)
+5V: +5.03 V (min = +4.49 V, max = +5.51 V)
+12V: +12.04 V (min = +9.55 V, max = +14.41 V)
-12V: -2.03 V (min = -4.07 V, max = -0.32 V)
-5V: -5.39 V (min = -1.76 V, max = -0.82 V)
fan1: 0 RPM (min = 61363 RPM, div = 2)
fan2: 3479 RPM (min = 18243 RPM, div = 2)
fan3: 0 RPM (min = 56250 RPM, div = 2)
M/B Temp: +31°C (high = +21°C, hyst = +6°C)
CPU Temp: +32.0°C (high = +100°C, hyst = +92°C)
temp3: -0.5°C (high = +80°C, hyst = +75°C)
vid: +1.700 V (VRM Version 8.2)
alarms:
beep_enable:
Sound alarm enabled

dessa maneira, eh possivel realizar o monitoramento dos sensores instalados em seu hardware via shell e se for o caso, pode ser instalado algum monitor grafico dessas mesmas informacoes de status e deixa-lo rodando no desktop para uma maior comodidade…

pipes e redirecionamento de entrada/saida

Posted in bash with tags , , , , , , , , , on 20-04-2008 by sirboderafael

iremos verificar o funcionamento dos pipes e dos redirecionamento de entrada/saida de uma maneira simples e guiada por exemplos praticos.

em sistemas unix-like, eh comum utilizar-se de pipes para concatenar a saida de um programa imediatamente na entrada de outro programa…

quando executamos o comando:
bode@bodacious:~$ dmesg

gera uma saida de ~20KB em alguns sistemas… o que eh o suficiente para que do texto exibido tenhamos informacoes iniciais perdidas, pois mesmo rolando o texto todo para cima (com varios shift+page_up’s seguidos) notamos que faltam muitas das informacoes iniciais (caso nosso terminal suporte um buffer menor que o tamanho da saida retornada)…

entao uma boa maneira de visualizar todo o conteudo da saida do comando dmesg eh atraves da utilizacao de um pipe para um visualizador de textos que aceite uma streaming de dados como entrada:

bode@bodacious:~$ dmesg | most

ira fazer com que a saida do comando dmesg seja visualizada no most, onde podemos rolar o texto livremente e sem perda de informacoes…

curiosidades:
(1) o caractere | eh comumente lido como pipe
(2) o conceito de ter um ‘cano’ ligando a saida de um comando na entrada de outro comando foi criado por douglas mcIlroy e implementado no unix por ken thompson em 1973;
(3) quando a saida de um programa eh produzida, uma quantidade de dados deve ser absorvida pela entrada do outro programa concatenado pelo pipe e assim sucessivamente (caso esteja trabalhando com mais de dois programas ‘concatenados’), no entanto esta saida nao deve ser maior que o buffer (ou fila) de entrada do programa que ira recebe-la… o sistema se encarrega de cuidar disso caso o buffer de entrada se preencha, a execucao do programa que gera a saida eh suspensa e soh eh retomada assim que o buffer de entrada possa receber mais dados… ou seja, o escalonador de processos marca o processo como bloqueado ateh que este esteja apto a assumir o estado de pronto novamente… isso eh muito bacana =)
(4) quando falamos em saida-padrao de um programa nos referimos a stdout e similarmente quando falamos em entrada-padrao de um programa nos referimos a stdin;
(5) quando um erro eh disparado, este eh gerado em sua stderr, abordaremos seu uso mais adiante…

os pipes nao sao limitados a exemplos banais como este, eles podem ser utilizados para se filtrar a saida de um determinado comando quando utilizados em conjunto com algum comando da familia grep por exemplo:

bode@bodacious:~$ ps -A | fgrep swift
2821 ? 00:00:00 swiftfox
2830 ? 00:09:58 swiftfox-bin

fez com que a saida do comando ps -A fosse filtrada pelo comando fgrep em busca da palavra swift (estava realmente executando o swiftfox em meu sistema enquanto editava este post e recebi o numero dos processos gerados relacionados ao mesmo)

ha uma maneira de pipe que consiste em executar um determinado comando dentro de outro comando, passando para o ultimo sua saida, onde eh possivel absorver estes dados de alguma maneira:
bode@bodacious:~$ for diretorio in `ls -1 /home`; do echo "diretorio: ${diretorio}"; done

faz com que todos os diretorios dentro do diretorio /home sejam listados com a palavra diretorio em sua frente… isso eh possivel pois iteramos sobre cada ‘diretorio’ atraves da captura da saida do comando ls -1 envolvido por aspas invertidas ``

existem outras formas de se realizar pipes e estamos entrando em um conceito chamado redirecionamento de entrada/saida… assim como os pipes concatenam o fluxo de dados proveniente da saida de programas com a entrada de outros programas, podemos por exemplo redirecionar a saida de um programa para um arquivo… ou entao capturar os dados de um arquivo e enviar os mesmos para a entrada de um programa:
bode@bodacious:~$ cat /proc/cpuinfo >> ~/status /proc/meminfo >> ~/status

temos que a saida dos comandos cat foram redirecionadas para o arquivo status de maneira que seus conteudos foram concatenados um apos o outro atraves do operador >>
note: mesmo que o arquivo nao exista ele sera criado… caso exista, o conteudo redirecionado sera concatenado imediatamente apos as demais informacoes ja gravadas no interior do arquivo;

tambem podemos capturar informacoes sobre as flags que a cpu instalada em nosso sistema suporta, caso utilizemos:
bode@bodacious:~$ fgrep flags /proc/cpuinfo | cut -f 3 | cut --complement --delimiter=":" -f 1 | uniq > descricao-cpu

observacoes:
(1) a saida do comando eh direcionada ao arquivo descricao-cpu
(2) a diferenca basica entre utilizar o operador >> ao inves de utilizar o operador > para o redirecionamento de saida dos programas consiste em:
>> concatena a saida ao final do arquivo especificado, caso este nao exista ele sera criado, similar ao modo append de escrita em arquivos comumente encontrado em grande parte das linguagens de programacao
> simplesmente descarrega a saida para o arquivo especificado… tambem cria o arquivo caso este nao exista e no caso de existir, sobrescreve todo seu conteudo pela saida do programa que precede seu uso

tambem temos o caso de quando queremos efetuar o direcionamento de algum arquivo para um programa… exemplo classico que abre um streamming de dados do arquivo /proc/meminfo para o programa cat:
bode@bodacious:~$ cat < /proc/meminfo

agora uma mistura entre pipe e redirecionadores de entrada/saida:
bode@bodacious:~$ cat < /proc/modules | sort > informacoes

le o arquivo /proc/modules atraves do redirecionador de entrada < e o programa cat, passa a saida para a entrada do programa sort atraves do pipe | que armazena as informacoes geradas no arquivo informacoes atraves do redirecionador de saida >

aproveitando que estamos tratando do termo redirecionador de saida devemos saber que existem duas saidas que sao frequentemente utilizadas: stdout e stderr:

stdout nos lembra algo relacionado a saida ja que seu proprio nome eh standard output… eh utilizada pelos programas para imprimirem mensagens na saida padrao… ja viu em alguns lugares que a impressora pode ser sua saida padrao? pois eh, ela pode… mas somente caso queira, porque o padrao eh que seja em seu terminal (ou console) por motivos bem obvios =)
nos referenciamos a este descritor de arquivo (este eh o termo correto) por um numero que no caso eh 1

bode@bodacious:~# /etc/rc.d/rc.httpd start > saida_httpd 2>&1
ira iniciar o servidor apache enviando sua saida para o arquivo saida_httpd e os eventuais erros serao redirecionados para a saida padrao:
2 eh o numero do stderr que eh redirecionado para &1, a saida-padrao stdout (o simbolo & funciona aqui como um meio de referenciarmos a saida-padrao)…. eh interessante notar que se nao tivessemos feito isso, os erros nao seriam reportados no mesmo meio que a saida-padrao (no caso, redirecionada para o arquivo saida_httpd)… nao que todos os erros devam ir para a saida padrao soh porque eu queira… no entanto um bom exemplo de quando isso se faz util eh o caso de estarmos analisando em conjunto a saida que um programa produz junto de suas mensagens de erro…

podemos facilmente ter uma versao modificada do comando anterior, onde stdout e stderr sao redirecionadas para arquivos distintos saida_httpd e erros_httpd respectivamente:
bode@bodacious:~# /etc/rc.d/rc.httpd start 1>saida_httpd 2>erros_httpd

sim… se voce acompanhou a conclusao do funcionamento destes descritores de arquivo, provavelmente chegou a conclusao (ou nao…) de que < eh uma abreviacao de <0… sim, isto eh verdade, o descritor de arquivo 0 equivale a stdin (standard input) que naturalmente eh a entrada para nosso programa a ser executado… podemos brincar bastante com as entradas, no entanto na maioria esmagadora das vezes utilizamos somente os pipes e os redirecionadores de saida… entao chega de fritacao por enquanto!!! =D

bom, pra terminar listei abaixo algumas referencias que utilizei para pesquisa e que podem ateh quem sabe clarificar alguma coisa que passou batido:
http://en.wikipedia.org/wiki/Pipeline_(Unix)
http://www.december.com/unix/tutor/pipesfilters.html
http://www.livefirelabs.com/unix_tip_trick_shell_script/june_2003/06092003.htm
http://www.softpanorama.org/Scripting/pipes.shtml