Правила за входящ трафик по SSH и VPN: какво всъщност управлява списъкът с разрешени

Свържете се веднъж, преди да промените правило, и отбележете дали клиентът виси, или веднага получава отказ. Тази единствена разлика ви казва кое решение е изхвърлило пакета и спестява час четене на файлове с политики. Останалата част от пътя е кратка: пакетът пресича кука, съвпада с правило и или стига до слушател, или не. Списъкът с разрешени е просто отчетност около тези три факта.

Проследете един опит за SSH до куката за вход

Клиентът изпраща SYN към адреса на хоста на порт 22 и ядрото решава дали този пакет е за локална услуга. Ако е така, пътят за вход се изпълнява и наборът от правила или приема пакета, или го отхвърля. Тишината означава, че SYN е умрял, преди слушателят да го види, а бързият отказ означава, че нещо е отговорило с ресет. Това са различни присъди от различни правила и двете са законни изходи.

След това проверете слушателя, защото никое правило не може да спаси услуга, която я няма. Изпълнете ss -ltnp и проверете дали нещо е вързано към порта и семейството адреси, които очаквате, после прочетете ssh -v на клиента, за да видите къде спира.

Препращането е отделно решение

На VPN сървър по-интересната кука е forward, защото клиентският трафик се маршрутизира през машината, вместо да ѝ се доставя. Хост, който пуска само собствения си VPN клиент, се нуждае от много по-малък набор правила от този, който препраща пакетите на други хора. Смесването на двата дизайна в една кутия създава правила, които изглеждат правилни и не пропускат нищо.

Напишете вътрешната политика като отделен въпрос: кои клиентски адреси могат да достигат кои дестинации през тунела. Дръжте административния път, например SSH, на пътя за вход със собствено ограничение по източник. Разрешителното правило forward, добавено по време на тест, е класическият дефект, който надживява теста, затова преглеждайте целия набор правила след промяна, а не реда, който сте редактирали. Отварянето на слушателя на тунела не е разрешение всеки свързан клиент да администрира хоста.

Изхвърлянето и отхвърлянето са действия, не политики

Политиката на базовата верига приема или изхвърля и това е целият списък от избори, както твърди справката за nftables. Отхвърлянето съществува като действие на правило с избран отговор, затова записването му като политика се проваля и в nftables, и в iptables. На практика изхвърлянето не дава на клиента никаква информация, докато отхвърлянето му дава грешка, с която може да работи.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Четете тази скица като форма на решение, а не като файл за поставяне, защото диапазоните от адреси са примери. Явно отхвърляне на SSH порта кара неоторизиран клиент да се провали за секунда, вместо да изчака таймаут, което съкращава вашето собствено отстраняване на проблеми. Тишината възпира случайното сканиране и не казва нищо на оторизиран потребител. Избирайте за всяка услуга и записвайте защо, иначе следващият човек ще го върне обратно.

Пазете контролния трафик, който наистина ви трябва

Блокирането на целия ICMP е популярна настройка по подразбиране, която чупи откриването на MTU по пътя, а симптомът е връзка, която се установява и после засяда при по-големи пакети. Откриването на съседи при IPv6 зависи от собствените си типове ICMPv6 и изхвърлянето им чупи връзката, преди да бъде прочетено каквото и да е правило за TCP. И двете принадлежат в списъка с разрешени като именувани зависимости, а не като цялостни разрешения. Политика, която тихо чупи откриването, е по-лоша от такава, която допуска малко диагностичен трафик.

Разрешете състоянията established и related за връзките, които сте започнали, и оставете машината за състояния да се погрижи за отговорите. После потвърдете, че пътят за отговор не е блокиран по-нататък, защото ограничение само за изходящ трафик по-горе по веригата произвежда същия таймаут, който щяхте да обвините хоста.

Докажете възстановяване, преди да се откажете от стария път

Дръжте отворена конзолна сесия, приложете промяната и отворете чисто нова връзка за управление от друг терминал. Съществуваща сесия не доказва нищо, защото може да преживее правило, което блокира всеки нов вход, и това я прави най-убедителния фалшив положителен резултат в работата с защитни стени. Ако система за мониторинг проверява хоста, добавете адреса ѝ като източник преди промяната, а не след първата тревога. После тествайте един голям и един малък пакет, за да докажете, че откриването още работи.

За VPN услуга повторете от клиент, който никога не се е свързвал, защото възобновена сесия може да използва състояние, което нова трябва да договори. Запишете точния набор правила, който е минал, с контролна сума или копие, за да може по-късна редакция да се сравни, вместо да се гадае. Координирайте с този, който притежава реда на правилата, защото по-ранно правило тихо побеждава добавеното от вас.