Каким образом человек может попасть на хакнутый им сервер?
Меня атаковали позавчера, систему сносить и ставить с нуля желания нет, логи пустые.
Изменил пароли, проверил authorized_keys, проверил пользователей - ничего подозрительного не нашёл.
Прокси если стоял бы, по идее ip внешний изменился бы - не изменился, поэтому я в данный момент думаю что у него нет доступа в систему, но порты в сеть пока не открываю.
historydev, либо ты его криво запомнил или вводил (такое бывает при сломанной консоли), хотя с учетом такой кучи действий что ты творишь, мог и сам его сломать))
mayton2019, не настолько простой, но мой пароль точно был слит, т.к. я ставил кряк программы пару лет назад и поймал троян, мне из-за него ютуб акк забанили ещё)
pfg21, кстати хорошая идея - быстро восстанавливать образ сайта из git.
Из него-же можно смотреть diff и понять где были изменены php файлы например.
Знакомые которые суппортят WordPress, таким образом находили плагины вордпресса
с троянами.
Для системы - полный бэкап OS-раздела. И для сайта - из git.
Vladimir,
ip у виртуалок да, серые, у хоста есть и белый, и серый.
Виртуалки в отдельной подсети, с хоста я порты перенаправляю на ssh виртуалок через iptables prerouting.
Фишка в том, что из них был доступ к хосту и это стало фатальной ошибкой, я думаю меня тупа брутнули, сначала через открытый порт к виртуалке пробрались, из виртуалки к хосту, пароль один и тот-же был.
Сейчас я это всё исправил, забанив сеть виртуалок на хосте через iptables drop.
mayton2019, git ориентирован на текстовые файлы, так что гитом лучше "бекапить" html svg xml и т.д.
а так, обычный инкрементальный или дифференциальный бекап отлично отлавливает и показывает внедрения в систему.
Слышали про такую вещь как rootkit? Если взломщик получил root, то это финиш. Вы уже не можете доверять выводу ни одной утилиты и работе ни одной команды. В том числе rsync, netstat и iptables.
Могли оставить какой-нибудь скрипт, который по запросу из сети выполнить любой заранее заложенный или загруженный в процессе код. Могли майнер оставить. Могли какой-то сервис развернуть. Могли в крон положить скрипт который через Х дней даст доступ по ключу или добавит пользователя. А могли ничего не сделать. Вариантов слишком много :) Проще переустановить. Логи могли и подчистить.
майнера нет, мониторю ресы, ничего не грузится, видеокарту правда проверить не могу, т.к. драйвер не поддерживается системой.
Кронтаб проверил, там только моя запись.
Логи пустые, как раз и говорю о том, что их почистили.
Запрос из сети идёт по адресу:порту, у меня открыты порты которые я контролирую и знаю куда они ведут.
Сервис развернуть, например?
Могу вывести что-то вроде "недавно установленных" сервисов, вчера проверял всех юзеров на предмет смены пароля, новых не нашёл, все юзеры с момента установки системы.
historydev, предполагать можно всё что угодно, но гарантировать, что ничего не осталось нельзя. Кронтаб пустой, но "закладка" может лежать в любом штатном скрипте который рано или поздно будет выполнен и троян развернётся подняв необходимые соединения. Это гипотетически.
Вообще так скомпрометированный сервер - это отличный повод пересобрать образ с нуля, навести ревизию и сделать орекстрацию установок. Так, чтобы и бэкапы файловой системы были не нужны, потому что он разворачивается за считанные минуты с нуля.
historydev, если у хакера был root, он мог заменить любую программу, библиотеку и даже ядро. Завтра в недрах какой-нибудь libpcre выполнится злоумышленный код и... и что? Так что доверять "чистоте" системы - огромный риск.
historydev, если сохранять чистую систему - достаточно. Если начать копировать софт, скрипты и сайты из старой системы бездумно - можно вернуть обратно все дыры и уязвимости.
Я так понимаю в данном случае речь идёт о хосте для виртуалок? Тогда ставим всё заново, настраиваем гипервизор, если тянем из старой системы какие-то готовые скрипты - обязательно смотрим внутрь... Весь самосборный софт (если что-то ставилось из исходников) собираем заново, не копируем из иначального положения. И конечно же защищаемся от доступа на хост с этих виртуалок. Сами виртуалки (образы дисков), вероятно, можно сохранить, особенно те, которые не ломали. В теории, в них тоже могли записать вредонос прямо в структуры файловой системы, но это малореально, если вирус не писали какие-то суперспециалисты под узкоцелевое использование, ибо это очень сложно.
shurshur, У меня есть бэкапы виртуалок, но да, я не знаю стоит их брать или нет, да и по настройке всё чуть-ли не apt install pkg, ошибки которые допустил, я учёл и применю это всё после переустановки, в этот раз скорее всего сразу бэкапы сделаю и сохраню на компе.
historydev, полезно даже не бэкапить виртуалки, а практиковать автоматизацию их разворачивания. Например, писать плейбуки для ansible, с помощью которых свежеустановленная система получает нужный софт с нужными базовыми настройками (nginx/php/docker/юзеры/права/настройки/итд/итп). Сайты, которые в сырцах (например, на php или python) разворачивать из git, но параметры конфигурации (например, реквизиты базы) не хранить в git. Обычная практика: в git лежит config_example.php с демонстрационным набором параметров, а для прода делают копию файла и меняют значения на реальные. Это рекомендация по личному развитию, если освоить подобный подход, то можно существенно улучшить поддержание текущих и поднятие новыхп роектов.
От паролей ssh лучше отказываться. Пароль должен или не использоваться совсем, или быть крайним вариантом на чёрный день и быть у каждого сервера разным автогенерированным и храниться где-нибудь там, где его легко не найдут!
Вместо пароля использовать ключи. Причём в хорошем варианте ключи хранятся только на локальной машине, а на удалённую (откуда практикуется ssh на какие-то ещё другие хосты) прокидываются через ssh-agent. Но для начала хотя бы просто начать использовать ключи. Можно вплоть до того, чтобы каждому серверу свой ключ, чтобы при утечке какого-то одного ключа не пострадало вообще всё.
