Klassische Firewalls

Der Ein­satz von Fire­walls zum Schutz ihrer Netz­wer­ke ist heu­te unab­ding­bar. Nach­fol­gend ein Blick auf klas­si­sche Fire­walls, die heu­te zum Schutz von Netz­wer­ken oder Ser­ver ein­ge­setzt wer­den. Sie lie­fern einen Grund­schutz, der sich auf die Ver­bin­dun­gen bezieht. Über­tra­ge­ne Inhal­te wer­den von ihnen meist nicht tie­fer­ge­hend untersucht.

Neben der hier beschrie­be­nen stren­gen Klas­si­fi­zie­rung klas­si­scher Fire­walls gibt es häu­fig Misch­for­men, bei denen unter­schied­li­che Prin­zi­pi­en kom­bi­niert zur Erhö­hung der Sicher­heit ein­ge­setzt werden.

Paket­fil­ter

(Sta­ti­sche) Paket­fil­ter sind heu­te meist auf Rou­tern imple­men­tiert. Sie fil­tern nach den IP-Adres­sen, dem IP-Pro­to­koll und, soweit TCP oder UDP zum Ein­satz kom­men, auch nach den Ports. Hier­durch besteht grund­sätz­lich die Opti­on, spe­zi­el­le Ports für Appli­ka­tio­nen frei­zu­schal­ten. Sofern die Fil­te­rung TCP betrifft, ist heu­te zusätz­lich eine Fil­te­rung nach den TCP-Flags inner­halb eines Pake­tes möglich.

Vor­teil sol­cher Lösun­gen ist, dass sie von der Kos­ten­sei­te her güns­tig sind. Die Fil­ter, meist ACL (Access Con­trol List) genannt, müs­sen ledig­lich kon­fi­gu­riert wer­den. Per­for­mance ist für sol­che Fil­ter nur in den sel­tens­ten Fäl­len ein Pro­blem, da Rou­ter für die Wei­ter­lei­tung von Pake­ten opti­miert sind. Die gute Trans­pa­renz von Paket­fil­tern setzt weder auf der Sei­te der Benut­zer, noch auf Sei­ten der Ser­ver irgend­ei­ne spe­zi­el­le Kon­fi­gu­ra­ti­on oder gar Zusatz­pro­gram­me voraus.

Trotz­dem haben die­se Lösun­gen auch Nach­tei­le. Rou­ter kön­nen prin­zip­be­dingt kei­ne Daten der Appli­ka­ti­ons­schicht unter­su­chen. Inso­fern bie­ten sie hier kei­nen Schutz. Eine Kon­trol­le, ob eine (ver­meint­lich) bestehen­de Ver­bin­dung wirk­lich kor­rekt auf­ge­baut wor­den ist, fin­det nicht statt. Eben­so sind, zum Teil stark abhän­gig von der Kon­fi­gu­ra­ti­on, auf der Netz­werk- und Trans­port­ebe­ne unter­schied­li­che Angrif­fe mög­lich — durch die der Fil­ter­me­cha­nis­mus teil­wei­se zu umge­hen ist. Sofern kom­ple­xe­re Pro­to­kol­le wie z.B. FTP oder VoIP zum Ein­satz kom­men, müs­sen die Fil­ter teil­wei­se sehr weit geöff­net wer­den, so dass hier kaum noch ein Schutz für die inter­nen Sys­te­me vor­han­den ist.

Fazit:
Ergän­zend zu einer “rich­ti­gen” Fire­wall ist der Ein­satz von sta­ti­schen Paket­fil­tern eben­so sinn­voll wie im Intra­net, wo die Unter­schie­de des Ver­trau­ens nicht so gra­vie­rend sind, wie gegen­über dem Internet.

Sta­teful Inspection

Oft wird die­se Art der Fil­te­rung auch als “dyna­mi­sche Paket­fil­te­rung” bezeich­net. Die Fil­te­rung der Daten fin­det im Ker­nel statt und das wesent­li­che Merk­mal ist, dass dyna­mi­sche Tabel­len geführt wer­den. Die­se wer­den auch als “Sta­te Tables” bezeich­net. In die­sen Tabel­len wer­den Infor­ma­tio­nen über den Zustand von bestehen­den und erwar­te­ten Ver­bin­dun­gen (z.B. FTP-DATA) gespei­chert. Im Gegen­satz zu ein­fa­chen Paket­fil­tern wird zur Ent­schei­dung, ob ein Paket durch­ge­las­sen wird, nicht nur das Paket für sich allein betrach­tet, son­dern die Ver­bin­dung als Gan­zes mit ihrer Vorgeschichte.

Vor­teil die­ser Lösung ist die eigent­lich voll­stän­di­ge Kon­trol­le über die ein­zel­nen Ver­bin­dun­gen, wobei inzwi­schen die­se Art der Fil­te­rung teil­wei­se auch für UDP oder ICMP mög­lich ist. Da die Fil­te­rung bereits im Ker­nel geschieht, ist auch hier kaum ein Ver­lust bei der Per­for­mance zu erwar­ten. Bei den meis­ten Her­stel­lern wer­den die für Paket­fil­ter typi­schen Angrif­fe bereits im Vor­feld ver­ei­telt. Zusätz­lich sind Fire­walls mit die­sem Fil­ter­me­cha­nis­mus eben­so wie sta­ti­sche Paket­fil­ter für den Benut­zer voll­stän­dig trans­pa­rent konfigurierbar.

Die mög­li­chen Nach­tei­le der (rei­nen) Sta­teful Inspec­tion sind einer­seits die Kom­ple­xi­tät die­ser Lösung, ande­rer­seits die feh­len­de voll­stän­di­ge Kon­trol­le der Daten der Appli­ka­ti­ons­schicht, sofern die­ser Mecha­nis­mus nicht durch wei­te­re Optio­nen ergänzt wird. Außer­dem ist, wie bei Paket­fil­tern auch, der “Unsi­cher­heits­fak­tor Mensch”, der sämt­li­che Ver­bin­dun­gen erlau­ben kann, zu berücksichtigen.

Fazit:
In Kom­bi­na­ti­on mit wei­te­ren Fil­ter­me­cha­nis­men kann die Sta­teful Inspec­tion durch­aus sicher ein­ge­rich­tet wer­den. Sie bie­ten einer­seits die Vor­tei­le von Paket­fil­tern und zusätz­lich eine voll­stän­di­ge Kon­trol­le über die ein­zel­nen Verbindungen.

Cir­cuit Level Gateways

Die­se Fire­walls arbei­ten in Schicht 6 des ISO/O­SI-Schich­ten­mo­dells und wer­den auch “user defi­ned Pro­xy” oder “Gene­ric Ser­vice Pas­ser” genannt. Sie kön­nen die Daten der Appli­ka­ti­ons­ebe­ne nicht inter­pre­tie­ren und arbei­ten beim Abruf der Daten von Ser­vern als Stell­ver­tre­ter für die Benutzer.

Unter­schied­li­che Mecha­nis­men tei­len dem Gate­way mit, von wel­chem Ser­ver Daten geholt wer­den sol­len. Hier gibt es die “modi­fied pro­ce­du­re”, bei der sich ein Benut­zer direkt mit der Fire­wall ver­bin­det und ihm das gewünsch­te Ziel mit­teilt. Die­se Infor­ma­ti­on wird beim “modi­fied cli­ent” über ein sepa­ra­tes Pro­to­koll (z.B. socks) über­mit­telt. Der heu­ti­ge Stan­dard ist das “trans­pa­rent IP mas­que­ra­ding”, bei dem Anfra­gen des Benut­zers mit Hil­fe eines ver­än­der­ten TCP/IP Stacks auto­ma­tisch abge­fan­gen und eine Ver­bin­dung auf­ge­baut wird.

Die Vor­tei­le die­ser Lösung sind, dass sämt­li­che Angrif­fe auf der Netz­werk- und Trans­port­ebe­ne, die bei Paket­fil­tern theo­re­tisch mög­lich sind, nicht erfol­gen kön­nen, weil die Fire­wall selbst eine Ver­bin­dung zum Ziel­sys­tem auf­baut. Es erge­ben sich auf­grund der Unter­su­chung in Schicht 6 auch erwei­ter­te Mög­lich­kei­ten für das Log­ging und Accounting.

Nach­tei­lig kann sich aus­wir­ken, dass die über­tra­ge­nen Daten selbst nicht über­prüft wer­den kön­nen. Die feh­len­de Trans­pa­renz mit ihrer umständ­li­chen Bedie­nung klas­si­scher Cir­cuit Level Gate­ways kann Benut­zern die­se Art der Fire­wall ver­lei­den und eine gute Hot­line erfor­dern. Zudem ist die Per­for­mance die­ser Fire­walls meist nicht so hoch wie bei Paket­fil­tern oder der Sta­teful Inspection.

Fazit:
In Kom­bi­na­ti­on mit Appli­ca­ti­on Level Gate­ways stel­len moder­ne Fire­walls die­ser Art eine gute Ergän­zung für die Nut­zung “exo­ti­scher” Diens­te dar.

Appli­ca­ti­on Level Gateways

Ab und zu  sind auch heu­te noch Stim­men sind zu hören, dass die­se Fire­walls “sta­te of the art” sind. Sie wir­ken als Pro­xys, so dass der Benut­zer kei­ne direk­te Ver­bin­dung zum Ziel­sys­tem hat. Da sie in Schicht 7 des ISO/O­SI-Schich­ten­mo­dells arbei­ten, besteht zusätz­lich eine vol­le Kon­trol­le über die tat­säch­lich inner­halb des Pro­to­kolls über­tra­ge­nen Daten.

Vor­tei­lig ist die­se Lösung, wenn für das genutz­te Pro­to­koll ein spe­zi­el­ler Pro­xy zur Ver­fü­gung steht, so dass wirk­lich eine vol­le Kon­trol­le vor­han­den ist. Eine direk­te Ver­bin­dung zwi­schen Cli­ent und Ser­ver besteht nicht, so dass eini­ge der für Paket­fil­ter genann­ten Nach­tei­le kaum gel­ten kön­nen. Zusätz­lich besteht die Opti­on, bei HTTP bei­spiels­wei­se akti­ve Inhal­te her­aus­fil­tern zu kön­nen. Benut­zer sind direkt über das Pro­to­koll zu authen­ti­sie­ren, so dass auch hier ein guter Schutz zu kon­fi­gu­rie­ren ist.

Außer­dem gibt es spe­zi­ell für sen­si­ble Anwen­dun­gen im E‑Business inzwi­schen Appli­ca­ti­on Level Gate­ways, die einen Angriff über die Appli­ka­ti­ons­ebe­ne fast unmög­lich machen, da auch Ses­si­on-IDs und Coo­kies sehr genau über­prüft werden.

Die Nach­tei­le eines Appli­ca­ti­on Level Gate­ways sind unter ande­rem, dass für wirk­lich jedes zu fil­tern­de Pro­to­koll ein Pro­xy vor­han­den sein muss. Sofern von Stan­dards abwei­chen­de Pro­to­kol­le gefil­tert wer­den sol­len, muss hier auf Cir­cuit Level Gate­ways aus­ge­wi­chen wer­den. Da es sich bei den Pro­xys um Appli­ka­tio­nen han­delt, bie­ten sie eine gerin­ge­re Leis­tungs­fä­hig­keit in Bezug auf Daten­durch­satz als Paket­fil­ter oder Sta­teful Inspec­tion. Ein Schutz der unte­ren Schich­ten fin­det bei rei­nen Appli­ca­ti­on Level Gate­ways nicht statt.

Fazit:
Für den Schutz vor Angrif­fen auf der Appli­ka­ti­ons­ebe­ne bie­ten die­se Fire­walls oft sehr gute Mög­lich­kei­ten. Kom­bi­niert mit Cir­cuit Level Gate­ways las­sen sich eini­ge poten­zi­el­le Nach­tei­le die­ser Fire­walls kom­pen­sie­ren, wobei aber die Leis­tungs­fä­hig­keit in Bezug auf Per­for­mance nicht immer opti­mal ist.

Aus­prä­gun­gen von Firewalls

Kom­mer­zi­el­le Firewalls

Bei kom­mer­zi­el­len Fire­walls wer­den die oben genann­ten Optio­nen zur Fil­te­rung meist kom­bi­niert. Hier­bei wird zwi­schen rei­nen Soft­ware­lö­sun­gen für bereits instal­lier­te Sys­te­me, einer Kom­bi­na­ti­on von Betriebs­sys­tem und Fire­wall und sog. Appli­ances unter­schie­den. Letz­te­re sind Kom­plett­lö­sun­gen inkl. Hard­ware eines Her­stel­lers. Nicht zuletzt auf­grund eines dedi­zier­ten Ansprech­part­ners gilt die­se Lösung heu­te meist als Standard.

“Halb­kom­mer­zi­el­le” Firewalls

Hier fin­det sich heu­te eine Kom­bi­na­ti­on frei ver­füg­ba­rer Sicher­heits­me­cha­nis­men (z.B. für Linux oder Free­BSD), die mit einer kom­mer­zi­el­len Benut­zer­ober­flä­che und mög­li­cher­wei­se noch wei­te­ren kom­mer­zi­el­len Pro­duk­ten wie z.B. einem Anti­Vi­rus-Ser­ver gekop­pelt sind. Die­se Opti­on ist bei Unter­neh­men heu­te immer weni­ger zu finden.

Frei ver­füg­ba­re Firewalls

Die­se Fire­walls ste­hen ent­we­der nur für den pri­va­ten Gebrauch oder als “Bau­satz” zur Ver­fü­gung. Der Admi­nis­tra­tor kann selbst sei­ne Fire­wall bau­en, indem er die rich­ti­gen und frei ver­füg­ba­ren Werk­zeu­ge instal­liert, kon­fi­gu­riert, tes­tet und aktu­ell hält. Hier­mit las­sen sich zwar Ver­bin­dun­gen kon­trol­lie­ren, aber spä­tes­tens wenn ein Unter­neh­men nicht nur eine ein­zi­ge Fire­wall hat und auch Logs aus­ge­wer­tet wer­den müs­sen, kommt die­se Mög­lich­keit nicht mehr in Frage.