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

Nenhum comentário:

Postar um comentário