Re: [Tech Quiz] Qual é a razão pela qual...

(Tenho que admitir, desde já, que esta nota é muito techie e low-level. Perdoem-me os leitores que ficarem à nora com esta descrição, ok? Esta coisa da segurança tem um âmbito muito abrangente e os níveis de detalhe e profundidade podem variar imenso, desde as águas mais profundas até ao mar junto à praia, mais ameno e apetecível para os humanos. E sei que desse lado do fio encontram-se Gregos, Gregas e Troianos : ) … )

Quando pensei neste quiz, sobre a inadequação de um filtro sem-estado para controlar o protocolo de transferência de ficheiros, o que tinha em mente era o problema que nasce com as regras de filtragem para a versão activa do protocolo. Dito de outra forma, considerando os filtros inbound que são necessários para permitir o acesso outbound a um FTP activo (ou seja, o acesso a partir do interior de uma organização até ao serviço num equipamento remoto), considerando esses filtros, é necessário estabelecer uma regra (ou uma variante de uma regra) do tipo allow tcp from any port 20 to any inside (ou, se a comunicação for mediada por uma proxy, qualquer coisa como allow tcp from any port 20 to proxy inside . Porquê? Porque um stateless filter não sabe, num dado momento, se deve (ou não deve) admitir uma comunicação de retorno de um FTP activo – como não tem memória, não sabe se essa comunicação surge como resposta a um pedido de ligação interno ou, em alternativa, se é uma ligação arbitrária.

A ausência de memória destes equipamentos obriga-nos a definir regras muito perigosas. Porquê? Porque as regras anteriores legitimam, na prática, a comunicação total com o interior (ou com a proxy) a partir de qualquer máquina na Internet.

A forma de mitigar esta limitação, se quisermos mesmo usar um stateless packet filter, passa por impedir a utilização de transferências activas e, assim, utilizar apenas a variante passiva do protocolo FTP (que não depende de ligações inversas para estabelecer a comunicação – é equivalente ao HTTP, por exemplo, que depende apenas de uma ligação outbound ao porto 80. No caso do FTP, o porto 21).

Esta era a ideia inicial quando pensei no quiz. No entanto, nas respostas que foram publicadas, destacaram-se duas questões igualmente interessantes, nomeadamente, a inadequação genérica da utilização de filtros sem-estado e, também, a inadequação do protocolo FTP para a transferência de ficheiros, em virtude da exposição dos dados e, em particular, da exposição das credenciais dos utilizadores no momento da autenticação ao serviço. Em relação a estas questões – que são questões relevantes! – vou aproveitar a oportunidade para escrever mais alguns pontos. São os seguintes:

  1. Um stateless packet filter não é uma boa solução para filtrar as comunicações que entram (e saem) de uma organização, i.e., não substitui uma statefull deep packet inspection firewall. Porquê? Porque a ausência de memória impede o acompanhamento das ligações legítimas que são estabelecidas, por um lado, e, por outro lado, não analisa o conteúdo dos pacotes em profundidade;
  2. No entanto, apesar de não substituir uma firewall, considerando que é um equipamento de alto desempenho, baixo custo, e com características que lhe permitem resistir mais facilmente aos ataques de negação de serviço, pode ser utilizado, em alguns casos, para limitar a chuva de areia que atinge a firewall corporativa. Como? Colocando-o à frente dessa firewall e, assim, filtrar todos os pacotes de dados que voem na sua direcção mas que sejam irrelevantes (que sejam irrelevantes mas que, infelizmente, gerem milhares de registos e que possam degradar o desempenho da firewall principal);
  3. Nesse cenário, e em organizações que pretendam reforçar a segregação de funções dos seus colaboradores, a gestão do packet filter e da firewall pode ser atribuída a equipas diferentes e, dessa forma, obrigar à intervenção de dois elementos autónomos sempre que existir a necessidade de mudança das regras de filtragem;
  4. No que concerne a utilização do protocolo FTP, é necessário conduzirmos uma análise segundo 3 vectores, designadamente, (i) o mecanismo de autenticação dos utilizadores (sempre que a autenticação for necessária, bem entendido), (ii) o mecanismo de protecção dos dados em trânsito na rede (novamente, se essa protecção for necessária) e, finalmente, (iii) a utilização da variante activa versus a variante passiva. Nessa análise temos que ponderar o seguinte:
  5. O mecanismo de autenticação dos utilizadores não protege as suas credenciais enquanto são transmitidas, e, por essa razão, torna-as vulneráveis à captura e reutilização por pessoas não-autorizadas. Esta característica torna o protocolo absolutamente inadequado na Internet e, também, na maioria das redes internas das organizações. A sua adopção, mesmo nas intranets, deve ser evitada;
  6. O protocolo não protege a informação em trânsito na rede. Por isto, não deve ser usado para transmitir informação sensível. No limite, se houver uma razão específica para adoptar o FTP, a informação transmitida deve ter um caracter estritamente público;
  7. No seguimento do que analisámos no início deste apontamento, a variante activa do protocolo exige o estabelecimento de uma ligação inversa, do exterior para o interior, para efectivar a comunicação. Mais, esta ligação, apesar de partir de um porto conhecido (porto 20), termina num porto aleatório, na máquina que solicitou o serviço. A variante passiva não exige este requisito. Assim, se for mesmo necessário adoptar o FTP, e em face do risco subjacente à admissão de ligações inversas, é preferível utilizar sempre a variante passiva; Finalmente,
  8. Considerando que existem soluções com funcionalidades equivalentes mas com características mais seguras, nomeadamente, o SFTP (que protege as credenciais e os dados em trânsito, e que não depende de ligações inversas), é preferível realizar soluções de transferência de ficheiros com uma destas alternativas do que, considerando o que foi dito até aqui, continuar a usar o FTP.

E pronto, ce ça. Obrigado por terem contribuído com os vossos comentários a este desafio. E se quiserem continuar sobre este apontamento, já sabem, be my guestsit's always good to know one is not alone. Cheers! ; )