Проблема c настройками SSH после взлома сервера. Как можно изменить поведение сервера и клиента без изменения ssh_config и sshd_config ?
Краткая предыстория для понимания ситуации.
Наш убунту-сервер взломали буквально на следующий день после скандала с уязвимостью Shellshock. Не знаю применили конкретно её или нашли какую-то другую дыру, но к нам c одного румынского IP-адреса проник злоумышленник. Раньше я в душе посмеивался над ихними ботами из ZmEu, которые пытались запустить несуществующий у меня phpMyAdmin, а тут вдруг на мой сервер пошли жалобы на предмет аналогичного брутфорса.
Когда я подключился, хакер еще висел в системе (или недавно перезашел) под пользователем root. Я его кильнул и начал наводить порядки. Незваный гость особо себя не ограничивал - установил и запустил программное обеспечение для узла ботнета (сканеры и IRC-сервер), раскидал свои ключи SSH под пользователями, переписал мне таблицу iptables и постирал логи предыдущих действий. Таким образом я точно не знаю, что он успел наделать кроме самих последних команд перед его килом из системы...
Текущая проблема.
Чужой код и левые SSH-ключики почистил, правила фаервола востановил, почти всех пользователей заблокировал, а оставшимся сменил пароли. Но при последующем использовании сервера обнаружил ряд нестыковок.
Для начала, при попытке по SSH зайти моего сервера на комп из видимой ему локалки, я получил предупреждение о неизвестном хосте. Проверил в ~/.ssh/known_hosts - его запись там была (я больше никуда собственно и не хожу с данного сервера) с указанием шифрования ecdsa-sha2-nistp256. Я подтвердил вход на сервер и получил в файле известных хостов вторую запись с типом шифрования ssh-rsa. Более того, теперь при заходах на локальный компьютер я все время получаю сообщение:
/etc/ssh/ssh_config line 52: Unsupported option "GSSAPIAuthentication"
/etc/ssh/ssh_config line 53: Unsupported option "GSSAPIDelegateCredentials"
Т.е. поведение локального ssh-клиента изменилось: и теперь он вместо привычного SHA-2 стал почему-то использовать SHA-1.
Еще. Я в терминале работаю в основном под MC. Вместо привычной псевдографики я теперь вижу рисование крякозябами. Помогла только смена кодировки в putty с UTF-8 на KOI8-R (если делать подключение на вышеупомянутый комп из локалки, то там все в порядке и мне приходится делать обратную смену с KOI8-R на UTF-8 чтобы снова видеть нормальный MC).
Как злоумышленник провернул все эти фокусы? Как я уже упомянул ранее, файлы ssh_config и sshd_config из директории /etc/ssh не изменились. Но даже, если предположить, что с помощью touch даты вернули назад на 2012 год, то в sshd_config все равно явно указано использование протокола 2. И прочие настройки визуально никак не изменены. Поиск по файловой системе показал, что это единственные экземпляры конфигов и других (пользовательских) нет.
Второстепенная проблема но тоже связана с SSH.
Когда пошли тревожные звоночки, я был в гостях. Там же с чужого компа я несколько раз подключался по putty не по ключу, а с явным указанием логина и пароля. Потом при анализе последних измененных в файловой системе я наткнулся на очень неприятный файлик /etc/ppp/.ilog , в котором в текстовом виде был прописан мой логин и пароль в количестве раз, сколько я подключался без ключа. Время модификации файла совпадало со временем моего последнего входа по SSH. Но что самое паскудное - мой последний вход был уже после проведения "лечебных" процедур и последующего ребута сервера. Поэтому возможно что вторая проблема и первая имеют общую причину.
Поскольку я уже упомянул про ребут и оставшиеся проблемы, то хочу сразу отметить, что я уже проверил кронтабы пользователей и содержимое директорий /etc/rcX.d и ничего нового/необычного не обнаружил.
Моя фантазия выдохлась... Прошу подсказок от "знатоков" и более опытных коллег.
Не заметил сразу, но бинарники ssh* все оказались с датой модификации = дате взлома. После обновления ОС на один релиз и обновления пакетов (в том числе OpenSSH), тревожившие меня симптомы исчезли. Теперь провожу профилактические работы по окапыванию...
"Там же с чужого компа я несколько раз подключался по putty не по ключу, а с явным указанием логина и пароля" - в одной статье по настройке ssh сервера помню постоянно писали,что настоятельно рекомендуется отключать авторизацию по логину паролю.
@rusbaron, пишут верно. Но отключить насовсем парольную защиту я не хочу, так как обстоятельства меня могут застать в разных местах, а приватный ключ таскать на чужие компы не очень хорошая затея - проще воспользоваться паролем, а потом его сменить. Для защиты от брутфорса я сменил порт на очень нестандартный и включил fail2ban с настройкой на 3 попытки входа. Последнее из разряда дутья на воду, так как согласно логов еще ни один бот-нет не догадался на каком порту у меня теперь висит sshd.
Правилом номер один при компромитации системы является ее полная переустановка.
Нет ни одного надежного способа диагностировать изменения в системе проведенные злоумышлеником, в случае если у него был рут и был достаточно квалифицирован.
Я имею ввиду при помощи самой это системы.
К сожалению, полностью все переставить не получится. Главная проблема - сервер 1С со своими ключами (серверным и многопользовательским) и тяжелыми базами, а еще своими пользователями, которые работают всю неделю включая выходные и праздники...
Я надеюсь, что поможет следующий финт - обновлю релиз убунты, а вместе с ним обновятся libc и другие системные библиотеки, что приведет к автоматическому обновлению большинства репозиторных программ и их настроек. Уже проводил эксперимент на кошечках (виртуалке) и вроде без особых проблем, только для некоторых наших программ пришлось найти устаревшие версии библиотек (буст и что-то в том же духе) и подкинуть в /lib для разрешения зависимостей. Буду пробовать на этих выходных.
Но меня все же волнует то, что я не понимаю как злоумышленнику удалось понизить версию протокола SSH без правки конфигов. Ничего похожего в документации не нашел. Но ведь это не значит, что я не мог пропустил нечто важное. Альтернативой вижу только подмену бинарника, но для этого ему нужно было закачать измененные исходники и смейкать на месте - как он проделал это с руткитом. Но исходники руткита я нашел рядом с исполняемыми файлами, а исходников для sshd не увидел...
Попробуйте посмотреть что именно висит на 22 порту. Совсем не обязательно что там висит именно ваш sshd
netstat -tpln
попробуйте установить рут кит хантер и посмотреть отсканировать систему и посмотреть что он вам подскажет. В репозитеариях убунты он кажется есть
посмотрите все процессы которые запущены на машине один за одним, не обращайте внимания на названия процессов а смотрите именно откуда какой процесс запущен.
Но все эти процедуры мертвому припарки, если человек был достаточно квалифицирован чтобы установить нормльный ядерный руткит. В этом случае вы не найдете ровным счетом ничего.
Чуть успокою Вас тем фактом, что если бы было именно так, то вы бы не обнаружили запущенное хакером ПО. Кстати вы смотрели от какого пользователя оно было запущено?
так же добавлю, что нередки случае когда компромитацией системы занимается бот, а не реальный человек. И в том случае ваши шансы на то чтобы восстановить систему в оригинальное состояние растут.
В любом случае, у Вас сейчас удивительный шанс подтянуть свои знания администратора системы расследуя этот случай на вашей машине. Дам парочку советов
увидев чужой процесс не спешите его сразу удалять. Узнайте место откуда он запущен. От какого пользователя. В какое время файл был создан сколько времени процесс активен. Попробуйте по разным логам посмотреть что именно происходило в это время.
Совет в принципе хороший.
Но у меня нет запасного сервера равного по мощности текущему. Плюс главная проблема с установленной 1С - нужно перенести ключи (серверный и многопользовательский), тяжелые базы и обеспечить бесперебойную работу пользователей с 7:00 утра до 2:00 ночи (включая субботу и воскресенье).
Удобный случай предложить Вам начать использовать etckeeper на всех серверах. По крайней мере, в следующий раз Вы будете знать, что в каком конфиге было поменяно.
Пища для размышления: есть в линухах компиляторы, и имея исходники SSH и прямые руки, можно скомпилить свою редакцию ссш сервера, со встроенными "фичами"
Средний
Простой
