Изменить порт по умолчанию или настроить файрвол правильно?

Любой сервер, подключенный напрямую к сети интернет, должен быть надёжно защищён.

Есть следующие методы на пути к обеспечению безопасности ваших серверов:

• надёжная парольная защита,
• своевременное обновление программного обеспечения,
• защита с помощью межсетевого экрана.

Применять эти методы следует в совокупности, остановимся подробнее на каждом из них.

Парольная защита

Под парольной зашитой подразумевается, что вы разработали и применяете парольную политику:

• не используете типовые имена учётных записей, такие как «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.

Сравним, насколько часто на наши сервера пытались проникнуть в зависимости от настроек.

На нестандартном порту попыток меньше в два раза. Отсутствие отклика по ICMP никак не влияет.

Интересно то, что отсутствие ответа на ICMP Echo в случае, когда мы оставили порт по умолчанию, ничего не поменяло (отклонение в рамках погрешности), а вот когда порт был изменён, что снизило попытки подключения почти в четыре раза, недоступность сервера по ICMP привела к сокращению попыток подключения ещё вдвое. Как сокращение записи на диск такой метод, конечно, подойдёт, но с точки зрения обеспечения безопасности лучше правильно настроить файрвол.

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх