Archive for the sysadmin Category

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++!

Anúncios

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…