Sluttrapport - Hovedprosjekt - Copyleft Solutions

perchmysteriousΔιαχείριση Δεδομένων

1 Δεκ 2012 (πριν από 4 χρόνια και 9 μήνες)

456 εμφανίσεις


Brannmur

med
webgrensesnitt

Hovedprosjekt ved Høgskolen i Bergen

Avdeling for ingeniørutdanning,

Institutt for data
-

og realfag,

Drift av datasystemer og Datateknikk




Yngve Solås

Nesse, Helge Kristoffer Hjelset Paulsen og Kine Margrethe Klubnes

Vår 2007


















2







H
ØGSKOLEN
I
B
ERGEN

Avdeling for Ingeniørutdanning

Institutt for Data
-

og Realfag


TITTELSIDE FOR HOVEDPROSJEKT


Rapportens tittel:


Brannmur

m
ed webgrensesnitt


Dato:

11.06.07


Rapportnummer:


Forfatter(e):


Helge
Kristoffer
Hjelset Paulsen

Yngve Solås Nesse


Antall sider u/vedlegg:

3
7




Kine Margrethe Klubnes

Antall sider

vedlegg:

6



Studieretning:


Datateknikk og Drift av datasystemer


Antall disketter/CD
-
er:

1



Kontaktperson ved studieretning:


Petter Seip


Gradering:

Ingen

Merknader:




Oppdragsgiver:


Copyleft Solutions AS


Oppdragsgivers referanse:



Oppdragsgivers
kontaktperson:


Geir Inge Imsland


Telefon:

47647074


Sammendrag:


Grovt sett går prosjektet ut på å utvikle et
brannmur
oppsett som kan distribueres sammen med
Copylefts eget operativsystem. Dette må være enkelt for kunden å konfigurere selv, derfor

må det
leveres med et oversiktlig webgrensesnitt hvor en skal kunne oppdatere brannmurregler, begrense
båndbredde og vise oversikt over trafikk inn og ut. Det skal også være mulig å lese lo
gger for
båndbreddebruken to døgn

tilbake i tid.





Stikkord:

Br
annmur



Nettverk

PF



Høgskolen i Bergen, Avdeling for ingeniørutdanning


Postadresse: Postboks 7030, 5020 BERGEN

Besøksadresse: Nygårdsgaten 112, Bergen

Tlf. 55 58 75 00


Fax 55 58 77 90


E
-
post:
post@hib.no

Hjemmeside: http://www.hib.no



FORORD

3



FORORD

Denne rapporten er skrevet i
forbindelse

med avsluttende hovedprosjekt ved
Høgskolen i Bergen, avdeling for data
-

og realfag. Vi har jobbet med dette prosjektet
fra mars til juni 2007.

Vi takker Petter Seip
ved HiB
for veiledning i oppgaven.

Vi vil spesi
elt takke Matias Hermanrud Fjeld og Geir Inge Imsland ved Copyleft
Solutions for

opplæring og god hjelp til oppgaven.


Innholdsfortegnelse

4



Innholdsfortegnelse

FORORD

................................
................................
................................
................................
...............................

3

INNHOLDSFORTEGNELSE

................................
................................
................................
.............................

4

1. INNLEDNING

................................
................................
................................
................................
..................

6

1.1

O
PPDRAGSGI
VER

................................
................................
................................
................................
...........

6

1.2

P
ROBLEMSTILLING

................................
................................
................................
................................
........

7

1.3

H
OVEDIDÉ FOR LØSNINGS
FORSLAG

................................
................................
................................
...............

7

1.4

P
ROSJEKTFORM

................................
................................
................................
................................
.............

8

2. DEFINISJO
N AV OPPGAVEN

................................
................................
................................
......................

8

2.1

K
RAVSPESIFIKASJON

................................
................................
................................
................................
.....

8

Del 1: Utvikling av brannmuroppsett

................................
................................
................................
............

8

Del 2: Lagring av data

................................
................................
................................
................................
..

8

Del 3:

Presentasjon av data gjennom webgrensesnitt

................................
................................
...................

9

3. ANALYSE AV PROBLE
MET

................................
................................
................................
........................

9

4. DESIGN AV MULIGE

LØSNINGER

................................
................................
................................
...........

9

4.1

L
ØSNINGSALTERNATIV
1

................................
................................
................................
...............................

9

4.2

L
ØSNINGSALTERNATIV
2

................................
................................
................................
.............................

10

4.3

D
RØFTING AV LØSNINGSA
LTERNATIVENE

................................
................................
................................
...

10

5. VALG AV VERKTØY

................................
................................
................................
................................
...

11

5.1

P
ROGRA
MVARE

................................
................................
................................
................................
...........

11

5.2

H
ARDWARE

................................
................................
................................
................................
.................

11

5.3

O
PPLÆRING

................................
................................
................................
................................
.................

11

6. IMPLEMENTERING

................................
................................
................................
................................
....

12

6.1

O
PPSETT AV BRANNMUR M
ASKINEN

................................
................................
................................
............

12

6.2

O
PPSETT AV
WEBAPPLIKAJSON

................................
................................
................................
....................

14

6.3

P
ROGRAMMERING AV WEBA
PPLIKASJON

................................
................................
................................
.....

14

7. TESTING

................................
................................
................................
................................
.........................

16

8. BESKRIVELSE AV UT
VIKLET SYSTEM I BRUK

................................
................................
.................

17

8.1

B
RUKERDOKUMENTASJON

................................
................................
................................
..........................

17

Innlogging og adgangskontroll

................................
................................
................................
...................

17

Grafer over båndbreddebruk

................................
................................
................................
.......................

20

Brannmurregler

................................
................................
................................
................................
...........

21

Logger

................................
................................
................................
................................
.........................

25

8.2

D
RIFTS
-

OG VEDLIKEHOLDSDOKUM
ENTASJON

................................
................................
............................

26

Installere FreeBSD

................................
................................
................................
................................
......

26

Opprett ny bruker

................................
................................
................................
................................
........

27

Oppsett av PF

................................
................................
................................
................................
..............

27

Legg til i
rc.
conf
:
................................
................................
................................
................................
....

27

Bygge ALTQ inn i kjernen

................................
................................
................................
...........................

28

Oppsett av CVSUP og Portupgrade

................................
................................
................................
............

29

Sette opp Apache

................................
................................
................................
................................
.........

29

Installere mod_python

................................
................................
................................
................................
.

29

Installere Postgre
SQL

................................
................................
................................
................................
.

29

Installere PMACCT

................................
................................
................................
................................
.....

30

Installere pNRG

................................
................................
................................
................................
...........

30

Nagiosscript

................................
................................
................................
................................
.................

32

9. OPPSUMMERING, DIS
KUSJON OG KONKLUSJON
ER

................................
................................
.......

35

9.1

R
ESULTAT I FORHOLD TI
L KRAVSPESIFIKASJON

................................
................................
...........................

35

9.2

R
ESULTAT I FORHOLD TI
L FREMDRIFTSPLAN

................................
................................
...............................

35


Innholdsfortegnelse

5



9.3

R
ESULTAT I FORHOLD TI
L RISIKOANALYSE

................................
................................
................................
..

36

9.4

A
NSVARSFORDELING OG S
AMARBEID

................................
................................
................................
..........

36

10. LITTERATURLISTE

................................
................................
................................
................................
..

37

10.1

W
EBSIDER

................................
................................
................................
................................
.................

37

VEDLEGG
................................
................................
................................
................................
...........................

38

V
EDLEGG
A:

O
RDLISTE

................................
................................
................................
................................
.....

38

V
EDLEGG
B:

F
REMDRIFTSPLAN
/G
ANTT
-
DIAGRAM

................................
................................
...........................

39

Opprinnelig tidsplan

................................
................................
................................
................................
....

39

Revidert

tidsplan

................................
................................
................................
................................
..........

40

V
EDLEGG
C:

R
ISIKOLISTE

................................
................................
................................
................................
.

41

V
EDLEGG
D:

K
ODE

................................
................................
................................
................................
...........

42




1. INNLEDNING

6



1. INNLEDNING


1.1
Oppdragsgiver

Vår oppdragsgiver er Copyleft Solutions AS som holder til i ”inkubatoren” på HiB,
avdeling for ingeniørutdanning.

Copyleft ble startet i Oslo i 1997,
og i april 2004 ble det opprettet en avdeling i
Mexico. Copyleft Bergen, også kalt Copyleft Solutions, ble i samarbeid med Copyleft
Oslo startet av Geir Inge Imsland, Ole Bjørn Tøllefsen, Terje Kolstøl og Anders
Helland i desember 2004. De opprettet en we
bshop i januar 2005 og etablerte
serverrom i Bergen i februar. Det første året hadde firmaet i Bergen en omsetting på
700 000, og andre året var omsettingen på 1,5 millioner. Andre året begynte de å ta inn
lærlinger, og på slutten av 2006 var det totalt 10

ansatte.

Copyleft Bergen arbeider på tre hoverområder: hardware salg gjennom en webshop,
systemutvikling/webutvikling, og it
-
drift som er drift av kontornettverk for
mellomstore bedrifter.

Noen av Copyleft So
lu
tions

bedriftskunder
: SLAB AS, Hovland Elekt
ro AS,
Ø
konomiservice Stord AS, Chiron Media, Wilson Ship Management, Orion Trading,
Predimark ANS.

Som nevnt tidligere består Copyleft av tre avdelinger: Copyleft Bergen, Copyleft Oslo
og Copyleft Mexico. På sikt har de også planer om å opprette en avdel
ing i
Trondheim. I Copyleft Mexico arbeides det stort sett kun med webutvikling og i Oslo
er arbeidsområdene det samme som i Bergen.

Alt som blir utviklet av Copy
left blir lisensiert under GPL(General Public License).

Grunnregelen i GPL er at et program s
om distribueres i kompilert form også sk
al være
tilgjengelig for bruker
ne i form av kildekode


alle filer som er nødvendige for å
produsere den distribuerte versjonen skal være tilgjengelig for fri bruk. Hvis
programkode som er GPL
-
lisensiert inkluderes i

et annet program, må også dette
programmet lisensieres under GPL.



1. INNLEDNING

7



1.2
Problemstilling


Oppdragsgiver ønsker et
brannmur
system som kan distribueres sammen med deres
serveroperativsystem.
Brannmur
en de bruker i dag (PF
, Packet Filter
) er vanskelig å
konfigurere. En person som ikke er kjent med systemet vil bruke un
ødvendig lang tid
på å lære seg
installasjon og konfigurasjon. Oppdragsgiver ønsker derfor et
brukervennlig grafisk grensesnitt som forenkler disse oppgavene. Dette grensesnittet
kan også br
ukes av Copylefts ansatte. Noen kunder hos Copyleft blir fa
kturert ut

ifra
båndbreddebruk. O
ppdragsgiver ønsker derfor et s
ystem som kundene kan logge på og

sjekke hvor mye båndbredde de bruker.



1.3

Hovedidé for løsningsforslag

Et webgrensesnitt vil væ
re en god løsning for å forenkle konfigurasjonen av PF. Da
kan autoriserte brukere logge på systemet fra hvor som helst.
Her skal en kunne
oppdatere
brannmur
regler og vise oversikt over trafikk inn og ut. Det skal være mulig
å se grafer for båndbreddebruke
n ett år tilbake i tid. Systemet må ha støtte for
forskjellige typer brukere. En administrator på systemet skal kunne endre rettigheter til
andre brukere. Noen kunder kan få muligheten til å endre
brannmur
oppsett. Andre
kunder som ikke har kompetanse på de
tte feltet skal ikke ha mulighet til å endre
konfigurasjon. I tillegg er det viktig at kundene kun får tilgang til sin egen
båndbreddebruk, siden webapplikasjonen også skal brukes på serverparker med mange
kunder bak samme
brannmur
.

Brannmur
en skal kjøres

en maskin med FreeBSD. S
erveroperativsystemet er en
modifisert installasjon av dette. På denne maskinen må vi ha følgende programvare:
Brannmur
, databaseserver, webserver og program for å lytte på nettverkskortene.
Brannmur
programvaren konfigureres vha.

regler som bestemmer hvilke pakker som
skal slippe gjennom, og hvilke som skal blokkeres. Reglene skal lett kunne opprettes,
endres og slettes via webgrensesnittet. Til dette trenger vi en database som
webapplikasjonen kan bruke til lagring av regler og b
rukerdata. Standardoppsettet til
brannmuren må kunne blokkere forsøk på angrep eller innbrudd. Når det gjelder
styring og fakturering av båndbredde, har oppdragsgiver allerede et system for dette.

2. DEFINISJON AV OPPGAVEN

8



Det eneste vi trenger å lage, er et script som varsler dett
e systemet ved for høy
båndbreddebruk.


1.
4

Prosjektform

Fossefallsmodellen er en såkalt «strukturert» systemutviklingsmodell. Aktivitetene er
inndelt i faser som kommer etter hverandre. En fase skal avsluttes før den neste
begynner.

Denne modellen har
sine klare svakheter og er derfor lite brukt i

dag. Vi valgte denne
metoden fordi vi har fått en klart spesifisert oppgave av oppdragsgiver, og derfor
fungerer dette godt for oss.

Det eneste avviket vi har hatt i forhold til fossefallsmodellen er at vi ha
r testet
underveis.


2.
DEFINISJON AV OPPGAVEN

2.1 Kravspesifikasjon

Oppgaven består av 3 deler beskrevet under.

Del 1: Utvikling av
brannmur
oppsett

Det skal utvi
kles et veldig generelt
brannmur
oppsett basert på PF. Oppsettet skal være
slik at det kan legg
es ut på mange forskjellige servere uten å måtte konfigurere alt på
nytt. Man skal også kunne regulere båndbredde dersom en kunde går over sin
maksgrense over en gitt tidsperiode.
Brannmur
reglene skal i hovedsak baseres på
portnummer og ip
-
adresser.


Punkt
er:



Lage plugin for Nagios som varsler dersom en kunde bruker for mye
båndbredde



Skal være enkelt å oppdatere
brannmur
regler, muligens via web (Regulere
båndbredde, blokkere porter etc.)



En kjørende server som oppdaterer regler, gir beskjed til kjerne og

aktuelle
servere.



Innbruddsdeteksjon



Lage en pakke som distribueres sammen med Copylefts serverOS.

Del 2: Lagring av data

Det skal leses data fra loggene til
brannmur
en og lagre dette på en hensiktsmessig
måte i database eller på filer.

Punkter:



Parse
loggfiler, hente ut relevant info i realtime.



Lagre data på filer eller i database(PostgreSQL)



Lage en pakke som distribueres sammen med Copylefts serverOS.



3.
ANALYSE AV PROBLEMET

9



Del 3: Presentasjon av data gjennom webgrensesnitt

Det skal leses data fra båndbreddemålingen
og presentere dette for mange forskjellige
brukere. Kunder skal f.eks. kun ha tilgang til båndbreddemålinger fra sine egne
servere.

Punkter:



Vise fine grafer over trafikk over gitte tidsintervall (time, døgn, måned, år)



Grafene skal produseres realtime



G
rensesnittet skal baseres på Django



Mulighet for å generere PDFrapporter for kunder som ønsker dette



Lage en pakke som distribueres sammen med Copylefts serverOS


3. ANALYSE AV PROBLEMET

Vi har fått en veldig detaljert beskrivelse fra oppdragsgiver for
hvordan systemet skal
fungere, både med tanke på hvilke funksjoner det skal ha og hvilke programvare og
verktøy vi skal bruke. Vi ser derfor ikke noe behov for å analysere problemet utover
kravspesifikasjonen vi har utarbeidet i samarbeid med Copyleft Solu
tions AS.



4. DESIGN AV MULIGE LØSNINGER

Det finnes, som vi vet om, to eksisterende opensource løsninger med mye av den
funksjonaliteten vi trenger. Dette er PFsense og Monowall. Grunnen til

at Copyleft
ikke vil ta i bruk

en av disse løsningene er at de
blir for avanserte og for lite
brukervennlige. Monowall er uansett uaktuell siden den bygger på feil
brannmurprogramvare. En annen viktig grunn er at disse systemene ikke har støtte for
individuell båndbreddemåling for maskiner bak brannmuren. De ønsker et

system med
enkelt brukergrensesnitt som kan distribueres sammen med deres eget
serveropera
tivsystem. Det positive
med at det finnes lignende løsninger er at vi her kan
få ideer til gode måter å løse ulike problemstillinger.

4.1 Løsningsalternativ 1

Vi kan

ta i bruk den eksisterende opensource løsningen pfSense. Dette prosjektet er et
komplett brannmursystem som tilbyr alt av funksjonalitet som en kommersiell
brannmur gjør. Systemet baserer seg på operativsystemet FreeBSD og brannmur
programvaren Packet Fil
ter (PF). Dette passer med kravspesifikasjonen fra
oppdragsgiver. Alt leveres som en ferdig pakke som installeres på en vanlig PC.
Denne løsningen har muligheten til å vise grafer over båndbreddebruk, men disse
grafene oppfyller ikke oppdragsgivers krav. D
et er ikke mulig å få opp
båndbreddebruk for en enkelt maskin bak brannmuren, kun samlet båndbreddebruk
gjennom brannmuren. I tillegg er det et krav at båndbreddedata skal lagres ett år
tilbake i tid. Dersom vi skal bruke pfSense må vi legge til funksjonal
itet for dette. Vi
kan da bruke PMACCT til å lytte på nettverkskortene, og sende disse dataene videre til
pNRG som lagrer dem i en rrd
-
database. PNRG kan også produsere grafer ut

ifra disse
dataene. Det som gjenstår da er å flette grafene inn i webgrensesn
ittet, og bygge dette
sammen med tilgangssytemet. Det er viktig at brukerne kun får opp sin egen


10



båndbreddedata, da dette potensielt sett kan være sensitive data. Vi må også legge til
funksjonalitet for å presentere logfilene til PF.

4.2 Løsningsalternativ

2

En annen løsning er å bygge opp en egen webapplikasjon fra grunnen av. Da kan vi
selv velge hvilket språk/rammeverk vi skal bruke. Vi har fått detaljerte krav fra
oppdragsgiver når det gjelder bruk av software. Det ferdige systemet må kjøre
FreeBSD
operativsystem, og det skal bygges rundt brannmurprogramvaren PF. Når det
gjelder programmeringsspråk vil oppdragsgiver helst at vi skal bruke Python og
Django. Django er et høynivå webrammeverk som bygger på scriptspråket Python.
Dette er ikke et krav, me
n det vil gjøre det enklere for oppdragsgiver å vedlikeholde
koden. I tillegg har vi lyst å lære oss Python og Django. Hvis vi skriver alt selv fra
bunnen av vil koden være enklere å vedlikeholde enn om vi gikk ut

ifra pfSense.
Dessuten er Python
\
Django
-
k
ode mye mer oversiktlig enn PHP
-
kode. Den delen av
webapplikasjonen som vil ta lengst tid å få til er funksjonaliteten rundt
brannmurregler. Disse må vi lagre i en database, sammen med brukerdata og
tilgangsrettigheter. Oppdragsgiver vil at vi skal bruke P
ostgreSQL
databaseprogramvare. På samme måte som i løsningsalternativ 1 vil vi bruke
PMACCT og pNRG til å produsere grafer over båndbreddebruk.

4.3 Drøfting av løsningsalternativene

Et problem

ved de eksisterende opensource

løsningene er at de har alt f
or mye
funksjonalitet. Ansatte hos Copyleft klarer å bruke dem, men noen av kundene vil
sikkert få problemer. Siden Monowall er uaktuell pga. feil brannmurprogramvare, og
pfSense alene mangler viktig funksjonalitet, står det mellom de to
løsningsalternativ
ene som er skissert over. Et problem med løsningsalternativ 1 er at
pfSense kommer pakket sammen med operativsystemet. De to delene er knyttet nært
sammen, og det er gjort mange endringer av konfigurasjonen til os. Det vil være en
stor oppgave å skille ut
den delen av systemet som vi trenger, og en enda større
oppgave å få dette til å
virke sammen med en normal FreeBSD installasjon.
Arbeidsmengden ville ha blitt for stor for vår bacheloroppgave.
En fordel med
l
ø
sningsalternativ 1 er at pfSense hele tiden bl
ir videreutviklet, og at vi derfor kan
benytte oss av de kodeoppdateringer som kommer
.

Den funksjonaliteten som
oppdragsgiver trenger er forsvinnende lite i forhold til hva pfSense tilbyr. Vi mener
derfor at løsningsalternativ 2 er det beste. Vi vil nok ik
ke rekke å implementere
avansert brannmurfunksjonalitet. Det vi må fokusere på å få til er oppdatering

av
brannmurregler. Oppdragsgiver er også enig i våre prioriteringer og valg av løsning.





5. VALG AV VERKTØY

11



5
.
VALG AV VERKTØY

5.1
Programvare

I dette prosjektet
skulle

vi kun bruke open source programvare. Her er en liste over
programmer
vi
har brukt
:




FreeBSD

er et
Unix
-
lignende

operativsystem
som arver fra den opprinnelige
UNIX gjennom
BSD
-
grenen.



PF

(
Packet Filter
) er
standard brannmur programvare som følger med i
nyeste
versjon av FreeBSD.



Støtte for ALTQ i PF.
ALT
Q

(ALTernate Queueing) er et køstyringsverktøy
for BSD UNIX
.



Apache

er en webserver
som e
r
utviklet primært med tanke p
å

Unix
-
lignende
operativsystemer



Portupgrade

er et

v
erktøy for
å bruke pakkesystemet
i FreeBSD



PMACCT

er

verktøy for nettverksovervåkning



PostgreSQL

er et databasesystem utgitt under en BSD

lisens.



Nagios

er et system for
overvåkning av maskiner og tjenester



RRDtool

er e
t

Round Robin database
verktøy

som

også

kan tegne grafe
r



pNRG

er et

p
rogram som genererer g
rafer basert på data fra PMACCT



Cron

er et v
erktøy for å kjøre o
ppgaver ved gitte tidsintervall



Subvers
ion

er et versjonskontrollsystem



SQLite 3

er en
enkel

dat
a
baseserver


I kapittel 6 går vi
mer detaljert inn på noen av disse prog
rammene og hvordan vi
bruker dem
.



All

programmer
ing

i dette prosjektet
har

vi
hov
edsakelig
skrevet

i Python. Til å lage
webgrensesnittet
har vi brukt

vi

Django rammeverket til Python.

5.2
Hardware

Maskinen
brannmur
en kjører på må ha to ne
ttverkskort, minst 3Gb harddisk og helst
en CD
-
ROM(Ikke et krav, siden alt kan installeres over nettverk). Prosessor og minne
vil variere etter hvor stort nettverk som står bak, og hvor mye trafikk som går
igjennom
brannmur
en.

I testoppsettet var vi i till
egg avhengig av en switch(eller hub) og to andre maskiner til
å plassere på hver sin side av
brannmur
en.

5.3
Opplæring

Operativsystemet vi har brukt er FreeBSD, dette hadde vi på forhånd lite erfaring med.

FreeBSD er mye likt Linux, og har dermed ikke væ
rt


tidkrevende for oss å lære. Vi
har også måttet lære oss PF, men dette likner mye på IPtables
fra Linux, noe

flere av
oss hadde gode kunnskaper om før prosjektstart.

Ingen av prosjektdeltakerne hadde noen erfaring med Python. Vi hadde derfor to dager
med grunnleggende opplæring med Matias hos Copyleft. Dette hjalp oss godt for

å
komme i gang, men vi

har allikevel bruk
t mye tid på å lære oss mer avanserte

6. IMPLEMENTERING

12



funksjon
er

og metoder

gjennom å lese diverse manualer på internett. Planen var også
at vi skulle ha

et kurs med opplæring i Django
-
rammeverket, men dette har vi stort sett
lært oss gjennom
www.djangobook.com

og
www.djangoproject.com
,
vi har også fått en
god del hjelp fra Matias.


6. IMPLEMENTERING

6.1 Oppsett av brannmur maskinen

I dette avsnittet forklarer vi hvordan vi har satt opp maskinen med
brannmurprogramvaren. Det er

meningen å gi en overordnet forståelse for hvordan de
forsk
j
ellige delene av systemet fungerer. Detaljert informasjon om hvordan alt er
konfigurert
,
følger

i kapittel 8.


Bildet over viser hvordan test
-
nettverket vårt ser ut
. Selv om vi bare har satt opp é
n
maskin bak brannmuren, fungerer oppsettet i praksis som
over. Serveren er satt opp
med FreeBSD versjon 6.2 som kjører på en i386 kjerne. Maskinen har 2 nettverkskort.
Et som vender inn mot lokalnettet og et som går ut mot WAN. Det første vi gjorde
etter installasjonen var å kompilere kjernen på nytt med støtte
for
ALTQ(køfunksjonalitet i PF). Så redigerte vi /etc/rc.conf(konfigurasjonsfil for oppstart
av maskinen) for å aktivere PF, logging, gateway, ip
-
forwarding og konfigurere
nettverkskortene. Deretter endret vi konfigurasjonsfilen til PF(/etc/pf.conf) slik a
t den
stemmer med testnettverket. På serveren bak brannmuren satt vi default
-
rute til det
nettverkskortet på brannmuren som er koblet til lokalnettet.


FreeBSD har et pakke
s
ystem som heter ”P
orts”. Dette
programmet tar seg av
installering av
nye programme
r. Det plasserer alle filer i riktige mapper, og installerer
også eventuelle avhengigheter.

Ports tar seg også av avinstallering. Vi installerte
Ports

fra en FreeBSD
-
CD og konfigurerte det til å oppdatere fra en norsk database over
tilgjenglige ”porter”. D
e aller fleste programmene/verktøyene vi har brukt har vi
installert vha. ports.



6. IMPLEMENTERING

13



Webserveren vi har brukt er Apache versjon 2.2, som vi installerte vha. ports. Den må
aktiveres i filen /etc/rc.conf. Vi må også legge inn en linje i /boot/loader.conf for
å
starte Apache ved oppstart. Videre opprettet vi en egen bruker til å kjøre Apach
e,
denne har vi gitt navnet ”apache
”. For å få Apache til å fungere sammen med
Python
\
Django installerte vi en apache
-
plugin som heter mod_python. Python pakken
har vi også i
nstallert, og det er viktig at denne blir kompilert uten støtte for tråder(for
kompatiblitet med Apache).


Webapplikasjonen trenger en database til å lagre brukerdata, tilgangsrettigheter og
brannmurregler. Oppdragsgiver foretrekker PostgreSQL. Vi installe
rte både server og
klient vha. ports. Under installasjonen ble det opprettet en bruker «pgsql» som vi
senere skal bruke til å koble til databasen. Etter installasjonen konfigurerte vi serveren
slik at den tillater lokale tilkoblinger. I tillegg installerte

vi en en pakke «ps
ycopg»,
som Django trenger for
å kommunisere med en PostgreSQL server.


Til å lage grafer over båndbredde har vi brukt en opensource løsning som heter pNRG.
Denne løsningen baserer seg på PMACCT og rrdtool. De to sistnevnte programmene
installerte vi vha. ports. pNRG installerte vi ved å laste ned

en

zipfil

og pakke denne
opp i mappen /usr/local/pnrg. For at pNRG skal fungere må PMACCT konfigureres
riktig. I pNRG
pakken

følger det med et eksempel på hvordan dette gjøres. I tillegg
satte
vi opp programmet Cron til
å
kjøre pnrg
-
wrapper hvert 5. minutt (som brukeren
«web»). Dette er et script som leser data fra PMACCT og lagrer det i RRD
-
filer. I
tillegg produserer det HTML
-
sider og én RRDCGI
-
fil for hver av de IP
-
adressene som
PMACCT lytter

til. Det er kun RRDCGI
-
filene vi er interessert i. De produserer grafer
i form av gif bilder ut

ifra dataene lagret i rrd filene.




Scriptet til Nagios fant vi på nettstedet nagiosexchange.org. Scriptet tolker innholdet i
RRD filene, og regner ut gjennomsnittet av trafikken i et gitt tidsrom(5 minutt). Hvis

6. IMPLEMENTERING

14



en gitt maskin har brukt mer båndbredde en hva som er oppgitt i parameter til s
criptet,
vil returverdien inneholde melding om dette. Hvordan Nagios reagerer på meldingene
bestemmes i Nagios
-
konfigurasjonen, men dette er utenfor rammen av vår oppgave.


6.2 Oppsett av webapplikajson

Det første vi gjorde var å installere Django. Dette g
jorde vi ved å sjekke ut kildekoden
vha. subversion. Det neste vi gjorde var å opprette et prosjekt og en applikasjon, vha.
script som fulgte med Django. Så endret vi konfigurasjonen til prosjektet slik at
applikasjonen ble en del av det. Det var også en

d
el andre innstillinger vi endret, f.eks.
database og språkin
n
stillinger. Så startet vi opp de
n innebygde webserveren og
begy
nte kodingen. Ett
er hvert som applikasjonen begyn
te å ta form, og vi skulle
begynne å kommunisere med brannmurprogramvaren, flyttet
vi testingen over til
maskinen med FreeBSD og PF. Da droppet vi den innebygde test
-
webserveren, og
konfigurerte Apache til å kjøre Python kode.


6.3 Programmering av webapplikasjon

Django
er et opensource webapplikasjon
rammeverk som er skrevet i Python. D
et er
basert på model
-
view
-
controller arkitekturen. Djangos hovedmål er å gjøre det enkelt å
opprette komplekse databasebaserte websider. Det fokuserer på gjenbruk av kode og
rask utvikling. Kjernen i rammeverket består av kode som kobler Python klasser
sa
mmen med databaser, en URL tolker basert på regulære uttrykk, et «view» system
for å håndtere forespørsler, og et template system.





Når en applikasjon er konfigurert til å bruke en database, er det bare å skrive vanlige
python klasser(i Django kalles d
e modeller), og disse blir da automatisk(vha. én
kommando) opprettet som tabeller i databasen. Da er det bare å bruke klassene på
vanlig måte, og objektene lagres ved å bruke den innebygde funksjonen save(). Det er
altså ikke nødvendig å skrive en eneste l
inje med SQL med mindre man har helt
spesielle behov. I vår applikasjon har vi brukt disse modellene: Rule, User og
UserPermission. Rule brukes til å lagre brannmurregler. User er en del av Django
-
rammeverket og brukes til å lagre brukerdata, denne klassen

innehol
der mange ferdige

6. IMPLEMENTERING

15



funksjoner for

innlogging og autentisering. UserPermission bruker vi til å lagre
adresser som kobler en bruker opp mot en eller flere maskiner bak brannmuren. En
bruker kan bare se båndbreddegrafer for maskiner som er på denne lis
ten. I Django
-

applikasjoner er det mulig

å aktivere et innebygget admin
grensesnitt. Dette har vi
aktivert i vår applikasjon, og vi vil bruke dette til å opprette, endre og slette brukere.
Applikasjonen vår bruker innebygde funksjoner til å håndtere innlog
ging og utlogging.
Disse var relativt enkle å ta i bruk.


Når en Django
applikasjon mottar en forespørsel fra en klient, blir «stien» i denne
forespørselen sammenlignet med oppføringene i filen urls.py, for å bestemme hvilken
funskjon som skal håndtere fore
spørselen. Slike funksjoner kalles views. Her er et lite
utdrag fra vår urls.py:


(r'^home/$', 'bandaid.views.home'),

(r'^rules/$', 'bandaid.views.rules'),

(r'^editrule/(?P<id>[0
-
9]+)/$', 'bandaid.views.editrule'),


Hvis vår applikasjon nå mottar en foresp
ørsel:
http://eksempel.brannmur.no/rules/
, vil
stien «rules/» matche det regulære uttrykket i linje nr. 2. Det betyr at funksjonen
bandaid.views.rules skal ta seg av denne forespørselen. Rules view'et sjekker først om
brukeren er innlogget, og om han har rettigheter til å se denne siden. Videre l
eser det
inn alle reglene fra databasen, og sender disse dataene videre til en spesifikk template.
Template systemet i Django er basert på HTML filer med «ekstra tagger» som blir
byttet ut med de data som viewet sender. Når template'en har blitt fyllt ut m
ed data fra
databasen, vil view'et returnere den ferdige HTML
-
siden, og Django sender så denne
tilbake til klienten. Hvis brukeren ikke har rettigheter til å vise siden, vil view'et
returnere en HTML
-
side med en feilmelding. Template systemet er rimelig av
ansert,
med funksjonalitet for blant annet: variabler, if
-
setninger, for
-
løkker og mye mer. Det
er også mulig å skrive egne template
-
tagger, noe vi benyttet oss av i vår applikasjon.


Den viktigste funksjonaliteten i vår webapplikasjon er håndtering av br
annmurregler.
PF fungerer slik at når maskinen starter opp lastes konfigurasjonen som er lagret i
/etc/pf.conf. Første gang webgrensesnittet tas i bruk finnes det ingen regler i
databasen. Vi har derfor implementert en funksjon som leser inn de kjørende
br
annmurreglene fra PF og lagrer dem i databasen. Sammen med PF følger det med et
program
,

pfctl
,

som brukes til å utføre endringer i den kjørende konfigurasjonen. Det
er dette programmet vi bruker til å lese inn den gjeldende konfigurasjonen. Python
som er
et scriptspråk har støtte for å utføre skallkommandoer på systemet. Derfor kan
vi kalle pfctl fra webapplikasjonen og hente utdataene tilbake som en tekststreng. Vi
har brukt regulære uttrykk til å tolke denne tekststrengen slik at hver regel blir delt inn

i attributter. Etter at brannmurreglene er lest inn i databasen kan brukeren arbeide med
disse reglene. Vi har laget funksjonalitet for å legge til nye, redigere og slette
eksisterende regler. En annen funksjon vi har implementert vha. pfctl er å sjekke
s
yntaksen til reglene. Hvis det finnes syntaksfeil i en eller flere av reglene, vil
brukeren få beskjed om dette, og i noen tilfeller også informasjon om hva som er galt.
Den siste viktige funksjonen når det gjelder brannmurregler er å ta i bruk reglene som

ligger i databasen. Dette har vi implementert slik at vi åpner filen pf.conf og fjerner

7. TESTING

16



alle brannmurregler som er lagret der. Så skriver vi inn alle de nye reglene fra
databasen, og ber PF laste inn konfigurasjonsfilen på nytt vha. pfctl. Dermed vil
bran
nmuroppsettet være det samme også etter en reboot.


Funksjonalitet for å vise grafer over båndbreddebruk har vi implementert ved sende
klienten en HTML
-
side som inneholder alle tilgjengelige grafer på brannmuren. Etter
at klienten har mottatt denne, sender

den ut en ny forespørsel for hver av <img>
taggene i denne filen. Vanlige brukere skal kun ha tilgang til sine «egne» grafer. Dette
har vi løst ved å sjekke UserPermissions for hver bildeforespørsel som mottas. Hvis
brukeren har rettigheter til å se denne

grafen, vil bildet returneres til klienten. Hvis
ikke, returneres en standard feilmelding. Andre bilder som kun har med layout å gjøre,
serveres gjennom Apache.


Logg delen av webapplikasjonen lister opp alle loggoppføringer fra PF som stammer
fra de sist
e 48 timene.
Vi har konfigurert
PF

til å lagre

disse loggene på fil, og
automatisk slette

de

som er
eldre enn 48 timer.

Disse loggene er komprimert med
bzip2, og lagret i et format kalt tcpdump. For å vise loggene må vi først kjøre en
kommando for å pakke
dem opp, og deretter må de tolkes vha. tcpdump
applikasjonen.


7. TESTING

Som beskrevet tidligere, har vi et testnettverk bestående av tre maskiner. En
brannmur

og to maskiner som står på hver sin side av
brannmur
en.

Vi har testet kontinuerlig underveis.

Hver gang vi har gjort en endring i systemet har vi
forsikret oss om at ingen ting har sluttet å fungere.

Ved endringer i nettverks
innstillinger

og
brannmur
regler har vi testet at maskinene i de
forskjellige nettene fremdeles kan nå hverandre. Det er ogs
å testet at de ikke kan nå
hverandre ved enkelte
brannmur
regler.

Når ny programvare er installert ble det testet om programmene fungerte med
standardkonfigurasjoner. Og hver gang konfigurasjonen ble endret testet vi at
programmene fungerte etter endringen.

Vi har også testet
brannmur
en mot enkle angrep, som ordliste
-
angrep mot
FTP og
SSH. Det ble gjort ved
hjelp av verktøy som vi fant på internett.

Webgrensesnittet ble først utviklet på andre maskiner enn
brannmur
en. Her ble det
testet mot en enkel database
server, SQLite 3, og en enkel webserv
er som følger med
django. Etter
hvert når vi måtte få webgrensesnittet til å snakke med PF, ble alt flyttet
over på
brannmur
en. Her ble kode testet mot PF, PostgreSQL og Apache. Det ble
fremdeles kodet litt på andre mas
kiner grunnet mangelen på godt oversiktlige
teksteditorer i skallet. Denne koden ble flettet sammen med resten ved hjelp av
Subversion, før den ble testet mot de aktuelle delene av systemet.

Ved slutten av hele prosjektet testet vi funksjonaliteten til
br
annmur
en, ved å teste
forskjellige re
gler gitt av webgrensesnittet.

Når det gjelder skalerbarhet på systemet, har vi ikke utført noen tester. Ytelsen til vårt
system er kun avhengig av ytelsen til PF. Maskinvaren er den viktigste faktoren som
kan begrense ytelsen. Den viktigste komponenten er nettverkskortet. Et gigabit ko
rt vil
yte godt i små til middels store nettverk. Ytelsen kommer mer an på antall pakker som

8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

17



går gjennom brannmuren, enn på båndbreddebruk. Dette systemet er ikke ment for
bruk i veldig store nettverk, så vi har ikke sett så mye på skalerbarhet
.



8. BESKR
IVELSE AV UTVIKLET SYSTEM I BRUK


8.1 Brukerdokumentasjon


Innlogging og adgangskontroll




Dette er den første siden som vises, her kan man logge

seg inn med
registrert

brukernavn og passord.



8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

18



Ved vellykket innlogging kommer man til velkomstsiden:





Vi har brukt navnet BandAid som arbeidsnavn på prosjektet, men dette vil ikke bli
stående når systemet tas i bruk. På velkomstsiden

står

det

en kort forklaring på hva
BandAid er og det forklares at det finnes to typer brukere: administrator, som har
tilgan
g til alt, og vanlig bruker, som kun har tilgang til båndbreddegrafer for noen
spesifiserte IP
-
adresser.



8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

19



Ved å klikke på ”Log out” nede til høyre på siden

(vises alltid)
, kommer man hit:




Her kan man, via en link, komme seg tilbake til innloggingssiden.



8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

20



Grafer over båndbreddebruk


Ved å velge menyvalget ”Graphs” kommer man til denne siden:





Denne siden viser grafer over båndbreddebruk
for de IP
-
adressene man har til
gang til.
Dersom m
an er administrator kan man se grafer for alle registrerte IP
-
adresser. Det er
fem grafer per IP
-
adresse:



8 timer tilbake i tid



1 døgn

tilbake i tid



1 uke tilbake i tid



1 måned tilbake i tid



1 år tilbake i tid


8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

21



Brannmur
regler


Ved å velge menyvalget
”Firewallrules” kommer man til denne siden:





Her vises en oversikt over
brannmur
ens regler. Disse kan man
flytte opp eller ned ved
å klikke på pilene til høyre for regelen. Ved å klikke på det røde krysset, sletter man
regelen. Det kommer opp forklarin
g på disse knappene når man holder musen over.


Det er også flere andre funksjoner i forbindelse med regeltabellen:



”Read rules from pfctl”
. Ved å klikke her vil
de kjørende reglene til PF leses
inn i databasen, og dermed oppdateres på websiden.




”Save
rules to pf.conf”
.
Denne knappen vil lagre informasjonen fra tabellen til
pf.conf. Da blir først alle regler som står i pf.conf slettet, så blir de nye reglene
skrevet inn og dette lagres. Slik at det som ligger av regler i pf.conf blir identisk
med det som vises på skjermen
. Deretter vil
PF laste inn den nye
konfigurasjonsfilen slik at de nye reglene blir tatt i bruk.




8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

22





“Syntax check”
. Hvis man klikker her vil man v.h.a. pfctl sjekke reglene i
databasen(dvs. de reglene som vises på websiden)

og få feilmelding dersom det
ikke

er korrekt syntaks. Her er et eksempel på hvordan feilmeldingen ser ut når
reglene inneholder syntaks feil:






8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

23





”Add rule”. Denne knappen
fører deg til siden vist under. Her kan man legge til
en ny regel i databasen. Siden viser en liste med felter som k
an fylles ut for å
spesifisere en regel.
Feltene er: action, enabled, direction, log, quick, interface,
address family, protocol, source address, source port, destination address,
destination port, misc og description.
Det er også en liten forklaring ved h
vert
felt som sier hva som skal fylles inn i feltet.

På bunnen av siden har man tre alternativer:



”Save”



lagrer til databasen og linker deg tilbake til siden med oversikt
over reglene. Da er den nye regelen lagt inn på bunnen av listen. (Men
den kan flyt
tes oppover v.h.a. pilen på siden av regelen).



”Save and add another”



lagrer til databasen og laster ”Add rule”
-
siden
på nytt med tomme felter.



”Cancel”
-

avbryt og gå tilbake til siden som viser listen over regler.






8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

24





”Edit / Show rules”
. Ved å trykke
her kan man editere en regel,

da vil også alle
detaljer om regelen vises, bl.a. ”address
-
family” og ”description”
.

Deretter kan
man enten velge ”Save”(lagre til databasen og gå tilbake til regellisten) eller
”Cancel”(avbryt og gå tilbake til regellisten).

Slik ser siden for å editere en
regel ut:





8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

25



Logger


Ved å velge menyvalget ”Logs” kommer man til denne siden:





Her vises en liste over logger fra de forskjellige logfilene til PF. Disse inneholder log
for 48 timer tilbake i tid.




8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

26



8.2 Drifts
-

og
vedlikeholdsdokumentasjon

Installere FreeBSD

En skikkelig steg for steg gjennomgang finnes her:
http://www.freebsd.org/doc/en_US.ISO8859
-
1/books/handbook/install.html
.

Vi går raskt igjennom, og tar kun med de viktigeste stegene.


Vi gjennomgår installasjonen i fra CD.

Først må man hente ISO
-
bildene i fra

nettet. De kan enkelt hentes
fra
www.freebsd.org/where.html
. Pass p
å å laste ned den versjonen som passer
arkitekturen til CPUen. Det mest normale er i386.

Brenn ut ISO
-
bildene på CD. Versjon 6.2, som vi har brukt, krever 2 Cder.

Sett CD #1 i CD
-
ROMen på maskinen som skal kjøre
brannmur
en og reboot
maskinen.

Grensesnittet

man får opp nå kalles Sysinstall.

Gå inn på «Keymap» først og velg norsk tastatur. Når dette er gjort, kommer man ut i
hovedmenyen igjen. Her velger man «Standard» for å starte standard installasjon.

Nå skal man allokere harddiskplass. Velg hvilken harddisk som skal brukes og trykk
«Ok».

Her skal det lages 4 partisjon
er. På den maskinen vi testet på hadde vi bare en 5GB
harddisk. Vi brukte da dette oppsettet:

«swap»: 512MB

«/»: 200MB

«/var»: 500MB

«/u
sr»: Resten av av disken.


Swap b
ør være minst like stor
som

størrelsen på

minnet i maskinen

(helst dobbelt så
stor)
.

«/» partisjonen trenger ikk
e være så stor, men minst 100MB.

«/var» er hvor loggene legges. Dersom det skal logges mye på maskinen bør det
være
litt størrelse p
å denne. Den bør være minst 50MB
.

«/usr» inneholder alle programmer, hjemmekataloger, systemfiler osv. Denne bør være
så stor som mulig.

Dersom det står en stor harddisk i maskinen kan man trykke «A», og det opprettes
partisjoner autom
atisk.

Trykk «Q» etter partisjoneringen er gjort.

Nå skal det bestemmes hvilken versjon som skal installeres. Velg «User» her, og trykk
ja på spørsmålet om å installere «FreeBSD Ports collection».

Velg så CD
-
ROM som installasjonsmedie.

Hopp over nettverks
-

og mus
-
instillinger. Men tidssone kan være grei å sette.

Når du kan velge «pakker» som skal installeres kan man velge å ta med følgende
pakker: pico(eller en annen editor man liker), bash og portupgrade. Dette er ikke
nødvendig, da

man kan installere det
te etter
på. Installasjon av portupgrade er
beskrevet lenger nede.

Man kan også velge å legge til en bruker «apache» når man får spørsmål om man vil
opprette ny bruker eller gruppe, men dette kan også gjøres senere.


8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

27



Nå vil man få beskjed om å sette «root
-
pa
ssord». Gjør dette og fortsett installasjonen.

Når denne er ferdig skal man gå ut av Sysinstall
-
grensesnittet, og man får spørsmål om
å starte maskinen på nytt.

Systemet kan tas i bruk etter rebooten.



Kommandoer som kjøres med $ er ”apache”
-
brukeren,
med # skal det kjøres som
root.


Opprett ny bruker

Siden vi kommer til å trenge en bruker som ikke har root
-
tilgang, oppretter vi en
bruker ”apache”


# adduser


Her går man bare igjennom veiledningen.


Oppsett av PF

Legg til i
rc.conf
:

pf_enable="YES" # Enable PF (load module if


# required)

pf_rules="/etc/pf.conf" # rules definition file for pf

pf_flags="" # additional flags for pfctl startup

pflog_enable="YES" # start pflogd(8)

pflog_logfile="/var/log/pflog" # where pflogd should store the


# logfile

pflog_flags="" # additional flags for pflogd


# st
artup

gateway_enable="YES" # Enable as LAN gateway


# Set the IP of the LAN network card (rl0)

ifconfig_rl0="inet 10.0.0.1 netmask 255.255.255.0"

# Request IP of the LAN network card from DHCP (xl0)

ifconfig_xl0="DHCP"

Her er nettverkskortet som står mot lokalnettet
rl0
, og det som vender ut er
xl0
. Her
settes de innstillingene som er aktuelle for nettverkene systemet skal settes opp i. Vi
vil bruke
10.0.0.1
på i
nterfacet som vender inn mot lokalnettet, og
10.47.120.149

(tildelt av DHCP) på det som vender ut.

Editer i
/etc/pf.conf
:

ext_if="xl0"

int_if="rl0"

internal_net="10.0.0.1/24"

external_addr="10.47.120.149"


8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

28



nat on $ext_if from $internal_net to any
-
> ($ext_
if)

Sjekk med
# netstat
-
rn

at det finnes ruter til begge nettverkene og at default rute
er til gateway på eksternnettet. På serveren bak
brannmur

skal det settes ipadresse og
default rute til
brannmur
.

#ifconfig bfe0 10.0.0.2 netmask 255.255.255.0

#
route add default 10.0.0.1

Driveren til nettverkskortet på denne maskinen heter
bfe0.
Dette kan selvfølgelig
variere fra maskin til maskin. Navn på interface kan man finne ved å kjøre
# ifconfig

kommandoen.

Legg til i
/etc/sysctl.conf

om

nat skal brukes:

net.inet.ip.forwarding=1

Om ting ikke
virker
, prøv
# pfctl
-
e



Bygge ALTQ inn i kjernen

Dersom kjernekilden ikke er innstallert, dvs det finnes ingen
/usr/src/sys

mappe i
systemet, må dette gjøres. Det letteste er da å kjøre
sysinstall

som root, deretter
velge
Configure
, så
Distributions
, så
src
. Installer kildene
base

og
sys
.
Alternativt kan du installere med følgende kommandoer:

# mount /cdrom

# mkdir
-
p /usr/src/sys

# ln
-
s /usr/src/sys /sys

# cat /cdrom/src/ssys.[a
-
d]* | tar
-
xzvf
-

# cat /cdrom/src/sbase.[a
-
d]* | tar
-
xzvf
-

Det kan være en god idé å lagre kjernekonfigurasjonen en trygg plass, for så å lage en
link til
/usr/src/sys/i386/conf
:

# cd /usr/src/sys/i386/conf

# mkdir /root/kernels

# cp GENERIC /root/kernels/MYKERNEL

# ln
-
s /root/kernels/MYKERNEL

Nå skal du redigere kernel konfigurasjonen, kompilere og installere kjernen:

# vi /root/kernels/MYKERNEL

# cd /usr/src

# make buildkernel KERNCONF=MYKERNEL

# make installkernel KERNCONF=MYKERNEL


8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

29



Oppsett av CVSUP og
Portupgrade

Installer Portupgrade fra FreeBSD CD
-
ROMen.

Kjør:


# sysinstall


Velg

Configuration
-
>Packages.
Velg å installere fra CD
-
ROM. Gå så på
sysutils

og velg portupgrade
-
pakken. Trykk så på installer.


cp /usr/share/examples/cvsup/ports
-
supfile /etc



Editer denne filen så den henter ifra
cvsup.no.freebsd.org.

Så skal cvsup
-
databasen oppdateres.


# cvsup
-
g
-
L 2 /etc/ports
-
supfile


Sette opp Apache

Installer med apache22 porten. (
portupgrade
-
RPN www/apache22
).

Legg til i
/etc/rc.conf
:

apache22_enable="YES"

Legg til i
/boot/loader.conf:

accf_data_load="YES"

Bak
127.0.0.1

i
/etc/hosts

skal du forandre
localhost.my.domain

til
maskinnavn med domene. eks.
gamletappern.in.copyleft.no



Installere mod_python

Installere Python uten tråd
-
støtte

# cd /usr/ports/lang/python

# make clean

# WIHTOUT_THREADS=1 make install

# portupgrade
-
RPN www/mod_python3


Installere PostgreSQL


# portupgrade
-
RPN databases/postgresql82
-
client


8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

30



# portupgrade
-
RPN
databases/postgresql82
-
server

# portupgrade
-
RPN databases/py
-
psycopg2

py
-
psycopg2

er en pakke som django må ha for å kunne bruke PostgreSQL.

# su
-

pgsql

$ /usr/local/pgsql/bin/initdb

$ /usr/local/bin/pg_ctl
-
D /usr/local/pgsql/data
-
l logfile start

$ /
usr/local/pgsql/bin/createdb test

Editer
/usr/local/pgsql/data/pg_hba.conf
:

# TYPE DATABASE USER CIDR
-
ADDRESS METHOD

host all all 10.47.120.149/32 password

Editer
/usr/local/pgsql/data/postgresql.conf
:

#
-

Connection Settings
-



listen_addresses = '*'


port = 5432


Installere PMACCT

# portupgrade
-
RPN net
-
mgmt/pmacct


Installere pNRG

Last ned pNRG tarball, og pakk den ut i
/usr/local/pnrg


#portupgrade
-
RPN net/rrdtool

Editer
/usr/local/pnrg/contribs/pmacct
-
pnrg.conf:

interface: rl0 #interfacet som står mot lokalnettet

aggregate_filter[out]: src net 10.0.0.0/24

aggregate_filter[in]: dst net 10.0.0.0/24


Start opp pmacctd med config som passer til pNRG:


# pmacctd
-
f
/usr/local/pnrg/contribs/pmacct
-
pnrg.conf

Kjør kommando:

$ crontab
-
e


8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

31



Legg inn denne linjen:

*/5 * * * * ( cd /usr/local/pnrg/; ./pnrg
-
wrapper.sh )

Opprett en link til

/usr/local/pngr/spool/


$ ln
-
s /usr/local/pngr/spool /home/apache/www/pngr

Sørg
for å gi brukeren

apache

eierskap og kjørerettigheter til filene i
/usr/local/pngr

og i

/usr/local/pngr/spool


#chown apache:apache *

Editer

/usr/local/etc/apache22/httpd.conf:

User apache

Group apache


DocumentRoot "/home/apache/www"


<Directory
"/home/apache/www">

Options Indexes FollowSymLinks ExecCGI

</Directory>


<Directory /home/apache/www/media
>

Options Indexes

AllowOcerride None

Order allow,deny

Allow from all

</Directory>


<Location "/bandaid
/">


SetHandler python
-
program


PythonHandler django.core.handlers.modpython


SetEnv DJANGO_SETTINGS_MODULE
sandbox
.settings


PythonDebug On

</Location>



<IfModule mime_module>

AddHandler cgi
-
script .cgi

</IfModule>

Start apache på nytt:

# apachectl restart


8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

32





Nagiosscript

Scriptet er laget av Garry W. Cook, og det kan lastes ned i fra
nagiosexchange.org
. Det
eneste som er editert er sti til RRDtool og RRD
-
filene, samt at det ser
på de 16 siste
timene og ikke 5 minuttene.

check_rrd_bw.sh:


#!/bin/sh

####################################################################
############

#

# CHECK_RRD_BW plugin for Nagios

#

# Written by Garry W. Cook <garry@cookbros.net>

#

#

# Description:

# This plugin will read the current value from an rrd file and

# compare with warning and critical values, for either inbound or

# outbound bandwidth parameters.

#

#

# Notes:

#
-

This plugin requires:

#

rrdtool

#

awk

#

#

# Example checkcommands.cfg
entry:

#

# 'check_rrd' command definition

#define command{

#

command_name

check_rrd_bw.sh

#

command_line

$USER1$/check_rrd $ARG1$ $ARG2$ $ARG3$ $ARG4$

# [$ARG5$]

#

}

#

#

# Edit the following variables to match your
system.

# RRDTOOL Binary Directory

RRDTOOL="/usr/local/rrdtool/bin"

# RRD Files Directory

RRDFILES="/var/www/html/mrtg/rrdfiles"


#

# Nothing to change below this line

#


PROGNAME=`basename $0`

PROGPATH=`echo $0 | /bin/sed
-
e 's,[
\
\
/][^
\
\
/][^
\
\
/]*$,,'`

R
EVISION=`echo '$Revision: 1.4 $' | sed
-
e 's/[^0
-
9.]//g'`


8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

33





. $PROGPATH/utils.sh


print_usage() {


echo ""


echo "Usage:"


echo " $0 [
-
bkmg] <rrdfile> <in|out> <warning> <critical>"


echo " $0 (
-
V |
--
version)"


echo " $0 (
-
h |
--
help)"


echo ""


# Need to change this to ranges in future


echo "Warning and critical thresholds are MAX values,"


echo "going above the threshold will trigger an alert."


echo ""


echo "
Labels and multiplier for warning and critical values"


echo "are determined by the first argument:"


echo "B=bps; K=Kbps (Default); M=Mbps; G=Gbps"


echo ""

}


print_help() {


print_revision $PROGNAME $REVISION


print_usage


echo "Nagios Plugin: Check Bandwidth within an RRD."


echo ""


support

}




exitstatus=$STATE_UNKNOWN #default


# Check for
--
help, etc.

case $1 in


-
V)


print_revision


exit $STATE_UNKNOWN


;;


--
version)


print_revision


exit $STATE_UNKNOWN


;;


-
h)


print_help


exit $STATE_UNKNOWN


;;


--
help)


print_help


exit $STATE_UNKNOWN


;;

esac


# Verify correct number of arguments

if [ $#
-
lt 4 ]; then


print_usage


exit $STATE_UNKNOWN


8. BESKRIVELSE AV UTVIKLET SYSTEM I BRUK

34



fi


while [ $#
-
eq 5 ];do


case $1 in


B)



LABEL=""



DIV="1000"




;;


K)



LABEL="$1"



DIV="100000"




;;


M)



LABEL="$1"



DIV="1000000"




;;


G)



LABEL="$1"



DIV="1000000000"




;;


*)



echo "$1 not a valid Label/Multiplier"



exit $STATE_UNKNOWN




;;


esac


shift

done


FILE=$1

BW=$2

WARNING=$3

CRITICAL=$4


####################################################################
###########################

# Hmmm... Am I multiplying by 8 to get Bytes and then dividing by an
#extra 100 to get bits???

####################################################################
###########################


# Verify file exists and calculate current inbound or outbound

#bandwidth

if [
-
e "$RRDFILES/$FILE" ]; then


if [ $BW = "in" ]; then


VALUE="$($RRDTOOL/rrdtool fetch $RRDFILES/$FILE AVERAGE
-
s
-



16hours | awk 'BEGIN { IFS=":" } NR==3 { printf("%d
\
n", $2 *


8) }')"


elif [ $BW = "out" ]; t
hen


VALUE="$($RRDTOOL/rrdtool fetch $RRDFILES/$FILE AVERAGE
-
s
-



16hours | awk 'BEGIN { IFS=":" } NR==3 { printf("%d
\
n", $3 *


8) }')"


fi




if [ $(($VALUE/${DIV:
-
100000}))
-
gt $CRITICAL ]; then


echo "CRITICAL
-

Current BW $BW: $(($VALUE/${DIV:
-



100000}))"${LABEL:
-
K}"bps"


9. OPPSUMMERING, DISKUSJON OG KONKLUSJONER

35




exit $STATE_CRITICAL


elif [ $(($VALUE/${DIV:
-
100000}))
-
gt $WARNING ]; then


echo "WARNING
-

Current BW $BW: $(($VALUE/${DIV:
-



100000}))"${LABEL:
-
K}"bps"


exit $STATE_WARNING


else


echo "OK
-

Current BW $BW: $(($VALUE/${DIV:
-



100000}))"${LABEL:
-
K}"bps"


exit $STATE_OK


fi

else


echo "$RRDFILES/$FILE does not exist."


exit $STATE_UNKNOW
N

fi


exit $exitstatus






9. OPPSUMMERING, DISKUSJON OG KONKLUSJONER

9.1 Resultat i forhold til kravspesifikasjon

Vi er godt fornøyd m
ed arbeidet vi har gjort og
hvordan resultatet ble til slutt. Vi synes
vi har gjort en god jobb i forhold til
kravspesifikasjonen. Systemet fungerer nå som det
skal, og alle de viktigste funksjonene som oppdragsgiver ønsket er implementert.

Det
var tre punkter i kravspesifikasjonen

vi ikke fikk tid

til
: PDF
-
rapport, køstyring og å
lage distribusjonspakke. Disse fu
nksjonene

var fra begynnelsen av regnet som mindre
viktige, og ble derfor nedprioritet da vi innså at
dette var nødvendig.
V
i konsulterte
med Copyleft

om dette
, og de var enig i våre vurderinger.

Dersom det i etterkant er ønskelig å implementere disse
funksjonene,

vil ikke dette
være en stor jobb for oppdragsgiver. Til å generere PDF
-
rapporter antar vi at det finnes
open source programvare som lett kan tilpasses deres behov. Køstyring er delvis
implementert.
I webgrensesnittet er det fullt mulig å bruke

manuelt opprettede køer,
men det gjenstår
å lage støtte for å opprette køer
. Ifølge oppdragsgiver er det fort gjort
å lage en distribusjonspakke for vårt system. Dette er noe de har mye erfaring med fra
tidligere prosjekt.


9.2 Resultat i forhold til fre
mdriftsplan

Vi har ikke klart å følge den opprinnelige fremdriftsplanen. Grunnen til dette er at det
underveis har dukket opp flere påvirkende faktorer som har gjort at noen aktiviteter
har tatt lenger tid enn planlangt og noen har gått raskere enn planlan
gt. Vi måtte derfor
sette opp en ny fremdriftsplan i slutten av april, hvor vi endret rekkefølge og lengde på
d
e resterende aktivitetene. Den nye

planen er mer realistisk i forhold til tidsbruk og
avhengighete
r mellom aktivitetene. I denne
planen hadde vi

ikke lenger oppgaven
inndelt i tre hoveddeler. I og med at vi ganske tidlig gjorde store deler av del tre, og
måtte utsette deler av del en, var det da lettere å se på de aktivitetene som gjenstod

9. OPPSUMMERING, DISKUSJON OG KONKLUSJONER

36



hver for seg og ikke som et underpunkt til en av hoveddele
ne. Vi ville også sette opp
en del av aktivitetene på en litt annen måte enn vi tenkte i starten. Blant annet ville vi
ikke lage en pakke for hver del, men en pakke for hele systemet.

Det ble også store endringer i forhold til databaseprogrammet. Vi ville

ikke lagre
logging i databasen, slik vi trodde i starten. pNRG tar seg av båndbreddemålingen, og
lagrer dataene i en rrd
-
database. Loggen fra PF
har vi lagret

på filsystemet lokalt på
maskinen. Det som lagres i databasen er kun det som trengs til webgrens
esnittet.


Vi mener vi har fulgt den nye planen ganske bra, men vi har lært at det kan være
veldig vanskelig å følge en detaljert tidsplan slavisk fra dag til dag, det vil alltid dukke
opp uforutsette ting. Det har også vært mye nytt for oss, dermed har de
t vært noe
vanskelig å planlegge hvor lang tid dette ville ta.

Derfor er vi glad for at vi satte av uke 22 til gjenstående arbeid.

Denne uken trengte vi
til å jobbe mer med
webg
rensesnittet.


Det har blitt noen forsinkelser, men ingen som har gitt store ko
nsekvenser. Det at noen
aktiviteter også har gått raskere enn forventet, har veid opp for eventuelle store
forsinkelser.


9.3 Resultat i forhold til risikoanalyse

En av risikoene vi satte opp var server krasj, dette ble en realitet da vi
i uke 19

oppdaget

en feil på maskinen hvor

vi har

brannmur
en. Resultatet ble at vi måtte
formatere harddisken og installere alt på nytt. Dette
brukte vi

lit
t over to dager på, så
dette

ført
e

til noen forsinkelser. V
i var

heldigvis

flink å dokumentere
tidligere arbeid,
derm
ed gikk

det mye fortere å gjøre det denne gangen.


En annen risiko vi satte opp var sykdom. Det har ikke inntruffet, men uforutsett fravær
har inntruffet. I siste uke måtte Yngve på obligatorisk heimevernsøvelse, dette gjorde
at vi

måtte fordele de gjenstå
ende arbeidsoppgavene noe annerledes, og jobbe litt
ekstra den siste helgen.


9.4

Ansvarsfordeling og samarbeid

Vi har stort sett jobbet sammen om alle oppgaver.
N
oen oppgaver har fordelt seg
naturlig blant oss, bl.a. pga ulike

kunnskapsområder og erfarin
ger, men vi har ikke
definert noen spesifikke ansvarsområder.
Vi synes vi har jobbet godt sammen som
gruppe, og
vi
har ikke hatt noen komplikasjoner innad i gruppen.

Vi har arbeidet jevn og trutt gjennom
hele prosjektperioden, med

arbeidstid fra 09.00
til tidligst 16.00 hver dag.





10. LITTERATURLISTE

37



10. LITTERATURLISTE

10.1 Websider



www.djangobook.com



www.djangoproject.org



www.freebsd.org/docs.html



www.openbsd.org/faq/pf/



www.pmacct.net



http://oss.o
etiker.ch/rrdtool/



www.pfsense.com



http://m0n0.ch/wall
/



www.bgnett.no/~peter/pf/no/index.html



http://www.nagiosexchange.org/Others.152.0.html?&tx_netnagext_pi1%5Bp_v
iew%5D=2



http://cl.wiki.no



www.postgres
ql.org



http://apache.org



http://w3schools.com



http://eple.hib.no



http://oswd.org



www.nagios.org



www.wikipedia.org


Disse websidene har vi hentet informasjon fra i perioden mars
-
juni 2007.






VEDLEGG

38



VEDLEGG


Vedlegg A: Ordliste


ALTQ

Køstyringsverktøy

Apache

Webserver

Brannmur

Sørger for
filtrering av trafikk inn og ut av ett nettverk

Cron

Verktøy for å kjøre oppgaver ved gitte tidsintervall

CVSUP

Program som sørger for synkronisering av filer og mapper

Database

Samling av relaterte data

Django

Webrammeverk basert på Python

FreeBSD

Operativsystem

IPadresse

Unik nettverksadresse

Monowall

Webapplikasjon for styring av brannmur(IPfilter)

Nagios

S
ystem for
overvåkning av maskiner og tjenester


Nettmaske

Et tall som brukes sammen med IP
-
adresse for å oppgi en serie

Packet Filter, PF

Brannmurprogramvare

Pf.conf

Konfigurasjonsfil for Packet Filter

Pfctl

Program til å styre Packet Filter

PFsense

Webapplikasjon for styring av brannmur(Packet Filter)

PMACCT

Verktøy for nettverksovervåkning

pNRG

Program som genererer grafer basert på
data fra PMACCT

Portupgrade

Verktøy for å bruke pakkesystemet i FreeBSD

PostgreSQL

Databasesystem

Python

Et høynivå programmeringsspråk

RRDtool

Round Robin databaseverktøy

Server

En maskin som leverer informasjon til andre maskiner i et nettverk

SQLite

En enkel dat
a
baseserver

Subversion

Versjonskontrollsystem

Switch

Knutepunkt i et nettverk som kan knytte sammen flere enheter

Webapplikasjon

Programvare som produserer websider ut ifra forespørsler

Webgrensesnitt

Brukergrensesnitt levert over
internett

Webserver

Programvare/maskin som leverer websider



VEDLEGG

39



Vedlegg B: Fremdriftsplan/Gant
t
-
diagram




Opprinnelig
tids
plan






VEDLEGG

40



Revidert tidsplan




VEDLEGG

41



Vedlegg C: Risikoliste


ID


R1


Risiko


Vi bruke
r lengre tid enn planlagt på å
tilegne oss den
kunnskapen vi trenger.

Konsekvens


Vi blir forsinket i framdriften. I verste fall blir vi ikke ferdig med prosjektet i tide.

Sannsynlighet


Relativt stor.

Alvorlighet


Kommer an på hvor mye forsinket vi b
lir. Veldig
alvorlig dersom vi ikke blir ferdig

med den
viktigste funksjonaliteten

i tide.

Tiltak


Planlegge bedre.

Kommentar


Vi må lære oss mye nytt i forbindelse med oppgaven: Python, Django, FreeBSD, PF,



Nagios, PostgreSQL. Det er vanskelig å vite hvor lang tid det vil ta å lære seg disse


tingene, derfor er det ganske stor sannsynlighet for at det tar lengre tid enn planlagt.




ID


R2


Risiko


Sykdom

Konsekvens


Arbeidet blir forsinket

Sannsynlighet


Liten

Alvorlighet


Kommer an på varigheten.

Tiltak


Kommentar


Dersom sykdom inntreffer, vil vi eventuellt måtte endre fordelingen av arbeidsoppgaver.


Slik at vi sørger for at den fraværende sine arbeidsoppgaver fremdeles blir gjort.




ID


R3


Risiko


Undervurdering av prosjektets størrelse

Konsekvens


Prosjektet kan bli forsinket

Sannsynlighet


Liten

Alvorlighet


Ikke så alvorlig med litt forsinkelser.

Tiltak


God planlegging, realistiske frister.

Kommentar


Har tatt med i tidsberegningen at det er muligheter for forsinkelse, ved å sette av en uke


på slutten til å «hente oss inn igjen».




ID


R4


Risiko


Server krasj

Konsekvens


Arbeid kan gå tapt

Sannsynlighet


Liten

Alvorlighet


Middels

Tiltak


Ta back
-
up

Kommentar


Med server
krasj mener vi alle feil som kan inntreffe utenfor vår kontroll, og eventuelle


kritiske feil vi kan gjøre.




VEDLEGG

42



Vedlegg D
: Kode


Følgende filer finnes på vedlagt CD:



bandaid (mappe)



bandaid (mappe)



media
(mappe)



bg_topnav.gif



button.jpg



delete.jpg



down.jpg



flammer3.jpg



flammer5.jpg



green_in.jpg



green_in_out.jpg



green_out.jpg



red_in.jpg



red_in_out.jpg



red_out.jpg



styles.css



up.jpg



templates (mappe)



bandaid (mappe)



addrule.html



base.html



base_login.html



base
_site.html



editrule2.html



error.html



graphs.html



home.html



logged_out.html



login.html


VEDLEGG

43





logs.html



nat.html



rules.html



traffic.html



templatetags (mappe)



bandaid_tags.py



_init_.py



views (mappe)



_init_.py



static.py



_init_.py



models.py



settings.py



urls.py



AUTHORS



COPYING



README



cp_pfconf



bandaid_files.tar.gz