Existe uma maneira (simples) de fazer com que o fantoche use um arquivo disponível na Internet para a propriedade Source de um arquivo?
por exemplo:
file { "/home/text.txt":
source => [
"http://www.example.com/text.txt",
]
}
Esta é uma pergunta canônica sobre segurança do servidor - respondendo a eventos de violação (hacking)
Veja também:
Versão canônica
Suspeito que um ou mais dos meus servidores estejam comprometidos por um hacker, vírus ou outro mecanismo:
- Quais são meus primeiros passos? Ao chegar no local devo desconectar o servidor, preservar "evidências", existem outras considerações iniciais?
- Como faço para recuperar os serviços online?
- Como faço para evitar que a mesma coisa aconteça imediatamente novamente?
- Existem melhores práticas ou metodologias para aprender com esse incidente?
- Se eu quisesse montar um Plano de Resposta a Incidentes, por onde começaria? Isso deve fazer parte do meu planejamento de recuperação de desastres ou de continuidade de negócios?
Versão original
02.01.2011 - Estou a caminho do trabalho às 21h30 de um domingo porque nosso servidor foi comprometido de alguma forma e estava resultando em um ataque DOS ao nosso provedor. Os servidores de acesso à Internet foram desligados, o que significa que mais de 5-600 sites de nossos clientes estão fora do ar. Agora, isso pode ser um hack de FTP ou alguma fraqueza no código em algum lugar. Não tenho certeza até chegar lá.
Como posso rastrear isso rapidamente? Vamos ter um monte de litígios se eu não recuperar o servidor o mais rápido possível. Qualquer ajuda é apreciada. Estamos executando o Open SUSE 11.0.
03.01.2011 - Obrigado a todos pela ajuda. Felizmente eu não era o único responsável por este servidor, apenas o mais próximo. Conseguimos resolver esse problema, embora possa não se aplicar a muitos outros em uma situação diferente. Vou detalhar o que fizemos.
Desconectamos o servidor da rede. Ele estava realizando (tentando realizar) um ataque de negação de serviço em outro servidor na Indonésia, e o culpado também estava baseado lá.
Em primeiro lugar, tentamos identificar de onde no servidor isso estava vindo, considerando que temos mais de 500 sites no servidor, esperávamos estar fazendo bico por algum tempo. No entanto, ainda com acesso SSH, executamos um comando para encontrar todos os arquivos editados ou criados no momento em que os ataques começaram. Felizmente, o arquivo incorreto foi criado durante as férias de inverno, o que significa que muitos outros arquivos não foram criados no servidor naquele momento.
Conseguimos então identificar o arquivo ofensivo que estava dentro da pasta de imagens carregadas em um site ZenCart .
Após uma breve pausa para fumar, concluímos que, devido à localização dos arquivos, ele deve ter sido carregado por meio de um recurso de upload de arquivos que foi protegido de forma inadequada. Depois de pesquisar no Google, descobrimos que havia uma vulnerabilidade de segurança que permitia o upload de arquivos, no painel de administração do ZenCart, para uma foto de uma gravadora. (A seção que ele nunca usou), postar este formulário apenas carregou qualquer arquivo, não verificou a extensão do arquivo e nem verificou se o usuário estava logado.
Isso significava que qualquer arquivo poderia ser carregado, incluindo um arquivo PHP para o ataque. Protegemos a vulnerabilidade com o ZenCart no site infectado e removemos os arquivos ofensivos.
O trabalho foi feito, e eu estava em casa às 2 da manhã
A Moral - Sempre aplique patches de segurança para ZenCart, ou qualquer outro sistema CMS para esse assunto. Assim como quando as atualizações de segurança são lançadas, o mundo inteiro fica sabendo da vulnerabilidade. - Sempre faça backups e faça backup de seus backups. - Empregar ou arranjar alguém que estará lá em tempos como estes. Para evitar que alguém confie em uma postagem em pânico sobre falha do servidor.