Fui informado hoje pela DigitalOcean que meu Droplet foi desconectado porque estava realizando um ataque DDoS.
Eles me pediram para investigar e descobrir o que estava causando isso.
Este era o Ubuntu 14 e eu tinha 6 Apache VirtualHosts lá. Todos estavam ao vivo.
Um dos meus sites era uma instalação do WordPress com alguns plug-ins.
Outro site continha algum código da API do Google Maps.
O resto continha apenas meu código original.
Ainda não entrei no servidor. Depois disso, qual seria o processo para encontrar corretamente o software que está causando isso?
Suspeito que isso aconteceu porque não estava usando uma chave SSH com minha senha.
Responder1
Primeiro, minhas condolências por ter que lidar com algo assim. Mas você pode limpar isso. Primeiro, só preciso resolver isso:
Suspeito que isso aconteceu porque não estava usando uma chave SSH com minha senha.
99% de certeza de que não é o caso. Praticamente todos os comprometimentos de servidores web com os quais lidei pessoalmente - e limpei - ao longo dos meus mais de 20 anos de experiência vieram de falhas no nível do aplicativo enãoqualquer coisa conectada a SSH ou SFTP. Na verdade, a maioria dos desenvolvedores/administradores da web nunca lidará com comprometimentos de nível SSH/SFTP; falhas no código frontal são o principal ponto de entrada para muitos malwares e incursões injustificadas em sistemas públicos da web.
E no seu caso você afirma o seguinte:
Este era o Ubuntu 14 e eu tinha 6 Apache VirtualHosts lá. Todos estavam ao vivo.
Um dos meus sites era uma instalação do WordPress com alguns plug-ins.
Outro site continha algum código da API do Google Maps.
Meu palpite é que – a menos que você se mantenha atualizado sobre as atualizações/patches do WordPress – suas instalações do WordPress estarão vulneráveis. E não apenas o núcleo do WordPress, mas também os plug-ins.
Faça backup da base de código, banco de dados e configurações existentes.
A primeira coisa que eu faria seria neutralizar os hosts virtuais do Apache, talvez definindo um index.phpque diz “Inativo para manutenção” em cada um dos índices raiz desses sites. Eu também faria uma cópia de cada instalação de host virtual por meio de um arquivo TAR/Gzip e faria o download para possível análise forense. Isso deve ser feito para todos os servidores virtuais Apache, incluindo dumps dos bancos de dados MySQL e arquivos de configuração relevantes.
Verifique o /tmp/diretório em busca de sinais de infecção; explodi-lo se necessário.
A próxima coisa que eu recomendo que você faça é despejar e recriar o /tmp/diretório no servidor. A razão é que muitas infecções de malware em servidores web Linux colocam uma boa parte de sua carga útil no /tmp/diretório. Eu vou mais fundonesta resposta aquimas tudo se resume a fazer o seguinte.
Então, primeiro, olhe no /tmp/diretório e veja se há algo que não deveria estar lá. 9 em cada 10 malwares em sistemas Linux serão capazes de se instalar em arquivos /tmp/.
Se você não tiver certeza do que deveria/não deveria estar lá /tmp/, há uma coisa fácil - mas extrema - que você pode fazer para eliminar as coisas ruins. Basta executar isso online na linha de comando:
rm -rf /tmp && mkdir /tmp && chown root:root /tmp && chmod 1777 /tmp
Ou execute cada comando individualmente assim:
sudo rm -rf /tmp
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp
Em seguida, reinicie o servidor para ver se isso esclarece as coisas. Se isso acontecer, parabéns! Mas você ainda não está fora de perigo, pois o que quer que tenha causado o sistema original ainda pode penetrar em seu sistema, é apenas uma questão de tempo até que eles o reinfectem novamente. Ou seja, isso limpa a bagunça causada por uma fraqueza no seu sistema, mas você precisa descobrir qual pode ser esse ponto fraco e fortalecê-lo.
Verificações de vulnerabilidade “shellshock” do Bash.
E nessa outra resposta forneço dicas sobre como verificar basha vulnerabilidade “shellshock”.Este site fornece boas ferramentas de testepara ver se o seu servidor está vulnerável a bashexplorações “shellshock”. Honestamente, esta foi uma das falhas de segurança mais comuns que tive de corrigir desde que foi descoberta. Portanto, há uma boa chance de que isso também seja um ponto fraco no servidor. Para saber como corrigir bashvulnerabilidades, se encontradas, consulte a seção abaixo sobre como atualizar/corrigir todos os componentes no nível do sistema operacional. Faça isso e bashtambém deverá ser atualizado/corrigido.
Atualize/corrija todos os componentes do nível do sistema operacional.
Isso pode parecer assustador, mas a realidade é que patches de segurança são lançados o tempo todo para sistemas Linux. E se você estiver usando uma instalação Linux padronizada como Ubuntu ou CentOS, você pode simplesmente executar uma atualização/atualização por meio do instalador de pacotes como este. No Ubuntu basta fazer isso:
sudo apt-get update
sudo apt-get upgrade
Agora, se você não atualiza o sistema há algum tempo, poderá ver um grande número de patches e atualizações que precisam ser corrigidas. Não entrar em pânico! Isso é normal. Basta executar o updatee upgradee esperar. Pode ser necessário reiniciar depois, mas quando isso for feito, seu sistema operacional principal deverá estar totalmente corrigido e atualizado.
Avalie a base de código dos seus sistemas de código de servidor virtual Apache; Coisas do WordPress e da API do Google.
Prepare-se: esta é a parte mais feia. Você deve baixar e avaliar a base de código que foipotencialmenteinfetado. Esperamos que apenas um ou dois sites tenham sido comprometidos. Como fazer isso é idiossincrático para cada configuração, mas geralmente o que você deve fazer é carregar cada site em um ambiente de desenvolvimento, atualizar o núcleo do WordPress, atualizar os plug-ins, verificar se tudo funciona bem e então considerar o código limpo /estábulo.
Agora simplifiquei muito esta etapa. Mas a realidade é que mesmo depois de fazer patches e atualizações você ainda pode ter código de malware no núcleo do WordPress. Portanto, a outra coisa que você pode fazer é reconstruir cada site WordPress do zero. Mantenha os bancos de dados, os modelos e basicamente reconstrua o site a partir de um núcleo WordPress novo e limpo.
Sim, parece muito trabalhoso, mas se você tiver tantos servidores virtuais com diferentes bases de código, não há escolha.
Conselho post-mortem.
Isso não funciona para todos, mas direi o seguinte: backups e talvez até mesmo um repositório GitHub para a base de código limpa são o caminho a seguir para limpar a bagunça sem a última etapa de “avaliação” confusa que dei acima.
O que faço é executar dumps regulares do MySQL em qualquer site de unidade de banco de dados em que trabalho e certifico-me de que uma base de código central limpa esteja no GitHub. Então, se ocorrer uma infecção por malware, posso vasculhar os backups do MySQL e até mesmo reimplantar o código limpo do GitHub para garantir que a base de código esteja limpa. E se o próprio servidor for simplesmente prejudicado? Bem, basta descartar o sistema infectado, reconstruir um novo sistema Linux, implantar o código, importar os bancos de dados, ajustar as configurações e encerrar o dia.
Lembre-se de que 99% de todos os sites são apenas um banco de dados, uma base de código e um conjunto de configurações. Se você tiver alguma maneira limpa de “congelar” ou fazer backup de código não infectado e um backup de bancos de dados MySQL, tudo o que você precisa fazer é lidar com o material de configuração. O que é uma pequena dor em comparação com a limpeza do código do zero.