comportamento estranho do servidor, medo de violação de segurança, mas nada em logs

Question

Hoje em dia, minha hospedagem (a2hosting) teve um problema com o nó que hospedava meu VPS e, durante esse período, meus usuários notaram um comportamento estranho, além das diversas reinicializações ocorridas enquanto havia problemas no nó.

Tudo começou quando alguns dos usuários do meu site me contataram dizendo que viram imagens diferentes do normal no site (imagens totalmente aleatórias, não relacionadas ao meu site), já que eu não estava em casa e desliguei o servidor da minha hospedagem painel de controle, temendo um ataque de hackers.

Após algumas horas, meus usuários me disseram que o servidor está ativo novamente (embora eu não tenha mencionado isso) e meus usuários disseram que, depois de limpar o cache, não viram nada de errado com suas imagens mais. Eu fecho de novo assim que eu li sobre isso, ainda mais com medo de um ataque de hacker (mas intrigado já que nenhuma senha foi alterada)

Finalmente, quando voltei para casa, inicializei o servidor novamente e verifiquei o log. Nenhuma atividade suspeita nos logs, ninguém logou no servidor além de mim, nenhum arquivo (daqueles que me disseram serem diferentes) foi alterado. As únicas coisas estranhas eram:

• Eu tenho 2 arquivos de logs do apache chamados 20150518-access.log e 20150517-access.log (e eu tenho algumas entradas de log com data de 18 de maio em outros logs, como dito acima), o que significa que meu sistema teve temporariamente 18 de maio como data (agora está de volta a abril e mudou por si só).
• Alguns dos meus registros têm esse link como entrada de registro após uma das reinicializações

Eu fiz algumas verificações e meu sistema parece bem, nenhum acesso além do meu, nenhum arquivo suspeito encontrado (nem mesmo as imagens que me contaram eram diferentes), e passei todo o meu domingo checando por atividade suspeita mas eu não consegui encontre algum.
Então, eu abri um ticket no a2hosting e eles disseram que não podiam me dar nenhuma informação, mas era mais provável que fosse uma violação de segurança e não um problema ligado ao problema do nó (exceto os reinícios, eles confirmaram que era um problema do lado deles), mas honestamente eu não estou convencido ... e enquanto eu posso pensar em um link entre o reinício automático e a data de mudança temporária, não consigo encontrar nenhum relacionado com as imagens (que é a única coisa isso me fez pensar em um problema de segurança, embora eu não consiga pensar em um hacker que mude um monte de imagens aleatórias e a data do servidor, mas depois reverte tudo de volta). Minhas perguntas são:

• há alguma maneira de as pessoas verem imagens aleatórias em vez das imagens reais estarem vinculadas a um problema de servidor / nó em vez de uma violação de segurança?
• O que mais eu poderia verificar além de logs do sistema e arquivos recentemente modificados para garantir que nada de estranho aconteceu?

Answer 1

Parece uma atualização do BGP combinada com opções de host padrão¹. Tive problemas para coletar dados (devido a uma rede que eu pagaria para fazer upgrade), mas aqui está o que recebi:

A rota

As rotas da A2 Hosting estão em AS55293 . Você está coberto pelo / 22 e / 23 lá. Os caminhos do ASN foram atualizados em 17 de abril, mesmo dia do anexo do NUL. De LookingGlass (digite seu IP, escolha Route e depois Probe):

core1.fmt2.he.net> show ip bgp routes detail 199.195.117.35
Number of BGP Routes matching display condition : 2
S:SUPPRESSED F:FILTERED s:STALE 

1 Prefix: 199.195.116.0/23,  Status: BI,  Age: 19d20h14m55s
NEXT_HOP: 206.223.119.132, Metric: 593, 
Learned from Peer: 216.218.252.168 (6939)
LOCAL_PREF: 100,  MED: 20,  ORIGIN: igp,  Weight: 0
AS_PATH: 12129 55293

2 Prefix: 199.195.116.0/23,  Status: I,  Age: 82d0h54m10s
NEXT_HOP: 206.126.236.70, Metric: 685, 
Learned from Peer: 216.218.252.169 (6939)
LOCAL_PREF: 100,  MED: 20,  ORIGIN: igp,  Weight: 0
AS_PATH: 12129 55293

Last update to IP routing table: 2d19h12m13s, <--------- Right here
1 path(s) installed:  (no data was here, maybe a removal)

O serviço

O serviço da A2 Hosting é o WordPress. Quando visito seu servidor pelo endereço, ele serve outro site do WP e, embora estejamos acostumados a pensar em nomes, é por isso que isso é importante.

Por ter omitido seu nome de host, o servidor escolheu outro site (encontrado primeiro ou configurado como padrão). Os navegadores não se importam muito com nomes e abordam servidores por endereço, fornecendo apenas o nome para que o servidor possa escolher um site da configuração. O DNS também tem PTRs para cruzar os endereços de volta aos nomes, mas o seu não:

$ dig PTR 35.116.195.199.in-addr.arpa.

;; ANSWER SECTION:
... 43200 IN    PTR 199.195.116.35.static.a2webhosting.com.

Para hosts compartilhados, isso significa apenas que o servidor da Web precisa confiar no nome fornecido pelo cliente, em vez de verificar novamente com o DNS. O que não deve fazer é enviar o conteúdo errado do site quando não tem certeza (embora muitas pessoas se safem disso, porque o pior que geralmente acontece é o do 404). Infelizmente, o seu host carrega principalmente WordPress, gerando uma maior chance de sucesso com as solicitações erradas para os servidores errados. O SSL poderia emitir avisos, mas eu não contaria com isso.

Aqui está uma solicitação do google no endereço do seu servidor:

$ nc youraddress 80
GET / HTTP/1.1
HOST: www.google.com

.....
HTTP 1.1 200 OK
...headers, html, nothing Google yet...
<head>...<base href="http://www.google.com/" />...
  <meta name="generator" content="Joomla!
 - Open Source Content Management" /> 
  <title>FillGood</title>...

qual é a mesma resposta (errada). A mágica acontece quando solicito uma imagem do WordPress em seu site, mas ela é encaminhada incorretamente, acaba no padrão e corresponde a arquivos de outro site.

Os NULs

O SIGTERM (15) na sua imagem NUL implica um desligamento normal em de sshd e não em um sled de exploração, e os NULs parecem ser keepalives. Em um / segundo há quase exatamente 5,5 minutos deles (você menciona desligar por horas), e embora iTerm e roteadores enviam keepalives (NUL ou ^ @) aparece o serviço retornado sem logs intermediários. Estou tentado a descartar estes como apenas acontecendo muito rápido porque o tempo limite padrão para roteadores Cisco em mudanças de rota é de 270 segundos ( aqui e aqui ) ... 4,5 minutos ... ou exatamente a diferença entre os tempos que o sshd graciosamente desliga (21:56:59) e retorna (22:01:30), dentro de uma fração de segundo.

Conclusão

Esses eventos são alinhados no tempo² e com durações que pessoas e scripts fazem, não falhas aleatórias. Isso tudo supõe que o host permaneça ativo, o DNS não suporte, configurações padrão, prevalência de arquitetura e SSH controlado separadamente, como pode ser feito com jails baseados em host.

Você mencionou Varoufakis e uma motocicleta, e eu vi no noticiário que ele visitou o Eurogroup Finance recentemente. O site do EGF é na mesma sub-rede e eles usam / wp , mas o servidor responde adequadamente a nomes de host desconhecidos. Como você tem duas sub-redes cobrindo você , provavelmente existem cerca de 500 endereços de sites padrão para verificar, mas O principal problema parece ser que nem todo servidor define um site padrão ou uma parede.

É realmente com eles, mas uma página genérica "incompatível com o Wordpress" provavelmente deve aparecer de modo que quando eu jogar o seu xadrez hospedado não me seja oferecido o repositório de sapato de outro servidor. Com roteamento rompido, existe a possibilidade de compartilhar scripts e cookies, e qualquer pessoa familiarizada com o BGP pode ver problemas adicionais aqui. Esses sites devem ser invadidos da mesma forma que se recusam a compartilhar conteúdo.

¹ Informações oportunas com suposições geralmente são mais importantes, mas meu texto original era muito especulativo. Desculpe pelo atraso.

² Para a alteração do registro de data e hora, tente procurar os logs que fazem referência ao ntp ou ntpd, para verificar se o sistema está sincronizado com uma fonte de tempo inesperada.