segunda-feira, 5 de outubro de 2009

OWASP AppSec Brasil 2009

CHAMADA PARA PARTICIPAÇÃO

Conferência Internacional de Segurança de Aplicações, organizada e promovida pela comunidade TI-controle e pelo Centro de Informática da Câmara dos Deputados, em parceria com o OWASP, Capítulo Brasil, e com apoio da Universidade de Brasília (UnB)

O Centro de Informática da Câmara dos Deputados e a Comunidade TI-Controle convidam a todos a participarem da Conferência Internacional de Segurança de Aplicações (AppSec Brasil 2009), que ocorrerá na Câmara dos Deputados (Brasília, DF) de 27 a 30 de outubro de 2009.

Haverão mini-cursos nos dias 27 e 28 de outubro, seguidos de sessões plenárias de trilha única nos dias 29 e 30 de outubro de 2009.


Keynotes

Dr. Gary McGraw, CTO da Cigital
O Modelo de Maturidade Building Security In (BSIMM)

Jason Li, Aspect Security
Ágil e Seguro: É possível fazer os dois?

Dinis Cruz, OWASP Board
Apresentação do Projeto OWASP

Kuai Hinojosa, NY University e OWASP
Implementando Aplicações Web Seguras Usando Recursos do OWASP


Palestras

A Conferência contará com palestras técnicas que tratarão diversos aspectos de Segurança de Aplicações. Os temas incluem:

  • Segurança de aplicações web
  • Otimização de gastos com segurança
  • SQL Ownage
  • ferramentas.


Mini-cursos

A Conferência contará também com 5 mini-cursos:

  • Gestão de Riscos de Segurança Aplicada a Web Services
  • Segurança Web: Técnicas para Programação Segura de Aplicações
  • Segurança Computacional no Desenvolvimento de Web Services
  • Tecnologias de Segurança em Web Services
  • Hands on Web Application Testing using the OWASP Testing Guide.


Local

A Conferência ocorrerá na Câmara dos Deputados, em Brasília. As plenárias serão no auditório Nereu Ramos, no Anexo II e os mini-cursos serão no Centro de Formação, Treinamento e Aperfeiçoamento.


Inscrições

A participação na Conferência será gratuita, mas, devido à limitação de lugares, será necessário inscrever-se previamente.

As inscrições estarão abertas a partir do dia 29/10/2009 na URL: http://www.camara.gov.br/appsecbrasil2009


Informações

Para maiores informações, favor consultar os sites abaixo ou enviar email para appsec.brasil@camara.gov.br

Inscrições e informações sobre a conferência: http://www.camara.gov.br/appsecbrasil2009
Comunidade TI-Controle: http://www.ticontrole.gov.br
Câmara dos Deputados:
http://www.camara.gov.br

segunda-feira, 28 de setembro de 2009

Hackers To Hackers Conference (H2HC)

Hackers To Hackers Conference (H2HC) é uma conferência organizada por pessoas que trabalham ou que estão diretamente envolvidas com pesquisas e desenvolvimento na área de segurança da informação, cujo principal objetivo é permitir a disseminação, discussão e a troca de conhecimento sobre segurança da informação entre os participantes e também entre as empresas envolvidas no evento. Com treinamentos e palestras apresentadas por membros respeitados do mundo corporativo, grupos de pesquisas e comunidade underground, neste ano a conferência promete demonstrar técnicas que nunca foram vistas ou discutidas com o público anteriormente.

E por que realizar uma conferência onde podem ser demonstradas novas técnicas de ataque, novas ferramentas e pontos de inseguranças de sistemas? Porque queremos mostrar esse tipo de informação para o público, principalmente para pessoas cujo trabalho é proteger e aumentar a segurança dos sistemas e fazer com que eles entendam melhor como os outros atacam os seus computadores. As pessoas que atacam normalmente conhecem diversas técnicas e é importante que analistas de segurança, auditores de sistemas entre outras pessoas responsáveis pela segurança também saibam como se defender.

Como pode ser percebido ao acessar os melhores fóruns, sites e listas de e-mail sobre o assunto, encontrar falhas de segurança não é uma tarefa muito difícil. Para cada falha descoberta por um pesquisador e enviada a um fabricante, provavelmente existem outras que já são conhecidas por pesquisadores que não notificam o fabricante. E nós acreditamos que a melhor maneira para se proteger contra essas falhas desconhecidas é entender profundamente como os problemas acontecem e criar mecanismos de segurança para impedir uma classe de falhas, e não apenas aplicar as correções publicadas pelo fabricante e esperar que ninguém ataque seu sistema com 0day.


Não deixem de participar.

segunda-feira, 21 de setembro de 2009

Participação na Ekoparty

Bem, depois de um bom tempo estou de volta. =D

Estive participando na ultima semana da ekoparty ( www.ekoparty.com.ar), uma conferencia argentina sobre segurança da informação. A conferencia contou com quase 500 participantes e é bem parecida com a nossa H2HC (www.h2hc.org.br) que a propósito acontecerá nos dias 28 e 29 de novembro deste ano. Mas voltando a ekoparty a conferencia este ano contou com palestras com um ótimo nível de qualidade. Dentre elas podemos destacar as seguintes:

- Pedram Amini - Mostrame la guita! Adventures in buying vulnerabilities.

Que comentou sobre como é o mercado de compra e venda de vulnerabilidades, na talk o Pedram comentou que existem pessoas no Brasil que vendem vulnerabilidades mas não consegui falar com ele para saber quem são esses caras. =p


- Deviant Ollam - Ten Things Everyone Should Know About Lockpicking & Physical Security

Essa foi uma das palestras que mais me chamou a atenção, além de mostrar diversos tipos diferentes de cadeados/fechaduras o Deviant nos mostrou como abri-las, a conferencia também contou com um stand de lockpicking onde você podia comprar um kit de lockpicking com 7 ferramentas por 100 pesos argentinos (mais ou menos 50 Reais)


- Alfredo Ortega/Anibal Sacco - Deactivate The Rootkit

Essa palestra foi muito interessante pois eles demonstraram como implantar alguns rootkits na BIOS das maquinas e teve demonstração tanto em maquinas virtuais quanto em maquinas reais.

- Moxie Marlinspike - More Tricks For Defeating SSL In Practice

Essa foi com certeza a palestra mais esperada, o Moxie demonstrou como a criação de um certificado ssl junto a uma entidade certificadora é falho e como podemos enganar os usuários que utilizam ssl utilizando a ferramenta sslstrip.

Bem além do alto nível de palestrantes a conferencia contou com uma presença forte da comunidade brasileira de Security, apesar de infelizmente não termos nenhum palestrante brasileiro este ano.

By CleBeeR

quinta-feira, 6 de agosto de 2009

Testando o Nping

Hoje comecei a testar o nping a nova ferramenta do Nmap (insecure.org) para gerar pacotes. O Nping é inspirado no famoso hping uma ferramenta que permite que você consiga gerar diversos tipos de pacote através de vários protocolos permitindo que o usuário altere diversos campos do cabeçalho do pacote, já o Nping pode ser utilizado como uma simples ferramenta de ping para testar hosts ativos e também como um gerador de pacotes para testes de IDS, ARP poisoning, ataques DoS, traçar rotas, etc...
Como o Nping ainda é beta vamos baixa-lo via svn. Caso você não possua o comando svn você deve intalar o subversion (http://subversion.tigris.org/)

Baixando o Nping

svn co --username guest --password "" svn://svn.insecure.org/nmap-exp/luis/nping

após terminar o download basta um "cd nping" e executar o famoso:

./configure && make && make install


Pronto com o Nping instalado você ja pode utilizar o "man nping" =p
Segue alguns exemplos de utilização do Nping:

----------
/* Fazer conexão TCP em um host*/
nping --tcp-connect google.com

/* Fazer conexão TCP em varios hosts */
nping --tcp-connect google.com ask.com yahoo.com bing.com

/* Enviar um pacote UDP com 100 bytes de dados randômicos */
nping --udp google.com -p 53 --data-length 100

/* Tenta conectar em um range de portas TCP*/
nping --tcp-connect google.com -p75-85 -c 1

---/* opções que precisam de direitos de root*/

/* Envia pacote UDP com checksum falso e porta de origem 1337 */
sudo nping --udp --badsum --source-port 1337 -p 53 google.com -v6

/*Envia requisição ARP para o IP 192.168.1.1*/
sudo nping --arp 192.168.1.1

/*Envia 300 pacotes TCP a uma taxa de 100pct/seg*/
sudo nping --tcp google.com --rate 100 -c 300

/*Envia pacotes ICMP com os campos ID e Seq customizados*/
sudo nping google.com --icmp --icmp-type echo --icmp-id 31337 --icmp-seq 1

/* Envia um ICMP echo reply*/
sudo nping google.com --icmp --icmp-type echo-reply

----------


Bem.. Agora e só brincar

By CleBeer.... |_b

segunda-feira, 6 de julho de 2009

meu n0t3


Só pra mostrar meus adesivos... =p

bu CleBeeR

sexta-feira, 5 de junho de 2009

FreeBSD com IPFW

Há uns 2 anos atraz eu postei esse artigo no meu antigo blog e hoje rodando pela net achei ele no site do PfSense... então ai vai o "re-blog".

O IPFIREWALL é o filtro de pacotes nativo do FreeBSD, sendo também chamado de IPFW, que é a interface para controle do IPFIREWALL. O IPFIREWALL faz o monitoramento de cada pacote em cada conexão feita à máquina, determinando por meio das regras definidas pelo IPFW qual é o tratamento dado a estes pacotes. As regras são lidas de cima para baixo, e podem determinar se o pacote será liberado, bloqueado, encaminhado etc.

Atualmente podemos ativar o suporte a IPFW2. O IPFW2 é uma nova versão do IPFW, com maior flexibilidade no formato das regras e algumas funcionalidades a mais, entre elas: suporte a regras não específicas para TCP ou UDP com número de porta, suporte a blocos OR, keepalives para sessões stateful e filtragem por cabeçalho MAC.
Ativando o IPFW2

Para habilitar o suporte ao ipfirewall e o ipfw2, devemos seguir alguns passos. Inicialmente, o próprio ipfw deverá ser recompilado, para suportar ipfw2. Execute os seguintes comandos:

# cd /usr/src/sbin/ipfw
# make clean
# make -DIPFW2
# make -DIPFW2 install

Para que quando formos atualizar o sistema e executar um "make buildworld" o make saiba deste detalhe no momento de compilar o ipfw, adicione a linha abaixo ao arquivo /etc/make.conf:

IPFW2=TRUE

Edite o arquivo de configuração do kernel e insira as seguintes linhas, descritas abaixo:

options IPFIREWALL
options IPFW2
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_FORWARD
options IPDIVERT

Primeira linha: ativa o ipfirewall, carregando-o estaticamente no kernel.
Segunda linha: ativa o ipfw2 propriamente dito.
Terceira linha: ativa o suporte a log no ipfirewall. O log é feito via syslog.
Quarta linha: define um limite para o log de cada regra. O padrão é 100, dessa forma cada regra terá até 100 ocorrências no log. Isto é feito para evitar o comprometimento do sistema em caso de ataques como negação de serviço.
Quarta linha: ativa o suporte a encaminhamento de pacotes.
Quinta linha: ativa o suporte a redirecionamento de porta através de socket "divert".


Após todas estas configurações, compile e reinstale o kernel, e reinicie a máquina. Isto deverá ser feito no console, pois após reiniciar o firewall será carregado, e como não foi definida nenhuma regra irá bloquear tudo. Uma forma de contornar isso, caso não seja possível estar junto a máquina, é inserir as seguintes linhas no arquivo /etc/rc.conf:

firewall_enable="YES"
firewall_type="OPEN"

Isto fará com que na inicialização seja carregada a configuração "OPEN" do arquivo /etc/rc.firewall. Esta configuração irá adicionar uma regra que libera todo o tráfego.

Após reiniciada a máquina, digite o seguinte comando:

# ipfw list

Será mostrada a lista de regras ativas, que de acordo com a configuração OPEN do arquivo /etc/rc.firewall deverá ser a seguinte:

00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
65000 allow ip from any to any
65535 deny ip from any to any

Neste momento, todos os pacotes que entram e saem da máquina estão passando por estas regras, na ordem em que estão, definida pelo número da regra (que vai de 1 a 65535). A primeira regra que for atendida irá definir o que fazer com o pacote, e as demais são geralmente ignoradas (em alguns casos específicos o pacote é reinjetado).

Regra 100: permite que qualquer pacote IP trafegue na interface lo0 (localhost).
Regra 200: bloqueia o tráfego de qualquer origem para a rede 127.0.0.0/8 (localhost).
Regra 300: bloqueia o tráfego com origem na rede 127.0.0.0/8 para qualquer destino.
Regra 65000: permite qualquer tráfego.
Regra 65535: bloqueia qualquer tráfego.

Estas regras estão no formato do ipfw1, que também é suportado, para compatibilidade, pelo ipfw2. Lembre-se que todas estas regras foram definidas pelo rc.firewall, exceto a regra de número 65535 (máximo), que é o padrão do ipfirewall, bloquear tudo. Caso seja conveniente que o padrão do firewall seja liberar tudo, ou seja, a regra 65535 seria "allow all from any to any", então deve ser adicionada a seguinte linha na configuração do kernel:

options IPFIREWALL_DEFAULT_TO_ACCEPT



Comando IPFW

O comando ipfw, de uma forma sucinta, possui os seguintes parâmetros:

ipfw [-q] add regra -> Adiciona a regra (ver o formato abaixo). A opção "-q" indica que deverá ser uma operação "silenciosa", não gerando saídas nem relatando as ações.

ipfw delete número_regra -> Remove a regra com o número especificado.

ipfw list -> Lista as regras ativas.

ipfw [-t -d] show -> Lista as regras ativas, incluindo os contadores número de pacotes e número de bytes. O parâmetro -t inclui ainda a data/hora da última ocorrência. O parâmetro -d lista também as regras dinâmicas.

ipfw [-q] flush -> Deleta todas as regras.

ipfw [-q] zero -> Zera todos os contadores (número de pacotes, número de bytes, número de logs e timestamp).

ipfw [-q] resetlog -> Zera o contador número de logs.



Formato das Regras

As regras que vimos anteriormente, como foi mencionado, estão no formato do ipfw1, que atualmente também é aceito pelo ipfw2. Pode-se usar este formato para escrever as regras, no entanto é bom se habituar com o novo formato. Quando forem acrescentadas regras no formato novo, o ipfw2 irá automaticamente inserir as palavras "ip from any to any", que fazem parte do formato antigo, e não irão mudar em nada a regra, já que não impões nenhuma restrição, e quem vai ditar a especificação dos pacotes são as opções, explicadas adiante. Este esquema é feito para manter uma certa compatibilidade com o ipfw1.

A partir de agora, já podem ser definidas regras para controlar o Firewall. É muito importante se familiarizar com a sintaxe e forma de uso do ipfw, que será o único comando utilizado para controlar o ipfirewall. A formato das regras é o seguinte:

[número_regra] [prob probalilidade] ação [log [logamount número] ] corpo_regra

[número_regra]
Varia de 1 a 65535 e indica a seqüência em que as regras serão processadas. A número 65535 é reservado para a ação padrão do firewall, que será bloquear ou permitir tudo, dependendo da configuração do kernel. Se não for inserido um número de regra ela será automaticamente a última antes da 65535. Se forem inseridas duas ou mais regras com o mesmo número, será obedecida a ordem em que foram inseridas.

[prob probabilidade]
Define uma probabilidade para aplicar a regra. Varia de 0 a 1.


ação

allow
Sinônimo de accept, pass e permit. Libera o tráfego do pacote e termina a leitura das regras.

check-state
Checa o pacote contra um conjunto de regras dinâmico.

count
Apenas atualiza o contador desta regra. As demais regras continuam a ser lidas.

deny
Sinônimo de drop, descarta o pacote e termina a leitura das regras.

divert porta
Redireciona o pacote para a porta especificada, utilizando um socket "divert". Pode ser especificado número ou nome, veja /etc/services.

fwd ip[,porta]
Sinônimo de forward, encaminha o pacote para o ip especificado. Se o ip for local será encaminhado para a porta especificada, se o ip não for local a porta será ignorada. O pacote não é alterado, e isto inclui o ip de destino, então se o pacote for encaminhado para outro host provavelmente será rejeitado. Caso seja encaminhado para um ip local, desta máquina, o socket que irá receber o pacote terá o seu endereço alterado para coincidir com o endereço de destino do pacote, aceitando desta forma o mesmo.

pipe número
Passa o pacote através de um "pipe" dummynet, para controle de tráfego.

queue número
Passa o pacote para uma "queue" dummynet, para controle de tráfego utilizando WF2Q+.

reset
Descarta o pacote, e se o mesmo for TCP tenta enviar um TCP RST.

skipto número
Pula para a regra de número especificado.

tee porta
Aceita o pacote e envia uma cópia do mesmo para a porta especificada, via socket "divert".

unreach código
Descarta o pacote, e tenta enviar uma resposta "ICMP unreachable" com o código especificado. O código deve ser entre 0 e 255, ou alguma destas palavras chave: net, host, protocol, port, needfrag, srcfail, net-unknown, host-unknown, isolated, net-prohib, host-prohib, tosnet, toshost, filter-prohib, host-precedence ou precedence-cutoff.


[log [logamount número] ]
Caso mencionada a palavra log, cada vez que um pacote coincidir com esta regra será feito um log, através do syslog. Caso seja inserido logamount número, este será o limite de vezes que será feito o log para esta regra. O valor 0 (zero) significa sem limites. Caso não seja inserido logamount, o padrão é o limite que foi configurado no kernel.


corpo_regra
Contém uma ou mais exigências que o pacote precisa coincidir para a regra ser atendida. Essa especificação pode incluir endereço ip de origem, endereço ip de destino, porta de origem, porta de destino, protocolo, interface de rede de entrada, interface de rede de saída etc. O corpo da regra pode possuir uma ou mais opções. Essas opções podem ser precedidas de "not", como negação, ou serem agrupadas em blocos OR, entre chaves, por exemplo: { dst-port 50 or dst-port 51 or not src-port 52 }.

A seguir as opções mais importantes:

// comentário
Insere o texto como sendo um comentário na regra.

dst-ip endereço
Endereço IP de destino do pacote.

dst-port porta
Porta(s) de destino do pacote. Se for especificada mais de uma porta, separar por vírgula (50, 51, 52), ou em faixa de portas (50-60).

established
Se o pacote tiver os bits RST ou ACK.

frag
fragmentos de pacotes, não sendo o primeiro fragmento.

gid grupo
Pacotes TCP ou UDP enviados ou recebidos pelo grupo. O grupo pode ser especificado pelo nome ou pelo GID.

icmptypes tipo
Tipo(s) de pacotes ICMP. Se for mais de um, separar por vírgula. Os tipos podem ser: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) e address mask reply (18).

in | out
Pacotes de entrada ou de saída. Note que isto significa que os pacotes estão entrando ou saindo da máquina, então mesmo que um pacote venha da rede interna, estará entrando na máquina antes de sair.

keep-state
Quando um pacote coincidir com uma regra que tiver esta opção, será criada uma regra dinâmica, cujo comportamento será coincidir o tráfego bidirecional entre este ip/porta de origem e ip/porta de destino, no mesmo protocolo. A regra dinâmica expira após um certo tempo. Dessa forma, pode-se definir uma regra "check-state" anterior a esta, liberando este fluxo de pacotes, e teremos um firewall "stateful".

limit {ip-origem | porta-origem | ip-destino | porta-destino} número
Serão permitidas apenas o número especificado de conexões com os parâmetros especificados.

mac mac-destino mac-origem
Pacotes com o endereço MAC de destino e/ou de origem especificados. Se não for especificado algum deverá ser usada a palavra "any", para coincidir com todos os endereços.

proto protocolo
Pacotes com o protocolo (IP) especificado. Veja /etc/protocols.

recv interface | xmit interface | via interface
Pacotes recebidos pela interface de rede especificada (recv xl0), pacotes transmitidos pela interface especificada (xmit fxp0), ou pacotes passando pela interface, independentemente de entrar ou sair (via xl0). Quando xmit for utilizado é requerida a opção "out", já que o pacote estará saindo.

setup
Pacotes com o bit SYN mas sem o bit ACK.

src-ip endereço
Endereço IP de origem do pacote.

src-port porta
Porta(s) de origem do pacote.

tcpflags flags
Flags dos pacotes TCP, separadas por vírgula. As possíveis são: fin, syn, rst, psh, ack e urg. A negação pode ser feita por um "!".

uid usuário
Pacotes TCP ou UDP enviados ou recebidos pelo usuário. O usuário pode ser especificado pelo username ou pelo UID.

vrrevpath
Pra pacotes de entrada, é feita uma consulta ao endereço de origem na tabela de roteamento. Se a interface na qual o pacote entrou é a mesma de saída especificada pela rota, então a regra coincide. Isto pode ser utilizado para criar regras anti-spoofing. Os pacotes de saída não são submetidos à verificação.



Firewall Stateful

O funcionamento stateful permite que o firewall crie regras dinâmicas para fluxos específicos de pacotes. Pode-se fazer algumas coisas interessantes, como por exemplo manter o firewall fechado, bloqueando todo tráfego de fora para dentro e permitindo apenas que pacotes da rede interna saiam para a rede externa, passando por uma regra "keep-state". Assim, cada conexão feita de dentro para fora irá criar uma regra dinâmica, que irá liberar aquele tráfego nas duas direções, permitindo que os dados de resposta, por exemplo, uma página web que um usuário acessou, cheguem até a máquina do usuário, na rede interna.
As regras dinâmicas possuem as seguintes informações: protocolo, endereço IP e porta de origem e endereço IP e porta de destino. Elas irão permitir o tráfego bidirecional, ou seja, mesmo que os endereços de origem e destino se invertam. Isto é uma das coisas que possibilita criar o que foi descrito acima. As regras dinâmicas possuem um tempo de vida limitado, que é determinado pelas variáveis net.inet.ip.fw.dyn*, do sysctl (maiores informações vide a man page do sysctl). Estas variáveis também determinam o número máximo de regras dinâmicas, entre outros.
Uma regra dinâmica é criada cada vez que um pacote coincide com uma regra que possua as opções keep-state ou limit, não sem antes checar se a regra já existe. As regras dinâmicas são checadas na ocorrência da ação check-state.

Exemplo:

# ipfw add 1000 check-state
# ipfw add 1100 allow tcp from 10.10.0.0/16 to any setup keep-state
# ipfw add 1200 deny tcp from any to any

Este conjunto de regras irá, para cada pacote:
1. Checar se existe alguma regra dinâmica que permita o tráfego do mesmo;
2. Caso o pacote seja da rede 10.10.0.0/16 e tiver o bit SYN, mas não o bit ACK (indicando desta forma um início de conexão), irá permitir o tráfego e criar uma regra dinâmica;
3. Bloquear qualquer outro tráfego.



Log

Para direcionar os logs do ipfw para o arquivo /var/log/ipfw/ipfw.log, primeiramente crie este diretório e este arquivo:

# mkdir /var/log/ipfw
# touch /var/log/ipfw/ipfw.log
# chmod -R 600 /var/log/ipfw

Então adicione as seguintes linhas ao arquivo /var/log/syslog.conf:

!ipfw
*.* /var/log/ipfw/ipfw.log

Após isso, reinicie o syslog, através do comando "killall -HUP syslog". Talvez seja interessante também criar um script que faça a rotação deste log e agendar no Cron, ou adicionar uma entrada no newsyslog.conf, para que o arquivo não fique demasiado grande.



Arquivo de Regras

Não é recomendado editar o arquivo /etc/rc.firewall, que vem com o sistema. O seu conjunto de regras deverá ficar em um arquivo separado, exclusivo para isso. Este arquivo poderá ser um script shell ou poderá ser apenas uma listagem de regras, que o ipfw irá interpretar. O tipo de arquivo é uma escolha pessoal, e não fará diferença no funcionamento do firewall.


Arquivo com listagem de regras

Deverá ser criado um arquivo, por exemplo /etc/firewall, com dono root e permissão 600. Neste arquivo serão colocadas as regras, que são iguais às passadas via linha de comando ao ipfw, mas sem o comando "ipfw" no começo. Exemplo:

add 1000 allow src-ip 10.10.0.0/16 dst-ip 192.168.0.0/16

Para efetuar a inicialização destas regras no momento da inicialização, adicione ou modifique as seguintes linhas no /etc/rc.conf:


firewall_enable="YES"
firewall_type="/etc/firewall"
firewall_quiet="YES"

A opção firewall_quiet faz com que seja executado o comando "ipfw -q" ao invés de simplesmente "ipfw", ao ler cada regra do arquivo. Dessa forma ocorrerá uma operação "silenciosa", não gerando saídas na tela. Para interpretar um arquivo deste tipo via linha de comando, simplesmente execute "ipfw /etc/firewall".



Script de regras

No caso de criamos um script shell com as regras, também deverá ser criado um arquivo exclusivo para isso, como por exemplo /etc/firewall.sh, com dono root e permissão 700. O conteúdo deste arquivo pode ser como você quiser, pois trata-se de um script comum. Quando for passar as regras, o comando ipfw deve ser exatamente como se fosse via linha de comando. É recomendado usar a opção "-q", do comando ipfw, em scripts.
Para que o script seja executado na inicialização do sistema, edite o arquivo /etc/rc.conf, remova as linhas (caso existirem) firewall_type e firewall_quiet, mantenha a linha

firewall_enable="YES"

e adicione a seguinte linha:

firewall_script="/etc/firewall.sh"

Deste ponto em diante, cabe a você decidir como deverá ser o comportamento do seu firewall, tendo em vista a que ele se destina. Sugiro a leitura do livro "Building Internet Firewalls", de D. Brent Chapman e Elizabeth D. Zwicky, da editora O'Reilly. Seguem abaixo algumas regras e um script simples, a título de exemplo.



Exemplos de Regras

(não esquecer do comando "ipfw" antes delas):

add 100 allow via lo0
add 200 deny { dst-ip 127.0.0.0/8 or src-ip 127.0.0.0/8 }

Observe os espaços após a "{" e antes da "}". Se não houver este espaço será retornado o seguinte erro:

ipfw in free(): warning: modified (chunk-) pointer

Estas duas regras acima terão o mesmo efeito que as regras abaixo, no formato antigo, descritas anteriormente:

add 100 pass all from any to any via lo0
add 200 deny all from any to 127.0.0.0/8
add 300 deny ip from 127.0.0.0/8 to any

add 1000 allow src-ip 10.10.0.0/16 dst-port 80
add 1100 allow dst-ip 10.10.0.0/16 dst-port 1024-65535

Irá permitir que máquinas da rede 10.10.0.0/16 enviem pacotes com destino a porta 80 e irá permitir que pacotes cheguem até a rede 10.10.0.0/16 com destino a portas entre 1024 e 65535, permitindo por exemplo a resposta de um pedido HTTP.

add 1000 allow proto tcp dst-port ssh recv xl0
add 1100 deny proto tcp dst-port ssh out

Irá permitir que a máquina receba conexões TCP pela interface de rede xl0, à porta do ssh, que é a porta 22, conforme definido no arquivo /etc/services. Também irá negar a saída de qualquer pacote com protocolo TCP e com destino a porta do ssh.

add 1000 check-state
add 1100 allow src-ip 10.10.0.0/16 keep-state
add 1200 deny log ip from any to any

Irá permitir que a rede 10.10.0.0/16 estabeleça qualquer conexão, cujo tráfego de resposta será liberado pelas regras dinâmicas que serão criadas pela regra 1100 e que serão checadas pela regra 1000. Qualquer outro tráfego será bloqueado e logado no arquivo de log.

add 50 deny not vrrevpath in

Irá bloquear ip-spoofing, conforme explicado anteriormente.

add 500 deny log { src-ip 10.0.0.0/8 or dst-ip 10.0.0.0/8 } via xl0
add 510 deny log { src-ip 172.16.0.0/12 or dst-ip 172.16.0.0/12 } via xl0
add 520 deny log { src-ip 192.168.0.0/16 or dst-ip 192.168.0.0/16 } via xl0

Irá proibir o tráfego de pacotes de redes privadas, conforme definido na RFC1918, na interface de rede xl0. Também irá fazer log quando a regra coincidir com algum pacote.

add 100 prob 0.05 deny in

Irá bloquear 5% dos pacotes de entrada, como se houvesse perda de pacotes.


Exemplo de Script

#!/bin/sh

ipfw="/sbin/ipfw -q"

# IP local
ip="10.10.0.5"

# Portas de entrada permitidas
portas="22,53,80"

$ipfw flush
$ipfw add 100 deny log not verrevpath in
$ipfw add 1000 check-state
$ipfw add 1100 allow src-ip $ip keep-state
$ipfw add 1200 allow dst-port $portas in
$ipfw add 65000 deny ip from any to any


By CleBeeR...

quarta-feira, 3 de junho de 2009

Esse frio pede um Choconhaque


Esta semana aqui em São Paulo o frio esta castigando e com esse frio a boa e velha cerveja não desce muito bem. O que fazer? ficar sem beber? isso não..rsrsr no frio o que eu costumo beber é o choconhaque, uma bebida quente que ajuda a manter o corpo aquecido e a mente tranquila..rsrs mas vamos a receita, ele é muito fácil só precisamos de:

Leite condensado
chocolate em pó
conhaque

Como preparar?

Em uma xícara você coloca o leite condensado até a metade da xícara e coloque chocolate em pó a gosto....
misture os dois até parecer uma massa para brigadeiro, depois complete a xícara com o conhaque e misture até ficar com a consistência de uma vitamina, então leve ao micro-ondas por 1 minuto...

Pronto agora é só relaxar e curtir i frio..rsrsr

Ps.
Também existe a receita de choconhaque que vai creme de leite, cocolate meio amargo etc... mas resolvi postar essa pois da menos trabalho para fazer e é mais barata....rsrsr

Happy drinking
By CleBeer |_b

quinta-feira, 28 de maio de 2009

Torne-se um spammer com apenas 20 reais




Caminhando pelo centro de São Paulo vi em uma daquelas barraquinhas que vende
CDs piratas um CD intitulado "45 milhões de emails"... Opa.. interessante hein
perguntei para o garoto que cuidava da barraca o que mais de CD ele possuia nesste mesmo gênero...
Então ele começou a me mostrar...
- CD com detalhes de diversas empresas no estado de São Paulo (inclusive contendo CNPJ e CPF dos sócios)
- CD com o título "como se tornar hacker" (esse deu até medo rsrs) segundo o garoto da barraca ele continha diversas ferramentas para roubo de senha e listas com senhas de emails, msn, perfis de Orkut, etc...
E o que me deu mais medo foi um DVD com o cadastro de todos os CPFs e CNPJs cadastrados na receita federal (esse inclusive contendo dados do imposto de renda das pessoas).
Show de bola vamos ver o que encontramos..rsrs
comprei o CD com os 45 milhoes de emails e o cd com cadastro das empresas paulistas...
Primeiro vamos ver o CD com os emails... será que acho meu email aqui? rsrs
O CD é muito bem organizado, dividido em pessoas físicas e jurídicas, 400 mil emails do IG, mais de 415 mil emails do hotmail mas o meu email não esta em nenhum deles... ufaa!!! alívio...
O interessante do CD com os emails é que também vem vários programinhas pra envio de spam, ops mala direta..rsrs
Agora vamos ao CD com os dados das empresas de São Paulo... o legal é que neste CD você já ganha inteiramente "de grátis" e sem nenhum custo adicional 10 arquivos infectados com trojans....rsrs
Maravilha hein...rsrs Mas vamos ao que interessa... boot na maquina virtual e install no CD.....
Mais uma vez a tensão... será que meu nome esta nesta lista? huahua
Ufaaaa também me safei desta..rsrs mas o legal deste CD é que você pode dar um search pelo nome da empresa e ver a lista de sócios com seus respectivos CPF, data de nascimento, endereço e cargo.. show de bola hein.. prato cheio para as mentes perigosas...
e tudo isso com apenas 20 reais hein..
Agora me vem a seguinte pergunta na cabeça... será que estes CDs tem boa saida? estes CD possuem informações extremamente sigilosas e em poder de pessoas sem escrúpulos podem gerar muito prejuízo e dor de cabeça.
Como se defender destes perigos..rsrsrs

Ps.
Por favor não comprem estes CD para utiliza-los para o mal....


[]s
By CleBeeR |_b

Novo site do Snort


Esta no ar o novo site do snort com novo layout, o novo site vem no ano em que o snort comemora 10 anos de vida com mais de 3.7 milhões de downloads e mais de 244,000 usuários registrados.
Para conferir o novo site acesse:
www.snort.org

By CleBeer
Happy Snorting...

segunda-feira, 25 de maio de 2009

25 de maio é dia Internacional dos Nerd


Para os Nerd e Geeks de plantão, hoje é nosso dia.. 25 de maio é conhecido como dia internacional do orgulho nerd e para curtir ai vão nossos direitos e deveres.

  • Direitos:
  1. O direito de ser ainda mais nerd.
  2. O direito de não sair de casa.
  3. O direito de não gostar de futebol ou de qualquer outro esporte.
  4. O direito de se associar a outros nerds.
  5. O direito de ter poucos (ou nenhum) amigo.
  6. O direito de ter tantos amigos nerds quanto quiser.
  7. O direito de não ter que estar "no estilo".
  8. O direito ao sobrepeso (ou subpeso) e de ter problemas de vista.
  9. O direito de expressar sua nerdice.
  10. O direito de dominar o mundo.
  • Deveres
  1. Ser nerd, não importa o quê.
  2. Tentar ser mais nerd do que qualquer um.
  3. Se há uma discussão sobre um assunto nerd, você tem que dar sua opinião.
  4. Guardar todo e qualquer objeto nerd que você tenha.
  5. Fazer todo o possível para exibir seus objetos nerds como se fosse um "museu da nerdice".
  6. Não ser um nerd genérico. Você tem que ser especialista em algo.
  7. Assistir a qualquer filme nerd na noite de estréia e comprar qualquer livro nerd antes de todo mundo.
  8. Esperar na fila em toda noite de estréia. Se puder ir fantasiado, ou pelo menos com uma camisa relacionada ao tema, melhor ainda.
  9. Não perder seu tempo em nada que não seja relacionado à nerdice.
  10. Tentar dominar o mundo!

E para curtir veja a seguir uns sinais geeks bem legais

Feliz dia dos Nerds.
By CleBeer

quinta-feira, 7 de maio de 2009

Webminar Overview redes e snort (pt_BR)

Caros,
A Dynsec ( http://www.dynsec.com.br ) fará um webminar inicial sobre os topicos abaixo:

- Introdução redes
- Protocolos ( tcp,ip, udp, icmp, http, ssh, smtp, pop3, imap ..... e pequeno correlacionamento com os pré processadores existentes)
- Overview funcionamento snort
- Equipamentos
- Ataques

A idéia é nivelar um pouco todos da lista e mostrar importancia de entendimento de funcionamento e protocolos.

O webminar acontecerá terça feira (12/05) às 20:00h (horário Brasilia) e terá duração de 1 hora. O webminar terá nessa edição como speakers o Marcos Aurélio(Dynsec), Rodrigo Montoro (Dynsec) e eu Cleber Brandão (BRconnection).
Quem se interessar enviar o e-mail para webminar@dynsec.com.br


Happy Snorting!

By Clebeer

segunda-feira, 4 de maio de 2009

Quebrando senhas do MySQL.

Fuçando na Net achei um código bem legal de como quebrar senhas armazenadas no MySQL.
Como isso funciona? As senhas de usuários armazenadas em um banco MySQL (geralmente) são armazenadas em hash, ou seja se eu tenho acesso ao banco e dou um select no campo de password do usuário "fulano" eo resultado seria como a seguir:

mysql> SELECT PASSWORD('fulano');
+--------------------+
| PASSWORD('fulano') |
+--------------------+
| 6f8c114b58f2ce9e |
+--------------------+
Aqui vemos apenas o hash da senha ae entra o código que achei para nos auxiliar a descobrir a senha deste usuário.

executamos o comando (já compilado)

[localhost~] $ ./MysqlCrack 6f8c114b58f2ce9e
Hash: 6f8c114b58f2ce9e
Trying length 3
Trying length 4
Trying length 5
Trying length 6
Found pass: mypass

Aeee a senha do usuário fulano é "mypass"... rsrsrs
Fácil né?
Abaixo segue o código fonte do programa, para compilar basta executar o seguinte comando:
[localhost~]$ gcc -o MysqlCrack MysqlCrac.c

---Corte---
/* This program is public domain. Share and enjoy.
*
* Example:
* $ gcc -O2 -fomit-frame-pointer mysqlfast.c -o mysqlfast
* $ mysqlfast 6294b50f67eda209
* Hash: 6294b50f67eda209
* Trying length 3
* Trying length 4
* Found pass: barf
*
* The MySQL password hash function could be strengthened considerably
* by:
* - making two passes over the password
* - using a bitwise rotate instead of a left shift
* - causing more arithmetic overflows
*/

#include

typedef unsigned long u32;

/* Allowable characters in password; 33-126 is printable ascii */
#define MIN_CHAR 33
#define MAX_CHAR 126

/* Maximum length of password */
#define MAX_LEN 12

#define MASK 0x7fffffffL

int crack0(int stop, u32 targ1, u32 targ2, int *pass_ary)
{
int i, c;
u32 d, e, sum, step, diff, div, xor1, xor2, state1, state2;
u32 newstate1, newstate2, newstate3;
u32 state1_ary[MAX_LEN-2], state2_ary[MAX_LEN-2];
u32 xor_ary[MAX_LEN-3], step_ary[MAX_LEN-3];
i = -1;
sum = 7;
state1_ary[0] = 1345345333L;
state2_ary[0] = 0x12345671L;

while (1) {
while (i < stop) {
i++;
pass_ary[i] = MIN_CHAR;
step_ary[i] = (state1_ary[i] & 0x3f) + sum;
xor_ary[i] = step_ary[i]*MIN_CHAR + (state1_ary[i] << 8);
sum += MIN_CHAR;
state1_ary[i+1] = state1_ary[i] ^ xor_ary[i];
state2_ary[i+1] = state2_ary[i]
+ ((state2_ary[i] << 8) ^ state1_ary[i+1]);
}

state1 = state1_ary[i+1];
state2 = state2_ary[i+1];
step = (state1 & 0x3f) + sum;
xor1 = step*MIN_CHAR + (state1 << 8);
xor2 = (state2 << 8) ^ state1;

for (c = MIN_CHAR; c <= MAX_CHAR; c++, xor1 += step) {
newstate2 = state2 + (xor1 ^ xor2);
newstate1 = state1 ^ xor1;

newstate3 = (targ2 - newstate2) ^ (newstate2 << 8);
div = (newstate1 & 0x3f) + sum + c;
diff = ((newstate3 ^ newstate1) - (newstate1 << 8)) & MASK;
if (diff % div != 0) continue;
d = diff / div;
if (d <> MAX_CHAR) continue;

div = (newstate3 & 0x3f) + sum + c + d;
diff = ((targ1 ^ newstate3) - (newstate3 << 8)) & MASK;
if (diff % div != 0) continue;
e = diff / div;
if (e <> MAX_CHAR) continue;

pass_ary[i+1] = c;
pass_ary[i+2] = d;
pass_ary[i+3] = e;
return 1;
}

while (i >= 0 && pass_ary[i] >= MAX_CHAR) {
sum -= MAX_CHAR;
i--;
}
if (i < 0) break;
pass_ary[i]++;
xor_ary[i] += step_ary[i];
sum++;
state1_ary[i+1] = state1_ary[i] ^ xor_ary[i];
state2_ary[i+1] = state2_ary[i]
+ ((state2_ary[i] << 8) ^ state1_ary[i+1]);
}

return 0;
}

void crack(char *hash)
{
int i, len;
u32 targ1, targ2, targ3;
int pass[MAX_LEN];

if ( sscanf(hash, "%8lx%lx", &targ1, &targ2) != 2 ) {
printf("Invalid password hash: %s\n", hash);
return;
}
printf("Hash: %08lx%08lx\n", targ1, targ2);
targ3 = targ2 - targ1;
targ3 = targ2 - ((targ3 << 8) ^ targ1);
targ3 = targ2 - ((targ3 << 8) ^ targ1);
targ3 = targ2 - ((targ3 << 8) ^ targ1);

for (len = 3; len <= MAX_LEN; len++) {
printf("Trying length %d\n", len);
if ( crack0(len-4, targ1, targ3, pass) ) {
printf("Found pass: ");
for (i = 0; i < len; i++)
putchar(pass[i]);
putchar('\n');
break;
}
}
if (len > MAX_LEN)
printf("Pass not found\n");
}

int main(int argc, char *argv[])
{
int i;
if (argc <= 1)
printf("usage: %s hash\n", argv[0]);
for (i = 1; i < argc; i++)
crack(argv[i]);
return 0;
}
---Corte---

Aprecie com moderação... =D

By CleBeer |_b

quinta-feira, 30 de abril de 2009

OWASP AppSec Brazil 2009 - Brasília, 27-30 de outubro de 2009

Tenho o prazer de anunciar que a Conferência Internacional sobre Segurança de Aplicações, a ser realizada nos dias 27 a 29 de outubro de 2009 nas dependências da Câmara dos Deputados, em Brasília, DF é agora o primeiro OWASP AppSec Brazil 2009. Isso é uma vitória do Capítulo OWASP Brasil que está tentando trazer o evento para o nosso país desde novembro de 2008 e finalmente conseguiu discutir o assunto com todos os envolvidos e conseguir a aprovação necessária para isso.

A Conferência será promovida pelo OWASP Brasil com o suporte da Comunidade TI-Controle para tratar os diferentes assuntos relacionados a Segurança de Aplicações, tais como:

  • Desenvolvimento seguro
  • Segurança e arquitetura de software
  • Processos de desenvolvimento de sistemas seguros
  • Ferramentas para análise de segurança de aplicações
  • Bibliotecas e frameworks de segurança para aplicações web
  • Auditoria e testes de segurança em aplicações
  • Metodologias gerenciais para melhoria da segurança no desenvolvimento de software
  • Análise de ataques a aplicações
  • Avaliação de riscos de negócio em aplicações web
  • Segurança de web services

A Conferência terá dois dias de treinamentos (27 e 28 de outubro) seguidos de dois dias de palestras (29 e 30 de outubro). As chamadas de trabalho serão divulgadas neste fim de semana. A página com as informações relacionadas está disponível na Wiki da OWASP.


Retirado do blog do Camargo Neves

http://camargoneves.com

terça-feira, 28 de abril de 2009

[INFORME] Cursos gratuitos

o Pontão de Cultura Coletivo Digital estará oferecendo oficinas gratuitas :

TÉCNICO EM SISTEMAS LINUX
Data: 04 à 08 de maio de 2009.
Horário: das 08 hs às 12 hs
.

Público-Alvo: Pessoas que já possuem um conhecimento básico de software e hardware, mas que são iniciantes e interessadas em aprender a utilizar o sistema operacional Linux como ferramenta do dia-a-dia.


EDIÇÃO DE IMAGENS - GIMP
Data: 11 à 15 de maio de 2009.
Horário: das 14 hs às 18 hs
.

Público-Alvo: Pessoas que queiram manipular imagens com uso do computador.
Recorte, edição, fusão e tratamento de imagens com conceitos básicos de composição serão os conteúdos aplicados nesta oficina.


Os cursos serão aplicados na sede do Coletivo Digital.
Reserve sua vaga pelo telefone.

Rua Cônego Eugênio Leite, 883 - Pinheiros - São Paulo/SP - CEP: 05414-012 - Telefone: (11) 3083-5134.

segunda-feira, 27 de abril de 2009

Teste de infecção pelo conficker via web

O Conficker é o malware do momento, temos ouvido muita coisa sobre ele na Internet, mas a dúvida que muitos têm é: "Meu computador esta infectado com esse tal conficker?" em um dos meus posts antigos comentei de como ver se uma maquina esta infectada com o conficker utilizando o nmap, porém nem sempre temos esta ferramenta a mãos, então como podemos verificar a existência ou não do conficker em nossa máquina?
A galera do "Conficker Working Group" criou um teste gráfico via web que é bem fácil, basta acessar o seguinte endereço:
http://www.confickerw
orkinggroup.org/infection_test/cfeyechart.html

Esta página deverá lhe mostrar a seguinte imagem:



Caso a imagem exibida seja diferente há algum problema com seu computador =p
veja a seguir as possíveis causas:


Caso seja exibida esta figura seu computador pode estar infectado com o conficker (variante "C" ou mais nova)







Caso seja exibida esta figura seu computador pode estar infectado com o conficker (variante "A/B")







Caso seja exibida esta figura seu browser pode estar com a opção de exibir imagens desabilitada.. =p






Explicando:

O conficker bloqueia o acesso a mais de 100 sites de antivirus e segurança, ou seja se você não conseguir carregar as imagens da parte de cima da tabela com as 6 figuras possívelmente o conficker ou outro software malicioso esta bloqueando o seu acesso a este site.
Caso você consiga ver todas as 6 figuras signicica que você não esta infectado com o conficker ou que você pode esta navegando através de um proxy (neste caso você não pode executar este teste pois o resultado não sera real).


By CleBeer |_b

quinta-feira, 23 de abril de 2009

Jack Daniels



O Bom e velho Tio Jack como eu gosto de chamar um dos meus Whiskeys prediletos o famoso Jack Daniels, apesar de não ter muito marketing aqui no Brasil o bom e velho Jack é muito conhecido mundialmente, fora o rótulo padrão existe também o "Single Barrel" que todas as garrafas de tederminado lote são estraídas de um único barril e o meu preferido o "Gentleman Jack" (por isso o chamo de velho tio Jack rsrs) com um sabor suave e bem específico herdado do seu duplo processo de destilação. Uma curiosidade sobre o Bom e velho Jack é a inscrição no seu rótulo que diz "The old N° 7 Brand". Existem várias versões sobre esta frase, as mais conhecidas são as que falam que o velho Jack Daniels teve 7 namoradas, a que o jeito do velho Jack escrever seu nome parecia o número 7 e uma que fala que o velho jack escoheu o número 7 por ser seu número da sorte porém o verdadeiro significado desta frase o velho Jack levou para o seu túmulo. Bem agora que já conhecemos um pouco mais sobre o Velho Jack, assim que tiver oportunidade não deixe de aprecia-lo.

By CleBeer |_b


quarta-feira, 22 de abril de 2009

Client SSH via web

Existe um site que fornece um client ssh via web (em ajax).
Pois é por mais estupido que possa ser existe, mais uma ferramenta a favor do mal..rsrsrs
Para os que estão se perguntando porque estou reclamando de algo "relativamente" útil, eu explico, uma ferramenta dessas ajuda muuito na hora de invadir um site pois a conexão parte do servidor deles ou seja vou fazer auditoria para ver quem invadiu e vejo que é um site que fornece um serviço pra isso.... show de bola!!!

para quem quiser testar o site é o seguinte:

http://www.serfish.com/console/

By CleBeer (tks to welias at twitter)

Nova versão beta do Nmap

Postei há algumas semanas comentando sobre o lançamento do nmap-4.85beta-5 que tinha a opção de scan que permitia verificar se a maquina estava infectada com o conficker mas uma atualização do conficker fez com que este recurso do nmap não reconhecesse mais a nova variante do conficker, porém a galera do insecure.org lançou uma nova versão do nmap, o nmap-4.85beta-8 que corrige este problema, no meu post anterior sobre nmap eu comentei que para escanear uma máquina com suspeita de infecção pelo conficker basta utilizar o seguinte comando:

nmap -p139,445 --script p2p-conficker,smb-os-discovery,smb-check-vulns --script-args checkconficker=1,safe=1 -T4 [ rede de destino]

Porém se você tiver tempo para uma análise mais lenta porém mais criteriosa pode executar o seguinte comando:

nmap --script p2p-conficker,smb-os-discovery,smb-check-vulns -p- --script-args checkall=1,safe=1 -T4 [rede de destino]

A nova versão do nmap-4.85beta-8 e a lista de todas as alterações desta nova release podem ser encontradas no site do nmap nos links a seguir:

Download

Changelog

Fonte: nmap.org

By CleBeer

segunda-feira, 20 de abril de 2009

Departamento de segurança americano procura por Hackers White Hat


O departamento de segurança interno dos Estados Unidos esta procurando por "Hackers White Hat" para ajudar a defender a infra-estrutura de internet americana. Um anuncio do DHS (Department of Homeland Security) procura pessoas que "possam pensar como os caras maus"
Algum candidato??? =D

By CleBeer

Fonte:
The Register

quarta-feira, 15 de abril de 2009

Falha no PF causa DoS no OpenBSD 4.3

Na semana passada (09/04/2009) Foi divulgada uma falha na implementação do PF (Packet Filter) que ao receber um pacote IP forjado com zero byte causa kernel panic no OpenBSD.
O teste pode ser feito utilizando o comando nmap com a opção -s0. (não use isso para o mal..)
Os sistemas FreeBSD não foram afetados.

By Clebeer
Fonte:
Security Focus

terça-feira, 14 de abril de 2009

10 Bebidas que levam as mulheres a transar

Pesquisa com 860 garotas americanas mostra como a bebida que elas escolhem no bar influi nas chances de a noite terminar em sexo. Veja na lista a porcentagem delas que dormiram com alguém depois de beber.


1º - Tequila (91%)
2º - Vodca (79%)
3º - Uísque (68%)
4º - Gim (67%)
5º - Rum (62%)
6º - Cerveja (48%)
7º - Conhaque (46%)
8º - Champanhe (23%)
9º - Vinho tinto (12%)
10º - Vinho branco (9%)

E viva a Tequila... =)

By CleBeer
Fonte:
http://copao.blogspot.com/


quarta-feira, 1 de abril de 2009

Primeiro de abril para os Nerds

Como todos sabem primeiro de abril é o dia internacional da mentira e muitas noticias falsas são publicadas na internet, o pior é que tem gente que cai nessas falsas noticias, vejam o exemplo da nova RFC intitulada "IPv6 over Social Networks" rsrsrs
show de bola, outra pegadinnha esta no site do Metasploit (metasploit.com) onde na página inicial exibe uma mensagem que o site foi tirado do ar pelo FBI e que todos os indivíduos que utilizam metasploit estão sobre investigação..rsrsrs...




By CleBeer |_b

terça-feira, 31 de março de 2009

Nmap 4.85BETA5 lançado para escanear Conficker

O malware Conficker tem recebido muita atenção da mídia pois tem trabalhado em vasta escala e ja infectou milhoes de maquinas.

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

É incrível até onde vai a criatividade humana a favor do mal...rsrsrs
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

Pesquisadores tem demonstrado como criar rootkits que permanecem na máquina mesmo após formatação do HD colocando o código malicioso na BIOS do computador.

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

Hehe nem só de bits vive um geek...
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

Ontem saiu a nova versão do kernel linux 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)

Se um dia você estiver com problemas no seu sistema de DNS o único site que você provavelmente conseguirá acessar é o da "Southern Air Inc", porquê? porque você vai lembrar do endereço. "http://12.34.56.7"

sexta-feira, 20 de março de 2009

Websense classifica erroneamente cisco.com como site hacker

No inicio desta semana o websense classificou erroneamente o site da Cisco como site Hacker, por cerca de 15 minutos os usuários do websense ficaram impossibilitados de acessar o site da Cisco. Segundo a Websense isso ocorreu porque o endereço IP utilizado pelo host www.cisco.com estava associado anteriormente a um site hacker.

Fonte:
The Register

Como trabalha o Kernel Linux

Ao procurar a definição da palavra "Kernel" em um dicionário (inglês/inglês) percebi que ele deu ênfase ao seguinte ponto: “The most important part of a statement, idea, plan, etc” e também “a very small part or amount of something”. A partir daqui já temos uma idéia de que é algo muito importante, pois mesmo sendo muito pequeno o kernel é o cara que gerencia a interface de comunicação entre o hardware o os programas instalados no computador. Quando falamos do Linux estamos falando exclusivamente deste kernel, todo o resto como gnome, firefox e até mesmo o bash tratam-se apenas de programas que rodam no Linux e não fazem parte do Sistema Operacional (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....
clebeer@gmail.com
clebeerpub.blogspot.com

Representação geográfica de alertas do snort

Um dos engenheiros da Source Fire desenvolveu um perl script que pega os alertas gerados pelo snort ou apliances Source Fire e mapea o evento utilizando o google earth.

Maiores detalhes no site do autor do script: aqui
O script pode ser baixado aqui

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 usuario@192.168.0.254:/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.

O twitter virou febre entre os geeks de plantão, eu mesmo as vezes atualizo ele até qdo estou no banheiro, mas como muitas coisas na net podem ser utilizadas tanto para o bem quanto para o mal, um cara muito "esperto" recebeu uma proposta de emprego da Cisco e postou no twitter uma mensagem :
--
"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

sábado, 28 de fevereiro de 2009

Protegendo senhas com GPG

Hoje em dia é muito comum alguns administradores de rede possuirem vários servidores

e possuir uma senha (forte) para cada um destes servidores, nas palestras que tenho ministrado

ja fui questinado algumas vezes de como guardar dezenas de senhas diferentes com segurança?

Bem na minha opinião a melhor forma é guarda-las no cérebro mesmo..rsrs mas como nem

sempre possuimos capacidade para armazenar tais informações nos meros 10% que utilizamod do nosso

cérebro eu decidi pesquisar sobre uma solução para tal problema e achei diversos programas que propoem

uma solução simples para nosso problema, eles armazenam as senhas em arquivos criptografados, ou seja

ao invés de termos que decorar 15 senhas com 20 caracteres cada uma precisamos lembras de apenas uma única senha.

Dentre os programas que eu achei mais interesantes estão o jpws[1], o Password Gorilla[2], o Password Dragon[3],

e o KeePassX[4], a proposta de todos eles é bem interessante gerenciar o armazenamento de senhas de forma segura

porém depois de ler sobre os programas eu pensei, "Perae por quê diabos estou querendo reinventar a roda?"

a solução sempre esteve mais perto do que imaginei, basta utilizar o GnuPG[5].GnuPG (GNU Privacy Guard)

é um projeto openource que implementa as definições da RFC 4880[6]. O GnuPG no permite criptografar e

assinar arquivos, emails, etc. A utilização do GnuPG (ou gpg na linha de comando) é bem simples como veremos

no Exemplo a seguir para criarmos um arquivo com as nossas senhas.

Primeiro verifique se vc possui o pacote gnupg instalado:


---

# dpkg -s gnupg (para sistemas debian-like)

# rpm -qv gnupg (para sistemas red-hat like)

---


Possuindo o gnupg instalado vamos criar uma chave de criptografia para o nosso usuário.

---

# gpg --gen-key (Comando para gerar uma nova assinatura)

gpg (GnuPG) 1.4.6; Copyright (C) 2006 Free Software Foundation, Inc.

This program comes with ABSOLUTELY NO WARRANTY.

This is free software, and you are welcome to redistribute it

under certain conditions. See the file COPYING for details.

Por favor selecione o tipo de chave desejado:

(1) DSA e Elgamal (padrão)

(2) DSA (apenas assinatura)

(5) RSA (apenas assinar)

Sua opção? 1

---

Escolheremos a opção 1 (padrão)

Então seremos questionados sobre o tamanho da chave que pode ter entre 1024 e 4096 bits,

neste ponto quanto maior a chave mais segura ela será, no exemplo eu escolhi uma chave com

2048 bits.

---

par de chaves DSA vai ter 1024 bits.

ELG-E chaves podem ter o seu comprimento entre 1024 e 4096 bits.

Que tamanho de chave você quer? (2048) 2048

---

Após definir o tamanho da chave seremos questionados sobre o tempo de validade

da chave, podemos difinir um temo X para que a chave expire porem para o nosso

caso como não vamos divulga-la e a utilizaremos somente para criptografar nosso arquivo de

senha podemos escolhes a opção "0 = chave não expira"

---

Por favor especifique por quanto tempo a chave deve ser válida.

0 = chave não expira

= chave expira em n dias

w = chave expira em n semanas

m = chave expira em n meses

y = chave expira em n anos

A chave é valida por? (0) 0

---

Agora vamos definir um identificador do usuário para o qual estamos criando

a chave. No exemplo vamos utilizar o Zé da Silva.

---

Você precisa de um identificador de usuário para identificar sua chave; o

programa constrói o identificador a partir do Nome Completo, Comentário e

Endereço Eletrônico desta forma:

"Heinrich Heine (Der Dichter) "

Nome completo: Ze da Silva

Endereço de correio eletrônico: ze@example.com

Comentário: Chave do Ze da Silva

Você selecionou este identificador de usuário:

"Ze da Silva (Chave do Ze da Silva) "

Muda (N)ome, (C)omentário, (E)ndereço ou (O)k/(S)air? O

---

Agora vamos definir uma senha para esta chave, esta é a senha que nos

NÃO podemos esquecer pois ele será utilizada para criptografar o nosso

arquivo de texto com as senhas.

---

Você precisa de uma frase secreta para proteger sua chave.

Digite a frase secreta:

Digite novamente a frase secreta:

+++++++++++++++...+++++.+++++++++++++++++++++++++.+++++++++++++++....

+++++.+++++++++++++++++++++++++++++++++++++++++++++.

.++++++++++.+++++++++++++++....++++++++++>..+++++..+++++>+++++>.+++++..>+++++..+++++^^^

gpg: chave 62B6EE12 marcada como plenamente confiável

chaves pública e privada criadas e assinadas.

gpg: checando o trustdb

gpg: 3 parcial(is) necessária(s), 1 completa(s) necessária(s), modelo de confiança PGP

gpg: profundidade: 0 válidas: 2 assinadas: 0 confiança: 0-, 0q, 0n, 0m, 0f, 2u

pub 1024D/62B6EE12 2008-11-03

Impressão digital da chave: 6686 B77A 0DEB 5FBF 6A29 33C6 74F7 8A32 62B6 EE12

uid Ze da Silva (Chave do Ze da Silva)

sub 2048g/EB413A88 2008-11-03

---


Pronto ja temos uma chave para o Ze da Silva

Para verificar os dados da chave criada basta utilizar o

comando "gpg --list-key"

---

# gpg --list-key

/root/.gnupg/pubring.gpg

------------------------

pub 1024D/62B6EE12 2008-11-03

uid Ze da Silva (Chave do Ze da Silva)

sub 2048g/EB413A88 2008-11-03

---

Agora vamos ao que interessa, vamos criar um arquivo com as nossas senhas.

---

#cat senha.txt

Senha de root

root=22#$54543%4FDDwkdk439

Senha do gmail

ze@gmail.com = Z20r$55ec$

Senha do msn

ze_silva@hotmail = Z3$1l\/@

---

Agora que ja temos o arquivo com as senhas vamos criptografa-lo com

a chave que criamos. No comando abaixo a opção "-r" indica o ID de usuário

para o qual estamos criptografando este arquivo e a opção "-e" indica

que queremos criptografar ao dados do arquivo senha.txt

---

gpg -r Ze -e senha.txt

---

Após executar o comando acima vc percebera que foi criado um arquivo chamado

senha.txt.gpg, este é o arquivo criptografado, com isso ja podemos apagar o arquivo

ariginal, (rm -f senha.txt) e ficarmos somente com o arquivo criptografado.

Agora para visualizarmos as senhas dentro do arquivo criptografado basta executar o seguinte comando

---

gpg -d senha.txt.gpg

Você precisa de uma frase secreta para destravar a chave secreta do usuário: "Ze da Silva (Chave do Ze da Silva) "

2048-bit ELG-E chave, ID EB413A88, criada 2008-11-03 (ID principal da chave 62B6EE12)

Digite a frase secreta:

----

Após digitar a frase secreta corretamente o conteudo do arquivo será exibido.

---

gpg: criptografado com 2048-bit ELG-E chave, ID EB413A88, criado 2008-11-03

"Ze da Silva (Chave do Ze da Silva) "

Senha de root

root=22#$54543%4FDDwkdk439

Senha do gmail

ze@gmail.com = Z20r$55ec$

Senha do msn

ze_silva@hotmail = Z3$1l\/@

---

Outra opção legal é exportar a chave pública e enviar para outra pessoa,

desta forma a pessoa que receber esta chave pública também podera criptografar

arquivos que só vc podera descriptografar.

Exportar chave publica:

---

#gpg -a --export -r Ze > chave_publica-Ze.asc

---

Agora é só enviar o arquivo "chave_publica-Ze.asc"

para alguem e pedir para ele importa-la com o comando:

"gpg --import"

---

$ gpg --import /root/chave_publica-Ze.asc

gpg: chave 62B6EE12: chave pública "Ze da Silva (Chave do Ze da Silva) " importada

gpg: Número total processado: 1

gpg: importados: 1

---


Bem por enquanto é só, agora podemos ocupar a mente com outras coisas que não sejam as senhas

Espero que seja util para alguem...

Links

[1] http://jpws.sourceforge.net/

[2] http://www.fpx.de/fp/Software/Gorilla/

[3] http://www.passworddragon.com/

[4] http://www.keepassx.org/

[5] http://www.gnupg.org/

[6]http://www.ietf.org/rfc/rfc4880.txt

Se quiser enviar críticas, elogios, sugestões ou até mesmo

Me chamar pra tomar uma Cerveja basta enviar um email para.

clebeer@gmail.com

By CleBeer |_b