Как стать автором
Обновить

Гайд по межсетевому экранированию (nftables)

Время на прочтение 32 мин
Количество просмотров 46K
Всего голосов 30: ↑29 и ↓1 +28
Комментарии 15

Комментарии 15

Спасибо, это было технично.

Make habr tech again :)

После того, как потратил неделю на изучение iproute2, изучать "новый,классный,прогрессивный" интерфейс как то вообще сложно. Чем им старый не угодил!??!

Все новое это всегда боль. Но если сравнивать с iptables, то nftables все же продуманней. Всех примеров приводить не буду, остановлюсь лишь на классике:

Допустим вы работаете по SSH и отлаживаете какой-нибудь сетевой сервис.

-- А не отключить ли мне файервол, iptables -F...

Хм что с сессией? Почему перестал работать SSH?

После поездки на работу выяснится, что там были POLICY DROP. Так вот с nftables такого не будет. nft flush ruleset - полностью уберет всю фильтрацию. Тут правда тоже могут быть нюансы, если вы с его помощью маршрутизировали трафик, но это как говорится совсем другая история.

Еще следует вспомнить про списки. ipset + iptables - жалкая пародия на то, что nftables делать со списками.

Так что учить нужно, не разочаруетесь.

Что будет более эффективно (по расходу процессора при работе) при фильтрации (или по простому, бане) сотен и тысяч подсеток -- iptables+ipset или nftables?

Надо проводить эксперименты, так не скажу. Говорят, что nftables специально точили под производительность.

После поездки на работу выяснится, что там были POLICY DROP.

Ну ведь правка файрволла по ssh -- к долгой поездке (это древняя админская мудрость).

И что-то мне кажется, что таки policy DROP секурнее чем вообще ничего.

Ну ведь правка файрволла по ssh -- к долгой поездке (это древняя админская мудрость).

Сон про удалённую правку файрвола - к дороге дальней, да.

Потому надо предусматривать либо резервный способ доступа, либо автоматический откат настройки (или перевод в состояние "разрешено всё отовсюду") через определённое время.

policy DROP конечно секурно и правильно, но после сброса правил теряется удалённый доступ... С непривычки можно на это напороться.

Можно держать скрипт, который сначала сбрасывает правила а потом ставит новые. При его запуске вся система будет без правил очень короткое время, после чего ssh снова разрешится, а tcp-коннекты этого вовсе (или почти) не заметят.

Ну или по cron'у сбрасывать, например. Способов на самом деле много, главное, не забыть ими воспользоваться, а не как всегда...

Статья понравилась.

Всем ++

Хорошая статья, но вот к примеру в разделе "Практическая работа: реализация межсетевого экранирования сервера по схеме усиленной защищенности" ИМХО (если что это моё мнение и я его не в коем случае не навязываю) было бы удобней и наглядней если было бы не сразу вот вам конфиг его надо написать, а были перечислены команды а в конце в спойлере был сам конфиг.

Описание того что делается дается перед конфигом. Конкретные команды и синтаксис разбираться в других статьях.

Статья супер.и очень злободневно ) буквально "вчера" врывался в nft. Вот чего не хватило в вэтоашей статье - пошаговых команд через nft add, тк многие мануала в инете набрали друг у друга и в результате не везде цепочка/таблица совпадают, команды не работают.

Shell скрипты и соответственно nft add лучше не использовать, а вместо них использовать конфиг файлы, как описано в статье.

Дело в том, что применение nft конфиг файлов имеет свойство атомарности, то есть он применяется целиком за раз, у shell скриптов такого нет, и если в скрипте вы, например, вначале отключаете ssh, а потом разрешаете его, то имеете все шансы полностью потерять ssh доступ (если конечно работаете через него).

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации