> А что, разве есть такие люди, которые знают как там в виндах работает файрвол на уровне ядра ОС ?Они есть, но не факт что они есть на этом форуме, ну и когда вы говорите "файрвол", вы, наверное, имеете в виду Windows Filtering Platform. Это API, которое задокументировано, и на базе которого строятся все реализации файрволов для ядра и сетевого стека венды.
https://docs.microsoft.com/en-us/windows/win32/fwp/windows-f...
Самих же файрволов несколько, они реализуют разный функционал, как минимум Windows Firewall и RRAS.
> И для тех, кто скажет "лучше" и для тех кто будет доказывать обратное - всего лишь, курятничье кудахтание.
Сравнивать по принципу "лучше", как-то странно, потому что nftables и WFP имеют разную архитектуру, в основном, потому что ядра имеют разный сетевой стек... Тёплое vs мягкое.
Если же говорить про функционал для конченого пользователя (скорее системного администратора), то всё зависит от того, что там на в хозяйстве...
Windows Firewall - это Identity Based Firewall, он генерирует правила относительно пользователей и компьютеров. В основе аутентификации и авторизации лежит протокол Kerberos, но поддерживаются и другие методы, например сертификаты X.509, или даже ретроградные методы вроде PSK+NTLM. Задача инкапсулировать траффик на незащищенные порты в IPsec, аутентифицировать и авторизовать по ESP-заголовку, проверить хэш-сумму. Шифрование по вкусу.
Nftables и тулзы построенные поверх него не могут в такой функционал, хотя бы потому что Linux - это Unix-like операционная система. В Unix-like операционных системах нет понятие типов аутентификации и нет поддержки сетевой аутентификации на уровне ядра. Linux/Unix PAM расценивает любую аутентификацию как локальную (Unix - это ОС из 70-х) и не позволяет передать дескрипторы безопасности пользовательской сессии запущенным процессам, для автоматического запроса TGS. Из-за этого поддержка Kerberos, который изначально создавался для Unix-like (иронично не так ли?), всегда где-то сбоку и требует реализации костылей в каждом приложении. Идентификация устройства-компьютера начала появляться только вместе в systemd... Дело не в файрволе, а во всем остальном. Технически подобного функционала можно добиться на Linux, но там придётся столько ручками педалить, что проще жить в списках ACL с IP, настраивая IPsec только там где-это обязательно.
Опять же, весь этот функционал - это решения задач Workstation в крупных компаниях, в то время как nftables таргетится на задачи удобства управления в рамках кластеров, управляющих контейнерами. Windows Firewall в этой ситуации вообще мимо. Разные применения же.
Если для понимания нужна цепочка проверки пакета для Windows Firewall (не для RRAS!), то вот она:
1. Сервисные правила
2. Интерфейсные ограничения и политики IPsec
3. Проброс соединений прошедших проверку по состоянию (сущность Stateful Firewall)
4. Блокировочные правила
5. Разрешающие правила (в том числе ESP-правила)
6. Параметры по-умолчанию
Здесь нету Forward/NAT и прочего, потому что они доступны в RRAS, это файрвол рабочей станции или сервера без RRAS. По сути - цепочка INPUT из iptables c рядом специфики:
1. Сервисные правила - это особые скрытые из интерфейса наборы правил (они все ограничительные), которые применяются к сервисам, фоновым процессам магазина и пакетам приложений. Их видно только в реестре.
2. Это параметры для интерфейсов, для NDIS там много всего может быть.
3. Windows Firewall - это Statefull Firewall, если это не было выключено в настройках. Например, все эти ESTABLISHED, RELATED разрешены, если не запрещены явно.
Windows Firewall разделяет локальные и доменные правила и управляет тем, какие превалируют только в случае входа в домен, здесь решения применяются вне файрвола. По поводу конфиликтующих правил используется логика "лучше блокировать, чем разрешать". Некоторые сервисы имеют свои цепочки правил, поэтому отключение служб файрвола приведет к их неработоспособности. Причем это самое туманное и то что может вогнать в ступор. Сервисная модель вменяет ограничителоьные правила для системных сервисов, магазин вменяет ограничительные правила для пакетов приложений, а пользователь/администратор не контролирует это ни через GUI ни через powershell ни через netsh, только вручную в реестре... потому что эти правила WFP не имеют отношения к правилам Windows Firewall. А есть еще NDIS-фильтры, и конечно же Winsock-фильтры, которые тоже вне Windows Firewall. Они нужны, когда нужно написать драйвер для кастомнной фильтрации (по аналогии с классическим BPF)...
Даже не знаю что рассказать, документацию почитайте... Я пишу это не потому что он чем-то лучше, а чтобы показать, что это не rocket science и что информация доступна. Если вы лично чего-то не знаете, это не значит, что этого не знает никто.
P.S. Инструменты управления у всех вендовых файрволов - оторвать и выбросить и производительность у них до 1809, мягко скажем, посредственная. Они почему так хотят eBPF себе в венду, потому что у них лет 15 точно есть в наличии продвинутый функционал по мониторингу, отладке и аналитике сетевого стека и производительности процессов, но им пользуется 3.5 руссиновича, потому что документация по нему сложна к прочтению, а тулзы настолько неудобны, что их использование напоминает оккультизм и сатанизм (я про netsh trace). То что там было до Windows 7/2008 R2... если вы не знаете, то лучше пусть так и остаётся, про это разве что фильмы ужасов снимать.
