SSH-соединение с public интерфейса при явном запрете

[t800]

Добрый день

Столкнулся вот с такой ситуацией. Есть два кинетика. Локальный - Гига-1 и удалённый - Гига-2. Настройки ssh-сервера у меня в Гиге-1:

ip ssh
security-level private
lockout-policy 5 15 3
session timeout 3600

То есть, явно указано, что принимаются входящие соединения только с интерфейсов, где security-level установлен = private. Далее, в Гига-1 настроен WG-туннель до Гига-2. Интерфейс имеет уровень public:

interface Wireguard0
description WG-Tunnel
security-level public
ip address 10.0.0.2 255.255.255.0
ip mtu 1324
ip access-group _WEBADMIN_Wireguard0 in
ip tcp adjust-mss pmtu
wireguard peer *** !WG-S
endpoint ****:16332
keepalive-interval 30
allow-ips 10.0.0.0 255.255.255.0
allow-ips 192.168.1.0 255.255.255.0
allow-ips 192.168.2.0 255.255.255.0

При этом ssh соединения, входящие на этот интерфейс (из сети с Гига-2) без проблем устанавливаются с сервером на Гига-1. Открыл кейс в поддержку. Первый ответ был вообще удивительным. Мол, исходно соединение приходит из Home сегмента удалённого кинетика (Гига-2), где тип интерфейса - private. Поэтому Гига-1 принимает входящие ssh соединения.

На мой вопрос откуда известен тип исходного интерфейса, особенно если на удалённом конце мог быть НЕ кинетик вообще, я получил второй ответ. Что соединение устанавливается, потому что у меня есть аксесс-лист, разрешающий входящие соединения из удалённой сети. Но это же ерунда, аксесс-лист не меняет тип интерфейса и не меняет логику ssh-сервера, он просто разрешает входящие соединения извне! Тем не менее, такой ответ предоставлен официально, я на него дал свои комментарии, но хотел бы услышать мнение сообщества. Может я чего-то не понимаю и исходно неправ в ожиданиях?

[r13]

1 час назад, t800 сказал:

Добрый день

Столкнулся вот с такой ситуацией. Есть два кинетика. Локальный - Гига-1 и удалённый - Гига-2. Настройки ssh-сервера у меня в Гиге-1:

ip ssh
security-level private
lockout-policy 5 15 3
session timeout 3600

То есть, явно указано, что принимаются входящие соединения только с интерфейсов, где security-level установлен = private. Далее, в Гига-1 настроен WG-туннель до Гига-2. Интерфейс имеет уровень public:

interface Wireguard0
description WG-Tunnel
security-level public
ip address 10.0.0.2 255.255.255.0
ip mtu 1324
ip access-group _WEBADMIN_Wireguard0 in
ip tcp adjust-mss pmtu
wireguard peer *** !WG-S
endpoint ****:16332
keepalive-interval 30
allow-ips 10.0.0.0 255.255.255.0
allow-ips 192.168.1.0 255.255.255.0
allow-ips 192.168.2.0 255.255.255.0

При этом ssh соединения, входящие на этот интерфейс (из сети с Гига-2) без проблем устанавливаются с сервером на Гига-1. Открыл кейс в поддержку. Первый ответ был вообще удивительным. Мол, исходно соединение приходит из Home сегмента удалённого кинетика (Гига-2), где тип интерфейса - private. Поэтому Гига-1 принимает входящие ssh соединения.

На мой вопрос откуда известен тип исходного интерфейса, особенно если на удалённом конце мог быть НЕ кинетик вообще, я получил второй ответ. Что соединение устанавливается, потому что у меня есть аксесс-лист, разрешающий входящие соединения из удалённой сети. Но это же ерунда, аксесс-лист не меняет тип интерфейса и не меняет логику ssh-сервера, он просто разрешает входящие соединения извне! Тем не менее, такой ответ предоставлен официально, я на него дал свои комментарии, но хотел бы услышать мнение сообщества. Может я чего-то не понимаю и исходно неправ в ожиданиях?

Public private - это пресеты для  настройки firewall. Если настроили acl то будет использоваться acl, у них приоритет выше.

[t800]

12 минуты назад, r13 сказал:

Public private - это пресеты для  настройки firewall. Если настроили acl то будет использоваться acl, у них приоритет выше.

Согласен. Только причём здесь ssh-сервер? ACL это набор запретов и разрешений для интерфейса. Для ssh-сервера я не создаю никаких ACL. Почему ACL на интерфейсе Wireguard0 оверрайдит прямой запрет на коннект с public интерфейсов на ssh-сервере? 

[r13]

6 часов назад, t800 сказал:

Согласен. Только причём здесь ssh-сервер? ACL это набор запретов и разрешений для интерфейса. Для ssh-сервера я не создаю никаких ACL. Почему ACL на интерфейсе Wireguard0 оверрайдит прямой запрет на коннект с public интерфейсов на ssh-сервере? 

Потому что у acl приоритет выше. Лучше покажите какие acl созданы для интерфейса. Возможно там и еет ничего. 

[t800]

17 часов назад, r13 сказал:

Потому что у acl приоритет выше

Приоритет выше для интерфейса же, на котором ACL создан, а не для всех прочих интерфейсов или компонентов, имеющих настраиваемый уровень безопасности. 

 

17 часов назад, r13 сказал:

Лучше покажите какие acl созданы для интерфейса. Возможно там и еет ничего

Есть. Разрешён входящий трафик по протоколу IP; источник - удалённая сеть (192.168.1.0/24), цель - локальная сеть (192.168.0.0/24)

Edited March 11, 2022 by t800

[Le ecureuil]

self-test отправляли в поддержку с гига-1? Если да, то скажите номер в zendesk.

[t800]

15 минут назад, Le ecureuil сказал:

self-test отправляли в поддержку с гига-1? Если да, то скажите номер в zendesk.

Не отправлял, только куски конфигурации. Но инженер поддержки и не просил, с его точки зрения всё очевидно, а я неправ в своих ожиданиях. Посмотрите - запрос № 578948

[Le ecureuil]

18 минут назад, t800 сказал:

Не отправлял, только куски конфигурации. Но инженер поддержки и не просил, с его точки зрения всё очевидно, а я неправ в своих ожиданиях. Посмотрите - запрос № 578948

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

[t800]

20 минут назад, Le ecureuil сказал:

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

Отправил в запрос. 

Виноват, обычно вполне внятно изъясняюсь. Попробую еще раз:

1. Есть два кинетика - Giga и Giga-III, между ними поднят Wireguard-тоннель, имя интерфейса на обоих - Wireguard0

2. На Giga-III Wireguard0 имеет уровень public. 

3. Подключения с хостов в домашней сети Giga 192.168.1.0/24 по ssh к Giga-III проходят успешно. На мой взгляд это неверно, потому на Giga-III настроено 

ip ssh
security-level private

Я понимаю это так, что ssh-сервер должен принимать входящие соединения только с интерфейсов с уровнем private. Таким образом, с Wireguard0 ssh-соединения в текущей конфигурации проходить не должны. Но они проходят, и я хотел бы разобраться в причинах.

[Le ecureuil]

17 часов назад, t800 сказал:

Отправил в запрос. 

Виноват, обычно вполне внятно изъясняюсь. Попробую еще раз:

1. Есть два кинетика - Giga и Giga-III, между ними поднят Wireguard-тоннель, имя интерфейса на обоих - Wireguard0

2. На Giga-III Wireguard0 имеет уровень public. 

3. Подключения с хостов в домашней сети Giga 192.168.1.0/24 по ssh к Giga-III проходят успешно. На мой взгляд это неверно, потому на Giga-III настроено 

ip ssh
security-level private

Я понимаю это так, что ssh-сервер должен принимать входящие соединения только с интерфейсов с уровнем private. Таким образом, с Wireguard0 ssh-соединения в текущей конфигурации проходить не должны. Но они проходят, и я хотел бы разобраться в причинах.

Да, теперь из self-test я все понял.

Вы сами разрешили эти соединения, задав в ACL:

    permit ip 192.168.1.0 255.255.255.0 0.0.0.0 0.0.0.0

Дословно это означает: "разрешить из 192.168.1.0/24 на любое назначение".

Судя по всему, у вас в Wireguard0 проходят SSH запросы с источником 192.168.1.0/24 и назначением 10.0.0.2, что вполне подходит под условие и коннект разрешается.

И да, ACL имеет высший приоритет, чем security-level, потому все, что явно разрешено или запрещено в ACL будет работать именно так.

Если не нужен доступ по SSH, закройте его явно первым правилом в ACL:

 deny tcp 192.168.1.0 255.255.255.255 0.0.0.0 0.0.0.0 port eq 22

[t800]

8 минут назад, Le ecureuil сказал:

И да, ACL имеет высший приоритет

Спасибо за ответ. Но хочу пояснить почему вообще возник мой вопрос. Я предполагал, что ACL имеет наивысший приоритет только для сетевых интерфейсов. Ssh-сервер, всё-таки, это служба, пусть и имеющая настройку security-level. Поэтому, разрешив входящий трафик из Wireguard0, я ожидал, что ssh-сервер не пустит входящий коннект от public-интерфейса, раз это явно запрещено. Исходя из вашего объяснения, получается, что ssh-сервер имеет тот же подход в работе уровней безопасности, что и сетевые интерфейсы. Это всё объясняет, но было бы неплохо в какой-то форме отразить это в документации. Допускаю, что я один такой тугой, но всё-таки служба <> интерфейс, отсюда и вопросы.

[Le ecureuil]

53 минуты назад, t800 сказал:

Спасибо за ответ. Но хочу пояснить почему вообще возник мой вопрос. Я предполагал, что ACL имеет наивысший приоритет только для сетевых интерфейсов. Ssh-сервер, всё-таки, это служба, пусть и имеющая настройку security-level. Поэтому, разрешив входящий трафик из Wireguard0, я ожидал, что ssh-сервер не пустит входящий коннект от public-интерфейса, раз это явно запрещено. Исходя из вашего объяснения, получается, что ssh-сервер имеет тот же подход в работе уровней безопасности, что и сетевые интерфейсы. Это всё объясняет, но было бы неплохо в какой-то форме отразить это в документации. Допускаю, что я один такой тугой, но всё-таки служба <> интерфейс, отсюда и вопросы.

Для простоты считайте что настройка security-level - это такой автоматический фаервол для службы, который работает сразу на всех интерфейсах. Тогда будет в разы понятнее, почему службы и интерфейсы не разделяются как таковые.

[t800]

39 минут назад, Le ecureuil сказал:

службы и интерфейсы не разделяются как таковые

Да, ок. Я просил вашего коллегу это подтвердить в рамках запроса, но от явного ответа он ушел в тот момент. 🙂 Сейчас всё понятно, спасибо за разъяснения!