Russian Users MikroTik | Форум пользователей MikroTik

всем привет. помогите найти ответы на два вопроса
1. в какой практической ситуации может понадобиться правило фаервола вида
ip firewall filter add chain forward action=accept ....
имею ввиду зачем вообще нужна цепочка forward с действием accept? понятно, если есть общее правило forward any drop, но нужно явно указывать accept соединения. но если этого правила нет. для публикации внутренних ресурсов достаточно dst-nat.
почти во всех статьях базовой настройки фаервола есть такие пункты
ip firewall filter add chain forward connection-state=established action=accept comment="Allow established connections"
ip firewall filter add chain forward connection-state=related action=accept comment="Allow related connections"
если у меня не будет правила для related пакетов, то мой опубликованный FTP не сможет работать? или без правила established запущенный у меня скайп будет постоянно обрывать звонок?

2. что такое connection-state=new, в каких ситуациях этот тип может понадобиться?

1. Принцип построения правил фаервола в RouterOs - Правила срабатывают от первого к последнему строго по порядку.
-------------Из чего делаем вывод, что сначала определяем, что нам нужно пропускать, а затем запрещаем всё остальное.
-------------Фаервол в RouterOs по умолчанию имеет три основных цепочки: input - для пакетов, входящих в роутер и предназначенных для него, output - для пакетов, источником которых является роутер и, наконец forward - для пакетов проходящих через роутер, то есть тех, коими обмениваются ваша локальная сети и внешний мир.
По поводу NEW, ESTABLISHED, RELATED и INVALID читайте http://www.opennet.ru/docs/RUS/iptables/#USERLANDSTATES
2. В ссылке выше есть ответ на вопрос, что это такое. А вот зачем это Вам, Вы должны ответить сами, нам сие неизвестно.

connection-state=new штука удобная ))

Например есть у вас сеть А и Б и вам надо сделать так что бы из сети А в сеть Б доступ был, а из Б в А не было, вот тут вам и понадобится connection-state=new

vqd писал(а): vqd

спасибо.

podarok66 писал(а):

я понимаю, что это за пакеты, теорию уже читал. я не могу понять зачем они нужны. задам вопрос по другому - что будет, какие возможны последствия, если я на фаерволе не создам правила вида
add chain=forward connection-state=invalid action=drop comment="drop invalid connections"
add chain=forward connection-state=established action=accept comment="allow already established connections"
add chain=forward connection-state=related action=accept comment="allow related connections"

Если последнее правило дропа всех остальных пакетов у Вас присутствует, то часть сетевых приложений будет выдавать ошибки в работе. Вероятнее всего FTP, телефония, торренты, игры точно выдадут кучу ошибок. Там ведь создается множество родственных соединений и поддерживаются установленные. Это и есть пресловутые related и established. Пакеты, которые роутер не может идентифицировать, конечно лучше отсекать, зачем они нужны. Вот им и присвоим invalid.
Если же правила дропа в конце нет, то и смысла в остальных правилах нет никакого.
Мы ведь помним, что по умолчанию в фаерволе все разрешено?
Вообще, мне кажется, не очень корректно говорить о нескольких правилах из общего объема, не зная как выглядит остальной массив правил и каков порядок правил.

plni писал(а):

vqd писал(а): vqd

спасибо.

podarok66 писал(а):

я понимаю, что это за пакеты, теорию уже читал. я не могу понять зачем они нужны. задам вопрос по другому - что будет, какие возможны последствия, если я на фаерволе не создам правила вида
add chain=forward connection-state=invalid action=drop comment="drop invalid connections"
add chain=forward connection-state=established action=accept comment="allow already established connections"
add chain=forward connection-state=related action=accept comment="allow related connections"

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

друзья, спасибо за ваши комментарии.
получается, что эти правила являются "признаком хорошего тона" при настройке? я не беру сейчас кукую-то конкретную задачу, мне хочется понять - вот если у меня новая железка микротик, нужно задавать эти правила или это лишнее?
я вижу так:
при настройке обычного НАТ (ЛАН->ВАН) такие правила лишние, так как резать пакеты из локалки в инет смысла не вижу (про ограничение доступа по протоколам, адресам назначения, УРЛ речь сейчас не идет).
при публикации "сложных" сервисов FTP, SIP, AAJAX и др (ВАН->ЛАН) правила нужны, т.к. обеспечивают передачу установленных и связанных пакетов.
поправьте, пожалуйста, если ошибаюсь.

plni писал(а):друзья, спасибо за ваши комментарии.
получается, что эти правила являются "признаком хорошего тона" при настройке? я не беру сейчас кукую-то конкретную задачу, мне хочется понять - вот если у меня новая железка микротик, нужно задавать эти правила или это лишнее?
я вижу так:
при настройке обычного НАТ (ЛАН->ВАН) такие правила лишние, так как резать пакеты из локалки в инет смысла не вижу (про ограничение доступа по протоколам, адресам назначения, УРЛ речь сейчас не идет).
при публикации "сложных" сервисов FTP, SIP, AAJAX и др (ВАН->ЛАН) правила нужны, т.к. обеспечивают передачу установленных и связанных пакетов.
поправьте, пожалуйста, если ошибаюсь.

У кого-то "признак хорошего тона" :) ,у кого-то оптимизация работы оборудования, у кого-то необходимость (если есть другие запрещающие правила).
Я бы рекомендовал их задать.

Друзья, всем дня!

Подскажите пожалуйста является такая конфигурация firewall достаточной для домашнего роутера, если задача разрешить снаружи icmp, established, related трафик и дропнуть остальное?

add chain=input comment=" test Allow ICMP" in-interface=wan protocol=icmp
add chain=input comment=" test Allow established & related" connection-state=\
established,related
add action=fasttrack-connection chain=forward comment="test fasttrack" \
connection-state=established,related
add action=drop chain=input comment=" test Drop all from WAN" in-interface=\
!bridge log-prefix="test drop all from WAN"

Будет ли такая конфигурация firewall полноценной с точки зрения безопасности? Отсечет ли весь не санкционированный трафик? Нужно ли разносить отдельными правилами drop invalid и drop new для снижения нагрузки на проц? Одним словом - все кошерно?) И если нет, то почему?

Заранее спасибо

Осталось только понять, что такое "несанкционированный трафик"?

Общий принцип работы фаерволла: добавлять только те правила, которые действительно нужно и которые вы четко понимаете, как они работают. Все остальное, что вы нарыли в интернете добавлять не стоит.

Ку думаете, сколько пакетов Invalid может прийти на ваш порт??? За последние 50 дней непрерывной работы RB2011 в это правило у меня упало 2 (два) пакета. Они сильно нагрузили проц?