Отключение правила

[Bolt]

было создано NDM-3067 давно, суть в том , что при создании правила (подключение по RDP) в межсетевом экране - подключение работает, но если это правило выключить - связь не обрывается. Этот баг действует и на любые другие правила, как пример - подключение к по 80 порту- работает вне зависимости от того запрещено или нет, до тех пор пока просто не перегрузишь устройство 

это же дыра в безопасности

[Le ecureuil]

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

Понятно. А если так: вместо DROP используем REJECT с отправкой TCP RST на сервер или и на клиент и на сервер для надежности. (REJECT --reject-with tcp-reset). Удаляем conntrack запись.  Сокет закроется по правилам TCP. Соединение разовётся. Не даем пересоздавать запись CONNTRACK как NEW из-за запрещающего правила фервола.

Или есть какие-то нюансы?

Конечно есть.

1. tcp rst - это, по хорошему, вмешательство в трафик. Хотя вроде администратор сам этого хочет.

2. А сколько должна жить эта блокирующая запись в нетфильтре?

3. На нее могут попадать и легитимные соединения от, скажем, другого проброса - что не очень хорошо.

[avn]

3 часа назад, Le ecureuil сказал:

Конечно есть.

1. tcp rst - это, по хорошему, вмешательство в трафик. Хотя вроде администратор сам этого хочет.

2. А сколько должна жить эта блокирующая запись в нетфильтре?

3. На нее могут попадать и легитимные соединения от, скажем, другого проброса - что не очень хорошо.

Так, стоп, тут не хорошо, а то что мы натыкаемся в правилах на не легитимную цепочку по 443 порту, то это нормально?

== Chain INPUT ==
src: 0.0.0.0/0, dst: 0.0.0.0/0, in: "*", out: "*", proto: "TCP"; "tcp" match, mask: , cmp: , dport: 443; jump to "_NDM_HTTP_INPUT_TLS_"

 

[Bolt]

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

2. А сколько должна жить эта блокирующая запись в нетфильтре?

эту блокирующую запись можно отключить/удалить?

если да, то после отключения правил {перевода в "запрещено") удалит и жту запись.

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

3. На нее могут попадать и легитимные соединения от, скажем, другого проброса - что не очень хорошо.

в моем случае интерес представляет соединение rdp, т.е. есть только один источник и только один приемник. поэтому других легитимных нет.

[Bolt]

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

1. tcp rst - это, по хорошему, вмешательство в трафик. Хотя вроде администратор сам этого хочет.

со стороны админа - однозначно вмешательство и есть цель.

[Bolt]

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

с отправкой TCP RST на сервер или и на клиент и на сервер для надежности.

а вот отправлять на сервер или клиенту это не надо, только управление роутером

[keenet07]

22 часа назад, Le ecureuil сказал:

Конечно есть.

1. tcp rst - это, по хорошему, вмешательство в трафик. Хотя вроде администратор сам этого хочет.

2. А сколько должна жить эта блокирующая запись в нетфильтре?

3. На нее могут попадать и легитимные соединения от, скажем, другого проброса - что не очень хорошо.

1. Но в рамках стандарта. И исключительно точечно.

2. В теории пока есть исходное общее запрещающее правило фаервола. Как правило будет деактивировано, можно и эту блокировку удалять. Но опять же наверное есть нюансы.

3. Тут да. Всякое может случиться. Эту блокировку можно и не ставить отдельно. По идее TCP RST если сработает и так уже должен будет прервать соединение. Серверная сторона же не должна после этого что-то слать клиенту наружу. А  новые входящие и так будут заблокированы фаерволом. Или не так?

Изменено Вторник в 06:38 пользователем keenet07

[Le ecureuil]

Так нет никакого запрета, есть отключенный проброс, но зеркального правила "на выход" - явно нет.

[Denis P]

В 20.04.2025 в 16:13, Le ecureuil сказал:

Эта возможность у вас уже  есть. Создаете access-list, вешаете его на output ISP (в вебе только на input), создаете запрещающее правило, зеркальное пробросу, и дальше выключаете.

разве если повесить его через веб на "Home" не будет того же эффекта? как раз output из-за security level private