Eu executo um VPS Ubuntu 12.04 x64 com Vesta e um site em PHP. Ele foi hackeado várias vezes com código injetado parecido com este:
<?php $KoDgalxVvsZfidVcEOTJDeMX='ba'.'se6'.'4_deco'.'de';eval($KoDgalxVvsZfidVcEOTJDeMX("cHJlZ19yZXBsYWNlKCIvN0xna0xnND1IR2JEOGs2WDht....
Para consertar, decidi alterar as permissões e o proprietário de todos os arquivos para 555 e root, para que nenhum usuário possa alterar os arquivos. Removi o acesso ao FTP e protegi o SSH para que apenas as chaves que tenho no VPS possam se conectar.
Apesar de todas essas mudanças, outro usuário sempre poderá alterar arquivos, renomear pastas e fazer upload de outro arquivo hackeado.
O que você acha que estou perdendo? Alguma sugestão? Obrigado! Se precisar de mais informações sobre esse assunto terei prazer em compartilhar, para ajudar outras pessoas que sofrem do mesmo mal!
Responder1
Um invasor conseguiu root no seu sistema. Você não pode confiar em NADA no sistema. O escopo do que pode ser feito por um rootkit é vasto.
Se você tiver backups do seu conteúdo em algum lugar, use-os. Caso contrário, você pode esperar que o invasor não tenha bagunçado seus dados. Descarte suas tabelas SQL e copie-as junto com suas outras coisas (jpgs, pdfs, html, mas NÃO quaisquer scripts/php/qualquer outra coisa que será executada). Copie-o para outro sistema ou baixe-o para o seu computador doméstico, se for pequeno o suficiente para poder carregá-lo novamente.
Faça o que puder para verificar se o que você copiou ainda está ok. (como verificar se os jpgs ainda são jpgs válidos, só para garantir. Talvez executar um antivírus neles?)
Elimine a instalação comprometida. Se o seu servidor estiver hospedado em um serviço de hospedagem típico, esperamos que eles tenham tudo configurado para que você tenha um painel de controle que não possa ser bagunçado nem mesmo pelo root no host. Portanto, você pode esperar que o invasor não tenha conseguido tocar em nada fora da máquina que comprometeu. (Se você tivesse acesso sem senha a qualquer outra coisa configurada naquela máquina, verifique-a.)
Faça o que for necessário para fazer uma nova instalação. É melhor mudar para o Ubuntu 14.04 LTS, já que você terá que reinstalar de qualquer maneira.
NÃO copie nenhum código do sistema comprometido para o novo sistema. Todos os dados provenientes do sistema comprometido devem ser tratados como um potencial portador da peste.
A semântica do sistema de arquivos Unix requer permissão de gravação no diretório para remover arquivos. (nomes de arquivos são links de um nome para um inode. A chamada do sistema para criar hardlinks (outros nomes para um arquivo) élink(2), e a chamada para remover um arquivo éunlink(2).)
Se o sticky bit estiver definido em um diretório ( chmod +t) unlink(2)e rename(2)também exigir que o chamador possua o arquivo a ser desvinculado ou renomeado. (independentemente da permissão de gravação no arquivo). É padrão para /tmpe /var/tmppara ser 1777(gravável mundialmente com conjunto de bits fixos).
rm, o comando shell, é exigido porPOSIXpara avisar antes de desvincular arquivos somente leitura, mas é necessário verificar esse caso. Na verdade, ele não precisa fazer nada além do unlink(2)que faria com qualquer outro arquivo. Portanto, não se iluda pensando que isso tem algum efeito sobre o adversário.
Nada disso é muito relevante para a defesa contra ataques, porque o caso mais provável é obter o controle do processo do seu servidor web ou de algo que esteja sendo executado com um ID de usuário que tenha acesso de gravação a muitas coisas.
Quanto mais você limitar o que pode ser escrito por processos que precisam lidar com dados da Internet, menor será a chance de um invasor passar de obter o controle do seu httpd para modificar seus dados ou obter o controle de toda a sua máquina.
É por isso que você não deve executar o Apache como root.
Responder2
Se você puder evitá-lo, não deverá executar os processos do servidor web como usuário root, pois isso significa que o comprometimento de qualquer vulnerabilidade no serviço web comprometerá completamente o servidor.
Com onde você está agora, recomendo começar do zero em um novo servidor - o invasor poderia ter obtido acesso root persistente por meio de vários métodos. VeraquiPara maiores informações.
Responder3
Apesar de todas essas mudanças, outro usuário sempre poderá alterar arquivos, renomear pastas e fazer upload de outro arquivo hackeado.
Se o diretório pai da raiz da web pertencer ao mesmo usuário que executa o servidor web, essas permissões do diretório pai substituirão quaisquer permissões definidas para arquivos e diretórios filhos.
Por exemplo, abra um processo “Terminal” em qualquer diretório de sua propriedade. Agora crie um arquivo chamado zzz_test.txtassim:
touch zzz_foo.txt
Agora verifique o arquivo assim:
ls -la zzz_foo.txt
As permissões - no meu caso - são assim:
-rw-r--r-- 1 jake staff 0 Feb 23 19:11 zzz_foo.txt
Então eu corro chmodassim:
chmod 555 zzz_foo.txt
Agora execute ls -lanovamente e o resultado ficará assim:
-r-xr-xr-x 1 jake staff 0 Feb 23 19:11 zzz_foo.txt
Ok, as permissões foram alteradas. Então vamos fazer algo “louco” como tentar excluí-lo:
rm zzz_foo.txt
A resposta seria:
override r-xr-xr-x jack/staff for zzz_foo.txt?
E aí é só bater ye apertar returne viola! O arquivo desapareceu.
É por isso que simplesmente alterar as permissões dos arquivos nunca será uma forma eficaz de proteger um servidor web. A natureza simples da forma como os servidores web funcionam – especialmente se for baseado em PHP – significa que o usuário do servidor web sempre terá acesso de leitura e gravação aos arquivos que precisa acessar. Portanto, simplesmente ir chmod 555 [some files]é uma forma ineficaz de “defender-se” contra malware e tentativas de hacking.
Quanto ao que você pode fazer agora? Bem, simplesmente alterar as permissões e a propriedade não significa nada. O maior problema é que sua base de código PHP é vulnerável a ataques. Portanto, a única maneira eficaz de limpar esse tipo de coisa é limpar seu código PHP. Se este site for baseado em uma estrutura pronta como Joomla!, WordPress ou CakePHP, então o melhor curso de ação é atualizar a estrutura principal do Joomla!, WordPress ou CakePHP para bloquear a segurança. Da mesma forma, se houver um plugin Joomla!, WordPress ou CakePHP que seja vulnerável a ataques, esse plugin deve ser atualizado/corrigido para tapar o buraco.
E além de tudo isso, o software principal do sistema – supondo que seja uma pilha LAMP (Linux Apache MySQL PHP) – deve ser mantido atualizado e corrigido também.
No final das contas, a segurança do site não é algo que ocorre apenas uma vez. É uma mentalidade geral e um processo de manutenção que deve ser seguido. Caso contrário, quando seu site for hackeado, você ficará sem cabeça tentando limpar a bagunça, o que pode realmente causar mais danos do que a própria incursão inicial do malware.
Responder4
Concordo em recomeçar com a opção de servidor, mas se você quiser mais segurança e controle, um servidor dedicado é uma ideia melhor.
Quanto à sua situação, a primeira coisa que sugiro é desabilitar todos os serviços em execução, exceto o acesso ao shell. Isso significa interromper o serviço FTP, o servidor web (HTTP), e-mail, etc. Em seguida, entre no shell e navegue até as pastas que contêm os itens que você alegou estarem sendo hackeados. então digite:
ls -al
Você deverá ver algo semelhante ao seguinte nos resultados:
drwxrwxrwx 2 root root 4096 2014-10-10 00:31 ./
Se o quarto item (ou especialmente o terceiro item) for realmente "root", então você está com sérios problemas e precisa refazer a configuração do servidor web para que ele execute as coisas como usuários diferentes, dependendo da pasta. Você deve procurar mod_rewrite (ou similar) para o apache e depois ajustar seu arquivo de configuração do apache (httpd.conf) de acordo para que o sistema altere o nome de usuário quando cada solicitação à pasta for feita. Em seguida, altere o nome de usuário e o nome do grupo da pasta de acordo.
Depois que isso for corrigido, navegue até a pasta raiz do documento (provavelmente public_html), use um editor (pico funciona) e digite o seguinte:
<?php
echo shell_exec("whoami");
?>
então salve-o como who.php. Em seguida, ligue o servidor web e em qualquer navegador, vá para a página inicial do seu site, mas adicione who.php ao final e você verá apenas uma palavra na tela. Se essa palavra for raiz, então você está com sérios problemas e precisa seguir as etapas acima novamente. Se a palavra for ninguém, você terá problemas porque os hackers conhecem muito bem esse nome de usuário.