Três perguntas que espero que alguém possa ajudar a responder:
Estou executando o CentOS 6, pilha LEMP
Como sei se meu servidor já está comprometido devido ao bug do Shellshock?
Você não Essa é a ideia de uma vulnerabilidade de segurança. Se você tivesse que clicar em Let the crackers in? OK / Cancelar , não seria uma grande vulnerabilidade.
Você pode ter alguma sorte verificando os logs dos seus vetores de ataque, mas, como muitos serviços são vulneráveis e nem todos registram todos os acessos, provavelmente não é possível encontrar um ataque conclusivamente.
Se foi comprometido, existe uma pasta específica em que devo procurar arquivos maliciosos?
Não, um arquivo malicioso pode estar em qualquer lugar.
Os rootkits comuns se instalam em /rootou /ou em /tmpum dos caminhos binários, mas na verdade eles podem estar em qualquer lugar. Eles podem ter um nome semelhante a um serviço real ou algo "importante" com aparência " IPTables" ou " kernel-bin", mas também podem ser sequências aleatórias de caracteres ou o mesmo nome de um binário genuíno (apenas em um caminho diferente). Você pode identificar um rootkit realmente óbvio carregando /etc/rc.localou fazendo conexões via netstat -neopa. Procure por nomes de processo suspeitos em top -c.
Um rootkit menos comum e muito mais difícil de encontrar substitui uma biblioteca ou se carrega como uma biblioteca shim e intercepta chamadas do sistema. Isso é quase impossível de encontrar, a menos que você rastreie / rastreie todas as coisas em execução no seu sistema e compare o comportamento com o comportamento esperado de um sistema ou código-fonte em boas condições.
Seria mais rápido, mais fácil e mais conclusivo apenas recarregar o sistema.
Como é um arquivo malicioso?
Provavelmente como qualquer outro binário ou biblioteca ELF regular. Também pode ser um script.
Em conclusão, se você acha que existe a possibilidade de seu sistema ter sido comprometido, trate o sistema como se tivesse sido comprometido e tome as medidas necessárias.
bashinstalados e um cabo de rede conectado, certo?shellshock não é um worm, então não há arquivos para procurar. Shellshock é uma maneira de atacar uma rede para obter entrada. Uma vez lá dentro, quem sabe o que o atacante fará.
fonte
is there a particular folder where I should look for malicious files.Eu vi uma tentativa de explorar o bug, que instalaria um bot de IRC como
/var/tmp/x. Mas, em geral, não há arquivos específicos para procurar, pois eles podem estar em qualquer lugar ou lugar nenhum.Se você foi comprometido pelo servidor da Web, qualquer novo arquivo ou processo de propriedade do usuário do servidor da Web seria suspeito.
Caso um invasor use primeiro o
bashbug para entrar no sistema e a próxima vulnerabilidade localroot, pode ser quase impossível detectar.Veja também essa pergunta semelhante .
fonte
Eu ecoaria a resposta do suprjami e diria que, se o seu sistema estiver vulnerável, você deve tratá-lo como comprometido.
Se você estiver executando o apache, poderá verificar os logs em busca de tentativas de invasão do Shellshock com o seguinte comando:
Este comando extrai todas as linhas que contêm "cgi" dos logs de acesso do Apache (por padrão chamado access_log, access_log.1, access_log.2 etc) e depois o envia para o egrep com o regex.
(Fonte: http://linux.slashdot.org/story/14/09/24/1638207/remote-exploit-vulnerability-found-in-bash )
fonte
Como existem vários vetores de ataque para o Shellshock, alguns deles ainda desconhecidos para o público em geral ou causados por um script CGI personalizado, não há uma maneira definida de saber se você está comprometido ou não.
Além da abordagem usual "vamos ver se alguns arquivos do sistema foram alterados ou se algo suspeito aconteceu recentemente", você pode querer ficar de olho no comportamento do servidor.
netstatmostram conexões de rede estranhos oups auxMostrar processos que você não reconhece?Se você tiver o monitoramento adequado da integridade do servidor (como
Zabbix) instalado e em execução, também poderá ajudá-lo a descobrir violações de segurança. Você também pode comparar as somas MD5 / SHA dos arquivos do sistema com um backup em boas condições.Basicamente, aja como seu servidor foi comprometido e investigue tudo o que você puder imaginar.
fonte
Tive o prazer de limpar um sistema Plesk mais antigo comprometido. A primeira coisa que o denunciou foram inúmeros processos que foram iniciados ouvindo várias portas e outras tentando baixar o código do servidor de digitalização original.
Após os registros, descobri que o buraco final era o
cgi_wrapperscript a, algo que deveria proteger e proteger o sistema é o que realmente abriu o buraco na proteção. Aqui estão algumas das linhas de log das análises e do ataque bem-sucedido:Essas são as linhas do access_log, pois é apenas uma amostra. Observe as 200 em duas linhas, enquanto as outras falham com 404. Você não precisa se preocupar com as linhas que possuem um 404, pois elas não foram bem-sucedidas, aqueles com 200 no entanto fizeram. O padrão desses ataques aqui é sempre o mesmo: 1. encontre um script cgi vulnerável, use o shellshock exploit para baixar e executar um script perl, exclua o script perl novamente. O script perl, na verdade, baixa alguns arquivos de origem (tgz), compila-os e executa-os, pelo que vi, incluem pelo menos um backdoor e um mecanismo de atualização automática, além do que parece ser uma exploração para tentar obter privilégios de execução elevados. Na verdade, todos os scripts iniciais são executados como o usuário fornecido pelo wrapper, enquanto os serviços posteriores são iniciados com um PPID 1 (iniciado a partir do processo raiz)).
E aqui as linhas error_log correspondentes:
Arquivos baixados para / tmp Como se pode imaginar, eu não tenho o arquivo bot.pl, pois ele foi excluído imediatamente.
Depois de um tempo, notei conexões ssh de vários lugares como a China, que geralmente não visitam muito o nosso servidor. Eu corrigi o bash como uma medida de emergência (seria bom ter fontes corrigidas disponíveis no site da FSF e não apenas as fontes e arquivos de correção realmente antigos (um dos quais não se aplicava corretamente no início). limpe agora, portanto, se alguém estiver procurando algo mais sobre o ataque, você pode perguntar, mas faça isso em breve.
fonte
Esta resposta não está especialmente relacionada ao Shellshock, mas a qualquer sistema que você considere comprometido
segunda nota: você não pode ter certeza de ter se recuperado de um sistema comprometido para o sistema raiz. Sua única ação é destruir e aprovisionar o sistema
Tente obter uma compilação estática limpa
rpme execute o comandorpm --verify --all. Ele informará quais arquivos pertencentes a um pacote foram modificados. Mas como você pode executá-lo em um sistema comprometido, pode não confiar totalmente no resultado. Então você pode simplesmente fazer umrpm -qapara obter a lista de pacotes, recriar outro sistema com as mesmas versões de pacotes e depois umfind / -type f |xargs -r -n 100 md5sum |sortno sistema e ver o que difere. Além disso, se você gerenciar seu sistema corretamente (ou seja, não instalar nada manualmente fora de / opt ou / usr / local / bin ou outro local não gerenciado), poderá procurar todos os arquivos em seu sistema que não pertençam a um pacotefind / -type f -exec rpm -qf {} \;. Ele deve mostrar erros para arquivos desconhecidos. Eu deixo você não mostrar os pontos positivos como um exercício ;-)Para fazer o mesmo periodicamente com a prova criptográfica, existe uma ferramenta chamada
Tripwireque você ainda pode encontrar como versão gratuita. É velho, mas faz o seu trabalho. Uma alternativa mais nova éAIDE, mas ela não estava usando criptografia quando a observei anos atrás.Existem algumas ferramentas que podem ajudar. Por exemplo, procure pacote
rkhunter. Ele examinará seu computador em busca de kits de ferramentas raiz conhecidos e arquivos explorados.Obviamente, essas ferramentas devem ter sido instaladas e configuradas antes do comprometimento do sistema, e essas ferramentas também podem ser direcionadas se o seu sistema for hackeado com sucesso para obter acesso root. Além disso, essas ferramentas podem ser muito intensivas e tornar seu sistema lento.
fonte
A única maneira de saber se o seu servidor está comprometido é ter em algum lugar uma assinatura dos seus arquivos e compará-los. No entanto, você pode ver se você é vulnerável.
fonte
Como descobrir se sua caixa Linux está comprometida.
Se se retornar
tu es.
Para executar a atualização, em root, execute o seguinte comando
fonte
yume não outro gerenciador de pacotes.Você pode verificar se está vulnerável executando os seguintes comandos (código fornecido pelo CSA). Abra uma janela do terminal e digite o seguinte comando no prompt $:
Se o seu bash NÃO estiver atualizado, será impresso:
Se o seu bash estiver atualizado, você verá apenas:
Mais detalhes estão disponíveis por trás deste link .
fonte