LINUX.ORG.RU
ФорумAdmin

Nftables. Варианты реализации

 , ,


1

2

Пытаюсь углубиться в nft. Практически везде учат так. Запрещаем всё, а потом разрешаем что необходимо

table ip filter {
    chain input {
        type filter hook input priority filter; policy drop;
            правило 1 accept
            правило 2 accept
            ...
	}

Наткнулся на мануал, где чел сперва описал что разрешить, а в самом низу уже запретил остальное

table ip filter {
    chain input {
        type filter hook input priority filter; policy accept;
	    правило 1 accept
	    правило 2 accept
            counter drop
        }

Оба варианта рабочие, но сто-пудово сетевые оракулы аргументируя раскритикуют какой-то из. Хотелось бы узнать мнение

★★
Ответ на: комментарий от anonymous

И не забыть написать в самом низу общий drop для второго варианта.

counter drop стоит же. Он всё запрещает

А в первом не забыть политику drop выставить

policy drop в хуке инпута стоит же

Shprot ★★
() автор топика
Ответ на: комментарий от Shprot

Тут ты написал. А когда будешь руками писать правила или копировать откуда-то шаблон - не забудь указать политику или написать общее блокирующее правило в конце.

Это всё человеческий фактор.

Если забудешь - ничего работать так, как ты думаешь должно не будет.

В первом варианте сразу всё запрещено по умолчанию и ты только что-то разрешаешь.

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

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

Примеры написания что ты привёл реализуют один и тот же принцип - блокировать всё, что явно не разрешено. В этом они равнозначны.

anonymous
()
Ответ на: комментарий от anonymous

Примеры написания что ты привёл реализуют один и тот же принцип

Это понятно и видимо я неправильно задал вопрос.

Смоделируем ситуацию:

WAN_INT = eth0
WAN = 82.162.58.22/30 - static
LAN = 192.168.1.0/24

Для того, чтоб выпустить юзверей во вне мы применим технологию, позволяющая перенаправлять трафик между локальной и глобальной сетями не будем умничить и применим NAT, но…

его можно применить двумя способами:

  1. nft add rule ip nat postrouting oif eth0 masquerade
  2. nft add rule ip nat postrouting ip saddr 192.168.1.0/24 oif eth0 snat to 82.162.58.22

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

Возвращаясь к моему вопросу о политиках файервола. Я сейчас как душнила спрашиваю, какой вариант политик предпочтительней…?

Shprot ★★
() автор топика
Ответ на: комментарий от Shprot

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

А в случае явного snat ты явно указываешь - подменять адрес источника на вот этот.

anonymous
()
Ответ на: комментарий от anonymous

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

А в случае явного snat ты явно указываешь - подменять адрес источника на вот этот.

А-а-а-а….!!! ЧеловеГ, давай завязывай отвечать на вопросы не по теме. Я про трансляцию пример просто привёл.

Я спрашивал про политики файервола…=)

Shprot ★★
() автор топика
Ответ на: комментарий от anonymous

Если ты не понимаешь написанного тут: Nftables. Варианты реализации (комментарий)

Я вообще-то сюда за ответом пришёл. Если бы я это понимал, то не задавал вопросов

Shprot ★★
() автор топика
Ответ на: комментарий от Shprot

Я вообще-то сюда за ответом пришёл.

И тебе он дан, но для тебя либо слишком много текста и ты не понимаешь написанного, либо не можешь понять.

Прочти текст в комментарии, ссылку на который далее я дал, задай уточняющие вопросы.

Если ты этого не можешь - значит тебе это не нужно.

Раз не стараешься разобраться.

anonymous
()
Ответ на: комментарий от anonymous

задай уточняющие вопросы

Опираясь на смоделированный пример трансляции, в котором src-nat предпочтительней, так как несёт меньше накладных расходов, есть ли существенная разница в политиках файра (и если есть, то какая) запретить всё, а потом разрешить, что надо, между обозначить что разрешено, а потом запретить всё?

Shprot ★★
() автор топика
Ответ на: комментарий от Shprot

В первом варианте сразу всё запрещено по умолчанию и ты только что-то разрешаешь.

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

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

Копирую ответ, здесь пояснение отличий в применении политики accept и drop, т.е. в возможностях построения правил.

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

anonymous
()