Любой сервер, подключенный напрямую к сети интернет, должен быть надёжно защищён.
Будем разбираться, как этого достичь и что можно использовать.
Есть следующие методы на пути к обеспечению безопасности ваших серверов:
- надёжная парольная защита,
- своевременное обновление программного обеспечения,
- защита с помощью межсетевого экрана.
Применять эти методы следует в совокупности, остановимся подробнее на каждом из них.
Парольная защита
Под парольной зашитой подразумевается, что вы разработали и применяете парольную политику:
- не используете типовые имена учётных записей, такие как «user», «admin», «root» и так далее,
- используете сложные пароли. На самом деле, в большинстве случаев достаточно, чтобы пароль не подбирался по словарю, т. е. не был эквивалентен «123456», «admin», «password» и т.д. Дело в том, что классический перебор паролей малоэффективен, поскольку при правильной настройке после нескольких неуспешных попыток авторизации блокируется учётная запись и (или) адрес, с которого производятся неуспешные попытки, заносится в список блокировки временно или на постоянной основе в соответствии с вашей политикой,
- регулируете сложность паролей и частоту их смены. Сейчас более безопасным считается такой подход, при котором единожды задаётся надёжный пароль, нежели подход, при котором пароль нужно менять через определённый промежуток времени. Какой подход использовать – выбирать вам.
Обновление ПО
Своевременная установка обновлений значительно снижает риск проникновения при надёжной парольной защите. Постоянно обнаруживаются всё новые уязвимости в программном обеспечении, и их производитель выпускает исправления, которые необходимо своевременно применять для закрытия уязвимостей. Бытует мнение, что эти уязвимости создаются специально, и толку от обновлений нет никакого: сегодня мы устраняем известные уязвимости, а завтра появятся новые. Здесь дело даже не в том, специально закладываются эти уязвимости в качестве т. н. бэкдоров, или нет. Дело в том, что пока известная уязвимость существует, её можно эксплуатировать. И чем дольше она существует, тем более широкому кругу лиц она доступна, т. к. со временем появляются готовые инструменты для её эксплуатации – эксплойты, которые изначально могут продаваться за деньги, а затем становятся общедоступными. Поэтому чем меньше будет окно уязвимости, тем безопаснее нам с вами будет. Причина появления уязвимости не так важна, куда важнее её закрыть как можно быстрее.
Файрвол
Перейдём к защите с помощью межсетевого экрана. Есть неправильные практики применения файрвола. Например, мы лишь блокируем определённые соединения, а весь остальной трафик у нас разрешён. Правильным же подходом является запрет любого трафика и разрешение трафика, удовлетворяющего конкретным условиям.Приведём пример. У нас есть узел с веб-сервером, файловым сервером и удалённым доступом. Нам нужно сделать так, чтобы из интернета был доступен только веб-сервер. При первом подходе вам нужно запрещать трафик для файлового сервера, удалённого доступа, а также проверять, что ещё сетевого на сервере работает (вот «здорово», если у вас база данных находится на этом же сервере и случайно «смотрит» не только в localhost, но и в интернет, а вы забыли закрыть порт файрволом, да ещё и обновления безопасности не устанавливаете). Вместо этого достаточно создать одно правило, запрещающее весь трафик, и ещё одно – разрешающее входящий трафик на наш веб-сервер. Ну и ещё одно, чтобы разрешить icmp echo, если мы хотим, чтобы наш сервер отвечал на «пинг». Исходящие подключения, как правило, разрешены по умолчанию. Если нет, то нужно создать такое правило.
▍ Как ограничить внешние подключения
В качестве примера разберём работу с сервером по протоколу SSH.
Если мы подключаемся всегда из одного и того же места (например, из офиса) и внешний адрес всегда один и тот же (организации часто получают статический внешний адрес), мы просто вносим его в разрешающее правило.
Например, ваш постоянный адрес — 203.0.113.243, и вам нужно ограничить доступ по SSH, тогда добавляем следующее правило:
iptables -t filter -A INPUT -p tcp -s 203.0.113.243 --dport 22 -j ACCEPTЕсли адрес меняется, можно внести диапазон адресов. Например, вы подключаетесь к своему серверу либо из дома, либо через мобильный интернет. Вы можете ограничить подключения к своему серверу подсетью провайдера. Посмотрите whois информацию об адресе, чтобы узнать, к какому диапазону он принадлежит и добавьте в правило весь диапазон. (В одном конкретном случае это была /22 подсеть в случае с одним провайдером и /23 в случае с другим. Подобный приём для мобильной сети пришлось провернуть раза три.) И это помогает, ведь мы очень сильно ограничиваем адреса, с которых доступен наш сервер.
Например, сейчас ваш адрес — 198.51.100.54. Вы узнали, что адрес принадлежит сети 198.51.100.0/24, и вам нужно ограничить доступ по SSH. Тогда внесём всю подсеть следующим образом:
iptables -t filter -A INPUT -p tcp -s 198.51.100.0/24 --dport 22 -j ACCEPT▍ Управление файрволом из ЛК хостера
В личном кабинете на сайте RUVDS вы можете управлять правилами для сетевого адаптера виртуальной машины. Удобство заключается в том, что при переустановке ОС на сервере не нужно настраивать файрволл внутри ОС – правила, заданные в личном кабинете, сохраняются.
В первую очередь нужно понимать, что мы будем работать со stateless файрволом, который не отслеживает состояния соединений. Здесь по незнанию можно ошибиться и подумать, что файрвол не работает или работает неправильно. Когда мы создаём правило, запрещающее весь входящий трафик, то блокироваться будет вообще весь трафик, включая и все ответы на наши запросы, потому что направление этого трафика – входящее. Если мы хотим получать ответы, для этого тоже нужно создать правила. Например, если хотим получать ответы от DNS-серверов, нам нужно разрешить входящий трафик с 53 UDP порта удалённых узлов. Хотим получать ответы по протоколу HTTP(S) – нужно сделать то же самое для TCP портов 80 и 443. И так далее.
Для удобства есть преднастроенные правила для распространённых протоколов и наборы правил для серверов с Windows и для серверов с Linux.
Небольшой эксперимент
Мы решили проверить, насколько эффективно менять стандартный RDP или SSH порт, а также не отвечать на ICMP-запросы и создали несколько серверов. Сервера с 1 по 4: с SSH-сервером, имеют IP-адреса, отличные друг от друга не более чем на 3; сервера с 5 по 8: с RDP-сервером, и также имеют IP-адреса, отличные друг от друга не более чем на 3.
| Сервер | Порт SSH/RDP | ICMP Echo |
| Сервер 1 | 22 | да |
| Сервер 2 | 22 | нет |
| Сервер 3 | N+22 | да |
| Сервер 4 | N+22 | нет |
| Сервер 5 | 3389 | да |
| Сервер 6 | 3389 | нет |
| Сервер 7 | N+3389 | да |
| Сервер 8 | N+3389 | нет |
Сравним, насколько часто на наши сервера пытались проникнуть в зависимости от настроек.
На нестандартном порту попыток меньше в два раза. Отсутствие отклика по ICMP никак не влияет.
Интересно то, что отсутствие ответа на ICMP Echo в случае, когда мы оставили порт по умолчанию, ничего не поменяло (отклонение в рамках погрешности), а вот когда порт был изменён, что снизило попытки подключения почти в четыре раза, недоступность сервера по ICMP привела к сокращению попыток подключения ещё вдвое. Как сокращение записи на диск такой метод, конечно, подойдёт, но с точки зрения обеспечения безопасности лучше правильно настроить файрвол.
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ????️
Комментарии (28)
Pochemuk
30.05.2023 09:19+4Сама смена порта мало дает прибавки к надежности. У меня RDP был выведен на внешние порты 3389x, но очень быстро они оказались скомпрометированы. Пришлось вообще прикрыть их, где возможно.
Но вот если стандартный порт сменить на нестандартный, а на стандартный навесить ханипот с мгновенной блокировкой IP источника на недельку, на другую ... Это уже полезнее, т.к. в первую очередь будет попытка сканирования именно стандартных портов.
MiraclePtr
30.05.2023 09:19Зависит от протокола, видимо. Когда SSH висел на 22 порту, fail2ban срабатывал каждые пол часа, стоило перевесить на порт сильно выше (в районе верхней границе диапазона), теперь баннилка срабатывает раз в месяц, а то и реже.
Lazhu
30.05.2023 09:19+4Открытый доступ к машине с белым IP чему-то кроме ВПН с самоподписными сертификатами - случай классического ССЗБ
dlinyj
30.05.2023 09:19+1Например, сейчас ваш адрес — 198.51.100.54. Вы узнали, что адрес принадлежит сети 198.51.100.0/24, и вам нужно ограничить доступ по SSH. Тогда внесём всю подсеть следующим образом:
iptables -t filter -A INPUT -p tcp -s 198.51.100.0/24 --dport 22 -j ACCEPT
Тот странный случай, когда в 2023 году читаешь инструкцию по iptables. А её не ставят в современные дистрибутивы…
Подробнее, как перейти с iptables на nftables (статья в блоге этой же компании).
mayorovp
30.05.2023 09:19+2Проверил свежий Ubuntu Server — iptables стоит
DaemonGloom
30.05.2023 09:19+3Это слой совместимости nftables со старым синтаксисом. Но вообще, на ubuntu всё же стоит использовать ufw тогда (или отключать его, переходя полностью на nft).
$ update-alternatives --config iptables Есть 2 варианта для альтернативы iptables (предоставляет /usr/sbin/iptables). Выбор Путь Приор Состояние ------------------------------------------------------------ * 0 /usr/sbin/iptables-nft 20 автоматический режим 1 /usr/sbin/iptables-legacy 10 ручной режим 2 /usr/sbin/iptables-nft 20 ручной режим
cupespresso
30.05.2023 09:19+1Или как вариант — firewalld. Правила из iptables в него тоже можно вставить, с незначительными изменениями в синтаксисе.
swshoo
30.05.2023 09:19+2китайским ботам всё равно, поменяли вы порт или нет. Тут более менее срабатывает порткнокинг на фаерволе, защита по сертификату (но если пользюков много отснашают вопросами по установке и.т.д.), ограничение по подсетям для подключения (если есть такая возможность), использование Fail2ban или аналогов. И двухфакторная авторизация по типу Google Authenticator - настраивать геморно, но штука очень не плохая.
Darkholme
30.05.2023 09:19А как китайские боты узнают о наличии хоста, если порты не стандартные? Если условный http сервер легко обнаружится автоматическим сканом, то со шлюзом будет посложнее - нужно ведь сканировать все порты во всем Интернете. А в остальном согласен - с port knocking ваши логи будут чистыми а системы в безопасности.
LevOrdabesov
30.05.2023 09:19китайским ботам всё равно
Если вы не ждёте посетителй из Китая, то
GeoIP -> China -> Blockна пару порядков снижает головную боль.
swshoo
30.05.2023 09:19Мы с ними работаем -). Но это вообще не самый хороший вариант - в случае проблем диагностика может превратиться в кошмар.
miga
30.05.2023 09:19Нестандартные порты, порт нокинг - это все security through obscurity, и, следовательно, не нужно и вредно. Оно, может быть, и снизит количество ботов на графиках, но боты и так безвредны (тут как с акулами, нет нужды плыть быстрее всех); в то же время, от направленной атаки это вас никак не защитит
fail2ban еще туда-сюда, но тут надо понимать, что он может и в ногу пальнуть.
Darkholme
30.05.2023 09:19Port knocking не просто "снизит количество ботов на графиках", а практически полностью убирает возможность атак эксплойтов и перебора, также достаточно неплохо защитит от DoS/DDoS. Боты тоже не обязательно перебором будут заниматься. Вот вы уверены, что после сканера к вам не прилетит перебор уязвимостей?
miga
30.05.2023 09:19Ну смотрите, нокинг, очевидно, нельзя использовать на портах публичных сервисов, типа хттп, смтп и так далее. Соответственно, от уязвимостей в этих сервисах он не защищает. Что у нас тогда остается? Всякие служебные порты, вроде ssh. Ну, удачи попытаться найти там уязвимость.
Так что да, вполне уверен, и за почти 20 лет меня ломали только через очевидно глупые настройки веб-серверов, VoIP серверов (особенно больно) и прочих публичных штук.
Darkholme
30.05.2023 09:19Да, но вы забываете, что бывают серверы, на которых публичных сервисов как таких нету. Те самые шлюзы. И вот там опция "остаться невидимым" ой как хороша.
miga
30.05.2023 09:19Ну, "ой как хороша" это так себе аргумент, я бы рекомендовал вместо админских баек и присказок руководствоваться чем-то более рациональным:
Модель злоумышленника. От кого мы хотим защититься? (От неведомого хакера, который будет искать уязвимости в sshd?)
Цена, как настройки всех этих выкрутасов, так и удобство использования
Надежность. Что будет если какой-нить knockd внезапно умрет/закрешлупится, системд не сможет его перезапустить (например, место кончилось), как тогда доступаться?
Вот после ответа хотя бы на эти вопросы уже можно подумать, а надо ли оно вам.
Darkholme
30.05.2023 09:19Так я ведь не из админских баек это всё услышал, а дошёл по собственному опыту. Приходилось администрировать сетевое оборудование MT. Там есть достаточно неплохая графическая утилита winbox. Но вот протокол немного дырявый и иногда обнаруживаются серьёзные уязвимости. Открыл в мир и прохлопал момент - сеть скомпрометирована. Открывать каждый раз - страдает удобство и логи ssh всегда забиты. И тут киллерфича в виде простукивания спасает.
Вообще никто и не говорил, что оно применимо везде и всегда. Неудобства тоже имеются. В крупном ентерпрайзе вряд ли кто-то будет использовать. Но открытый в мир sshd и ко - моветон.
Вообще есть компромиссное решение в виде VPN. Ентерпрайз тоже использует для доступа к управлению.
swshoo
30.05.2023 09:19От уязвимости в таких сервисах ничего не защищает. Только своевременные обновления модулей вебсервера, скриптов и.т.д. Вот только не всё можно обновить. Это вообще большая головная боль.
miga
30.05.2023 09:19О том-то и речь, лучше потратить время и усилия на защиту того, что реально уязвимо.
ifap
За смену порта по умолчанию скажут "спасибо" те, у кого свой файрвол настроен правильно, т.е. разрешает обращение к веб-серверам только по стандартным портам.
Darkholme
И часто вы видите жесткую блокировку всех портов назначения, кроме белого списка? Как по мне, для таких в аду отдельный котел должен стоять.
ifap
Ежедневно.
Мотивируете?
mayorovp
Да запросто. В интернете полным-полно веб-серверов, которые настроены "неправильно", т.е. на другом порту. Если вы запрещаете все нестандартные порты - вы просто теряете совместимость с www.
ifap
"Неправильно" Вы неправильно в кавычки взяли, т.к. см. рис.1 фиг.2 и все, что не соответствует - неправильно без всяких кавычек и это оно теряет совместимость с WWW, а не наоборот. На практике я всего несколько раз сталкивался с HTTP не на 80 порту, и то ЕМНИП это всегда были альтернативные HTTP-порты, а не взятые от балды. HTTPS не на 443 вообще не встречал.
mayorovp
Вы как-то неправильно смотрите на этот список. Суть общеизвестных и зарегистрированных портов - не в том, что программы обязаны их использовать, а в том что программы обязаны их не использовать если порт регистрировался не для них.
То есть любая программа, которая выступает в роли HTTP-сервера технически, но при этом не является HTTP-сервером общего назначения, не может использовать ни порт 80, ни альтернативные порты HTTP (по крайней мере, в настройках по умолчанию). Но это не означает что доступ к ней следует запрещать.
ifap
Формально Вы правы, фактически же сегодня: если веб-сервер, то 80/443. Я еще застал времена, когда было 8080 и то редко, а сегодня уже и не вспомню, где видел такое.
Я и не утверждал, что следует запрещать всем, кроме браузера - это решается по месту, речь шла о том, что администратору сервера следует помнить и о другой стороне, у которой может стоять запрет (в т.ч. на местном сервере, т.е. не под контролем пользователя) на исходящие соединения по нестандартным портам. В частности, запрет на HTTP по портам, отличным от 80/443.