Security best pratices

Para finalizar a série de posts relacionados com segurança faço algumas pequenas considerações sobre pontos simples, pequenos, porém igualmente importantes para deixar seu servidor mais seguro e à prova de malandragem virtuais. Daqui em diante irei postando coisas relacionadas à segurança sem no entanto me ater a uma seqüência ou série específica.

1) Nos posts passados falei sobre a importância de se deixar o debug options “desligado” no ColdFusion Server. Muitos se esquecem de fazê-lo e isso significa deixar informações valiosas disponíveis para visitantes mal intencionados. Um servidor de produção não deve estar com o debug disponível para todos os IP’s. Quanto menos o malandro do cyberspace souber sobre o seu servidor, melhor para você. “Desligar” o debug no CFServer é uma operação extremamente ridícula, porém negligenciada por muitos. Para fazê-lo basta adicionar um número de IP qualquer na seção “debugging IP’s”. Uma boa sugestão é adicionar o IP loopback da própria máquina (127.0.0.1). Pronto, dessa forma você limita o acessoa informações de erro tais como local físico dos scripts, tipo de servidor, queries SQL e verdadeiros “informes” sobre como é o seu servidor por dentro, tal como você pode ver neste exemplo aqui.

2) Nas versões anteriores ao CFMX, existe um furo de segurança leve, mas que deve ser considerado para aumentar ainda mais a segurança do seu servidor. Ele permite que o visitante, mesmo com o debug desligado, possa conhecer o local físico dos arquivos/scripts do site. Por algum motivo estranho, quando você solicita um arquivo com nomes reservados ao DOS (nul e prn, por exemplo) o ColdFusion retorna uma mensagem de erro diferente, contento a informação de path do scrip: veja este exemplo. Mesmo se você configurar um missing template no ColdFusion Administrator, você terá acesso a esta informação. A solução para este pequeno problema é, também, bem simples. No IIS (se você estiver usando um) vá até o WebSite em questão, clique em “properties” -> “Home Directory”. Em “Application Settings”, clique no botão “Configuration”. Clique no mapping para a extensão “.cfm” e selecione a opção “Check that file exists”. Pronto, agora qualquer erro 404 será direcionada para a página de erro 404 padrão do IIS. Minha recomendação é que se deixe esta opção sempre habilitada em qualquer mapping, não causa perda de performance e você torna o seu servidor web mais “coeso” nas respostas de erro 404.

3) Essa eu nem precisava falar, mas tem muita gente que deixa o ColdFusion Administrator ESCANCARADO para quem quiser visitá-lo. PROTEJA-O JÁ! O diretório CFIDE/Administrator/ deve contar com pelo menos três camadas de proteção, a primeira a própria senha do CFADM, a segunda a proteção de diretório por senha do sistema e a última (se possível) com permissão de acesso apenas a IP’s específicos. Eu ainda coloco uma “quarta” camada de proteção: SSL, acessando o CFADM via https voce protege as senhas de serem “snifadas” em uma rede insegura (Vírtua, por exemplo). Fico impressionado em ver provedores de renome deixando esta opção aberta para que qualquer um possa brincar de brute-force no campo “password”. Lembrem-se de que o CFADM possui apenas uma mísera senha (sequer tem um username). Já consegui acesso a um servidor destes com apenas 6 horas de brute-force rodando na minha máquina. Veja um exemplo de escancaramento aqui.

4) Não instale nenhum exemplo! O ColdFusion Server vêm com uma série de templates de exemplos que podem ser instalados no seu servidor. Eles estão localizados sob a pasta CFDOCS. É recomendável que você NÃO instale tais exemplos no servidor de produção (servidor que fica exposto à internet). Na versão 4.5 o ColdFusion trazia, nestes exemplos, um template que permitia qualquer usuário anônimo fazer um upload (através de CFFILE) no servidor e em qualquer pasta. Isso é uma séria ameaça à segurança do seu servidor por isso não instale aquilo que você não conhece totalmente, independentemente da versão do CF ou mesmo de outros produtos. A velha máxima é a que vale: se não vai usar, não instale.

5) Desabilite o serviço RDS! Mesma coisa. Prefira outras formas de acesso ao seu servidor de produção (FTP, por exemplo). O RDS pode ser mais um dos caminhos que um malandro pode escolher para brincar com a sua máquina, por isso mesmo desligar (seja não instalando-o ou desabilitando o serviço RDS) é uma boa medida de precaução.

Por fim sempre que tiver alguma dúvida sobre segurança em suas aplicações, escreva!