Por que incomodar os aplicativos proxy reversos se você não estiver usando o mod_security ou o TMG / UAG?

4

O senso comum é que os aplicativos internos que vivem dentro da rede confiável, como o Exchange, devem ser proxies reversos sempre que forem expostos à Internet. A Microsoft recomenda o uso do UAG / TMG para isso, pois possui alguns recursos de segurança incorporados. Mod_security tem uma função semelhante nos cenários de proxy reverso do apache. No entanto, vejo muitas instalações em que um proxy reverso é usado, mas essa camada de segurança adicional não é usada.

Por que se preocupar com um proxy reverso nesse cenário? Se você não está usando alguma lógica L7 para atenuar os ataques, quais são os benefícios de adicionar a camada de proxy vs. apenas expondo o aplicativo diretamente?

    
por MDMarra 19.11.2013 / 20:20

2 respostas

4

Do ponto de vista da defesa contra ataques, não filtrar dados de entrada / saída, é claro, não acrescenta nada de valor. Poder-se-ia argumentar que o proxy sem premeditação na verdade reduz a segurança nisso:

  • maior complexidade é introduzida, muitas vezes com uma vingança.
  • menos transparência em que várias camadas de log e alerta precisam de correlação por transação.
  • a superfície de ataque aumenta por meio de subsistemas adicionais.
  • maior diversificação de sistemas aumenta o risco de erro humano.
  • todo sistema carrega erros que introduzem incertezas, proxies não são exceção.

para não mencionar os desperdícios em recursos tecnológicos (máquinas, armazenamento, backup / restauração etc).

Por outro lado, pode haver vitórias relacionadas à segurança de outras formas:

  • Equilíbrio de carga e possibilidades de failover.
  • Maior flexibilidade na separação da camada de acesso da camada de serviço (ou seja, mais fácil de fazer manutenção, reestruturação, etc.).
  • A opção futura de introduzir facilmente a filtragem e outros recursos sem disputa pelos recursos do sistema na camada de serviço.
  • Separar outras funções que a simples filtragem de assinatura de ataque, como a lógica de regravação ou determinados registros, por exemplo, facilitando a configuração e reduzindo os riscos durante a alteração.
  • Certas funções podem ser melhor documentadas ou conhecidas na plataforma de proxy, proporcionando maior estabilidade e controle ou uma redução de incógnitas ao afastá-los do backend.

Tenho certeza de que há mais, apenas do topo da minha cabeça.

    
por 19.11.2013 / 22:21
2

Houve um tempo em que a instalação padrão do Apache simplesmente tinha menos falhas de segurança conhecidas do que uma instalação padrão do IIS; que sozinho foi uma melhoria de segurança.

Assim, pode simplesmente ter se tornado tradição tribal porque já foi uma boa prática.

    
por 20.11.2013 / 00:52