Szerző: Tamás

Ez a bejegyzés nem utolsósorban Misi cimborámnak szól, aki tudomásom szerint egy ideje már keresgél olyan VPN megoldást, ami bárhonnan, tűzfal, proxy mögül működik, kellőképpen biztonságos, és lehetőség szerint nem kell hozzá 3rd party klienst telepíteni. Az SSTP, hasonlatosan az OpenVPN-hez, nem igényli az ilyen-olyan kimenő portok nyitását, elég neki egy standard 443-as port, ezen keresztül építi fel a tunnelt. Ennek mutatom be a következőkben egy működő megoldását, amelynek a kiszolgáló oldalát a Mikrotik OS testesíti meg.

Áttekintés

Mi is az SSTP?
Az SSTP (Secure Socket Tunneling Protocol) egy Microsoft által kifejlesztett SSL alapú VPN, amely felváltani hivatott az eddigi implementációkat a megnövelt biztonsággal, kompatibilitással és teljesítménnyel.

Milyen operációs rendszerrel lehet használni?
Windows Vista SP1 és az utána megjelent PC és szerver Windows kiadások beépítve tartalmazzák. E mellett Linux alatt (pl. SoftEther, ez open-source) és Mikrotik routereken fut.

Mit jelent a megnövelt biztonság?
Az SSTP SSL (v3.0) kódolással csatlakozik, ami a mai kódolások között a legtöbbet használt és legbiztonságosabbnak tekintett készlet. Megoldásra kerültek a PPTP/L2TP biztonsági hibái. Hasonló SSL megoldást használ az OpenVPN.

Mit jelent a megnövelt kompatibilitás?
Az SSTP 443/HTTPS porton kommunikál, így gond és egyéb beállítás nélkül használható szinte minden tűzfal és NAT megoldás mögött. Az OpenVPN-hez hasonló módon proxyn keresztül is tud kommunikálni, de csak authentikáció nélkülin. Mivel a klienst beépítve tartalmazza Windows Vista SP1-től az összes M$ op. system, így nem kell telepíteni semmi kliensoldalon ezen a platformon, és nagyon egyszerű a kliensbeállítás is.

Mit jelent a megnövelt teljesítmény?
Mivel a Windows kernel szinten beépítve tartalmazza az SSTP VPN-t, így nincs az OpenVPN-hez hasonló userspace overhead, ezért jobb eredmények várhatóak sebességben.

Topológia

Megvalósítás

Szerveroldali lépések (konfiguráció a Routerboardon)

1., Certificate megkreálása. Itt én az egyszerűség (és persze költséghatékonyság szempontjából) egy self-signedet fogok használni; technikailag ez is ugyanolyan tökéletes. Ha az anyagiak engedik, akkor hivatalos tanúsítvány kibocsátótól is vásárolhatunk). Itt szükség lesz egy számítógépre, lehetőleg Linux OS-sel, és installált OpenSSL csomaggal.

# openssl genrsa 2048 > router_priv.pem (ez lesz a privát kulcsunk, 2048bit-es)
# openssl req -x509 -days 999 -new -key router_priv.pem -out router_pub.pem (ez fogja generálni a self-signed certificatet. Itt fogunk kapni pár kérdést, ezek közül az egyetlen ami nagyon fontos a CN (Common Name). Ennek meg kell egyeznie azzal az FQDN domainnévvel, amire majd a későbbiekben, mint SSTP szerver névre hivatkozunk)
# openssl pkcs12 -export -in router_pub.pem -inkey router_priv.pem -out router_pfx.pfx (ez konvertál nekünk egy .pfx kimenetet a certificateból (Personal Information Exchange), melyet majd, mint root CA-t kell importálnunk kliens oldalon (mivel nincs hivatalos kibocsátó, elhitetjük a windowssal, hogy mi vagyunk az)

2., Az elkészült certificate importálása a Mikrotikben

# certificate import file-name=router_pub.pem
# certificate import file-name=router_priv.pem

Hasonlót kell látnunk az importálás ellenőrzésekor.

3.,  Hozzunk létre egy PPP profile-t, külön az SSTP VPN serverhez.

# ppp profile add change-tcp-mss=yes name=sstp use-compression=yes use-encryption=yes use-vj-compression=yes

4.,  Hozzunk létre egy accountot, amivel majd a kliens csatlakozni tud (itt ez egy helyi user, de ha van a hálózaton RADIUS szerver, onnan is authentikálni)

# ppp secret add local-address=192.168.1.1 name=testuser password=testpassword profile=sstp remote-address=192.168.1.245 service=sstp

Ezt az utolsó parancsot nézzük meg alaposabban. Létrehoz tehát egy ‘testuser’ nevű usert, a megfelelő jelszóval. A ppp profil, amelyet használ, az előbbiekben létrehozott ‘sstp’ nevű lesz. A local-address a 192.168.1.1, mely a router local LAN felé néző interface, a remote-address pedig az az IP cím, amelyet a sikeresen becsatlakozott kliens kap meg. A létrehozott user csakis az sstp service-n valid, tehát pl. ssh loginként nem fogadja el a router.

5., A local LAN interfacen engedélyezzük a proxy-arp-t. Mivel a tunnel nem Layer2 szinten működik, így a becsatlakozott kliens MAC-addresse nyilvánvalóan nem fog “átjönni” a belső hálózat gépei számára. MAC-address nélkül azonban nincs kommunikáció sem, tehát erre szükség van. Ezt a szerepet fogja a local LAN interface ellátni azzal, hogy proxyzza a saját MAC addressét a kliensek és belső hálózati node-k között.

# interface bridge set bridge-local arp=proxy-arp (itt a bridge-local a belső hálózat felé néző interface)

6., Hozzuk létre az SSTP server virtuális interface-t.

# interface sstp-server add comment=”SSTP VPN” name=sstp-in1 user=””

7.,  Az SSTP server engedélyezése és beállítása

# interface sstp-server server set authentication=mschap2 certificate=cert_6 enabled=yes

Az autentikáció mschapv2-n történik, és a szerver certificate a cert_6 lesz, amit beimportáltunk.

8., Ha eddig nem tettük volna meg, a tűzfalon a 443-as portot ki kell nyitnunk a routeren, hogy az SSTP szerver fogadhassa a kéréseket.

#  ip firewall filter add chain=input protocol=tcp dst-port=443 action=accept

A szerveroldali konfiguráció a Routerboardon elkészült.

Kliensoldali lépések (konfiguráció  Windows 7-en jelen esetben)

1., Navigáljunk a ‘Control panel’ -> ‘Network and Sharing Center’ menüjébe, majd pedig kattintsunk a ‘Setup a new connection or network’ lehetőségre.

2., Válasszunk a ‘Connect to a workplace’ lehetőséget.

3., VPN connection létrehozása

4., Töltsük ki a mezőket az alábbi képen látható módon.

5., Felhasználónév és jelszó a csatlakozáshoz

6., A VPN kapcsolat kész, de még nem teljesen!

7., Zárjuk be az ablakot, majd újból navigáljuk a  ‘Control panel’ -> ‘Network and Sharing Center’ menübe. Bal oldalt a ‘Change adapter settings menüpontot válasszuk ki. Valami hasonlót fogunk látni (a kitakart részek nélkül, természetesen):

8., A létrehozott VPN kapcsolaton jobb egérgomb, majd pedig ‘Properties’ fül.

9., A ‘Security’ fülön a VPN típust állítsuk SSTP-re (enélkül is működni fog, de jóval több idő, mert először PPTP, majd L2TP/IPSec-kel próbálkozik, és csak utoljára SSTP-vel). Majd ugorjuk a ‘Network’ fülre.

IPv6-ra nincs szükség, az IPv4-es beállításoknál az IP cím és minden egyéb automatikus.

10., Az ‘Advanced’ fül alatt a következő pipát vegyük ki:

A ‘Use default gateway on remote network’-re nincs szükségünk, hacsak nem akarunk minden forgalmunkat a tunnelbe irányítani. Mi ezt nem szeretnénk, csak a távoli hálózatot elérni, az egyébként működő internetforgalom pedig menjen a saját default gateway-e felé

Tulajdonképpen készen is vagyunk!

11., Opcionális!! Ha a certificate-t nem vásároltunk, hanem self-signed, akkor a következő dolgot kell még megtennünk:

a., Start Menu ->Run -> mmc (Enter)
b., File menu -> Add/remove snap-in -> Certificates (Add)
c., Válasszuk a ‘Computer accountot’ -> Next -> Local computer (Finish)(OK)
d., Certificates (Local computer) -> Trusted root certification authorities -> Jobb egér
e., All tasks -> Import (cert-k kitallózása: router_pub.pem és router_pfx.pfx: itt, ha adtunk, akkor adjuk meg a passphrase-t)
f., Import, majd minden ‘Close’

Ez az a bizonyos lépés, amellyel a Windows számára “tesszük hivatalossá” a certificate-t.

Készen vagyunk!

Jobb egér gomb a létrehozott VPN kapcsolaton, majd ‘Connect’. Ha mindent jól csináltunk, a titkosított tunnel felépül, és nekünk tudnunk kell pingelni a belső hálózati node-okat.

Összegzés

Ez a típusú VPN nagyon leegyszerűsítette azt a problémát, amelyet a kliens tűzfal és/vagy proxy szerver mögött való elhelyezkedése vet föl. Mivel csak a 443-as célportot szükséges a kliensnek elérni, ez a legtöbb hálózaton nem akadály, a proxyk is általában átengedik. Tény és való: minderre képes az OpenVPN is. Ám annak a kliensoldali konfigurációja bonyolultabb, és ráadásul külön kell beszereznünk, míg ez a kliens a Windowsban integrálva van. Nagyfokú biztonsága, jó átviteli képessége, könnyű konfigurálhatósága pedig ötvözi azt, amit én egy jó VPN megoldástól elvárok.

Mind Windows nem-szerver verziókra, mind Linux-ra, továbbá Solaris-ra, FreeBSD-re és MAC OS X-re elérhető a szerver alkalmazása:

http://www.softether-download.com/en.aspx?product=softether

Napjainkban mindennapi dolognak számít, hogy az otthoni internet kapcsolat meg van osztva több gép között (céges környezetben pedig magától értetődő). A piac tele van ilyen-olyan home vagy SOHO kategóriás routerekkel, melyeknél már nem kuriózum a wifi támogatás illetve egyéb extra képességeik is vannak (dinamikus dns kliens, egyszerűbb QOS, stb.). Az évek során nekem is volt jó néhány ilyen routerem, de amiben az egyik jó volt, az más képességekben szegényebb. Valami olyasmit szerettem volna, ami valóban mindent tud. A címben szereplő router egy ilyen darab, és bár a hardvere is figyelemre méltó, tudását a Mikrotik nevű operációs rendszer teszi teljessé.

Mi ez a router tulajdonképpen és mitől annyira különleges?

1., A hardware

A kategória jól ismert brandjei (Linksys, D-Link, TP-Link, stb.) között valószínűleg idegenül cseng a Routerboard név. Pedig ez a rigai székhelyű, lett cég közel 20 éve, 1995 óta gyárt routereket és szolgálja ki a piacot a home kategóriás eszközöktől kezdve az ISP volumenű routerekig termékeivel. Maga a routerboard, mint neve nagyon találóan mutatja, egy célhardver, voltaképpen egy alaplap, melyet igény szerint több és többféle hálózati interfésszel szereltek fel. A fenti routert egy 600MHz-es processzor hajtja meg és 128MB RAM-mal rendelkezik. Hálózati oldalról 10 RJ45-ös portja van (5db gigabit port és 5db 10/100-as), melyekből 1 db élvez POE támogatottságot. Található rajta egy microUSB port és egy egy SFP port, mely kompatibilis bővítőport segítségével akár a 10GB-es link is elérhetővé válik. Van továbbá egy konzol portja is, just in case. A vezetéknélküli hálózati kapcsolatért pedig egy Atheros AR9300-as chip felel (B/G/N szabványú), mely 1W-os (!!!) wifi teljesítménnyel képes adni.

RB2011UiAS-2HnD alaplapja

Természetesen nem ilyen, a fenti képen látható “pucéron” kapjuk a terméket. A doboz tartalmazza a router-t magát, a tápkábelt, egy microUSB – USB konverter kábelt. Kicsomagolás után ezt látjuk:

Jobban megnézve a dobozt, feltűnik, hogy felülnézetből a jobb felső sarokban egy ablakhoz hasonló kis téglalap látható. Nos, ez egy mini LCD érintőképernyő, mely egy sor információt tud megjeleníteni az eszközről, beleértve a realtime színes grafikonokat a hálózati interfészek forgalmáról. A megfelelő menüből a router szabályos újraindítása is kieszközölhető.

2., A szoftver

Nos, ez az, ami igazán naggyá teszi ezt az eszközt. Én magam a Mikrotik OS-sel 2004 körül találkoztam először. Túlzás nélkül: már akkor olyan lehetőségei voltak (itt még a 3.x-es verzióról beszélünk, most 6.7-nél tart), amelyeket csak a több százezer vagy 1-2 millió forintos Cisco routerekben lehetett megtalálni.  A feature-k terjedelme meghaladja ezt a leírást, ezért a hivatalos linkjét illesztem ide: http://wiki.mikrotik.com/wiki/Manual:RouterOS_features . Saját shell-je van, mely jó átláthatósága és következetessége mellett tartalmaz egy igen jól használható script-nyelv támogatást. Maga az OS Linux alapú. A menedzsmentje történhet ebből a shell-ből, webböngészőbőből vagy a saját, egyedi megoldású WinBOX felületen keresztül (mindháromról írok később). A szoftver különféle license-ekkel vásárolható, e router esetében a Level 5-ös license az, ami “jár” a routerrel és természetesen a lifetime upgrade. A license szintekről itt: http://wiki.mikrotik.com/wiki/Manual:License

A beüzemelés

Csatlakoztatjuk a 230V -ra és várunk. A kis LCD-n azonnal megjelenik a Mikrotik logo, két-három boot üzenet, majd a router kis beépített hangszórója kettőt pittyen, és az eszköz működik. Itt először egy pici negatívumot is kell írnom: ez a router nem a kezdőknek készült. Nem a D-Link-féle “adok-hozzá-egy-telepítő-cd-t-és- azonnal-mindent-megcsinál” szemlélete van. Van ugyan egy alapkonfigja, ez a csomagolódobozra is rá van írva (default IP: 192.168.88.1, 2-10-es portig figyel, ill. az 1-es port dhcp client módúra van állítva), de ennyi. Még a wifi sem működik alapból (konfiguráltság hiányában le van tiltva az interfész). Mi hát a teendő?

Mint írtam, háromféle módon menedzselhető az eszköz. Shell (telnet, ssh, konzol, mindhárom esetén működik a dupla TAB-os kiegészítés), webes felület (ennek egyébként WebFig a neve), ill. a Winbox. Mi ez a Winbox? A Winbox egy egyszerű ,telepítést sem igénylő .exe file, melyből az eszköz minden paramétere elérhető. Nagyon következetes és barátságos felülete van. Én ezt a megoldást választottam (és ajánlom is) a menedzsmentre.

A router IP-címe vagy hostneve, felhasználónév és jelszó megadása után a ‘Connect’ gombra kattintva bejelentkeztünk a routerbe:

Látjuk, hogy az ablak bal oldalán egy rakat menü helyezkedik el; némelyiknek almenüje is van. Ezeket használva tudjuk a router konfigurálni.

A menedzsment

Őszintén szólva kicsit nehéz helyzetben vagyok, ha erről kell írnom, mivel a lehetőségek hatalmas száma miatt nem vállalkozhatom egy komplett manuál megírásása, nem is beszélve arról, hogy ezt már megtették helyettem: http://wiki.mikrotik.com/wiki/Manual:TOC . Ennél alaposabb és jobban részletekbe menő leírást nehezen lehetne írni.

Fontos tudnunk, hogy bár az alapkonfigurációban a 2-től a 10-ig portok össze vannak “fűzve” egy switchbe, ez nem magától értetődő. A 10 port lehet 10, egymástól független port is, azaz egy 10 portos router, de lehet egy 10 portos menedzselhető switch is. Akár egy 7 portos switch és 3 portos router felállás is. Switch oldalon természetesen VLAN-ozható is, ill. több switch között bonding-olhatóak is a portok, a nagyobb sávszélesség elérése végett. Bármely interfésznek adható IP cím, több is, ha erre van igény. Közös és ugyancsak praktikus dolog minden menüben, hogy az elemek nemcsak hozzáadhatók és elvehetők a konfigból, de engedélyezhetőek, letilthatóak és kommentezhetőek is. Router nagyon ki van hegyezve arra, hogy gazdája minden pillanatban pontos képet kaphasson a forgalomról, terheltségről, stb. Minden interfészhez tartozik realtime grafikon, TX/RX pillanatnyi és összes forgalom packet per sec és kilobyte per sec alapon.

Az én konfigurációm (egyelőre) a következőképpen néz ki. Egy interfész a VDSL modem felé (kvázi WAN port), a többi 9 port plusz a wlan interfész pedig összefogva egy multiport bridge-be a local LAN felé.

Packet filter és translation oldalról pedig kifelé minden, befelé csak a válaszkapcsolatok, ill. a belső hálós 192.168.55.x tartományt NAT-olja a WAN interfacen.

Továbbá egy redirect szabály, mely minden kifelé a 80-as tcp célportra tartó forgalmat a router 8080-as portjára irányít. Miért? A router OS tartalmaz egy nagyon jól használható beépített webproxy-t (én a router USB portjára dugott 2GB-s pendrive-ot használom e proxy cache drive-jának), és ide irányítja a webforgalmat. Egyszóval, ez az egy szabály egy transzparens proxy-vá is tette a routert egyben.

Extrák

1,  SMB szerver

Az USB portra (akár USB hubon keresztül is) rádugott merevlemez megosztható SMB protokoll használatával (windows network share). Megosztások, user kezelés működik, egyelőre munkacsoport módban csak, de könnyen el tudom képzelni, hogy a jövőben az AD integrációt is megoldják.

2., Traffic flow

Cisco routerekben régi és bevált technológia a “netflow”. A Mikrotik is tudja ezt,  támogatja a version 1, 5, és 9-et is. Megfelelő collector használatával a hálózat totálisan nyomonkövethető forgalom és kapcsolatok tekintetében.

3., QOS és packet manipulation

Abszolút kifinomult QOS kezelés, forgalom priorizálás. Csomagok, kapcsolatok megjelölése és ezek alapján osztályozása, stb. Linux Iptables ismeretekkel nagyon egyszerű a kezelése.

4., Layer 7 classification

Támogatja a Layer 7 reguláris kifejezéseket, ami által a forgalom sokkal finomabb (igaz, erőforrás igényesebb) megfigyelése lehetővé válik. http://l7-filter.sourceforge.net/protocols (az össze itt felsorolt regexp beilleszthető).

5., Metarouter

Nos, igen, a virtualizáció. Ami a Solarisnak a zóna, az AIX-nak az LPAR, a Linuxnak a jail, az a Mikrotik-nek a METARouter. Virtuális router a routeren belül.

6., VPN-ek

Gyakorlatilag majd minden VPN majd minden módban támogatott. IPSEC, L2TP with IPSEC, OpenVPN, PPTP VPN, mindezek network-network vagy host-network topológiában is. VPLS és MPLS ugyancsak támogatott.

7., Hotspot

Nos, ezt annyira összehozták, hogy komplett központok, csarnokok, nyilvános helyek forgalom vagy idő alapú számlázással,  felhasználónévre és jelszóra, de akár MAC addressre épülő autentikációval megoldott hotspotja működtethető. Támogatja a RADIUS szervereket és a voucherek (hotspot ticketek) nyomtatását is.

7., Egyebek

Említettem már a scriptelhetőséget. Feladatütemező. NTP kliens és szerver.

8., Enterprise routing

Teljeskörű BGP, OSPF, RIP, RIPng, MPLS, VPLS, VRF, MME (Mesh Made Easy) támogatás

9., Source ill .policy routing

Redundáns,failover ill forgalomfüggő routing-ok konfigurációja

10., VRRP

Virtual Router Redundancy Protocol. Segítségével és egy másik Mikrotik eszközzel redundáns gateway-ek, tűzfalak építhetők. Teljeskörűen támogatja.

Hirtelen ennyi, ami eszembe jutott és ezeket különböző környezetekben magam is használtam. Természetesen sokkal több ennél az, amit tud.

Összegzés

Nem is titkolom: erről a rendszerről csak szuperlatívuszokban tudok nyilatkozni. Iskolapéldája annak, hogy egy jó csapat, ha gondolkodik és akarja, akkor elfogadható áron tud kiváló TERMÉK-et gyártani. Összehasonlításul: egy Cisco 2600-as router vmikor 1999-2000 környékén súlyos százezrekbe került (talán millión fülül volt árban). Tudásban ugyanez Routerboard-dal és Mikrotikkel kialakítva bőven százezer forint alatt volt. Ami pedig az enterprise volument illeti, egyik előző munkahelyemen a BIX BGP peering routert építettem ilyenből, és évekig ment mindenféle probléma nélkül. A fentebb bemutatott Routerboard RB2011UiAS-2HnD ára szálítással és utánvéttel együtt ~33 ezer forintba került. 2012-től pedig a cloud routerek gyártását is megkezdték (Cloud Core Router CCR1036-8G-2S+EM, 36 CPU core, 1200Mhz/core és 16GB RAM).A cég évek óta és szinte heti gyakorisággal szervez világszerte ún. MUM-okat (Mikrotik User Meeting), ahol a workshopok mellett certified Mikrotik előadók osztják meg tudásukat az jelenlevőkkel.

A BSD szekciót nézve azt hiszem, mostmár feltűnővé vált az, hogy míg FreeBSD és OpenBSD cikkek  jelentékeny számban születtek, addig a NetBSD-ről még egyet sem tartalmaz a gyűjtemény. Tekintve, hogy egy szintén népszerű és jól támogatott, stabil BSD terjesztésről van szó, úgy  gondoltam, hogy ideje végetvetni ennek, ezért a NetBSD telepítéséről szeretnék most egy összefoglalót közzétenni, méghozzá nem szimpla módjáról, hanem kicsit adatvédelmi szempontokat is figyelembe véve, egy mirror diszk-párra való telepítéséről.

NetBSD install RAID1 root-ra – lépésről-lépésre

A BSD-kről szóló általános írásban már ejtettem szót a NetBSD-ről, kiemelve azon nagyszerű jellemzőjét, hogy tényleg nagyon sok architektúrát támogat. Most hirtelen vettem a fáradtságot, és megszámoltam: az 5.1.2-es, legfrissebb verziója 42 önálló architektúrára érhető el. Azért ez nem rossz szerintem. A hibatűrő adattárolást, értem itt a különféle RAID-szinteket, mint azt már szintén említettem, a RAIDframe (raidctl) látja el, támogatva a rendszerindítást is.

Környezet

– virtual PC (Oracle Virtualbox 4.1.22)
– 2 db 3GB-os diszk
– 1 CPU
– 512MB RAM
– NetBSD 5.1.2 (i386) operációs rendszer

Lássuk hát a telepítés lépéseit mirror diszkre.
1., A telepítő médiát (itt nálunk CD) elindítva ezt az indítómenüt fogjuk kapni

Itt válasszuk értelemszerűen az 1-es ’Install NetBSD’ opciót.

Válasszunk magunknak egy emberi nyelvet, melyen majd a telepítő üzeneteit szeretnénk látni. Nekem (s gondolom, sokunknak)az angol itt teljesen megfelel, a magyar jelenleg nem támogatja.

Itt a billentyűzet-kiosztást állíthatjuk be, melyet a telepítés ideje alatt használni szeretnénk. Itt már van magyar nyelvi támogatás. Választhatjuk ezt is. Most következik az izgalmas része a telepítésnek.

Az installálás maga az ’a’ opcióval történne, de mi egy picit bonyolítjuk a dolgot a RAID1 root-tal, ezért NEM ezt választjuk, hanem az ’e’ Utility menu opciót.

Itt pedig az ’a’ opciót, tehát egy shell-t futtatunk, és egy darabig kézihajtányos módban haladunk tovább, azaz előkészítjük a két üres diszket a RAID1-be történő szervezéshez, majd a további telepítéshez.

2., Diszkek előkészítése (a shellben ehhez a következőket kell tennünk)

# fdisk -0ua wd0

Az fdisk kérdéseire mindenhol maradhat a default válasz, ahol mégsem, ott pirossal kiemeltem a választ. Értelemszerűen tegyük meg ugyanezt a második diszkkel is, ugyanezekkel a beállításokkal.
3., A diszkek cimkézése (disklabel)
Ez szintén egyszerű, mindössze a partíciótípust kell majd megváltoztatnunk, ezt is kiemelem itt.

# disklabel -i -I wd0

No kérem, mi is történt itt? A lemezünk teljes partíciójának a típusát megváltoztattuk a default 4.2BSD-ről RAID típusúra. Erre azért van szükség, mert a RAIDframe (raidctl) az ilyen típusúakat lesz majd hajlandó kezelni csak mikor majd RAID-et szeretnénk létrehozni. Ezt a lépést meg kell tennünk a másik lemezünkön is. Ha esetleg változtattunk is a partíció méretén vagy akárcsak kicsit gyorsabban szeretnénk haladni, nem kell pontosan az előző lépéseket a disklabel-lel megtennünk, a partíciós tábla ugyanis másolható.

# disklabel wd0 >/tmp/wd0.prt
# disklabel -R wd1 /tmp/wd0.prt

4., A RAIDframe vagy raidctl alapkonfigja

# cat > /tmp/raid1.conf
START array
1 2 0

START disks
/dev/wd0e
/dev/wd1e

START layout
128 1 1 1

START queue
fifo 100
^D (gyk.: CTRL+D)

Majd inicializáljuk a tükröt a következő módon:

# raidctl -v -C /tmp/raid1.conf raid1

Ezután pedig:

# raidctl -v -I 2012093001 raid1 (ezzel egy device serial adunk a raid device-unknak)
# raidctl -v -i raid1 (ez inicializálja a raid eszközt ill. le is synceli)
# raidctl -v -A root raid1 (ez megmondja neki, hogy ezen lesz a / filesystem maga)

Maga a RAID1 tömb tulajdonképpen elkészült és konzisztens is.

5., A boot-code installálása (ez szükséges a rendszerindításhoz, és mindkét diszken meg kell tennünk)

# installboot -o timeout=30 -v /dev/rwd0e /usr/mdec/bootxx_ffsv1
# installboot -o timeout=30 -v /dev/rwd1e /usr/mdec/bootxx_ffsv1

6., A tulajdonképpeni telepítés. A diszkek előkészítése és mirrorba való konfigja kész. Lépjünk ki a shellből, és folytassuk a telepítést a telepítő segítségével

# exit

Lépjünk vissza egészen a telepítő első képernyőjéig, és folytassuk az ’a’ Install NetBSD to hard disk opcióval. Ezt fogjuk látni:

Folytassuk, tehát ’b’ azaz yes!

Nagyon fontos! Innentől az előzőekben megkreált RAID1 tömbünkkel dolgozunk, tehát a két komponenséhez ne nyúljunk, hanem a mostmár megjelent ’c’ azaz raid1 opciót válasszunk!

Itt válasszunk igényeinknek megfelelően Teljes, Minimális vagy Egyedi telepítést! Jön a partícionálás!

Én most hagyom így ahogy van, aki majd élesben telepíti, az varázsolhat a méretekkel. Kapunk egy összegzést, és mehetünk tovább.

Üssünk Entert. A telepítő továbblép.

A konzol módnak megfelelő bootblock installt választhatjuk itt ki. Az ’a’ opció nekünk megfelel, tehát az ’x’ Exit opcióval innen kilépünk, és a tulajdonképpeni installja a rendszernek most kezdődik meg.

Itt kiválaszthatjuk, hogy az install közben egy progress bar-t szeretnénk-e látni, vagy ne legyen kimenet illetve akár teljes kimenet is lehetséges, az összes fileset nevét követhetjük ezzel. Nekem az ’a’ Progress bar opció megfelelt. Enterrel lépjünk tovább.

Az install média forrást választhatjuk itt ki, nekünk van CD-nk, mehet erről: ’a’ CD-ROM/DVD opció. Nyilván, ha online forrásból származó installt választanánk, akkor itt valamilyen formában a hálózati konfiguráció következne még.

Válasszuk az ’x’ Continue opciót, és az install elindul.

Ilyesmiket fogunk látni install közben. Ha elkészült a telepítés, akkor pedig ez a képernyő fogja tudtunkra adni (full installban is elég gyorsan lemegy).

Következzen az időzóna beállítása!

Ezt állítsuk be értelemszerűen a saját időzónánknak megfelelően, a lista tartalmazza Europe/Budapestet. Lépjünk tovább.

A fenti képernyőn kiválaszthatjuk, milyen jelszótitkosítási algoritmust szeretnénk használni a rendszerünkön. Mivel ez most egy teszt-telepítést, ezért ez most teljesen mindegy. Maradhatunk az elsőnél. Lépjünk tovább.

A root jelszó beállításról kérdez, szeretnénk-e ezt most megtenni. Persze, miért ne? Adjunk meg egy jelszót, és lépjünk tovább.

A használni kívánt shell-t választhatjuk itt ki (sajnos bash nincs közte). Ha megvan, lépjünk tovább.

Ha nyomunk egy ’Enter’, akkor visszadob minket a telepítő főmenüjébe, ahol a ’d’ Reboot computer-t választva újraindul a gépünk, és ha mindent jól csináltunk, akkor a már telepített rendszerünk fog indulni.

7., Újraindítás és system check

Az indításkor ezt a boot-menüt fogjuk kapni

A rendszer 5 másodpercen belül a default opcióval el fog indulni. Lefutnak a rendszer betöltődésekor az üzenetek, és megkapjuk a bejelenkezési promptot. Loginoljunk be, végezzünk el pár egyszerű ellenőrzést (filerendszer, raid állapot)

#df -h

# raidctl –s raid1

Minden működik.

Összegzés

Mint a többi BSD terjesztésnél, most, a NetBSD-nél is a telepítős cikk a leghosszabb talán, különösen, ha még RAID tömbre is szeretnénk telepíteni. A lépések talán bonyolultak, ezért kicsit szájbarágósra írtam ezt a cikket is. A folyamat bizonyára hosszadalmasnak tűnik, de nagyjából ugyanolyan logika mentén működik, mint pl. a FreeBSD ZFS root mirrorja. Telepítő indít, shell kérés, diszkek előkészítése, install, öröm. A rendszerre külön itt nem térnék ki,  alapjaiban hasonló a többi két BSD terjesztéshez, azaz: stabil, gyors, megbízható, biztonságos. Akinek sikerült felkeltenem az érdeklődését, annak jó tesztelést és sikereket kívánok.

FreeBSD installálás már szerepelt egy előző leírásban, tükrözve is. A leírásban azonban a FreeBSD natív filerendszere, az UFS testesítette meg a használt fájlrendszer típust. Ez egy kiforrott fájlrendszer, és a geom keretrendszerrel a tükrözés is könnyedén megoldható. Azonban a ZFS, mint fájlrendszer sok szempontból rengeteg újdonságot hozott a fájlrendszerek világába. A ZFS-ről már Misi cimborám írt egy átfogó cikket, ezért ennek a jellegzetességeit itt nem tárgyalnám ki. A FreeBSD már a 7.0-ás stabil verziótól tartalmazza a ZFS támogatást, beleértve a ZFS kötetről történő bootolást is. Ennek fényében számomra nehezen érthető, hogy a telepítő – eltérően pl. a Solarisétól – miért nem tartalmazza a lehetőséget a ZFS-re történő telepítésre.  Ám nem kell kétségbe esnünk: nem lehetetlen a dolog. A most következő írásban bemutatom, hogyan tudjuk a FreeBSD 9.0-ás verzióját teljes egészében ZFS-t használó fájlrendszeren telepíteni.

FreeBSD install – full ZFS mirror poolon

Környezet

– virtual PC (Oracle Virtualbox 4.1.22)
– 2 db 6GB-os diszk
– 1 CPU
– 1024MB RAM
– FreeBSD 9.0 operációs rendszer

A cél a FreeBSD 9.0 OS-t telepíteni ZFS fájlrendszeren, a két rendelkezésre álló diszkünk tükörbe rendezésével.

A telepítés lépései

Mint említettem, kis trükközésre lesz szükségünk, mivel az OS támogatja a ZFS-t minden szempontból, azonban a telepítő sajnos NEM. Ezért a következőt fogjuk tenni.

– NEM megyünk végig a telepítő szokásos lépésein, hanem az install médiáról való bootolás után „kidobjuk” magunkat a Live-CD shelljébe
– itt a diszkjeinket GPT partíciós sémával fogjuk partícionálni, cimkézni majd a boot-code-t installáljuk kézzel a bootszektorba
– megkreáljuk a szükséges pool-okat, majd a fájlrendszereket (beleértve a swap-et is)
– és a telepítő-felületet kihagyva kézzel fogjuk a szükséges rendszercsomagokat installálni
– végül néhány utólagos lépést elvégzünk (root pass, stb.)

Ez talán így elsőre kicsit ijesztően hangzik, de a lépések során láthatóvá válik, hogy bár sokat kell gépelni, de logikusak a lépések. Vágjunk is bele.

1., Hozzuk létre a partíciós sémát!

Bootoljunk az install médiáról, ami ebben az esetben NEM lehet a boot-only média, mivel az nem tartalmazza a rendszercsomagokat (mivel az internetről szedné le, nekünk viszont helyben kellenek).

’Enter’, majd válasszuk a Live CD opciót!

Ezután a root login után (itt nincs jelszó most), megkapjuk a shell-t. A következő lépésben előkészítjük a diszkjeinket.

# gpart create -s gpt ada0
# gpart add -b 34 -s 94 -t freebsd-boot ada0
# gpart add -t freebsd-zfs -l disk0 ada0
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0

Majd –mivel mi tükrözött környezet szeretnénk- ismételjük meg a procedúrát a másik diszkünkön is!

# gpart create -s gpt ada1
# gpart add -b 34 -s 94 -t freebsd-boot ada1
# gpart add -t freebsd-zfs -l disk1 ada1
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1

A partíciós sémánk ezzel el is készült, beleértve a boot-code installját is. Itt hadd álljak meg egy gondolat erejéig. Emlékszünk még talán az alap FreeBSD installra, ahol megemlítésre került a GPT partíciótípus. Ez a partícionálás egy sokkal rugalmasabb módját teszi lehetővé illetőleg a létrehozható partíciók számát 128-ban maximálja. Mi itt kettő partíciót hoztunk létre, egyet a boot-nak, a többi a maradék, ennel finomabb, fájlrendszer-szintű elosztása majd a ZFS-sel fog történni.

2., Most kreáljuk meg a ZFS poolunkat, úgy, hogy a két diszk tükrözve kerüljön bele.

# zpool create zroot mirror /dev/gpt/disk0 /dev/gpt/disk1

3., Majd állítsuk be a boot filerendszert és tulajdonságait.

# zpool set bootfs=zroot zroot
# zfs set checksum=fletcher4 zroot
# zfs set mountpoint=/mnt zroot

Kapunk néhány üzenetet, melyeket figyelembe véve majd később megtesszük a szükséges beállításokat. Nem tudta megkreálni a mountpointot sem, mivel ez Live CD, tehát read-only. Ezenkívűl beállítottuk a boot fs-t, és a / filesystemet most az /mnt alá tettük, mivel az már foglalt a Live CD / filesysteme miatt. Később, mielőtt az install kész lenne, ezt természetesen majd módosítjuk.

4., Most exportáljuk és importáljuk a poolt, a zroot.cache-t pedig a /var/tmp alá tesszük.
# zpool export zroot
# zpool import -o cachefile=/var/tmp/zpool.cache zroot

5., Most következik a fájlrendszerek létrehozása  a megfelelő paraméterekkel (ez a sokat gépelős rész 🙂 ). Itt, természetesen el lehet térni a leírtaktól az igényeinknek és elképzeléseinknek megfelelően.

# zfs create zroot/usr
# zfs create zroot/usr/home
# zfs create zroot/var
# zfs create -o compression=on -o exec=on -o setuid=off zroot/tmp
# zfs create -o compression=lzjb -o setuid=off zroot/usr/ports
# zfs create -o compression=off -o exec=off -o setuid=off zroot/usr/ports/distfiles
# zfs create -o compression=off -o exec=off -o setuid=off zroot/usr/ports/packages
# zfs create -o compression=lzjb -o exec=off -o setuid=off zroot/usr/src
# zfs create -o compression=lzjb -o exec=off -o setuid=off zroot/var/crash
# zfs create -o exec=off -o setuid=off zroot/var/db
# zfs create -o compression=lzjb -o exec=on -o setuid=off zroot/var/db/pkg
# zfs create -o exec=off -o setuid=off zroot/var/empty
# zfs create -o compression=lzjb -o exec=off -o setuid=off zroot/var/log
# zfs create -o compression=gzip -o exec=off -o setuid=off zroot/var/mail
# zfs create -o exec=off -o setuid=off zroot/var/run
# zfs create -o compression=lzjb -o exec=on -o setuid=off zroot/var/tmp

6., A swap létrehozása (itt 1GB lesz) és ennek beállításai (ez ugyanis nem normál filesystemként viselkedik).

# zfs create -V 1G zroot/swap
# zfs set org.freebsd:swap=on zroot/swap
# zfs set checksum=off zroot/swap

7., Néhány jogosultság és symlink beállítás

# chmod 1777 /mnt/tmp
# cd /mnt
# ln -s usr/home home
# chmod 1777 /mnt/var/tmp

8., A tulajdonképpeni install most következik, hiszen eddig csak előkészítettünk mindent, de rendszerfile még nem került a fájlrendszerre.

# sh
# cd /usr/freebsd-dist
# export DESTDIR=/mnt
# for file in base.txz lib32.txz kernel.txz doc.txz ports.txz src.txz; do (cat $file | tar –unlink -xpJf – -C ${DESTDIR:-/}); done

Ez a fileseteket ki fogja csomagolni a megfelelő könyvtárakba. Jó esetben nem lesz kimenete, csak a promptot fogjuk visszakapni. Itt sem muszáj persze mindent feltenni, az src.txz ill. a ports.txz pl. később online forrásból is feltehető, mint up-to-date csomag.

9.,  A zpool.cache-t másoljuk a boot könyvtár megfelelő helyére (ez NAGYON FONTOS! , ha kihagyod, valószínűleg kezdheted előlről!)

# cp /var/tmp/zpool.cache /mnt/boot/zfs/zpool.cache

10., Hozzuk létre az rc.conf, a loader.conf fileokat és egy fstab-ot, ez utóbbit üres tartalommal.

# echo ‘zfs_enable=”YES”‘ >> /mnt/etc/rc.conf
# echo ‘zfs_load=”YES”‘ >> /mnt/boot/loader.conf
# echo ‘vfs.root.mountfrom=”zfs:zroot”‘ >> /mnt/boot/loader.conf
# touch /mnt/etc/fstab

11., Unmountoljunk mindent , majd állítsuk be a végleges mountpointokat (nyilván minden filerendszernél, amit létrehoztunk).

# zfs set readonly=on zroot/var/empty
# zfs umount -af
# zfs set mountpoint=legacy zroot
# zfs set mountpoint=/tmp zroot/tmp
# zfs set mountpoint=/usr zroot/usr
# zfs set mountpoint=/var zroot/var

Igazság szerint készen vagyunk! Nincs más hátra, mint rebootolni a kész rendszert (előtte persze az install médiát eltávolítjuk!).

Bootoláskor ha ilyet látunk, akkor valamit már jól csináltunk 🙂

A sikeres újraindulás után állítsunk be egy root jelszót, adjunk hozzá nem-root jogú felhasználót, és állítsuk be a hálózatot a már ismert módon (sysinstall-lal vagy manuálisan, ahogy tetszik).

Ellenőrzések

# zpool list

# zpool status

# zpool get version zroot

# zfs get version zroot

# df –h
# zfs list

Összegzés

Bár kicsit talán hosszadalmasnak tűnik, és bonyolultnak, a lépések logikailag szerintem átláthatóak. A fenti leírást alkalmazva egy teljesértékű, tükrözött ZFS poolon futó operációs rendszert sikerült feltelepítenünk. A ZFS, csakúgy, mint más OS, pl. Solaris alatt ugyanúgy működik és használható. A storage pool jelenlegi verziószáma a FreeBSD 9.0-ben 28, filerendszeré pedig 5. A ZFS filerendszer memória igénye csakúgy, mint akárhol másutt, magasabb az átlagosnál, így 1GB RAM legyen tesztkörnyezetben is az a minimum, ahol ezt a filerendszert használjuk. Cserébe egy nagyon sokoldalú, nagyszerű lehetőségekkel felvértezett, stabil fájlrendszert használhatunk FreeBSD telepítésünkön.

Ez a post most dedikáltan, külön igényre készült, Paluska Misi komámnak, a bloggazdának. Az előző VPN-ről szóló írásban kifejezte igényét hozzászólásában olyan, a PPTP-nél biztonságosabb megoldásra, melyet ő egyaránt tudna használni a rendelkezésére álló eszközeiről, pl. rendszereinek távelérésére. Apple alapú rendszereken ugyan a PPTP VPN kliens is beépítve megtalálható, azonban, mint ezt említettem is, nem a legbiztonságosabbnak kikiáltott típusa ez a VPN-eknek. Ami ennél sokkalta jobb faktorral rendelkezik biztonság szempontjából, és több ma használt okostelefon is alapból támogatja, az L2TP VPN, IPSEC-kel ötvözve. Szóljon most erről ez a bejegyzés.

VPN megoldások II. – L2TP/IPSEC VPN szerver

Mi az L2TP?

Az L2TP a Layer 2 Tunneling Protocol rövidítése. Az L2TP tulajdonképpen a már megismert PPTP protokollnak és a Cisco Layer 2 Forwarding megoldásának az összeházasításából született meg. PPP hitelesítési módszert és tunneling megoldást alkalmaz, ami alkalmas két egymástól eltérő alhálózat összekötésére, azonban titkosítást önmagában nem használ, ezért önmagában a módszer nem biztonságos. Ezért gyakorlat szerint a IPSEC protokollkészlettel ötvözve alakítunk ki egy kevert megvalósítást, ahol a tunnelt az L2TP, a biztonságot pedig az IPSEC szolgáltatja. Tegyük mindezt OpenBSD platformon.

Topológia

Első lépések

Sajnos OpenBSD-n a szükséges csomag telepítését nem könnyítették meg nekünk a fejlesztők: a L2TP-t megvalósító daemon-t nem találtam meg a legfrissebb port-tree-ben sem. Kénytelen voltam forrásból feltelepíteni, amit CVS-sel kellett letöltenem, igaz, túl bonyolult ez sem volt:

Ennél a pontnál pihenjük kicsit (vagy igyunk meg egy jó sört, a sorok írásakor a külső hőmérséklet is bőven 25 fok fölött van), számolnunk kell a internet kapcsolatunk sebességétől függően 10-15 perccel.

Körülbelül így ér véget a forrás-update. Ezután tegyük a következőket:

# cd /usr/src/usr.sbin/npppd
# make depend
# make
# make install

A csomagunk, mely a L2TP szerver működéséért közvetlen felelős lesz, fel lett telepítve. Eddig ok. Mi jön még?

Bizonyos, a helyes működéshez elengedhetetlen kernel-paramétereket módosítanunk kell, ezek pedig:

# sysctl net.inet.ip.forwarding=1
# sysctl net.inet.esp.enable=1     # Enable the ESP IPsec protocol
# sysctl net.inet.ah.enable=1      # Enable the AH IPsec protocol
# sysctl net.inet.ipcomp.enable=1  # Optional: compress IP datagrams
# sysctl net.pipex.enable=1

Ezeket persze érdemes beszúrni az /etc/sysctl.confba, hogy érvényesüljenek újraindítás után is. Majd létre kell hoznunk konfigurációs állományt, amely hasonlóképp fog kinézni :

# cat /etc/npppd/npppd.conf
interface_list:                         tun0
interface.tun0.ip4addr:                 172.16.0.1

# IP address pool
pool.dyna_pool:                         172.16.0.0/24

# Local file authentication
auth.local.realm_list:                  local
auth.local.realm.acctlist:              /etc/npppd/npppd-users.csv
realm.local.concentrate:                tun0

lcp.mru:                                1400
auth.method:                            mschapv2 chap

# L2TP daemon
l2tpd.enabled:                          true
l2tpd.ip4_allow:                        0.0.0.0/0
#l2tpd.listener_in:                     L2TP 192.168.0.1
#l2tpd.purge_ipsec_sa:                  true
l2tpd.require_ipsec:               true
#l2tpd.accept_dialin:              true

pptpd.enabled:                         false
pptpd.ip4_allow:                        0.0.0.0/0

pppoed.enabled:                         false
pipex.enabled:                     true

Kell még egy „adatbázis”, ahonnan az autentikációs adatok lesznek feldolgozva, erre a fenti konfigban hivatkozik is egy sor:

auth.local.realm.acctlist:              /etc/npppd/npppd-users.csv

# cat /etc/npppd/npppd-users.csv
Username,Password,Framed-IP-Address,Framed-IP-Netmask,Description,Calling-Id
user1,secret,172.16.0.5,,memo for user1
user2,secret,172.16.0.6,,memo1 for user

Nem elírás, az első sor azért nincs kikommentezve, mert az npppd nem fogja ezt figyelembe venni, hasonlóan, mintha RADIUS konfig volna. Viszont jól látható, hogy mely oszlop mely autentikációs adatnak fog megfelelni (username,pass, etc.) Továbbá az IP cím, melyet kliens majd meg fog kapni a sikeres csatlakozáskor. Ha ilyet nem adunk meg, akkor a ’pool.dyna_pool’-ban deklarált IP poolból fog osztani egyet véletlenszerűen.

Eddig szép és jó, tulajdonképpen  a tunnel, TITKOSÍTÁS NÉLKÜL már most is működne, de mi nem érjük be ennyivel. Ígértünk IPSEC titkosítást is. Nézzük meg ezt is. Ezt nekünk az  ’isakmpd’ daemon fogja biztosítani (ezt már szerencsére nem kell külön fordítanunk; megtalálható a disztribúcióban). Hozzunk létre ennek is egy konfigurációs állományt.

# cat /etc/ipsec.conf
ike passive esp transport proto udp from 192.168.55.13 to any port 1701  main auth “hmac-sha1” enc “3des” group modp1024 quick auth “hmac-sha1” enc “aes”  psk “password

Gyors magyarázatként a fentebbi ipsec.conf-hoz elmondhatjuk, hogy az IPSEC beágyazott tunnel a 192.168.55.13-as IP-n fog várakozni, UDP 1701 portot használva. Az algoritmusokra, Diffie-Hellmann groupra most nem térnék ki, a ’psk’ azonban nekünk még fontos lesz: a pre-shared-key nekünk most a „password” lesz (értelemszerűen ezt a megosztott kulcsot, mely az encryption-höz kell, érdemes minék bonyolultabbra beállítani (kis- és nagybetű, szám, speciális karakter)).

Ha az előzőekben leírtakkal megvagyunk, indítsuk el az isakmpd daemont, a következő flagekkel:

# isakmpd -4Kv

ahol a -4 jelenti, hogy csak IPv4-en szolgáltat, a –K azt, hogy az algoritmusokat külső alkalmazás szolgáltatja (a mi esetünkben az ipsec alkalmazás, a –v pedig a bőbeszédű logolást).

Ezután indítsuk el az npppd daemont!

# npppd –d (ha szeretnénk a konzolkimenetet látni, vagy –D , ha daemonként futtatjuk).

Majd végül olvastassuk be az isakmpd-nek a titkosítási algoritmusokat:

# ipsecctl  –f /etc/ipsec.conf

Mivel, hasonlóan a PPTP-hez, nem tudunk egyedi routekoat leosztani, kénytelen kelletlen a tunnelre fogjuk terelni az összes, nem helyi hálózati forgalmunkat (ill. ha tudjuk, mit csinálunk, és engedi a platform is kliens oldalon, adhatunk egyedi routeokat kézzel is), így a tűzfalunkon NAT szabályt is kell megadnunk (/etc/pf.conf):

pass out on tun0 to !em0  nat-to 192.168.55.13
pass out on em0  to !em0  nat-to 192.168.55.13

Így, mikor a nem-helyi forgalom a tunnelen keresztül a VPN szerver felé indul, és ott nem kerül be a tunnel másik oldalán levő hálózatba, hanem default gatewayen keresztül menne tovább, előbb NAT-olva lesz, lehetővé téve az internettel való kommunikációt.

Szerveroldalról tehát kész vagyunk. A következőkben nézzük a kliens oldalt, legyen ez akár iPhone, Android, ill. Windows. Mivel Windoes kliens konfig már volt, iPhone-om pedig nincs, marad az Android platform, de minimális megfeleltetéssel mindhárom helyen ugyanezek lesznek  opciók.

Kliens config

A telefon itt egy Samsung Galaxy SII (GT-I9100), Android ICS 4.0.3-as OS-sel (gyári). Lássuk.

1., Alkalmazások -> Beállítások -> Egyebek -> VPN

Amint a ’VPN’ menüre nyomunk, már jön is a figyelmeztetés:

Ide egy feloldó mintát kell állítanunk, ugyanis a telefon ill. az Android komolyabb feloldási biztonság nélkül nem hagyja, hogy VPN-t állítsunk be.

Válasszuk a mintát, és rajzoljunk valamit 🙂

Tudom, nem lihegtem túl, dehát a teszt az teszt 🙂 Válasszunk a VPN hálózat hozzáadását:

Válasszuk az L2TP/IPSEC PSK módot. Írjuk be a VPN szerver KÜLSŐ IP-jét, majd adjuk meg a pre-shared key-t (amit ugye jó bonyolultra állítottunk).

Mentsük el a konfigot!

A VPN beállításunk kész. Teszteljük! Bökjünk rá, majd azonosítsuk magunkat!

Ha megadtuk az azonosítót ill. jelszót, akkor „Kapcsolódás” !

Látjuk, hogy csatlakoztunk, ill. a bal felső sarokban egy helyes kis kulcs ikon is jelzi, hogy biztonságos hálózati kapcsolatunk aktív.

Ha pedig egy ping tesztet is vizsgálunk, akkor látjuk, hogy teljes mértékben sikeresen konfiguráltunk mindkét oldalon.

A titkosítási szintet Androidon nem tudom megmutatni, azonban idevágom a Windows 7 státuszát (a beállítások pontról pontra megegyeznek!):

Hát, ennyi! Adós vagyok még egy log-részlettel,  csak hogy tudjuk, hogy kell vizsgálódnunk, ha bármi is nem működik vagy egyszerűen csak mert kíváncsiak vagyunk:

Jól látszik az isakmpd kezdetű soroknál az IPSEC kapcsolat felépülése, majd az npppd kezdetűeknél a tunnel létrejötte.

Összegzés

Az L2TP/IPSEC a biztonságos tunnelnek már egy jóval magasabb fokát valósítja meg (a titkosítás AES 256 bit is lehet, mint látszik a képen, ez gyakorlatban nem törhető). Sajnos, ezzel arányosan a szerveroldali konfigurációja is bonyolultabbá válik. Az egyedi routeok kiosztása itt is csak komolyabb nehézségek árán valósítható meg (ha szerveroldal Windows AD, valamivel könnyebb). Ám előnyére mondható, hogy amint a cikk elején említettem, ez sem igényel a legtöbb platformon 3rd party alkalmazást. Kinek-kinek  egyéni ízlése, hogy VPN irányban mire „szakosodik”, én ezt a megoldást inkább a bemutató kedvéért konfiguráltam be.

Napjainkban a VPN (Virtual Private Networking) -virtuális magánhálózat- főként az IT szektorban dolgozók számára nem kuriózum. Napi szinten kell használniuk (nekem is), ami teljesen érthető: biztonságossá és kényelmessé teszi az otthoni munkát (home office). Segítségével a munkahelyi és az otthoni hálózaton való munka közötti különbség elenyészik.  Az OpenBSD biztonságosságáról már esett szó; ennek magas foka miatt előszeretettel használják tűzfalak, security gatewayek, VPN szerverek operációs rendszereként. A VPN megoldások egyik fajtája a PPTP VPN (Point-Point Tunneling Protocol). A következőkben ennek a konfigurálását szeretném bemutatni – OpenBSD-n.

VPN megoldások I. – PPTP VPN szerver

Nem szeretnék mélyebben belemenni a PPTP VPN ismertetésébe  (nem akarom az írást hálózatbiztonság felé elúsztatni), de pár szó erejéig kénytelen vagyok megtenni a jobb megértés kedvéért. A PPTP-t az RFC 2637 írja le részletesen. Maga a PPTP a TCP 1723 portot és a GRE (IP 47-es) protokollt használja a tunnel felépítéséhez, és mivel PPP enkapszulációt (emlékezzünk a modemes dial-in-re anno, az is PPP volt) használ, innen a neve is: tunnelezett PPP protokoll. Ez volt az első VPN protokoll, mely a Microsoft által támogatottá vált (mind kliens (Windows 95 OSR2 óta!!!), mind szerver oldalon (RRAS service)). Titkosításra az MPPE 128 algoritmust használja, mely -meglepő módon- 128 bites titkosítást biztosít.

Előnyei:
–    egyszerű megvalósítás, mind kliens, mind szerver oldalon
–    beépített kliensoldali támogatás Windows platformon
–    a legtöbb mobilplatform (Android, iOS, Windows Mobile, MacOS) is tartalmazza beépítve

Hátrányai:
–    a VPN megvalósítások között csak közép-erősen számít biztonságosnak
–    esetenként nehézkes egyedi route-k kiosztása a kliensnek
–    magasabb fokú biztonságra csak jóval több adminisztrációval lehet felkészíteni (pl. (P)EAP-TLS)

Topológia:

A topológia szerint van nekünk egy munkahelyi hálózatunk, kiszolgálókkal, köztük egy irodai pc-vel és van egy otthoni PC-nk, melyről szeretnénk biztonságos módon elérni a munkahelyi hálózatot.  Mivel én most a tesztet otthoni virtual pc-s környezetben végeztem, nem szimuláltam külön szolgáltatói hálózatot, de ez nem is fontos a teszt szempontjából.

A teszt irodai PC IP-je: 10.0.0.2
A VPN szerver irodai hálózat felé „néző” IP-je: 10.0.0.1
A VPN szerver publikus IP-je: 192.168.55.13
Az otthoni PC IP-je: 192.168.55.14

Router nincs köztük,  és a VPN szerveren sincs route, csak maga a futó PPTP daemon. A cél: az otthoni pc érje el az irodai pc-t.

Konfiguráció – szerver oldalról:

OpenBSD-n  PPTP VPN szerver funkciót a PoPToP nevű port tudja biztosítani. Ezt a szokott módon a port-fából tudjuk telepíteni:

# cd /usr/ports/net/poptop/
# make install

Ezzel meg is vagyunk. Nézzük a konfigurációt lépésenként:

1., A tun interfacek létrehozása

# cd /dev
# ./MAKEDEV tun? (ahol a ? a tunnel interface száma, >4-től indul)

2., az /etc/pptpd.conf file tartalma

option /etc/ppp/ppp.conf
# Ez az IP egy subnetben van az irodai pc-vel
localip 10.0.0.1

# Ebből a tartományból fog kapni a kliensünk IP-t
remoteip 10.0.0.3-10

# Ez az IP a VPN szerver külső “lába”
# Ide fog csatlakozni a kliens

listen 192.168.55.13

pidfile /var/run/pptpd.pid
noipparam

3., az /etc/ppp/ppp.conf file tartalma

loop:
set timeout 0
set log phase chat connect lcp ipcp command
set device localhost:pptp
set dial
set login
set mppe * stateful
set ifaddr 10.0.0.1 10.0.0.3-10 255.255.255.255
set server /tmp/loop “” 0177

loop-in:
set timeout 0
set log phase lcp ipcp command
allow mode direct

pptp:
load loop
disable pap
disable chap
enable mschapv2
disable deflate pred1
deny deflate pred1
disable ipv6
accept mppe
enable proxy
accept dns
set dns 192.168.55.1
set nbns 192.168.55.1
set device !/etc/ppp/secure

4., az /etc/ppp/secure file tartalma (futtatható)

#!/bin/sh
exec /usr/sbin/ppp -direct loop-in

5., az /etc/ppp/ppp.secret tartalma

# Authname Authkey      Peer’s IP address        Label   Callback

tompika    testpass     10.0.0.3
horsedick  bigbraner    10.0.0.4
secuser    securepass   10.0.0.5

6., Indítás (/etc/rc.conf-ba pptpd=YES)

/etc/rc.d/pptpd start

Szerver oldalról készen is vagyunk!

Konfiguráció – kliens oldalról:

A kliens legyen egy Windows7 (ezzel fogom bemutatni), de lehet XP, Vista, stb.

1., Vezérlőpult\Minden vezérlőpultelem\Hálózati és megosztási központ

2., Új kapcsolat vagy hálózat beállítása

3., Kapcsolódás munkahelyhez (majd: Tovább)

4., Saját internetkapcsolat (magánhálózat) használata (majd: Tovább)

5., Töltsük ki az internetcímet (ez az az IP cím mely a /etc/pptpd.conf ‘listen’ szekciójában szerepel).

6., a szerveren levő /etc/ppp/ppp.secret -ban szereplő username-pass páros valamelyike (majd Kattintsunk a ‘Létrehozás’ gombra )

7., Az itt levő képernyőn NE kattintsunk a ‘Csatlakozásra’, csak zárjuk be az ablakot.

8., Menjünk a Vezérlőpult\Hálózat és internet\Hálózati kapcsolatok ablakba.

9., Nyomjunk jobb egérgombot a létrehozott ‘First OpenBSD PPTP test’ csatolón, és válasszuk a ‘Tulajdonságok’ menüpontot.

10., Itt az IPv4 protokoll tulajdonságait válasszuk!

11., Ez fontos lépés! Vegyük ki a pipát az ‘Alapértelmezett átjáró használata a távoli hálózaton’ xheckbox-ból. Ha ezt nem tesszük, akkor MINDEN internet forgalmunkat ide fogja irányítani a tunnel (ezt nem akarjuk).

12., OK-zzunk le mindent, majd:

12., Nyomjuk meg a ‘Csatlakozás’ gombot!

13., Kész vagyunk! Ellenőrizzük, mit csináltunk!

Részletek:

Mindeközben a PPTP szerven is megjelent egy interface:

A tesztünk tehát sikeres volt. A PPTP VPN tunnel a két, egymástól független hálózat között felépült. Az ellenoldali node-k látják egymást, elérik egymást.

Összegzés:

Maga a leírás a sok screenshottal talán hosszú volt, de a fentebbi működő konfiguráció életre keltése negyed órán belül történt. A PPTP  gyakran használt protokoll VPN tunnel felépítésére. Vállalati vagy Small Office környezetben, ahol az infrastruktúra és az erre fordítható összeg véges, gyakran találkozhatunk ezzel a megoldással. Egyszerű, megbízható és könnyen is konfigurálható; ehhez hasonló szájbarágós leírás alapján rendszergazdai ismeretek nélkül is könnyen beállítható (itt természetesen kliensoldalról beszélek). A szerveroldalon, mint szintén látható, minimális odafigyeléssel fel lehet építeni a PPTP kiszolgálót. Bízom benne, hogy e leírás segítségére lesz másnak is.

Az előző részben alapszinten megvizsgáltuk, hogyan tudunk az OpenBSD pf segítségével NAT-olni ill. portátirányítást beállítani. A pf tudása azonban tartogat még számunkra érdekes lehetőségeket. Ugyanis ha az előzőekben áttekintett funkciókat alkalmazva már sikerült beállítanunk a más hálózatokra irányuló címfordítást és a csomagszűrő segítségével biztonságossá is tettük ezt, megtehetjük, hogy a rendelkezésre álló sávszélességet minél gazdaságosabban használjuk ki. Erre lesz alkalmas a pf traffic shaper-e, az ALTQ (Alternate Queueing).

OpenBSD tűzfal (pf) – III. rész – traffic shaping (queueing)

Ahhoz, hogy a pf tűzfalunk alkalmas legyen sávszélesség-szabályozásra ill. forgalom priorizálásra, az operációs rendszerünknek ezt kernel szinten is támogatnia kell, ellenkező esetben a pf.conf betöltésekor a queue szabályokhoz érve hibaüzenetet kapunk, hogy nem támogatja ezt kernelünk. A kernel újrafordítására nem fogok most részletesen kitérni, a jelenleg használt OpenBSD 5.1 amúgy is tartalmazza már a megfelelő modulokat, tehát itt csak annyit jegyzek le, mely opciók lennének szükségesek (a kernel konfigok  i386 architektúra esetén a /usr/src/sys/arch/i386/conf/GENERIC  útvonalon találhatók):

options         ALTQ
options         ALTQ_CBQ        # Class Based Queuing (CBQ)
options         ALTQ_RED        # Random Early Detection (RED)
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler (HFSC)
options         ALTQ_PRIQ       # Priority Queuing (PRIQ)
options         ALTQ_NOPCC      # Required for SMP build

Nézzük tehát, hogy a konfigurációban mire van szükségünk ahhoz, hogy megvalósuljon a sávszélesség szabályzás. Szerkesszük meg az /etc/pf.conf filet, és adjuk hozzá a következőket:

Az ALTQ tehát egy mondatban megfogalmazva azt teszi, hogy deklarál egy vagy több queue-t, majd normál, már látott filterszabályokkal ezekre hivatkozik. Nézzük sorra, mely sor vagy sorok mit eredményeznek!

altq on em0 cbq bandwidth 8Mb  queue { www, ftp, other }

Ez a sor aktiválja az ALTQ modult az em0 interfacen-n, Class Based Queue módban. Ez lesz a parent queue.  A maximális sávszélességet, amiből gazdálkodni foguk,  8Mb/s-ben határozza meg, és három child queuet, a www, az ftp, és az other queue nevez meg.

queue www bandwidth 1% priority 2 cbq
queue ftp bandwidth 50Kb  priority 5 cbq
queue other bandwidth 2Mb priority 7 cbq(default)

A fentebbi három sor írja le a child queuekat. A ’www’ nevű használhatja a sávszélesség 1%-át, és 2-es prioritása van. Itt megjegyezhetjük, hogy az ALTQ rendelkezik QoS  (Quality of Service) képességekkel is, tehát a forgalom sávszélességét nemcsak szabályozhatjuk, de priorizálhatjuk is. Ez azt jelenti, hogy a ’www’ queueba eső forgalom ugyan csak a sávszélesség 1%-át fogja használni, de ha egyszerre van jelen más forgalom is, akkor ennek lesz a legnagyobb a prioritása. Az ’ftp’ queue sávszélessége abszolút módon van megadva, ez 50Kb/s.  Az ’other’ queue, ami a mi esetükben minden más, az előző kettőtől eltérő forgalmat jelenti majd, 2Mb/s sávszélességet kap. Fontos, hogy egy default queue-nak léteznie kell.

pass out quick on em0 inet proto tcp to port { 20, 21 } flags any  queue ftp keep state
pass out quick on em0 inet proto tcp to port 80 flags any  queue www keep state
pass out on em0 all queue other keep state

Az utolsó három sor a létrehozott queuekat párosítja a megfelelő forgalommal. Láthatjuk, hogy ezek mezei csomagszűrő szabályok,  a queue <queuenév> résszel  kiegészítve. Fontos még benne a ’quick’ kulcsszó, hiszen, a pf csomagszűrőről szóló írásban már láthattuk, hogy enélkül itt a csomag nem akadna bele az első sorba, hanem végigmenne a további kettőn, és az utolsó szabály illeszkedne rá, azaz MINDEN csomag az ’other’ nevű queuera illeszkedne.

Az általános szintaktika az ’altq’ –ra (a normál betűsek a változók, a dőlt betűsek pedig ezek értékei):

altq on interface scheduler bandwidth bw qlimit qlim tbrsize size queue { queue_list }

Az általános szintaktika a ’queue’ –ra:

queue name [on interface] bandwidth bw [priority pri] [qlimit qlim] scheduler ( sched_options ) { queue_list }

Hogyan tesztelhetjük, illetve nézhetjük meg, hogy a megfelelő forgalom valóban az általunk kívánt módon „akad-e” bele a szabályokba? Én egy sima http alapú downloaddal teszteltem, kellő méretű filet választva a letöltéshez, hogy meg tudjuk figyelni, valóban leesik-e a letöltés sebessége:

# lynx http://letoltes.szoftverbazis.hu/6f2b2ff4c9d35d01eda36b0db0864cf65de42943/4fee511c/alien-arena-2008-v7-21-VS11/alienarena-7_53-win20111222.exe

A következőt láttam a lynx felületén:

Kijelenthetjük tehát, hogy sikeres volt ennek az egyébként nagyon szimpla traffic shapernek a beállítása. Tekintsük meg kicsit szemléletesebb módon, hogyan néz ki a queue-tree. Ezt az operációs rendszer ’systat’ parancsával tehetjük meg – többek közt!

# systat queues

Itt jól látható, hogyan épül fel a queue-tree. Ennél is részletesebb, szintén valós idejű statisztikákat a pf saját módszerével is láthatunk:

# pfctl -sq -vv

Itt láthatjuk queue-kat és azok részletes statisztikáit pf módra.

Összegzés

A pf ALTQ  frameworkje egy szerintem igazán kiváló és logikus szabályokra épülő traffic shaper. Természetesen, ízlés szerint variálhatjuk a queue-k számát, típusát, a hozzájuk rendelt sávszélességet. Több interface-szel rendelkező rendszerek esetén támogatja a interface-k bridge módban történő kezelését is, lehetővé téve ezzel a transzparens traffic shaper kialakítását is.

Az eddigi FreeBSD-s írások után következzen ugyanebben a témában egy kicsit izgalmasabb  írás, szóljon pedig ez a virtualizációról. Napjainkban már több operációs rendszer támogatja a virtualizációt natívan, különböző formában, különböző megoldásokkal, a terminológia is különböző lehet. Gondolhatunk itt arra, amit Solaris alatt zónának neveznek, AIX platformon LPAR, Linux-oknál chroot. Nagyon kíváncsi voltam arra, hogy BSD (ebben az esetben FreeBSD) fronton mik a lehetőségek, ha ilyen igényeim vannak. Nos, örömömre szolgált, hogy itt sem találkoztam elmaradással. A FreeBSD-nek megvan a megoldása a virtualizációra, amit itt jail-nek nevezünk, és a legegyszerűbb módon az ez-jail nevű porttal menedzselhetjük.

FreeBSD virtualizáció (jail) az ezjail használatával

Mi az a jail?

A BSD-szerű operációs rendszerekben már a 4.2BSD óta megtalálható volt a chroot. Ez lehetővé tette adott programok számára a gyökérkönyvtár megváltoztatását (saját könyvtárstruktúrájuk volt). Az adott program nem fért hozzá a chroot-olt könyvtáron kívüli részhez, ez biztonságossá tette ezt. Az idők folyamán azonban biztonsági réseket fedeztek fel, egyre több kiskaput találtak ezek kijátszására, és nem utolsósorban a hangolásra sem nagyon volt lehetőség. Ennek kiküszöbölésére született a jail alrendszer, mely az előbb felsoroltakon kívül már kibővítette a lehetőségeket, pl. a hálózati alrendszer és felhasználók jailben történő kezelésére, ezenkívül a finomhangolhatósága is jóval kiterjedtebb lett. Ez azonban azt is magával vonta, hogy a jailek telepítése, beállítása, konfigurációja meglehetősen nehézkessé vált. Ezt sikerült megkönnyíteni az ez-jail nevű porttal (igazából ez egy script-szerű tool), mely ezt nagyon egyszerűvé teszi.

Nézzük meg a FreeBSD ez-jail-lel installált jailjeinek előnyeit:

– tárhely-megtakarítás azáltal, hogy egyetlen alaprendszer bináris szettet használ az összes jail
– updatelhető az összes jail egy base-directoryn belül
– mivel a base system (binárisok) read-only módban vannak csatolva, ez a betörő dolgát nehezíti (ellehetetleníti), pl. rootkitek esetén
– az ezjail sh scriptként van írva, így nem szükséges bármilyen extra shell telepítése a host-rendszeren
– attach-detach, backup-restore megoldott

és hátrányait:

– közös binárisok (külön nem upgradelhető jailek)
– jelenleg körülményes, ill. helyenként nem megoldott a jailek erőforrás menedzsmentje
– az előbbi miatt amennyiben több  jailt akarunk futtatni, a CPU kiosztás csak affinity alapján lehetséges
– egy base-jailre mindenképp szükség van, ez plusz helyet foglal (azonban ez a továbbiakban templateként használható, tehát van pozitívuma is)

Az első lépések:

Tesztrendszerünk egy FreeBSD, annak is 9.0-ás verziója, friss portfával, egy darab em0-ra hallgató hálózati csatolóval. A jailek base-directoryja nagyon szimplán a /jails lesz, ez azonban akár lehet külön filerendszeren is természetesen. Első lépésként telepítenünk kell az ez-jail-t.

# cd /usr/ports/sysutils/ezjail
# make install

Alapesetben maga telepítés kész is. Tegyük be az /etc/rc.conf-ba is, hogy elinduljon rendszerinduláskor ( ezjail_enable=”YES” ). Szükségünk van még az ezjail konfigurációs fájljának editálására, ez igazából csak egyszer, most az elején szükségeltetik.

Én csak a jail-ek basedir-jét változtattam, semmi egyebet. Ha ez megtörtént, akkor készen állunk arra, hogy installáljuk a base-jailt. Erre, normál esetben, egyetlen egyszer van szükség a jail használatánál, többet nem.

# ezjail-admin install

Érdekes dolgokat figyelhetünk most meg:

Látjuk, hogy az install a FreeBSD ftp helyéről letölti a jelenlegi verziónknak megfelelő alaprendszer csomagját, és ezt telepíti (mintegy másodszor), csak épp most a jail basedir alá a basejail könyvtárba. A basejail installja valami hasonló módon ér véget:

A basejailünk készen van. Ezzel azonban még nem nyertük meg a lottó 5-öst, hiszen nincs egy darab virtuális rendszerünk sem, éppen csak felkészítettük rendszerünket arra, hogy létrehozhassuk a valóban működő jaileket. Érdekes lesz megfigyelni, hogy mennyire hasonlít ennek az egésznek a folyamata és az eredménye a Solaris operációs rendszer zóna-szemléletére (annyira azért nem kifinomult, de ki tudja, talán a jövőben). No, hát kreáljuk meg az első jailünket.

Ehhez létre kell hozni a host system-en az IP címet vagy címeket aliasként, amin majd az újonnan létrehozott jailünk figyelni fog. Fontos megjegyezni, hogy ez azt is jelenti, hogy az olyan szolgáltatásokat, amik minden IP-n figyelnek (syslogd például), a host systemen át kell konfigurálni, hogy csak a host IP-n figyeljenek (értelemszerűen a jailen ezt NEM kell megtenni, hiszen ott csak egy IP-n – amit osztottunk- fog figyelni).

# ipconfig em0 192.168.55.17 alias
# ezjail-admin create -r testjail testjail 192.168.55.17

Majd a vége valami hasonló lesz:

Látjuk is a figyelmeztetést, éppen az említett syslogd-ről, mely minden IP-n figyel, ezt leszámítva sikeres volt a jail létrehozása. Nézzük meg, a meglevő és újonnan installált jaileket, erre is van több mód:

Megnézhetjük az ezjail paranccsal:

# ezjail-admin list

Illetve a jls paranccsal:

Látjuk, a kettő kimenete, más elrendezésben, de megegyezik. Az  STA oszlop alatti DR státusz mutatja, hogy D(irectory tree based jailünk) van és R(unning), tehát fut.

Próbáljuk most ide beloginolni:

# ezjail-admin console testjail

Sikeres volt tehát az installunk. A jail fut és igény szerint integrálhatóak bele az igényeknek megfelelő alkalmazások (web, mail, stb. szerverek).

A jail vagy jailek leállítása és indítása a következőképpen történik:

# ezjail-admin stop testjail
# ezjail-admin start testjail

Finomhangolás:

A jailek beállításainak finomhangolását túlnyomórészt sysctl változókkal végezhetjük el. A sysctl-en belül egy speciális részfában találhatunk erre alkalmas beállításokat: ez a a FreeBSD rendszermag opciói között megtalálható security.jail.*. Az alábbi képen ezek láthatóak kigyűjtve:

Összegzés:

Annak ellenére, hogy bármelyik BSD rendszer támogatja a leírtakban szereplő lehetőségeket, legkönnyebben nekem FreeBSD alatt sikerült működésre bírnom – itt viszont rövid idő alatt (Open- és NetBSD esetében nem fordult le probléma nélkül, de ez lehetett az én figyelmetlenségem miatt is). Engem ez a  virtualizációs megvalósítás leginkább a Solaris zónáira emlékeztetett, ahogy említettem. Vannak még korlátok, és megoldásra váró problémák a BSD virtualizációban, azonban a jelenlegi eredmények alapján is ígéretesnek és használhatónak tűnik a BSD jail.

Az OpenBSD pf először a 3.0-ás kiadásban mutatkozott be először, miután az addig használt IPFilter-t (ipf) eltávolították belőle. Mivel az OpenBSD talán leggyakoribb “felhasználási területe” a firewalling, így a csomagszűrő nélkül maradt OS-be nagyon hamar integrálták a már létező pf-et (említsük meg a fejlesztő nevét, megérdemli: Daniel Hartmeier), és ez folyamatos fejlesztése mellett a mai napig is szerves részét képezi az OpenBSD-nek. A pf-hez szorosan kötődik a CARP redundancia protokoll illetve a pfsync, melynek segítségével több gépből álló,  állapottartó redundáns tűzfal készíthető, ahol a tűzfal szabályok a gépek között egymással szinkronban tarthatók.

OpenBSD tűzfal (pf) – I. rész – alapok és a szűrés

Vegyük sorra néhány pontban, milyen lehetőségei vannak a pf-nek:

• csomagszűrés
• sávszélesség szabályzás (traffic shape)
• IP groupok létrehozása és ezek használata a pf szabályokban
• makrózás
• hálózati címfordítás (NAT)
• szűrés op. rendszer ujjlenyomat alapján (OS fingerprint)
• scrubbing (csomagok normalizálása)
• anchor-ok (a szabályok egy halmazának külön kezelése)
• átirányítás (redirection)
• stateful packet inspection (állapottartó tűzfal)
• naplózás (logging)
• loadbalancing

Most, hogy áttekintettük, mire is használható a pf, vágjunk is bele, konkrét példákon keresztül. Előrebocsátom: nem szeretnék egy új, átfogalmazott pf dokumentációt írni; ennek a terjedelme sok-sok oldalra rúgna, és ezt egyébként is megtették már a fejlesztők, akik kiváló dokumentációt írtak a pf-hez, ezt itt és most ide is linkelem, annak, aki szeretne mélyebben belemerülni. Nem utolsósorban én is fogok az eredeti angolból magyarra fordítva részeket kiemelni.

A pf alapból engedélyezett a rendszer indulásakor. Amennyiben szeretnénk tiltani, adjuk (ill. állítsuk) az /etc/rc.conf fileban a pf=YES értékét NO-ra. Továbbá tilthatjuk vagy engedélyezhetjük a következő indulásig kézzel:

# pfctl -d
# pfctl -e

A pf fő konfigurációs fájlja a /etc/pf.conf. Ebben vannak általában a szabályok, esetenként hivatkozások más fájlokra, melyek pl. IP csoportokat tartalmaznak.

A leggyakrabban használt parancsok:

# pfctl -f /etc/pf.conf     Betölti a pf.conf-ban szereplő szabályokat
# pfctl -nf /etc/pf.conf    Parse-olja, de nem tölti be a szabályokat
# pfctl -Fa                     Kiűrít minden a futó konfigból
# pfctl -Fa -f /etc/pf.conf Flush, majd teljes szabályrendszer újratöltése
# pfctl -sr                 Megmutatja a futó tűzfalszabályokat
# pfctl -ss                 Megmutatja a futó állapottáblát
# pfctl -si                 Megmutatja a szűrő statisztikáit
# pfctl -sa                 Megmutat minden létező változót a szűrőről

Listák és makrók:

Ahelyett, hogy pl. minden forrás IP címre külön szabályt hoznánk létre, használhatunk listákat. A szabályok betöltésekor a listában szereplő változókra automatikusan fog szabályt létrehozni a pf. Például:

Ez a két sor egy sorban is leírható a listák használatával.

block out on em0 from 192.168.0.1 to any
block out on em0 from 10.5.32.6 to any

Így:

block out on em0 from { 192.168.0.1, 10.5.32.6 } to any

Létrehozhatunk elnevezett listát is, amire aztán hivakozunk; ilyenformán:

untrusted = “{ 192.168.1.2 192.168.5.36 }”
block in inet proto tcp from { $untrusted } to port 23

A fenti két sor az ‘untrusted’ listában szereplő IP címekről jövő kéréseket eldobja, amennyiben ez a tcp/23-as (telnet) portra érkezik.

Makrók:

A makrók olyan változók, melyek tartalmazhatnak IP-ket, interfész neveket, portokat, stb. Nagyban megkönnyítik és átláthatóbbá teszik a tűzfalszabályok létrehozását ill. a szabályokat magukat.

external_if = “em0”
block in on $external_if from any to any

vagy:

enemies = “{ 192.168.1.1, 10.0.2.5, 192.168.43.53 }”
pass in inet proto tcp from $enemies to any

Ez, ha lekérdezzük a futó szabályokat, így fog kinézni:

Táblák:

A táblák, szemben a listákkal, csak IPv4 ill. IPv6 címek vagy hálózatok tárolására alkalmasak, viszont -ellentétben a listákkal- ezek beolvasása még nagyszámú, többszáz soros lista esetén is kevéssé processzor és memóriaigényes, mint a listáké.

Két fajtájuk van:

const – itt a tábla tartalma nem változtatható, ha egyszer létre lett hozva
persist – ezt a kernel memóriába teszi, akkor is, ha nincs rá vonatkozó szabály. Enélkül az opció nélkül ‘flush’ esetén kiürül a tábla is.

Nézzünk példát mindegyikre és írjuk hozzá a /etc/pf.conf-hoz a következőket:

table <goodguys> { 192.0.2.0/24 }
table <rfc1918> const { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
table <spammers> persist

block in on em0 from {  <spammers> } to any
pass  in on em0 from <goodguys> to any

table <spammers> persist file “/etc/spammers.table”

block in on em0 from <spammers> to any

Nézzük most a futó szabályokat a tűzfal konfig újratöltése után!

Tehát: a spammers táblában szereplő IP blokkokból a 25-ös portunkra érkező forgalom ki van tiltva (innentől Korea egy jó részéből nem fognak spamek érkezni a mailszerverünkre, hurrá 🙂 ) Ezenkívűl a goodguys táblában szereplő hálózatból mindenkit beengedünk mindenhova. Az rfc1918 táblára pedig nincs illeszkedő szabály, így azt nem is töltötte be. Ilyen egyszerű ez.

Megjegyezhetjük, hogy meglevő táblához adhatunk vagy törölhetünk bejegyzést az alábbi módon is:

# pfctl -t spammers -T add 218.70.0.0/16
# pfctl -t spammers -T delete 218.70.0.0/16

Ennyit most a táblákról.

Csomagszűrés:

Ha az erre vonatkozó összes példát szeretnénk végignézni, az meglehetősen hosszú cikket szülne, ezért megpróbálom kicsit általánosabban leírni. A szintakszis így néz ki:

action [direction] [log] [quick] [on interface] [af] [proto protocol] [from src_addr [port src_port]] [to dst_addr [port dst_port]] [flags tcp_flags] [state]

Ez gondolom, így kicsit ijesztő, de helyettesítsük be a változókat egy konkrét értékkel, és mindjárt a helyükre kerülnek a dolgok:

block in log quick on em0 inet proto tcp from 1.1.1.1 port 1 to 2.2.2.2 port 80 flags any no state

Fordítsuk le pf-ről magyarra 🙂

Minden olyan tcp csomag, mely az em0 interfacen jön be az 1.1.1.1-es IP 1-es portjáról és a 2.2.2.2-es IP 80 portjára érkezik, tekintet nélkül a flagekre és az állapotra, naplózásra  és eldobásra kerül, függetlenül attól, hogy van-e más illeszkedő szabály.

Az implicit tiltás:

block in  all
block out all

A quick opció:

Nos, ez egy nagyon fontos dolog a pf szabályokban. Ugyanis alapvetően a pf szekvenciálisan, fentről lefelé kezeli a tűzfal szabálysorait. Amennyiben több szabálysor van, amely egy adott forrás IP-re illeszkedik pl. , akkor mindkettőt feldolgozza és az utolsó győz alapon a második fog érvényesülni. Ennek a viselkedésnek a megváltoztatására való a ‘quick ‘. Amennyiben ezt egy szabálysorba beletesszük, akkor illeszkedés esetén semmit nem vizsgál tovább, ezt a sort fogja alkalmazni. Magyarán, az utolsó illeszkedő szabály győz helyett az első illeszkedő szabály győz elve fog érvényesülni.

Monitorozás:

Időközben kaptam egy kérdést, hogy vajon milyen a monitorozhatósága a tűzfalnak? Ez teljesen jogos kérdés, és a válasz is adott: nagyon jól követhető az egyes szabályok használtsága, ráadásul többféle módon is. Nézzük meg ezeket dióhéjban:

1., A pf saját statisztikái:

# pfctl -v -s r

2., A másik megoldás a tcpdump használata, bár ez inkább debugolásnál hasznos a pf esetében:

# tcpdump -i em0 -n -v

3., Külső alkalmazás: a pftop (http://www.eee.metu.edu.tr/~canacar/pftop/ )

4., Grafikus módon: pfstat (http://www.benzedrine.cx/pfstat.html )

Hát, azt hiszem, lehet válogatni 🙂 A külső alkalmazások elérhetők a port-treeben, így tulajdonképpen ezek is nagyon könnyen telepíthetőek.

Összegzés:

Ennek a cikknek a végigolvasása után remélhetőleg sikerült megértened a pf alapjait. Ebből és majd az ezután következőkből látjuk, hogy egy nagyon jól átgondolt kialakítású, logikusan, következetesen és rugalmasan konfigurálható tűzfal alkalmazásról van szó, mely igazából több is, mint tűzfal, hiszen NAT és traffic shape funkciókkal is rendelkezik.