Jump to content
  • 0

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


t800
 Share

Question

Добрый день

Столкнулся вот с такой ситуацией. Есть два кинетика. Локальный - Гига-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-сервера, он просто разрешает входящие соединения извне! Тем не менее, такой ответ предоставлен официально, я на него дал свои комментарии, но хотел бы услышать мнение сообщества. Может я чего-то не понимаю и исходно неправ в ожиданиях?

Link to comment
Share on other sites

12 answers to this question

Recommended Posts

  • 0
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, у них приоритет выше.

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

  • 0
Posted (edited)
17 часов назад, r13 сказал:

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

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

 

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

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

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

Edited by t800
Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

  • 0
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-соединения в текущей конфигурации проходить не должны. Но они проходят, и я хотел бы разобраться в причинах.

Link to comment
Share on other sites

  • 0
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

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...