Palomuurisääntöjen logiikka

[Ishtor]

Onko täällä palomuuri-ihmisiä? Minulle on epäselvää palomuurisääntöjen toimintalogiikka. Kyse lähinnä Ciscon CLI-pohjaisten komentojen käytöstä, mutta sama periaate lienee kaikissa muuri-/reititinmerkeissä, pienillä komentokielen variaatioilla.

Jotenkin varmaan mietin asiaa liian monimutkaisesti, kun aina on hirveää pähkäilemistä sen kanssa miten päin säännöt pitää kussakin tapauksessa rakentaa. Vaikka niitä on jonkin verran tehnyt, niin aina kun verkon topologia muuttuu niin koko ajatustyö pitää aloittaa alusta ja taas huomaan pähkäileväni että mihin kohtaan riviä se TCP-porttinumero pitikään sijoittaa, ja kummin päin osoitteet tulee.

Joten otetaan yksinkertainen esimerkki, sähköpostiyhteys: PC tarvitsee yhteyden sähköpostipalvelimelle automaattisesti generoitavien hälytysviestien lähettämiseksi. Leikitään vielä että sähköpostipalvelin sijaitsee DMZ:lla, eli sen kautta pääsee nettiin, josta viestit sitten saavuttavat hälytysten saajat (jotka voivat olla missä päin internettiä hyvänsä). Kuva alla.

Perusperiaate meidän säännöstössä on, että ulospäin kaikki liikenne aliverkoista on sallittu ja access-lista ottaa kantaa vain liikenteeseen joka tulee ulkoverkosta sisäänpäin. Kuitenkin säännöt on IN-sääntöjä mikä mielestäni tarkoittaa ihan päinvastaista; että tavallaan verkosta (kuvassa pilvi) ulos, siis reitittimen interfaceen tuleva liikenne menee pääsylistan kautta. Ja reitittimestä poispäin liikenne pääsee suoraan. Eikö niin?

Miten näillä perusperiaatteilla tehtäisi pääsyrivi joka sallii sähköpostiliikenteen? Tässä esimerkissä on helppo ymmärtää mikä on source ja mikä destination, mutta jotenkin aina sekään ei tullut niin yksinkertaiselta.

interfacet:
ip address 10.10.10.1 255.255.255.0
ip access-group 2 in

ip address 10.11.11.1 255.255.255.0
ip access-group 1 in

Lähtisin liikkeelle siitä että PC on source, eli

Extended IP access list 1
1 permit tcp host <pc:n osoite> host <exchange> eq 25
2 deny any any

Extended IP access list 2
1 deny any any

Mutta riittääkö tämä? Pitääkö myös ACL2:sta avata vielä jotain, kun siellähän IN-suuntaan blokataan myös liikennettä? Vai tuleeko paluupaketit aina perille? Entä tapauksessa jossa palvelimen ja PC:n välillä on kaksi reititintä?

Ja missä tapauksissa tuo porttinumero tuleekin tuonne väliin eikä rivin viimeiseksi? Sellaisiakin sääntöjä näkee, tosin vähemmän. Mutta jos suunnat on samat eli IN-suuntaan vain blokataan, niin mitkä on noita poikkeustapauksia?

Osaako joku selittää palomuurisääntöjen perusperiaatteen niin että tyhmäkin tajuaa?

 

[dot1q]

Ilmeisesti kyse on kuitenkin perinteisestä ACL sääntöjen hiomisesta?

ACL pitää aina miettiä niin että menet seisomaan tuohon reitittimen X kohdalle ja otat aina vain YHDEN verkon ACL:n kerrallaan työn alle.

Sitten mietit mitä tapahtuu kun tuossa liikennöidään. Mikä ohjelma (clientti) PC:llä hakee postit palvelimelta. Katsot ihan tietoliikenteen kulun kuvauksista millä rutiinilla liikennöinti avataan.

1) pc lähtettää ekan viestin exchangelle. Viesti osuu reitittimen ACL1 listaan (koska se on reitittimen IN tyypin ACL pc:n käyttämän verkon interfacelle.
Source = PC, Dest = Exc

2) reititin lähettää viestin edelleen palvelimelle. Nyt se osuisi Exchange palvelimen OUT listaan,jos se olisi käytössä. Out listassa Source = PC ja dest = Exc.

3) palvelin saa viestin ja vastaa PC:lle normi yhteyden kättelyrutiinien mukaan. Palvelimen vastaus osuu reitittimen ACL2 listaan saapuessaan palvelimen verkosta välitettäväksi PC:lle.
Tsekkaa mitä portteja jne tässä kohtaa käytetään. Voipi olla että client ei tod.kuuntele SMTP porttia koska eihän se ole se serveri

Source on nyt Exc ja dest = PC.

Nämä ACL säädöt on kohtuu haastavia koska tosiasialliset palomuurisäännöt juuri tässä kohtaa helpottaisivat hommaa - ne tajuaisivat että tämä on SMTP vastaus paketti ja kun SMTP on sallittu, vastaus sallitaan myös.

Helpottaiskohan ajattelua jos yksinkertaistaisin tätä niin että ACL on L2 tason tapa hoitaa L3 ja L5 liikenteen salliminen. Koska ACL on tilatiedoton, ylläpito saa tehdä moninkertaiset konffimiset...

Palomuurit taas seuraa pakettien tilatietoja ja muodostavat sitten sen perusteella sessiontableen tiedon avatuista yhteyksistä. Liikenne sallitaan jos se on avattu protokolla/portti tasolla jommasta kummasta suunnasta (ACL1 tai ACL2).
Eli tässä tullaan just tuohon sun kysymykseen pitääkö ACL:ien kanssa avata myös paluu paketit - pitää. Koska reitin ei tiedä kuuta tai maata siitä että PC aloitti jutustelun..

Ja tuo oli hyvä kysymys miten tietää mihin tuo portti numero tulee. Tarkastele tietoliikennepaketin headerin kenttiä. Siellä on src_ip, dst_ip, src_pt ja dst_pt kohdat. Ja ne on siellä tarkoituksella mukana - siksi myös niiden pohjalta voi noita ACL:iä tehdä/rakentaa. Tähän myös viittasin tuolla aiemmalla kirjoittamallani, kun sanoin että tarkastele miten se liikenne milläkin softalla pc-server välillä kulkee. Siellä on näitä portteja usein kerrottu jotta mistä portista PC:n eka viesti lähtee (yleensä tässä tapauksessa dynaaminen yläportti = hiton iso läjä sattumanvaraisia portteja) mutta on myös kerrottu että KOHDE portti on juurikin tuo SMTP eli TCP25.

Jos sulla on kaks reititintä joissa ACL:ät. Hyppää aina tohon keskelle X:ää seisomaan ja tiedät sitten mihin kaikkeen saat sääntöjä naputtaa.

En tosin ole vuosiin tunkannut ACL:ien kanssa. Ainakaan kymmeneen vuoteen

 

[telcoM]

Muuten erinomainen viesti dot1q:lta, mutta yhtä kohtaa haluaisin tarkentaa:

3) palvelin saa viestin ja vastaa PC:lle normi yhteyden kättelyrutiinien mukaan. Palvelimen vastaus osuu reitittimen ACL2 listaan saapuessaan palvelimen verkosta välitettäväksi PC:lle.
Tsekkaa mitä portteja jne tässä kohtaa käytetään. Voipi olla että client ei tod.kuuntele SMTP porttia koska eihän se ole se serveri

Source on nyt Exc ja dest = PC.

Kun puhutaan TCP-protokollasta, silloin on neljä asiaa jotka pysyvät samoina koko yhteyden ajan, ensimmäisestä SYN-paketista vihoviimeiseen FIN- tai RST-pakettiin asti:

• A-osapuolen (=yhteyden avaajan) IP-osoite
• A-osapuolen käyttämä porttinumero (yhteydenavauksen lähtöportti)
• B-osapuolen (=palvelinpään) IP-osoite
• B-osapuolen käyttämä porttinumero

Jos jokin näistä vaihtuu, silloin TCP-määritysten mukaan kyse ei voi enää olla samasta yhteydestä.

Tästä seuraa että palvelimen vastaus lähtee aina tasan siitä portista johon asiakaspää yhteyspyynnön lähetti, ja vastauksen kohdeporttina on se asiakaspään dynaaminen yläportti josta alkuperäinen yhteyspyyntö lähti.

(Tästä seuraa myös se, että NATtausta tehtäessä myös NATatun yhteyden paluupaketeille on aina tehtävä käänteinen NATtaus, tai muuten yhteys ei muodostu koska yhteyden avausta yrittävä pää ei pysty tunnistamaan "väärästä IP:stä/portista" saamaansa vastausta vastaukseksi, vaan hylkää sen ja jää turhaan odottamaan oikeilla tiedoilla tulevaa vastausta.)

Siellä on näitä portteja usein kerrottu jotta mistä portista PC:n eka viesti lähtee (yleensä tässä tapauksessa dynaaminen yläportti = hiton iso läjä sattumanvaraisia portteja) mutta on myös kerrottu että KOHDE portti on juurikin tuo SMTP eli TCP25.

Juuri näin. Eli asiakaspään lähettämän liikenteen puolella ne kolme tunnettua asiaa joihin ACL-säännöillä kannattaa normaalisti tarttua ovat IP-osoitteet ja kohdeportti palvelimen päässä. Palvelinpään vastauksissa ne kolme tunnettua ovat taas IP-osoitteet ja lähtöportti palvelimen päässä.

 

[dot1q]

Palvelinpään vastauksissa ne kolme tunnettua ovat taas IP-osoitteet ja lähtöportti palvelimen päässä.

Hep! Hyvä nosto, mä en taas tuossa enää muistanut tätä että sen tosiaan pystyi liimaamaan Source portille - vaikka tää hyvin oli itselläkin tiedossa
Kiitos kun virkistit hoksottimia.

Eli tosiaan sitä TCP 25 porttia pitää pompauttaa siihen ACL säännön "keskelle" että saa paluu viestit toimimaan. Ja tätähän kysyjä myös aprikoi viestissään mihin ja missä tapauksessa se portti pitikään laittaa .