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

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

 Своевременная установка обновлений значительно снижает риск проникновения при надёжной парольной защите. Постоянно обнаруживаются всё новые уязвимости в программном обеспечении, и их производитель выпускает исправления, которые необходимо своевременно применять для закрытия уязвимостей. Бытует мнение, что эти уязвимости создаются специально, и толку от обновлений нет никакого: сегодня мы устраняем известные уязвимости, а завтра появятся новые. Здесь дело даже не в том, специально закладываются эти уязвимости в качестве т. н. бэкдоров, или нет. Дело в том, что пока известная уязвимость существует, её можно эксплуатировать. И чем дольше она существует, тем более широкому кругу лиц она доступна, т. к. со временем появляются готовые инструменты для её эксплуатации – эксплойты, которые изначально могут продаваться за деньги, а затем становятся общедоступными. Поэтому чем меньше будет окно уязвимости, тем безопаснее нам с вами будет. Причина появления уязвимости не так важна, куда важнее её закрыть как можно быстрее. Перейдём к защите с помощью межсетевого экрана. Есть неправильные практики применения файрвола. Например, мы лишь блокируем определённые соединения, а весь остальной трафик у нас разрешён. Правильным же подходом является запрет любого трафика и разрешение трафика, удовлетворяющего конкретным условиям.Приведём пример. У нас есть узел с веб-сервером, файловым сервером и удалённым доступом. Нам нужно сделать так, чтобы из интернета был доступен только веб-сервер. При первом подходе вам нужно запрещать трафик для файлового сервера, удалённого доступа, а также проверять, что ещё сетевого на сервере работает (вот «здорово», если у вас база данных находится на этом же сервере и случайно «смотрит» не только в localhost, но и в интернет, а вы забыли закрыть порт файрволом, да ещё и обновления безопасности не устанавливаете). Вместо этого достаточно создать одно правило, запрещающее весь трафик, и ещё одно – разрешающее входящий трафик на наш веб-сервер. Ну и ещё одно, чтобы разрешить icmp echo, если мы хотим, чтобы наш сервер отвечал на «пинг». Исходящие подключения, как правило, разрешены по умолчанию. Если нет, то нужно создать такое правило. В качестве примера разберём работу с сервером по протоколу SSH. Если мы подключаемся всегда из одного и того же места (например, из офиса) и внешний адрес всегда один и тот же (организации часто получают статический внешний адрес), мы просто вносим его в разрешающее правило. Например, ваш постоянный адрес — 203.0.113.243, и вам нужно ограничить доступ по SSH, тогда добавляем следующее правило:

 Если адрес меняется, можно внести диапазон адресов. Например, вы подключаетесь к своему серверу либо из дома, либо через мобильный интернет. Вы можете ограничить подключения к своему серверу подсетью провайдера. Посмотрите whois информацию об адресе, чтобы узнать, к какому диапазону он принадлежит и добавьте в правило весь диапазон. (В одном конкретном случае это была /22 подсеть в случае с одним провайдером и /23 в случае с другим. Подобный приём для мобильной сети пришлось провернуть раза три.) И это помогает, ведь мы очень сильно ограничиваем адреса, с которых доступен наш сервер. Например, сейчас ваш адрес — 198.51.100.54. Вы узнали, что адрес принадлежит сети 198.51.100.0/24, и вам нужно ограничить доступ по SSH. Тогда внесём всю подсеть следующим образом:

 В личном кабинете на сайте 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 привела к сокращению попыток подключения ещё вдвое. Как сокращение записи на диск такой метод, конечно, подойдёт, но с точки зрения обеспечения безопасности лучше правильно настроить файрвол.