Firewalls de aplicação costumam ser computadores de uso geral que
rodam programas especiais chamados "proxy servers". Cada aplicação
abilitada na configuração de firewall – SMTP (correio), HTTP (Web),
FTP, Telnet etc. – exige um proxy server específico que
supervisione a porta IP por onde passam os pacotes referentes àquela determinada aplicação. Este tipo de firewall não permite tráfego
direto entre duas redes: toda comunicação requer o estabelecimento de
duas conexões, uma entre o remetente proxy e a outra entre o proxy e o destinatário. O proxy correlaciona a duas comunicações
através do número da sessão TCP (que está presente em todos os
pacotes) e ecoa os dados que vêm da conexão x para a conexão y e
vice-versa. O que é importante é que todo pacote, antes de ser ecoado
de uma conexão para a outra, é analisado pelo proxy server – um
programa para detectar abusos de segurança no protocolo utilizado
naquela porta específica - , que decide se o pacote deve passar ou ser descartado. O resultado é que o firewall de aplicação consegue detectar
riscos que um firewall de rede não teria como perceber, alcançando
um nível de segurança superior.

    Um exemplo clássico do tipo de informação que um proxy pode
filtrar é o comando DEBUG do SMTP, usado para solicitar a
um servidor de correio que forneça certas informações de controle e considerado arriscado pela maior parte dos administradores de rede.
Como não é normal que esse tipo de comando seja emitido durante uma
troca de mensagens de correio, um bom proxy SMTP descartará o pacote
com o comando proibido, mudará o estado do firewall para "ataque em
curso" e enviara uma mensagem (que pode até seguir para um pager
ou telefone celular) para o administrador, prevenindo-o do ocorrido.

    Outro exemplo são proxies FTP, que podem vedar completamente o
acesso de usuários externos ás maquinas da empresa ao mesmo tempo que permite que funcionários copiem arquivos da Internet para a rede
interna (comando GET), mas não o contrário (comando PUT).
Todos esses exemplos estão ligados ao funcionamento dos
protocolos específicos de cada aplicação e não poderiam ser
implementados em firewalls de rede, que não são capazes de examinar o conteúdo dos pacote IP.

    Firwalls de aplicação são bem menos transparentes do que
firewalls de rede. Para começar, toda e qualquer aplicação
exige a existência de um proxy; se o usuário precisa de uma aplicação
para a qual não existe um proxy rodando no firewall, não há o que fazer:
a aplicação simplesmente não funcionará. Em um mundo onde há novas aplicações sendo lançadas todos os dias, este tende a ser um problema considerável, e o resultado é que os fornecedores sempre têm uma
nova versão (esta suporta SSL, a próxima suportará RealAudio, a
seguinte suportará SQL) do firewall.

    Quando é necessário usar uma aplicação para a qual o fornecedor
do firewall não tem (nem terá) um proxy específico, a solução é a
utilização de um proxy genérico. Criar um proxy genérico é simples:
trata-se tão somente de informar ao firewall que quaisquer pacote
trafegando entre as maquinas x (internas) e as maquina y (externas) que
usem a porta z são confiáveis e podem passar. Apesar de tais pacotes
serem roteados sem uma análise cuidadosa (similar ao que faria um
firewall de rede), trata-se de um procedimento razoavelmente seguro,
porque a comunicação não monitorada é duplamente restrita: não apenas
ocorre numa única porta IP, como só envolvem maquinas de confiança
– afinal, se o fornecedor não fosse de confiança não
seria contratado.

    Como não permite comunicação direta entre o cliente e o servidor, o firewall de aplicação é consideravelmente menos transparente que o
firewall de rede. É necessário que o programa cliente saiba que deve estabelecer uma conexão com o proxy e determinar ações como
"conecte-se ao servidor Web do UOL e recupere a página tal para mim".
Quando o cliente sabe isso; como é a maioria dos browsers Web, basta configurá-lo corretamente. Quando os clientes são poucos
sofisticados e exigem conexões diretas com o servidor (como é comum
com FTP e Telnet, por exemplo), utiliza-se um artifício: o usuário
se loga no proxy e este; uma vez solicitado nome e senha (como seria de esperar), solicita o nome do servidor com o qual se
deseja a conexão; a partir daí, tudo funciona normalmente.

    O firewall de aplicação oferece algumas vantagens sobre o firewall de rede. A primeira e mais importante é permitir um acompanhamento
muito mais próximo e efetivo das comunicações entre duas redes,
inclusive com logs e relatórios de auditoria. O fato de o DNS ser
também um proxy server permite que os nomes das maquinas internas
sejam preservados e que um mesmo nome possa identificar duas máquinas diferentes da origem de quem consulta, se um usuário interno ou externo.

Além disso, como toda a comunicação é ricocheteada pelo firewall,
o mundo só precisa saber de um único endereço IP (o da porta externa do firewall), e os verdadeiros endereços das máquinas internas podem ser protegidos, trazendo vários benefícios. Para começar, o simples desconhecimento dos endereços reais reforça a segurança. Melhor ainda é
que isso permite o uso de faixas reservadas de endereços que,
por convenção, não podem ser utilizadas na Internet. Neste caso, é
virtualmente impossível para o cracker enviar pacotes diretamente às máquinas da rede interna. E o uso de endereços protegidos também
possibilita a atribuição de mais endereços do que os concedidos originalmente pelo provedor de acesso.

    Na verdade, a discussão sobre qual é o melhor firewall, se o de rede ou o de aplicação, não procede, porque eles não representam soluções
mutuamente excludentes. Os melhores sistemas de firewall, como
seria de esperar, adotam ambas as abordagens, permitindo a
definição de regras, controles e auditorias nos dois níveis.