Brandväggar i publika nätverk

Brandväggar i publika nätverk
"The ultimate security is your understanding of reality"
H. Stanley Judd
GUSTAV STENLUND, JONAS VIS
Master’s Thesis at IMIT/TSLAB, KTH & Columbitech
Supervisor: Mats Persson
Examiner: Johan Montelius
ECS/ICT-2006-136

Abstract
Internet is an important part of many modern companies and opens for communication
opportunities between co-workers and parties. Technologies like VPN (Virtual Private
Network) makes it possible for employees to connect from home, public airports or internet
coffee shops. Corporate networks are usually protected by firewalls guarding the physical
borders of the network. These firewalls have difficulties keeping up with the security threats
introduced by these technologies. With the rapid development in mobile internet technologies,
new threats are introduced all the time forcing new counter actions. To be able to
enforce a security policy for a corporate network, all connected nodes must be protected by
a personal firewall.
In this thesis we presents a general model for a personal firewall consisting of two
cooperating filters. By using two filters; one session filter and one dynamic packet filter
we construct an effective tool for maintaining a distributed security policy. The model is
tested by an implementation for Windows XP consisting of a NDIS Intermediate filter and
a TDI Hook filter. By testing the implementation we show that the model satisfies our
requirements and is practically usable.
iii

iv
Sammanfattning
Internet är en viktig del av varje företags verksamhet och öppnar upp möjligheter för
företagen att kommunicera bättre med medarbetare och andra aktörer. Tekniker som VPN
(virtuellt privat nätverk) gör det möjligt för anställda att ansluta sig till företaget hemifrån,
från flygplatser eller internetkaféer. Företagsnätverk skyddas i regel med brandväggar i
utkanterna men dessa har svårt att skydda mot hot introducerade med de nya teknikerna.
I samband med den mobila utvecklingen introduceras nya hot vilket gör det viktigt att
överväga risker och vidta nödvändiga åtgärder för att skydda sig. För att upprätthålla en
säkerhetspolicy för ett företagsnätverk måste alla enheter som ansluter sig utrustas med en
personlig brandvägg.
I denna rapport presenterar vi en generell modell för en personlig brandvägg bestående
av två samarbetande filter. Genom att kombinera två filter; ett sessionsfilter och ett dynamiskt
paketfilter konstruerar vi en effektiv lösning för att underlätta att upprätthålla en
distribuerad säkerhetspolicy. Modellen testas genom en implementation för Windows XP
bestående av ett NDIS Intermediate-filter och ett TDI Hook-filter. Genom testning av implementationen
visas att modellen uppfyller uppställda krav och är praktiskt genomförbar.

Innehåll
Innehåll v
Figurer vii
1 Introduktion 1
1.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Bakgrund 5
2.1 OSI-modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Standardmodellen . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 TCP/IP-modellen . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Brandväggstyper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Paketfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Anslutningsorienterat paketfilter . . . . . . . . . . . . . . . . 9
2.2.3 Dynamiskt paketfilter . . . . . . . . . . . . . . . . . . . . . . 9
2.2.4 Applikationsproxy . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.5 Deep Packet Inspection . . . . . . . . . . . . . . . . . . . . . 11
2.2.6 Sessionsfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Analys och testning av brandväggar . . . . . . . . . . . . . . . . . . 11
2.3.1 Feltyper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Effekter av fel . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Sammanfattning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Modell 15
3.1 Krav för modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Sessionsfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Dynamiskt paketfilter . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Kontrollapplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Fallstudie - Microsoft Windows XP 21
4.1 Operativsystemsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Drivrutinsmodell . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.2 Nätverksmodell . . . . . . . . . . . . . . . . . . . . . . . . . . 23
v

vi INNEHÅLL
4.2 Filtreringstekniker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Filtrering i applikationslagret . . . . . . . . . . . . . . . . . . 25
4.2.2 Filtrering i kärnan . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1 Mål och krav för implementationen . . . . . . . . . . . . . . . 27
4.3.2 Begränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.3 Arkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.4 Paketfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.5 Sessionsfilter - TDI filter . . . . . . . . . . . . . . . . . . . . . 30
4.3.6 Kontrolltjänst . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5 Tester 35
5.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1 Implementationstester . . . . . . . . . . . . . . . . . . . . . . 36
5.1.2 Penetrationstester . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.3 Regeltester . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.4 Sammanfattning . . . . . . . . . . . . . . . . . . . . . . . . . 37
6 Slutsats 39
Litteraturförteckning 41
Appendix 42
A TDI filter 43
A.1 IO till TDI-lagret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2 Ny anslutning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.3 Öppna en anslutning med TDI . . . . . . . . . . . . . . . . . . . . . 44
A.3.1 Öppna en Transportadress . . . . . . . . . . . . . . . . . . . . 44
A.3.2 Öppna en anslutningsslutpunkt . . . . . . . . . . . . . . . . . 44
A.3.3 Associera transportadressen med anslutningsslutpunkten . . 46
A.3.4 Göra anslutningen . . . . . . . . . . . . . . . . . . . . . . . . 46
A.4 Skicka och ta emot data med TDI . . . . . . . . . . . . . . . . . . . 46
A.5 Avsluta en anslutning med TDI . . . . . . . . . . . . . . . . . . . . . 47

Figurer
2.1 OSI-modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 OSI-modellen matchad mot TCP/IP-modellen . . . . . . . . . . . . . . 7
2.3 Arkitektur för en paketfiltrerande brandvägg . . . . . . . . . . . . . . . 8
2.4 Arkitektur för en anslutningsorienterad brandvägg . . . . . . . . . . . . 9
3.1 Övergripande bild över flödet i modellen. . . . . . . . . . . . . . . . . . 15
3.2 Flödesdiagram över sessionsfiltret. . . . . . . . . . . . . . . . . . . . . . 18
3.3 Flödesschema över paketfiltret. . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Flödesschema över kontrollapplikationen. . . . . . . . . . . . . . . . . . 20
4.1 Abstraktionslager i Windows XP . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Drivrutinsmodellen i Windows XP . . . . . . . . . . . . . . . . . . . . . 23
4.3 Nätverksmodellen i Windows XP . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Arkitektur för implementationen . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Förenklat sekvensdiagram för implementationen . . . . . . . . . . . . . 29
4.6 Komponenter i paketfilter . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7 Komponenter i TDI-filtret . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.8 Tillståndsdiagram för en session i TDI-filtret . . . . . . . . . . . . . . . 32
A.1 Create Address Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.2 Create Connection Context . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.3 Associate Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.4 Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.5 Send Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.6 Receive Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.7 Register Event Receive Function to Receive Data . . . . . . . . . . . . . 49
A.8 Receive Data in Event Receive Function . . . . . . . . . . . . . . . . . . 49
A.9 Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.10 Disassociate the Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.11 Close the Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
vii

Kapitel 1
Introduktion
De flesta företag i dagens samhälle anser att Internet är en viktig del av deras
verksamhet och för att kunna konkurrera med andra företag måste de vara anslutna
till Internet. Men det finns stora risker att ansluta företagsnätet till Internet. När
ett företag ansluter sitt nätverk till Internet möjliggör det inte bara för de anställda
att komma åt material på Internet, utan gör det även möjligt för utomstående
att komma åt företagets privata nätverk. Behovet av kontroll av tillgänglighet för
datortrafik har därmed drivit fram utvecklingen av kontroll av datorkommunikation.
Ett program speciellt avsett för denna typ av kontroll kallas brandvägg därför att
den kan efterliknas en brandvägg i en bil.
De allra flesta datoranvändare idag har någon gång kommit i kontakt med en
brandvägg. Nästan alla som anslutit sig till Internet via bredband med till exempel
ADSL (Asymmetric Digital Subscriber Line) har ett kombinerat bredbandsmodem
och brandvägg. Alla som använder operativsystemet Windows XP eller Mac OS X
får med en förinstallerad brandvägg. I idealfallet är en brandvägg något användaren
ej behöver känna till, än mindre konfigurera, men det är inte alltid detta fungerar
som tänkt.
De första brandväggarna kom i slutet av 1980-talet som en reaktion på flera
allvarliga säkerhetsincidenter. En av de mest kända säkerhetsincidenterna var den
så kallade Morris-masken som slog till mot Internet i slutet av 1988 (Spafford, 1991).
Programmet utnyttjade en säkerhetslucka i BSD-versioner av UNIX och spreds sig
till tusentals datorer och slog ut större delen av Internet under flera dagar.
Gemensamt för alla datorbrandväggar är att huvudfunktionen är att skydda
ett betrott område, där ett ett område både kan vara ett företags nätverk eller en
persondator. Grunden för denna funktion bygger på att man analyserar datortrafik
och jämför denna med en lista av regler. En regel specificerar en viss typ av
kommunikation mellan två eller flera ändpunkter. Ett exempel kan vara då X vill
kommunicera med Y då dessa befinner sig på var sin sida om brandväggen F . I det
enkla fallet kan följande scenario tänkas:
• X försöker kontakta Y
1

2 KAPITEL 1. INTRODUKTION
• Anropet hamnar hos F
• F kontrollerar om det finns en regel som tillåter X att kontakta Y
• Om en sådan regel finns vidarebefordrar F anropet till Y
• Om en sådan regel ej finns kastas anropet alternativt rapporteras till X att
anropet ej genomförts
De första brandväggarna var huvudsakligen anpassade för att filtrera datortrafik
mellan två olika nätverk, till exempel ett lokalt nätverk på jobbet och det världsomspännande
nätverket Internet. En brandvägg som denna körs normalt på en separat
dator som är ansluten till de båda nätverken. Viktigt är att denna anslutning är den
enda kopplingen mellan dessa nätverk. Detta eftersom brandväggen skall fungera
som ett filter för all datortrafik mellan nätverken.
Denna typ av brandväggar installeras normalt i utkanten av det nätverk man
vill skydda. Efter att datorer blivit mindre, lättare och mer portabla på senare tid
har det blivit vanligare att företagens anställda tar med sig datorer och andra enheter
utanför kontoret. Genom att göra det möjligt för anställda att ansluta sig till
företagets nätverk via en VPN-tunnel (Virtuellt Privat Nätverk) var som helst ifrån
har man i ett slag flyttat gränserna för det nätverk man vill skydda. Fördelen med
en VPN-tunnel är att en dator som är ansluten får precis samma kommunikationsmöjligheter
som om den skulle fysiskt befunnit sig innanför brandväggarna på det
nätverk den är ansluten till. Denna egenskap gör att en hacker som lyckas ta över
kontrollen av en sådan dator inte endas har kontroll över en anställds dator utan
indirekt en dator inne i det nätverk man vill skydda. En bärbar dator som används
av en resande anställd på en flygplats, ett café eller hemma måste därmed även den
skyddas med en brandvägg.
Risken har som sagt ökat de senaste åren i och med publika trådlösa nätverk
och möjligheten att alltid vara uppkopplad hemma, vilket gör det extra viktigt att
ha ett fullgott skydd på de anställdas bärbara datorer och andra enheter för att
skydda företagets nätverk. Brandväggar delas in i två huvudkategorier:
• Nätverksbrandvägg. Installeras och körs på en dedikerad dator. Denna
skyddar mot angrepp mellan olika nätverk.
• Personlig brandvägg. Installeras och körs lokalt på den egna datorn. Denna
skyddar mot lokala angrepp.
Men det är inte bara hoten utifrån som man måste ta hänsyn till och skydda sig
mot utan hoten kommer oftare och oftare på senare tid från insidan vilket gör att
det inte räcker med en traditionell brandvägg. Ett exempel är mailkorrespondens
som idag är vanligt förekommande både privat och affärsmässigt. Med mail kan man
bifoga såväl dokument som exekverbara program eller skript. Trots att användaren
har en brandvägg som skyddar mot angrepp utifrån finns inget som förhindrar att
exekverbara program eller skript kan ta sig ut när de väl kommit in i datorn. Som

1.1. SYFTE 3
en bifogad fil kan därför ett litet exekverbart program eskorteras in i datorn och
därmed inifrån öppna en kommunikationskanal utåt. Ett sådant program kallas
efter grekisk mytologi för en trojansk häst (Wikipedia, 2006e). När väl trojanen
exekveras (t.ex. genom att användaren sätter igång den) kan trojanen installera sig
själv, skicka sig själv vidare i nya mail till adresser i användares adressbok eller
diskret börja kommunicera ut information från användarens dator helt utan att
denne märker något.
Dessa nya hot har drivit fram behov av filtrering av vilka program som får
möjlighet att kommunicera. Man har introducerat ett nytt lager av filtrering för
den personliga brandväggen, ett applikationsfilter. Det räcker inte med att endast
filtrera trafikflöden baserat på avsändare och mottagare, man måste även filtrera
trafik utefter vilken applikation som vill kommunicera.
Mycket utveckling har skett inom detta område de senaste 20 åren. I dagsläget
finns en uppsjö av brandväggsvarianter, såväl kommersiella som gratis. Nätverksbrandväggar
följer till exempel med de flesta startpaketför bredbandsuppkopplingar.
Desto svårare är det att hitta relevant information om hur brandväggar egentligen
fungerar, hur en brandvägg designas utifrån standarder för kommunikation på internet
samt hur en implementation egentligen skall göras.
1.1 Syfte
Mot denna bakgrund vill vi i denna rapport presentera en generell modell för en
personlig brandvägg baserad på standarder inom datorkommunikation. Modellen
skall rymma de grundfunktioner en personlig brandvägg bör implementera samt
kunna ligga till grund för en implementation. För att testa att modellen är genomförbar
presenterar vi en implementation för operativsystemet Windows XP. Genom
att implementera modellen och testa implementationen kan vi verifiera att modellens
design uppfyller de grundläggande krav (Ingham och Forrest, 2002) vi ställer
upp för vår modell. Som utgångspunkt för denna rapport har vi därför ställt upp
följande egenskaper som en personlig brandvägg bör ha:
• Skydda mot säkerhetsproblem i operativsystem. Dagens operativsystem
är otroligt komplexa och nya buggar upptäcks hela tiden. Genom att
använda sig av en personlig brandvägg skyddar man operativsystem från attacker
utifrån.
• Förhindra åtkomst till information. En av de viktigaste funktionerna hos
brandväggar är att förhindra åtkomst till information. Exempelvis begränsar
många företag vilka webbsidor de anställda kan komma åt.
• Förhindra informationsläckor. Eftersom all information som lämnar ett
system passerar brandväggen kan den användas till att förhindra att känslig
information kommer ut. Ett exempel på detta är hotet från trojaner som
fångar upp exempelvis lösenord och skickar dem vidare.

4 KAPITEL 1. INTRODUKTION
• Upprätthålla en säkerhetspolicy. Brandväggar är ett viktigt verktyg för
att upprätthålla och implementera ett företags säkerhetspolicy.
• Underlätta granskning. Om ett system har råkat ut för intrångsförsök är
det sällan brandväggen i sig har tagit skada. Detta gör att logfilerna från
brandväggen kan användas för att kartlägga och granska intrånget eller intrångsförsöket.
Detta gäller framförallt nätverksbrandväggar.
Genom att utgå från tidigare forskning och standarder i nätverkskommunikation
i kapitel 2 presenterar vi en modell i kapitel 3 som skall kunna ligga till grund
för en implementation i ett godtyckligt system baserat på dessa standarder. En implementation
som utgår från modellen erhåller indirekt de egenskaper vi i modellen
presenterar. Som test av vår modell presenterar vi slutligen en implementation av
modellen för operativsystemet Windows XP i kapitel 4.

Kapitel 2
Bakgrund
Trots att brandväggar är så vanligt förekommande har forskningen och teorin om
dem varit knapphändig. En stor del av utvecklingen har gjorts på företag utan
att någon tydlig modell eller teori presenterats offentligt. Dock finns det ett antal
artiklar om brandväggar och de flesta teorierna utgår från den så kallade OSImodellen.
Som introduktion presenteras OSI-modellen för att ligga som grund för
en genomgång av brandväggstyper indelade efter vilken nivå av information från
OSI-modellen de olika filtrerar på.
2.1 OSI-modellen
OSI står för Open Systems Interconnect och är en formell standardmodell som ofta
används av forskare och utvecklare när man diskuterar nätverk och datasäkerhet.
OSI-modellen är framtagen av ISO (International Standards Organization) för att
definiera en standard för utveckling av nätverk och kringliggande system. Modellen
beskriver sju lager som representerar viktiga funktioner som generellt behövs vid
datakommunikation. Som många andra ISO-standarder går det inte att flytta den
formella teorin till en implementation utanför den akademiska världen. Dock är OSImodellen
en viktig verktyg för att kunna förklara och diskutera nätverksdesign.
2.1.1 Standardmodellen
OSI-modellen består som sagt av sju lager där varje lager tillför en nivå av abstraktion.
För att skicka data från en nod till en annan passerar data från lager sju ner
till lager ett vidare till den andra noden där det motsatta sker, från lager ett upp
till lager sju (se figur 2.1). På väg ner genom modellen styckas data normalt upp
i fragment kallade paket, vardera bärande på information från de lager de passerat
genom. Mottagarnoden sätter således ihop fragmenten igen till en dataström allt
eftersom dessa anländer och kan sorteras upp i rätt ordning.
De olika lagren nedifrån:
5

6 KAPITEL 2. BAKGRUND
7. Applikation
6. Presentation
5. Session
4. Transport
3. Nätverk
2. Datalänk
1. Fysisk länk
Utgående trafik
Inkommande trafik
Figur 2.1. OSI-modellen
7. Applikation
6. Presentation
5. Session
4. Transport
3. Nätverk
2. Datalänk
1. Fysisk länk
1. Det fysiska lagret är ansvarigt för den fysiska kommunikation mellan ändpunkterna.
Det hanterar själva fysiska kodningen och överföringen av data.
2. Datalänklagret hanterar den logiska delen av överföringen mellan två direktanslutna
enheter. Bland annat hanteras hur flera enheter som delar på ett
överföringsmedium skall kommunicera och adressera varandra.
3. Nätverkslagret hanterar adressering för nätverk som kan spänna över flera
förbindelser och medium. Denna abstraktion används för att avgöra vilken väg
ett paket behöver ta för att nå sin slutdestination över flera möjliga datalänkar
och vägar över flera mellan liggande noder.
4. Transportlagret introducerar konceptet dataströmmar. Detta lager är ansvarigt
för hantering av sortering av paket, anpassning av överföringshastighet
och säkerställande att informationen når sin ändpunkt.
5. Sessionslagret kontrollerar sessionerna mellan olika datorer. Det sätter upp,
hanterar och avslutar anslutningar mellan en lokala applikation och en fjärrapplikation.
6. Presentationslagret tillhandahåller ett standardiserat gränssnitt mot applikationslagret
för data.
7. Applikationslagret gör det möjligt för användaren att komma åt information
som finns på nätverket. Användargränssnitt och funktioner som inte direkt är
relaterade till nätverksoperationer finns i detta lager.
2.1.2 TCP/IP-modellen
OSI-modellen används som sagt mest som en akademisk modell när man vill diskutera
nätverk och nätverkssäkerhet men den används ej i någon konkret tillämpning.

2.2. BRANDVÄGGSTYPER 7
Idag är det istället de protokoll som ingår i TCP/IP familjen som är helt dominerande.
De undre lagren av TCP/IP-modellen liknar OSI-modellens, medan lager
5, 6 och 7 i OSI-modellen normalt igår i applikationslagret i TCP/IP-modellen (se
figur 2.2).
OSI-modellen TCP/IP-modellen
7. Applikation
6. Presentation
5. Session
4. Transport
3. Nätverk
2. Datalänk
1. Fysisk länk
5. Applikation
4. TCP
3. IP
2. Datalänk
1. Fysisk länk
Inkommande trafik Utgående trafik
Figur 2.2. OSI-modellen matchad mot TCP/IP-modellen
Exempel på implementation av de 5 lagren i TCP/IP-modellen nedifrån:
1. En populär implementation är till exempel standarden 802.11 (trådlöst nätverk)
som definierar hur kodning av information till radiovågor skall gå till.
2. En del av standarden 802.11 specificerar även att adressering skall ske med
hjälp av MAC-adresser (Medium Access Control) som även den är en standard.
Ett exempel på en MAC-adress är "00:12:a2:b7:4c:b1".
3. En populär implementation av detta lager är IP-protokollet (Internet Protocol)
som adresserar noder med hjälp av IP-adresser. Ett exempel på en
IP-adress är "192.168.0.1".
4. En populär implementation av detta lager är protokollet TCP (Transport Control
Protocol). Denna implementation introducerar konceptet av en port som
ett identifikationsnummer för ändpunkten för en dataström. En dataström
går alltså mellan var sin port på käll- och destinationsnoden. Ett program
kan ha flera parallella dataströmmar mellan två noder där respektive ström
identifieras av ett portpar.
5. Ett exempel på protokoll i applikationslagret är HTTP (Hypertext Transfer
Protocol), FTP (File Transfer Protocol) och SMTP (Simple Mail Transfer
Protocol).
2.2 Brandväggstyper
Innan vi går in på de olika brandväggstyper som finns ger vi en kort definition av
vad en brandvägg är.

8 KAPITEL 2. BAKGRUND
Brandväggsteknik är en mängd av mekanismer som kan upprätthålla
en nätverksdomäns säkerhetspolicy på inkommande och utgående
kommunikation för nätverksdomänen. Ett brandväggssystem, eller en
brandvägg är en instans av brandväggsteknik (Schuba, 1997).
Brandväggar brukar delas in i olika kategorier utifrån från vilka lager i OSImodellen
de använder information från för att klassificera nätverkstrafik samt hur de
arbetar. Utvecklingen av brandväggar har gått från att endast använda information
från lager tre i OSI modellen till att kombinera information från flera lager.
2.2.1 Paketfilter
Paketfilter kallas den teknik där man filtrerar datortrafik genom att analysera paket
som skickas via nätverket. Filtrering baseras på information man extraherar
från paketet i sig, normalt information från lager tre och fyra från OSI-modellen
(Woodall, 2004).
7. Applikation
6. Presentation
5. Session
4. Transport
3. Nätverk
2. Datalänk
1. Fysisk länk
Inkommande trafik Utgående trafik
Trafik filtreras utifrån käll- och
destinationsadress, pakettyp och
portnummer. Okänd trafik är bara
tillåten upp till lager 3 i
nätverksstacken.
Figur 2.3. Arkitektur för en paketfiltrerande brandvägg
Till denna kategori hör exempelvis den första välkända kommersiella produkten
Cisco IOS (Cisco, 2002) som lanserades 1985, vilken kom att kallas den första
generationens brandvägg. Denna paktefiltrerande brandvägg använder sig av protokoll,
käll- och destinationsadress samt port från TCP-protokollet (lager 3 och 4
i OSI-modellen) för att filtrera trafik. Dock dröjde det till 1989 innan den första
vetenskapliga artikeln publicerades av Mogul (1989).
En egenskap hos paketfiltrerande brandväggar är att de har relativt liten påverkan
på nätverksprestandan. Dock saknar denna generation av brandvägg möjlighet
att konfigureras efter vem som initierar trafik. Eftersom nästan all datortrafik baseras
på att information skall skickas i båda riktningarna för att fungera blir de
oerhört svåra, om inte omöjliga, att konfigurera på ett säkert sätt. För att konfigurera
en sådan brandvägg att tillåta noder på ena sidan att få full tillgång till
andra sidan måste man följaktligen tillåta alla trafik i båda riktningarna. En sådan
brandväggskonfiguration fyller inte stor funktion. Ytterligare säkerhetsproblem

2.2. BRANDVÄGGSTYPER 9
som finns med denna typ av paketfiltrerande brandvägg är att de inte håller i vilket
tillstånd en anslutning är i. Utan denna kontroll kan buggar i operativsystemets
implementation lätt utnyttjas för intrångsförsök.
2.2.2 Anslutningsorienterat paketfilter
En vidareutveckling av den första generationens paketfiltrerande brandvägg introducerade
ett koncept av tillstånd för TCP-anslutningar. Detta för att kontrollera
upp- och nerkopplingsfasen för TCP-protokollet och för att säkerställa att denna
genomförts korrekt, att en anslutning är legitim samt att ingen tredje part försöker
genskjuta kommunikationen. För varje anslutning genom brandväggen sparas
information om anslutningens tillstånd i en tillståndstabell. Informationen i tillståndstabellen
brukar oftast bestå av en unik identifierare, tillståndet på anslutningen
(uppkopplad/stänger), sekvensinformation, IP adressen på avsändaren och
mottagaren och de fysiska nätverkskortet som paketen inkommer eller går ut på.
1. All paket jämförs mot för
definierade regler utifrån ett eller
flera lågnivå protokoll så som IP,
TCP och ICMP. Filtret stoppar
antigen paketen eller släpper i
genom dem vidare till
nätverksstacken.
Sorterad
regellista
7. Applikation
6. Presentation
5. Session
4. Transport
3. Nätverk
2. Datalänk
1. Fysisk länk
3. Om ett paket uppfyller alla
villkor för den virtuella krets
tabellen och regellistan skickas
det vidare upp i nätverksstacken.
2. Transportlagret sparar
information om en
nätverkssession i en
virtuell kretstabell
Figur 2.4. Arkitektur för en anslutningsorienterad brandvägg
Fördelen mot paketfiltrerande brandväggar är att paket måste tillhöra en giltig
anslutning. Varje paket undersöks först mot regellistan och sedan mot tillståndstabellen
för att se om det skall accepteras eller ej. Denna brandväggstyp introducerades
omkring 1989-1990 av Dave Presotto och Howard Trickey på AT&T Bell Labs
och kom att kallas andra generationens brandvägg (Cisco, 2002). Med hjälp av den
nya tekniken med tillståndstabell gjorde man det möjligt att stärka kontrollen av
TCP-protokollet.
2.2.3 Dynamiskt paketfilter
Nästa tekniska framsteg utgjordes av en anpassning av de tidigare paketfiltrerande
brandväggarna att möjliggöra för dynamisk uppdatering av regellistan under
körning. Konceptet stödjer sig på att praktiskt taget all datorkommunikation är
dubbelriktad. Förenklat kan man se det som att en förfrågan skickas i ena riktningen
och ett svar i den andra. Förbättringen för denna typ av paketfilter ligger i att

10 KAPITEL 2. BAKGRUND
det räcker med att ha en regel för en utgående förfrågan. Då förfrågan skickas iväg
läggs en ny regel till för inkommande trafik från precis den som förfrågan skickats
till i regellistan. När svaret inkommer finns då en regel som tillåter detta att passera.
Hade förfrågan aldrig skett skulle detta svar ej heller tillåtas passera. Då denna teknik
kombineras med tidigare teknik rörande tillstånd för TCP-uppkopplingar samt
ett tillägg för liknande virtuella tillståndstabeller för andra protokoll som UDP och
ICMP har man lagt grunden för dagens paketfiltrerande brandväggar. Denna typ av
paketfiltrerande brandväggar kom att kallas fjärde generationens brandväggar, dynamisk
paketfiltrering (itsecurity.com, 2006) eller SPI (Stateful Packet Inspection).
Check Point Software släppte 1994 den första kommersiella produkten baserad på
denna teknologi och kallade typen för Stateful Mulitlayer Inspection Firewalls. Säkerhetsmässigt
kom denna teknik att innebära ett stort steg framåt. Med hjälp av
brandväggar baserade på denna teknik kan man sätta upp ett skalskydd runt ett
lokalt nätverk där man tillåter utgående trafik (initierad av användarna innanför
brandväggen) men ej inkommande trafik (initierad av okända externa aktörer).
2.2.4 Applikationsproxy
En helt annan teknik baserad på filtrering av innehåll i informationsströmmar snarare
än paket är att använda sig av en applikationsproxy. Detta filter opererar som
en proxytjänst i form av en applikation som sköter kommunikationen ut på nätverket.
All trafik tänkt att passera ut på nätverket passerar proxytjänsten. Denna typ
av brandvägg skiljer sig mot de två tidigare på så sätt att man inte har något filter
för TCP/IP stacken, utan låter paketen propagera uppåt i stacken för att sedan
behandlas av en proxytjänst innan det skickas vidare till programmet som skall
ha paketet. För att detta skall fungera krävs en proxytjänst för varje protokoll på
applikationsnivå. Huvudsakligen var det AT&T Bell Labs som utvecklade de första
brandväggarna av denna typ vilken kom att kallas Application Level Gateways eller
Proxy Frewalls.
Det finns många fördelar med en proxybrandvägg bland annat att de kan filtrera
på applikationsprotokoll och att de inte tillåter direkt kommunikation med nätverket
utan allt måste passera genom proxybrandväggen. På denna nivå är det lätt att
införa intelligenta filter som kan filtrera på innehåll i dataströmmen som till exempel
skadliga skript. Tyvärr finns det flera nackdelar med denna typ av filter. I stort sett
måste man skriva en proxytjänst för varje protokoll som man vill använda. Dock
finns det vissa generella proxytjänster som hanterar UDP, RPC och andra vanliga
protokoll. Proxybrandväggar är dessutom beroende av att operativsystemet de körs
på är säkert nog. Paketfiltrerande brandväggar filtrerar trafik innan nätverkslagret
och skyddar därmed nätverksstacken från attacker medan proxybrandväggar inte
har något skydd för denna typ av attacker (Cisco, 2002). En annan nackdel är att de
ofta är relativt enkla att ta sig runt inifrån. Moderna operativsystem tillhandahåller
enkla möjligheter att själv öppna anslutningar och man kan därigenom förbigå en
applikationsproxy.

2.3. ANALYS OCH TESTNING AV BRANDVÄGGAR 11
2.2.5 Deep Packet Inspection
En vidareutveckling av paketfiltreringstekniken har introducerat ett begrepp kallat
Deep Packet Inspection. Denna teknik bygger på att undersöka information från protokoll
i applikationslagret i ett paket eller en ström av paket redan på nätverkslagret
i OSI-modellen. Genom att analysera information från applikationslagret kan till
exempel skadlig kod rensas bort tidigt, långt innan nätverksstacken börjat behandla
dataströmmen. Tekniker som används för deep packet inspection består oftast
av kombination av statistisk och strängmatchning. Dessa typer av analys kräver
mycket datakraft vilket gör det svårt att utan speciell hårdvara utföra deep packet
inspection i en hastighet som matchar nätverkets. En brandvägg som utför deep packet
inspection måste inte bara hålla reda på tillstånden för nätverksanslutningarna
utan även tillstånden hos de applikationer som använder sig av nätverket. Eftersom
deep packet inspection kräver relativt mycket datorkraft är det inget alternativ än
så länge för personliga brandväggar (Dubrawsky, 2003). Dock kan man tänka sig
att i och med att antalet processorkärnor i dagens persondatorer ökar snabbt, skulle
det kunna vara möjligt att använda sig av en av processorkärnorna till deep packet
inspection utan att påverka prestanda på resten har systemet.
2.2.6 Sessionsfilter
Vid användande av VPN-lösningar då man flyttar ut företagets skalskydd till enskilda
datorer uppkopplade via VPN kan det vara nödvändigt att endast tillåta vissa
applikationer efter strikta regler att kommunicera ut på nätverket. För att företaget
skall kunna ha en säkerhetspolicy och vara säker på att denna efterlevs krävs
ytterligare en typ av filter, nämligen sessionsfilter. Ett filter som detta opererar på
information från sessions-, presentations- och applikationslagret för att begränsa
access utåt. Detta filter är alltså inget filter för att huvudsakligen hindra inkommande
trafik utan snarare ett filter för att hindra utgående trafik baserat på vilken
applikation som vill kommunicera samt hur den vill få access till nätverket.
2.3 Analys och testning av brandväggar
Precis som med forskning kring brandväggar är det först på senare tid som man
gått mer vetenskapligt tillväga för att kontrollera att brandväggar implementerar
en säkerhetspolicy korrekt. Problemet är att det är oerhört komplext att säkerhetställa
en säkerhetspolicy eftersom den är beroende av så många faktorer. Detta är
framförallt svårt när man hanterar stora nätverk med flera brandväggar eftersom
man även måste kartlägga hur de olika brandväggarna tillsammans implementerar
säkerhetspolicyn.
Flera artiklar har tagit upp hur man kan gå till väga för att testa brandväggar,
bland annat Schultz (1996), Schuba (1997), Haeni (1997), KhalidAl-Tawil och
Al-Kaltham (1999) samt Kamara m.fl. (2003). Dock riktar alla in sig på nätverksbrandväggar
och hur man ska kontrollera hur de implementerar en säkerhetspolicy

12 KAPITEL 2. BAKGRUND
för ett eller flera nätverk. Ingen av dessa behandlar personliga brandväggar. Dock
finns en en websida (Kaddouch, 2006) som försöker skapa ett standardtest bestående
av flera deltester för just personliga brandväggar. Testerna är begränsade till Windows
XP och fokuserar att testa olika tekniker som trojaner och linkande program
använder sig av för att skicka ut information från en dator. Genom att kombinera
testerna från Kaddouch (2006) och bland annat Haeni (1997) får man tester som
både täcker in de mer traditionella testerna för brandväggar med specifika tester
för personliga brandväggar.
2.3.1 Feltyper
En sårbarhet hos en brandvägg definieras som ett fel, en svaghet eller ett felaktigt
antagande som gjorts under design, implementation eller konfiguration, som kan
utnyttjas för att attackera ett betrott nätverk som brandväggen antas skydda (Kamara
m.fl., 2003). Kamara m.fl. (2003) delar upp sårbarheterna i kategorier utifrån
orsak och effekt för att bättre kunna analysera sårbarheter hos brandväggar. De
vanligaste sårbarheterna hos brandväggar är:
• Valideringsfel (Validation error): Ett valideringsfel uppkommer när programmetet
interagerar med sin omgivning utan att bekräfta korrektheten hos
de data som programmet får från denna. Det finns tre typer av data från
omgivningen som måste valideras: inmatning, ursprung och mål. Inmatningsvalidering
ser till att indata är som förväntat. Ursprungsvalidering ser till att
ursprunget hos data verkligen är den som det påstås vara. Målvalidering ser
till att informationen går dit den är förutsatt att gå. Detta inkluderar även
att skyddad information inte går till ett mål som inte är betrott.
• Auktoriseringsfel (Authorization error): Ett autentiseringsfel tillåter en
skyddad operation körs utan tillräcklig verifiering av rättigheter har skett.
• Serialiseringsfel/Aliasfel (Serialization/Aliasing error): Ett serialiseringsfel
tillåter att det asynkrona beteendet hos olika systemoperationer utnyttjas
för att göra ett säkerhetsintrång. Ett aliasfel uppkommer då två namn
för samma objekt kan göra att dess innehåll ändras snabbt och oförutsägbart,
och medföra att redan gjorda säkerhetskontroller blir ogiltiga.
• Avgränsningsfel (Boundary checking error): Ett avgränsningsfel uppkommer
då man misslyckas med att kontrollera gränser mellan olika komponenter
eller missar att kontrollera restriktioner. Att inte kontrollera om värden
för tabellstorlekar, filallokeringar eller för andra resurser är orimliga leder till
avgränsningsfel. Ett exempel på detta är buffer overlow som många gånger
utnyttjats för intrångsförsök.
• Domänfel (Domain error): Ett domänfel uppkommer när tänkte gränser
mellan skyddade miljöer har hål som gör att information läcker ut.

2.3. ANALYS OCH TESTNING AV BRANDVÄGGAR 13
• Svag/Inkorrekt design (Weak/Incorrect design error): Ett designfel
som uppkommer kan spåras tillbaka till designfasen av utvecklingen. Till exempel
faller en svag krypteringsalgoritm inom detta område.
2.3.2 Effekter av fel
En sårbarhet kan ge upphov till en eller flera effekter där en effekt är någon av
följande:
• Exekvering av kod (Execution of code): Detta uppkommer när en sårbarhet
kan leda till att kod otillåtet körs. Det inkluderar, men är inte begränsat
till, kod som är skriven av en hacker.
• Förändring av målresurs (Change of target resource): Detta händer
när en sårbarhet som tillåter att tillståndet hos en resurs otillåtet ändras av
en hacker. En resurs kan vara en server, routing tabellen hos en brandvägg
eller någon enhet som ska skyddas av brandväggen.
• Åtkomst till målresurs (Access to target resource): Uppkommer då
en sårbarhet tillåter att en hacker otillåtet får tillgång till en resurs, där en
resurs är en enhet som skyddas av brandväggen. Exempel på denna effekt är
att tillåta en hacker att läsa regellistan för brandväggen, eller att ta reda på
vilka tjänster som finns tillgängliga på en skyddas server.
• Denial of service (DoS): Uppkommer då en sårbarhet utnyttjas för att störa
en tjänst som tillhandahålls till legitima användare. Här innebär en tjänst allt
från att vidarebefordra paket eller adressöversättning till administration.
2.3.3 Tester
Brandväggstester delas in i tre huvudkategorier som är tänkt att testa olika aspekter
Zaugg (2004). Målet är att testa designen, konfiguration och den säkerhetspolicy
som man har satt upp för brandväggen.
• Penetrationstester Målet med penetrationstester är att upptäcka säkerhetsproblem
hos ett nätverk genom att utföra attacker mot det. Penetrationstester
består av (1) informations insamling, (2) utforska nätverket och (3) attackera
nätverket. Attackerna utförs genom att köra olika testverktyg som testar
brandväggen för potentiella luckor i säkerheten som kan utnyttjas. Penetrationstester
utförs vanligen av systemadministratörerna själva eller av en tredje
part.
• Implementationstester Implementationstester fokuserar på själva brandväggsmjukvaran
där man försöker hitta buggar i programvaran. Man testar
bland annat att en brandväggsregel motsvarar den funktion brandväggen utför.
Exempelvis om en regel indikerar att man ska blocka ett paket men brandväggen
skickar vidare paketet, står man inför ett implementationsfel.

14 KAPITEL 2. BAKGRUND
• Regeltester Regeltester verifierar om säkerhetspolicyn är korrekt implementerad
av en mängd regler.
2.4 Sammanfattning
De flesta personliga brandväggar fungerar på ett liknande sätt som ett sessionsfilter
men ytterst lite är beskrivet i forskningen vad gäller denna typ av filter. I denna studie
vill vi belysa hur ett sessionsfilter kan fungera. Vi vill även visa att man genom
en kombination av ett paketfilter och ett sessionsfilter effektivt kan upprätthålla en
strikt säkerhetspolicy samt eliminera de svagheter som finns i paketfilter respektive
sessionsfilter. Genom en implementation av en sådan kombination i operativsystemet
Windows XP vill vi visa att det även är praktiskt genomförbart.

Kapitel 3
Modell
Personliga brandväggar som filtrerar utifrån vilket program som försöker använda
nätverket har blivit vanligare. Dock riktar sig de flesta artiklar in sig på nätverksbrandväggar.
Vi vill i den här rapporten framför allt visa hur man kan konstruerar
ett sessionsfilter men även hur man genom att kombinera det med ett dynamiskt
paketfilter kan få ett effektivare filter. Genom att kombinera ett dynamiskt paketfilter
med ett sessionsfilter kombinerar man styrkorna hos båda och undviker deras
respektive nackdelar då de täcker upp varandras svaga sidor.
Den modell för personlig brandvägg som den här rapporten föreslår bygger framför
allt på ett sessionsfilter som placeras mellan transportlagret och sessionslagret i
OSI-modellen. Sessionsfiltret fångar upp alla program som försöker använda nätverket
och kontrollerar att de är tillåtna. För program som tillåts skickas regler ner till
paketfiltret för att öppna upp för den aktuella sessionen. För att samordna de två
filtren är det nödvändigt med en kontrollapplikation. Kort sammanfattat fungerar
brandväggen på följande vis (se figur 3.1):
7. Applikation
6. Presentation
5. Session
Sessionsfilter
4. Transport
3. Nätverk
Paketfilter
2. Datalänk
1. Fysisk länk
1. Tillåt session?
2. Ja/Nej
3. Ny regel
Kontrollapplikation
Figur 3.1. Övergripande bild över flödet i modellen.
1. Alla applikationer som vill använda nätverket kommer att fångas upp och
15

16 KAPITEL 3. MODELL
stoppas i sessionsfiltret. Sessionsfiltret frågar kontrollapplikationen om programmet
får använda nätverket.
2. Har programmet inte tillåtelse att komma ut på nätverket kommer det inte
längre än så här.
3. Om programmet är tillåtet skickar kontrollapplikationen regler till paketfiltret
som öppnar upp för just den här sessionen och sessionsfiltret får signal från
kontrollapplikationen att det ska tillåta programmet.
Idén med att använda sig av dynamiska regler är att endast tillåta reglerna under
en kort tid när själva anslutningen görs istället för att ha regler som ligger aktiva hela
tiden. Genom att överlåta till kontrollapplikationen att skapa regler till paketfiltret
som är knutna till till en session och ett visst program får man regler som är lätta
att verifiera att de gör det de ska och nätverksadministratörer kan koncentrera
sig på att sätta upp den övergripande säkerhetspolicyn. En kontrollapplikation kan
dessutom enkelt samla information i logfiler att använda vid felsökning.
3.1 Krav för modellen
Målet för vår modell är att den ska klara av de fem huvudfunktioner för brandväggar
som ställdes upp i kapitel 1. Modellen löser dessa fem huvudfunktioner på följande
sätt:
• Skydda mot säkerhetsproblem i operativsystemet. Genom att använda
sig av två filter, ett på vardera sida om operativsystemets nätverksstack,
skyddar man sig mot utnyttjande av buggar i operativsystemet och dess implementation
av nätverksstacken. Oberoende av nätverkstrafikens riktning måste
den passera ett filter som verifierar dess legitimitet innan den tillåts behandlas
av nätverksstacken.
• Förhindra åtkomst till information. Kontrollapplikationen är den enda
som får öppna för trafik genom paketfiltret och därmed har den ensamrätt
att bestämma över vilka informationsflöden som får passera. Endast i det fall
då trafik initieras inifrån, passerar sessionsfiltret samt följer de regler som
kontrollapplikationen har att gå efter öppnar denne för trafik genom paketfiltret.
Detta gör att ingen information blir åtkomlig utifrån eftersom denna
informationsström är initierad utifrån.
• Förhindra informationsläckor. Precis som ovan gäller att endast i det fall
då trafik initieras inifrån, passerar sessionsfiltret samt följer de regler som kontrollapplikationen
har att gå efter öppnar denne för trafik genom paketfiltret.
Detta gör att kontrollapplikationen kan sköta autentisering baserad på information
från sessions-, presentations- och applikationslagret i OSI-modellen.
Kontrollapplikationen kan alltså agera efter ett strikt regelverk som endast

3.2. SESSIONSFILTER 17
tillåter begränsade informationsflöden för ett begränsat antal applikationer.
På detta sätt kan trojaner och liknande program förhindras skicka ut information
från en infekterad enhet.
• Upprätthålla en säkerhetspolicy. Genom möjligheten att sätta regler för
kontrollapplikationen baserad på information från toppskiktet av OSI-modellen
kan denna modell hjälpa till att garantera att kommunikation endast tillåts
efter strikta regler. På detta sätt kan en implementation av denna modell
hjälpa till att upprätthålla en övergripande säkerhetspolicy för ett stort antal
enheter.
• Underlätta granskning. Eftersom alla program som vill använda nätverket
passerar genom sessionsfiltret och enkelt kan loggas av kontrollapplikationen
kan man på ett lättare sätt spåra och undersöka vad som exempelvis hände
vid ett intrång.
3.2 Sessionsfilter
Sessionsfiltret har två uppgifter, dels att stoppa ej tillåten nätverkstrafik från att
komma ut på ett tidigt stadium, dels att koppla samman nätverkstrafik med det
program som gav upphov till den. Att sammankoppla nätverkstrafik med det som
genererade trafiken är för de flesta operativsystem omöjligt att göra på den nivå som
paketfilter opererar eftersom all nätverkstrafik hanteras som enskilda paket. Detta
är en av de svagheter som finns med paketfilter och för att komma åt den svagheten
låter man sessionsfiltret utgöra kopplingen mellan program och nätverkstrafik. Sessionsfiltret
har ingen egen regelhantering utan förlitar sig på kontrollapplikationen
för att avgöra om en nätverksanslutning ska tillåtas eller inte vilket förenklar den
övergripande designen.
Flödesdiagrammet i figur 3.2 visar hur sessionsfiltret fungerar och hur det integrerar
med kontrollapplikationen. Vid två tillfällen skickar sessionsfiltret information
till kontrollapplikationen. När ett program försöker göra en ny anslutning
skickas information om det upp till kontrollapplikationen som svarar om sessionsfiltret
ska tillåta anslutningen eller inte. Även när en anslutning avslutas skickar
sessionsfiltret upp information om detta så att kontrollapplikationen kan ta bort de
regler som hör samman med den session som avslutats.
De nackdelar som finns med ett sessionsfilter är att det inte kan skydda nätverksstacken
från attacker utifrån eftersom det ligger ovanför hela nätverksstacken
och kan inte heller analysera nätverkstrafiken som den ser ut på nätverket. Oftast
består nätverkstrafiken på den här nivån av strömmar av data eftersom det är först
längre ner i stacken som data strömmarna blir till paket. Men med hjälp av ett
paketfilter kan man analysera både de protokoll som används för transportlagret
och nätverkslagret samt skydda datorn från attacker utifrån.

18 KAPITEL 3. MODELL
Ny session
Fråga
kontrollapplikation
3.3 Dynamiskt paketfilter
Tillåt
session?
Nej
Avsluta
session
Ja
Vänta på data
Avsluta
session?
Ja
Informera tjänst
Figur 3.2. Flödesdiagram över sessionsfiltret.
Ett paketfilter är både enkelt att implementera, ger ett starkt skydd från intrång
utifrån samt kräver lite resurser. Paketfiltret består av två komponenter, en regellista
med regler som kontrollapplikationen har genererat och skickat ner samt en
tillståndsmaskin med en tillståndstabell som där tillstånden för anslutningar genom
paketfiltret sparas. Regellistan är sorterad i prioritetsordning och den första regel
som hittas används. Nya regler läggs till överst i regellistan vilket kan ses som ett
naivt sätt att hantera regler på och garanterar inte att vissa regler alltid gäller
(Hazelhurst, 2001). För vår design är detta är dock inget problem eftersom tanken
är att inte ska finnas några regler som alltid ska gälla, utan man ska börja med
en tom regellista för att sedan lägga till och ta bort regler dynamiskt allt eftersom
olika program använder nätverket.
Genom att använda sig av dynamiska regler som specificerar en viss anslutning
tillsammans med en tillståndsmaskin för nätverksanslutningar ökar man säkerheten
avsevärt i jämförelse med ett traditionellt paketfilter eftersom tiden som ett
regel gäller är relativt kort samt att den gäller bara för kommunikation mellan två
noder. Om man skulle spoofa nätverksadresser för att utnyttja en regel i paketfiltret
kommer tillståndsmaskinen att märka att paketen inte matchar tillståndet
som anslutningen är i och kasta bort dem. Figur 3.3 beskriver flödet för ett paket
genom paketfiltret. Genom att använda en tillståndsmaskin behöver man bara söka
i regellistan när en ny anslutning görs, resten av paketen som hör till anslutningen
matchas mot tillståndet för anslutningen i tillståndstabellen.
Nej

3.4. KONTROLLAPPLIKATION 19
Sök
tillståndstabell
Finns
tillstånd?
ja
Tillåtande
tillstånd?
ja
Uppdatera
tillståndstabellen
3.4 Kontrollapplikation
Nytt paket
nej
Blockera
nej nej
paket
Släpp igenom
paket
Figur 3.3. Flödesschema över paketfiltret.
Sök regellista
Tillåtande
regel?
ja
Lägg till i
tillståndstabellen
Är det program som samordnar de två filtren och hanterar regellistan över program
som får använda nätverket. Kontrollapplikationen verifierar vilket program som
försöker använda nätverket och använder sig av en regellista för att avgöra vilken typ
av nätverksaccess programmet får göra. Om programmet är godkänt skickas en regel
ner till paketfiltret för att öppnar upp för aktuella sessionen. När sessionen avslutats
indikerar sessionsfiltret detta till kontrollapplikationen som då tar bort den aktuella
regeln från paketfiltret. Själva flödet för kontrollapplikationen är enkelt och visas i
figur 3.4, dock finns det svårigheter med hur man verifierar en applikationen eller
om den utför kommandon åt någon annan applikation. Eftersom implementationen
av där här funktionen skiljer sig mycket mellan olika operativsystem samt att det
ligger utanför området brandväggar och snarare inom området för antivirus och
antispyware programvara har vi valt att inte beskriva någon specifik teknik för
att verifiera ett program. Generellt sätt kan man dock säga att man bör verifiera
program med någon form av hash-funktion, kontrollera vilka bibliotek programmet
har laddat samt undersöka processträdet för programmet för att kontrollera att
även de program som har startat programmet är betrodda.

20 KAPITEL 3. MODELL
Matcha PID mot
program
verifiera program
Sök regellista regel finns
Förfrågan om ny
anslutning från
sessionfiltret
Nej
Ja
Meddela
sessionsfiltret
att stoppa
anslutningen
Nej
tillåt
anslutning
Figur 3.4. Flödesschema över kontrollapplikationen.
Ja
Skapa regler för
paketfiltret
Skicka regler till
paketfiltret
Meddela
sessionsfiltret att
tillåta
anslutningen

Kapitel 4
Fallstudie - Microsoft Windows XP
Den stora användningen av Windows XP som operativsystem i konsumentdatorer
har drivit fram en stor efterfrågan på säkerhetsprogramvara som brandväggar och
antivirusprogram. Det finns många produkter ute på marknaden att köpa, men lite
finns skrivet om hur de egentligen fungerar. Viktigt är att belysa hur säkerhetsprogram
som dessa fungerar för att kunna använda dem på rätt sätt. Säkerhetsmässigt
brukar man säga att en ökad insyn och förståelse för funktionen bara kan höja den
faktiska säkerheten av ett system. För att testa vår modell har vi implementerat
en personlig brandvägg för Microsofts operativsystem Windows XP. Det finns flera
anledningar att vi valt detta operativsystem bland annat följande:
• Windows XP används som operativsystem i majoriteten av världens konsumentdatorer.
• Windows XP är det operativsystem som i störst utsträckning utsätts för regelbundna
attacker, främst baserade på svagheter i operativsystemet samt att
konsumentanvändare är dåliga att skydda sig mot dessa.
• Det finns få artiklar, om några alls, som presenterar design och implementation
av ett sessionsfilter i Windows XP.
• Det finns få artiklar skrivna om hur en implementation av en kombination av
sessions- och paketfilter i Windows XP kan göras.
4.1 Operativsystemsmodell
Microsoft Windows XP har två abstraktionslager där programkod körs (Wikipedia,
2006a). Den del av operativsystemet som tillhandahåller grundläggande funktionalitet
för program kallas vanligtvis kärna eller kernel (se figur 4.1). Kärnan är
ansvarig för att tillhandahålla ett enkelt gränssnitt för program att komma åt funktionalitet
som till exempel att läsa och skriva till disk. Lagret ovanför kallas normalt
applikationslager eller user space och det är i detta lager som vanliga program körs.
21

22 KAPITEL 4. FALLSTUDIE - MICROSOFT WINDOWS XP
Applikationslager
OSkärna
IOhanterare
Figur 4.1. Abstraktionslager i Windows XP
I själva verket är dessa två lager uppdelade i ytterligare lager, där varje nytt
lager introducerar en ny nivå av abstraktion, men det finns en distinkt skillnad
mellan kärnan och applikationslagret. All programkod som körs i kärnan har högre
prioritet än den som körs i applikationslagret. Dessutom har programkod som körs
i kärnan i stort sett obegränsad access till hela systemet. Dock finns det nackdelar
med kärnan till skillnad från applikationslagret. Skulle någon del av programmet
vara felaktigt eller sluta fungera som det skall är sannolikheten mycket stor att hela
systemet havererar. Normalt är inte heller enkla standardfunktioner tillgängliga
vilket gör det mycket svårare att skriva program.
Programkod som körs i applikationslagret har däremot begränsad access till systemet.
Alla grundfunktioner är normalt tillgängliga genom standardiserade gränssnitt.
Genom denna nivå av abstraktion kan man enkelt skriva ett program som
använder sig av standardgränssnitt för att till exempel läsa och skriva till disk. Programmet
behöver således inte ändras för olika lagringsmedium som till exempel en
hårddisk, en brännbar CD-skiva eller ett minneskort. Ytterligare en skillnad som
har avgörande effekt är att program som körs i applikationslagret normalt delar på
alla resurser. Program som körs i kärnan kan ibland ha ensamrätt till hela systemet
vilket i vissa fall försvårar för utvecklaren. Ett sådant program kan till exempel inte
vänta på att någon annan del av systemet skall bli klar eftersom det har exklusiv
access till alla resurser.
Normalt sköts all kommunikation till och från kärnan i Windows XP av en
del av operativsystemet som kallas IO-hanterare eller Input Output manager. IOhanteraren
är även ansvarig för kommunikationen mellan olika lager i kärnan. Denna
kommunikation är i Windows XP paketbaserad. Den vanligaste typen av kommunikation
sker med datafragment kallade IO-paket eller Input Output Request Packet
(IRP).
4.1.1 Drivrutinsmodell
Drivrutin eller driver kallas en bit programkod som utökar kärnans funktionalitet.
Vid installation av en drivrutin installeras programmet in i kärnan och körs igång.
En tillverkare av till exempel ett nätverkskort är normalt sett ansvarig för att

4.1. OPERATIVSYSTEMSMODELL 23
tillhandahålla en drivrutin som styr nätverkskortet och ett standardiserat gränssnitt
mot resten av systemet. Kärnan i Windows XP består till stor del av lager ovanpå
lager av drivrutiner som kommunicerar med IO-paket via IO-hanteraren (se fig 4.2).
Applikationslager
Kärna
Hårdvara
TCP/IP-drivrutin
Ethernet-drivrutin
Drivrutin nätverkskort
Nätverkskort
Hårdvaruabstraktionslager
Applikation
API
Executive
...
Minneshant.
IO-hanterare
Processhant.
...
Fysisk enhet
Figur 4.2. Drivrutinsmodellen i Windows XP
För kommunikation mellan applikationer och komponenter i kärnan brukar denna
kommunikation gå genom ett applikationsgränssnitt eller Application Programming
Interface (API). Det finns flera sätt för ett sådant gränssnitt att implementera
själva kommunikationen, men det vanligaste är att använda sig av IO-paket. Att
från en komponent i kärnan initiera kommunikation till en applikation i applikationslagret
är svårt varför normalt sett applikationen är den som initierar trafiken.
En vanlig metod är att applikationen förbereder och skickar ner ”tomma” IO-paket
som drivrutinen buffrar upp. När denne är redo att skicka upp information tar den
ett ”tomt” IO-paket ur högen, fyller i information och returnerar till applikationen.
Applikationen som har legat och väntat på att få tillbaka sina IO-paket kan nu läsa
ut informationen, förbereda ett nytt ”tomt” IO-paket och skicka ner det.
4.1.2 Nätverksmodell
Nätverksmodellen i Windows XP består av flertalet lager inuti och utanför kärnan
(se figur 4.3). Denna modell är en anpassning av TCP/IP-modellen (se figur 2.2)
för att passa drivrutinsmodellen i Windows XP.
Applikationer använder sig normalt av något av de gränssnitt (API) som finns
för nätverkskommunikation såsom Winsock API för TCP/IP. Lagret där Winsock
finns kallas för API-lagret och där finns olika gränssnitt för att kommunicera över
nätverk.

24 KAPITEL 4. FALLSTUDIE - MICROSOFT WINDOWS XP
OSI-modellen XP-modellen
7. Applikation
6. Presentation
5. Session
4. Transport
3. Nätverk
2. Datalänk
1. Fysisk länk
Applikationer och tjänster
Winsock
API
NetBios
API
Servers
TCP/IP IPX/SPX NetBEUI
Drivrutin
nätverkskort
TDI
NDIS
HAL
Drivrutin
nätverkskort
Nätverkskort Nätverkskort
Figur 4.3. Nätverksmodellen i Windows XP
Applikationslager
Under API-lagret finns ett standardiserat gränssnitt mot alla nätverksprotokoll
implementerade i kärnan kallat TDI-lagret (Transport Driver Interface) (Microsoft,
2006c). TDI är ett gemensamt gränssnitt alla protokoll måste implementera för att
API-lagret ska kunna kommunicera med dem. I det här lagret finns bland annat
TCP/IP-protokollet implementerat.
Protokollen i TDI-lagret kommunicerar i sin tur med nästa lager via ett gränssnitt
kallat NDIS-lagret (Network Driver Interface Specification). NDIS är ett gemensamt
gränssnitt för drivrutiner för nätverkskort. Protokollagret får på detta
sätt ett standardiserat gränssnitt att kommunicera mot. NDIS består i sig själv av
flera olika lager. Drivrutiner i NDIS-lagret kommunicerar i sin tur med hårdvaran
via HAL-lagret (Hardware Abstraction Layer). Se DDK-dokumentationen (Driver
Development Kit) från Microsoft för mer information (Microsoft, 2006e).
4.2 Filtreringstekniker
Det finns flera sätt att implementera ett nätverksfilter i Windows XP där alla varianter
har sina fördelar och nackdelar. Huvudsakligen finns det två huvudkategorier
av filter:
• Filter som är implementerade i applikationslagret, det vill säga på samma
nivå som vanliga program körs på.
Kärna
• Filter som är implementerade i kärnan, det vill säga som drivrutiner.
Generellt är det enklare att implementera ett filter i applikationslagret eftersom
det finns fler funktioner och bibliotek tillgängliga samt att fel bara påverkar den

4.2. FILTRERINGSTEKNIKER 25
applikationen som felet uppstod i, inte hela systemet. Att implementera ett filter
i kärnan ställer högre krav på koden. Många funktioner och bibliotek som finns i
applikationslagret finns inte i kärnan. Dessutom orsakar ett fel i en drivrutin med
största sannolikhet att hela systemet havererar. Dock finns det fördelar att implementera
filter i kärnan, bland annat körs de med högre prioritet, de är svåra att
ta bort, man får tillgång till paketen på ett tidigt stadium (vilket gör att de inte
behöver passera hela nätverksstacken) och det är svårt att gå runt ett filter i kärnan.
Nedan följer en genomgång av filtreringstekniker som finns tillgängliga i Windows
XP.
4.2.1 Filtrering i applikationslagret
• Winsock Layered Service Provider (LSP). LSP är en del av Winsock
gränssnittet och gör det möjligt att på ett enkelt sätt filtrera eller implementera
tjänster så som Quality of Service (QoS) för TCP/IP. Dock är det möjligt
att anropa TDI-lagret direkt och på så sätt gå förbi en LSP. Vill man inspektera
alla paket kan man inte förlita sig på Winsock LSP, utan måste använda
andra tekniker.
• Packet Filtering Interface. Detta gränssnitt är en del av det så skallade
IP helper API i Windows XP och gör det möjligt för applikationer att ange
ett antal regler som används av TCP/IP-komponenter för att filtrera paket.
Detta filter är inbyggt i olika TCP/IP-komponenter i kärnan och själva filtret
kallas IP Filter. Filtrering sker på IP-adresser och portnummer. Dock är det
möjligt att gå förbi även denna mekanism genom att exempelvis installera ett
eget protokoll parallellt med TCP/IP protokollet.
• Winsock Replacement DLL (Dynamically Linked Library). Innan det
var möjligt att bygga ut Winsockgränsnittet med en LSP var det ända sättet
att byta ut vissa av DLL-erna mot nya. På detta sätt kunde man filtrera
alla anrop till Winsock och anropa de ursprungliga funktionerna i Winsock
när så behövdes. Det finns flera anledningar till att det här var och är en
dålig idé. En av anledningarna är att gränssnittet mellan DLL-erna är privata
och odokumenterade vilket gör att en uppdatering av operativsystemet kan
medföra att en DLL slutar att fungera.
4.2.2 Filtrering i kärnan
• TDI-Hook (TDI-filter). Genom att lägga sig som ett lager ovanpå protokolldrivrutinen
för TCP/IP kan man filtrera alla IO-paket som passerar. Det
finns två sätt att filtrera IO-paket till TDI-lagret. Antigen kan man använda
sig av IoAttachDeviceXYZ-anrop för att filtrera ovanför TDI eller så kan man
ersätta utvalda funktioner i anropstabellen (Dispatch Table) för TDI så att
alla IO-paket filtreras. Dessa är en relativt drastiska metoder som genskjuter

26 KAPITEL 4. FALLSTUDIE - MICROSOFT WINDOWS XP
alla anrop till TDI-lagret. Båda teknikerna kräver en djup förståelse för TDI
gränssnittet och Windows XP vilket gör dem relativt svåra att implementera.
Implementationen försvåras ytterligare av att det finns lite, om alls någon,
dokumentation om hur man skall gå tillväga. Med ett TDI-filter kan man inte
skydda TCP/IP-stacken från attacker utifrån eftersom filtret installeras ovanför
TCP/IP protokollet. Fördelen är att man kan filtrera på information från
sessions- och applikationsnivån i OSI-modellen (se figur 2.2) samt att ett filter
av denna typ är mycket svårt att avinstallera.
• NDIS Intermediate (NDIS-filter). Denna typ av filter installeras som
en komponent i NDIS-lagret. NDIS tillhandahåller ett inbyggt stöd för denna
typ av filter vilket gör en implementation enkel. Microsoft rekommenderar
att paketfilter implementeras som NDIS-filter och tillhandahåller i sin
DDK-dokumentation ett exempel för att fånga paket kallat Passthru (Microsoft,
2006e). En nackdel är att ett NDIS-filter endast filtrerar på paketnivå.
Det finns alltså ingen information från applikations- eller sessionsnivån i OSImodellen
att filtrera på (se figur 2.2). Det går således inte att filtrera dataströmmar
efter vilken applikation som kommunicerar. Fördelen med NDISfilter
är att man har tillgång till datapaketen så som de ser ut på nätverket
och att filtreringen sker under TCP/IP-stacken.
• NDIS-Hook. På samma sätt som för ett TDI-filter kan man ersätta utvalda
funktioner i anropstabellen för NDIS och på detta sätt filtrera alla anrop till
NDIS. Även denna typ av filter är relativt drastisk och saknar dokumentation
och tydliga exempel. Fördelen med detta filter jämfört med ett NDIS
Intermediate-filter är att de generellt är mycket svåra att avinstallera eller
kringgå. Nackdelen är istället att dokumentationen är knapphändig, de är
svåra att implementera och att NDIS kan sluta fungera vid en eventuell uppgradering.
• Firewall-Hook. Microsoft tillhandahåller ett gränssnitt som kom i och med
Windows 2000 för ett generellt brandväggsfilter inbyggt i nätverksstacken.
Dock avråder Microsoft från att använda det idag eftersom det finns kända
problem med implementationen av detta filter. Filtreringen sker på för hög
nivå i stacken för att fungera som en effektiv brandvägg.
• Filter-Hook. Genom att registrera en filterfunktion i det inbyggda IP Filter
som används av bl.a. IP helper-API kan man utöka IP Filter-funktionaliteten.
TCP/IP-stacken anropar denna funktion på många olika ställen och man kan
på detta sätt implementera ett filter som inte lägger till något nytt lager
till stacken. Fördelar är bland annat att man kan filtrera på datapaketen
direkt från nätverket samt skydda transportlagret av TCP/IP (Jackson, 2005).
En nackdel med denna teknik är att endast ett filter kan vara installerat åt
gången.

4.3. DESIGN 27
4.3 Design
Utgångspunkten för designen är att visa att vår teori fungerar i en implementation.
För att kunna göra detta inom ramen för det här arbetet har vissa praktiska detaljer
utelämnats. Bland annat har inget grafiskt användargränssnitt utvecklas och
program som vill använda nätverket identifieras endast utifrån namnet på deras exekverbara
fil. En praktisk implementation borde göra en utförligare identifikation av
program, vilka bibliotek varje program har laddat, vem som startade programmet
i fråga och så vidare. Med denna implementation vill vi visa ett koncept.
4.3.1 Mål och krav för implementationen
Prototypen skall implementera de grundfunktioner som presenterats i teoridelen
(kapitel 3). Målet med implementationen är att visa att konceptet med två filter
och dynamiska regler fungerar och kan utgöra grunden för en säker personlig brandvägg.
Utöver de grundläggande kraven för funktionalitet har vi ställt upp följande
implementationsspecifika krav:
• Det skall vara svårt för obehöriga att förändra filtrens beteende.
• Det skall vara svårt att kringgå filtren.
• Implementationen måste vara effektiv i bemärkelsen att normal användning
ej skall medföra någon försämring i prestanda för slutanvändaren.
4.3.2 Begränsningar
Eftersom implementationen görs för att visa ett koncept och ej en färdig produkt
har följande begränsningar satts upp:
• Förenklad tillståndshantering En enkelt version av tillståndhantering i
paketfiltret som inte verifierar sekvensnummer och fönsterstorlek i TCP/IPprotokollet.
• Förenklad identifikation av program Program som vill använda nätverket
identifieras endast utifrån namnet på deras exekverbara fil.
• Förenklad kontrolltjänst Inget grafiskt gränssnitt för kontrolltjänsten. Som
följd av begränsningen i identifikation av program har heller inget avancerat
regelverk för access baserat på applikation satts upp.
4.3.3 Arkitektur
Implementationen är precis som modellen uppdelad i två filter och en kontrollapplikation.
Utifrån kraven och informationen om filtreringstekniker i Windows XP
anser vi att båda filtren måste implementeras i kärnan. Genom att installera filtren

28 KAPITEL 4. FALLSTUDIE - MICROSOFT WINDOWS XP
Brandväggstjänst
Applikationer och tjänster
Winsock
API
NetBios
API
Servers
TCP/IP IPX/SPX NetBEUI
Drivrutin
nätverkskort
TDI-filter
TDI
NDIS
NDIS-filter
HAL
Drivrutin
nätverkskort
Nätverkskort Nätverkskort
Applikationslager
Kärna
Figur 4.4. Arkitektur för implementationen
som drivrutiner i kärnan blir de svåra att kringgå och man får bland annat tillgång
till paketen innan de når TCP/IP stacken (se figur 4.4).
Som paketfilter har vi valt att använda oss av ett NDIS-filter. Filtreringen sker
på en låg nivå mellan nätverkskortet och TCP/IP-stacken. Ytterligare en fördel är
att det finns mycket information att tillgå om denna typ av drivrutiner, bland annat
i form av ett exempel i Microsoft DDK (Microsoft, 2006e).
Vårt sessionsfilter har vi valt att lägga mellan transportlagret och applikationslagret
i TCP/IP-modellen. Detta filter har vi valt att implementera som ett TDIfilter.
Genom att ändra anropstabellen för det ursprungliga TDI-lagret att hänvisa
till våra egna funktioner genskjuter vi alla anrop till TDI-lagret. Godkända anrop
vidarebefordras till det ursprungliga TDI-lagret. Det finns dock vissa risker med ett
TDI-filter, bland annat att det är komplicerat att implementera då det inte finns
någon, eller mycket lite dokumentation om hur man gör.
Själva kontrollapplikationen har vi valt att implementera som en tjänst vilket
bland annat innebär att den kan starta utan att en användare behöver start ett
program. All konfiguration och alla regler ligger i registret, som är en databas med
inställningar som finns tillgängligt i Windows, eftersom det inte finns något filsystem
tillgängligt när drivrutinerna laddas under uppstart av operativsystemet.
För att kommunicera med drivrutinerna använder sig kontrolltjänsten av IOCTLmeddelanden
(Input Output Control Codes) som skickas som IO-paket ner till drivrutinerna.
En applikation försöker öppna en anslutning fångas detta anrop i TDI-filtret.
Filtret skickar en förfrågan till brandväggstjänsten som får avgöra huruvida anslut-

4.3. DESIGN 29
ningen är tillåten eller inte. Brandväggstjänsten verifierar i sin tur att det finns
en regel som tillåter applikationen att öppna anslutningen. Ifall anslutningen är
legitim skickar brandväggstjänsten ner en ny regel till NDIS-filtret som öppnar för
kommunikation (se figur 4.5).
Applikation TDI filter Tjänst
TDI_CONNECT
4.3.4 Paketfilter
svc_io_query_service
ALLOW
ValidateProcess()
IOCTL_NDIS_
ADD_RULES
TDI_CONNECT
NDIS filter
Figur 4.5. Förenklat sekvensdiagram för implementationen
Paketfiltret installeras som en NDIS intermediate driver och lägger sig som en integrerad
del av NDIS i nätverksmodellen för Windows XP (se figur 4.4). En intermediate
driver är en speciell komponent i NDIS som lägger sig ovanpå varje drivrutin för
nätverkskort installerade i NDIS-lagret. Tillgängligt för filtrering finns här hela nätverkspaket
precis som de skickas ut på det medium man anslutit sig till. Denna plats
är således utmärkt för filtrering av in- och utgående paketströmmar. Paketfiltret är
konstruerat utifrån grundexemplet Passthru i DDK-dokumentationen (Microsoft,
2006e). Utöver grundkomponenterna läggs några komponenter till enligt figur 4.6.
En enkel och effektiv tillståndshantering för anslutningar har implementerats
efter flödesdiagrammet i figur 3.3. För att utnyttja teknikerna för dynamiska paketfilter
(se 2.2.3) har även UDP-protokollet hanteras som ett anslutningsorienterat
protokoll. En timer har implementerats för att hålla koll på livslängden för tillstånden
i tillståndstabellen. Tillståndshanteringen för TCP kontrollerar uppkopplingsoch
nerkopplingsfaserna för TCP (Wikipedia, 2006d) medan tillståndshanteringen
för UDP är förenklad till att det antingen finns en uppkoppling eller inte. Genom
denna implementation skyddar NDIS-filtret operativsystemets TCP/IP-stack från
hot utifrån. Dessutom agerar paketfiltret som ett extra filter för trafik inifrån. Skulle
en applikation installera en parallell protokollstack för att försöka gå runt TDI-filtret
kommer man inte längre än hit. Alla paket stoppas som ej tillhör en tillåten paketström
som kontrollapplikationen öppnat för genom att skicka ner nya regler. All
trafik som filtret ej känner igen eller ej har någon regel som explicit tillåter den
TDI

30 KAPITEL 4. FALLSTUDIE - MICROSOFT WINDOWS XP
Utgående trafik
Paketfilter
Inkommande trafik
Överliggande protokoll
Regellista
Protocol
Tillståndstabell
Miniport
Timer
Underliggande NDIS-drivrutin
Regelhantering
Figur 4.6. Komponenter i paketfilter
IOCTL
konfiguration
stoppas. För enkelhets skull har detta filter endast implementerats för att hantera
IP-protokoll version 4, men en enkel anpassning skulle göra det kompatibelt med
IP-protokoll version 6.
4.3.5 Sessionsfilter - TDI filter
Sessionsfiltret installeras ovanpå TCP/IP-protokollet som en TDI-Hook. På detta
sätt genskjuter man alla anrop till TDI-lagret och därmed alla normala uppkopplingsförsök
gjorda från applikationslagret. Eftersom detta filter installeras ovanför
TCP/IP-stacken kan vi avbryta anslutningen så tidigt som möjligt och få minimal
inverkan på TCP/IP-stacken. Sessionsfiltrets uppgift är att identifiera och sammankoppla
sessions- och applikationsinformation. Alla normala kommunikationskanaler
öppnas genom att använda ett API som kommunicerar med TDI. Vid denna kommunikation
sker ett IOCTL-anrop till TDI-lagret och detta anrop körs i programmets
egna process. Detta gör att man under ett anrop kan ta reda på vilken process
eller PID (Process Identification Number) man är och därigenom vilket program
som gjort anropet. Ett anslutningsförsök i TDI är alltså förknippat med följande
information:
• Adressinformation gällande anslutningen, t.ex. käll- och destinationsadresser,
portar och protokoll.
• PID för den process som gjort anropet.
Det finns inget väldokumenterat sätt att ta reda på vilken exekverbar fil som en viss
PID tillhör i en drivrutin varvid själva mappningen till vilket program som motsvarar
en PID måste göras i applikationslagret. TDI-filtret måste därför ta hjälp av
kontrolltjänsten för att verifiera att programmet som gör anropet har rättigheter att

4.3. DESIGN 31
öppna en anslutning. Eftersom kontrollapplikationen körs i applikationslagret och
därmed har lägre prioritet än en drivrutin måste denna förfrågan göras asynkront.
För att hantera detta har vi implementerat ett kösystem där en tråd som gör en
förfrågan lägger en semafor i en väntekö för att sedan ligga och vänta på att svar
skall inkomma. För att det inte skall uppstå någon lägre låsning har vi även en
timer som avbryter väntan efter en tid. Dessa system har gjort att TDI-filtret har
relativt många komponenter (se figur 4.7).
IOCTL-anrop till TDI
TDI-filter
Adressobjekt
IRP-kö
Anrop till återkopplingsfunktion
(Callback)
TDI-klient
IO-hanterare
Associerade
objekt
Förfrågningar
som väntar på
svar
TDI-lager
Anslutningar
Timer
Figur 4.7. Komponenter i TDI-filtret
IOCTL
förfrågningar/
svar
Konceptuellt fungerar sessionsfiltret relativt enkelt och är baserat på flödesdiagrammet
i figur 3.2. Vad gäller tillståndshantering för en uppkoppling i TDI-lagret
är denna inte lika lättöverskådlig (se figur 4.8). Konceptuellt fungerar denna som
följande:
1. Öppna två ändpunkter för kommunikation (adresser).
2. Associera dessa.
3. Anslut.
Det finns knapphändig dokumentation om hur anslutningar hanteras i TDI men
för en utförligare beskrivning se appendix A.
4.3.6 Kontrolltjänst
Kontrolltjänsten är ansvarig för att knyta samman sessions- och paketfiltret. Denna
komponent är även ansvarig för den övergripande regelhanteringen. Komplexiteten

32 KAPITEL 4. FALLSTUDIE - MICROSOFT WINDOWS XP
start
ZwCreateFile
En öppen
adress
ZwClose
slut
ZwCreateFile
ZwClose
ZwClose
TDI_SEND
TDI_RECEIVE
Två öppna
adresser
ZwClose
Uppkopplad
TDI_ASSOCIATE_ADDRESS
TDI_DISASSOCIATE_ADDRESS
TDI_DISCONNECT
TDI_CONNECT
TDI_SET_EVENT_HANDLER
Uppkopplad
med
callback
TDI_SEND
TDI_RECEIVE
TDI_EVENT_RECEIVE
Associerade
adresser
Callback
registread
TDI_DISCONNECT
~TDI_SET_EVENT_HANDLER
TDI_CONNECT
ZwClose
~TDI_SET_EVENT_HANDLER
TDI_SET_EVENT_HANDLER
ZwClose
Figur 4.8. Tillståndsdiagram för en session i TDI-filtret
för reglerna för ett sessionsfilter gör att implementationen av regelhantering underlättas
avsevärt då den flyttas till kontrolltjänsten.
För de förfrågningar kontrolltjänsten får från TDI-lagret kan kontrolltjänsten
avgöra huruvida en applikation får upprätta en anslutning eller ej. TDI-lagret skickar
en förfrågan med följande information:
• PID för den process som försöker öppna en anslutning.
• Adressinformation om vilket protokoll och vart processen vill ansluta.
Man kan även ta reda på vilka bibliotek som denna process har laddat och vem
som startat den. Från denna information samt vilken adress den försöker ansluta till
kan man sedan bestämma huruvida en applikation (exekverbara filer och bibliotek)
får genomföra anslutningen eller ej. Möjligt i detta läge är även att fråga användaren
om anslutningen är legitim eller ej. Det är många kommersiella program som
använder sig av denna typ av kontroll, vanligtvis presenteras ett fönster med en
fråga om ett visst program får ansluta eller ej. Den grundläggande funktionaliteten
för tjänsten baseras på flödesdiagrammet i figur 3.4.
I det fall tjänsten beslutat att anslutningsförsöket är legitimt skickar denne ner
en ny regel till NDIS-filtret för att öppna för trafik till denna anslutning. Tjänsten
kommunicerar med de två drivrutinerna med hjälp av IOCTL-meddelanden. För

4.3. DESIGN 33
NDIS filtret används dessa för att lägga till, ta bort och rensa regler från paketfiltret.
NDIS filtret skickar aldrig själv meddelanden till tjänsten utan hanterar en
egen regellista som tjänsten är ansvarig för att uppdatera. IOCTL-meddelanden
till och från TDI-filtret är av två typer. Antigen informerar TDI-filtret tjänsten till
exempel om att en anslutning har avslutats, eller skickar TDI-filtret en förfrågan
om en anslutning får göras. Tjänsten har en egen regellista som består av regler per
program.

Kapitel 5
Tester
För att testa och utvärdera om implementationen och därav modellen uppfyller
de mål och krav som ställts upp för den här rapporten utfördes ett antal tester.
Implementationstester för att utvärdera att implementationen fungerade som det
var tänkt, penetrationstester för att verifiera att implementationen klarar av externa
och interna attacker samt regeltester för att säkerhetsställa att en säkerhetspolicy
implementeras på ett korrekt sätt. Utifrån dessa tester kan man sedan dra slutsatser
om implementationen uppfyller de fem mål som ställdes upp i avsnitt 1.1 och därav
visa om implementationen innehar de egenskaper som beskrivs för modellen.
Implementationstesterna utfördes i två delar. För att upptäcka valideringsfel
och avgränsningsfel i implementationen användes kodanalysverktyg. Koden i NDIS
och TDI drivrutinerna analyserades regelbundet vid kompilering med hjälp av PRE-
Fast for Drivers (Microsoft, 2006b) som är ett verktyg för statisk kodanalys och som
kan upptäcka problem som inte brukar upptäckas av vanliga kompilatorer. Tjänsten
analyserades med hjälp av kodanalysverkyget i Visual Studio 2005 (Microsoft,
2006d). Den andra delen av implementationstester gjordes genom för att testa om
brandväggen verkligen blockerade paket och utförde det som reglerna beskrev. Dessa
tester gjordes med hjälp av enkla program som ping och telnet.
Penetrationstesterna bestod av externa och interna attacker. För de externa penetrationstesterna
användes paketgenererings- och nätverksscanningsverktyg. För
interna penetrationstester (program som försöker ta sig ut) användes program från
en websida med testprogram (Kaddouch, 2006). Dock utfördes inte alla deras tester
utan bara sådana som motsvarade målen för implementationen. Framförallt utlämnades
tester som använder sig av tekniker för att ladda in sig själva i andra program
och liknande. Eftersom endast en enkelt version för att verifiera program har implementerats
kan inte vår implementation upptäcka och stoppa denna typ av interna
attacker. Följande program och tester valdes ut då de motsvarar de mål som vi
ställt upp för implementationen.
• Leak Test v1.2: Programmet försöker kontakta websidan grc.com genom att
döpa om sig till ett program som antagligen är godkänt, Internet Explorer.
35

36 KAPITEL 5. TESTER
• TooLeaky: Tooleaky öppnar standardwebläsaren med följande kommandorad:
iexplore.exe http://grc.com/lt/leaktest.htm?PersonalInfoGoesHere
Fönstret som öppnas är gömt. Om webläsaren är tillåten att anropa servrar
på port 80 kommer den att lyckas skicka information till destinationsadressen
som i det här fallet är GRC.com.
• YALTA: Provar att skicka UDP paket på portar som ofta är tillåtna så som
53 (DNS) och 21(FTP).
• hping: Paketgenerator för TCP/IP-protokollet (Wikipedia, 2006b).
• Nmap: Nätverksscanner för TCP/IP-protokollet (Wikipedia, 2006c).
Regeltesterna gjordes genom att en säkerhetspolicy sattes för brandväggen och
sedan testades om brandväggen implementerade denna genom att testa med ping,
hping, telnet och nmap.
Alla tester utfördes i en virtuell maskin (Microsoft, 2006a) med operativsystemet
Microsoft Windows XP SP2 med alla säkerhetsuppdateringar som fanns tillgängliga
november 2006. Noden som användes för de externa penetrationstesterna använde
sig av operativsystemet Mac OS X 10.4.8.
5.1 Resultat
5.1.1 Implementationstester
Genom att utgå från modellen vid design implementerade vi en brandvägg bestående
av två filter och en kontrollapplikation. Dessa filter har var för sig olika
funktionalitet, olika starka och svaga egenskaper men tillsammans kompletterar de
varandra. För enklare program som ping och telnet kunde deras uppkopplingsförsök
följas redan i TDI-lagret. Då vi skrivit in en tillåtande regel för ett av dessa program
kunde det utan problem kommunicera eftersom tjänsten vid ett uppkopplingsförsök
skickat ner en ny regel till NDIS. Även mer komplicerade program som installerar
en egen nätverksstack parallellt med den inbyggda får problem att kommunicera ut
trafik eftersom NDIS-filtret blockerar trafiken.
5.1.2 Penetrationstester
Vi genomförde en testsvit med olika typer av penetrationstester för utgående trafik
(se tabell 5.1).
För penetrationstester utifrån har vi genomfört tester med bland annat hping
med lyckat resultat. Vid penetrationstesterna innifrån lyckades TooLeaky ta sig ut
vilket beror på att den startar Internet Explorer. Eftersom implementationen inte
undersöker processträdet för varje process fångar vi inte upp denna typ av program.
Dock klarar implementationen de två andra som väntat.

5.1. RESULTAT 37
Test Riktning Resultat Kommentar
Leak Test Ut Stoppad
TooLeaky Ut Passerar Använder sig av Internet Explorer
YALTA Ut Stoppad
hping In Stoppad Specialkonstruerade paket
Nmap In Stoppad Portscanning
5.1.3 Regeltester
Tabell 5.1. Resultat av penetrationstester.
För regeltesterna definierades en säkerhetspolicy som innebar att Internet Explorer
fick kommunicera med servrar med TCP port på 80, samt att systemets DNS
klient får kommunicera med servrar med UDP på port 53. Denna säkerhetspolicy
lades in som två regler för kontrolltjänsten, en för Internet Explorer och en för
DNS klienten. Genom att starta Internet Explorer och gå mot en websida samtidigt
som de olika komponenterna (TDI filtret, NDIS filtret och kontrolltjänsten)
i brandväggen övervakades. Utifrån detta kunde vi se att brandväggen implementerade
säkerhetspolicyn som det var tänkt. Tester gjordes även med nmap för att
verifiera att inga andra portar var öppna.
5.1.4 Sammanfattning
Resultaten från de olika testerna visar att implementationen fungerar som tänkt
samt att den innehar de egenskaper som beskrivs av modellen. Nedan följer en
beskrivning av hur testerna visar att implementationen klarar av dem fem målen
från avsnitt 1.1.
• Säkerhetsproblem i operativsystem. Genom penetrationstesterna har man
visat att implementationen skyddar mot externa och interna attacker vilket
betyder att implementationen skyddar operativsystemet från attacker.
• Förhindra åtkomst till information. Eftersom implementationen klarar
av implementationstesterna samt regeltesterna har vi visat att den klarar av
att förhindra åtkomst till information.
• Förhindra informationsläckor. De interna penetrationstesterna har visat
att implementationen klarar av att förhindra informationsläcker.
• Upprätthålla en säkerhetspolicy. Regeltesterna har visat att implementationen
implementerar en säkerhetspolicy på ett korrekt sätt.
• Granskning. Genom att implementationen spårar alla applikationer och all
nätverkstrafik är det lätt att följa ett förlopp för till exempel ett intrångsförsök.

Kapitel 6
Slutsats
I denna rapport har vi börjat med att presentera OSI-modellen för att relatera den
till TCP/IP-modellen som är den standard som används på Internet idag. Utifrån
dessa modeller har vi i kapitel 2 presenterat olika brandväggstekniker samt olika
metoder för att testa och analysera dessa. I kapitel 3 har vi sedan utgått från tekniker
presenterade i kapitel 2 för att ta fram en generell modell för en personlig
brandvägg kapabel att filtrera på information från flera lager i OSI-modellen. Fokus
har legat på design av ett sessionsfilter samt kombinationen av detta filter ihop med
ett dynamiskt paketfilter. Genom denna kombination av brandväggstekniker har vi
visat att man kunnat eliminera betydande svagheter hos respektive teknik. På detta
sätt har vi designat en personlig brandvägg som ger ett bättre skydd, från attacker
både inifrån och utifrån. För att testa den teoretiska modellen och visa att den är
praktiskt genomförbar har vi i kapitel 4 konstruerat en prototyp för Microsoft Windows
XP. Nätverksmodellen, drivrutinsmodellen samt olika filtreringstekniker för
Windows XP har presenterats i detta kapitel. Utifrån de tekniker som presenterats
har vi implementerat modellen presenterad i kapitel 3 med hjälp av ett TDI-filter,
ett NDIS-filter och en kontrolltjänst. I kapitel 5 har vi testat prototypen utifrån
tre olika testkategorier: (1) implementationstester, (2) penetrationstester och (3)
regeltester för att verifiera att prototypen stämmer överens med den teoretiska modellen.
Genom tester genomförda i kapitel 5 har vi visat att implementationen och
modellen uppfyller de fem egenskaper vi ställt upp i kapitel 1. I och med detta
har vi uppnått de mål som ställts upp för den här rapporten; att presentera en
generell modell för en personlig brandvägg med följande fem egenskaper: (1) skydda
mot säkerhetsproblem i operativsystem, (2) förhindra åtkomst till information, (3)
förhindra informationsläckor, (4) upprätthålla en säkerhetspolicy och (5) underlätta
granskning.
39

Litteraturförteckning
Cisco. Evolution of the firewall industry, September 2002. URL http://www.cisco.
com/univercd/cc/td/doc/product/iaabu/centri4/user/scf4ch3.htm.
Dubrawsky, Ido. Firewall evolution - deep packet inspection, Juli 2003. URL http:
//www.securityfocus.com/print/infocus/1716.
Haeni, Reto E. Firewall penetration testing. Teknisk rapport, Cyberspace Policy
Institute, 1997.
Hazelhurst, Scott. A proposal for dynamic access lists for tcp/ip packet filering.
Teknisk rapport, School of Computer Science, University of the Witwatersrand,
April 2001.
Ingham, Kenneth och Forrest, Stephanie. A history and survey of network firewalls.
Teknisk rapport, The University of New Mexico Computer Science Department
Technical Report 2002-37, 2002. URL http://www.cs.unm.edu/~treport/tr/
02-12/firewall.pdf.
itsecurity.com. History of the firewall, Augusti 2006. URL http://www.
itsecurity.com/security.htm?s=410.
Jackson, Debbie. Windows xp firewall. Examensarbete, University of Sheffield, May
2005.
Kaddouch, Guillaume. Firewall leak tester, 2006. URL http://www.
firewallleaktester.com/.
Kamara, Seny, Fahmy, Sonia, Schultz, Eugene, Kerschbaum, Florian, och Frantzen,
Michael. Analysis of vulnerabilities in internet firewalls. Journal of Computers
and Security, 22(3):214–232, April 2003.
KhalidAl-Tawil och Al-Kaltham, Ibrahim A. Evaluationandtestingofinternetfirewalls.
INTERNATIONAL JOURNAL OF NETWORK MANAGEMENT, ss 135–
149, 1999.
Microsoft. Microsoft virtual pc 2004, 2006a. URL http://www.microsoft.com/
windows/virtualpc/default.mspx.
41

42 LITTERATURFÖRTECKNING
Microsoft. Prefast for drivers, 2006b. URL http://www.microsoft.com/whdc/
devtools/tools/PREfast.mspx.
Microsoft. Tdi drivers, 2006c. URL http://msdn.microsoft.com/library/
default.asp?url=/library/en-us/NetXP_d/hh/NetXp_d/nettdidriv_
27c4b7c0-7e21-441d-bb08-335d48204a06.xml.asp.
Microsoft. Visual studio team system, 2006d. URL http://msdn2.microsoft.
com/en-us/library/fda2bad5(VS.80).aspx.
Microsoft. Windows Driver Development Kit: Network Devices and Protocols: NDIS
Drivers. Microsoft Corporation, 2006e.
Mogul, Jeffrey C. Simple and flexible datagram access controls for unix-based
gateways, 1989. URL http://www.hpl.hp.com/techreports/Compaq-DEC/
WRL-89-4.html.
Schuba, Christoph L. On the modeling, design, and implementation of firewall
technology. Teknisk rapport, Center for Education and Research in Information
Assurance and Security, 1997.
Schultz, E. Eugene. How to perform effective firewall testing. Computer Security
Journal, 12(1):47–54, 1996.
Spafford, Eugene H. The internet worm incident. Teknisk rapport, Department of
Computer Sciences Purdue University, 1991. URL http://www.funet.fi/pub/
crypt/old/spaf/IWorm2.PS.Z.
Wikipedia. Architecture of windows nt, 11 2006a. URL http://en.wikipedia.
org/wiki/Windows_kernel.
Wikipedia. hping free packet generator, 2006b. URL http://en.wikipedia.org/
wiki/Hping.
Wikipedia. Nmap free security scanner, 2006c. URL http://en.wikipedia.org/
wiki/Nmap.
Wikipedia. Transmission control protocol, 2006d. URL http://en.wikipedia.
org/wiki/Transmission_Control_Protocol.
Wikipedia. Trojan horse, 10 2006e. URL http://en.wikipedia.org/wiki/
Trojan_horse_%28computing%29.
Woodall, Stephen. Firewall design principles. Course project, April
2004. URL http://www4.ncsu.edu/~kksivara/sfwr4c03/projects/
SteWoodall-Project.pdf.
Zaugg, Gerhard. Firewall testing. Examensarbete, Swiss Federal Institute of Technology
Zurich, 2004.

Bilaga A
TDI filter
Detta appendix beskriver mer i detalj hur TDI filtret fungerar och hur TDI fungerar
allmänt genom att visa hur en anslutning kan göras med TDI. För att bättre förklara
hur TDI filtret fungerar och vilka funktioner som finns kommer vi att gå i genom
processen att göra en anslutning, skickar data och slutligen stänger anslutning med
hjälp av TDI. Innan vi går in på detaljer ger vi först en kort överblick.
A.1 IO till TDI-lagret
Varje protokoll som implementerar ett TDI-interface sätter upp en eller flera enheter
som API lagret kommunicerar med (se figur 4.3). TCP/IP-protokollet sätter upp
följande enheter:
• \Device\Tcp
• \Device\Udp
• \Device\RawIp
• \Device\IP
De första två används för TCP respektive UDP trafik, medan RawIp kan användas
för att skicka råa IP paket. Dock kan man bara använda denna device om man
är administratör på datorn. Denna begränsning har gjort att man varit tvungen
att implementera den fjärde enheten som användas bland annat för att skicka t.ex.
ICMP-meddelanden med programmet Ping utan att man behöver vara administratör.
Dock används den troligtvis till fler funktioner men det saknas helt dokumentation
för denna enhet från Microsoft, troligtvis för att den endast är tänkt att
användas internt av Microsoft.
A.2 Ny anslutning
Beroende på om en applikation vill öppna en ny anslutning eller skicka data hanteras
det på olika sätt. När en applikation vill öppna en ny anslutning sker förenklat det
43

44 BILAGA A. TDI FILTER
förlopp som visas i figur 4.5. En applikation använder sig i vanliga fall av Winsock
som fungerar som en TDI klient och gör alla TDI anrop som behövs för att göra en
anslutning. Det som visas i figuren är endast det avslutande anropet för att göra
själva anslutningen till fjärrnoden. För en mer detaljerad beskrivning av hur man
gör en anslutning TDI och hur TDI filtret hanterar det, se appendix A.
I första steget får TDI filtret TDI_CONNECT anropet från applikation och skickar
den en förfrågan till tjänsten genom att anropa svc_io_query_service med information
om vilket process id, protokoll, destinations adress och destinations port.
Tjänsten mappar process id till namnet på den exekverbara filen och söker sedan
i sin regellista efter matchande regler. Om det inte finns någon regel som matchar
namnet på processen eller det finns en regel som matchar namnet, men den anslutningen
som applikationen vill göra inte tillåts, svara tjänsten med BLOCK. TDI
filtret svarat då till applikationen med STATUS_REMOTE_NOT_LISTENING vilket innebär
att anslutningen avbryts. Om anslutningen tillåts som i figuren skickar tjänsten
en regel till NDIS filtret som matchar den aktuella anslutningen och svarar sedan
till TDI filtret med ALLOW. TDI filtret skickar då vidare TDI_CONNECT anropet till
det ursprungliga anropet och returnerar senare svaret till applikationen.
A.3 Öppna en anslutning med TDI
För att göra en anslutning med TDI måste följande steg utföras:
• Öppna en transport adress
• Öppna en anslutningsslutpunkt
• Associera transport adressen med anslutningsslutpunkten
• Göra anslutningen
A.3.1 Öppna en Transportadress
Första steget är att skapa ett objekt som representerar en transportadress. Transportadressen
är den IP adress och port som kommer att användes på den lokala
noden. Det är möjligt att specificera en lokal adress och port och används bland
annat när en process vill vänta på anslutningar på en viss port. Figur A.1.
A.3.2 Öppna en anslutningsslutpunkt
Nästa steg är att skapa en anslutningsslutpunkt som definierar en klients sida av
en nätverks anslutning. Denna anslutningsslutpunkt sätts upp är den inte aktiv och
ingen I/O kan utföras på denna innan man har associerat en transportadress med
den. Figur A.2.

A.3. ÖPPNA EN ANSLUTNING MED TDI 45
TDI Client
ExtendedAttributes->EaNameLength = TDI_TRANSPORT_ADDRESS_LENGTH
Possibly specify local address to use
irp1
Dispatch Create
Handler
Create Address
Object
Set completion
routine:
Complete_Address_
Object
IoCallDriver(... irp1)
ZwCreateFile(... ExtendedAttributes ...)
Transport Data Interface
Complete
Address Object
Create irp2 & set
completion
function:
Complete_Query_
Local_Address
irp1
irp1
IoCallDriver(... irp2)
Original TDI Driver
Object List
Address Object
Complete Query
Local Address
Save Address Object
in Object List
irp2
Figur A.1. Create Address Object
TDI Client
ExtendedAttributes->EaNameLength = TDI_CONNECTION_CONTEXT_LENGTH
Dispatch Create
Handler
irp
ZwCreateFile(... ExtendedAttributes ...)
Transport Data Interface
Create Connection
Context
Save Connection Object
in Object List
IoCallDriver(... irp)
Original TDI Driver
Object List
Address Object
Connection Object
Figur A.2. Create Connection Context
User Space
Kernel Space
User Space
Kernel Space

46 BILAGA A. TDI FILTER
TDI Client
irp = TdiBuildInternalDeviceControlIrp(TDI_ASSOCIATE_ADDRESS ...)
TdiBuildAssociateAddress(irp ...)
irp
Dispatch Internal
Device Control Handler
TDI Associate Address
1. Verify Address and
Connection objects
2. Save associated Address
Object in Object List
3. Associate objects
IoCallDriver(... irp)
IoCallDriver(... irp)
Transport Data Interface
2x
Object List
Address Object
Connection Object -> Address Object
Original TDI Driver
Verify Objects
Associate Objects
Associate List
Address Object -> Connection Object
Figur A.3. Associate Address
User Space
Kernel Space
A.3.3 Associera transportadressen med anslutningsslutpunkten
Som sagts tidigare behöver vi först associera en transportadress med en anslutningsslutpunkt
innan vi kan skicka data över anslutningen. Associationen görs genom ett
TDI_ASSOCIATE_ADDRESS IOCTL anrop. En anslutningsslutpunkt kan endast vara
associerat med en transportadress, medan en transportadress kan ha associationer
till många olika anslutningsslutpunkter. Ett exempel är när flera klienter är ansluta
till en server socket.
A.3.4 Göra anslutningen
För att göra själva anslutningen skickas ett TDI_CONNECT IOCTL anrop som gör att
själva anslutningen. I det här steget skickas även själva adressen till den fjärrnod
som man vill ansluta till
A.4 Skicka och ta emot data med TDI
Ä client can disable an already registered event handler by making a subsequent
TDI_SET_EVENT_HANDLER request in which the EventType member specifies the type
of handler but the EventHandler and EventContext members are NULL."
Åhen a kernel-mode client makes a TDI_SEND request, it asks the underlying TDI
transport driver to transmit a normal or expedited TSDU on a specified connection

A.5. AVSLUTA EN ANSLUTNING MED TDI 47
TDI Client
irp = TdiBuildInternalDeviceControlIrp(TDI_CONNECT ...)
Specify remote address to connect to
TdiBuildConnect(irp ...)
irp
Dispatch Internal
Device Control Handler
TDI Connect
1. Find related Connection
Object and Address Object
2. Query Service
3. Save connection in
Connection List
IoCallDriver(... irp)
IoCallDriver(... irp)
Transport Data Interface
Object List
Address Object
Connection Object -> Address Object
Find Object
Original TDI Driver
Save Connection
Query Service
Connection List
Pid, Protocol, IP:Port -> IP:Port
Figur A.4. Connect
Service
Investigate
Permissions
User Space
Kernel Space
endpoint to its remote-node peer."
Åhen a kernel-mode client makes a TDI_SET_EVENT_HANDLER request, it asks
the underlying TDI transport driver to call the specified ClientEventXxx routine
whenever the corresponding network event occurs."
A.5 Avsluta en anslutning med TDI
Disconnect
Åhen a kernel-mode client makes a TDI_DISCONNECT request, it asks the underlying
TDI transport driver to make a disconnect indication to the remote node,
to acknowledge a disconnect indication from the remote node for an established
endpoint-to-endpoint connection, or to reject an offered connection by a remotenode
peer."
Disassociate the Handles
Åhen a kernel-mode client makes a TDI_DISASSOCIATE_ADDRESS request, it asks
the underlying TDI transport driver to break an established association between a
particular local-node address and a connection endpoint."
Close the Handles
"TdiDispatchClose runs when the I/O manager is releasing its last reference
to the handle of the file object representing an address, connection endpoint, or
control channel. Such a file object is deallocated when this last reference to the file
handle has been released."

48 BILAGA A. TDI FILTER
TDI Client
irp = TdiBuildInternalDeviceControlIrp(TDI_SEND ...)
TdiBuildSend(irp ... dataBuffer ...)
irp
Dispatch Internal
Device Control Handler
TDI Send
Verify a valid connection
IoCallDriver(... irp)
IoCallDriver(... irp)
Transport Data Interface
Original TDI Driver
Connection List
Pid, Protocol, IP:Port -> IP:Port
Verify Connection
Figur A.5. Send Data
TDI Client
irp = TdiBuildInternalDeviceControlIrp(TDI_RECEIVE ...)
TdiBuildReceive(irp ... dataBuffer ...)
irp
Dispatch Internal
Device Control Handler
TDI Receive
Verify a valid connection
IoCallDriver(... irp)
IoCallDriver(... irp)
Transport Data Interface
Original TDI Driver
Connection List
Pid, Protocol, IP:Port -> IP:Port
Verify Connection
Figur A.6. Receive Data
User Space
Kernel Space
User Space
Kernel Space
Åhen the I/O manager is closing the last handle to an open file object that represents
an address, connection endpoint, or control channel, it calls TdiDispatchCleanup.
In other words, the I/O manager always submits an IRP_MJ_CLEANUP request to a
transport before it submits an IRP_MJ_CLOSE request for a particular file object."

A.5. AVSLUTA EN ANSLUTNING MED TDI 49
TDI Client
irp = TdiBuildInternalDeviceControlIrp(TDI_SET_EVENT_HANDLER ...)
TdiBuildSetEventHandler(irp ... TDI_EVENT_RECEIVE ... clientEventHandler, clientContext)
irp
Dispatch Internal
Device Control Handler
Verify Address Object
IoCallDriver(... irp)
Transport Data Interface
Object List
1 - Address Object
2 - Connection Object, -> Address Object
Original TDI Driver
TDI Set Event Handler
1. Verify a valid Address Object
2. Save clientEventHandler and
clientContext in new context of
a modified irp
3. Replace event handler in irp
with: TDI_Event_Receive
IoCallDriver(... modified irp)
Figur A.7. Register Event Receive Function to Receive Data
TDI Client
NTSTATUS clientEventHandler(clientContext ... irp){
handle irp...
}
clientEventHandler(clientContext ... irp)
TDI Event Receive
1. Verify a valid connection
2. Call clientEventHandler with
clientContext earlier saved in
context of modified irp
context + irp
clientContext + irp
Transport Data Interface
Original TDI Driver
Associate List
Address Object -> Connection Object
Verify Connection
Connection List
Pid, Protocol, IP:Port -> IP:Port
Figur A.8. Receive Data in Event Receive Function
User Space
Kernel Space
User Space
Kernel Space

50 BILAGA A. TDI FILTER
TDI Client
irp = TdiBuildInternalDeviceControlIrp(TDI_DISCONNECT ...)
TdiBuildDisconnect(irp ...)
irp
Dispatch Internal
Device Control Handler
TDI Disconnect
1. Find & remove connection
from Connection List
2. Inform Service
IoCallDriver(... irp)
IoCallDriver(... irp)
Transport Data Interface
Original TDI Driver
Connection List
Pid, Protocol, IP:Port -> IP:Port
Find & Remove
Connection
Inform Service
Figur A.9. Disconnect
TDI Client
irp = TdiBuildInternalDeviceControlIrp(TDI_DISASSOCIATE_ADDRESS ...)
TdiBuildDisassociateAddress(irp ...)
irp
Dispatch Internal
Device Control Handler
TDI Disassociate Address
1. Find & remove related
Address Object
3. Disassociate objects
IoCallDriver(... irp)
IoCallDriver(... irp)
Transport Data Interface
Object List
Address Object
Connection Object -> Address Object
Original TDI Driver
Find Object
Disassociate
Objects
Associate List
Address Object -> Connection Object
Figur A.10. Disassociate the Handles
Service
Update
connection
states
User Space
Kernel Space
User Space
Kernel Space

A.5. AVSLUTA EN ANSLUTNING MED TDI 51
TDI Client
Closes handle to Address Object and Connection Context separately.
irp
Dispatch Close Handler
Remove object from Object List
IoCallDriver(... irp)
ZwClose(handle)
Transport Data Interface
Original TDI Driver
Find & Remove
Object
Object List
Address Object
Connection Object
Figur A.11. Close the Handles
User Space
Kernel Space