C OMPARATIVE  L ESSONS

Atualmente ´e quase impens´avel pensar-se numa rede corporativa completamente isolada, ou seja, sem ligac¸˜ao `a Internet. Quer isto dizer que toda e qualquer rede que tenha acesso `a Internet pode estar suscet´ıvel a sofrer ataques de v´arios tipos pelo que, imp˜oe-se que estas redes estejam protegidas de ameac¸as externas. Neste contexto surge a importˆancia da utilizac¸˜ao de mecanismos de seguranc¸a como as Firewalls e Sistemas de Prevenc¸˜ao de Intrus˜oes em geral.

Firewalls

A caracter´ıstica b´asica apresentada por Stallings [22], relativamente `a definic¸˜ao de fi- rewall, consiste na capacidade de bloquear tr´afego indesejado, permitindo ao mesmo tempo que os utilizadores de uma rede interna acedam `a Internet (ver figura 2.7). Ainda assim ´e importante conhecer os objetivos que norteiam a utilizac¸˜ao de uma firewall, tal como definidos por Bellovin e Cheswick [1]:

1. Todo o tr´afego proveniente da rede interna para o exterior (e vice-versa) deve passar pela firewall;

2. Apenas o tr´afego autorizado e definido pela pol´ıtica de seguranc¸a local ser´a permi- tido pela firewall;

3. A pr´opria firewall dever´a ser imune a intrus˜oes. Quer isto dizer que o sistema onde est´a configurada a firewall, dever´a ser alvo de reforc¸o a n´ıvel de seguranc¸a por forma a n˜ao comprometer todo o objetivo da mesma.

O autor William Stallings refere que um dos aspetos centrais na implementac¸˜ao de uma firewall ´e a definic¸˜ao de uma boa pol´ıtica de acessos. Esta pol´ıtica define qual o tr´afego permitido ou, por outras palavras, representa o tr´afego que a empresa ou organizac¸˜ao definiu como aceit´avel. A pol´ıtica de acesso deve, primeiramente, ser definida atrav´es da aplicac¸˜ao de filtros para perfis de tr´afego mais gerais para que, em seguida, se definam filtros para perfis de tr´afego mais particulares. Existe um conjunto de caracter´ısticas que podem ser utilizadas pela pol´ıtica de acesso de uma firewall de modo a filtrar o tr´afego, tal como apresentado por Karen Scarfone e Paul Hoffman [5]:

• Enderec¸o IP e Portas L´ogicas: o controlo ´e feito tendo como base o IP de origem, IP de destino, portas l´ogicas, sentido do tr´afego de entrada e de sa´ıda. Normalmente utilizados para limitar o acesso de servic¸os espec´ıficos;

• Protocolo Aplicacional: baseia-se nos dados autorizados pelo protocolo aplicaci- onal, como por exemplo, verificar se um email (SMPT) cont´em spam ou se um determinado pedido HTTP (Hypertext Transfer Protocol) corresponde ao de um websiteautorizado;

• Identidade do Utilizador: controlo de acesso baseado na identidade do utilizador que, por sua vez, recorre a um qualquer mecanismo de acesso seguro (IPSec); • Atividade de Rede: controla o acesso tendo em conta algumas considerac¸˜oes como

o tempo/hora ou tipo de pedido, como por exemplo, quantidade de pedidos durante um curto espac¸o de tempo ou permiss˜ao de um determinado tipo de tr´afego apenas em hor´ario laboral.

A escolha de uma pol´ıtica de acessos deve ser feita antes de se proceder `a escolha de um tipo particular de firewall a utilizar no sistema em quest˜ao. Existem normalmente dois tipos mais comuns quando se fala de implementac¸˜ao de pol´ıticas:

• Pol´ıtica Aberta - Implica que todo o tr´afego ´e permitido `a excec¸˜ao dos casos que foram explicitamente definidos como proibidos. S˜ao definidas regras expl´ıcitas so- bre os casos particulares onde o tr´afego deve ser bloqueado enquanto a regra final aceita todo o tr´afego restante;

• Pol´ıtica Fechada - Todo o tr´afego ´e bloqueado `a excec¸˜ao daquele que foi expli- citamente definido como aceit´avel. Neste ´ultimo caso ´e necess´ario definir regras para o tr´afego que deve ser permitido pela firewall uma vez que a regra final est´a configurada para bloquear o restante tr´afego.

Figura 2.8: Arquitetura NIPS e HIPS Sistemas de Prevenc¸˜ao de Intrus˜oes

Na sequˆencia dos mecanismos de seguranc¸a apresentados at´e aqui, surgem os mecanismos de Detec¸˜ao e Prevenc¸˜ao de Intrus˜oes ou IPS como ser˜ao referidos daqui em diante. Um IPS ´e uma extens˜ao de um IDS [22], na medida em que inclui, para al´em da detec¸˜ao, a capacidade de bloquear tr´afego considerado malicioso.

Sempre que detetada atividade maliciosa, este mecanismo tem a capacidade de modi- ficar ou bloquear pacotes dentro de um determinado per´ımetro ou anfitri˜ao. A sua forma de atuar pode ser comparada `a de uma firewall, tendo em conta a sua capacidade de blo- quear tr´afego malicioso. No entanto, um IPS recorre ao mesmo tipo de mecanismos e regras de um IDS por forma a determinar qual o tr´afego leg´ıtimo ou malicioso.

Alguns autores, tal como Stallings [22], referem que ´e uma quest˜ao de terminologia, considerar-se um IPS como um mecanismo diferente ou apenas um outro tipo de firewall. De forma semelhante ao referido no caso dos IDSs, um IPS pode ser baseado nas seguintes categorias (ver figura 2.8):

• IPS baseado no anfitri˜ao ou Host-based IPS (HIPS): Pode recorrer a um conjunto de assinaturas ou t´ecnicas de detec¸˜ao de anomalias por forma a identificar poss´ıveis ataques. No primeiro caso, foca-se no conte´udo do tr´afego de rede gerado por uma aplicac¸˜ao, procurando padr˜oes/assinaturas que tenham sido identificados anterior-

mente como maliciosos. No segundo caso, de detec¸˜ao de anomalias, o IPS procura padr˜oes comportamentais que indiquem ac¸˜oes maliciosas;

• IPS baseado na rede ou Network-based IPS (NIPS): Numa definic¸˜ao mais pr´atica, um NIPS ´e nada mais nada menos que um NIDS com a capacidade de bloquear tr´afego em tempo real, ou seja, um NIDS inline. Recorre a t´ecnicas de detec¸˜ao por assinatura ou anomalia comportamental.

Snort

O Snort ´e um sistema de prevenc¸˜ao de intrus˜oes de c´odigo-aberto criado em 1998 por Martin Roesch. Desenvolvido pela Sourcefire, da qual Martin Roesch ´e fundador, que foi comprada pela Cisco 10. Os autores Baker, Caswell e Beale [3] referem que esta ferramenta tem a capacidade de analisar tr´afego de rede em tempo real e armazenar logs de pacotes IP.

Permite a an´alise protocolar, pesquisa de conte´udos e a detec¸˜ao de ataques como, buffer overflows, port scans, entre outros. Em resumo, o Snort pode ser considerado um sniffer de pacotes, logger de pacotes ou IPS/IDS de rede. O Snort tem trˆes modos de utilizac¸˜ao: sniffer de pacotes, logger de pacotes (´util para monitorizar tr´afego de rede) e sistema de prevenc¸˜ao de intrus˜oes.

A base do Snort est´a assente no desenvolvimento de regras (ver figura 2.10) que per- mitem detetar e bloquear intrus˜oes. A maioria destas regras s˜ao desenvolvidas pela comu- nidade e s˜ao distribu´ıdas sob a licenc¸a GPLv2 (GNU General Public License) pelo que, qualquer utilizador pode utilizar as regras de forma gratuita. No entanto, algumas regras, desenvolvidas por utilizadores para ambientes muito espec´ıficos, n˜ao s˜ao partilhadas pela comunidade. A arquitetura do Snort consiste, segundo Baker, Caswell e Beale [3], em quatro componentes b´asicas (ver figura 2.9):

• Sniffer: tem como principal funcionalidade a captura de tr´afego. Os autores compa- ram o sniffer com um aparelho utilizado para fazer escutas em telefones, sendo neste caso usado para tr´afego de rede. Tal como qualquer ferramenta de monitorizac¸˜ao de redes, um sniffer de rede pode ser utilizado com fins maliciosos como por exemplo, obter passwords atrav´es da monitorizac¸˜ao de tr´afego que n˜ao est´a cifrado;

• Preprocessor: recebe os pacotes obtidos pelo sniffer e compara-os com determi- nados plugins por forma a identificar comportamentos maliciosos. O Snort utiliza uma vasta quantidade de preprocessors e plugins, cobrindo os protocolos mais co- muns. Depois de associado um pacote a um determinado tipo de comportamento, este ´ultimo ´e reencaminhado para o Detection Engine;

10_{http://www.cisco.com/c/en/us/about/corporate-strategy-office/}

Figura 2.9: Arquitetura do sistema Snort

• Detection Engine: Depois de recebidos os pacotes de todos os Preprocessors, o tr´afego ´e comparado com o conjunto de regras que tem ativadas. Caso algum dos pacotes recebidos fac¸a correspondˆencia com uma das regras, ´e enviada uma notificac¸˜ao para o sistema de alarm´ıstica, notificando o administrador do sistema; • Output: Este ´e o ´ultimo passo do sistema Snort. Quando algum dos eventos anali-

sados corresponde a uma das regras pr´e-definidas, o sistema deve emitir um alerta sendo essa a func¸˜ao desta ´ultima componente. Esta componente permite que os alertas sejam despoletados de diversas formas, como por exemplo, sistemas de log (syslog), ligac¸˜oes de rede, Perl, PHP ou mesmo via email.

Figura 2.10: Exemplo de regra snort - logins FTP (File Transfer Protocol) efetuados com privil´egios de root