☰

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

tag-icon • tag-icon ssh amazon-web-services access-control-list amazon-vpc
Как настроить список контроля доступа к сети AWS для 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

решение1

Первое, что нужно сделать, — это определить, что означают некоторые термины.

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 (например, разрешая трафик только из доверенных корпоративных сетей), а затем позволяет командам ops/dev настраивать собственные правила групп безопасности. Таким образом, даже если инженер попытается открыть группу безопасности на своем экземпляре для Интернета для тестирования, NACL заблокирует ее. Вы можете использовать IAM, чтобы ограничить тех, кто может изменять NACL, но предоставить командам доступ для управления всем остальным, это действует как отличная защита от ошибок конфигурации в более крупных средах.

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

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

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

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

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

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

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

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

решение2

Списки управления доступом не имеют состояния.

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

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

Связанный контент