OpenBSD 7.7 как прочная основа для межсетевого экрана: pf.conf и sysctl.conf, которые прикрывают твою спину

OpenBSD 7.7 как прочная основа для межсетевого экрана: pf.conf и sysctl.conf, которые прикрывают твою спину

OpenBSD уже много лет известен своим бескомпромиссным подходом к безопасности: здравые настройки по умолчанию, чистый код и «secure by default» не как лозунг, а как обязательство. Если тебе нужен межсетевой экран, который в повседневной работе ведёт себя надёжно и предсказуемо, OpenBSD — отличный фундамент. При этом одних сильных дефолтов мало: несколько точечных регулировок заметно повышают уровень безопасности и предсказуемость — не превращая систему в хрупкий лабораторный эксперимент.
В этой статье мы предлагаем практичную базовую линию, которая уверенно защищает небольшие сети, домашние лаборатории и многие инфраструктуры малых/средних компаний, оставаясь при этом читаемой и удобной в сопровождении.

Вместо бесконечных чек‑листов и произвольных «тюнингов» ты получишь обоснованные решения с понятной мотивацией. Мы объясняем, почему включена та или иная опция, какие риски она закрывает и о каких побочных эффектах стоит помнить. Цель — не накрыть каждый теоретический сценарий атаки, а дать надёжную отправную точку: стройные правила, минимум исключений, однозначное поведение.

Мы проводим чёткую линию: явно разрешено — иначе запрещено. Снаружи внутрь пропускается только то, что действительно нужно самому роутеру; изнутри наружу — лишь то, что ты сознательно разрешаешь. DNS остаётся видимым и управляемым. DoH, DoT, DoQ и QUIC не получают тихих обходных путей, чтобы не возникало «невидимых» каналов. Состояния соединений привязываются к интерфейсам, чтобы соединения оставались там, где возникли. Это делает систему предсказуемой, а разбор проблем — терпимым. И поскольку прозрачность ценнее десятка хитрых трюков, все критичные пути снабжены метками: в эксплуатации сразу видно, что прошло, что заблокировано и где нужно подкрутить.

Чтобы оставаться предметными, мы даём два профиля pf на выбор: компактный вариант только роутер для классической схемы LAN‑в‑интернет и вариант роутер + DMZ, если нужно изолировать сервисы. Мы жёстко принуждаем клиентский DNS к 1.1.1.1 (опционально 1.0.0.1 как резерв). Это не педантизм, а осознанное архитектурное решение: ты возвращаешь себе видимость и контроль. Если приложению требуется что‑то иное, это заметно, и ты сознательно решаешь, давать ли исключение и где.

Файл sysctl.conf дополняет эту позицию на уровне ядра. OpenBSD уже приносит много полезного, но несколько переключателей дают измеримый выигрыш по надёжности: ужесточённая конфигурация malloc, из‑за которой классические ошибки памяти падают раньше и громче; отключение SMT/Hyper‑Threading, когда риски сайд‑чэннелов не приносят пользы; W^X, которое лучше завершит процесс, чем позволит ему работать в опасной «серой зоне»; отключение редиректов и ненужных туннельных протоколов; современные TCP‑опции и умеренные rate‑limit’ы, приглушающие сетевой «шум», не ломая легитимные функции. Это не эффектные «твики», а последовательная гигиена: меньше поверхность атаки, меньше сюрпризов, стабильнее поведение под нагрузкой.

Вне фокуса находятся высоко‑таргетированные атаки и полноценные IDS/IPS‑развёртывания. Если тебе нужны многоуровневый мониторинг, глубокая инспекция протоколов или фиды threat‑intel, эта конфигурация не мешает; это фундамент, на который можно методично нарастить такие блоки позже. Мы также сознательно не покрываем сложные multi‑WAN‑политики, обширные схемы проброса портов и экзотические overlay‑сети. Всё это возможно, но не без потери ясности базовой линии.

Стремление к читабельности означает и выбор механики вместо магии. NAT — статический там, где это важно для real‑time‑протоколов, и динамический там, где всё равно. QUIC отключён, чтобы DNS не прятался внутри TLS‑потоков. IPv6 изначально блокируется, чтобы не получить «наполовину открытый IPv6», когда клиенты предпочитают v6, а экран его не контролирует; дальше по тексту есть аккуратный рецепт, как включить IPv6 правильно, если он нужен. И везде, где это помогает, мы помечаем крайние случаи метками — не чтобы раскрасить логи, а чтобы получить ответы: кто пытался говорить DoT? Какие хосты бьются в anti‑rebind? Что триггерит блокировки исходящего трафика?

Для кого это? Для тебя, если ты относишься к администрированию как к ремеслу и готов вложить час в чистую базу, вместо трёх недель охоты за странными побочными эффектами. Для тебя, если ты хочешь понимать свою сеть, а не удивляться дефолтным разрешениям. И для тебя, если ты «между стульями»: мал для SOC/blue‑team‑аппарата, но слишком требователен для «домашнего роутера с полки». Эта базовая линия — не фокус, а здравый стандарт: достаточно мала, чтобы её держать под контролем, и достаточно крепка, чтобы держаться годами.

Модель угроз: от чего мы защищаемся — и от чего нет

Эта базовая линия рассчитана на окружения без выделенной «синей» команды, но с потребностью в надёжных стандартах. Она защищает от привычного шума на периметре: массовых сканов, оппортунистических эксплойтов, злоупотреблений протоколами («DNS поверх чего угодно»), неверных настроек и излишне щедрых политик исходящего трафика (egress), которые и делают возможной утечку данных. Она изолирует необязательные серверы в DMZ, предотвращая боковое перемещение в LAN. Не в фокусе — высоко‑нацеленные атаки и полноценные IDS/IPS‑стеки: их можно добавить поверх этого фундамента позже.

Принципы дизайна: малая поверхность атаки, ясные зоны ответственности

Конфигурация следует нескольким правилам, полезным и для будущих доработок:

Fail‑closed. Если что‑то не разрешено явно — оно запрещено, и на вход, и на выход. В тестах ты быстро поймёшь, что приложению на самом деле нужно, и сохранишь контроль.

Детерминированные состояния. if-bound гарантирует, что соединение привязано к интерфейсу, где оно родилось. На одно‑WAN‑роутерах это завершает охоту за «плавающими» состояниями и упрощает отладку.

Минимализм на исходе. Изнутри наружу проходит только необходимое: классический веб, почтовая отправка (submission), определённые UDP‑диапазоны для VoIP/WebRTC — и DNS только туда, куда решишь ты.

Прозрачность вместо угадываний. Блокируются QUIC и DoH/DoT/DoQ. Да, некоторым приложениям неудобно. Взамен — ясность: DNS есть DNS, TLS есть TLS. «Теневой» DNS сразу заметен.

Крепкие дефолты. Scrubbing, ограничение MSS, случайные IP‑ID, фильтры bogon‑сетей, anti‑spoofing, гигиена TCP‑флагов, разумные лимиты для ICMP и RST. По отдельности — ничего особенного; вместе — крепкая гигиена.

IPv6 — по осознанному выбору. IPv6 выключен по умолчанию. Если нужен — дальше есть аккуратный план включения. Мы целенаправленно избегаем «наполовину открытого IPv6».

sysctl.conf — рычаги безопасности ядра, которые действительно важны

OpenBSD даёт отличные дефолты, но несколько настроек ощутимо повышают безопасность и предсказуемость. Главное — без бесконечных списков, с чёткими аргументами.

Ужесточение памяти (vm.malloc_conf=CFGJRS). Guard‑страницы, «junk»‑шаблоны, red‑zone и канарейки осложняют эксплуатацию классических багов памяти и заставляют процессы падать «громко», а не тихо портиться. Небольшой оверхед окупается почти в любом роутерном сценарии.

CPU/железо: SMT выкл, aperture закрыт. hw.smt=0 уменьшает риски сайд‑чэннелов (Hyper‑Threading); на роутерах влияние обычно минимально. machdep.allowaperture=0 закрывает доступы вида /dev/mem — идеально для headless‑машин. Нужен X11/KMS — ты знаешь, что делаешь; иначе оставь закрытым.

Маршрутизация и протоколы: IPv4 включён, IPv6 намеренно выключен. net.inet.ip.forwarding=1 превращает узел в IPv4‑роутер. net.inet6.ip6.forwarding=0 предотвращает «случайную» маршрутизацию IPv6. Также отключаем лишние туннели (IP‑in‑IP, GRE, ESP/AH, EtherIP). Меньше крипто/инкапсуляции = меньше поверхность атаки и сюрпризов.

Обезвреживание наследованных ловушек. Directed‑broadcast выкл, редиректы игнорируются (IPv4 и IPv6). ICMP‑редиректы — классическая «мина»; если хочешь менять пути — делай это явно в маршрутизации или PF, а не боковыми каналами.

ICMP с мерой. Никаких эхо‑ответов на broadcast, никаких timestamp/netmask; пакеты ошибок ограничены по скорости. Это гасит DDoS‑шум, не ломая легитимное. ICMP — не враг, но ему нужны ограничители.

Ужесточение UDP/TCP без «магии». Обязательные checksum’ы UDP; внятные сокет‑буферы, чтобы избежать некрасивых потерь. В TCP оставляем включёнными современные функции (window scaling, timestamps, SACK) ради стабильности. ECN — включён; редко мешает и помогает под нагрузкой. Лимиты SYN‑кэша/«корзин» и rate‑limit RST сглаживают типичные волны сканирования.

Очереди, BPF и W^X. Увеличенная if‑queue снижает потери при всплесках. Большие BPF‑буферы — подарок «будущему себе» для отладки. kern.wxabort=1 жёстко проводит W^X: код либо записываемый, либо исполняемый. Нарушение — немедленное завершение (fail‑closed). Шифрование свапа остаётся включённым, чтобы чувствительные остатки не попадали на диск в открытом виде.

Этот набор sysctl намеренно скромен. Он смещает кривую от «обычно работает» к «ведёт себя стабильно под стрессом». Загружай чисто (sysctl -f), проверь пару счётчиков (sysctl -n net.inet6.icmp6.errppslimit, netstat -m, pfctl -s memory) и помни: если трогаешь бюджеты mbuf/cluster, возможно, придётся подстроить PF‑лимиты вроде set limit frags.

pf.conf: правила, которые можно объяснить

pf даёт бесконечные возможности. Наша базовая линия берёт ровно столько, сколько нужно для прочных стандартов — ни больше, ни меньше.

Макросы, таблицы, метки — половина успеха в структуре. Сначала явно определяем интерфейсы и сети: WAN, LAN и — в DMZ‑варианте — DMZ. Добавляем таблицы для bogon‑сетей, abusers, scanners и watch‑лист подозрительных DoH‑узлов. Это не декор: с persist таблицы переживают перезагрузку правил, а через overload шумные источники попадают в них автоматически. Метки на правилах дают отличную операционную видимость без тяжёлого pcap: pfctl -vvsr или systat pf покажут, где пульс.

Глобальные опции — предсказуемое поведение. set block-policy drop и оптимизация «aggressive» — разумные консервативные дефолты. set state-policy if-bound привязывает соединения к входному интерфейсу. Определяем лимиты для состояний, фрагментов и src‑nodes, включаем адаптивные таймауты и syncookies — они выручают, когда волна высокая. loginterface даёт WAN‑статистику; set skip on lo0 предотвращает «выстрел в ногу».
В pf IPv6 по умолчанию заблокирован, согласован с sysctl, что предотвращает «наполовину открытый IPv6». Если нужен — включай осознанно и явно.

ICMP на вход: открыто ровно настолько, чтобы быть «здоровым». На WAN разрешаем echo и «unreachable» — со state и rate‑limit. Это помогает диагностике (как иначе стабильно ловить MTU/путь?), оберегая от ping‑флудов. Остальное — особенно redirects — выключено.

Scrubbing: меньше фрагментации — меньше боли. Очищаем в обе стороны: случайные IP‑ID, консервативный min‑TTL, MSS ограничено 1440 (здоровое практическое значение), TCP‑реассамблирование. Это не даёт сомнительным фрагментам забивать состояния и снижает PMTU‑головную боль. MSS через sysctl тогда почти не нужен.

NAT: статический там, где важен real‑time; динамический — где без разницы. UDP получает статические порты — золото для VoIP/WebRTC, игр и прочих real‑time‑протоколов. Остальное — через высокий ephemeral‑диапазон: легче атрибутировать исходящее в дампах и меньше коллизий. NAT применяем ко всему, кроме явно определённых управляющих целей — никаких сюрпризов.

Anti‑spoofing, bogon‑сети, нулевые порты. antispoof наблюдает за всеми важными интерфейсами. То, что приходит на WAN со сломанным источником, рано отбрасывается. Bogon‑сетям — блок и на вход, и на выход; трафик, например, из 10/8 или 127/8 в интернет обычно указывает на иные проблемы. Чистим также порт 0 и невероятные TCP‑флаги — не ракетостроение, но избавляет от боли со «сканерами‑креативщиками».

Запрет по умолчанию: большой веник. После гигиены — жёсткий срез: block all. Дальше — только осознанные исключения.

Вход с WAN: только то, что нужно самому роутеру. Разрешаем входящий DHCP, если этого требует провайдерский аплинк. И всё. Публичная DMZ, доступная из интернета, не цель этой базовой линии; для неё ты осознанно настроишь пробросы портов — и очень умеренно.

QUIC: HTTP/3 остаётся снаружи. Блокируем UDP 80/443 на WAN. Это «перекрывает кислород» QUIC. Почему строго? Потому что QUIC — удобный туннель, в том числе для DoH‑вариаций и других «всё в одном потоке». Если позже действительно нужен HTTP/3 к конкретным целям (и ты знаешь зачем), добавляй хирургические исключения. Базовая линия ставит прозрачность выше скорости.

Видимость DoH/DoT/DoQ — с чёткими границами. DoT (853/TCP) и DoQ (784/UDP) блокируются на исходе и логируются на входе. В LAN/DMZ мы помечаем TLS‑соединения к известным DoH‑хостам — не меняя политику, пока ты не выберешь строгий вариант. Смысл: видеть попытки скрытого DNS.

Админ‑доступ к экрану: узко и с ограничением частоты. SSH из LAN на экран разрешён — со state, гигиеной флагов и мягким rate‑limit. Пути к upstream‑менеджменту (например, GUI модема/роутера) получают точечные pass‑правила; лимиты по скорости сглаживают «спреи» и ошибки кликов. Метки держат эти пути на виду.

DNS‑политика без локального резолвера: не надеяться, а принуждать. Ключевой момент: клиенты в LAN (и в DMZ, если есть) могут использовать только 1.1.1.1 и опционально 1.0.0.1 на порту 53/TCP+UDP. Всё прочее на 53 — блок и лог. Это не «nice to have», а основа видимости. Попытки иных резолверов — или DoH/DoT/DoQ — тут же видны (и отдельно блокируются). Хочешь другой внешний резолвер — просто подставь его; механика та же.

DMZ: никаких боковых дверей и срезов. В DMZ‑варианте нет внутридемилитаризованной связи, нет обратного пути в LAN, и есть только точечные исходящие правила для сервисов, которые там живут (классический веб, почтовая отправка, UDP‑диапазоны VoIP/WebRTC). Доступ к любым upstream‑GUI из DMZ запрещён: так скомпрометированный сервер не тронет твою управляющую сеть. Остальное — блок и лог, чтобы быстро найти недостающий винтик.

Снижение рисков на исходе: закрыть «классику». Наружу блокируем привычных подозреваемых: SMB/NetBIOS, RPC/NFS, TFTP, SNMP, RDP/VNC/WinRM и «вольный» SMTP. Всё это уместно внутри сети или на осознанных маршрутах; в интернет — по дефолту нет. Нужна исключительная тропинка — оформи её осознанно и с меткой.

Сам экран: наружу можно, но всё под контролем. Экрану разрешён выход в интернет — со state, лимитами и метками. Это нужно для апдейтов, пакетов и диагностики. Без фанатизма: эта коробка — роутер и сторож, не браузерный терминал.

Anti‑rebind, LAN→DMZ и большое наведение порядка. Между LAN и DMZ разрешены только явные маршруты (например, клиенты к сервису в DMZ); обратка закрыта. Anti‑rebind предотвращает доступ к защищённым внутренним целям через DNS‑трюки поверх экрана. В остальном PF говорит чёткое «нет» — с return там, где быстрый отказ помогает диагностике.

Только роутер vs. роутер + DMZ: какой профиль твой?

Если тебе просто нужно подключить LAN к интернету, вариант «только роутер» идеален: компактный, ясный и всё равно жёсткий. Ты получаешь anti‑spoofing, фильтры bogon‑сетей, строгую исходящую политику, принуждение DNS к 1.1.1.1/1.0.0.1, контролирование DoH/DoT/DoQ/QUIC, админ‑SSH из LAN на экран и аккуратные дефолты для scrubbing, состояний и лимитов.

Как только ты хостишь сервисы — пусть даже только внутренние — вариант «роутер + DMZ» обретает смысл. DMZ локализует сбои и снижает шанс, что компрометированный сервис станет трамплином в LAN. Внутри DMZ — закрыто; исходящие — по белому списку и уже, чем в LAN. DNS столь же строг; NTP закрыт, пока он действительно не нужен.

Правильное включение IPv6

Базовая линия блокирует IPv6, чтобы ничего не осталось «наполовину открытым». Если нужен IPv6, включай его осознанно и последовательно: маршрутизация через sysctl, соответствующие правила inet6 в pf, чистый план исходящего (да, принуждение DNS и здесь — просто для v6), ясные решения по RA/DHCPv6. Зеркаль удачные идеи из v4: anti‑spoofing, deny‑by‑default, управление QUIC/DoH/DoQ и видимые исключения — ни больше ни меньше. Главный совет: не «подкладывай» v6 украдкой. Если вводишь — делай хорошо; иначе — пока не надо.

Эксплуатация, диагностика, форензика: измерять, а не угадывать

Жёсткая политика хороша лишь тогда, когда её можно читать каждый день. pf помогает тремя каналами:

Метки. Каждое важное правило имеет говорящую метку. В pfctl -vvsr видно, какие пути используются, какие блокируются и где гремит. Часто этого достаточно, чтобы сузить проблему.

Таблицы. pfctl -t <table> -T show показывает записи abusers/scanners. overload наполняет таблицы автоматически, когда клиенты открывают слишком много коннектов. Это не кара, а ремень безопасности.

Минимальный pcap. tcpdump — друг, но используй по делу. Для контроля DNS/DoH часто достаточно беглых взглядов:
tcpdump -n -e -ttt -i $wan 'port 53 or port 853 or (udp and port 784)'
Это форензика по плану, а не «Wireshark до слёз».

Здоровый набор тестов. Меняя правила, скомпилируй их без загрузки: pfctl -nf /etc/pf.conf. Затем pfctl -f — и если что‑то сломалось, метки и таблицы покажут, где править. Для принуждения DNS: drill @1.1.1.1 openbsd.org должен работать; drill @9.9.9.9 openbsd.org должен блокироваться. Для QUIC проверь, что curl -I --http3 https://example.com не идёт по UDP и откатывается на HTTP/2. Валидируй DoT/DoQ — попытки на 1.1.1.1:853 и UDP 784 должны падать, а счётчики блокирующих правил — расти.

Подсказка для исходящих изменений. Открывая что‑то, временно пометь правило очень явной меткой и через неделю посмотри, используется ли. Нет — удаляй. Так базовая линия останется стройной.

Производительность без «фольклора»

Схема не «на лезвии бритвы», а нацелена на стабильность. Несколько следствий важны:

Блок QUIC может слегка замедлить некоторые сайты. Это осознанный обмен: видимость вместо скорости. Если есть веские причины разрешить HTTP/3 — делай это точечно (цели в таблицу, метка — и готово).

ECN включён — в современных сетях почти всегда нормально. Если какая‑то экзотическая middlebox его не любит — быстро увидишь и отключишь в частном порядке — базовая линия не против.

Статические NAT‑порты для UDP — подарок для real‑time‑протоколов. Кто гонялся за WebRTC‑глюками, знает — бесценно. Это ничего не стоит, кроме понимания, что «рандомизация» UDP‑портов — не функция безопасности.

If‑queue и BPF‑буферы выставлены прагматично: запас на пики и отладочные сессии, которые не упираются в 4 КБ. Если реально упираешься в потолок, мерь и настраивай — не наоборот.

Частые ловушки — и как из них выходить достойно

«Моё приложение работает только с DoH!» Тогда нужно исключение или, лучше, честная оценка. Сам по себе DoH не зло, но мешает сетевому контролю (дом/офис). Можно разрешить конкретные хосты через таблицу; пусть это будет осознанное исключение, а не общая отдушина.

«Видеозвонки заикаются». Сначала проверь, покрыты ли UDP‑диапазоны твоего провайдера (Zoom/Teams/WebRTC). Статические UDP‑порты помогают, но без правильного исходящего коридора ничего не выйдет. Подстраивай прицельно, не «на всякий случай».

«Почтовый клиент не шлёт напрямую». Верно: исходящий порт 25 закрыт. Почта должна идти через submission (465/587) к провайдеру/серверу, а не прямо в интернет. Если нужно — явно разреши эти порты, с меткой.

«IPv6 внезапно сломался». В этой базовой линии v6 заблокирован. Если клиенты предпочитают v6, а экран его не маршрутизирует — будут таймауты. Либо включай v6 правильно (с правилами), либо сообщи клиентам (RA/ND), что v6 пока недоступен.

«После изменения правил начались чудеса». Думай о состояниях. Старые живут по умолчанию. Меняя базовую политику (например, открывая новый исходящий порт), убей затронутые состояния (pfctl -k ...) или, при необходимости, сбрось все (pfctl -F state). После этого мир снова согласован.

Почему эта базовая линия «безопасна» — и что здесь значит безопасность

Безопасность никогда не абсолютна. Но её можно измерять, когда цели ясны, а путь честно проверяется. Эта базовая линия снижает поверхность атаки, потому что:

минимизирует любую входящую экспозицию;

делает исходящий трафик исключением, а не правилом;

принуждает и делает видимым DNS;

блокирует маскирующие пути (QUIC/DoH/DoT/DoQ);

отключает псевдо‑функции (redirects, broadcasts);

применяет крепкие дефолты TCP/ICMP;

делает обработку состояний детерминированной;

даёт инструменты наблюдать за использованием ежедневно.

При этом конфигурация остаётся сопровождаемой. Она «безопасна» не потому, что в ней 3000 строк, а потому что каждую строку можно объяснить.

Миграция: как действовать

Если у тебя уже есть pf‑конфиг, двигайся по шагам:

1. Сначала sysctl. Загрузить ужесточение, которое не роняет сервисы. Посмотреть логи на необычный шум ICMP/RST.
2. Тестировать политику pf рядом. pfctl -nf и лаборатория/окно обслуживания. При первом включении не потеряй SSH из LAN на экран — закрыться снаружи очень больно.
3. Ужесточать исходящий. Включить принуждение DNS и понаблюдать. Затем постепенно закрывать «классические» рисковые сервисы. 1–2 недели мониторинга помогут найти слепые зоны.
4. Вводить DMZ (при необходимости). Перевести сервисы, держать закрытыми intra‑DMZ и DMZ→LAN. Открывать только строго необходимые исходящие. Наблюдать и точить.
5. Решить про IPv6 осознанно. Либо включать как положено, либо держать выключенным и честно сообщать клиентам.

Каждый этап повышает безопасность без рискованного «большого взрыва».

Что легко расширить потом

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

• Хирургические исключения для QUIC/DoH, если есть проверенные причины — всегда через таблицы и метки.
• Site‑to‑site VPN с минимальной поверхностью атаки; sysctl‑дефолты не мешают, если протоколы явно разрешены.
• Мониторинг/алерты. Счётчики pf и systat pf подходят для базовых метрик. Для большего — отправляй pf‑логи в центральную систему.
• IPv6, полностью зеркалируя логику v4 — не как чужеродную вставку.

Апдейты и обслуживание

OpenBSD держит слово — но читай release notes при каждом обновлении, особенно про синтаксис pf и ядреные дефолты. Метки, таблицы и ясные макросы ускоряют проверку между версиями. Держи дисциплину комментировать каждое исключение: зачем оно, кому нужно, когда в последний раз пересматривалось. Исключения — не грех; недокументированные исключения — технический долг.

Итог: ясность — лучшая «закалка»

Эта базовая линия преследует простую цель: ясность вместо сложности. Ты получаешь межсетевой экран OpenBSD, предсказуемый в повседневности, с уменьшенной поверхностью атаки, который показывает — с помощью меток, таблиц и разумных дефолтов — что реально происходит. Мы делаем ставку на явные решения, а не на неявные побочные эффекты: строгий исходящий, принуждение DNS к определённым резолверам, отсутствие тихих каналов через QUIC/DoH/DoT/DoQ, детерминированные состояния и крепкие «рычаги» ядра. Результат — не академический этюд, а надёжная отправная точка, на которой спокойно продолжаешь строить.

Важно отметить: эта базовая линия намеренно исходит из того, что локального резолвера нет и локального NTP‑сервиса нет. Она рассчитана на сценарии, где нужно быстро получить стабильность без дополнительной инфраструктуры. Если позже захочешь больше on‑prem‑контроля, это легко добавить — архитектура готова, без отказа от основных принципов.

Чтобы не искать: ниже ты найдёшь готовые конфигурации — оба профиля pf.conf (вариант «только роутер» без DMZ и «роутер + DMZ» с жёсткой изоляцией), а также ужесточённый sysctl.conf. Здесь мы объясняем решения; файлы внизу реализуют их буквально. Придерживайся последовательности «проверить → загрузить → измерить» — быстро получишь воспроизводимый результат.

И ещё о границах: здесь не фокусируемся на высоко‑таргетированных атаках и полном IDS/IPS. Это не значит от них отказаться — наоборот. Фундамент заложен так, чтобы можно было методично их добавить. На практике хорошо зарекомендовали себя три направления расширения.

Если у тебя появились идеи, как ещё подтянуть отдельные правила, есть особые требования или ты хочешь поделиться наблюдениями из эксплуатации — давай связь. Реальные отзывы — лучший катализатор содержательных улучшений и база для будущих дополнений. Безопасность — это процесс, а не спринт; с ясной базовой линией и сообществом, которое делится опытом, «хорошо» очень быстро превращается в «отлично».

Скачать sysctl.conf: https://www.protectstar.com/download/blog/sysctl.txt
Скачать pf.conf (с DMZ): https://www.protectstar.com/download/blog/pf.conf_withDMZ.txt
Скачать pf.conf (без DMZ): https://www.protectstar.com/download/blog/pf.conf_noDMZ.txt