terça-feira, 31 de março de 2009
Nmap 4.85BETA5 lançado para escanear Conficker
Com isso o pessoal do Insecure.org juntamente com a galera do The Honeynet Project
lançou uma nova versão beta do famoso portscan Nmap, o Nmap 4.85BETA5 pode ser baixado
no link a seguir:
http://nmap.org/download.html
Para escanear uma maquina pera ver se ela esta infectada com o Conficker basta executar o comando a seguir:
nmap -PN -T4 -p139,445 -n -v --script=smb-check-vulns --script-args safe=1 [Rede de destino]
Fonte:
http://insecure.org/
By CleBeer
quarta-feira, 25 de março de 2009
Quebrando captcha por dinheiro
com certeza você já deve ter se deparado com um CAPTCHA em sua vida, captcha é aquela figura com vários caracteres que é utilizado em sistemas como tira-teima do email UOL, quando você erra a senha do gmail e no easy-share quando vai baixar um arquivo. A figura a segui é um exemplo de captcha:
A sigla captcha significa "Completely Automated Public Turing test to tell Computers and Humans Apart" Que traduzindo para o português seria algo como "teste de turing público completamente automatizado para diferenciar entre computadores e humanos."
Este tipo de proteção é utilizado para evitar que propgramas acessem informações (como cadastro de usuários, envio de email ou perquisas) se passando por um ser humano, se bem que certa vez eu vi um captcha que a meu ver era humanamente impossível de resolver...rrs
Pois é mas hoje eu vi um site que fornece o serviço de quebrar captchas, pois é com a módica quantia de dois dolares (pouco menos de cinco reais) você compra um pacote para quebrar mil captchas, legal que o site tem F.A.Q e garantia, "You pay for correctly recognized CAPTCHAs only" (você só paga pelo captcha que forem reconhecidos corretamente...rsrs)
Interessado no serviço?
veja o site:
http://decaptcher.com/client/
Legal do site deles é que eles também utilizam Captcha..rsrsrs
By CleBeer.
Super rootkit resiste a formatação do HD
Mais em:
http://www.theregister.co.uk/2009/03/24/persistent_bios_rootkits/
By CleBeer...
terça-feira, 24 de março de 2009
Mojito
um dos drinks que mais curto é o Mojito por isso vou postar a receita dele aqui:
Ingredientes
2 ramos de hortelã
1 colher (sopa) de açúcar
Gelo em cubos
3 colheres (sopa) de rum branco
Suco de 1/2 limão
Club soda ou água com gás
Preparo
Coloque 3 a 4 folhas de hortelã num copo alto, adicione o açúcar e amasse bem.
Acrescente alguns cubos de gelo, o rum, o suco de limão e complete com club soda ou água com gás.
Mexa rapidamente e sirva decorado com a hortelã restante.
By CleBeer |_b
Kernel Linux versão 2.6.29
com o codinome "Temporary Tasmanian Devil." Dentre as
principais mudanças estão o suporte ao sistema de arquivo "Btrfs"
que foi inicialmente desenvolvido pela Oracle (Este ainda esta em teste e não é aconselhavel
o uso a não ser que você va testar o sistema de arquivos), suporte ao sistema de arquivos
squashfs e um modo de configuração específico para placas de vídeo Intel.
Maiores detalhes em:
http://kernelnewbies.org/Linux_2_6_29
DNS (Cultura Inútil)
sexta-feira, 20 de março de 2009
Websense classifica erroneamente cisco.com como site hacker
Fonte:
The Register
Como trabalha o Kernel Linux
Entendendo o kernel
OK, mas oque exatamente faz esse tal de kernel? A figura a seguir mostra de uma forma geral como o kernel disponibiliza serviço para os aplicativos rodando através de inúmeros pontos de entrada conhecidas como chamadas de sistema (system calls).
O kernel utiliza chamadas de sistema como leitura e escrita pra prover acesso ao hardware.
Do ponto de vista de um programador isso parece uma função comun, embora na realidade uma chamada de sistema envolva diferentes interruptores no modo de operação do "kernel space" para o "user space" Juntos esse conjunto de chamadas de sistema formam uma especie de "maquina virtual" que trabalha antes do hardware real. Um exemplo claro disso é o sistema de arquivos.
Kernel Modular
Agora que entendemos melhor o que o kernel faz, vamos olhar mais atentamente a sua organização física. As primeiras versões do kernel eram monolíticas, ou seja, todos os módulos estavam compilados dentro de um único arquivo executavel. O kernel das distribuições mais novas são modulares, ou seja, os módulos podem ser carregados no kernel em tempo de execução, isso faz com que o núcleo do kernel fique menor e não seja necessário reiniciar a maquina para carregar ou substituir novos módulos.
O núcleo do kernel é carregado na memória na hora do boot e é lido de um arquivo no diretório “/boot” na maioria das vezes este arquivo é chamado de “vmlinuz-VERSÃO_DO_KERNEL”. Para ver a versão do kernel corrente utilize o comando:
---
#uname -r
---
Os módulos ficam no diretório “/lib/modules/VERSÃO_DO_KERNEL/”
Gerenciando módulos.
Veremos agora alguns comandos para gerenciar os módulos do seu kernel, como por exemplo o comando para listar os módulos carregados que é o “lsmod”, o lsmod vai te mostrar uma saída semelhante a esta:
---
Module Size Used by
vfat 14464 0
isofs 36388 0
fat 54556 1 vfat
nfs 262540 0
lockd 67720 1 nfs
nfs_acl 4608 1 nfs
sunrpc 185500 5 nfs,lockd,nfs_acl
bridge 55576 0
tun 12672 0
usb_storage 73792 4
libusual 19236 1 usb_storage
---
Esta saída possui quatro campos divididos por nome do módulo que esta carregado, o tamanho do módulo, quantas vezes ele esta sendo utilizado e quais os módulos que dependem dele. Podemos carregar um módulo utilizando o comando “modprobe” (podemos também utilizar o comando “insmod” porém o modprobe é mais aconselhavel pois ele resolver as dependencias do módulo). Outro ponto muito importante na saída do comando lsmod é o terceiro campo que indica a quantidade de vezes que o módulo esta sendo utilizado pois o linux não vai permitir a remoção de um módulo cujo o campo used seja diferente de zero, no exemplo acima vemos o módulo “isofs” (utilizado para dar suporte ao sistema de arquivos “ISO” que é utilizado em Cds) com o campo used “0” neste caso podemos remover o módulo com o comando “modprobe -r isofs”, após executar este comando o módulo isofs não vai aparecer mais quando executarmos o lsmod.
Não é muito comum carregar módulos manualmente no dia a dia, porém se você precisar carregar um módulo manualmente você pode incluir parâmetros específicos de cada módulo para carrega-lo, como no exemplo a seguir:
---
modprobe usb_storage delay_use:3
---
No exemplo supra-citado habilitamos o parâmetro “delay_use:3” para o módulo “usb_storage” que define um time-out de 3 segundos para o módulo procurar um novo device. Para saber quais as opções de cada módulo utilizamos o comando modinfo como no exemplo a seguir:
---
# modinfo usb_storage
filename: /lib/modules/2.6.24-23-generic/kernel/drivers/usb/storage/usb-storage.ko
license: GPL
description: USB Mass Storage driver for Linux
author: Matthew Dharm
srcversion: 99E0EB653929DE200DF6AF9
depends: libusual,usbcore,scsi_mod
vermagic: 2.6.24-23-generic SMP mod_unload 586
parm: delay_use:seconds to delay before using a new device (uint)
---
A linha que nos interessa neste caso é a que começa com “param” que mostra os parâmetros aceitos pelo módulo. Caso você possua a source do kernel você também pode encontrar uma documentação muito útil em “/usr/src/VERSÂO_DO_KERNEL/Documentation/kernel-parameters.txt”
Sistema de arquivos /proc
O kernel também nos fornece inúmeras informações que podem ser encontradas no sistema de arquivos “/proc”, os arquivos no /proc são criados pelo kernel (alguns você pode alterar, outros não) um exemplo claro do tipo de informação que podemos encontrar no /proc esta to arquivo “/proc/modules” que mostra todos os módulos carregados no sistema (sim é semelhante ao comando lsmod.. =D), no arquivo “/proc/meminfo” que mostra o status detalhado da memória do sistema e também o arquivo “/proc/net/arp” que mostra a tabela ARP (mesma tabela exibida pelo comando “arp -a”).
Beleza falei do /proc mas só citei arquivos que não podem ser alterados, são arquivos que somente nos fornecem algumas informações, mas o /proc não é só isso, um subdiretório do /proc muito importante é o “sys”, por exemplo o arquivo “/proc/sys/net/ipv4/ip_forward” define que o kernel irá encaminhar pacotes IP, a sintaxe é muito simples se o conteúdo deste arquivo for “0” (zero) o kernel não fará encaminhamento de pacotes IP e se o conteúdo for “1” (Um) o kernel fará encaminhamento de pacotes IP, esta opção deve ser habilitada se você for utilizar o linux como um roteador; ta com mas como eu habilito isso?
Vamos primeiro ver como esta o arquivo:
---
# cat /proc/sys/net/ipv4/ip_forward
0
---
Vemos que o conteúdo do arquivo é “0” (zero), agora vamos habilitar o encaminhamento de pacotes IP no kernel.
---
# echo 1 > proc/sys/net/ipv4/ip_forward
---
Pronto agora o encaminhamento de pacotes IP esta habilitado, fácil né? Outro comando que também pode ser utilizado para executar a mesma tarefa é o “sysctl” como no exemplo a seguir:
---
#sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
---
No exemplo acima utilizamos o comando sysctl para ver o valor do ip_forward, para alterar este valor utilizamos o comando sysctl com as seguintes opções:
---
#sysctl -w net.ipv4.ip_forward = 1
---
Porém tem um pequeno problema aqui, se reiniciarmos a maquina este arquivo voltara a ter conteúdo igual a “0” (zero). E como solucionamos isso? A solução e muito fácil utilizamos o arquivo “/etc/sysctl.conf” para definir os valores que serão configurados na hora do boot, então basta acrescentarmos a linha “net.ipv4.ip_forward = 1” no arquivo sysctl.conf.
Melhorando a performance.
Muitos dos parâmetros do /proc/sys que permitem escrita podem ser utilizados para melhorar a performance do Linux, apesar de que a configuração padrão já habilite opções que trabalham muito bem. Um exemplo de como podemos modificar o kernel para melhorar a performance de acordo com o tipo de aplicação que você vai utilizar esta no guia de instalação do Oracle 10g (http://www.oracle.com/technology/obe/obe10gdb/install/linuxpreinst/linuxpreinst.htm) que pede pra você configurar alguns parâmetros como o “kernel.shmmax=2147483648” que define o tamanho máximo de segmento de memória partilhada para 2GB. (Memória partilhada é um mecanismo de comunicação entre processos que permite que um segmento de memória de ser visível dentro do espaço de endereçamento de múltiplos processos.)
Outra modificação que podemos fazer e definir que nossa máquina não vai responder por broadcast de icmp (o bom e velho ping -b 255.255.255.255) configurando o sysctl da seguinte forma:
---
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
---
Agora fica a seguinte dúvida, pra ver os valores eu vou ter que dar cat de arquivo em arquivo ou saber todos os caminhos do comando sysctl? Claro que não, basta utilizar o comando
---
sysctl -a
---
..que ele vai exibir todos os parâmetros e seu valores porém ele não fala pra que serve cada um deles porém isso podemos encontrar os detalhes no bom e velho “man proc” Ta vendo, o kernel não é aquele bicho de sete cabeças que muitos imaginam....rsrsr
By CleBeer....
[email protected]
clebeerpub.blogspot.com
Representação geográfica de alertas do snort
SSH - Muito mais que um simples shell seguro
Para quem administra vários servidores, hoje em dia o ssh faz-se mais do que necessário para agilizar a execução de comandos remotos. Entretanto, já presenciei diversas cenas em que determinado usuário não sabe o poder que o ssh nos oferece e acaba utilizando-o apenas como uma simples ferramenta para login remoto, deixando de lado outras poderosas funcionalidades.
O intuito deste tutorial é mostar algumas funcionalidades do ssh, que ajudam e muito no dia-a-dia do administrador.
1. Troca de Chaves
Certa vez um aluno me contou que queria criar um script de backup remoto utilizando o ssh (scp), porém não estava conseguindo fazer o script ler um arquivo com a senha (gravada em texto-plano) e inserí-la na hora em que o ssh pede a senha do usuário. Então perguntei para ele:
- Por que você quer utilizar o SSH ao invés de FTP?
- Porque é mais seguro.
- O que tem de seguro em colocar a senha em texto-plano dentro de um arquivo?
- …
Ele não soube o que responder. Falei pra ele utilizar a troca de chaves. Com esse método, as máquinas possuem uma chave pública e uma chave privada que podem ser geradas com o comando ssh-keygen. Neste tutorial estaremos utilizando um usuario chamado “usuario” para executar todo o procedimento, mas isso não impede de você utilizar qualquer usuário ou até o root. Mas nesse caso, lembre-se sempre de substituir os diretórios HOME quando houver referência e o próprio nome de usuário.
Primeiro gere as chaves da seguinte forma:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_rsa): # Aqui ele pergunta onde você quer gerar a chave
Enter passphrase (empty for no passphrase): # Aqui ele pergunta se quer senha na chave (deixe em branco)
Enter same passphrase again: # Aqui ele confirmação da senha (deixe em brando novamente)
Your identification has been saved in /home/usuario/.ssh/id_rsa.
Your public key has been saved in /home/usuario/.ssh/id_rsa.pub.
The key fingerprint is:
b3:12:2e:9b:b7:9b:56:f2:ba:fa:d7:71:74:74:99:b2 usuario@desktop-brandao
No final, dá para ver que ele mostra onde gravou as chaves pública e privada.
Este comando deve ser executado na maquina cliente, neste caso a máquina que vai enviar os arquivos. Verificando o arquivo ~/.ssh/id_rsa.pub (no cliente), teremos algo parecido com o exibido abaixo:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwN3WxdXANQxGW+gev3yrQKFzdpyuypmJGRQh6k
khB+axeCf/oQQTopHQPSJDpMtrWAXK8ZrYSlOgtLZQjjk0U1UDzYJ1Qcpq9Fh9b8NQBZLYuYimbFHuo
HZ1VGgmVkoaAQ31bKuaIK9Z2LvnR+YKPH6hPaDS9lCyW0xRAT4xSvK8S7ZrozEZUjQZ4+IMNN/yu5+
zalIzZyqXlRcDk+lV8PfR9p0EXQTaKRrNJz+sD6Yld5Ty7igd6bsGNa/pK6rxY0FLnPX/u4xjmDU1m
VNgFJ8zNcb6ibzv4IUk9xhVRDJKgW4xSNN7LEe2asjVXJ87UU/hkUGTLNGwg5c4hFWZ1w== usuario@desktop-brandao
(Esta é apenas uma linha, quebramos em várias linhas para melhor visualização neste tutorial).
Esta é a chave pública que deve ser adicionada no servidor, no arquivo definido na tag “AuthorizedKeysFile” na configuração /etc/ssh/sshd_config do servidor. Por padrão, este arquivo é o “authorized_keys” dentro do diretório .ssh (notem o ponto) no HOME de cada usuário. Neste exemplo vamos definir a tag AuthorizedKeysFile para utilizar o arquivo /etc/ChavesSSH. Utilizando um editor de texto de sua preferência, acesse o arquivo /etc/ssh/sshd_config e deixe a linha do AuthorizedKeysFile como a seguir:
AuthorizedKeysFile /etc/ChavesSSH
Reinicie o ssh para que as novas configurações sejam aplicadas:
/etc/init.d/sshd restart
Após isso, no servidor, crie o arquivo /etc/ChavesSSH e adicione a chave tirada do arquivo ~/.ssh/id_rsa.pub que está no cliente. Você pode copiar e colar ou transferir o arquivo via scp e concatená-lo (recomendado). No caso de transferir e concatenar, faça algo parecido com isto:
maquina-cliente$ scp ~/.ssh/id_rsa.pub [email protected]:/home/usuario
Enter password:
[...]
maquina-servidor# cat /home/usuario/id_rsa.pub >> /etc/ChavesSSH
(Lembrando de substituir o 192.168.0.254 pelo IP remoto do servidor).
Ao fazer isto, a chave do cliente estará dentro do arquivo de chaves autorizadas à fazer logins na conta, ou seja, se você tiver a chave privada (~/.ssh/id_rsa) correspondente, poderá se logar com qualquer usuário no sistema remoto. Na máquina cliente, execute o comando:
$ ssh-l root
Pronto, você verá que se logou na máquina servidor sem precisar digitar senha :)
Você também pode incrementar esta configuração. Por exemplo, se você quiser que esta chave só seja aceita se partir de uma determinada origem de IP (Ex.: 192.168.0.1), você pode adicionar no arquivo /etc/ChavesSSH a opção “from”, como mostrado na linha a seguir:
from="192.168.0.1" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwN3WxdXANQxGW+gev3yrQKFzdpyuypmJGRQh6k
khB+axeCf/oQQTopHQPSJDpMtrWAXK8ZrYSlOgtLZQjjk0U1UDzYJ1Qcpq9Fh9b8NQBZLYuYimbFHuo
HZ1VGgmVkoaAQ31bKuaIK9Z2LvnR+YKPH6hPaDS9lCyW0xRAT4xSvK8S7ZrozEZUjQZ4+IMNN/yu5+
zalIzZyqXlRcDk+lV8PfR9p0EXQTaKRrNJz+sD6Yld5Ty7igd6bsGNa/pK6rxY0FLnPX/u4xjmDU1m
VNgFJ8zNcb6ibzv4IUk9xhVRDJKgW4xSNN7LEe2asjVXJ87UU/hkUGTLNGwg5c4hFWZ1w== usuario@desktop-brandao
(Mais uma vez, lembre-se que esta é apenas uma linha
Repare que apenas foi adicionada a opção from=”192.168.0.1″ no inicio da linha.
Outra opção legal é limitar a utilização do usuário apenas à comandos, evitando assim que o usuário ganhe uma shell na máquina. Deste modo, o usuário poderá apenas executar comandos remotos ou utilizar o scp para transferência de arquivos. A configuração é simples, basta adicionar a opção no-pty no início da linha no /etc/ChavesSSH, deixando-a como a seguir:
no-pty,from="192.168.0.1" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwN3WxdXANQxGW+gev3yrQKFzdpyuypmJGRQh6k
khB+axeCf/oQQTopHQPSJDpMtrWAXK8ZrYSlOgtLZQjjk0U1UDzYJ1Qcpq9Fh9b8NQBZLYuYimbFHuo
HZ1VGgmVkoaAQ31bKuaIK9Z2LvnR+YKPH6hPaDS9lCyW0xRAT4xSvK8S7ZrozEZUjQZ4+IMNN/yu5+
zalIzZyqXlRcDk+lV8PfR9p0EXQTaKRrNJz+sD6Yld5Ty7igd6bsGNa/pK6rxY0FLnPX/u4xjmDU1m
VNgFJ8zNcb6ibzv4IUk9xhVRDJKgW4xSNN7LEe2asjVXJ87UU/hkUGTLNGwg5c4hFWZ1w== usuario@desktop-brandao
(Mais uma vez, lembre-se que esta é apenas uma linha
Note que também foi adicionada uma vírgula entre a tag no-pty e a tag from, ou seja, você pode combinar várias opções separando-as com vírgula.
Outras opções legais para se adicionar no arquivo de chaves podem ser obtidas na sessão 8 do man do sshd:
$ man 8 sshd
2. Configurações avançadas
O arquivo sshd_config oferece diversas opções que podem nos ajudar no dia-a-dia. Coloquei aqui as opções que mais me chamam atenção.
2.1. Port
Utilidade: A opção port serve para definir em qual porta o daemon do ssh (sshd) aceita novas conexões.
Comentário: Apesar de muitas pessoas acreditarem que trocando a TAG Port para uma outra porta estarão assegurando que o ssh ficara seguro, isso apenas causa uma falsa impressão de segurança, pois utilizando um simples port-scanning com o nmap ou programas similares, podemos verificar em que porta o daemon está escutando e qual a versão do serviço, utilizando a opção -sV
Exemplo:
# nmap localhost -sV
222/tcp open ssh OpenSSH 4.7 (protocol 2.0)
Veja que mesmo estando na porta 222, o nmap conseguiu ver que o serviço rodando na porta é o ssh.
2.2. ListenAddress
Utilidade: Esta opção é útil para definir um endereço IP específico em que o daemon ficará escutando no servidor, caso o servidor possua mais de uma interface de rede (física ou virtual).
Comentário: Esta opção é legal para servidores que ficam ligados diretamente a Internet, pois você pode definir que o daemon do ssh aceitará somente conexões oriundas da sua rede local.
Exemplo:
ListenAddress 192.168.0.254
2.3. LogLevel
Utilidade: Esta opção nos oferece diversos níveis de log para analisarmos.
Comentário: Os níveis disponíveis nesta opção são as seguintes: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, e DEBUG3. A opção que vem habilitada por padrão é a INFO, porém a que mais me chama a atenção é a DEBUG, que fornece todas as informações de possamos desejar.
2.4. PermitRootLogin
Utilidade: Esta opção serve para permitir ou não que o usuário root possa se logar via ssh.
Comentário: Esta opção é legal para evitar ataques de força bruta, pois o usuário root existe em qualquer sistema Linux/Unix e a maioria das tentativas de invasão tentam se logar como root.
2.5. AllowGroups
Utilidade: Esta opção nos permite estabelecer um grupo de usuários que poderão efetuar login via ssh.
Comentário: Esta opção é muito legal para definir, por exemplo, um grupo de administração do servidor e permitir o login via ssh somente dos usuários pertencentes à um certo grupo.
Exemplo:
AllowGroups admin
2.6. AuthorizedKeysFile
Utilidade: Como visto no primeiro tópico deste tutorial, esta opção é utilizada para definir o arquivo com as chaves públicas dos usuários que poderão efetuar login sem precisar digitar a senha.
Comentário: Esta opção é muito útil para pessoas que administram muitos servidores com senhas diferentes, ao invés de ter que decorar todas as senhas ele pode exportar a sua chave pública e efetuar o login via troca de chaves. Por padrão este arquivo vem definido como ~/.ssh/authorized_keys, porém você pode definir qualquer arquivo como arquivo de chaves, como vimos no primeiro tópico deste tutorial.
Termino por aqui e espero que este tutorial seja útil.
quinta-feira, 19 de março de 2009
Como perder uma ótima oportunidade de emprego.
--
"A Cisco me ofereceu um emprego, e agora eu preciso pesar a utilidade de um gordo salário contra viajar todo dia pra San Jose e detestar o trabalho"
--
Logo ele recebeu uma resposta bem legal de um advogado da Cisco.
--
“Quem é o gerente de contração(?). Tenho certeza que eles adorariam saber que você vai odiar o trabalho."
--
Hehe Desgraça pouca é bobagem
Detalhes em:
http://ciscofatty.com/ruin-a-fatty-cisco-job-with-1-tweet/
By CleBeer |_b