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:
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:
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:
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:
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.
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:
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 !!!
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>
# 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"
"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"
"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>
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