Любой сервер, подключенный напрямую к сети интернет, должен быть надёжно защищён.
Будем разбираться, как этого достичь и что можно использовать.
Есть следующие методы на пути к обеспечению безопасности ваших серверов:
- надёжная парольная защита,
- своевременное обновление программного обеспечения,
- защита с помощью межсетевого экрана.
Применять эти методы следует в совокупности, остановимся подробнее на каждом из них.
Парольная защита
Под парольной зашитой подразумевается, что вы разработали и применяете парольную политику:
- не используете типовые имена учётных записей, такие как «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 и постами о ретроиграх 🕹️
