Правила группы безопасности AWS EC2: указывается ли группа безопасности в качестве источника, который не считается более разрешающим, чем конкретный IP-адрес?

1177
sixty4bit

Я не был уверен, что это правильный sub-StackExchange для этого вопроса, поэтому не стесняйтесь загружать меня где-нибудь еще, если это будет необходимо.

Я пытаюсь работать с двумя серверами EC2: один - «рабочая станция», а другой - «узел» (подумайте Chef). Группа безопасности рабочей станции начиналась с одного входящего правила, которое разрешало доступ к порту 22 с IP-адреса моей локальной машины.

Я хотел, чтобы сервер узла был доступен с сервера рабочей станции, а также с моего локального компьютера. Поэтому вместо того, чтобы создавать новую группу безопасности, я просто добавил правило в группу безопасности, используемую на рабочей станции, с собственным идентификатором группы безопасности в качестве источника. Говоря простым языком, я собирался создать группу безопасности, которая разрешает доступ через порт 22 либо с IP-адреса моего локального компьютера, либо с любого компьютера, к которому также применена группа безопасности. Это было мое понимание того, как работает группа безопасности по умолчанию (весь трафик разрешен, причем источником является самоссылочный идентификатор группы безопасности).

На мой взгляд, это также соответствовало тому, что я нашел здесь в документах:

Если для определенного порта существует более одного правила, мы применяем наиболее разрешающее правило. Например, если у вас есть правило, разрешающее доступ к TCP-порту 22 (SSH) с IP-адреса 203.0.113.1, и другое правило, разрешающее доступ к TCP-порту 22 от всех, каждый имеет доступ к TCP-порту 22.

Мой случай, очевидно, немного отличается тем, что у меня есть правило, которое разрешает определенный доступ к порту 22 с определенного IP-адреса, и правило, которое разрешает определенный доступ к порту 22 из группы безопасности, а не «всех», но не будет источник группы безопасности также считается более разрешающим, чем конкретный IP-адрес, и, следовательно, разрешить сценарий, который я описал выше?

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

Любые идеи о том, что я могу делать неправильно / отсутствует?

1

2 ответа на вопрос

2
Michael - sqlbot

Я просто добавил правило в группу безопасности, используемую на рабочей станции, с собственным идентификатором группы безопасности в качестве источника.

Это противоположно тому, что вам нужно было сделать.

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

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

Спасибо что нашли время ответить. Я понимаю, что вы говорите, но надеялся, что у меня будет способ сделать это без создания более одной группы безопасности. Думаю, я действительно хочу разрешить 1) IP-адрес моей локальной машины и 2) входящий трафик с любой машины в подсети EC2. Я новичок в сетевом взаимодействии, но я должен быть в состоянии сделать # 2 с правилом, которое правильно использует 0 и маску подсети, верно? sixty4bit 7 лет назад 0
Группе безопасности на «узле» необходимо правило с группой безопасности рабочей станции в качестве источника. Машины выполняют разные роли, поэтому совместное использование одной группы безопасности нецелесообразно, но каждому классу компьютеров нужна только одна группа. Вероятно, распространенная ошибка - думать, что меньшее количество групп безопасности упростят ситуацию. Это не так, и это увеличивает вероятность неоправданного разрешения трафика там, где его нельзя допустить в будущем. Michael - sqlbot 7 лет назад 0
1
Putnik

Что на самом деле вы сделали: вы разрешаете доступ к рабочей станции с вашего IP-адреса и из любого другого экземпляра в той же группе (не имеет значения, если его сейчас нет, если вы добавите экземпляр в эту группу в будущем - он будет иметь доступ к SSH тоже.

Что нужно сделать: настроить SG, к которому принадлежит узел. Добавьте правило с вашим IP и правило с группой рабочих станций в качестве источника. Последний будет читаться как «разрешить доступ к порту 22 из всех экземпляров, которые находятся в workstation_group.

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

allow from 192.168.0.0/24 allow from 192.168.1.0/24

Здесь «правило большинства разрешающих правил» не будет применяться, потому что диапазоны не перекрываются: они фактически означают 

allow from 192.168.0.0 to 192.168.0.255 allow from 192.168.1.0 to 192.168.1.255

Вариант 2

allow from 192.168.0.0/22 (note '2' at the end) allow from 192.168.1.0/24

Здесь правило будет применяться, потому что диапазоны:

allow from 192.168.0.0 to 192.168.3.255 allow from 192.168.1.0 to 192.168.1.255

Таким образом, второй диапазон находится внутри первого, как маленькая коробка внутри большего. «Наиболее разрешительный» здесь означает, что будет работать первая строка, более широкий диапазон.

Не стесняйтесь проверить ipcalc для деталей.

Спасибо, что нашли время ответить и за детали. Поскольку основной ответ такой же, как у Майкла, и он был первым, я отметил его как правильный. sixty4bit 7 лет назад 0

Похожие вопросы