SSH- és VPN-bejövő szabályok: mit is vezérel valójában az engedélyezési lista

Kövessen végig egy kapcsolatot az ügyféltől a hosztig: melyik horgot lépi át, miért jelent a megakadás és az elutasítás más-más szabályt, és miért soha nem szabályzat az elutasítás.

Csatlakozzon egyszer, mielőtt szabályt módosít, és jegyezze fel, hogy az ügyfél megakad-e vagy azonnal elutasítják. Ez az egyetlen különbség megmondja, melyik döntés dobta el a csomagot, és egy óra szabályzatfájl-olvasást takarít meg. Az út többi része rövid: a csomag átlép egy horgot, illeszkedik egy szabályra, és vagy eléri a figyelőt, vagy nem. Az engedélyezési lista csupán könyvelés e három tény körül.

Kövessen végig egy SSH-kísérletet a bejövő horogig

Az ügyfél SYN-t küld a hoszt címére a 22-es porton, és a kernel eldönti, hogy ez a csomag helyi szolgáltatásnak szól-e. Ha igen, lefut a bejövő útvonal, és a szabálykészlet vagy elfogadja a csomagot, vagy eldobja. A csend azt jelenti, hogy a SYN még az előtt meghalt, hogy a figyelő látta volna, a gyors elutasítás pedig azt, hogy valami visszaállítással válaszolt. Ezek különböző szabályok különböző ítéletei, és mindkettő jogos kimenet.

Ezután erősítse meg a figyelőt, mert egyetlen szabály sem ment meg egy nem létező szolgáltatást. Futtassa a ss -ltnp parancsot, és ellenőrizze, hogy valami a várt porton és címcsaládon van-e kötve, majd olvassa el a ssh -v parancsot az ügyfélen, hogy lássa, hol áll meg.

A továbbítás külön döntés

Egy VPN-kiszolgálón a érdekesebb horog a forward, mert az ügyfél forgalma a gépen keresztül halad, nem pedig neki szállítják. Az a hoszt, amely csak a saját VPN-ügyfelét futtatja, sokkal kisebb szabálykészletet igényel, mint az, amely mások csomagjait továbbítja. A két terv egy gépen való keverése olyan szabályokat szül, amelyek helyesnek látszanak, és semmit sem engednek át.

Írja meg a belső szabályzatot külön kérdésként: mely ügyfélcímek mely célokat érhetik el az alagúton keresztül. Tartsa az adminisztratív útvonalat, például az SSH-t, a bejövő útvonalon, saját forráskorlátozással. A tesztelés közben hozzáadott megengedő forward-szabály az a klasszikus hiba, amely túléli a tesztet, ezért módosítás után a teljes szabálykészletet nézze át, ne az egy sort, amelyet szerkesztett. Az alagút figyelőjének megnyitása nem engedély arra, hogy minden csatlakozott ügyfél igazgassa a hosztot.

Az eldobás és az elutasítás műveletek, nem szabályzatok

Az alap lánc szabályzata elfogad vagy eldob, és ez a választékok teljes listája, ahogy a nftables-referencia írja. Az elutasítás létezik szabályműveletként, kiválasztott válasszal, ezért írja felül a szabályzatként való megírása mind az nftablesen, mind az iptablesen. A gyakorlatban a drop semmilyen információt nem ad az ügyfélnek, míg a reject olyan hibát ad neki, amelyre cselekedhet.

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

Ezt a vázlatot döntés formájaként olvassa, ne beillesztendő fájlként, mert a címtartományok példák. Az SSH-porton lévő kifejezett reject egy másodperc alatt meghibásítja a jogosulatlan ügyfelet ahelyett, hogy kivárná az időtúllépést, ami lerövidíti a saját hibakeresését. A csend visszatartja az alkalmi pásztázást, és semmit sem mond az engedélyezett felhasználónak. Szolgáltatásonként válasszon, és írja le, miért, különben a következő ember visszaállítja.

Tartsa meg a valóban szükséges vezérlőforgalmat

Az összes ICMP blokkolása népszerű alapértelmezés, amely megtöri az útvonal-MTU felderítését, és a tünet egy kapcsolat, amely felépül, majd megakad a nagyobb csomagoknál. Az IPv6 szomszédkeresése a saját ICMPv6-típusaitól függ, és ezek eldobása még azelőtt megtöri az összeköttetést, hogy bármely TCP-szabályt megkérdeznének. Mindkettő megnevezett függőségként tartozik az engedélyezési listára, nem átfogó engedélyként. Az a szabályzat, amely csendben megtöri a felderítést, rosszabb annál, amely megenged egy kis diagnosztikai forgalmat.

Engedélyezze az established és related állapotokat az Ön által kezdeményezett kapcsolatokhoz, és hagyja, hogy az állapotkezelő motor intézze a válaszokat. Ezután erősítse meg, hogy a válaszútvonal kijjebb nincs blokkolva, mert a csak kimenő forgalomra vonatkozó felsőbb korlátozás ugyanazt az időtúllépést eredményezi, amelyet a hosztra akart kenni.

Bizonyítsa a helyreállást, mielőtt nyugdíjba küldi a régi útvonalat

Tartson nyitva egy konzol-munkamenetet, alkalmazza a módosítást, és nyisson teljesen új felügyeleti kapcsolatot egy másik terminálról. Egy meglévő munkamenet semmit sem bizonyít, mert túlélhet egy szabályt, amely minden új bejelentkezést blokkol, ami a tűzfalas munka legmeggyőzőbb hamis pozitívjává teszi. Ha egy megfigyelő rendszer ellenőrzi a hosztot, adja hozzá annak forráscímét a módosítás előtt, ne az első riasztás után. Ezután teszteljen egy nagy és egy kis csomagot annak bizonyítására, hogy a felderítés még működik.

VPN-szolgáltatásnál ismételje meg egy olyan ügyfélről, amely soha nem csatlakozott, mert egy folytatott munkamenet újrahasznosíthat olyan állapotot, amelyet egy frissnek egyeztetnie kell. Jegyezze fel a pontos szabálykészletet, amely átment, ellenőrző összeggel vagy másolattal, hogy egy későbbi szerkesztés összehasonlítható legyen találgatás helyett. Egyeztessen a szabálysorrend tulajdonosával, mert egy korábbi szabály csendben legyőzi a hozzáadottat.

Kapcsolódó cikkek