Как стать автором
Обновить

Усиление защиты серверов Linux от угроз и атак

Время на прочтение6 мин
Количество просмотров3.6K
Всего голосов 12: ↑10 и ↓2+8
Комментарии14

Комментарии 14

Эта статья не туториал, это рекомендации. Туториал когда подробно показывают как что-то сделать.

Это вырезано из памятки от ФСТЭК по усилению безопасности Linux. Но как-то все не систематизировано.

Запретите запросы ICMP (ping)

Одна из малых головных болей моей жизни - админы из секты запретителей пинга. Интересно, помимо того, что это усложняет проверку доступности сервера простым пользователям, это хоть от чего-нибудь защищает?

От дудоса школьниками защищает. Насколько помню, лоик как раз именно через ICMP работает. Чуток усложняет сканирование сети роботами.

От дудоса защищает правило фаервола, ограничивающее частоту приёма эхо-запросов.

да, китайцы перестают пытаться брутфорсить ) по крайней мере их количество ощутимо снижается

От ICMP-туннелей, использующихся атакующими (в т.ч. и пентестерами) для развития атак. К сожалению, чаще всего можно увидеть 2 варианта: либо по ICMP в контексте безопасности вообще забывают, либо полностью блокируют (мешая полезности его периодического использования). Не помешала бы статья про грамотный подход к фильтрации ICMP (если кто знает такую статью - порекомендуйте, пожалуйста).

Избегайте прямого доступа под root. Это может сделать сервер более уязвимым. Вместо root‑доступа создайте нового пользователя с привилегиями sudo для административных задач.

А как это поможет вообще? Типа атакующему надо будет целое слово sudo добавлять к командам, и он обломается? :)

С помощью sudo можно дать пользователю права только к определенным командам, тогда как к остальным, доступ к которым по-прежнему нужно ограничивать, будет отсутствовать. К тому же, когда будут сервер брутить, то первое, что обычно стоит в списках логинов это как раз "root", если у тебя рут отключен, а учетка называется "yasuperadminbezopasnik2001", то вероятность попадания такой учетки в список предполагаемых логинов стремится к нулю.

Там было еще про "PasswordAuthentication no" было, в статье почему-то не упомянуто.

А не проще поставить одну попытку на неправильный пароль при авторизации root ?🤔 я себе так поставил и вроде норм )

Брутефорсить сервак проще так как имя root уже известно. Попробуйте брутефорсить сервер где PermitRootLogin no ... а к какому логину перебирать пароль?

PermitRootLogin no по умолчанию уже давно и это правильно. Не сиди под рутом - козлёночком станешь.

Используйте шифрование на уровне базы данных и рассмотрите полное шифрование диска.

А что это даст, если сервер всегда онлайн?

Если злоумышленник проник в линукс систему, то диск уже будет смонтирован и доступен. Не понял зачем нужно шифрование диска.

Не упомянули про то, что доступ по SSH желателен из локальной сети по внутренним ip адресам. А к этому промежуточному серверу доступ уже через VPN канал. Тогда уже технически невозможно подключиться к SSH без доступа к внутренней сети.

А по хорошему SSH нужно прятать за HTTPS сервером, чтобы его нельзя было вообще обнаружить никак через сканирование. Проект SSH3 (SSH over HTTP/3) уже реализовал такое.

Так же имеется черновик для стандартизации нового протокола - Remote terminal over HTTP/3 connections

Зарегистрируйтесь на Хабре, чтобы оставить комментарий