Назад | Перейти на главную страницу

Как настроить AWS Network Access Control List для SSH в частной подсети

Я прохожу курс по AWS. Я пытаюсь настроить VPC с двумя серверами Linux. Я установил VPC с двумя подсетями. Я поставил по одному серверу в каждый. Идея состоит в том, что одна подсеть является общедоступной, а другая - частной.

Я создал два сетевых ACL и связал по одному с каждой подсетью.

Я могу подключиться по SSH со своей машины к серверу в публичной подсети. Когда я пытаюсь подключиться по SSH к серверу в моей частной подсети, у меня истекает время ожидания соединения.

Я не уверен, какие правила мне нужно установить в двух моих сетевых ACL, чтобы SSH работал. Кто-нибудь может помочь? Учитывая, что я учусь, я был бы признателен за объяснение того, почему должны быть правила, а не только то, какими должны быть правила.

У меня есть VPC под названием MyVPC с CIDR 10.0.0.0/16
Моя первая подсеть называется MyVPCSub1 CIDR 10.0.1.0/24.
Моя вторая подсеть называется MyVPCSub2 CIDR 10.0.2.0/24
У меня есть таблица маршрутов MyInternetRoute, связанная с маршрутами MyVPCSub1:

|Dest        |Targ  |  
|10.0.0.0/16 |local |
|0.0.0.0/0   |igw   |

У меня есть таблица маршрутов MyPrivate, связанная с MyVPCSub2. Маршруты:

|Dest        |Targ  |
|10.0.0.0/16 |local |

У меня есть сетевой ACL MyWeb, связанный с MyVPCSub1, с правилами:

Входящий:

| #   | Type | Protocol | Ports | Source     | A/D
| 99  | HTTP | TCP      | 80    | {My IP}/32 | D
| 100 | HTTP | TCP      | 80    | 0.0.0.0/0  | A
| 200 | HTTPS| TCP      | 443   | 0.0.0.0/0  | A
| 300 | SSH  | TCP      | 22    | {My IP}/32 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0  | D

Исходящий:

| #   | Type   | Protocol | Ports      | Source     | A/D
| 50  | ALL    | ALL      | ALL        | 0.0.0.0/0  | A
| 100 | HTTP   | TCP      | 80         | 0.0.0.0/0  | A
| 200 | HTTPS  | TCP      | 443        | 0.0.0.0/0  | A
| 300 | Custom | TCP      | 1024-65535 | 0.0.0.0/32 | A
| *   | ALL    | ALL      | ALL        | 0.0.0.0/0  | D

У меня есть сетевой ACL MyPrivate, связанный с MyVPCSub2, с правилами:

Входящий:

| #   | Type | Protocol | Ports | Source    | A/D
| 100 | ALL  | ALL      | ALL   | 0.0.0.0/0 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0 | D

Исходящий:

| #   | Type | Protocol | Ports | Source    | A/D
| 100 | ALL  | ALL      | ALL   | 0.0.0.0/0 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0 | D

Прежде всего необходимо определить, что означают некоторые термины.

NACLS - списки управления доступом к сети,Меньше фильтр пакетов, применяемый на уровне подсети. Важно помнить об аспекте отсутствия состояния, это означает, что вам необходимо четко указывать весь трафик, входящий в подсеть и покидающий ее. Например, с подходом к правилу «полное состояние» (который применяется группой безопасности в AWS) вы можете просто указать входящий трафик TCP / 22 для SSH, и он автоматически разрешит исходящий трафик. С NACLS это не так, вам нужно будет указать правило для каждого направления, чтобы разрешить прохождение трафика.

Группы безопасности - это группы состояний-полный правила, которые могут применяться к одному или нескольким экземплярам в VPC. Обратите внимание, что они применяются на уровне экземпляра. Группу безопасности можно сравнить с традиционным межсетевым экраном с полным состоянием, но поскольку он применяется на уровне отдельного экземпляра, вы можете отделить экземпляры друг от друга даже в пределах одной подсети, что приятно. И поскольку они полны состояния, если вы хотите разрешить трафик на сервер (например, TCP / 22 для SSH), вам не нужно беспокоиться о создании соответствующего исходящего правила, платформа позаботится об этом автоматически, поэтому ими намного проще управлять, что также означает меньшую вероятность ошибок.

Есть хорошая таблица, которая сравнивает эти два: Сравнение безопасности VPC

На этой странице также есть красивая диаграмма, которая показывает порядок вещей, применяемых к трафику в зависимости от направления потока ... так что проверьте это.

Тогда в отношении подсетей мы имеем:

Общедоступная подсеть - в терминах AWS это просто подсеть, к которой прикреплена таблица маршрутов, которая имеет маршрут 0.0.0.0/0 через подключенный интернет-шлюз.

Частная подсеть - это наоборот, т.е. не иметь маршрут 0.0.0.0/0 через подключенный интернет-шлюз. Обратите внимание, что он все еще может иметь маршрут 0.0.0.0/0 через NAT-шлюз или аналогичный прокси-сервер в вашей среде, но не напрямую.

Вопрос в том, когда у вас есть NACLS и группы безопасности - что вы используете. AWS описывает NACL как «дополнительный уровень безопасности для вашего VPC». И правда, что в целом групп безопасности достаточно, они более гибкие и обеспечивают такую ​​же защиту. По моему опыту, есть несколько типичных случаев, когда я вижу использование NACLS:

  1. Черные дыры для известных злоумышленников - если вы подверглись атаке с определенного диапазона IP-адресов, можно просто добавить NACL, который полностью блокирует источник IP / подсети.
  2. В качестве способа делегирования управления командам - ​​группа безопасности применяет общие конфигурации NACL (например, разрешает трафик только из доверенных корпоративных сетей), а затем разрешает командам разработчиков и операторов настраивать свои собственные правила группы безопасности. Таким образом, даже если инженер попытается открыть группу безопасности на своем экземпляре для тестирования в Интернете, NACL заблокирует ее. Вы можете использовать IAM, чтобы ограничить круг лиц, которые могут изменять NACL, но предоставить командам доступ для управления всем остальным, он действует как отличное средство защиты от ошибок неправильной конфигурации в более крупных средах.

AWS также предоставляет некоторые рекомендации по ряду сценариев конфигурации, доступных здесь: Рекомендуемые сетевые правила ACL для вашего VPC

Хотя я рекомендую, как правило, группы безопасности обеспечивают подходящую защиту, их легче понять и настроить, а также они более гибкие и детализированные в своем приложении. NACL предоставляют дополнительную защиту от человеческой ошибки или более сложных конфигураций, но для базового использования они обычно не используются. Поэтому я предполагаю, почему AWS называет их «необязательными».

Я бы оставил NACL в их конфигурации по умолчанию (разрешить весь входящий и исходящий трафик) и вместо этого сосредоточиться на группах безопасности пока, поскольку использование NACL в качестве второго уровня только добавит дополнительный уровень сложности, который, возможно, не нужен в вашем сценарии. С точки зрения обучения хорошо знать, что они есть, они не имеют состояния, они применяются на уровне подсети, и они применяются после решения о маршрутизации и до групп безопасности для трафика, входящего в подсеть.

Что касается вашей конкретной ситуации, поскольку вы используете NACL, вам нужно помнить, что они являются государственными.Меньше. Поэтому необходимо учитывать все входящие и исходящие потоки трафика из подсети - основная причина, по которой группы безопасности намного проще. Итак, в вашем случае у вас есть:

  • Трафик на ваш общедоступный сервер по TCP / 22 с вашего IP - да - правило № 300 для входящих
  • Вернуть трафик с вашего общедоступного сервера на порт высокого уровня для обратного SSH-трафика - да - исходящее правило № 50 (но не правило № 300 - см. Ниже)
  • Трафик из вашей общедоступной подсети, исходящий в вашу частную подсеть по TCP / 22 - да - правило № 50 исходящее
  • Трафик, входящий в частную подсеть из публичной - да - правило # 100 входящее
  • Вернуть трафик с вашего частного сервера на общедоступный сервер в частной подсети - да - правило № 100 исходящее
  • Верните трафик с вашего частного сервера на публичный сервер на общественный subnet - ah - нет, нет правила, разрешающего возвращение высокого порта (временного порта, который ssh-клиент использует на общедоступном сервере для инициации подключения к частному) с частного сервера.

Вам необходимо добавить правило, подобное правилу № 300 (но обратите внимание, что вы немного неправильно отформатировали исходный IP-адрес - см. Ниже) в свой исходящий общедоступный ACL подсети, но в привязке с источником частной подсети. Затем, если ваши группы безопасности настроены правильно, все готово.

Надеюсь, это поможет.

Чтобы добавить - согласно другому ответу - правило № 300 в наборе исходящих правил общедоступной подсети неправильно отформатировано. Это должно быть 0.0.0.0/0, а не 0.0.0.0/32, однако в вашем случае вы не попали, так как правило № 50 применяется первым и в любом случае разрешает весь трафик - так что, хотя это не сработает, это не было на самом деле не вызывает вашей проблемы.

ACL не имеют состояния.

Ваша «общедоступная» подсеть, вероятно, блокирует обратный путь для вашего SSH-соединения из частной подсети. Вам также потребуется правило, эквивалентное исходящему для всех портов на входящей стороне, хотя вы можете ограничить его диапазоном подсети 10.0.2.0/24.

Отредактировано для добавления: Кроме того, исходящее правило для 0.0.0.0/32 просто неверно. Если ваш IP-адрес не равен 0.0.0.0, он не будет работать.