Apache error_log mostrando qual saída do comando

1

O error_log do Apache mostra linhas como as seguintes:

--- snip ---
which: no ruby in (/sbin:/usr/sbin:/bin:/usr/bin)
which: no locate in (/sbin:/usr/sbin:/bin:/usr/bin)
which: no suidperl in (/sbin:/usr/sbin:/bin:/usr/bin)
which: no get in (/sbin:/usr/sbin:/bin:/usr/bin)
which: no fetch in (/sbin:/usr/sbin:/bin:/usr/bin)
which: no links in (/sbin:/usr/sbin:/bin:/usr/bin)
which: no lynx in (/sbin:/usr/sbin:/bin:/usr/bin)
which: no lwp-mirror in (/sbin:/usr/sbin:/bin:/usr/bin)
which: no lwp-download in (/sbin:/usr/sbin:/bin:/usr/bin)
which: no kav in (/sbin:/usr/sbin:/bin:/usr/bin)
--- end ---

A arquitetura é:

Internet - > Balanceador de carga - > Verniz - > Apache

Existem vários servidores web por trás do balanceador de carga e eu verifiquei pelo menos um deles com o rkhunter ( link ) e não pude Não acho nada suspeito.

Versões:

  • CentOS 5.7
  • Varnish 2.1.5
  • Apache 2.2.3
  • PHP 5.2.17

Isso significa que alguém executou o comando através do Apache? Como isso pode acontecer?

Muito obrigado.

    
por Unai Rodriguez 20.03.2012 / 05:19

1 resposta

2

Está bem claro que você foi hackeado. Os comandos mencionados seriam de interesse para um hacker que encontrou uma vulnerabilidade permitindo que eles executem comandos como o usuário do apache (provavelmente através de uma vulnerabilidade de aplicativo da web). Por exemplo, links e lynx permitiriam que o atacante baixasse programas adicionais, assim como o lwp- *. Esses comandos nunca seriam executados por um aplicativo da web legítimo, portanto, ele deve ser um invasor.

Veja este tópico para um ataque com uma assinatura semelhante - este é realmente um escalação de privilégios.

A primeira coisa é colocar o sistema offline - uma decisão de compensação, mas como você não tem ideia de como o sistema é completamente de propriedade, é uma coisa segura a se fazer.

Você deve tentar descobrir quando foi invadido - por exemplo, restaure backups de 4 semanas atrás em um sistema separado e compare com um backup feito ontem à noite. Este deve ser um backup completo da máquina, pois o invasor pode ter entrado na raiz.

Uma vez que você sabe quando foi hackeado, você pode restaurar a partir de um backup que foi feito antes do ataque (mas ainda manter o sistema offline para que ele não possa ser explorado novamente). A vulnerabilidade ainda está lá, para que o invasor possa entrar novamente se o sistema estiver on-line - para que você também precise localizar e fechar rapidamente a vulnerabilidade - o backup completo da máquina da noite anterior é importante para que você descubra como eles chegaram. / p>

Veja Como faço para lidar com um servidor comprometido? para obter conselhos mais completos sobre como se recuperar de um hack.

Boa sorte.

    
por 20.03.2012 / 08:32