Назад | Перейти на главную страницу

Странное поведение сервера, опасение нарушения безопасности, но ничего в журналах

В эти дни у моего хостинга (a2hosting) возникла проблема с узлом, на котором размещен мой VPS, и в течение этого периода мои пользователи заметили странное поведение, отличное от нескольких перезапусков, которые произошли, когда на узле были проблемы.

Все началось с того, что некоторые из пользователей моего сайта связались со мной и сказали, что они видят на сайте изображения, отличные от обычных (совершенно случайные изображения, не связанные с моим сайтом), поскольку меня не было дома, я выключил сервер с панели управления хостингом опасаясь хакерской атаки.

Через пару часов мои пользователи сказали мне, что сервер снова работает (хотя я не поднимал его), и мои пользователи сказали, что после очистки кеша они больше не видели ничего плохого со своими изображениями. . Я снова выключил его, как только прочитал об этом, еще больше опасаясь хакерской атаки (но озадачен, поскольку пароль не был изменен)

Наконец, когда я вернулся домой, я снова загрузил сервер и проверил журнал. Никакой подозрительной активности в журналах, никто не заходил на сервер, кроме меня, ни один файл (из тех, которые, как мне сказали, были разными) не был изменен. Единственными странностями были:

У меня есть 2 файла журналов apache с именами 20150518-access.log и 20150517-access.log (и у меня есть некоторые записи журнала от 18 мая в других журналах, как указано выше), что означает, что моя система временно имела 18 мая в качестве даты ( теперь снова апрель, и все изменилось само собой).
В некоторых моих журналах есть это http://mjzone.net/Files/lognull.png как запись в журнале после одного из перезапусков

Я провел несколько проверок, и моя система выглядит нормально, никакого доступа, кроме моего, никаких подозрительных файлов не найдено (даже изображения, о которых мне сказали, были разными), и я провел все свое воскресенье, проверяя подозрительную активность, но не смог найти любой.
Итак, я открыл заявку на a2hosting, и они сказали, что не могут предоставить мне никакой информации, но более вероятно, что это было нарушение безопасности, а не проблема, связанная с проблемой узла (за исключением перезапусков, они подтвердили, что это проблема на их стороне), но, честно говоря, я не уверен ... и хотя я могу думать о связи между автоматическим перезапуском и временно измененной датой, я не могу найти ничего, связанного с изображениями (это единственное это заставило меня задуматься о проблеме безопасности, хотя я не могу представить себе хакера, который изменяет кучу случайных изображений и дату сервера, но затем возвращает все обратно).
Мои вопросы:

Есть ли способ, которым люди, которые видят случайные изображения вместо реальных изображений, могут быть связаны с проблемой сервера / узла, а не с нарушением безопасности?
Что еще я могу проверить, кроме системных журналов и недавно измененных файлов, чтобы убедиться, что ничего странного не произошло?

Похоже на обновление BGP в сочетании с выбором хоста по умолчанию¹. У меня возникли проблемы со сбором данных (из-за сети, за обновление которой я бы заплатил), но вот что я получил:

Маршрут

Маршруты A2 Hosting находятся под AS55293. Там вас охватывают / 22 и / 23. Пути ASN обновлены 17 апреля, в тот же день, что и ваше вложение NUL. Из LookingGlass (введите свой IP, выберите Route, затем 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)

Сервис

Хостинг A2 служба это WordPress. Когда я захожу на ваш сервер по адресу, он обслуживает другой сайт WP, и хотя мы привыкли думать об именах, поэтому это важно.

Не указав имя хоста, сервер выбрал другой сайт (либо первый найденный, либо настроенный по умолчанию). Браузеры не очень заботятся об именах и подходят к серверам по адресу, а только предоставляют имя, чтобы сервер мог выбрать сайт из конфигурации. DNS также имеет PTR для перекрестной проверки адресов в обратном направлении к именам, но ваш нет:

$ dig PTR 35.116.195.199.in-addr.arpa.

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

Для общих хостов это просто означает, что веб-сервер должен полагаться на предоставленное клиентом имя, а не на двойную проверку с помощью DNS. Чего он не должен делать, так это отправлять не тот контент сайта, когда он не уверен (хотя многим это сходит с рук, потому что худшее, что обычно происходит, - это 404-е). К сожалению, на вашем хосте есть в основном WordPress, поэтому вероятность успех с неправильными запросами к неправильным серверам. SSL может выдавать предупреждения, но я бы не стал на это рассчитывать.

Вот запрос Google на адрес вашего сервера:

$ 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>...

это такой же (неправильный) ответ. Волшебство происходит, если я запрашиваю изображение WordPress на вашем сайте, но оно маршрутизируется неправильно, заканчивается по умолчанию и соответствует файлам с другого сайта.

NUL

SIGTERM (15) в вашем образе NUL подразумевает постепенное завершение работы sshd а не салазки для эксплойтов, и NUL кажутся активными. На одну / секунду их почти ровно 5,5 минут (вы упоминаете о выключении на несколько часов), и хотя iTerm и маршрутизаторы отправляют сообщения поддержки активности (NUL или ^ @), похоже, служба вернулась без промежуточных журналов. Я склонен отклонить это как просто происходящее слишком быстро, потому что тайм-аут по умолчанию для маршрутизаторов Cisco при изменении маршрута составляет 270 секунд (Вот и Вот) ... 4,5 минуты ... или точно разница между временами, когда sshd корректно завершает работу (21:56:59) и возвращает (22:01:30) в течение одной доли секунды.

Вывод

Эти события выровнены по времени² и продолжительности, которую делают люди и скрипты, а не случайным сбоям. Все это предполагает, что хост работает, DNS не поддерживает, конфигурации по умолчанию, распространенность архитектуры и SSH контролируются отдельно, как это может быть сделано с тюрьмами на основе хоста.

Вы упомянули Варуфакиса и мотоцикл, и я видел в новостях, что он недавно посетил Eurogroup Finance. Сайт EGF в той же подсети и они используют / wp, но их сервер правильно реагирует на неизвестные имена хостов. Поскольку у вас две подсети покрывая тебя) существует, вероятно, около 500 адресов сайтов по умолчанию, которые нужно проверить, но основная проблема, похоже, заключается в том, что не каждый сервер устанавливает сайт или стену по умолчанию.

Это действительно их дело, но, вероятно, должна появиться общая страница «несовместимая с Wordpress», чтобы, когда я играю в их размещенные шахматы, мне не предлагали хранилище обуви другого сервера. При нарушенной маршрутизации существует возможность совместного использования сценариев и файлов cookie, и любой, кто знаком с BGP, может увидеть здесь дополнительные проблемы. Эти сайты следует заставить взламывать так же, как и отказываться от совместного использования контента.

¹ Своевременная информация с предположениями обычно более важна, но мой исходный текст был слишком умозрительным. Извините за задержку.

² Для изменения метки времени попробуйте поискать журналы, ссылающиеся на ntp или ntpd, чтобы узнать, синхронизировалась ли ваша система с неожиданным источником времени.