Проверка
Для того, чтобы узнать, не взломали ли ваш сервер, скажем, работающий под управлением Ubuntu, стоит кое-что проверить.
?Данные последнего входа в систему
Выясните данные последнего входа в систему. Делается это с помощью команды lastlog.
$>lastlog?История команд
Взгляните на историю команд, узнайте, когда именно их вводили:
$>historyЕсли список команд выводится без даты – настройте соответствующие параметры утилиты history.
?Журнал auth.log
Следующий способ проверки – просмотр файла /var/log/auth.log. Например, с помощью такой команды:
$>sudo vi /var/log/auth.logЗдесь можно найти список всех, кто пытался подключиться к серверу по SSH.
?IP-адреса
Для того, чтобы выяснить IP-адреса, с которых подключались к серверу, воспользуйтесь такой командой:
$>zgrep sshd /var/log/auth.log* | grep rhost | sed -re 's/.*rhost=([^ ]+).*/\1/' | sort –u?Журналы Apache
Проверьте журналы Apache:
$>sudo vi /var/log/apache2/access.log
$>sudo vi /var/log/apache2/error.log?Поиск подозрительных процессов
Если вы уверены в том, что сервер взломан, разыщите процесс злоумышленника. Например, список всех процессов можно получить такой командой:
$>ps aux | less?Список заданий cron
Анализируя сервер на предмет взлома, полезно будет проверить список заданий cron, в который злоумышленник вполне мог добавить что-то своё.
$>crontab -l | grep -v ‘^#’Независимо от того, выявила ли проверка попытки взлома, безопасности много не бывает. Поэтому вот – несколько советов по защите сервера.
Защита
Рекомендации по защите сервера, в основном, касаются отслеживания и блокирования подозрительной активности, а также регулярного обновления программного обеспечения.
?Запрет входа root-пользователей по SSH
Для повышения уровня безопасности сервера стоит запретить вход root-пользователей по SSH.
$>sudo vi /etc/ssh/sshd_config
PermitRootLogin no?Автоматические обновления
Включите автоматические обновления безопасности с использованием пакета unattended-upgrades. Сначала его надо установить:
$>sudo apt-get install unattended-upgradesСледующий шаг – настройка:
$>sudo dpkg-reconfigure -plow unattended-upgradesПакет можно вызвать и самостоятельно:
$>sudo unattended-upgrade?Настройка блокировок
Установите пакет fail2ban. Для того, чтобы блокировать с его помощью подозрительных SSH-пользователей, воспользуйтесь этим руководством, поле чего настройте систему отчётов.
Для того, чтобы узнать, сколько раз fail2ban заблокировал некий IP-адрес, воспользуйтесь такой командой:
$>sudo awk '($(NF-1) = /Ban/){print $NF}' /var/log/fail2ban.log | sort | uniq -c | sort –nДля того, чтобы просмотреть весь файл журнала fail2ban, введите следующее:
$>sudo zgrep -h "Ban "/var/log/fail2ban.log* | awk '{print $NF}' | sort | uniq –cДля поиска проблемных подсетей подойдёт такая команда:
$>sudo zgrep -h "Ban " /var/log/fail2ban.log* | awk '{print $NF}' | awk -F\. '{print $1"."$2"."}' | sort | uniq -c | sort -n | tailЕсли анализ файлов журнала показывает, что атаки из некоторой подсети происходят регулярно, её можно заблокировать на постоянной основе. Перед этим, однако, стоит проверить, к какой стране принадлежит подсеть.
Например, вот как заблокировать подключения к sshd-порту из подсети 221.229.*.*:
$>sudo iptables -I INPUT -p tcp -s 221.229.0.0/255.255.0.0 --dport ssh -j REJECT --reject-with tcp-resetДля того, чтобы узнать о том, что именно было заблокировано правилами iptables, можно воспользоваться такой командой:
$>sudo iptables -vnL INPUT --line-numbersДля того, чтобы правила iptables сохранялись после перезагрузки сервера, установите в Ubuntu пакет iptables-persistent.
$>sudo apt-get install iptables-persistent
$>cat /etc/iptables/rules.v4Если вы отредактировали правила iptables, используйте такую команду:
$>sudo bash -c "iptables-save > /etc/iptables/rules.v4"Файл с правилами не рекомендуется править вручную, так как его формат важен для того, чтобы всё работало как надо.
Итоги
Мы рассказали о методах проверки Linux-серверов на предмет взлома и об улучшении их защиты. Надеемся, наши советы помогут вам повысить уровень информационной безопасности ваших систем.
Комментарии (43)
farcaller
01.11.2016 17:05+6Подозреваете, что Linux-сервер взломан?
wipe, re-image.
Нет никаких других вариантов. Злоумышленник уже мог пропатчить ядро и спрятать зловредные процессы. При чем, мог это сделать даже и без перезагрузки, если ksplice включен.
chemtech
01.11.2016 19:30+1Смените порт SSH
kotomyava
01.11.2016 20:35+1И какой цели это волшебство послужит, особенно в свете того, что уже установлен fail2ban, и тупые боты не мешают. А не тупых и не ботов смена порта не запутает ни сколько…
sumanai
01.11.2016 23:21+2Смена порта помогает от засорения логов записями о блокировке тупых ботов. Чистые логи читать приятнее.
Scorry
02.11.2016 12:39Тупых ботов не помешает банить с помощью ipset навсегда. Попытался зайти из-под рута — добро пожаловать в пожизненный бан.
Просто, эффективно.sumanai
02.11.2016 18:41Сегодня бот- а завтра? А если вирус на компьютере ни в чём ни повинного пользователя? А 1000 пользователей за натом?
В общем не панацея, так с водой и ребёнка выплеснуть можно.Scorry
02.11.2016 18:54+1Я лично пока баню только ssh. Почта остаётся доступной, всегда можно попросить о возвращении доступа.
И это не панацея, а ощутимое снижение нагрузки на файрволл.
До сих пор, кстати, за удалением из банлиста обращались единицы из тысяч заблокированных. Протокол специфичный, не все посетители пользуются.sumanai
02.11.2016 19:14Я лично пока баню только ssh.
Тогда нормально. Я уж думал, вообще все пакеты от них дропаете.
KorP
01.11.2016 21:57+3Вроде такой солидный человек, в костюме, что то там про безопасность пишет/переводит и такой совет… да я покурить не успею пока сканер найдёт нестандартный ssh порт. как правильно ниже говорят — fail2ban, ключи и/или сложные пароли — вот отличный вариант, а не порт менять.
betsuni
02.11.2016 07:45А я успею, потому что я не курю.
KorP
02.11.2016 08:07И это правильно, курить вредно
betsuni
02.11.2016 17:46а как все-таки боты найдут нестандартный порт ssh? по каким признакам они определяют, что нестандартный порт — это порт ssh?
а если еще на стандартный порт ssh что-то другое установить самописное и открыть его, чтобы ботов сбить с толку? там ведь можно будет им отдать какой угодно ответ.
akubintsev
03.11.2016 14:15+1Как показал мой личный опыт, смена порта sshd на нестандартный на порядки уменьшило в логах auth.log кол-во записей. Это помогает отсеивать не целенаправленные атаки.
Scf
02.11.2016 13:59+2Добавлю советов и я:
- сменить порт ssh. Как ни возмущались бы выше, но большая часть взломов — это автоматические сканеры уязвимостей. другой порт -> меньше попыток взлома -> меньше шанс словить свежий эксплойт.
- отключить аутентификацию по паролю и использовать только аутентификацию по ключам. Хранить приватный ключ в зашифрованном виде. Это сделает бессмысленным брутфорс и кражу приватных ключей с машины администратора.
- (для параноиков) добавить в sshd двухфакторную аутентификацию по TOTP
- (для рисковых параноиков) настроить на сервере файрволл, чтобы он разрешал подключения по SSH только с ваших IP адресов.
GhOsT_MZ
02.11.2016 15:23Вопрос по проверке cron'а, что делать, если злоумышленник менял не пользовательскую конфигурацию, а системную? А если и пользовательскую, но создал еще одного root'а? А если изменил login shell для любого системного пользователя (плюс добавил пароль, разумеется), добавил его в sudoers и таким образом имеет backdoor с root'ом? Также, он мог банально повесить SUID-бит на /bin/bash, либо положить wrapper для оболочки с этим битом, чтобы иметь root'а при логине под любым пользователем.
Собственно, исходя из этого на мой взгляд нужно как минимум:
- Ежедневно проверять список файлов с SUID-битом (интересно, но во FreeBSD есть periodic-задание для этого)
- Проверять не crontab -l, а /var/spool/cron, /etc/crontab и /etc/cron.*
- Регулярно проверять изменения в /etc/passwd, возможно даже настроить мониторинг на изменение этого файла (по дефолту в zabbix'е есть даже триггер на это)
- Проверять /etc/sudoers
- Диски, на которые происходит заливка файлов с внешнего мира, монтировать с флагами nosuid и noexec
lorc
02.11.2016 18:01Нужно исходить из того, что если злоумышленник получил рута хоть на 5 секунд — вы больше не контролируете систему. Потому что уже руткит уже загружен прямо в ядро и вы никогда даже не узнаете о его существовании.
stat() будет показывать правильные права для нужных файлов, никаких лишних записей в /etc/passwd вы не увидите, в /proc/ тоже не будет видно лишних процессов и т.д. И при этом машина будет вовсю DDOSить кого-нибудь и рассылать спам в промежутках между атаками.
Разве что физически снимете винчестер, подключите его к другой системе и очень детально проанализируете данные (не файлы!) на нём. Тогда да, вы сможете понять что машина была заражена.
А это мы ещё не затрагивали UEFI. Вирус в биосе — это больше не фантастика.GhOsT_MZ
03.11.2016 12:44Это само собой разумеющееся, я всего-навсего немного развил мысли автора, не сильно углубляясь. Понятное дело, что при должном уровне паранойи необходимо заново поднимать сервер в такой ситуации.
dim2r
04.11.2016 16:32Еще рекомендую делать «rpm -V» — сверяет контрольные суммы файлов на диске с эталонными. Можно смотреть какие конфиги или бинарники изменлись.
KlimovDm
04.11.2016 18:09Коллега. Я даже не знаю, как сказать… Прежде чем что-то советовать, надо немного думать или писать более развернутое описание.
1) rpm не имеет вообще никакого отношения к данной статье (и без того бестолковой), нет на ubuntu (и много где еще) rpm.
2) После взлома компьютера «никому нельзя верить» — почитайте сообщение farcaller выше. Даже ядру. А вы о каком-то менеджере пакетов…
KlimovDm
05.11.2016 00:18Промазал с ответом dim2r
https://habrahabr.ru/company/ruvds/blog/314166/#comment_9895192
>>> Мне мое знание помогало пару раз найти атаки
Уточните — атаки или взломы? Для атак «пару раз» — мало, для взломов — много. И, честно говоря, вообще не понял — о чем вы, о каком таком знании.
Andrusha
А почему для просмотра логов vi, а не less?
v0rdych
Чтобы сразу удалить за собой следы.
KlimovDm
Да уж. Вообще, вот такие пассажи
>>sudo vi /var/log/apache2/access.log
ставят компетентность автора оригинального текста под сомнение.
foxmuldercp
Интересно, как долго у меня будет открываться вечером apache.log размеров в пару гигабайт на один виртуалхост?.. и через сколько я в соседней консоли этот vim прибью.
Пополнил свою коллекцию вредных советов.
Интересно, с сервисом у компании так же, как с этим постом?
revko
Интересно, зачем держать лог в пару гигабайт, когда давно придумали logrotate? Попробуйте, говорят, помогает
KlimovDm
Ключевое слово в сообщении foxmuldercp — «вечером». Скажем так, на некоторые сайты заходят больше чем полтора человека в день. А смысла ротейтить логи каждый час в общем то никакого.
MasMaX
Всё равно гигабайтные логи это не дело.
Всегда можно например писать не общий лог домена, а каждому location сделать свой файл.
KlimovDm
>>Всё равно гигабайтные логи это не дело.
Почему? Аргумент — трудно смотреть в редакторе — не принимается :)
>> Всегда можно например писать не общий лог домена, а каждому location сделать свой файл.
Да речь не о конкретной реализации и не о конкретном приложении (при чем тут nginx?). Речь о любых логах, которые автор статьи очень странно изучает.
foxmuldercp
Хорошо, у меня на каждом сервере шаредхостинга — несколько сот клиентов, у каждого от одного до десятка сайтов на жумлах, битриксах и прочих вордпрессах. на некоторые сайты госорганизаций, учебных заведений и просто достаточно большие порталы собирается под гигабайт логов в сутки.
Как вы себе представляете работу инженера поддержки, которому приходит тикет на "у меня тут вот на сайте что-то не работает", и как Вы себе представляете моё предложение клиентам разбить логи на location, например, в плеске, cpanel или даже просто, средствами обычного вордпресса? и работу саппорта в таком режиме "найти бог знает что в бог знает каком логе для воот этого домена"