Что ты выберешь и почему? Есть два пути и оба правильные.
AWS NACL. Нужно закрыть один порт - и сделать это можно двумя способами:
- Добавить правило “deny” с более высоким приоритетом, перед правилом “allow”.
- Разбить одно правило “allow” на два, исключив нужный порт из разрешённого диапазона.
У нас есть вот такие причины: Если мешать “deny” и “allow” правила - внимание рассеивается. Надо держать в голове каждый диапазон: что разрешено, что запрещено, плюс порядок нумерации. Запутаться легко.
Другое дело, если у тебя только одно “deny all” в конце - последнее правило, которое применяется последним. Тогда все остальные правила - только “allow”. Проверяешь проще: смотришь только на список портов, не думаешь про тип правила.
Звучит разумно, да? А теперь нюансы.
Пока портов немного - всё хорошо. Но когда их сотни с разными диапазонами - начинается веселье. Например, блокируем RDP 3389 - вместо одного правила получаем два диапазона. Все порты ниже 1024 тоже закрыты (кстати, помнишь почему?). Потом блокируем 3306, 5432, 6379 и так далее. Уже пять диапазонов. Каждый новый блокируемый порт меняет существующее правило и добавляет ещё одно.
Вот мы и пришли к сравнению двух подходов: “deny all” и “allow all” в конце. При “deny all” - явно разрешаем нужные порты. При “allow all” - явно запрещаем ненужные.
Почему не выбрать один подход для всего? Потому что ситуации разные.
В AWS Network Access Control List есть два списка правил - для ingress и для egress.
Для ingress обычно используют “deny all” - безопаснее. Для egress - “allow all”, потому что обычно хочется свободно ходить из своей сети в интернет, верно?
Но если нужен полный контроль трафика - разрешаем только конкретный список портов, нужных приложению. Тоже распространённая ситуация, просто чуть сложнее.
И тут приходим к ответам на запросы)))) Когда приложение отправляет запрос куда-то, оно должно получить ответ. А по протоколам TCP/IP ответ приходит на случайный порт где-то в диапазоне 40к. ;)
Но NACL - stateless штука! Он не помнит, что разрешил спросить секунду назад, и не пропустит ответ автоматически “потому что ты только что спросил”. Это фича security group. Для NACL нужно явно описать список портов, которые можно пропустить, в каждую сторону. Вот почему у нас есть правило allow ingress для диапазона 1024-65535. С исключениями.