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

Поврзете се еднаш пред да смените правило и забележете дали клиентот виси или веднаш се одбива. Таа единствена разлика ви кажува која одлука го фрлила пакетот и заштедува еден час читање на датотеки со политики. Остатокот од патот е краток: пакетот преминува кука, се совпаѓа со правило и или стигнува до слушателот или не. Списокот на дозволени е само книговодство околу тие три факти.

Следете еден SSH обид до влезната кука

Клиентот испраќа SYN до адресата на домаќинот на портата 22, а јадрото одлучува дали тој пакет е за локална услуга. Ако е, влезната патека се извршува и множеството правила или го прифаќа пакетот или го отфрла. Тишината значи дека SYN умрел пред слушателот да го види, а брзото одбивање значи дека нешто одговорило со ресетирање. Тоа се различни пресуди од различни правила и двете се легитимни исходи.

Потоа потврдете го слушателот, бидејќи ниту едно правило не спасува услуга што ја нема. Извршете ss -ltnp и проверете дали нешто е врзано за портата и семејството адреси што го очекувате, потоа прочитајте ssh -v на клиентот за да видите каде запира.

Пренасочувањето е одделна одлука

На VPN сервер поинтересна е куката forward, бидејќи сообраќајот на клиентот се насочува низ машината наместо да ѝ се доставува. Домаќин што врти само сопствен VPN клиент бара далеку помало множество правила од оној што пренесува туѓи пакети. Мешањето на двата проекти на една машина создава правила што изгледаат точни и не пропуштаат ништо.

Напишете ја внатрешната политика како одделно прашање: кои клиентски адреси смеат да стигнат до кои одредишта низ тунелот. Држете ја административната патека, на пример SSH, на влезната патека со сопствено ограничување на изворот. Дозволувачко правило forward додадено за време на тестирањето е класичниот дефект што го надживува тестот, затоа по промена прегледајте го целото множество, а не линијата што сте ја уредиле. Отворањето на слушателот на тунелот не е дозвола секој поврзан клиент да го администрира домаќинот.

Отфрлањето и одбивањето се дејства, не политики

Политиката на основната верига прифаќа или отфрла и тоа е целиот список на избори, како што вели референцата за nftables. Одбивањето постои како дејство на правило со избран одговор, затоа пишувањето како политика пропаѓа и на nftables и на iptables. Во практика drop не му дава на клиентот никаква информација, додека reject му дава грешка со која може да работи.

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
    }
}

Читајте ја таа скица како форма на одлука, а не како датотека за лепење, бидејќи опсезите на адреси се примери. Јасен reject на SSH портата го прави неовластениот клиент да пропадне во секунда наместо да чека истек на време, што го скратува вашето сопствено отстранување грешки. Тишината го одвраќа случајното скенирање и на овластениот корисник не му кажува ништо. Изберете по услуга и запишете зошто, инаку следниот човек ќе го врати.

Задржете го контролниот сообраќај што навистина ви треба

Блокирањето на целиот ICMP е популарна стандардна поставка што го крши откривањето на MTU на патеката, а симптомот е врска што се воспоставува и потоа заглавува на поголеми пакети. Откривањето соседи на IPv6 зависи од сопствените ICMPv6 типови, а нивното отфрлање ја крши врската пред да се погледа било какво TCP правило. Двете припаѓаат во списокот на дозволени како именувани зависности, не како општи дозволи. Политика што тивко го крши откривањето е полоша од онаа што пушта малку дијагностички сообраќај.

Дозволете ги состојбите established и related за врските што самите сте ги започнале и оставете го моторот што води состојба да се справи со одговорите. Потоа потврдете дека патеката на одговорот не е блокирана понатаму, бидејќи ограничување само за излезен сообраќај погоре го создава истиот истек на време што сакавте да го припишете на домаќинот.

Докажете го закрепнувањето пред да се откажете од старата патека

Држете отворена конзолна сесија, примените ја промената и отворете целосно нова административна врска од друг терминал. Постојната сесија ништо не докажува, бидејќи може да го преживее правилото што го блокира секое ново најавување, што ја прави највпечатливиот лажен позитивен резултат во работата со огнени ѕидови. Ако систем за следење го проверува домаќинот, додајте ја неговата изворна адреса пред промената, а не по првото предупредување. Потоа испробајте еден голем и еден мал пакет за да докажете дека откривањето работи и понатаму.

За VPN услуга повторете од клиент што никогаш не се поврзал, бидејќи продолжена сесија може повторно да искористи состојба што новата мора да ја договори. Запишете го точното множество правила што помина, со контролна сума или копија, за да може подоцнежна измена да се спореди наместо да се погодува. Координирајте со тој што го поседува редоследот на правилата, бидејќи поранешно правило тивко победува над тоа што сте го додале.