No inicio, a Internet e as redes de computadores eram lugares harmoniosos, onde todos se respeitavam e viviam felizes.<\/p>\n
H\u00e1 muito, o descrito acima deixou de ocorrer. Onde muitos viram oportunidades e um canal de comunica\u00e7\u00e3o r\u00e1pido e confi\u00e1vel (at\u00e9 ent\u00e3o) e tentaram utiliz\u00e1-la para facilitar suas vidas. Outros buscaram meios, t\u00e9cnicas e ferramentas para profanar a paz da rede. N\u00e3o faltam relatos sobre a\u00e7\u00f5es maliciosas.<\/p>\n
Haja vista, diversos esfor\u00e7os vem sendo feitos para assegurar algumas propriedades b\u00e1sicas da redes como autenticidade, confidencialidade, disponibilidade e integridade. Esses est\u00e3o entre os pilares da seguran\u00e7a da informa\u00e7\u00e3o.<\/p>\n
Esse post vem a falar brevemente sobre sistemas de firewall e a apresentar a solu\u00e7\u00e3o de preven\u00e7\u00e3o de intrus\u00e3o HLBR.<\/p>\n
1 – Sistemas de Firewall<\/p>\n
Segundo Eriberto Motta, sistemas de firewall s\u00e3o todo e qualquer esfor\u00e7o voltado a preserva\u00e7\u00e3o da seguran\u00e7a de uma rede de computadores.<\/p>\n
Portanto, se voc\u00ea colocar o Z\u00e9 Faxineiro olhando um LED vermelho e avis\u00e1-lo que quando estiver acesso ele deve apertar o bot\u00e3o 666, que leva a impedir uma a\u00e7\u00e3o maliciosa em sua rede, ele faz parte de seu sistema de firewall… Esse \u00e9 o exemplo mais did\u00e1tico que j\u00e1 escutei (acho que ouvi do Eriberto)… hehehe<\/p>\n
Ou seja, sistemas de firewall s\u00e3o bem mais que um simples filtro de pacotes de camada de rede. Envolve sistemas de detec\u00e7\u00e3o e preven\u00e7\u00e3o de intrus\u00e3o, proxies, anti-.*, e outras solu\u00e7\u00f5es. A figura 1.0 mostra um diagrama de solu\u00e7\u00f5es aplicadas a cada camada do modelo TCP\/IP.<\/p>\n
Figura 1.0: Solu\u00e7\u00f5es de seguran\u00e7a das camadas do modelo TCP\/IP<\/p>\n
O diagrama acima n\u00e3o pretende de forma alguma ser exaustivo, apenas para dar uma pequena id\u00e9ia das solu\u00e7\u00f5es existentes.<\/p>\n
Na camada mais inferior, a f\u00edsica, est\u00e3o todos os esfor\u00e7os contra o acesso f\u00edsico indevido e catastrofes eventuais. A lista poderia ser extendida com sistemas de nivelamento autom\u00e1tico, que protejem contra choques f\u00edsicos relacionados a terremotos e desmonoramentos, dentre outras solu\u00e7\u00f5es.<\/p>\n
No enlace, os principais mecanismos s\u00e3o os filtros de frames de camada de enlace. No Linux, temos o ebtables. Semelhante ao Netfilter\/iptables, ele \u00e9 capaz de realizar filtragem a n\u00edvel de enlace, podendo verificar campos como o MAC de origem\/destino, interface f\u00edsica do pacote, inteface l\u00f3gica (em caso de bridges), al\u00e9m das matchs extensions. Ainda nessa camada, temos mecanismos de autentica\u00e7\u00e3o a n\u00edvel de enlace, tal qual o PPPoE.<\/p>\n
Na terceira camada, os elementos que figuram disparados s\u00e3o os filtros de camada de rede, como o grandioso Netfiltet\/iptables. Como ele podem ser analisados os mais diversos campos do cabe\u00e7alho IP. Alguns dos campos tamb\u00e9m podem ser modificados, tal como faz a target extension TTL.<\/p>\n
O transporte, al\u00e9m de garantir entrega de pacotes confi\u00e1vel e multiplexa\u00e7\u00e3o, tamb\u00e9m muni os dispositivos de seguran\u00e7a com mais alguns dados valiosos. Com tais dados, filtros de pacotes como Netfilter\/iptables permitem ainda mais precis\u00e3o na tomada de decis\u00e3o.<\/p>\n
Atualmente muito \u00e9 pesquisado na \u00e1rea de intelig\u00eancia computacional na tentativa do desenvilvimento de um sistema auto-adaptativos baseado na correla\u00e7\u00e3o da informa\u00e7\u00e3o presentes em cabe\u00e7alhos (da 1\u00aa, 2\u00aa e 3\u00aa camada). O simp\u00f3sio de seguran\u00e7a da informa\u00e7\u00e3o e de sistemas computacionais, SBSEG, em sua edi\u00e7\u00e3o de 2008, teve diversas apresenta\u00e7\u00f5es sobre tal assunto. Confiram SBSeg’08 – About SBSeg\u00b408 , tem alguns PDFs.<\/p>\n
Na quinta e ultima camada do modelo TCP\/IP temos os proxy de aplica\u00e7\u00f5es, os anti-malwares, al\u00e9m dos sistemas de detec\u00e7\u00e3o e preven\u00e7\u00e3o de intrus\u00e3o, como o Snort e o HLBR. Essa camada tange os protocolos de aplica\u00e7\u00e3o, tipo o FTP e SSH, e tem seus pr\u00f3prios (e numerosos) desafios. A exemplo, como tratar do fluxo de protocolos stateless, tal o HTTP? Quais mecanismos usar para garantir que n\u00e3o se tenha evas\u00f5es e falsos positivos\/negativos? Codifica\u00e7\u00e3o? E por ai vai…<\/p>\n
Uma observa\u00e7\u00e3o v\u00e1lida e pertinente \u00e9 que a maioria dos sistemas de seguran\u00e7a se utilizam de mais de uma camada do modelo para suas an\u00e1lises. O Snort e o HLBR, a exemplo, realizam verifica\u00e7\u00f5es de payload somente ap\u00f3s verifica\u00e7\u00e3o da origem e destino. O Netfilter\/iptables possui funcionalidades padr\u00e3o e agregadas que v\u00e3o desdo o enlace (m\u00f3dulo mac) at\u00e9 a camada de aplica\u00e7\u00e3o (m\u00f3dulo ipp2p, layer7).<\/p>\n
2 – Sistemas de detec\u00e7\u00e3o intrus\u00e3o<\/p>\n
Sistemas de detec\u00e7\u00e3o de intrus\u00e3o (Intrusion Detection System) analisam o tr\u00e1fego de rede e relacionam informa\u00e7\u00e3o presentes nos diversos cabe\u00e7alhos com os dados da camada de aplica\u00e7\u00e3o e geram alertas, caso exista a possibilidade de um ataque. A topologia f\u00edsica tradicional para a implanta\u00e7\u00e3o de tais sistemas est\u00e1 representada na figura 2.0.<\/p>\n
Figura 2.0 Topologia f\u00edsica tradicional dos sistemas de detec\u00e7\u00e3o de intrus\u00e3o<\/p>\n
Vejam que os IDSs se encontram em paralelo a rede. A implica\u00e7\u00e3o direta disso \u00e9 que tais sistemas n\u00e3o recebem pacotes diretamente. Esses s\u00e3o c\u00f3pias dos pacotes originais, como ilustrado na figura 2.0.<\/p>\n
Devido a topologia acima, IDS tem o previl\u00e9gio de realizar computa\u00e7\u00f5es mais “pesadas” devido a atrasos gerados pelo processamento dos pacotes n\u00e3o acarretarem em atrasos na rede em quest\u00e3o.<\/p>\n
Desses sistemas, o mais not\u00e1vel deles \u00e9 o IDS open source Snort, desenvolvido pela Source Fire. Estando equipado com diversos preprocessadores, o Snort \u00e9 capaz de de alterar seu comportamento em tarefas como defragmentar pacotes IP e pacotes TCP adulterados, assumindo o mesmo perfil que os sistemas finais.Para informa\u00e7\u00f5es adicionais sobre o Snort e detec\u00e7\u00e3o de intrus\u00e3o, recomendo visitas ao site oficial Snort – the de facto standard for intrusion detection\/prevention e visitas ao site da comunidade brasileira Comunidade Snort Brasil.<\/p>\n
3 – Sistemas de preven\u00e7\u00e3o de intrus\u00e3o<\/p>\n
Sistemas de preven\u00e7\u00e3o de intrus\u00e3o (Intrusion Prevention System) analisam o tr\u00e1fego da rede relacionam informa\u00e7\u00f5es presentes nos diversos cabe\u00e7alhos com os dados da camada de aplica\u00e7\u00e3o e tomam decis\u00f5es acerca desses, podendo derrubar a conex\u00e3o, derrubar somento o pacote ou gerar um alerta, como fazem os IDSs. A topologia f\u00edsica tradicional para a implanta\u00e7\u00e3o de tais sistemas se encontra ilustrado na figura 3.0.<\/p>\n
Figura 3.0: topologia f\u00edsica tradicional dos sistemas de preven\u00e7\u00e3o de intrus\u00e3o<\/p>\n
A topologia representada acima \u00e9 denominada in-line. Ou seja, o IPS est\u00e1 em linha com a rede. Portanto, o mesmo pacote recebido pelo IPS \u00e9 recebido pelo sistema final.<\/p>\n
O IPS necessitam de tomar suas decis\u00f5es o mais r\u00e1pido poss\u00edvel. Caso a computa\u00e7\u00e3o dos pacotes leve tempo demasiado, os clientes podem sentir essa diferen\u00e7a ou at\u00e9 mesmo o IPS pode tornar-se um gargalo na rede.<\/p>\n
De fundamental import\u00e2ncia \u00e9 a conviv\u00eancia dos IDS e dos IPS. Como j\u00e1 citado, existe uma diferen\u00e7a conceitual entre os dois no tempo computacional dispon\u00edvel. Os IDSs podem levar um intervalo de tempo arbitr\u00e1rio para chegar a uma conclus\u00e3o acerca do tr\u00e1fego. J\u00e1 os IPSs, devem tormar a decis\u00e3o o mais r\u00e1pido poss\u00edvel. Haja vista as afirma\u00e7\u00e3o anterioires, devemos sempre ter os sistemas presentes em nossa rede: IDS minuciosos e IPS velozes.<\/p>\n
Aqui o Snort tamb\u00e9m dispara em popularidade, apesar de n\u00e3o ser o mais r\u00e1pido dos sistemas. Seu modo de opera\u00e7\u00e3o in-line permite que o mesmo trabalhe como ponte entre segmentos de rede e utilize sua vasta base de dados para realizar as decis\u00f5es.<\/p>\n
Nessa categoria, tamb\u00e9m se enquadra o HLBR, o qual falaremos mais um pouco na pr\u00f3xima sess\u00e3o!<\/p>\n
3 – HLBR<\/p>\n
O HLBR \u00e9 um sistema de preven\u00e7\u00e3o de intrus\u00e3o livre, desenvolvido principalmente por brasileiros. Ele \u00e9 baseado no Hogwash, criado por Jason Larsen e descontinuado em 2003. Ap\u00f3s diversas tentativas de se juntar a equipe do Hogwash, os l\u00edderes do projeto HLBR resolveram criar o fork.<\/p>\n
Diferentemente do Snort, que recebe seu pacotes atrav\u00e9s da target QUEUE do Netfilter\/iptables, o HLBR os recebe diretamente da camada de enlace. Apesar de dificultar o processo de an\u00e1lise, pois os protocolos devem ser decodificados pelo HLBR, essa decis\u00e3o tem implica\u00e7\u00f5es diretas na performance do sistema. No baixo n\u00edvel, a tecnologia envolvida com a captura dos pacotes s\u00e3o os raw sockets.<\/p>\n
Funcionando como uma bridge, HLBR n\u00e3o associa endere\u00e7os MAC ou IP as interfaces, o que lhe possibilita atuar de forma invis\u00edvel a topologia pois al\u00e9m da abs\u00eancia de endere\u00e7amento, o mesmo n\u00e3o modifica os cabe\u00e7alhos dos protocolos presentes nos frames. O processo de captura e tomada de decis\u00e3o s\u00e3o realizadas pelo engine do HLBR, sendo o mesmo capaz de analisar frames Ethernet em meio ao uso de decodificadores implementados com base nas camadas do Modelo TCP\/IP.<\/p>\n
A an\u00e1lise dos pacotes s\u00e3o realizados com base em regras. Estas podem ser est\u00e1ticas ou din\u00e2micas. Regras est\u00e1ticas especificam conte\u00fados a estar presente no payload dos pacotes. Regras din\u00e2micas especificam padr\u00f5es. A cria\u00e7\u00e3o de regras din\u00e2micas envolve o conhecimento de Express\u00f5es Regulares seguindo o padr\u00e3o PCRE (Perl Compatible Regular Expressions).<\/p>\n
3.1 – Instalando o HLBR<\/p>\n
Nas distribui\u00e7\u00f5es Debian e Ubuntu, a instala\u00e7\u00e3o do HLBR se d\u00e1 de forma simples, bastando apenas digitar no terminal:
\n# apt-get install hlbr
\nNo Slackware, \u00e9 necess\u00e1rio compilar o HLBR em meio ao c\u00f3digo fonte. Tamb\u00e9m \u00e9 uma tarefa simples. As depend\u00eancia para a compila\u00e7\u00e3o s\u00e3o PCRE e PThreads, ambas presentes nos discos de instala\u00e7\u00e3o do Slackware. O c\u00f3digo fonte do HLBR pode ser baixado em http:\/\/ufpr.dl.sourceforge.net\/sourc…lbr-1.6.tar.gz . Tendo baixado, a primeira tarefa \u00e9 descompact\u00e1-lo:
\n$ tar -xvzf hlbr-1.6.tar.gz
\nLogo em seguida, s\u00e3o iniciados os passos da compila\u00e7\u00e3o:
\n$ cd hlbr-1.6
\n$ .\/configure
\n$ make
\n# make install
\nNa etapa de configure ser\u00e1 perguntando acerca de qual lingua se deseja que o HLBR seja criado. Por padr\u00e3o, a lingua \u00e9 a inglesa, bastando apenas pressionar enter. Para aqueles menos familiarizados, pode-se optar pela lingua portuguesa. Basta digitar “p” e em seguida enter. Vale salientar que a lingua \u00e9 v\u00e1lida para o arquivo de configura\u00e7\u00e3o.<\/p>\n
Ser\u00e3o criados os diret\u00f3rios \/etc\/hlbr e \/var\/log\/hlbr, bem como ser\u00e3o criados os scripts de inicializa\u00e7\u00e3o (em \/etc\/init.d\/hlbr) e os arquivos de configura\u00e7\u00e3o padr\u00e3o.<\/p>\n
3.2 – Configurando o HLBR<\/p>\n
A configura\u00e7\u00e3o do HLBR \u00e9 feita pelo arquivo hlbr.config, encontrado, por padr\u00e3o, no diret\u00f3rio \/etc\/hlbr.<\/p>\n
O arquivo de configura\u00e7\u00e3o est\u00e1 organizado em se\u00e7\u00f5es. As principais delas s\u00e3o System, Interfaces, Actions e Routes.<\/p>\n
3.2.1 – Se\u00e7\u00e3o Sytem<\/p>\n
Em System, os principais par\u00e2metros a serem alterados s\u00e3o o Name, que especifica o nome do sensor. Esse par\u00e2metro serve principalmente para identificar de qual inst\u00e2ncia do HLBR foi gerado o log, caso tenha-se um mecanismo de registros centralizados; ID, que tem fun\u00e7\u00e3o semelhante a Name; Threads, que especidica se o HLBR dever\u00e1 usar mecanismos multi-threads em sua execu\u00e7\u00e3o. \u00c9 fortemente recomendado deixar essa op\u00e7\u00e3o intocada (1); AlerHeader, especifica o formato dos alertas gerados. Algumas flags poder\u00e3o ser usadas, como %dip para o endere\u00e7o IP de destino, %sp para a porta de origem, dentre outras. Recomendo uma lida breve no arquivo de configura\u00e7\u00e3o; PidFile especifica o arquivo que conter\u00e1 o PID de execu\u00e7\u00e3o do HLBR. Esse \u00e9 usado internamente. Lembre-se de manter esse arquivo num lugar acess\u00edvel. Segue um exemplo de configura\u00e7\u00e3o da se\u00e7\u00e3o system. Na se\u00e7\u00e3o interface especificamos quais dispositvos de rede far\u00e3o parte do sistema de preven\u00e7\u00e3o. Nessa devemos inserir o nome da inteface, seu tipo e o protocolo utilizado. Os exemplos ser\u00e3o mais pr\u00e1ticos: 3.2.3 – Se\u00e7\u00e3o IPLists<\/p>\n A se\u00e7\u00e3o IPLIst associa um conjunto de endere\u00e7os IP a um nome. Serve para facilitar a confec\u00e7\u00e3o de regas. Com uma simples sintaxe, o mais did\u00e1tico que podemos chegar \u00e9 um exemplo: 3.2.4 – Se\u00e7\u00e3o Actions<\/p>\n Seguindo, chegamos a se\u00e7\u00e3o actions. Nela devemos configurar para onde ir\u00e3o os alertas. As op\u00e7\u00f5es s\u00e3o DROP, ou seja, derrubar o pacote; alert console, envia o alerta para o consolo o qual o sistema est\u00e1 rodando; alert file(arquivo), joga a sa\u00edda para arquivo; alert syslog(fac, prio , opt), envia a sa\u00edda para o sistema de registro como a facility fac, a prioridade prio e op\u00e7oes especiais opt; e dump packet(arquivo), ger\u00e1 um arquivo pcap com o pacote que conferiu; Seguem exemplos e suas explica\u00e7\u00f5es: 3.2.5 – Se\u00e7\u00e3o Routing<\/p>\n A se\u00e7\u00e3o routing associa placas de rede para que seja realizada o repasse de pacotes entre essas. As interfaces a serem usadas aqui devem ter sido especificadas na se\u00e7\u00e3o interfaces.<\/p>\n As principais op\u00e7\u00f5es aqui s\u00e3o SBridege e MacFilter. A primeira associa duas interfaces, realizando uma ponte entre elas. A segunta pode associar um n\u00famero arbitr\u00e1rio de interface, atuando tal qual um switch. Sempre que poss\u00edvel, \u00e9 prefer\u00edvel que se utiliza o m\u00e9todo SBridge pois esse \u00e9 muito mais eficiente que o MacFilter.<\/p>\n Segue exemplo de configura\u00e7\u00e3o: 3.2.6 – Se\u00e7\u00e3o Decoders<\/p>\n Como dito anteriormente, o HLBR funciona em meio ao uso de decoders. Sendo a se\u00e7\u00e3o mais recente, o \u00fanico decoder que aceita par\u00e2metros em sua configura\u00e7\u00e3o \u00e9 o decoder HTTP.<\/p>\n O Decoder HTTP, para prover um ganho em usa performance, decodifica apenas os m\u00e9todos especificados em sua configura\u00e7\u00e3o. O arquivo de modelo do HLBR prov\u00ea entradas para os principais m\u00e9todos HTTP e WebDAV. Devem ser especificados na configura\u00e7\u00e3o, separados por virg\u00falas, todos os m\u00e9todos que trafegam em sua rede. Caso um m\u00e9todo n\u00e3o esteja presenta na configura\u00e7\u00e3o, o decoder HTTP n\u00e3o o vaculhar\u00e1. Segue um exemplo de configura\u00e7\u00e3o: 3.3 – Rodando o HLBR<\/p>\n Estando o HLBR devidamente configurado, devemos agora iniciar sua execu\u00e7\u00e3o. Por\u00e9m, primeiro \u00e9 necess\u00e1rio configurar as interfaces de rede. Para que se mantenha invis\u00edvel, o HLBR necessita que n\u00e3o haja endere\u00e7os IPs configurados nas interfaces. Podemos faz\u00ea-lo de duas maneiras: Rodando dessa maneira, o terminal ficar\u00e1 bloqueado pela aplica\u00e7\u00e3o. Para contornar esse problema, pode-se usar a flag -d, que far\u00e1 o HLBR rodar como um daemon, Tamb\u00e9m \u00e9 poss\u00edvel iniciar o processo em background, adicionando-se & ao final da linha de comando.<\/p>\n Usu\u00e1rios Slackware poder\u00e3o adicionar as linhas Usu\u00e1rios Ubuntu e Debian, devem usar a ferramente update-rc.d para iniciar o HLBR no runlevel desejado (vide http:\/\/www.debuntu.org\/how-to-manage…th-update-rc.d).<\/p>\n 3.4 – Testando sua configura\u00e7\u00e3o<\/p>\n Aparti desse momento, a seguran\u00e7a de sua rede j\u00e1 deve ter sido aprimorada. Para um teste simples fa\u00e7a: O HLBR possui um conjunto de 140 regras, relacionadas com os mais diversos servi\u00e7os. Dessas, apenas 119 est\u00e3o ativadas por padr\u00e3o. Apesar de apresentarem uma baixa taxa de falsos positivos (apenas um, e foi comigo ), considero uma boa pr\u00e1tica desativar algumas delas para aumentar a performance do sistema de preven\u00e7\u00e3o.<\/p>\n Exemplo: digamos que eu n\u00e3o possua roteadores cisco em minha rede. Ent\u00e3o, posso ir ao arquivo hlbr.rules e comentar a linha relativa ao arquivo cisco.rules: Existem tamb\u00e9m quatro linhas relativas a arquivos de regras que est\u00e3o comentados por padr\u00e3o, s\u00e3o estes: Recomendo a visualiza\u00e7\u00e3o de cada arquivo para que se tenha uma no\u00e7\u00e3o precisa do que cada regra bloqueia. Al\u00e9m, deve-se tamb\u00e9m diminuir a quantidade de par\u00e2metros em regras. Por exemplo, todos as regras relacionadas a bufferoverflow, est\u00e3o com as portas 1-1023 listadas. Caso esteja somente filtrando o tr\u00e1fego de um servidor WEB, pode somente colocar 80 (ou a porta adequada) como par\u00e2metro.<\/p>\n 3.6 – Criando Regras<\/p>\n As regras no HLBR seguem a seguinte sintaxe: Ent\u00e3o, sumarizadamente, as regras consistem em especificar quais dados devem ser analisados e quais testes realizar. Segue abaixo uma lista com os decoders e seus principais testes.<\/p>\n Ethernet Outro detalhe sobre o uso do teste content, \u00e9 que esse permite an\u00e1lisar bytes brutos. Por exemplo, caso queira verificar a presen\u00e7a de uma caract\u00e9re de controle backspace, pode ser feito da seguinte maneira: A diretiva action especifica qual a a\u00e7\u00e3o a ser tomada para o pacote que casa com a regra. O valor dela poder ser qualquer um entre os identificadores das actions criadas no arquivo de configura\u00e7\u00e3o.<\/p>\n 3.6.1 – Depurando novas regras<\/p>\n Ao HLBR, \u00e9 permitido tomar decis\u00f5es relativas ao tr\u00e1fego de rede, podendo at\u00e9 mesmo bloque\u00e1-lo. Acredito que isso j\u00e1 ficou claro at\u00e9 aqui. Portanto, deve-se ter um cuidado especial com novas regras pois estas podem levar a falsos positivos e a nega\u00e7\u00e3o de servi\u00e7o. Portanto, ao desenvolver uma nova regra, aconselho que a mantenha com uma action que n\u00e3o derrube o pacote. \u00c9 interessante tamb\u00e9m gerar os dumps dos pacotes. Utilizando um arquivo de configura\u00e7\u00e3o padr\u00e3o, esse comportamento pode ser conseguido utilizando-se a action2.<\/p>\n Os dumps s\u00e3o de fundamental import\u00e2ncia pois permitem que as regras sejam validadas. Ou seja, com eles em m\u00e3o, voc\u00ea pode utilizar seu analisador de pacotes preferido, desde que compat\u00edvel com PCAP, e validar seus resultados.<\/p>\n 3.6.2 – Ferramentas de depura\u00e7\u00e3o<\/p>\n Ap\u00f3s escrever as regras, se mostra proveitoso criar a aplicar casos de testes. As ferramentas descritas (brevemente) a seguir possibilitam a aplica\u00e7\u00e3o de casos de testes, n\u00e3o estando sua utilidade limitada somente a depura\u00e7\u00e3o de regras do HLBR. Recomendo estudar cada uma em separado.<\/p>\n 3.6.2.1 – Hping3<\/p>\n O Hping3 \u00e9 um gerador de pacotes de rede de prop\u00f3sito geral. Permite especificar todos os detalhes do pacote, desde o protocolo reportado pelo campo proto do protocolo IP at\u00e9 o n\u00famero de sequ\u00eancia do protocolo TCP. Claro, tamb\u00e9m permite determinar os dados do payload. Exemplo: ‘ O canivete su\u00ed\u00e7o do TCP\/IP. Uma boa pedida para o NetCat \u00e9 gerar tr\u00e1fego malicioso. Ent\u00e3o, seja a.data um arquivo bin\u00e1rio com tr\u00e1fego malicioso, No inicio, a Internet e as redes de computadores eram lugares harmoniosos, onde todos se respeitavam e viviam felizes. H\u00e1 muito, o descrito acima deixou de ocorrer. Onde muitos viram oportunidades e um canal de comunica\u00e7\u00e3o r\u00e1pido e confi\u00e1vel (at\u00e9 ent\u00e3o) e tentaram utiliz\u00e1-la para facilitar suas vidas. Outros buscaram meios, t\u00e9cnicas e ferramentas para […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[28,26,27,14],"class_list":["post-76","post","type-post","status-publish","format-standard","hentry","category-viazap","tag-defesa","tag-hlbr","tag-invasao","tag-linux"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/76","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=76"}],"version-history":[{"count":1,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/76\/revisions"}],"predecessor-version":[{"id":77,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/76\/revisions\/77"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=76"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=76"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=76"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n
\nName=HLBR_WEB
\nID=1
\nThreads=1
\nAlertHeader=%y-%m-%d %h:%m:%s %ac %sip:%dp >> %dip:%dp
\nPidFile=\/var\/run\/hlbr.pid
\n<\/system>
\nAqui podemos ver que teremos um sensor chamado HLBR_WEB com n\u00famero de identifica\u00e7\u00e3o 1 usando threads. Mais a seguir veremos os como configurar o destino dos alertas, por\u00e9m adianto um modelo de aleta gerado pelo AlertHeader acima:
\n2009-03-04 03:38:46 00000001 192.168.0.60:3483 >> 192.168.0.61:80 (webattacks-9) open proxy use attempt
\n3.2.2 – Se\u00e7\u00e3o Interfaces<\/p>\n
\n
\ntype=linux_raw
\nproto=Ethernet
\n<\/interface><\/p>\n
\ntype=linux_raw
\nproto=Ethernet
\n<\/interface>
\nO campo type precisa ser ajusto levando em cosidera\u00e7\u00e3o o sistema opercional utilizado. Para Linux, o tipo \u00e9 linux_raw; OpenBSD, bsd_bpf; … Um tipo que \u00e9 interessante comentar \u00e9 o tcpdump. Esse recebe um arquivo PCAP e utiliza como uma interface, podendo gerar alertas quanto ao tr\u00e1fego gerado.<\/p>\n
\n
\n192.168.0.10
\n192.168.0.11
\n<\/iplist><\/p>\n
\n192.168.0.20
\n192.168.0.21
\n<\/iplist><\/p>\n
\nwww
\ndns
\n<\/iplist>
\nComo podem ver, uma IPList pode fazer parte de outra IPList, vide o exemplo de IPList servers.<\/p>\n
\n
\nresponse=alert file(\/var\/hlbr\/hlbr.log)
\nresponse=dump packet(\/var\/hlbr\/hlbr.dump)
\nresponse=drop
\n<\/action><\/p>\n
\nresponse=alert file(\/var\/hlbr\/hlbr.alert.log
\nresponse=dump packet(\/var\/hlbr\/hlbr.alert.dump)
\n<\/action>
\nA o primeiro exemplo, action1, ir\u00e1 gerar um alerta no arquivo \/var\/hlbr\/hlbr.log, um dump do pacote em \/var\/hlbr\/hlbr.dump e derrubar\u00e1 o pacote. Ou seja, o pacote n\u00e3o chegar\u00e1 ao host de destino. O segundo exemplo, por sua vez, ir\u00e1 gerar os mesmo alertas que o primeiro exemplo, por\u00e9m n\u00e3o derrubar\u00e1 o pacote.<\/p>\n
\n
\nSBridge(eth0, eth1)
\n<\/routing><\/p>\n
\nMacFilter(eth2, eth3. eth4)
\n<\/routing>
\nA primeira das se\u00e7\u00f5es criar\u00e1 uma bridge entre as interfaces eth0 e eth1. A segunda, por sua vez, realizar\u00e1 a comuta\u00e7\u00e3o de pacotes entre as interfaces eth2, eth3 e eth4. Deveido a necessidade da descoberta dos endere\u00e7os ARP, o m\u00e9todo MacFilter pode levar um tempo at\u00e9 iniciar a troca de pacotes.<\/p>\n
\n
\nGET,POST
\n<\/decoder>
\nNessa configura\u00e7\u00e3o, apenas os m\u00e9todos GET e POST ser\u00e3o decodificados. Todos os outros, passar\u00e3o despercebidos pelo decoder HTTP.<\/p>\n
\n# ifconfig eth0 0.0.0.0
\nou
\n# ip addr flush dev eth0
\nFeito isso, podemos agora iniciar o servi\u00e7o:
\n# hlbr -c \/etc\/hlbr\/hlbr.config -r \/etc\/hlbr\/hlbr.rules
\nConfig file is hlbr.config
\nRules file is hlbr.rules
\nLoaded 119 rules
\nA linha de comando acima inicia o HLBR usando o arquivo de configura\u00e7\u00e3o \/etc\/hlbr\/hlbr.config e o arquivo de regras \/etc\/hlbr\/hlbr.rules. O sistema foi carregado com 119 regras.<\/p>\n
\nifconfig eth0 0.0.0.0 up
\nifconfig eth1 0.0.0.0 up
\n\/etc\/init.d\/hlbr start
\nno arqivo \/etc\/rc.d\/rc.local. Isso para a configura\u00e7\u00e3o de uma SBridge envolvendo as interfaces eth0 e eth1.<\/p>\n
\n$ links ‘http:\/\/www.endere\u00e7odowww.com.br\/search.php?query=\/etc\/passwd’
\nOnde www.endere\u00e7odowww.com.br deve ser resolvido para um dos endere\u00e7os presentes na lista www. Se a requisi\u00e7\u00e3o n\u00e3o puder ser completada, o HLBR est\u00e1 funcionando corretamente e voc\u00ea poder\u00e1 ver no arquivo \/var\/log\/hlbr.log uma entrada semelhante com a seguinte:
\n2009-03-08 01:49:44 00000001 192.168.0.10:33244 >> 192.168.0.11:80 (passwd-1) \/etc\/passwd call
\n3.5 – Otimizando o conjunto de regras<\/p>\n
\n
\n<\/include>
\n<\/include>
\n<\/include>
\n#<\/include>
\n<\/include>
\n<\/include>
\n<\/include>
\n<\/include>
\n<\/include>
\n<\/include>
\n<\/include>
\n<\/include>
\n<\/include>
\nCaso n\u00e3o possua clientes \u00b5Soft Janelas em minha rede, posso tamb\u00e9m comentar a regra relativa ao codered-numda.rules.<\/p>\n
\n#<\/include>
\n#<\/include>
\n#<\/include>
\n#<\/include>
\nEstas DEVEM ser analisadas pois podem causar falso positivos e DoS em sua rede. S\u00e3o relativas a m\u00e9todos HTTP, tipos de p\u00e1ginas que podem ser requisitadas e a argumentos passados para p\u00e1gina din\u00e2micas.<\/p>\n
\n
\ndecoder teste(argumento)
\ndecoder teste(argumento)
\n…
\ndecoder teste(argumento)
\nmessage=mensagem
\naction=action
\n<\/rule>
\nMuito pouco intuitivo… \u00c9 melhor apresentar um exemplo real:
\n
\nip dst(servers)
\ntcp dst(13,37,53,123)
\ntcp content(\/etc\/passwd)
\nmessage=(passwd-1) \/etc\/passwd call
\naction=action1
\n<\/rule>
\nEnt\u00e3o, na primeira linha temos a tag
\nsrc – permite verificar o endere\u00e7o MAC de origem. Ex: ethernet src(ff:ff:ff:ff:ff:ff)
\ndst – permite verificar o endere\u00e7o MAC de destino. Ex: ethernet dst(ff:ff:ff:ff:ff:ff)
\ntype – permite verififcar o tipo do protocolo encapsulado. Ex: ethernet type(IP)
\nIP
\nsrc – permite verificar o endere\u00e7o IP de origem. Ex: ip src(192.168.0.1, servers)
\ndst – permite verificar o endere\u00e7o IP de destino. Ex: ip src(192.168.0.1, www)
\nproto – permite verificar o protocolo encapsulado. Ex: ip proto(TCP,UDP)
\nTCP
\nsrc – permite verificar a porta TCP de origem. Ex: tcp src(2222)
\ndst – permite verificar a porta TCP de destino. Ex: tcp dst(80)
\ncontent – permite verificar a presen\u00e7a de um conte\u00fado est\u00e1tico em um payload TCP, levando em considera\u00e7\u00e3o a caixa. Ex: tcp content(\/etc\/passwd)
\nnocase – permite verificar a presen\u00e7a de um conte\u00fado est\u00e1tico em um payload TCP, sem levar em considera\u00e7\u00e3o a caixa. Ex: tcp content(
\nregex – permite verificar a presen\u00e7a de um padr\u00e3o definido por uma Express\u00e3o Regular em um payload TCP. Ex: tcp regex(\/etc\/(passwd|shadow))
\nUDP
\nsrc – vide TCP, por\u00e9m aplicado ao protocolo UDP
\ndst – vide TCP, por\u00e9m aplicado ao protocolo UDP
\ncontent – vide TCP, por\u00e9m aplicado ao protocolo UDP
\nnocase – vide TCP, por\u00e9m aplicado ao protocolo UDP
\nregex – vide TCP, por\u00e9m aplicado ao protocolo UDP
\nHTTP
\ncontent – vide TCP, por\u00e9m no protocolo de aplica\u00e7\u00e3o HTTP
\nnocase – vide TCP, por\u00e9m no protocolo de aplica\u00e7\u00e3o HTTP
\nregex – vide TCP, por\u00e9m no protocolo de aplica\u00e7\u00e3o HTTP
\nmethod – verifica o m\u00e9todo do cabe\u00e7alho HTTP.
\nVejam que os protocolos TCP e HTTP possuem alguns testes em comum. A diferen\u00e7a b\u00e1sica entre eles \u00e9 que, no decoder HTTP, os caract\u00e9res URL Encoded s\u00e3o decodificados e passados em texto puro para o teste. Por exemplo, caso o atacante tente se aproveitar de uma falha em um script PHP, ele poderia evadir a regra TCP usada como exemplo da seguinte forma:
\nGET \/scriptvulneravel.php?include=% 2f%65%74%63%2fpasswd HTTP\/1.0
\nOu seja, ele poderia passar o “\/etc\/” de forma codificada pois esses caract\u00e9res n\u00e3o estariam vis\u00edveis pelo teste content do decoder TCP. J\u00e1 usando o decoder HTTP, o texto seria primeiramente passado para sua forma “human-readable” e casaria com a seguinte regra:
\n
\nip dst(servers)
\ntcp dst(13,37,53,123)
\nhttp content(\/etc\/passwd)
\nmessage=(passwd-3) \/etc\/passwd call
\naction=action1
\n<\/rule>
\nPortanto, sempre que sua regra estiver direcionada ao protocolo HTTP, use o decoder HTTP.<\/p>\n
\n…
\ntcp content(ASD| 08 |DSA)
\n…
\nOnde 08 \u00e9 o c\u00f3digo hexadecimal do caract\u00e9re backspace, o qual deve ser substituido pelo caract\u00e9re desejado. Os delimitadores suportam sequencias de bytes ( |08 13 29| ). O mesmo vale para o teste nocase. J\u00e1 nas express\u00f5es regulares, usa-se o escape \\x seguido do c\u00f3digo hexadecimal:
\n…
\nhttp regex (ASD\\x08DSA)
\n…
\nNa diretiva message, deve-se especificar a mensagem que aparecer\u00e1 nos registros do sistema. Tamb\u00e9m \u00e9 poss\u00edvel fazer a substitui\u00e7\u00e3o de algumas flags (%sip, %dip, %sp, …), como feito no AlertHeader, por\u00e9m, visto que todas as informa\u00e7\u00f5es que se deseja armazernar j\u00e1 est\u00e1 especificado no AlertHeader, n\u00e3o h\u00e1 muita vantagem em faz\u00ea-lo. Uma frase simples e objetiva se mostra bastante eficiente.<\/p>\n
\nhping3 192.168.0.10 -p 80 –ack -e ‘GET \/ HTTP\/1.0<\/p>\n
\n3.6.2.2 – NetCat<\/p>\n
\nnc -u 192.168.0.20 53 < a.data\nIr\u00e1 enviar o conte\u00fado de a.data via UDP para a porta 53 do host 192.168.0.20. Na Internet existem milh\u00f5es e milh\u00f5es de tutoriais sobre o NetCat, com os mais variados exemplos.\n\n3.6.2.3 - Scapy\n\nO Scapy \u00e9 um poderoso programa interativo de manipula\u00e7\u00e3o de pacotes. Com ele \u00e9 poss\u00edvel gera ou decodificar pacotes de vasto n\u00famero de protocolos, envi\u00e1-los, captur\u00e1-los, e muito mais. Utilizando-se da linguagem de programa\u00e7\u00e3o Python como seu backend, o Scapy permite gerar e enviar tr\u00e1fego de forma mais automatizada e din\u00e2mica que a maioria das ferramentas.\n\nDevido a complexa (mas n\u00e3o complicada) utiliza\u00e7\u00e3o, n\u00e3o ser\u00e3o mostrado exemplos de utiliza\u00e7\u00e3o do Scapy. Mas fica o link para quem desejar se aprofundar: http:\/\/www.secdev.org\/projects\/scapy\/doc\/usage.html\n\n3.6.2.4 - KRegExpEditor\n\nEssa n\u00e3o \u00e9 uma ferramenta de rede, por\u00e9m se apresenta como uma poderosa aliada na escrita\/depura\u00e7\u00e3o de regras baseadas em Express\u00f5es Regulares. Sendo uma das op\u00e7\u00f5es de testes mais poderosas do HLBR, as Express\u00f5es Regulares podem apresentar alguns dificuldades, principalmente para aqueles que est\u00e3o iniciando.\n\nO KRegExpEditor \u00e9 um editor gr\u00e1fico de Express\u00f5es Regulares. Seu interface consiste em um campo para a digita\u00e7\u00e3o da ER, um campo para a entrada de casos de testes e um visualizador interativo da ER digitada. A medida que se digita a ER, o visualizador \u00e9 atualizado. Caso a ER case com algum caso de teste, a por\u00e7\u00e3o casante \u00e9 destacada do restante do texto.\n\nO \u00fanico problema com KRegExpEditor \u00e9 a compatibilidade somente com o padr\u00e3o POSIX, pois o HLBR utiliza-se do PCre. Mas mesmo assim, \u00e9 uma \u00f3tima ferramenta.\n\n3.7 - An\u00e1lisando os registros\n\nUma parte importante da preven\u00e7\u00e3o de intrus\u00e3o \u00e9 analisar quais ataques est\u00e3o sendo realizados e barrados em sua rede. Portanto, se mostra fundamental a visualiza\u00e7\u00e3o e interpreta\u00e7\u00e3o frequente dos registros gerados pelo sistema.\n\nA principal e mais simples ferramenta para essa tarefa \u00e9 o TCPDump. Bastante conhecida entre os administradores de rede, o TCPDump permite a captura e a visualiza\u00e7\u00e3o do tr\u00e1fego de uma interface ou do tr\u00e1fego presente em um arquibo PCAP, al\u00e9m de permitir o uso de regras de filtragem. No HLBR, o TCPDump \u00e9 utilizado das duas maneiras descritas. Primeiro, podemos abrir qualquer uma das interfaces:\ntcpdump -i eth0\ntcpdump -i eth1\ntcpdump -i any\nSegundo, podemos abrir os arquivos gerados pelas actions:\ntcpdump -r \/var\/log\/hlbr\/hlbr.dump -n -s 1500 -A\nPara tornar a an\u00e1lise mais eficiente, podemos tamb\u00e9m utilizar filtros e visualizar somente os pacotes relevantes a um dado host ou protocolo:\ntcpdump -r \/var\/log\/hlbr\/hlbr.dump -n -s 1500 -A dst host 192.168.0.10 and dst port 80\nA regra de filtragem acima ir\u00e1 mostrar somente os pacotes destinados a porta 80 do host 192.168.0.10. O manual do TCPDump (man tcpdumo) \u00e9 bem completo e possui diversos exemplos de regras de filtragem.\n\nOutra ferramente \u00fatil, principalmente para aqueles menos acostumados com o terminal, \u00e9 o Wireshark. Possuindo os mesmo recursos do TCPDump, o Wireshark \u00e9 capaz de gera gr\u00e1ficos de fluxo de pacotes, reconstuir fluxos, analisar dados de I\/O, al\u00e9m de interpretar os principais protocolos das mais diversas camadas.\n\nOs dumps s\u00e3o as mais completas fontes de dados, por\u00e9m, muitas vezes \u00e9 relevante somente um sum\u00e1rio das amea\u00e7as barradas. Nos arquivos de log s\u00e3o impressos somente os dados especificados no AlertHeader do hlbr.config. Portanto, apresentam somente informa\u00e7\u00f5es b\u00e1sicas como o IP de origem\/destino, porta de origem\/destino, hora do ocorrido, mensagem e mais alguns dados, dependendo da configura\u00e7\u00e3o realizada. Estando armazenados como arquivos de texto plano, os logs podem ser visualizados com ferramentas como o less, cat e more.\n\n3.7.1 - Valida\u00e7\u00e3o das decis\u00f5es\n\nApesar de todas as informa\u00e7\u00f5es dispon\u00edveis, ainda cabe ao administrador do sistema julgar as decis\u00f5es do HLBR e destivar regras que estejam causando problemas. N\u00e3o sendo um cen\u00e1rio comum, falsos positivos podem ocorrer quando n\u00e3o se tem a devida aten\u00e7\u00e3o no momento da otimiza\u00e7\u00e3o do conjunto de regras (3.5).\n\nPortanto, bastant cautela durante a sele\u00e7\u00e3o das regras do seu IPS. Como j\u00e1 dito, tente manter novas regras em estado de quarentena (sem impedir a passagem). Caso haja d\u00favida quanto ao funcionamento de alguma regra, tente mant\u00e9-la tamb\u00e9m em quarentena e verifique se algum acesso l\u00edcito a seu sistema casa com a regra, o que a tornaria uma fonte de falsos positivos.\n\nNo mais, bom senso \u00e9 a melhor das virtudes.\n\n3.8 - Futuro do HLBR\n\nBem, o desenvolvimento do HLBR anda a todo vapor, estando em fase de testes a otimiza\u00e7\u00e3o para arquiteturas multi-core e agendadas o porte para 64 bits.\n\nCaso algu\u00e9m venha a testar o HLBR, gostaria de ter o feedback e tamb\u00e9m ouvir sugest\u00f5es de melhoras e de funcionalidades.\n\n3.9 - Comunidade\n\nO HLBR possui um grupo de discuss\u00e3o onde rolam an\u00fancios e suporte ao uso da ferramenta. O endere\u00e7o do grupo \u00e9 http:\/\/br.groups.yahoo.com\/group\/hlbr\/ . Se inscreva e estaremos l\u00e1, sempre que poss\u00edvel, para tirar d\u00favidas e discutir opni\u00f5es.\n\nCaso seja desenvolvedor, o HLBR \u00e9 todo desenvolvido em linguagem C. As \u00fanicas bibliotecas as quais estamos sujeitos \u00e9 a PCRE e a Pthreads. Tamb\u00e9m, claro, a biblioteca padr\u00e3o, mas n\u00e3o vem ao caso. Se quiserem colaborar conosco, basta entrar no grupo e expor as id\u00e9ias.<\/include><\/p>\n","protected":false},"excerpt":{"rendered":"