Преамбула: Итак, прежде чем я на самом деле задам вопрос, я хотел бы указать, что я несколько опасаюсь публиковать это, потому что даже когда я печатаю это, кажется, что я прошу кого-то просто сказать мне конфигурацию переключателя Мне нужно, но это не так. У меня уже завершена конфигурация главного коммутатора, и я готов вернуться к клиенту, но они попросили меня проверить / all / config, которые они собираются фактически применить к коммутаторам, а не только для конкретных приложений, следовательно вопрос ниже. В любом случае, теперь все кончено, и перейдем к собственно вопросу.
Я занимаюсь разработкой приложения для клиента, который будет работать на нескольких серверах AWS с балансировкой нагрузки под управлением Debian 7.5, которые будут доступны только через порт 80 для самого приложения со всех адресов и порт 22 для SSH только из нашего офиса. и офис внешней команды управления AWS клиента.
Политика безопасности клиента обязательно носит ограничительный характер, поскольку серверы будут содержать конфиденциальные бизнес-данные, поэтому конфигурация сети должна быть заблокирована для входящих и исходящих соединений со всех серверов в максимально возможной степени. Я уже изложил требования к этой части, и они согласованы между мной и командой AWS. Однако они попросили меня проверить окончательную конфигурацию, которую они собираются применить, и она включает следующие строки:
Source Destination Protocol Ports Service Action Description
0.0.0.0/0 192.168.0.0/16 TCP 1024-65535 Ephemeral Ports Allow Allows inbound return traffic from the Internet
192.168.0.0/16 0.0.0.0/0 TCP 32768-65535 Ephemeral Ports Allow Allows outbound responses to clients on the Internet (for example, serving web pages to people visiting the web servers in the subnet)
К сожалению, сетевой уровень - это один из аспектов модели OSI, о котором я знаю очень мало. Я смутно знал, что некоторые службы используют эфемерные порты для фактических рабочих подключений после того, как был установлен первоначальный запрос к известному порту службы, но я не уверен, каким службам действительно нужны эти порты, чтобы они были открыты на общедоступных интерфейсах серверов, чтобы эти серверы работали правильно. Комментарий подразумевает, что для работы веб-серверов требуется 32768-65535, но в прошлом я получал от них авторитетные ответы, которые позже оказались неверными, поэтому я хочу подтвердить это утверждение.
Любой из nginx или sshd требует, чтобы эфемерные порты были открыты, чтобы они могли правильно выполнять свои функции, или все действия всегда происходят только на портах, которые они были настроены для использования (например, 80 и 443 и 22 соответственно) ? Может ли закрытие эфемерных портов для трафика препятствовать правильной работе таких служб, как apt (который, как я считаю, обычно использует HTTP на порту 80 для взаимодействия со своими источниками)?
Кроме того, они добавили в конфигурацию следующие две строки, касающиеся DNS-запросов:
Source Destination Protocol Ports Service Action Description
0.0.0.0/0 192.168.0.0/16 TCP/UDP 53 DNS Allow Allows inbound DNS query from anywhere
192.168.0.0/16 0.0.0.0/0 TCP/UDP 53 DNS Allow Allows outbound DNS queries to anywhere
Сейчас мы не запускаем DNS-демоны на этих серверах, поэтому я почти уверен, что мы можем полностью исключить первую строку, но может ли закрытие 53 для входящего или исходящего трафика помешать серверам правильно разрешать имена хостов? Я должен признать, что никогда не изучал, как на самом деле DNS работает так тесно, как мне никогда не было необходимости. : s Предположим, сейчас хорошее время для начала!
Но да, краткое содержание tl; dr:
Будет ли закрытие портов 1024-65535 для всего трафика, как входящего, так и исходящего, препятствовать правильной работе любых из nginx, sshd, DNS-запросов или любых основных утилит операционной системы на серверах Debian?
Определение слова пара розеток:
Связь между локальными и удаленными сокетами называется парами сокетов. Каждая пара сокетов описывается уникальным набором из 4-х элементов, состоящим из IP-адресов источника и получателя и номеров портов, то есть локальных и удаленных адресов сокетов. [3] [4] В случае TCP каждой уникальной паре сокетов из 4 кортежей назначается номер сокета, тогда как в случае UDP каждому уникальному локальному адресу сокета назначается номер сокета.
На стороне сервера порт обычно фиксируется используемым протоколом / приложением. Например, SSH 22 и DNS 53.
На стороне клиента, который инициирует соединение с сервером, он должен выбрать порт источника, чтобы выполнить свою часть этого 4-кортежа, необходимого для однозначной идентификации соединения. Клиенты обычно выбирают случайный порт в диапазоне 1025-65535. Я полагаю, это то, что они называют эфемерными портами?
Некоторые протоколы (например, карта портов RPC) будут иметь сервер, прослушивающий фиксированный порт, клиент будет подключаться и запрашивать конкретную службу, прослушиватель предоставит порт, к которому клиент должен подключиться (обычно случайным образом, в пределах диапазона) и порождать службу в этом порту. Это всего лишь пример более сложной организации портов сервера, но никоим образом не требует использования определенных исходных портов со стороны клиента. Они должны быть случайными.
Фильтровать исходный порт довольно неудобно. В опубликованном вами списке не отображается, фильтруют ли они порты источника или назначения. Если вы действительно хотите усилить брандмауэр, используйте по умолчанию политику block = all и впустите только необходимые порты. Я бы не стал связываться с ограничением того, какие исходные порты можно использовать, если только вы не ищете проблем (например, клиенты не могут connect) или дополнительные работы (например, сложные правила межсетевого экрана).
Кажется, что в первом списке они указывают случайные из случайных портов, которые могут использовать клиенты. Почему им все равно?