TTY / Tietoturvallisuuden jatkokurssi / Harjoitustyö 2012

Antti Kolehmainen

OpenBSD Palomuuri

Johdanto

OpenBSD on ilmainen avoimen lähdekoodin ja vapaan lisenssin omaava käyttöjärjestelmä ja se on yksi BSD-Unixin jälkeläisistä FreeBSD, NetBSD:n ja DragonflyBSD:n lisäksi. Kehittäjien lähtökohtana on ollut alusta asti tehdä OpenBSD:stä turvallisin käyttöjärjestelmä. Jatkuva koodipuun auditointi, tietoturvamekanismien implementointi ja avoimuus ovat olleet eräitä tietoturvallisuuteen tähtääviä toimenpiteitä. Tässä työssä esitellään OpenBSD:n ominaisuuksia palomuurirakennuksen näkökulmasta ja verrataan sitä yhteen suosituimmista vaihtoehdoista, linuxissakin esiintyvään iptablesiin. Lopuksi annetaan yksinkertainen esimerkki kotikäyttöön soveltuvasta palomuurisäännnöstöstä kommentointeineen.

PF, Hakkereiden kauhu

Yleistä

Yksi OpenBSD:n tärkeimmistä ominaisuuksista palomuureja ajatellen on PF. Tämä kernel-tasolla majaileva pakettisuodatin hallitsee verkkoliikennettä sekä muiden OpenBSD:n turvaohjelmistojen kuten spamd:n ja proxyjen toimintaa. PF kehitettiin alun perin IPFilter-palomuurin korvikkeeksi ja käyttääkin tämän johdosta hyvin samantapaista syntaksia config-tiedostossaan. IPFilterin ajoista PF on kuitenkin kehittynyt huimasti ja nykyisin siitä löytyykin ominaisuuksia NATista QoS-järjestelmän kautta kahdennukseen ja käyttäjien autentikointiin.

Yksinkertaista mutta totta

Koska yksi PF:n tärkeistä ominaisuuksista on sen syntaksin selkeys, on sitä hyvä verrata myös ”kilpailevaan” vaihtoehtoon. Otetaan esimerkiksi säännöstö jossa palvelimelle halutaan päästää vain SSH ja HTTP liikenne sisään, mutta kaikki liikenne ulos. Linuxin iptablesilla se onnistuu seuraavasti:

#!/bin/sh
IPT="/sbin/iptables"

# Siistitään vanhat säännöt ja ketjut
$IPT --flush
$IPT --delete-chain

# Vakiopolitiikat kaikille ketjuille
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT

# Skipataan säännöt loopbackissa
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# Kaikki paketit jotka eivät ala "SYN" pudotetaan
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -s 192.168.0.0/24 -j DROP

# Päästetään ssh ja www sisään
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -s 192.168.0.0/24 -j ACCEPT
$IPT -A INPUT -p tcp --dport 80 -m state --state NEW -s 192.168.0.0/24 -j ACCEPT

PF:llä saman saa aikaiseksi seuraavilla riveillä:

# Määritellään sisäverkon osoitealue ja loopback sovitin
localnet="192.168.0.0/24"
loopback="lo0"

# Määritellään lista palveluista jotka halutaan päästää läpi
services=”{ ssh,  www }”

# Blokataan vakiona kaikki liikenne sisään
block in all

# Päästetään kaikki liikenne ulos vertaamatta tuleviin sääntöihin
pass out quick

# Poistetaan palomuuraus loopbackistä
set skip on $loopback

# Avataan ssh ja www portit
pass in inet proto tcp from $localnet to port $services

PF:n käskyt ovat siis selkeästi selkokielisempiä ja helppotajuisempia kuin iptables. Huomionarvoista myös on, että iptables on ennemminkin shell-skripti jossa käskyt annetaan suoraan syötteenä ohjelmalle. PF:ssä taasen kaikki säännöt majailee pf.conf-tiedostossa johon määritellään kaikki haluttu toiminta. Tarjolla on myös pfctl-ohjelma jolla PF:ää. voidaan hallita suoraan komentoriviltä

NATinkia, NATinkia

NAT eli Network Adress Translation on tarpeellinen jos julkisia reititettyjä IP-osoitteita on vain muutama, mutta koneita verkossa sitäkin enemmän. NAT translaatioilla voidaan sisäverkossa käyttää privaatti-osoitteita ja silti liikennöidä ulkoverkkoon kuin käytössä olisi julkinen osoite. PF:ssä NAT on sisänrakennettu ja sitä käskytetään sääntölistassa kuten mitä tahansa muutakin PF:n toimintoa.

Ennen kuin NAT on mahdollinen, tarvitsee määritellä IP-reititys päälle. Tämä onnistuu konsolista "sysctl"-komentoa käyttämällä.

# sysctl net.inet.ip.forwarding=1

Jonka jälkeen pf.confiin lisätään NATin mahdollistavat säännöt.

match out on re0 from vr0:network to any nat-to re0

Siis päästetään vr0:sta (int) tulevat paketit läpi mihin tahansa osoitteeseen sovittimen re0 (ext) kautta ja samalla määritetään lähdeosoitteeksi re0:n ip-osoite luoden NAT-tauluun tarvittavat tiedot kaksisuuntaista liikennettä varten. Jos myös ollaan tarkkoja, tämä kyseinen ratkaisu on nimeltään PAT eli Port Address Translation jossa yhden julkisen IP:n taakse avataan portteja joiden kautta liikenne sisäverkkoon tapahtuu. Mikään ei tietenkään estä tekemästä PF:llä myös aitoa IP->IP NATia, mutta PATin yleisyyden takia keskityn ennemminkin siihen.

Joissain tapauksissa sisäverkossa ajetaan erinäisiä palveluja joihin tarvitsee päästä ulkoverkosta. Ongelmaan löytyy ratkaisu redirect-säännöistä. Esimerkiksi www-palvelimelle osoitteessa 192.168.0.15 annetaan pääsy seuraavasti:

pass in on re0 inet proto tcp to re0 port 80 rdr-to 192.168.0.15
pass on vr0 inet proto tcp to 192.168.0.15 port 80

Ensimmäinen rivi järjestää uudelleenohjauksen ja toinen avaa tarvittavan aukon palomuuriin liikennöinnin mahdollistamiseksi.

Sisäverkosta on myös hyvä mahdollistaa pääsy palveluihin käyttäen niiden julkista IP:tä. Tämä tarkoitaa, että myös sisäverkon sovittimesta on suoritettava redirect palveluiden osoitteisiin. Jos tätä ei tehdä, on palveluihin mahdollista päästä vain niiden sisäverkko-osoitteella joka voi aiheuttaa jossain tilanteissa ongelmia. Ratkaisuna uudelleenohjataan sisäverkon sovittimesta palveluihin saapuva liikenne ulkoverkon sovittimeen josta se löytää tiensä oikean osoitteen kautta oikealle palvelimelle.

Vieläkin parempi ratkaisu olisi luoda erillinen DMZ eli eriytetty verkko johon julkiset palvelut voidaan turvallisesti laittaa. DMZ:lle tarvitaan erillinen sovitin, olkoonkin se fyysinen tai virtuaalinen omassa vlanissaan, johon uudelleenohjaus tehdään. Sääntölistat ovat samantapaiset kuin yllä lisänään vain DMZ:lle näkyvä sovitin.

Pääsynvalvontaa, rakas Watson

PF mahdollistaa myös pääsynvalvonnan autentikaatiolla. Authpf on shell joka pakottaa käyttäjät kirjautumaan omilla tunnuksillaan SSH:n välityksellä ennen kuin liikennöinti verkkoon on mahdollista. Jokaiselle käyttäjälle pystytään tekemään omat PF-säännöt joita ladataan ja poistetaan aktiivisesta sääntölistasta täysin dynaamisesti. Authpf:llä onkin helppoa toteuttaa esimerkiksi wlan hotspot -tyyppisiä ratkaisuja ilman erillistä ”captive portal” -sovellusta.

Sisäverkosta on myös hyvä mahdollistaa pääsy palveluihin käyttäen niiden julkista IP:tä. Tämä tarkoitaa, että myös sisäverkon sovittimesta on suoritettava uudelleenohjaus palveluiden osoitteisiin. Jos tätä ei tehdä, on palveluihin mahdollista päästä vain niiden sisäverkko-osoitteella joka voi aiheuttaa jossain tilanteissa ongelmia.

CARP, ei mikään kala

Taustaa

Yksi OpenBSD:n mukana tuomista eduista on CARP eli Common Adress Redundancy Protocol. Se kehitettiin Ciscon VRRP:n (Virtual Router Redundancy Protocol) ja HSRP:n (Hot Standby Router Protocol) vapaalisenssiseksi ja avoimeksi korvaajaksi, mutta on sen jälkeen kehittynyt edelleen esimerkiksi kryptografisin lisäyksin.

Käytännössä tämä tarkoittaa sitä, että voidaan rakentaa esimerkiksi 4 koneen klusteri jossa kaikki jakavat yhden julkisen IP-osoitteen. Liikenne joka saapuu tähän julkiseen osoitteeseen ohjataan tiettyjen sääntöjen mukaisesti klusterin muille koneille. Jos yksi kone poistuu klusterista, liikenne tasautuu jäljellejääneiden kesken. Näin esimerkiksi yhden palomuurin hajoaminen ei vaikuta palvelun saatavuuteen mitenkään. Palomuurin lisäksi saatavuutta voi tarvita WWW- tai FTP -palvelut. Kaikki tämä on mahdollista tehdä CARPin tarjoamilla ominaisuuksilla. Tämän tekstin puitteissa kuitenkin keskitytään CARPiin palomuurikäytössä.

Verkon pystytys


     THE INTERNET
         |
         |
    --------------------
    |re0               |re0
   ----               ----
  |    |vr1-------vr1|    |
  |    |             |    |
   ----               ----
    |vr0               |vr0
    |                  |
    --------------------
                |
                |
         LOCAL NETWORK

Jokaiselle CARP-ryhmään osallistuvalle koneelle on määritettävä virtuaali-sovitin jotta yhteydenpito muihin onnistuu. Kaikilla saman ryhmän koneilla on oltava sama ”vhid” arvo sekä haluttaessa salasana. Esimerkkikoneessamme komento voisi olla vaikka seuraavanlainen:

# ifconfig carp0 create
# ifconfig carp0 vhid 123 pass tosivaikeapassu carpdev vr0 advskew 0 192.168.0.1 netmask 255.255.255.0

Näiden komentojen tuloksena kone asettuu master-tilaan, sillä advskew arvo on 0. Muihin koneisiin määritellään suurempi arvo, ja ne asettuvat slave-tilaan. Carpdev määrittää sen sovittimen joka kuuluu tähän tiettyyn CARP-ryhmään. Seuraavaksi on tehtävä Internetiin päin oleva CARP-sovitin.

# ifconfig carp1 create
# ifconfig carp1 vhid 321 pass vaikeatosipassu carpdev re0 advskew 0 10.0.0.20 netmask 255.255.255.0

Nyt kun sekä LAN-puoli että Internet-puoli on CARPattu, voidaan palomuurisääntöjen ext_if ja int_if kovata yksinkertaisesti niitä vastaavilla CARP-sovittimien nimillä.

Synkkaaks meillä?

Homma ei kuitenkaan ihan vielä ole kunnossa, sillä jokaisella CARP-ryhmän koneella on vielä täysin erilliset palomuurisäännöt. Tähän ongelmaan ratkaisun tarjoaa pfsync jolla yhden koneen, tyypillisesti masterin, säännöt voidaan ajaa kaikille. Jokaiselle ryhmän koneelle on siis luotava pfsync-sovitin jonka kautta päivitykset siirtyvät. Pfsync-sovitin on myös CARPin tapaan sidottava johonkin fyysiseen sovittimeen joka esimerkkitapauksessamme on vr1.

# ifconfig vr1 10.10.10.1 netmask 255.255.255.0
# ifconfig pfsync0 syncdev vr1
# ifconfig pfsync0 up

Sääntöpäivitykset siirtyvät salaamattomana multicastina, joten on suositeltavaa pitää se erillään muista verkoista. Esimerkissämme molemmat palomuurikoneet on kytketty toisiinsa ristiinkytketyllä kaapelilla. Saman tuloksen useammalle koneelle saa tehtyä vaikkapa omalla kytkimellä tai eriyttämällä liikenteen suljettuun vlaniin.

Lopuksi

Kaiken tämän jälkeen pystymme luomaan yksinkertaisen kotireitittimeen sopivan sääntölistan. Oletetaan, että sisäverkossa on myös palvelin johon tarvitaan pääsy ulkoa päin. Koodi on sisennetty ja kommentoitu helppolukuisuuden vuoksi ja käyttää uusinta syntaksia sekä optimointeja.


# Määritellään makrot

   # Sovitin joka on kytketty Internetiin
   ext_if=”vr0”

   # Sovitin joka on kytketty sisäverkkoon
   int_if=”re0”

   # Loopback tarvitaan joillekin paikallisille palveluille
   loopback="lo0"

   # Määritellään sisäverkon osoite-alue käyttämällä ”network”-avainta joka 
   # automaattisesti tunnistaa alueen sovittimelle määritetystä ip:stä
   localnet=”$int_if:network”

   # Määritellään lista palveluista joille avataan pääsy
   services=”{ ssh, www }”

# NAT säännöstöt

   # NATin voi tehdä myös vanhempaa ”nat to”-sääntöä käyttämällä, mutta 
   # käyttämällä ”match” säästetään rivejä sekä helpotetaan pääsynvalvontaa
   match out on $ext_if from $localnet to any nat-to $ext_if

# Default deny ja liikenne ulos

   # Estetään vakiona kaikki liikenne
   block all

   # Päästetään kaikki liikenne ulos. Olisi myös mahdollista päästää vain
   # tietyt portit lisäämällä ”port” määrittelyt riveille.
   pass inet proto tcp from $localnet to any

   # Poistetaan palomuuraus loopbackistä
   set skip on $loopback

# Porttien avaaminen

   # Päästetään SSH ja HTTP kulkemaan
   pass in inet proto tcp to $ext_if port $services

   # Uudelleenohjaus-säännöt sisäverkon palvelimelle.
   pass in on $ext_if inet proto tcp to $ext_if port $services rdr-to $the_server
   pass on $int_if inet proto tcp to $the_server port $services

Ilmainen ja vapaa koodi, enterprise-tason ominaisuudet ja vahva tietoturvallisuus joihin OpenBSD:n kehittäjät ovat jo vuosia panostaneet tekevät käyttöjärjestelmästä loistavan vaihtoehdon palomuurien rakennukseen. Kun tähän lisätään vielä kevyt laitteistovaatimus ja dokumentaation loistavuus, paketti on varsin valmis. CARP-protokollan avulla on mahdollista aikaansaada suuriin verkkoihin skaalautuva palomuuriclusteri joka ei lakkaa toimimasta edes yksittäisten nodejen ollessa poissa käytöstä. Vaikka tämä työ lähinnä käsittelikin Ipv4:ää, on kaikki säännöt täysin yhteensopivia myös Ipv6:n kanssa sillä PF suunniteltiin alusta asti toimimaan myös tulevaisuuden IP-verkoissa.

Lähteet

SivuTiedotLaajennettu edit

Vaativuus Jatko
Valmius Valmis
Tyyppi Ydin
Luokitus Verkko
Mitä Useita
Miltä Useita
Missä Useita
Kuka Titu-ammattilainen
Milloin Päivittäin
Miksi Hyvä tapa
Print version |  PDF  | History: r11 < r10 < r9 < r8 | 
Topic revision: r11 - 14 Dec 2012 - 01:30:55 - AnttiKolehmainen
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback