É possível indicar cópias de scripts feitas por administradores com nomes de cgis + .swp, .bak e .old, tendo acesso ao código dos scripts.
Remover todos os arquivos do tipo .old, .swp e .bak que possam ser lidos por clientes web e também incluir restrições, como:
<Files ~ “\.(bak|old|$” > Order allow,deny
Deny from all </Files>
<Location /server-status> SetHandler server-status AuthType Basic
AuthName “Server Status”
AuthUserFile /etc/apache2/htpasswd Require valid-user
Order deny,allow Deny from all
Ca pí tu lo 5 - S er vi ço s d e R ed es – P ar te 2 Allow from 127.0.0.1 Allow from 192.168.56.0/24 </Location> <Location /server-info> SetHandler server-info AuthType Basic
AuthName “Server Status”
AuthUserFile /etc/apache2/htpasswd Require valid-user
Order deny,allow Deny from all
Allow from 127.0.0.1 Allow from 192.168.56.0/24 </Location>
O Hardening da linguagem PHP apresentado neste capítulo tem como foco um modelo web. Dessa forma consiste, em muitos momentos, em desabilitar recursos poderosos da linguagem PHP que, para um contexto web, não são necessários. Todavia, não é incomum programadores que não levam isso em consideração. Nesse contexto, devemos solicitar que o código seja revisto, pois não se deve aprovar um código que não tenha boas práticas de programação segura ou mesmo use recursos que não são ideais para uma publicação web.
Em suma, todas a sugestões deste capítulo devem ser aplicadas sempre que possível, mas não devemos deixar de aplicar uma configuração em detrimento da segurança, para que uma determinada aplicação que foi mal elaborada seja colocada em produção. É preciso que os programadores busquem informações sobre desenvolvimento usando boas práticas de segurança e customizações de segurança do seu ambiente PHP.
Recomendamos que sejam ativadas na sua área de hospedagem diretivas de PHP inerente à segurança, lembrando que esta poderá afetar diretamente o funcionamento da sua aplicação PHP, pois algumas diretrizes tornam restritivas a ação de algumas funções, o que pode ter como consequência a falha em sua aplicação web, tornando-o parcialmente ou mesmo totalmente inoperante, o que motivará revisão e até mesmo modificação no seu código. Diante disso, devemos avaliar cada mudança que for feita e identificar o impacto em nossa aplicação. Lembramos que não damos suporte à aplicação do cliente.
Seguem algumas recomendações para o php-cgi.ini que se encontra na sua área de hospe- dagem, que só devem se aplicadas pelo programador do site após homologação da aplicação:
# ativar o modo de segurança safe_mode = on
H ar de ni ng e m L inu x
A linguagem PHP pode também ser utilizada para aplicações em ambiente shell, embora não seja a melhor linguagem para esse propósito. Algumas funções são muito poderosas, mas para um contexto web não são recomendadas. Diante disso, é recomendável desativá-las usando a opção “disable_functions” para este propósito, conforme o exemplo:
#desabilitar funcoes
disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_ exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_ isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_ times, posix_ttyname, posix_uname, proc_open, proc_close, proc_ get_status, proc_nice, proc_terminate, phpinfo
#desabilitar mensagens gerais debug – opcional display_errors = Off
register_globals = Off
# desabilitar funcoes de inclusão de arquivos allow_url_fopen = off
allow_url_include = off
# desabilitar funcoes de upload de arquivos file_uploads = Off
# ativar modo de segurança sql sql.safe_mode = Off
Outras recomendações importantes, também inerentes à segurança de sua área de hospedagem:
1 Revise todo o código de sua aplicação web e faça um novo upload, com o máximo de brevidade, pois uma vez que um invasor teve acesso à sua área de hospedagem, ele pode ter inserido trechos de códigos em seus arquivos com o objetivo de permitir acesso arbi- trário, caso o meio pelo qual ele explorou a vulnerabilidade seja corrigido. Esse tipo de artimanha é facilmente implementado usando funções com “passthru”;
Ca pí tu lo 5 - S er vi ço s d e R ed es – P ar te 2
1 Atualize seu antivírus e demais programas que possam identificar Malware, pois está cada vez mais comum a proliferação de Malwares desenhados para interceptar senhas ou mesmo contaminar os programas comumente usados para a publicação de sites. Uma vez interceptada a senha, o Malware passa automaticamente a realizar o download de páginas, inserir modificações e fazer um novo upload;
1 Caso utilize SSH, recomendamos que passe a realizar as conexões utilizando chaves, pois mesmo que um Malware consiga interceptar sua senha e enviá-la para um invasor, sem a chave ele não conseguirá efetuar login em sua área de hospedagem;
1 Dispomos de módulos para segurança específicos para o Apache (servidor web), tais como suhosin e mod_security e estes podem ser configurados em sua área de hospedagem. Diante do que foi relatado, é recomendável que todo o código seja revisto com o máximo de urgência, pois não temos como garantir problemas de segurança vinculados à progra- mação da aplicação do cliente. Podemos, sim, ser reativos e ajudar no momento em que o incidente é identificado, como foi o caso aqui. E esse site se encontra com problemas sérios e vulnerável no que tange à sua programação e na maneira em que as variáveis tratam os dados que são passados. E tenha em mente também que muitas invasões podem motivar problemas maiores, pois uma vez tendo acesso à sua área, o invasor pode usá-la para outros propósitos.
É fato que para eliminar todos os problemas, validando-os de forma a ter certeza que cada vulnerabilidade foi corrigida, é recomendável que o programador durante a fase de testes faça todas as simulações. Por esse motivo, buscamos destacar as linhas de logs mais rele- vantes do incidente. Dessa forma, o programador da aplicação pode analisar como foi explo- rado e, se quiser, pode criar um ambiente de simulação para tentar reproduzir o incidente como prova de conceito de que os problemas foram identificados e resolvidos.
Destacamos alguns links relevantes do site do projeto Open Web Application Security Project (OWASP), que reúne informações muito importantes para desenvolvimento de aplicações web. OWASP – Ataques de PHP Injection:
1 http://www.owasp.org/index.php/Path_Traversal 1 http://www.owasp.org/index.php/Code_Injection 1 http://www.owasp.org/index.php/Top_10_2007-Injection_Flaws 1 http://www.owasp.org/index.php/Comment_Injection_Attack 1 http://www.owasp.org/index.php/Cross-site_Scripting_(XSS) 1 http://www.owasp.org/index.php/Testing_for_IMAP/SMTP_Injection_(OWASP-DV-011) 1 http://www.owasp.org/index.php/Parameter_Delimiter
OWASP – Ataques de SQL Injection:
1 http://www.owasp.org/index.php/SQL_Injection
1 http://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)
Hardening do serviço DNS/BIND
Um servidor de DNS baseado no BIND normalmente exerce uma das quatro funções em uma rede:
1 DNS Autoritativo: sendo o servidor principal de um ou mais domínios; 1 DNS Secundário: responsável pela réplica de domínios;
H ar de ni ng e m L inu x
1 DNS Cache: atuar somente como servidor de consulta; 1 DNS Forwarder: encaminha consultas para outros servidores.
O ideal para implementação de servidores DNS é ter um servidor dedicado para cada função separadamente de outros serviços; dessa forma, a instalação de um Sistema Ope- racional em um servidor que vai suportar um serviço DNS deve ser a mais enxuta possível, devidamente direcionada para seu propósito.
Além das boas práticas de implementação, devemos configurar o BIND com ajuste finos que ajudem e reforcem a segurança de um servidor DNS.