A figura central de uma Intranet, quando se trata de conexões Internet, é muitas vezes um Proxy Server, pois será através dele que as máquinas da Intranet terão acesso a Internet, como mostra a figura 4.1.

Como o Proxy Server concentra todas as conexões enviadas e recebidas da Internet, será nele que os mecanismos que barram o recebimento de conteúdos executáveis estão desenvolvidos. Estes mecanismos barram o recebimento dos conteúdos executáveis descritos no capítulo 2, sendo eles : Applet Java, JavaScript, ActiveX, VBScript e ShockWave. Os mecanismos criados são baseados na premissa de que o recebimento de qualquer conteúdo executável das tecnologias acima descritas através da Internet é proibido, a não ser que seja explicitamente permitido. A partir desta premissa delimita-se que os conteúdos executáveis incorporados nos protocolos das aplicações só serão recebidos da Internet se o administrador da ferramenta previamente configurá-la para isto.

4.1 Bloqueio aos conteúdos executáveis

Para o bloqueio dos conteúdos executáveis os filtros estão implementados para impedir que os conteúdos executáveis descritos no capítulo 2 sejam recebidos da Internet. Os filtros implementados no Proxy Server procuram nos documentos HTML que foram solicitados pelas máquinas da Intranet os marcadores que identificam cada uma das tecnologias, como descrito na tabela 4.1. Quando o recebimento não autorizado de um conteúdo é detectado, o código HTML é modificado e substituído por uma explicação, como é detalhado adiante.

TECNOLOGIA MECANISMO DE BLOQUEIO
Applet Java (*) Pelos marcadores
JavaScript Pelos marcadores
ActiveX Pelos marcadores
VBScript Pelos marcadores
ShockWave Pelos marcadores
Tab 4.1 Métodos que são utilizados pelo filtros para barrar o recebimento de conteúdos executáveis

(*) - Este mecanismo tem um inconveniente, pois a linguagem JavaScript pode ser usado para montar ataques em sistemas que bloqueiam a entrada de Applets Java, como foi visto no item 3.2, mas como esta ferramenta também barra o recebimento de JavaScript, o método se torna seguro.

4.2 Permissões de Acesso

As permissões de acesso serão inteiramente baseadas nos endereços IPs das máquinas servidoras que possuem conteúdos executáveis para serem acessados e recebidos. Estas permissões funcionam da seguinte maneira:
Pelo Endereço IP de uma máquina : Para que os conteúdos executáveis de um único servidor da Internet possam ser recebidos pelas máquinas da Intranet, o endereço IP do servidor deverá estar configurado na tabela de endereços IPs permitidos;
Pela Classe de Endereços IP : Para que os conteúdos executáveis dos servidores de uma rede de computadores da Internet possam ser recebidos pelas máquinas da Intranet, a classe de endereços Ip da respectiva rede deverá estar cadastrada na tabela de endereços IPs permitidos.
Como o número de tecnologias existentes para a construção de conteúdos executáveis é grande, será necessário que o administrador da ferramenta informe também quais serão as tecnologias aceitas. Assim para cada endereço ou classe de endereços IP o administrador terá que informar quais serão as tecnologias aceitas.
Mesmo que os conteúdos executáveis sejam recebidos somente de máquinas conhecidas, pode-se tomar a precaução de barrar a entrada pelo seu nome. Através desta opção poderão ser barrados os conteúdos executáveis mais conhecidos na Internet e que já foram noticiado como causadores de ataques às máquinas dos usuários que os acessam, tais como os Applets Java, os ActiveX e os ShockWave.

4.3 Mecanismo adicional

Como esta ferramenta está se baseando nos conteúdos executáveis existentes no momento de sua implementação, possivelmente no futuro surgirão algumas outras tecnologias que adicionarão vulnerabilidades às máquinas dos usuários que as receberem através da Internet. Para tentar reduzir estes riscos será deixado um espaço reservado para serem colocadas regras adicionais para o recebimento de documentos, sendo necessário que o administrador desta ferramenta configure quais serão os marcadores (Tags) que deverão ser analisados e substituídos, pois como foi visto, substituindo os conteúdos executáveis que estão entre os marcadores (TAGS) que identificam a tecnologia evita-se que ataques possam ser praticados às máquinas dos usuários através dos conteúdos executáveis.

4.4 Detalhamento das Proibições

Como os conteúdos executáveis recebidos da Internet podem ser barrados na entrada da Intranet, como mecanismo de explicação para o não recebimento dos mesmos, para cada regra implementada pela ferramenta é deixado um espaço textual disponível para que os códigos recebidos sejam trocados, isto é, ao invés do usuário receber o conteúdo executável da Internet, ele receberá uma explicação do motivo pelo qual não foi possível o recebimento do conteúdo executável.

4.5 Interface

O ambiente no qual é gerada a Interface de configuração para as regras de funcionamento do mecanismo é um servidor WWW disponível na mesma máquina em que o Proxy Server está sendo executado. Através dos formulários HTML é criada uma interface na qual é possível configurar todas as funcionalidades da ferramenta proposta, não havendo a necessidade do administrador acessar diretamente os arquivos de configuração, possibilitando também uma administração remota.
Para a restrição de acesso às paginas de configuração da ferramenta proposta, faz-se necessário o controle através de chave e senha, no qual somente algumas pessoas autorizadas terão acesso. Este mecanismo de autenticação através de chave e senha para a configuração da ferramenta interage diretamente com o sistema de segurança da máquina Unix.
Por questões de segurança no acesso as informações, todas as páginas HTML que são mostradas pela ferramenta são armazenadas em outra área do disco, não fazendo parte da estrutura de diretório do servidor WWW. Estas páginas estão salvas sem a extensão padrão ".html ou .htm", para não serem identificadas. Como elas não possuem a extensão característica das páginas HTML nem fazem parte da estrutura padrão de diretório do servidor WWW, é impossível que elas sejam acessadas diretamente através de um Browser WWW, sendo o seu acesso possível somente através de um programa CGI que monta estas páginas sabendo em quais arquivos elas estão armazenadas e em quais diretórios da máquina Unix é possível encontrá-las. Existe uma exceção para esta regra, isto é, somente a primeira página é acessível diretamente através do servidor WWW, pois será através dela que todas as demais funções são acessadas. As demais páginas da ferramenta só serão acessadas se a chave e a senha do administrador forem informadas.

5. CONCLUSÃO

Por mais que existam ferramentas que consigam bloquear algumas das tecnologias mencionadas neste documento, como é o caso das Firewalls e de alguns anti-vírus, sempre aparecerá uma nova tecnologia ou a combinação delas que serão utilizadas para aplicar ataques aos usuários da Internet.
Para que os resultados destes ataques fossem minimizados, pois um controle efetivo sobre todos os Browsers WWW de uma Intranet é inviável, surgiu a solução exposta no sessão 4 deste documento, que barra o recebimento de conteúdos executáveis na entrada da Intranet, deixando passar somente quando o local de origem do conteúdo executável é conhecido e foi configurado pelo administrador da ferramenta para que o seu recebimento fosse aceito.
Esta não é a melhor solução para o problema uma vez que a melhoria da qualidade dos documentos que utilizam conteúdos executáveis é substancial, e a solução proposta na sessão 4 garante a segurança mas restringe o recebimento destas tecnologias somente de locais conhecidos. Por mais que um conteúdo executável seja confiável, se não fizer parte da relação de locais conhecidos e autorizados, seu recebimento é negado.
Existem alguns estudos que incluem assinaturas digitais nos conteúdos executáveis para os mesmos possam identificar a origem, como é o caso dos controles ActiveX, mas mesmo assim isto não resolve os problemas de segurança gerados pela utilização destas tecnologias, pois por mais que um código tenha uma assinatura digital ninguém garante o resultado de sua execução.
Para resolver os problemas qualquer conteúdo executável que fosse recebido por um Browser WWW deveria passar por Modelos de Segurança padrão criado no Browser WWW para a execução dos mesmos, como é mostrado na figura 5.1. Este modelo de segurança é que iria permitir que um conteúdo executável pudesse ser processado, independe da tecnologia que foi utilizada para a criação do mesmo.
Para isto uma padronização no uso dos conteúdos executáveis é necessária, isto é, os conteúdos executáveis primeiramente seriam executados e analisados pelo Modelo de Segurança para depois sua execução ser aplicada ao Browser WWW.
Isto tira das linguagens que desenvolvem conteúdos executáveis a tarefa de criar mecanismos alternativos para resolver os problemas de segurança gerados por soluções mal projetadas e muitas vezes mal implementadas.

BIBLIOGRAFIA