quarta-feira, 30 de julho de 2008

Dica: Ubuntu atualizado Diariamente



Se você for baixar o Ubuntu para instalar em seu micro e for pegar o que está nos espelhos e site da Canonical, você terá que se deparar com mais de 300MB de atualização.

Ao invés disso, pode pegar uma imagem de instalação totalmente atualizada.

O Próprio pessoal da Canonical faz isso.

Basta acessar http://cdimage.ubuntu.com/hardy/daily-live/current/

E Baixar o Ubuntu que é feito diariamente.
Clique em PC (Intel x86) desktop CD para baixar a imagem para PC 32 bits.
Clique em 64-bit PC (AMD64) desktop CD para baixar imagem para PC 64 bits.

Arte (NERD) Com cabos de Rede

É Coisa pra Russo ver!!! Realmente, porque vem de um site russo. Os caras não tem o que fazer e arrumam.
Além destas maneiras, tem mais algumas outras em http://basik.ru/handmade/2066/




terça-feira, 29 de julho de 2008

Formas de ataque, intrusão, invasão e detecção de intrusão.

1. Introdução

"Um ataque corresponde a um comprometimento em nível de sistema de segurança através de um ato inteligente ou deliberado, afetando serviços e violando política de um sistema.” (SHIREY, 1995).

Um Sistema Operacional, qualquer ele que seja, feito por colaboradores, open source, gratuito ou proprietário é dotado de falhas. Um sistema destes é composto por dezenas de softwares, milhares de linhas de código, rotinas, sub-rotinas, funções, drivers e chamadas de redes que apesar de todas os esforços e testes das empresas que o fazem antes do seu lançamento oficial, acaba aparecendo problemas em poucos dias de uso. Estes problemas, comumente chamados de “brechas”, vulnerabilidades ou ainda “furos”, acabam dando oportunidade de ataque e de acesso indevido ao sistema. As empresas se esforçam, liberando versões beta para que o público especializado (programadores, analistas de segurança e usuários da ferramenta) use e avise dos possíveis problemas para que seja corrigido antes do lançamento da versão final. Porém isso não é o bastante, é impossível a qualquer companhia produtora de sistemas ter testado todos os modos de uso e todas as situações que aquele programa irá passar... daí aparecem os famosos bugs dando oportunidade a alguns de se aproveitarem e usarem isso em benefício próprio ou com o intuito de prejudicar algo ou alguém.

Para se precaver contra estas vulnerabilidades no sistema é que existem profissionais nas empresas que cuidam para que estes problemas possam ser sanados de forma rápida e eficaz. O Administrador de Redes e/ou o Analista de Segurança tem que estar informado através do site do fabricante do sistema ou de sites especializados em publicação de boletins de segurança para ter acesso a estas informações o mais rápido possível e sanar estes problemas o quanto antes. Os fabricantes Sistemas Operacionais geralmente trazem no seu sistema ferramentas que fazem a atualização dos seus programas através da internet resolvendo o problema imediatamente. Esses patchs são baixados e instalados de forma rápida e fácil, porém não basta só aplicar os patchs, é necessária toda uma política de segurança sustentável que deve ser seguida à risca na empresa e ser medida, testada e avaliada periodicamente.

Para diminuir ao máximo as brechas de segurança dos seus sistemas, são necessários alguns cuidados como:
  • Manter seus sistemas atualizados;
  • Procurar usar versões estáveis dos programas utilizados;
  • Executar os serviços necessários na máquina evitando que portas sejam abertas sem necessidade;
  • Cuidado ao usar a conta do administrador;
  • Cuidar da segurança física das suas máquinas e do acesso a elas;
As maiorias das invasões acontecem por que algum serviço foi mal configurado ou está desatualizado. Mantendo estes métodos, com certeza a probabilidade de ataques diminui bastante, mas não evita o inevitável.

2. Intrusões

“A intrusão ou ataque podem ser definidos como qualquer conjunto de ações que tentam comprometer a integridade, confidencialidade ou disponibilidade de um recurso computacional, independente do sucesso ou não destas ações” (SOUZA, 2002).

Em geral, um ataque é cuidadosamente bem calculado, principalmente porque o atacante não quer ser identificado e se possível quer continuar tendo acesso irrestrito ao local invadido.

Não há regras para determinar os métodos dos atacantes, nem estilo. Mas é provável que o invasor comece em conhecer o sistema, em usar programas para rastrear os servidores e levantar as portas abertas. Este passo é compreendido pela Coleta de informação. É possível também nesta fase fazer a varredura dos servidores encontrados para descobrir as versões dos sistemas operacionais utilizados e as versões dos programas que mantém os serviços funcionando. Só após estes passos é que o atacante irá preparar ferramentas para poder tentar fazer a penetração no sistema ou simplesmente tentar fazer negação de serviço ou redirecionamento de tráfego para roubo de informações. Nesta fase, se for possível, o atacante poderá tentar deixar as portas abertas através de um backdoor ou um rootkit para que a sua entrada no sistema invadido seja mantida em sigilo e sempre facilitada. Como passo final, o invasor poderá tentar apagar seus rastros, excluindo ou burlando os sistemas de log do sistema.

Não existe um plano de ataque pré-definido, ou uma regra, mas com certeza alguns dos passos descritos acima são utilizados para que um invasor consiga ter sucesso na sua ação.

3. Qual o motivo das Invasões?

A resposta para esta pergunta não é simples. Os motivos pelos quais alguém tentaria invadir sua rede ou computador são inúmeros. Alguns destes motivos podem ser:

  • Utilizar seu computador em alguma atividade ilícita, para esconder a real identidade e localização do invasor;
  • Utilizar seu computador para lançar ataques contra outros computadores;
  • Utilizar seu disco rígido como repositório de dados;
  • Destruir informações (vandalismo);
  • Disseminar mensagens alarmantes e falsas;
  • Ler e enviar e-mails em seu nome;
  • Propagar vírus de computador;
  • Furtar números de cartões de crédito e senhas bancárias;
  • Furtar a senha da conta de seu provedor, para acessar a Internet se fazendo passar por você;
  • Furtar dados do seu computador, como por exemplo, informações do seu Imposto de Renda. (CARTILHA, 2006)

Existem diversos tipos de ataque, os intrusivos e os não intrusivos. Geralmente são utilizados ataques não intrusivos, aqueles que não comprometem seus dados nem sua confidencialidade, porém compromete seus serviços. São os famosos ataques de negação de serviço, onde o atacante deseja que sua rede, link ou servidor pare de funcionar e não responda mais aos serviços. Abaixo, citarei os principais tipos de ataques e pragas virtuais e a função de cada um deles.

Referências:

Shirey, Robert W. Security requirements for network management data / Robert W. Shirey Computer Standards & Interfaces, Lausanne, V.17,n.4 (Sept.1995), p.321-331

Cartilha de Segurança da Internet, http://nic.br , http://cert.br e http://cartilha.cert.br .Acessado em 22 de Junho de 2007

Souza, Marcelo. Readaptação do modelo ACME para detecção de novas técnicas de
intrusão.
Monografia de Graduação. UNESP – Departamento de Ciência da Computação e Estatística, São José do Rio Preto - SP, 2002.

segunda-feira, 21 de julho de 2008

Automatizando a Geração de BlackLists do Squid

Aqui no Site, tenho publicado algumas Blacklists.
Aqui segue uma dica, para você turbinar seu Squid com as regras mais recentes de alguns sites.
Dica:
Use a minha blacklist junto com a BlackList do site http://www.malware.com.br desta forma:
Estas blacklists são atualizadas constantemente. Então crie o seguinte script e coloque ele para rodar 2 ou 3 vezes por semana.

Dica: Copie e cole no seu editor de textos predileto como kate ou gedit que as linhas aparecerão de forma correta e não quebrada como está aqui no blog.

Script:

################################################
#!/bin/bash
# Script para Atualizar BlackList automaticamente
# Autor: Dailson Fernandes - http://www.dailson.com.br
# Licenca: GNU/GPL
################################################
# Baixa a nova versao da Blacklist
/usr/bin/wget -O - http://www.malware.com.br/cgi/submit?action=list_squid > /etc/squid/malware.txt

# Ativa as regras no Squid
squid -k reconfigure

Para utilizar esta Blacklist no squid abra o squid.conf e faça:
acl malware_block_list url_regex -i "/etc/squid/malware.txt"
http_access deny malware_block_list

sexta-feira, 18 de julho de 2008

As vezes analogias ajudam...

quinta-feira, 17 de julho de 2008

Personalizando o HLBR - IPS Invisível


INTRODUÇÃO:

O HLBR é um projeto brasileiro destinado à segurança em redes de computadores. O HLBR é um IPS (Intrusion Prevention System) bastante eficiente e versátil, podendo ser usado até mesmo como bridge para honeypots e honeynets. Como não usa a pilha TCP/IP do sistema operacional, ele é "invisível" a outras máquinas na rede e atacantes, pois não possui número de IP.

Para você entender do que vamo tratar aqui, primeiramente você deve conhecer o Projeto HLBR e as definições de IPS e IDS.
Aqui também serão tratados artifícios de gerar regras, análise de regras pré-existentes e arquivos de configuração.
Todo este conhecimento, você adquire no artigo anterior do nosso blog que pode ser acessado aqui: http://www.dailson.com.br/2008/07/tutorial-de-instalao-do-hlbr-verso.html ou VivaoLinux que você acessa através deste link http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=8511

A Versão 1.5-RC2 do HLBR vem com 144 Regras pre-definidas, porém se você apenas instalar e não ativar alguns tipos de regras nem todas irão para a execução.
Existem um conjunto de 4 arquivos que trazem regras que devem ser analisadas pelo Admininistrador antes de coloca-las em produção.
Isto é muito importante, porque por definição, o IPS - Intrusion Prevent System está para bloquear e não para lhe avisar do que pode está acontecendo de errado, ou seja, o IPS não pode se dar ao luxo de ter falso-positivo. As regras não podem barrar o acessos legítmos, se isso acontecer, o seu serviço/site fica fora do ar e na agonia de tentar resolver, você fica procurando problemas no serviço/servidor e não encontra nada, porém o IPS tá barrando o acesso antes que ele chegue no destino.

AS REGRAS A SEREM ANALISADAS.

O Arquivo /etc/hlbr/hlbr.rules indica que regras ele deve carregar na detecção de ataques.
A Sintaxe é a seguinte:

<include localização/arquivo_de_regra.rules>

Exemplo:

<include rules/cisco.rules>

A linha acima esta dizendo, que a partir do diretorio que estou (/etc/hlbr) tem o diretorio rules e dentro dele esta o arquivo cisco.rules que pode ter uma ou mais regras que serão carregadas na memória.

O Arquivo padrão hlbr.rules é o seguinte:

<include rules/awstats.rules>
<include rules/bufferoverflow1.rules>
<include rules/bufferoverflow2.rules>
<include rules/bufferoverflow3.rules>
<include rules/cisco.rules>
<include rules/codered-nimda.rules>
<include rules/coppermine.rules>
<include rules/dnsattacks.rules>
<include rules/joomla.rules>
<include rules/mailvirus.rules>
<include rules/passwd.rules>
<include rules/shell.rules>
<include rules/spam.rules>
<include rules/webattacks.rules>


# As regras dos arquivos abaixo deverao ser analisadas antes de serem
# utilizadas. Isso porque elas poderao interromper parte do trafego legitimo
# da rede.
# The rules of the files below must be analysed before being used. That is
# because they are able to interrupt part of the legitimate network traffic.
#
#<include rules/http.rules>
#<include rules/php.rules>
#<include rules/sql-xss.rules>
#<include rules/www.rules>


Note que há um aviso que as seguintes regras devem ser analisadas
#<include rules/http.rules>
#<include rules/php.rules>
#<include rules/sql-xss.rules>
#<include rules/www.rules>

Não vamos aqui comentar todas as regras, mas vamos analisar algum caso antes de ativa-las.

ANALISANDO O www.rules

O o arquivo /etc/hlbr/rules/www.rules traz regras que se ativadas sem a sua devida atenção poderá colocar todos os teus serviços www fora do ar.

Veja a primeira regra:

<rule>
ip dst(www)
tcp dst(80)
tcp nocase(.asp)
message=(www-1) .asp request
action=action1
</rule>

<rule> .... </rule>
São as TAGS que definem uma regra

ip dst (www)
o alvo desta regra são todos os servidores declarados no arquivo /etc/hlbr/hlbr.conf na seção www

tcp dst(80)
Especificando a porta destino do serviço web que será monitorada

tcp nocase(.asp)
Especifica um conteudo, dentro de um trafego TCP. O content considera a caixa do caractere (diferencia caracteres maiusculos e minusculos).
Espacos serao considerados como caracteres. Sequencias de bytes em
hexadecimal poderao ser inseridas entre caracteres "pipe".
Então se for solicitada qualquer string .asp ou seja, páginas de um servidor ASP a seguinte ação será tomada

action=action1
No arquivo /etc/hlbr/hlbr.conf está definido que a ação action1 é para negar pacotes. Isso quer dizer que se você tem páginas em asp e liberar esta regra, todas as suas páginas estarão inatingíveis a partir de agora.

Caso vocẽ não tenha servidores asp, esta regra pode ser liberada sem problemas e evita que invasores fiquem fazendo testes para tentar descobrir a linguagem de páginas utilizada em alguns servidores.

Pela explicação acima, veja que você consegue entender as outras regras:

<rule>
ip dst(www)
tcp dst(80)
tcp nocase(.php)
message=(www-2) .php request
action=action1
</rule>

A Regra acima bloqueia acesso a páginas em PHP

<rule>
ip dst(www)
tcp dst(80)
tcp nocase(.shtml)
message=(www-3) .shtml request
action=action1
</rule>

A Regra acima bloqueia acesso a páginas em SHTML

<rule>
ip dst(www)
tcp dst(80)
tcp nocase(.xml)
message=(www-4) .xml request
action=action1
</rule>

A Regra acima bloqueia acesso a páginas em XML

<rule>
ip dst(www)
tcp dst(80)
tcp nocase(.pl)
message=(www-5) .pl request
action=action1
</rule>

A Regra acima bloqueia acesso a páginas em PERL.

<rule>
ip dst(www)
tcp dst(80)
tcp nocase(/cgi-bin/)
message=(www-6) cgi request
action=action1
</rule>

<rule>
ip dst(www)
tcp dst(80)
tcp nocase(.cgi)
message=(www-7) cgi request
action=action1
</rule>

As Regras acima bloqueia acesso a execução de CGI-BIN

O ARQUIVO http.rules

Trazem regras que podem bloquear alguns métodos HTTP como o POST, DELETE, TRACE, OPTIONS entre outros.
Não vamos entrar nos méritos dos métodos, porém se você quiser proibir estes métodos, pode liberar a seguinte linha no arquivo /etc/hlbr.rules

#<include rules/http.rules>

E analisar cada uma das regras que estão no arquivo http.rules
Vejam elas:

# For your security SEARCH and CONNECT methods must be blocked.

<rule>
ip dst(www)
tcp dst(80)
tcp regex(^SEARCH )
message=(http-1-re) buffer overflow with search
action=action1
</rule>

<rule>
ip dst(www)
tcp dst(80)
tcp regex(^CONNECT )
message=(http-2-re) open proxy search
action=action1
</rule>

# Uncomment the following rule if you want to block POST.

#<rule>
#ip dst(www)
#tcp dst(80)
#tcp regex(^POST )
#message=(http-3) POST method
#action=action1
#</rule>

Veja aqui que regra de POST é comentada por padrão, porque negá-la pode fazer teu serviço WWW não funcionar.

# Comment the following rule if you don't want to block PUT. By the way, do you need PUT?

<rule>
ip dst(www)
tcp dst(80)
tcp regex(^PUT )
message=(http-4-re) PUT method
action=action1
</rule>

# Uncomment the following rule if you want to block OPTIONS.

#<rule>
#ip dst(www)
#tcp dst(80)
#tcp regex(^OPTIONS )
#message=(http-5-re) OPTIONS method
#action=action1
#</rule>

# Comment the following rule if you don't want to block TRACE. By the way, do you need TRACE?

<rule>
ip dst(www)
tcp dst(80)
tcp regex(^TRACE )
message=(http-6-re) TRACE method
action=action1
</rule>

# Comment the following rule if you don't want to block DELETE. By the way, do you need DELETE?

<rule>
ip dst(www)
tcp dst(80)
tcp regex(^DELETE )
message=(http-7-re) DELETE method
action=action1
</rule>

COMO COMEÇAR A ESCREVER REGRAS PARA O HLBR?

Este é um passo que requer atenção, pesquisa e alguns testes.
Em primeiro lugar você deve ler o README que vem no diretorio do HLBR.
Lá existem dicas preciosas de como você começá-las a construi-la. Lá também você consulta os parâmetros possíveis e as ações que o HLBR pode tomar.

Em segundo lugar, ler LOGs, lá você vai encontrar o que estão tentando fazer com seus servidores, quais são os erros comuns e os strings que estão sendo "injetadas" nos seu servidor.
Neste passo aconselho a instalação de programas que auxiliam na leitura de logs como o LOGWATCH, SWATCH e AWSTATS.
Um bom exemplo é aqui na empresa. Constatei vários acessos a uma dll em meu servidor. Esta dll é a owssvr.dll e vi que é um ataque as expressões do frontpage.
Ao longo do artigo, vou ensinar a escrever algumas regras inéditas. Esta regra, será uma delas.

Em terceiro lugar, é bom você conhecer um pouco de expressões regulares, não é obrigatório, porém importante.
Expressões Regulares define um padrão a ser usado para procurar ou substituir palavras ou grupos de palavras. É um meio preciso de se fazer buscas de determinadas porções de texto.
Por exemplo, se o conjunto de palavras for {asa, carro, jardim, ovos, terra} e a expressão regular buscar por um padrão rr, obterá as palavras carro e terra.
Existem vários caracteres especiais chamados metacaracteres nas Expressões Regulares para fazer uma busca avançada de palavras dentro de uma frase. (Fonte: wikipedia)

Por exemplo:

Existe um ataque básico a um servidor HTTP que pode ser visto neste vídeo: http://ufpr.dl.sourceforge.net/sourceforge/hlbr/http_attack_sample.avi que é a tentativa do atacante passear no hd do servidor, tentando descer na árvore de diretórios chamando os caracteres ../
Exemplo:

http://www.vivaolinux.com.br/../../

Se o servidor do vivaolinux tivesse esta vulnerabilidade eu conseguiria ver a raiz do disco do servidor (caso a páginas dele esteja hospeadada em /var/www)

Ou ainda posso tentar ver os arquivos de senha do servidor:

http://www.vivaolinux.com.br/../../etc/passwd
http://www.vivaolinux.com.br/../../etc/shadow

Com o HLBR, basta eu ter a seguinte regra:

<rule>
ip dst(www)
tcp dst(80)
http regex(\.+(/|\\)+)
message=(webattacks-1-re) directory change attempt (unicode,asc,plain)
action=action1
</rule>


Veja a expressão regular:

http regex(\.+(/|\\)+)

Ou seja, se na URL vier . (ponto) seguido de barras sejam elas normais (/) ou invertidas (\) o hlbr toma a ação action1 que é bloquear e colocar em log.

Quem quiser enveredar ou se especializar em Expressõres Regulares, aconselho o site do Aurelio Marinho Jargas: http://aurelio.net/er

ESCREVENDO REGRAS PRA VALER:

Na comunidade, lancei algumas regras contra IP SPOOFING, que é a técnica que o invasor esconde seu IP para que apareça errado nos logs.
Isto pode ser feito no seu firewall, mas como é um ataque conhecido, eu deixo no meu HLBR aqui no trabalho.
Como o HLBR não traz estas regras por padrão, é necessário nós fazermos dois passos:

Primeiro:
Cadastrar o arquivo de regras no /etc/hlbr/hlrb.rules

<include rules/spoof.rules>

Segundo:

Criar o arquivo /etc/hlbr/rules/spoof.rules com o seguinte conteúdo:

# name: spoof.rules
# created by: Dailson Fernandes - http://www.dailson.com.br
# date: 15 Dec 07
# update: none
# version: 1.0
# target: block ips spoofed

<rule>
ip dst(servers)
ip src(10.0.0.0/8)
message=(spoof-1) Ip spoof Network 10.0.0.0/8
action=action1
</rule>

<rule>
ip dst(servers)
ip src(172.16.0.0-172.31.255.255)
message=(spoof-2) Ip spoof Network 172.16.0.0-172.31.255.255
action=action1
</rule>

<rule>
ip dst(servers)
ip src(192.168.0.0-192.168.255.255)
message=(spoof-3) Ip spoof Network 192.168.0.0-192.168.255.255
action=action1
</rule>

Ou se você preferir, baixe este arquivo de regras aqui.

Depois salvar o arquivo e reiniciar o HLBR para ter as regras em execução.
Note que qualquer conexão vindo da WAN com ip de rede local serão bloqueadas.

ESCREVENDO UMA REGRA CONTRA ATAQUES A EXTENSÕES DO FRONTPAGE

Como citei no tópico "Como começar a escrever regras para o HLBR?" Vi que haviam tentativas de acesso a uma DLL inexistente em meu servidor WEB. Com pesquisas na Internet vi que a DLL owssvr.dll é uma extensão do frontpage e um conhecido ataque a servidores IIS da Microsoft.

Nos logs apareciam assim:

"GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=4518&STRMVER=4&CAPREQ=0 HTTP/1.1"
"GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=4518&STRMVER=4&CAPREQ=0 HTTP/1.1"
"GET /owssvr.dll HTTP/1.1"
"GET /owssvr.dll HTTP/1.1"
"GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6551&STRMVER=4&CAPREQ=0 HTTP/1.1"

Para barar este tipo de ataque, basta você escrever a seguinte regra:

<rule>
ip dst(www)
tcp dst(80)
http content(/owssvr.dll)
message=(webattacks-17) frontpage extensions attack
action=action1
</rule>

Se você deseja fazer o download desta regra clique aqui

Ela deve ser colocada no arquivo /etc/hlbr/rules/webattacks.rules. Como lá já existem 16 regras, ai você complementa com a 17.
Reinicia o HLBR
Deixa o log em visualização com o tail -f /var/log/hlbr/hlbr.log
E tenta fazer algo do tipo:
www.seuservidor.com.br/owssvr.dll e veja o HLBR pegando este ataque.

Mas veja o seguinte, no próprio arquivo webattack.rules tem a seguinte regra:

<rule>
ip dst(www)
tcp dst(80)
tcp content(/_vti_bin/)
message=(webattacks-12) fp call attempt
action=action1
</rule>

Que já bloqueia qualquer tipo de acesso ao diretório _vti_bin onde fica a dll. Já bloqueando o seguinte ataque:
"GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=4518&STRMVER=4&CAPREQ=0 HTTP/1.1"
"GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=4518&STRMVER=4&CAPREQ=0 HTTP/1.1"

Porém não bloqueando este:
"GET /owssvr.dll HTTP/1.1"
"GET /owssvr.dll HTTP/1.1"

Fazendo necessária a inclusão desta regra.

Bônus: Escrevendo uma regra contra SQL-INJECTIONS

Na regra abaixo, eu consigo bloquear técnicas como SQL INJECTION, onde o atacante pode tentar acessar o banco de dados SQL da nossa aplicação e mandar comandos maliciosos para apagar ou consultar senhas e usuários.

(?:^\s*[;>"]\s*(?:UNION|SELECT|CREATE|RENAME|TRUNCATE|LOAD|ALTER|DELETE|UPDATE|INSERT|DESC))|(?:(?:SELECT|CREATE|RENAME|TRUNCATE|LOAD|ALTER|DELETE|UPDATE|INSERT|DESC)\s+(?:CONCAT|CHAR|CONCAT|LOAD_FILE|0x)\s?\(?)|(?:END\s*\);)|("\s+REGEXP\W)

Esse palavrão ai todo está proibindo comandos SQL via protocolo HTTP e portanto protegendo nosso servidor contra SQL INJECTIONS. Esta regra contempla todos os comandos e opções além de técnicas de escondê-las.

Então a regra poderia ser colocada no arquivo /etc/hlbr/rules/sql-xss.rules e deve ficar assim:

<rule>
ip dst(www)
tcp dst(80)
regex((?:^\s*[;>"]\s*(?:UNION|SELECT|CREATE|RENAME|TRUNCATE|LOAD|ALTER|DELETE|UPDATE|INSERT|DESC))|(?:(?:SELECT|CREATE|RENAME|TRUNCATE|LOAD|ALTER|DELETE|UPDATE|INSERT|DESC)\s+(?:CONCAT|CHAR|CONCAT|LOAD_FILE|0x)\s?\(?)|(?:END\s*\);)|("\s+REGEXP\W))
message=(sql-xss-5) Detects concatenated basic SQL injection and SQLLFI attempts
action=action1
</rule>

Se você deseja fazer o download desta regra clique aqui

CONCLUSÃO:

O HLBR é um projeto promissor, e o grande coração dele são as regras e personalizações. Para isso convidamos a toda comunidade a portar regras de outros projetos, ataques conhecidos e casos particulares que acontecem em cada servidor.

No próximo artigo, vou apresentar novas regras e como porta-las através de scritps.

Um grande abraço a todos e lembrem-se...

FLAMES > /dev/null !!!

segunda-feira, 14 de julho de 2008

70 Papéis de (WallPaper) Parede do Firefox

PessoALL

Para quem gosta de Papel de Parede (Wallpaper), neste blog tem 70 opções com o tema Firefox e Thunderbird. Tem para todo gosto.

Para baixar todos de uma vez, pegue a dica da comunidade mzevbr e baixe neste link

sexta-feira, 11 de julho de 2008

BlackLists


Publicação das Listas Negras Que utilizo em produção no meu trabalho.

Garantia:
Utilize-as por sua conta e risco e não há nenhuma garantia da minha parte por quaisquer danos que ela possa vir a causar.

Todas elas são utilizadas em ambiente de produção. ;)

Sites que matém BlackLists

BlackList Email (Postfix):

BlackList para Acesso HTTP (Squid)

BlackList para Acesso FTP

BlackList da Spamhaus:

Em breve, lista de ataques SSH e Scaneadores de Redes.

BlackList Ftp

Blacklist utilizada em produção na minha rede.
É uma coletânea das redes que fazem ataques ao servidor FTP aqui do meu trabalho.
Esta é a primeira versão.

BlackList FTP Versão 1.0
Linhas: 109
Data: 11/07/2008
Donwload BlackList FTP 1.0

BlackList Postfix

Blacklist utilizada em produção na minha rede.
É uma miscelânea de várias blacklists, incluindo algumas listas do fórum postfix-br e outras de amigos administradores. Bloqueia Redes de Spammers e usuários de ADSL.
Esta é a primeira versão.

BlackList Postfix Versão 1.0
Linhas: 514
Data: 11/07/2008
Donwload BlackList Postfix 1.0

BlackList Squid

Blacklist utilizada em produção na minha rede.
É uma miscelânea de várias blacklists, incluindo a do Spybot, Malware.com.br, SquidGuard e outras de amigos administradores. Bloqueia Banners, Popupus e Adware.
Esta é a primeira versão.

Dica: Se quiser turbinar com outra Blacklist automática, veja esta dica

Veja Aqui os sites que mantém BlackLists

BlackList Squid Versão 1.0
Linhas: 27958
Data: 11/07/2008
Donwload BlackList 1.0

quinta-feira, 10 de julho de 2008

Tutorial de Instalação do HLBR Versão 1.5Rc2



O Emprego de uma Bridge como IPS
Para detecção de tráfego anômalo em redes.


Sistemas de Detecção de Intrusos são utilizados para perceber tráfego anômalo em uma rede de dados e tomar decisões de acordo com as regras e configurações definidas pelo gestor de segurança da rede. Estes sistemas são divididos ativos e reativos. Os sistemas ativos, também conhecidos como IDS (Intrusion Detection Systems), percebem o tráfego malicioso fazem a gravação em log e alertam o administrador da rede sobre o que está acontecendo. Os sistemas reativos, conhecidos como IPS (Intrusion Prevention System), tem todas as características do sistema ativo, porém é capaz de tomar decisões e interferir no tráfego malicioso e tornar o ataque inviável. Em alguns sistemas IDS é possível torná-lo em IPS bastando ativar as configurações para que ele intervenha no tráfego. Esta artigo tem como objetivo mostrar a instalação e configuração do HLBR, que é um IPS brasileiro, open source que tem como principal característica a sua “invisibilidade” na rede e sua fácil configuração.

O Que é o HLBR?

O HLBR (Hogwash Light Brasil) é Sistema de Detecção de Intruso que trabalha de forma reativa o que o classifica como IPS, baseado no IPS HOGWASH desenvolvido originalmente por Jason Larsen que colhe dados diretamente na camada 2 do Modelo OSI. Funcionando como uma bridge, sendo capaz de interceptar tráfego malicioso baseado em arquivos de regras e assinaturas de ataques. O HLBR é invisível na rede e é praticamente impossível de ser detectado pelo atacante. Esta característica é possível pelo fato do HLBR não alterar o cabeçalho dos pacotes. O fato de citar que é praticamente impossível de ser detectado é porque até então ainda nenhuma atacante não conseguiu comprovar sua presença na rede. O HLBR se comporta como um ativo de rede, como uma Ponte, Hub ou Switch. Isto é possível pelo fato de suas placas de redes não usarem endereços de IP ou ainda, usar endereços de Ip não roteáveis.

Atuação do HLBR em relação ao Modelo ISO/OSI

O HLBR é responsável em fazer a ponte entre as placas de rede da máquina. Por essa razão, não há aplicativos intermediários como a Libcap para fazer tal trabalho. Todo o trabalho de capturar, desmontar, analisar e remontar é feito pelo HLBR. O HLBR é capaz de analisar o pacote TCP em todas as camadas do Modelo ISO/OSI e TCP. Ele lê os campos dos cabeçalhos de camada 2 (ethernet), 3 (cabeçalho IP) e 4 (TCP e UDP). São esses valores que são testados pelas regras. É importante notar que o próprio HLBR faz esse reconhecimento dos formatos dos cabeçalhos, sem o apoio da pilha TCP/IP do sistema operacional. Isso esclarece o fato do HLBR poder negar ataques na camada 2 do Modelo ISO/OSI mesmo a máquina onde ele está instalado não possuir número de IP.


1 - Hardware Necessário


O HLBR faz jus ao L (light), pois os recursos de hardware e software são mínimos, sendo possível instalar em máquinas consideradas antigas com processador de 200Mhz e 64 de Ram. e um HD de 2 GB. Estes requisitos são suficientes para o HLBR funcionar. Em relação aos adaptadores de rede, o HLBR necessita de no mínimo 2 placas para que seja possível fazer a ponte entre duas redes. O HLBR é capaz de formar mais de uma ponte em uma mesma máquina, sendo que para cada ponte, 2 placas de redes sejam utilizadas.

2 - Instalação do Sistema Operacional

Para instalar o HLBR aconselho que a máquina seja instalada com um Debian Minimal Install que pode ser adiquirido no seguinte link:

http://cdimage.debian.org/debian-cd/4.0_r3/i386/iso-cd/debian-40r3-i386-netinst.iso

Este sistema instala o mínimo necessário em uma máquina para ter o linux funcionando. Sem servidores e serviços adicionais, provendo assim uma maior proteção por não haver serviços extras sendo executados na ponte.

Um passo importante após a instalação do Debian Minimal Install é instalar os pacotes necessários para compilação de programas no linux. Para isto execute:


apt-get install build-essential

Em especial, a partir da versão 1.5, a biblioteca libpcre é necessária para que as expressõres regulares sejam utilizadas. Para isso você também deve instalar:

apt-get install libpcre3-dev libpcre3

Você pode usar a distribuição que você achar melhor, não há problemas. Também pode ser usado outros sabores *NIX como o FREEBSD. Porém vale salientar, que a equipe mantenedora do software recomenda Debian.

3 - Configurando o HLBR

a) Desativando o suporte a IP do Kernel

Para configurar o HLBR sem suporte a IP é necessário ter o código fonte do Kernel do Linux e recompilar sem o suporte a IP. Desta maneira as placas não terão nenhum tipo de endereçamento local sendo controladas pelo daemon do HLBR. Isso será necessário porque o TCP/IP irá conflitar com o fato dos adaptadores de rede estarem ativos sem endereço IP. Assim, o HLBR poderá ter problemas no seu funcionamento, como retardo nos no tráfego. (Eriberto Mota;André Bertelli, 2006)

Porém esta forma de configuração desabilita a possibilidade de analisar o tráfego com ferramentas sniffers como TCPDump, IPTraf e o Wireshark.

b) Utilizando Endereços de Loopback

Caso o usuário opte usar endereço de nas placas do HLBR para facilitar a configuração basta utilizar os endereços de loopback como 127.0.0.0/8. Por exemplo:

eth0 : 127.0.0.2

eth1 : 127.0.0.3

Esta maneira é bem mais fácil de fazer, e não diminui a segurança do sistema em nada, pois endereços de loopback não são roteáveis. E ainda acrescenta a possibilidade de uso de Analisadores de Tráfego como o TCPDump, IPTraf e o Wireshark na camada 3 do modelo ISO/OSI (camada de rede), é possível também com esta configuração que um IDS como o Snort possa colher dados para análise e confecção de novas regras caso seja instalado na mesma máquina.


4- Instalação do HLBR.

a) Baixe o código fonte em:

wget http://ufpr.dl.sourceforge.net/sourceforge/hlbr/hlbr-1.5rc2.tar.gz

b) Descompacte

tar xzvf hlbr-1.5rc2.tar.gz


c) Entre no diretório

cd hlbr-1.5-rc2


d) Faça a compilação e instalação com:

./configure
make
make install


5 - Configurando


a) Vá para o diretório /etc/hlbr

cd /etc/hlbr

b) Abra o arquivo de configuração hlbr.config

vi hlbr.config

Aqui você deverá apontar quais são os servidores e máquinas que você quer proteger. Veja que o HLBR traz alguns exemplos para que você possa alterar de acordo com as suas necessidades. Veja abaixo:

<IPList www>
200.xxx.yyy.195
200.xxx.yyy.196
</list>

<IPList dns>
200.xxx.yyy.195
200.xxx.yyy.197
</list>

<IPList email>
200.xxx.yyy.198
</list>

<IPList firewall>
200.xxx.yyy.210
</list>

<IPList network>
200.xxx.yyy.192/26
</list>

<IPList others>
200.xxx.yyy.194
200.xxx.yyy.199
</list>

<IPList servers>
www
dns
email
firewall
others
200.xxx.yyy.209
</list>

Você deverá trocar os IPs para os correspondentes dos seus servidores.
Abaixo um exemplo utilizando IPs de redes locais, mas com certeza você irá colocar os IPs reais dos seus servidores (caso o HLBR esteja protegendo sua WAN). Se o HLBR estiver em rede local, protegendo servidores ou uma DMZ, o exemplo abaixo é válido.

<IPList www>
192.168.0.1
</list>

<IPList dns>
192.168.0.2
</list>

<IPList email>
192.168.0.3
</list>

<IPList firewall>
192.168.0.4
</list>

<IPList network>
192.168.0.0/24
</list>

<IPList others>
192.168.0.5
</list>

<IPList servers>
www
dns
email
firewall
others
</list>


c) Para configurar as regras

O HLBR já vem com muitas regras prontas. Todas elas ficam dentro do diretório /etc/hlbr/rules em vários arquivos. Geralmente, estes arquivos armazenam regras por assunto. Por exemplo: o arquivo webattacks.rules trazem regras que inibem ataques aos servidores webs. Um arquivo pode (e deve) armazenar diversas regras.
Abaixo, veja um exemplo de uma regra que impede que usuários tentem fazer a mudança de diretório no seu servidor web e visualizar informações importantes como o arquivo de senhas do seu servidor. Esta regra está no arquivo /etc/hlbr/rules/passwd.rules

<rule>
ip dst(servers)
tcp dst(53,80,110,220)
tcp content(/etc/passwd)
message=(passwd-1) /etc/passwd call
action=action1
</rule>

Note que toda regra começa com a tag <rules> e termina com </rule> o parâmetro ip dst está apontando para os servers que foi descrito no arquivo /etc/hlbr/hlbr.config. As portas destino estão especificadas no parâmetro tcp dst e o conteúdo malicioso é detectado através de tcp content, ou seja, caso seja invocado a string "/etc/passwd" o HLBR irá tomar uma atitude descrita em action.
As "actions" (ações) estão definidas no arquivo /etc/hlbr/hlbr.config. Na instalação padrão existem 3 actions:


<action action1>
response=alert file(/var/log/hlbr/hlbr.log)
response=dump packet(/var/log/hlbr/hlbr.dump)
response=drop
</action>

<action action2>
response=alert file(/var/log/hlbr/hlbr-2.log)
response=dump packet(/var/log/hlbr/hlbr-2.dump)
</action>

<action virus>
response=alert file(/var/log/hlbr/virus.log)
response=dump packet(/var/log/hlbr/virus.dump)
response=drop
</action>


Os parâmetros utilizados nas actions são:
alert file
Caminho do arquivo onde será gravado o log.

dump packet
Caminho do arquivo de dump no formato do TCPDump.

drop
Caso este parâmetro seja declarado, o pacote será negado e descartado pelo HLBR.

7 - Onde Posicionar o HLBR ?

O HLBR pode ser posicionado de diversas maneiras. A Mais comum é você colocá-lo na frente de seu firewall e depois do seu roteador.
Por exemplo: Entre seu roteador em casa e seu PC.
Veja na figura abaixo:



Um um ambiente corporativo, não vai ser necessário alterar sua atual estrutura de rede, você pode estar usando qualquer tipo de arquitetura de firewall com ou sem DMZ, Honeynet ou qualquer outro recurso. O HLBR não vai alterar em nada, basta colocá-lo da seguinte maneira:



Ou você pode proteger sua rede utilizando um HLBR na entrada da rede e outro HLBR junto aos usuários, que na maioria das vezes são os nossos inimigos em potencial.




8 - Vídeos do HLBR em Ação!!!

Se você quer ver o HLBR em ação, você pode ver através dos seguintes vídeos:

Vídeo 1: Ataque a um servidor DNS sem o HLBR

Vídeo 2: Ataque a um servidor DNS com o HLBR

Vídeo 3: Ataque a um Servidor HTTP

Brinde:
Vídeo Brinde: Se quiser ver um vídeo de como é feita a instalação do HLBR veja aqui

Obs: Todos os vídeos foram produzidos pela equipe do HLBR.

9 - Colocando pra funcionar!!!!

a) Para iniciar o servidor HLBR dê o seguinte comando:

/etc/initd.d/hlbr start


b) Verifique se o HLBR está no ar:

ps aux | grep hlbr


c) Para parar o HLBR

/etc/initd.d/hlbr stop


d) Se você prefere usar a inicialização em linha de comando, veja os parâmetros possíveis:

10 - Logs

Todos os logs do HLBR estão em /var/log/hlbr (local padrão). Lá você encontrará um arquivos textos com extensão .log e arquivos de dump do tcpdump com extensão dump.

Para visualizar os arquivo de log em modo texto basta usar o vi.

Ex: vi hlbr.log

Para visualizar os dumps do tcpdump, utilize a seguinte sintaxe:

tcpdump -s 1500 -vvv -tttt -X -r hlbr.dump

Onde:

-s: Tamanho máximo do segmento (mtu)

-vvv: Em modo detalhado

-tttt: Modo de tempo detalhado (hora e data)

-X: Exibe os valores em Hexadecimal

-r: Especifica o arquivo de entrada.

11 - Colocando no ar de forma definitiva

Você pode colocar em um arquivo de incialização do linux para toda vez que a máquina for ligada, a ponte seja "armada" e o hlbr esteja sempre analisando o tráfego.

Use o /etc/initd.d/bootmisc.sh e coloque a seguinte linha lá:

hlbr -c /etc/hlbr/hlbr.config -r /etc/hlbr/hlbr.rules

Ou utilize o seguinte comando no Debian:

update-rc.d -n hlbr defaults

Referências:

http://hlbr.sourceforge.net
http://www.eriberto.pro.br
http://bertelli.name

Obs: Este tutorial foi baseado no artigo de Eriberto Mota e André Bertelli.

Este artigo foi publicado no VivaoLinux e pode ser acessado aqui