Jump to content
Калькуляторы

секьюрность в ip firewall filter

В мануалах на просторе интернета рекомендуют для повышения секьюрности добавить в начало /ip firewall filter следующие правила:

 

# Разрешаем входящий трафик от уже установленных подключений и связанных
add chain=input action=accept connection-state=established,related

 

# Разрешаем транзитные пакеты от уже установленных соединений
add chain=forward action=accept connection-state=established,related   

 

И вот тут задался вопросом:

INPUT — позволяет модифицировать пакет, предназначенный самому хосту.
FORWARD  — цепочка, позволяющая модифицировать транзитные пакеты.
PREROUTING — позволяет модифицировать пакет до принятия решения о маршрутизации.

OUTPUT — позволяет модифицировать пакеты, исходящие от самого хоста.
POSTROUTING — дает возможность модифицировать все исходящие пакеты, как сгенерированные самим хостом, так и транзитные.

 

 

Так мож правильнее эти два правила объединить в одно правило с chain=prerouting ???

add chain=prerouting action=accept connection-state=established,related 

 

cbfruui7ydb8lqm19myzozfotbo.png

 

 

И еще есть вопрос по поводу: connection-state=established,related и connection-state=new. Разве это не взаимоисключающие правила?

Т.е. если первым правилом стоит connection-state=established,related то connection-state=new уже по смыслу не нужен!?

Пример:

1-е правило: add chain=prerouting action=accept connection-state=established,related 

2-е правило: add chain=input action=drop protocol=tcp connection-state=new in-interface=WAN dst-port=23 log=no log-prefix=""

               

Или всё же во втором правиле нужен  connection-state=new ???

 

Share this post


Link to post
Share on other sites
5 часов назад, RN3DCX сказал:

для повышения секьюрности добавить в начало

Никакого отношения к секьюрности это не имеет.

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

Share this post


Link to post
Share on other sites
7 часов назад, RN3DCX сказал:

# Разрешаем транзитные пакеты от уже установленных соединений
add chain=forward action=accept connection-state=established,related   

Если это роутер транзита, то там пусто в FORWARD и это правило смысла не имеет.

Да и вообще не нужно трекать транзит.

Share this post


Link to post
Share on other sites
В 24.04.2020 в 08:51, alibek сказал:

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

КЭП - подробности будут?

Share this post


Link to post
Share on other sites

Правила выполняются сверху вниз.

Верхние правила выполняются первыми.

Поэтому в начало списка часто посещают те правила, которые срабатывают чаще всего.

Share this post


Link to post
Share on other sites

@alibek , это я думаю всем понятно.

вопрос был про:

# Разрешаем входящий трафик от уже установленных подключений и связанных
add chain=input action=accept connection-state=established,related

# Разрешаем транзитные пакеты от уже установленных соединений
add chain=forward action=accept connection-state=established,related   

мож правильнее эти два правила объединить в одно правило с chain=prerouting ???

add chain=prerouting action=accept connection-state=established,related 

Share this post


Link to post
Share on other sites
В 24.04.2020 в 03:49, RN3DCX сказал:

Так мож правильнее эти два правила объединить в одно правило с chain=prerouting ?

Нет. Смотрите официальный packet flow, пакет forward может проходить неоднократно.

 

В 24.04.2020 в 03:49, RN3DCX сказал:

connection-state=established,related и connection-state=new. Разве это не взаимоисключающие правила?

Т.е. если первым правилом стоит connection-state=established,related то connection-state=new уже по смыслу не нужен!?

Пример:

1-е правило: add chain=prerouting action=accept connection-state=established,related 

2-е правило: add chain=input action=drop protocol=tcp connection-state=new in-interface=WAN dst-port=23 log=no log-prefix=""

Смысл второго правила вообще не ясен. Connection-state=new нужен, если вы хотите новые соединения дополнительно проверять, типа port knocking и т.п., или обрабатывать в отдельной chain. В остальных случаях этот признак указывать не надо - то, что уже есть, роутер пропустит первым правилом, новое пойдет по цепочке правил вниз и так.

Share this post


Link to post
Share on other sites
On 4/25/2020 at 6:45 PM, Jora_Cornev said:

мож правильнее эти два правила объединить в одно правило с chain=prerouting ???

add chain=prerouting action=accept connection-state=established,related 

 

q.png

Share this post


Link to post
Share on other sites

@jffulcrum, отдельное спасибо за подробный ответ!

 

 

 @McSea , а вот мысль по поводу add chain=prerouting была навеяна постом сааба:

В 24.03.2020 в 21:30, Saab95 сказал:

достаточно вставить вверху манглов:

 


/ip firewall mangle
add action=accept chain=prerouting connection-state=established

 

Сейчас сам проверил и действительно нету там prerouting'a

image.png.b172fe8f0a561e23fa2d36ec00c819a0.png

 

Share this post


Link to post
Share on other sites
/ip firewall mangle

он есть в другом разделе.

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this