SSH- ja VPN-saapumissäännöt: mitä sallittujen luettelo todella ohjaa

Yhdistä kerran ennen kuin muutat sääntöä ja pane merkille, jääkö asiakas jumiin vai hylätäänkö se heti. Tämä yksi ero kertoo, mikä päätös pudotti paketin, ja säästää tunnin käytäntötiedostojen lukemista. Loppumatka on lyhyt: paketti ylittää koukun, osuu sääntöön ja joko saavuttaa kuuntelijan tai ei. Sallittujen luettelo on vain kirjanpitoa näiden kolmen tosiasian ympärillä.

Seuraa yksi SSH-yritys syötekoukulle

Asiakas lähettää SYN:n isännän osoitteeseen porttiin 22, ja ydin päättää, onko paketti paikalliselle palvelulle. Jos on, syötepolku ajetaan ja sääntöjoukko joko hyväksyy paketin tai hylkää sen. Hiljaisuus tarkoittaa, että SYN kuoli ennen kuin kuuntelija näki sen, kun taas nopea hylkäys tarkoittaa, että jokin vastasi nollauksella. Nämä ovat eri sääntöjen eri tuomioita, ja molemmat ovat laillisia lopputuloksia.

Vahvista seuraavaksi kuuntelija, sillä mikään sääntö ei pelasta palvelua, jota ei ole. Aja ss -ltnp ja tarkista, että jotain on sidottu odottamaasi porttiin ja osoiteperheeseen, ja lue sitten asiakkaalla ssh -v nähdäksesi, mihin se pysähtyy.

Edelleenlähetys on erillinen päätös

VPN-palvelimella kiinnostavampi koukku on forward, koska asiakkaan liikenne reititetään koneen kautta sen sijaan että se toimitettaisiin sille. Isäntä, joka ajaa vain omaa VPN-asiakastaan, tarvitsee paljon pienemmän sääntöjoukon kuin se, joka välittää muiden paketteja. Kahden mallin sekoittaminen samassa koneessa tuottaa sääntöjä, jotka näyttävät oikeilta eivätkä päästä mitään läpi.

Kirjoita sisäkäytäntö omaksi kysymyksekseen: mitkä asiakasosoitteet saavat saavuttaa mitkä kohteet tunnelin kautta. Pidä hallinnollinen polku, kuten SSH, syötepolulla omalla lähderajoituksellaan. Testauksen aikana lisätty salliva forward-sääntö on klassinen vika, joka elää testiä pidempään, joten tarkista muutoksen jälkeen koko sääntöjoukko etkä sitä riviä, jota muokkasit. Tunnelin kuuntelijan avaaminen ei ole lupa jokaiselle yhdistetylle asiakkaalle hallita isäntää.

Pudottaminen ja hylkääminen ovat toimintoja, eivät käytäntöjä

Perusketjun käytäntö hyväksyy tai pudottaa, ja siinä ovat kaikki vaihtoehdot, kuten nftables-viite toteaa. Hylkääminen on olemassa säännön toimintona, jolla on valittu vastaus, minkä vuoksi sen kirjoittaminen käytännöksi epäonnistuu sekä nftablesissa että iptablesissa. Käytännössä drop ei anna asiakkaalle mitään tietoa, kun taas reject antaa sille virheen, jonka pohjalta se voi toimia.

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

Lue tuo luonnos päätöksen muotona äläkä liitettävänä tiedostona, sillä osoitealueet ovat esimerkkejä. Selkeä reject SSH-portilla saa luvattoman asiakkaan epäonnistumaan sekunnissa aikakatkaisun odottamisen sijaan, mikä lyhentää omaa vianetsintääsi. Hiljaisuus ehkäisee satunnaista skannausta eikä kerro valtuutetulle käyttäjälle yhtään mitään. Valitse palveluittain ja kirjoita perustelu ylös, muuten seuraava ihminen muuttaa sen takaisin.

Pidä hallintaliikenne, jonka todella tarvitset

Kaiken ICMP:n estäminen on suosittu oletus, joka rikkoo polun MTU:n löytämisen, ja oireena on yhteys, joka muodostuu ja jumittuu sitten suuremmilla paketeilla. IPv6:n naapurien löytäminen riippuu sen omista ICMPv6-tyypeistä, ja niiden pudottaminen katkaisee linkin ennen kuin yhtään TCP-sääntöä kysytään. Molemmat kuuluvat sallittujen luetteloon nimettyinä riippuvuuksina eikä yleisinä lupina. Käytäntö, joka rikkoo löytämisen hiljaa, on huonompi kuin se, joka päästää hieman diagnostiikkaliikennettä.

Salli tilat established ja related yhteyksille, jotka itse aloitit, ja anna tilaa seuraavan moottorin hoitaa vastaukset. Vahvista sitten, ettei vastauspolkua ole estetty kauempana, sillä vain lähtevää liikennettä koskeva rajoitus ylempänä tuottaa saman aikakatkaisun, jota olit syyttämäisilläsi isäntää.

Todista palautuminen ennen kuin jätät vanhan polun

Pidä konsoli-istunto auki, käytä muutos ja avaa täysin uusi hallintayhteys toisesta päätteestä. Olemassa oleva istunto ei todista mitään, koska se voi selvitä säännöstä, joka estää jokaisen uuden kirjautumisen, mikä tekee siitä palomuurityön vakuuttavimman väärän positiivisen. Jos valvontajärjestelmä tarkistaa isännän, lisää sen lähdeosoite ennen muutosta äläkä vasta ensimmäisen hälytyksen jälkeen. Testaa sitten yksi suuri ja yksi pieni paketti todistaaksesi, että löytäminen toimii edelleen.

VPN-palvelun kohdalla toista asiakkaalta, joka ei ole koskaan yhdistänyt, sillä jatkettu istunto voi käyttää uudelleen tilaa, jonka tuoreen on neuvoteltava. Kirjaa täsmällinen sääntöjoukko, joka meni läpi, tarkistussummalla tai kopiolla, jotta myöhempi muokkaus voidaan vertailla eikä arvata. Sovita yhteen sen kanssa, joka omistaa sääntöjen järjestyksen, sillä aikaisempi sääntö voittaa hiljaa lisäämäsi.