São apenas precisos meros minutos para um servidor ligado directamente a internet ser testado por vulnerabilidades e hackers, têm todo o tempo do mundo. Os administradores de sistemas, no entanto, só têm os horários normais do expediente para darem o seu melhor. Mas sem conceitos básicos de segurança, pode-se dar um elemento de déjà vu.
Como toda má notícia corre rápido, recebi uma mensagem que o website do Kero tinha sido hackeado. Então decido passar por lá e boom, realmente o site foi modificado. A primeira vista, parecem só ter acessado o servidor frontend (disponível na internet) em que alteraram as imagens do cache sem terem acessado a base de dados.
Procurando respostas, começo por sondar o servidor para saber como pode ter isso acontecido. A informação inicial sobre o tipo de servidor pode ser obtida carregando a página web com o DevTools do browser, acessível pela tecla F12:
Também podes obter a mesma informação com o comando curl:
> curl -I www.kero.co.ao
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Server: Microsoft-IIS/8.5
X-Powered-By: PHP/7.0.25
Set-Cookie: PHPSESSID=2itg4nknqc8dd9tlpjlm0pn7g4; path=/
X-Powered-By: ASP.NET
Date: Tue, 16 Jul 2019 19:49:55 GMT
Connection: close
A partir da informação obtida, nota-se que o sistema operativo do servidor é Windows Server 2012 R2 ou recente porque o servidor web usado é o Internet Information Services, ou IIS (o IIS 8.5 está disponível desde o Windows Server 2012 R2 e Windows 8.1, dai excluo o último). Como o Windows tem acesso remoto (RDP) e o Linux o SSH, testo a ver se a porta para acesso remoto está disponível e oh meu deus!
Terá sido este o caminho que os hackers usaram? Quem sabe? Não experimentei tentar entrar porque todo administrador deve ter ética. O objetivo deste artigo é alertar aos que cometem as mesmas falhas e mostrar soluções para melhor se protegerem destes erros básicos.
Já havia comentado sobre os riscos que uma empresa corre ao deixar as portas de acesso remoto do Windows disponíveis na internet. O Remote Desktop não possui nenhuma ferramenta de bloqueio ou auditoria de acesso em caso de falha, o que faz dele o caminho perfeito para inúmeras tentativas. E como disse no início, os hackers têm todo o tempo do mundo.
Para além do RDP, a porta do FTP também está aberta, mas não responde e a do MySQL (ou MariaDB neste caso) diz-me que não tenho acesso:
Host '41.43.121.67' is not allowed to connect to this MariaDB server
Connection to host lost.
Isto é de certa forma é mau, porque se houver um bug no MariaDB que me permita passar o acesso restrito por IP, eu consigo acede-lo pela internet. Esta porta não devia estar disponível para fora.
Porque estarão estas portas disponíveis via internet? Presumo que seja para permitir acesso externo ao sistema (consultores, administradores, etc). Se assim for, isto é um trabalho bem desleixado.
Proteger, proteger, proteger#
VPN#
A primeira solução é a mais óbvia: permitir acesso a recursos internos através de uma VPN. Dessa forma, somente o website está disponível na internet e o resto está fora de alcance.
Redireccionamento de portas pelo firewall#
Toda a rede corporativa deve ter pelo menos, um firewall para controlo de tráfego e acesso de e para a internet. O mesmo deve permitir fazer o redirecionamento de portas externas para internas. Dessa maneira, deixas de usar as portas padrão (3389 para RDP, 3306 para MySQL e 21 para FTP) externamente e usas outras à tua escolha, de preferência acima dos 2000. Embora internamente as portas padrão estejam disponíveis, externamente elas estão em portas diferentes.
Atenção que isto não impede as portas de serem encontradas por um scanner. O firewall também pode ser utilizado para restringir o acesso por IP em todas as portas, em vez de ser a aplicação a fazer isso, conforme o caso do MariaDB acima, negando assim a saída de qualquer informação que possa ser útil ao hacker.
O Windows Server traz um firewall, mas é básico e limitado ao servidor, sendo que se precisares bloquear as mesmas portas em outros servidores, terás de refazer as regras em todos os outros servidores.
Segurança de pobre#
Agora a pergunta: mas se eu tiver o servidor ligado diretamente a internet e não tiver/quiser um firewall?
Bem, a maioria das aplicações permite a alteração da porta de acesso. Neste caso vou apenas focar na porta do Remote Desktop que conheço. Mas como conselho, arranja um firewall!
Para se fazer o mapeamento da porta do Remote Desktop, é necessário abrir o Editor de Registo, pressionando Ctrl + Esc e escrevendo regedit para abrir.
Em seguinda, navegas até HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber e escolhes Edit > Modify e clicas em Decimal. Escreves a nova porta de acesso e clicas Ok. Reinicias o servidor e o acesso RDP estará disponível na nova porta de acesso.
Simples não é? Pois, só que a maioria utiliza mesmo a porta padrão. Se fôr o teu caso, dá uma olhada nos logs do Registo de Eventos de Segurança:
Se notares muitos acessos falhados com o ID 4776, precisas de rever as políticas de segurança urgentemente!
Por isso, se escapas ileso da primeira vez, pode ser que da segunda não tenhas tanta sorte, portanto, leva sempre a segurança das portas de gestão expostas na internet a sério.