Työ oli osa IT-palveluiden hallinta ja tietoturva kurssia, joka on osa kolmannen vuoden moduuliopintoja. Työssä keskityttiin lähinnä ingress-filteröintiin, eli filteröidään liikenne sen tullessa sisäänrajapintaan. Työssä tuli aikarajoitteet vastaan, ja asetusten täydellinen testaaminen jäi kesken. 1.1 Palomuuri suunnitelma Palomuurin asentaminen alkoi poistamalla VyOS-reitittimeltä 10.100.0.0/24 ja 10.0.0.0/24-verkot, sekä 10.50.0.0/24 DMZ-verkko. Palomuuri otti nämä alirajapinnat hoidettavakseen. Palomuurille luotiin nämä edellä mainitut verkot. Lisäksi luotiin uusi 10.24.0.0/24 verkko VyOS-reitittimen ja palomuurin välille. VyOS-reitittimelle määritettiin staattinen reitti, jolla ohjattiin pyynnöt edellä mainittuihin verkkoihin palomuurille. Tätä kautta liikenne kulkee jatkossa aina palomuurin kautta. Poikkeuksena ovat sivutoimipisteet, joiden liikenne ulkoverkkoon kulkee ilman palomuurin suodatusta. Kuviossa x on todennettu, kuinka liikenne kulkee palomuurin 10.100.0.1-rajapintaan. Sen jälkeen se kulkee 10.24.0.0/24 verkkoa pitkin VyOS-reitittimelle, joka reitittää sen määränpäähänsä. Kuvio 1. tracert-komento Palomuurin konfiguroimista nopeuttaa huomattavasti aliaksien käyttö. Loimme aliaksen ns. asiakasyrityksille, eli muiden yrityksien julkisille IP-osoitteille. Jos uusi asiakasyritys ilmestyy, tarvitsee vain lisätä tämä yritys aliakseen. Sivutoimipisteiden serverien sekä työasemien osoitteet niputettiin yhteen, ja DMZ-aluetta varten nämä vielä yhdistettiin. Aliaksia luodessa kannattaa kuitenkin olla tarkkana, ettei osoitteen tai osoitteiden poisto aliaksesta vaadi suurta määrää lisätyötä.
Kuvio 2. IP alias-määritelmät Myös portteja voidaan niputtaa yhteen. Aliaksien luominen voi myös selkeyttää palomuurisääntöjen lukemista. DHCP-palvelun kohdalla IPv4 ja IPv6 käyttivät eri portteja, joten niputimme nämä portit yhteen. http-aliakseen voitaisiin jatkossa lisätä alternative http-portit kuten 8080, eikä tarvitsisi kirjoittaa lisäsääntöjä tätä porttia varten. Aliaksen muokkaaminen riittäisi tässä tapauksessa. Jos tiedetään ennalta hyvin, että mitä portteja jollakin alueella on käytössä, voidaan niputtaa nämä portit yhteen, kuten DMZ_services aliaksen tapauksessa on tehty. Täytyy vain olla tarkkana, ettei salli liikaa portteja. Kuvio 3. Portti alias-määritelmät
Työn toteutus alkaa ottamalla outbound NAT-palvelu pois käytöstä. Tämä siksi, koska VyOS-reititin hoitaa NAT-osoitemuunnoksen. Kuvio 4. NAT-asetukset palomuurissa WAN-rajapinta on se rajapinta, johon saapuu kaikki ulkopuolinen liikenne, sekä liikenne lähtee ulkoverkkoon sen kautta. WAN-rajapintaan sallitaan tulevaksi liikenne asiakasyrityksistä DMZalueelle. Ei ole tarvetta, että asiakasyritykset ottaisivat yhteyden logistiikkaa.fi sisäiseen verkkoon. Lisäksi sallitaan kaikki liikenne aliaksesta 24 rajapinta, jossa on siis vain 2 IP-osoitetta, 10.24.0.1 ja 10.24.0.2. Tämä rajapinta-ratkaisu siis sallii kaiken vyos:in lähettämän liikenteen. Julkisilla osoitteilla on lähdeosoitteinaan oma julkinen osoite, joten liikenne on todella harvoin lähtöisin 10.24.0.1-osoitteesta. Olisimme voineet tehdä baselinen tälle verkolla. On kuitenkin kyseenalaista, että kuinka paljon loppujen lopuksi liikennettä kulkee VyOS:lta sisäverkkoomme. Etenkin kun olemme konfiguroineet OSPF:n kautta servereille sekä työasemille menevät rajapinnat passiivisiksi rajapinnoiksi jotka eivät vastaanota OSPF-mainostusviestejä. Kuviossa 39 on esitetty WAN-rajapinnan säännöt
Kuvio 5. WAN-rajapinnan säännöt Yhden palomuurin ratkaisussa on vaikeata hahmottaa sivutoimipisteiden reititystä. Liikenne siis saapuu esimerkiksi 10.200.2.0/24-osoitteesta. Siitä se voi joko mennä esim. 10.100.0.0/24 sisäverkkoon, tai VyOS eth0-rajapinnan kautta ulkoverkkoon. Kaikki sivutoimipisteiden liikenne reitittyy HQ VyOS-reitittimen kautta, joten on haastavaa suunnitella kaiken kattavaa ratkaisua. Jos liikenne menee ulkoverkkoon, se ei kulje lainkaan palomuurin kautta. Tätä kompensoi se, että hyvin vähän liikennettä sallitaan brancheilta logistiikkaa.fi sisäverkkoon. Jos liikenne menee brancheilta sisäverkkoon, silloin liikenne kulkee palomuurin kautta eth4- rajapinnan 10.24.0.0/24-verkkoa pitkin. Kuviossa x on suunnitelma sille, miten palomuuraus brancheille toimii. Branch_SRV-alias verkosta sallitaan servereille tarpeellinen liikenne, eli LDAP (portit 389 ja 3268) sekä Kerberos-protokolla. Voi olla, että windows-serverit tarvitsevat vielä tätäkin enemmän protokollia käyttöönsä servereiden välistä viestintää varten. Sivutoimipisteiden työasemille sallitaan pääsy päätoimipisteen samba-palveluun, sekä mahdollisuus tiedostonsiirtoon. Lisäksi kaikista branchien verkosta sallitaan pääsy DMZ-alueen palveluihin.
Kuvio 6. Palomuurin säännöt DMZ:lle Kuviossa 39 on esitetty palomuurin säännöt DMZ-rajapinnalle. Yhteys voitaisiin periaatteessa sallia kaikkialta internetistä määriteltyihin palveluihin, mutta tietoturvasyistä sallimme yhteydet julkisista osoitteista vain asiakasyritykset-ryhmästä. Suunnitelmassa on ehkä hieman toistoa, mutta siitä ei ole periaatteessa haittaa. Sääntöjen kirjoittaminen kahteenkin kertaan auttaa ymmärtämään palomuurausta sekä kehittämään rutiinia. Jos sisääntuleva liikenne on jo kerran filteröity, ei sitä tarvitse enää uudelleen filteröidä kun se saapuu ulostulevaan rajapintaan DMZ-rajapinnalle. Kaikki sisääntuleva liikenne siis saapuu ensiksi VYOS:n kautta 10.24.0.0/24 WAN-rajapintaan, josta liikenne ohjataan DMZ:lle. Jotta DMZ voi lähettää vastausviestit, eikä palomuuri oletuksena kiellä sitä, sallitaan kaikki liikenne 10.50.0.0/24-verkosta kaikkiin osoitteisiin. Rajausehdoksi määritetään se, että näiden palveluiden lähdeportin on oltava niitä palveluita, joita DMZ tarjoaa. Palvelin vastaa aina ns. perinteisellä portilla. http-pyyntöön vastataan 80-porttiin. Destination port on taas usein jotain 1000-65000 väliltä. Ja jos DMZ:n toiminta laajennetaan julkiseksi kaikkialle internettiin, myös vastausosoite voi olla mitä vain IPv4-osoitealueelta.
Kuvio 7. DMZ-rajapinnan asetukset HQSRV-rajapinnalle määriteltiin iso määrä sallittuja protokollia, jotka nähtiin tarpeelliseksi toimivalle palvelinympäristölle. Yhteydet sallitaan ulkoverkkoon, kunhan lähtöosoitteena on HQSRV-rajapinnan 10.100.0.0/24-osoite. Toisaalta taas yhteydet jotka sallitaan tähän verkkoon, ovat paljon enemmän rajoitetummat. Kohdeosoitteistusta voisi vielä tarkemmin rajoittaa. Yksi esimerkki tästä voisi olla se, että sallitaan 3268 eli global catalog-portin käyttö vain 10.100.0.0/24 ja 10.200-server verkkojen välillä. Kuviossa 42 ja 43 on esitetty HQSRV-rajapinnalle luodut säännöt.
Kuvio 8. HQSRV-rajapinnan säännöt Kuvio 9. HQSRV-rajapinnan säännöt 2
Työssämme täytyy lisäksi määrittää, että mikä liikenne sallitaan HQ työasemilta HQ servereille. Olennaisimpia ovat DNS, NTP, Samba, Kerberos sekä windows NetBIOS-palvelut. Myös LDAP ja global catalog-haut sallitaan varmuuden vuoksi. Jotta työasema-rajapinnan käyttäjät eivät pääse suorittamaan ldapsearch-hakuja, täytyy istuntojen kovennuksien olla kunnossa serverien puolella. Saattaa olla, että windows tarvitsee vielä näitä enemmän protokollia omiin palveluihinsa. Kuvio 10. HQSRV-rajapinnan palomuurisäännöt WS-rajapinnan säännöt muistuttavat hyvin pitkälti edellä määritettyä SRV-rajapinnan sääntöjä. Lisäksi täytyy määrittää yhteydet DMZ-alueelle, sekä sallia palveluita kuten http ja FTP ulkoverkkoon. Harjoituksen vuoksi yhdelle työasemalle lisättiin mahdollisuus muodostaa SSHyhteys servereille. Vastaavanlaisia erikoistapauksia täytyisi määrittää johtajille tai ITtukihenkilöille. WAN-rajapinnalle täytyy sallia http-liikenne ulkoverkosta WS-sisäverkkoon, ja miksei myös serveriverkkoon. http-liikenteen salliminen ulkoverkosta on tietenkin tietoturvariski. Tätä varten voitaisiin ottaa käyttöön palomuurin edistyneempiä ominaisuuksia, kuten deep inspection, joka siis tutkii pakettien sisältöä laajemminkin, kuin vain osoitteistuksen ja portin perusteella. Nämä ongelmat selittävät myös hyvin sen, että miksi tilallinen palomuuri on kätevä.
Koska SRV-rajapinnalle määritettiin niin tiukat ehdot sille, että mitä liikennettä päästetään läpi WSrajapinnasta, WS-rajapinnalle määritettiin löysät ehdot. Kaikki liikenne sallitaan SRV-rajapintaan, ja SRV-rajapinta filteröi mikä liikenne pääsee lävitse. Näin ollen ei tarvitse määrittää samoja sääntöjä kahta kertaa. On kuitenkin oltava tietoinen siitä, että missä vaiheessa liikenne suodattuu. Vastaavaa ajatustapaa voidaan soveltaa siinä, että mitä liikennettä sallitaan tulevaksi WSrajapinnasta lävitse. Koska kaikki liikenne on jo kerran suodatettu ennen kuin se saapuu WSrajapinnalle, määritämme että kaikki liikenne tähän verkkoon sallitaan. Kuvio 11. WS-rajapinnan säännöt 1.2 pfsense palomuurin toteutus ja todennus pfsense palomuuri on helppo asentaa. Laitteelle pitää määrittää hallinta-osoite, jonka jälkeen pääsemme konfiguroimaan laitetta verkon ylitse GUI:n kautta. Alla olevassa kuviossa 341 on kuvattu palomuurin IP-osoitteistuksen perusasetukset. Palomuuria varten luotiin uusi verkko VyOS-reitittimen ja palomuurin välille. Sille annettiin osoitealue 10.24.0.0/24, joista.1 on VyOS:ille ja.2 on palomuurille. Tämä verkko toimii WAN-rajapintana. Sitten määritetään muut verkot LANalueiksi. Kaikille näille annamme.250 päätteen. Yhdelle rajapinnoista annettiin ulkoverkon osoite, jotta pystyimme lataamaan ja asentamaan snort-paketin.
Kuvio 12. pfsense-palomuurin komentorivi Kuviossa 342 on kuva pfsense:n graafisesta käyttöliitymästä verkon ylitse. Kuvio 13. pfsense graafinen käyttöliittymä Jotta palomuuri toimii oikein, täytyy ottaa NAT pois käytöstä. Tämä on kuvattu kuviossa 343.
Kuvio 14. Firewall NAT-välilehti Firewall todennus tehtiin lisäämällä Labranetin transit-rajapintaan virtuaalinen workstation. Liikenne työasemalta kulkee VyOS-reitittimen eth0-rajapintaa pitkin, joten NAT-käännös toteutuu tämän kautta. NAT-käännös ei onnistu sisäverkosta, koska liikenne ei kulje mainittua eth0- rajapintaa pitkin, joka toteuttaa NAT-käännöksen. Kuviossa 344 on esitetty tietokoneen IPasetukset. Kuvio 15. Transit-rajapinnan tietokoneen IP-asetukset
Palomuurin asetukset pistettiin päälle, ja yhteydet testattiin http- sekä sähköpostipalvelimiin. Kuviossa 345 on todennettu http-yhteys DMZ-verkon WWW-palvelimeen. Kuvio 16. www-sivuston testaus Kuviossa 346 on testattu sähköpostin lähettäminen käyttämällä www-osoitteena julkista IPosoitetta, sekä kuviossa on vielä kertaalleen IP-asetukset. Sähköpostien selailu, sekä lähettäminen molemmat toimivat.
Kuvio 17. squirrelmail sähköposti-kansio Transit-rajapinnan kautta voidaan myös testata yhteyttä kielletyillä protokollilla. Yksi näistä protokollista on SSH, jolle ei tällä hetkellä ole tarvetta ulkoverkosta. Kuviossa 347 on testattu SSHyhteys sähköpostipalvelimelle. Koska erillistä sallimis-sääntöä ei ole luotu, palomuuri kieltää yhteyden. SSH käyttää pääsääntöisesti TCP-protokollaa.
Kuvio 18. Putty-yhteydenmuodostus Lisäämällä palomuuriin erillissääntö SSH-yhteydelle, johon määritetään lähtöosoitteeksi tietokoneen IP-osoite, kuviossa 348 huomataan että tätä kautta SSH-yhteyden muodostus onnistuu. Kuvio 19. Onnistunut SSH yhteys
UDP-protokollan toimivuus voidaan testata yksinkertaisesti lähettämällä DNS-kyselyjä palomuurin ollessa päällä. Kuviossa 349 on haettu sähköpostipalvelimia asiakasyritys-verkoista, joten voimme todeta, että DNS, joka toimii UDP:n kautta, on toiminnassa. Kuvio 20. Sähköpostipalvelimia TCP-protokollan toimivuus voidaan todeta esimerkiksi käymällä asiaskasyrityksen julkisella sähköposti-palvelimella. Kuviossa 350 on todennus http-protokollan, ja TCP:n toimivuudesta. Kuvio 21. http- sekä TCP-todennus Alla on vielä todennus, jossa on kielletty DC1-palvelinta pingaamasta 10.50.0.25 osoitteessa sijaitsevaa sähköpostipalvelinta. Kuviosta 351 huomataan, että DC1-palvelin lähettää ping requestpyyntöjä, mutta joihin vastataan Destionation unreachable -viestillä.
Kuvio 22. ping-pyyntö DC1-palvelimelta Tilannen palomuuri todennus PFsense-palomuurista näkee tilat States -valikosta Diagnostics -valikon alta. Alla kuviossa 352 on esimerkki tilasta, jossa 10.100.0.12 osoite on muodostanut TCP-yhteyden 10.50.0.25 palvelimen 80-porttiin. Kuvio 23. TCP-yhteyden tila Tilallisen palomuurin toiminnallisuus voidaan vielä testata SSH-yhteyttä käyttäen. Ideana on, että DC2-palvelin voi jatkaa SSH-yhteyttä TCP:n yli, vaikka palomuurin säännöt sen kieltävät. Samaan aikaan, DC1-palvelin ei voi muodostaa yhteyttä SSH:n ylitse juuri tästä säännöstä johtuen. Kuviossa 353 on todennettu SSH-yhteyden ESTABLISHED-tila. Kuvio 24. SSH-yhteys Kuviossa 354 on todennettu, että muutokset ovat otettu käyttöön. SSH-yhteys DC-palvelimilta kielletään 10.50.0.25 osoitteeseen, mutta samaan aikaan DC2-palvelin voi jatkaa SSH-yhteyden käyttöä, koska TCP-yhteys on muodostettu. Kuvaa varten on otettu netstat-komennolla todennus TCP-yhteyden tilasta, palomuurin säännöistä, sekä alalaidassa on tuoretta wireshark-liikennettä.
Kuvio 25. tilallisen palomuurin todennus Jos yritämme muodostaa yhteyttä DC1-palvelimelta, saamme virheilmoituksen. Testiä varten kannattaa tietenkin sulkea ensin SSH-yhteys DC2-palvelimelta. Yhteyden epäonnistuminen on todennettu kuviossa 355.
Kuvio 26. Putty virheilmoitus