V pretekli številki smo spoznali nekatere glavne značilnosti gradnikov usmerjevalnikov/požarnih zidov, ki jih lahko sestavimo sami. Natančneje smo spoznali pomen posameznih, na prvi pogled »enakih« komponent, in opozorili na pomembne razlike, ki lahko bistveno vplivajo na delovanje. Spoznali smo tudi prednosti in slabosti določenih gradnikov, ki se lahko med seboj razlikujejo do te mere (na primer trdi disk, bliskovni pomnilnik), da so potrebne določene spremembe programske opreme. Opozorili smo tudi na določene omejitve in prednosti strojne opreme (na primer ustreznih lahkih odjemalcev), ki lahko »govorijo« v prid določene rešitve, ter opozorili na določene marketinške zvijače, ki se od pravih rešitev bistveno razlikujejo in lahko vplivajo na varnost celotnega sistema. Poudarili smo tudi potrebe in argumente, zaradi katerih smo se odločili za pfSense (http://www.pfsense.org).

PREPROSTO UČITI SE

Omenili smo že, da se v postopku namestitve pfSensa vnesejo osnovni konfiguracijski parametri, ki nam pozneje omogočijo dostop prek grafičnega vmesnika v okolju spletnega brskalnika. Dostop prek ukazne vrstice pa ne glede na način dostopa (na primer prek serijskega vmesnika, lokalnega dostopa, SSH-povezave …) ponuja določene koristne pripomočke. Po zagonu se nam na zaslonu izpišejo naslednje možnosti:

0) Logout (velja le v primeru SSH-povezave) – odjava
1) Assign Interfaces – definiranje vmesnikov
2) Set Interface(s)IP address – določitev IP-naslovov
3) Reset webConfigurator password – ponastavitev gesla za dostop prek GUI
4) Reset to factory defaults – vrnitev na privzete nastavitve
5) Reboot system
6) Halt system
7) Ping host – ping želenega naslova
8) Shell – sistemska lupina
9) pfTop – izpis trenutnih stanj (packet filter)
10) Filter Logs (dnevnik – tcpdump)
11) Restart webConfigurator
12) pfSense Developer Shell
13) Upgrade from console – nadgradnja sistema
14) Enable Secure Shell (sshd) – vklop/izklop funkcionalnosti SSH-strežnika
15) Restore recent configuration – obnovitev sistema iz varnostne kopije
99) Install pfSense to a hard drive

Po vnosu parametrov, ki omogočajo oddaljen dostop do usmerjevalnika, lahko konfiguracijo nadaljujemo s pomočjo čarovnika v okolju grafičnega vmesnika. Že v pretekli številki smo omenili, da bomo tretji fizični vmesnik uporabljali glede na trenuten namen, zato uporabimo kar oznako OPT (Optional), ki jo lahko po potrebi tudi spremenimo (na primer DMZ).

Na tem mestu opozorimo še na nekaj pomembnih dejstev. PfSense podpira uporabo Ipv6, a je uporaba privzeto onemogočena. Če to funkcionalnost potrebujemo, moramo omogočiti tudi NAT enkapsulacijo IPv6 paketov. Grafični vmesnik v okolju spletnega brskalnika uporablja svoj certifikat (self signed), s stališča varnosti pa je smiselna uporaba lastnega certifikata in ključa, ki ju lahko uvozimo.

Komercialni usmerjevalniki, namenjeni domači uporabi, ponujajo omejen nabor prilagoditev. S pomočjo pfSensa pa lahko sistem »uglasimo« na različne načine »delovanja« – normalni, sistem z večjimi časovnimi zamiki (na primer satelitske povezave), agresivni (zahteva več procesorske moči in pomnilnika), konservativen (poskuša se izogniti nepotrebnim prekinjanjem povezav). Če zaradi nepazljivosti izključimo funkcionalnost požarnega zidu, se pfSense spremeni v usmerjevalnik z izključeno funkcionalnostjo translacije naslovov (NAT).

BREZ PANIKE

Pomembno je, da lahko s pfSensom brez strahu eksperimentiramo (dokler to ni produkcijska naprava!), saj pfSense shranjuje vse nastavitve v obliki XML konfiguracijske datoteke. V njej so shranjene vse sistemske nastavitve skupaj z nastavitvami nameščenih paketov. Datoteko najdemo v imeniku …/conf/config.xml (poiščemo jo s pomočjo ukaznega niza find / | grep /conf/config.xml). Varnostno kopijo lahko izdelamo v okolju grafičnega vmesnika s pomočjo klikov na Diagnostics – Backup/Restore. V polju Backup area izberemo možnost ALL. Naprednejšo možnost samodejnega kopiranja pa lahko izvedemo s pomočjo paketa AutoConfigBackup. Shranjene nastavitve lahko preprosto prenesemo s pomočjo WinSCP oziroma kopiranja prek SSH. V primeru morebitnih težav sistem obnovimo na podoben način (Diagnostics – Backup/Restore), le da v tem primeru izberemo datoteko, v kateri so shranjene nastavitve. S stališča diagnosticiranja napak je lahko zelo uporabna možnost obnovitve podatkov iz konfiguracijske zgodovine (Config History), v kateri imamo zadnjih trideset konfiguracij – skupaj s kratkim opisom spremembe in kdaj je bila sprememba izvedena. Čeprav ni vedno zahtevano, je smiselno (če je le mogoče), da se po »novi« konfiguracij izvede ponoven zagon sistema (Diagnostics – Reboot (System) – Yes). V primeru embedded sistemov pogosto poskušamo izvesti obnovitev sistema s pomočjo podatkov na USB-ključku ali zunanjem trdem disku (ki ga priključimo prek USB-vmesnika). Da podatke lahko prekopiramo, moramo to napravo najprej priključiti (mount-t ufs …), nato pa konfiguracijsko datoteko config.xml prekopiramo v imenik …/conf.

POŽARNI ZID

Ena glavnih funkcionalnosti, ki jo bomo uporabili, je požarni zid oziroma možnost filtriranja prometa. PfSense spada med napredne, tako imenovane stateful požarne zidove, in dovoljuje le promet na vmesnikih, na katerih se promet ustvarja. Definirana pravila delovanja najdemo v zavihku Firewall – Rules, v njih pa najdemo »definicijo«, kako naj se obravnava določen tip prometa. Ta pravila lahko definiramo ročno ali pa se dodajo samodejno z želeno funkcionalnostjo prek menijev. Za vsa definirana pravila, ki so aktivna, velja, da se pravila preverijo »po vrstnem redu« od zgoraj navzdol, kar pomeni, da se definirana akcija izvede, ko je prvič izpolnjen definiran pogoj, zato je jasno, da bolj »ohlapna« pravila definiramo na začetku.

Naj na tem mestu opozorimo na dejstvo, da večina komercialnih usmerjevalnikov, namenjenih domači uporabi, privzeto dovoljuje ves promet iz lokalnega omrežja v smeri proti internetu in brez ustreznih posegov onemogoča dostop do računalnikov (običajno prek mehanizma NAT) iz interneta v lokalno omrežje. Dejstvo se na prvi pogled ne zdi nič nenavadnega, resnejši razmislek pa odpira vprašanje, ali je res potrebno in sprejemljivo, da brez omejitev dovolimo ves promet iz omrežja (to je lahko tudi posledica zlonamerne programske opreme). Odgovor je brez dvoma negativen, zato pravila postavimo tako, da omrežje zapustil le promet, za katerega je to nujno. Blokada oziroma odkritje nepotrebnega odhodnega prometa lahko kaže na okužbo računalnika ali odtekanje podatkov v obliki neobičajno velike količine prometa, zmanjšuje možnost IP spoofinga, onemogoča uporabo aplikacij, ki jih ne dovolimo, ter preprečuje »odtekanje« informacij prek protokolov (na primer SNMP), ki zbirajo določene informacije.

Takšen pristop pa za marsikoga lahko pomeni težavo, saj je v tem primeru nujno dobro poznati promet. Dobro izhodišče je lahko zahteva, da dovolimo HTTP- in HTTPS-promet na vse naslove (vrata 80 in 443), SMTP-promet (do poštnega strežnika, ki ga uporabljamo) prek vrat 25 ter promet do znanih DNS-strežnikov (vrata 53). Za odkrivanje morebitnega dodatnega prometa lahko izkoristimo možnost beleženja prometa v dnevniške datoteke.

Promet, ki ga želimo onemogočiti, lahko obravnavamo na dva načina. Prvi je možnost blokiranja (block), drugi pa zavračanja (reject). V prvem primeru se paket brez povratne informacije zavrže, v drugem primeru je poslana ustrezna povratna informacija. Na WAN-povezavi je smiselno uporabiti mehanizem blokiranja.
Če se želimo izogniti nepotrebnim težavam, je dobro, da sledimo nekoliko bolj strogi politiki in se držimo načela, da je prepovedano vse, kar ni dovoljeno. To v praksi pomeni, da bomo tudi na našem požarnem zidu sledili vodilu – default deny. Kot že omenjeno, dovolimo le minimum nujno potrebnega prometa, zato če je le mogoče, pozabite pravilo alow all. Drugo pomembno načelo je »preprosto in enostavno«, saj se tako lažje izognemo nepotrebnim napakam, kot za vse podobne sisteme pa je priporočljivo, da jih občasno preverimo in preverimo, ali so vsa dovoljenja še vedno potrebna. Tak poseg je nujen, ko sistem »podedujemo«, in takoj ko je mogoče, preverimo, da ni nepotrebnih varnostnih lukenj.

V primeru privzetega pravila »deny« se ves promet, ki je blokiran z interneta, beleži. Če se vam zdi, da je zabeleženega preveč tovrstnega prometa, lahko svoje pravilo dodamo v zavihku Status – System Logs – Firewall.

Začasno lahko določeno pravilo (Rule) onemogočimo, ne da bi ga odstranili. To storimo tako, da pravilo označimo (klik na kvadratek), kar se pokaže v spremembi barve. Enako pravilo tudi aktiviramo (prazen kvadratek), kar se kaže v ponovni spremembi barve. Ena od zanimivejših možnosti je možnost filtriranja glede na OS, kar se doseže s pomočjo paketov TCP SYN. Tu so še možnosti različnih omejitev (maksimalnega števila aktivnih povezav, maksimalnega števila novih povezav v sekundi …).

Posameznemu pravilu lahko dodamo tudi časovne pogoje – časovno obdobje za dneve in ure, ko velja določeno pravilo. Najprej definiramo ustrezne časovne termine (Firewall – Schedules + Adding a Time Range), določimo še ime tega časovnega termina, ki mu sledi definicija želenih časovnih parametrov. Šele ko je ustrezen »urnik« definiran, ga lahko uporabljamo v pravilih požarnega zidu. Tako pravilo lahko recimo hitro uporabimo za časovno omejevanje uporabnikov (beri: najstnikov). Pravila vedno določimo le za dohodni promet, ki kreira stanje, promet v povratni smeri pa je dovoljen samodejno (za to ni potreben dodatni posebni »filter« na WAN). Običajno za »prehod« največkrat uporabimo mehanizem NAT, pfSense pa podpira tudi možnost neposredne translacije (mapiranje 1 : 1) več javnih IP-naslovov, drugi pa so dostopni prek mehanizma port forward.

SIMON PRAVI …

Pravila definiramo v že omenjenem zavihku Firewall – Rules. Izberemo zavihek vmesnika, ki mu želimo dodati določeno pravilo (LAN oziroma WAN). Obstoječe pravilo lahko spremenimo (gumb »e«) ali izbrišemo (gumb »x«), lahko dodamo novo pravilo (gumb »+«) ali spremenimo vrstni red (gumb s trikotnikom).

PfSense omogoča tudi uporabo različnih psevdonimov (alias), ki lahko označujejo skupino IP-naslovov (host alias), skupino omrežij (newtwork alias) oziroma skupino vrat (port alias). Psevdonime lahko uporabljamo v vseh poljih grafičnega vmesnika z rdeče obarvanim ozadjem, paziti pa moramo na »velikost« uporabljenih znakov v imenu (saj psevdonim mojmikro ni enak psevdonimu MojMikro). Če nas v določenem pravilu zanima, kaj se skriva za psevdonimom, lahko »vsebino« ugotovimo tako, da se z miško postavimo na psevdonim. Novejše različice pfSensa podpirajo prepletanje različnih psevdonimov.

S stališča primerjave pfSensa z usmerjevalniki, ki so namenjeni domači uporabi ali manjšemu podjetju (oziroma domači pisarni), so zanimive še nekatere druge možnosti. Ena od njih je možnost funkcionalnosti Multi WAN, ki omogoča možnost uporabe več internetnih povezav z namenom povečevanja zanesljivosti povezave do interneta oziroma združevanja kapacitet z namenom povečevanja prepustnosti. V primeru funkcionalnosti Multi WAN na podoben način konfiguriramo vmesnike, ki jih želimo uporabiti, zavedati pa se moramo, da vse aplikacije ne obvladajo tovrstnega načina delovanja (podobno velja za mehanizem deljenja obremenitve – load balancing). Funkcionalnost detekcije na tovrstni povezavi temelji na kreiranju skupine prehodov (gateway pool), katerega dostopnost preizkušamo s pomočjo icmp in tako ugotovimo morebiten izpad povezave WAN. Morda se komu zdi za domače okolje tovrstna funkcionalnost nepotrebna, dejstvo pa je, da lahko tovrstno funkcionalnost zagotovimo že za dodatni strošek nekaj evrov mesečno. V primeru solidnih povezav so rezultati lahko zavidljivi. V našem primeru je ob izpadu pretočni video deloval brez težav. Še največja težava pa je, da v primeru tovrstne konfiguracije uporabnik včasih sploh ne ve, da je prišlo do izpada ene od povezav (če že običajno opazi le počasnejše delovanje).

Moj mikro, julij avgust 2014 | Marko Koblar