Teknologisk videncenter - User contributions [en]

File:DT4-ValgfagI.jpg

2010-02-02T11:32:16Z

Sahan109:

Netværk II IT2 KT2 januar 2010

2010-01-20T10:41:20Z

Sahan109:

File:Basic wireless Concepts and Configuration.pdf

2010-01-20T10:40:16Z

Sahan109:

2010-01-19T08:31:11Z

Sahan109:

IT2-KT2/skema uge 3 - 2010

2010-01-18T13:33:28Z

Sahan109:

{{Infobox ugeskema2
|uge = 3 | ugedage =
{{Infobox ugeskema/dag
|ugedag = Mandag
|dato = 18. Jan
|antalfag= 8
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = VTP øvelse
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Vtp øvelse
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Kapitel 4 test gennemgang
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Kapitel 5 teori (STP)
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Kapitel 5 teori (STP)
|aktivitet = Praktik
|tid = 12:00 - 12:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = STP øvelse
|aktivitet = Praktik
|tid = 12:45 - 13:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = STP øvelse
|aktivitet = Praktik
|tid = 13:45 - 14:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 14:30 - 15:15
|lokale = [[olc]]
|lærer = shan
}}
}}
{{Infobox ugeskema/dag
|ugedag = Tirsdag
|dato = 19. Jan
|antalfag= 8
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Morgenmøde / Teori Inter Vlan routing
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Gennemgang Kapitel test 5
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 12:00 - 12:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 12:45 - 13:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 13:45 - 14:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 14:30 - 15:15
|lokale = [[olc]]
|lærer = shan
}}
}}
{{Infobox ugeskema/dag
|ugedag = Onsdag
|dato = 20. Jan
|antalfag= 8
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[IT IT2 KT2 januar 2010|IT]]
|emne = -
|aktivitet = Praktik
|tid = 12:00 - 12:45
|lokale = [[olc]]
|lærer = kbiv
}}

{{Infobox ugeskema/dagfag2
|fag = [[IT IT2 KT2 januar 2010|IT]]
|emne = -
|aktivitet = Praktik
|tid = 12:45 - 13:30
|lokale = [[olc]]
|lærer = kbiv
}}

{{Infobox ugeskema/dagfag2
|fag = [[IT IT2 KT2 januar 2010|IT]]
|emne = -
|aktivitet = Praktik
|tid = 13:45 - 14:30
|lokale = [[olc]]
|lærer = kbiv
}}

{{Infobox ugeskema/dagfag2
|fag = [[IT IT2 KT2 januar 2010|IT]]
|emne = -
|aktivitet = Praktik
|tid = 14:30 - 15:15
|lokale = [[olc]]
|lærer = kbiv
}}
}}
{{Infobox ugeskema/dag
|ugedag = Torsdag
|dato = 21. Jan
|antalfag= 8
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Engelsk IT2 KT2 januar 2010|Engelsk]]
|emne = -
|aktivitet = Praktik
|tid = 12:00 - 12:45
|lokale = [[olc]]
|lærer = soch
}}

{{Infobox ugeskema/dagfag2
|fag = [[Engelsk IT2 KT2 januar 2010|Engelsk]]
|emne = -
|aktivitet = Praktik
|tid = 12:45 - 13:30
|lokale = [[olc]]
|lærer = soch
}}

{{Infobox ugeskema/dagfag2
|fag = [[Engelsk IT2 KT2 januar 2010|Engelsk]]
|emne = -
|aktivitet = Praktik
|tid = 13:45 - 14:30
|lokale = [[olc]]
|lærer = soch
}}

{{Infobox ugeskema/dagfag2
|fag = [[Engelsk IT2 KT2 januar 2010|Engelsk]]
|emne = -
|aktivitet = Praktik
|tid = 14:30 - 15:15
|lokale = [[olc]]
|lærer = soch
}}
}}
{{Infobox ugeskema/dag
|ugedag = Fredag
|dato = 22. Jan
|antalfag= 4
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}
}}
}}

Netværk II IT2 KT2 januar 2010

2010-01-18T12:12:20Z

Sahan109:

*[[CCNA]]
- Materialer
* Kapitel 3: [[media:Introducing VLANs.pdf|Introducing VLAN]]
* Kapitel 4: [[media:VTP.pdf|VTP]]
* Kapitel 5: [[media:STP.pdf|STP]]

Stuen: Christian, Lasse, Paw

Etage 1:

Etage 2: Helen, Jann, Jan

Etage 3:

Etage 4: Danni, Kristoffer, Kim J.

Etage 5:

Etage 6:

Øvelse
[[image:VlanØvelse.jpg|thumb|none|650px|Network diagram]]

IT2-KT2/skema uge 3 - 2010

2010-01-18T12:11:49Z

Sahan109:

{{Infobox ugeskema2
|uge = 3 | ugedage =
{{Infobox ugeskema/dag
|ugedag = Mandag
|dato = 18. Jan
|antalfag= 8
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = VTP øvelse
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Vtp øvelse
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Kapitel 4 test gennemgang
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Kapitel 5 teori (STP)
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = Kapitel 5 teori (STP)
|aktivitet = Praktik
|tid = 12:00 - 12:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = STP øvelse
|aktivitet = Praktik
|tid = 12:45 - 13:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = STP øvelse
|aktivitet = Praktik
|tid = 13:45 - 14:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 14:30 - 15:15
|lokale = [[olc]]
|lærer = shan
}}
}}
{{Infobox ugeskema/dag
|ugedag = Tirsdag
|dato = 19. Jan
|antalfag= 8
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 12:00 - 12:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 12:45 - 13:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 13:45 - 14:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 14:30 - 15:15
|lokale = [[olc]]
|lærer = shan
}}
}}
{{Infobox ugeskema/dag
|ugedag = Onsdag
|dato = 20. Jan
|antalfag= 8
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[IT IT2 KT2 januar 2010|IT]]
|emne = -
|aktivitet = Praktik
|tid = 12:00 - 12:45
|lokale = [[olc]]
|lærer = kbiv
}}

{{Infobox ugeskema/dagfag2
|fag = [[IT IT2 KT2 januar 2010|IT]]
|emne = -
|aktivitet = Praktik
|tid = 12:45 - 13:30
|lokale = [[olc]]
|lærer = kbiv
}}

{{Infobox ugeskema/dagfag2
|fag = [[IT IT2 KT2 januar 2010|IT]]
|emne = -
|aktivitet = Praktik
|tid = 13:45 - 14:30
|lokale = [[olc]]
|lærer = kbiv
}}

{{Infobox ugeskema/dagfag2
|fag = [[IT IT2 KT2 januar 2010|IT]]
|emne = -
|aktivitet = Praktik
|tid = 14:30 - 15:15
|lokale = [[olc]]
|lærer = kbiv
}}
}}
{{Infobox ugeskema/dag
|ugedag = Torsdag
|dato = 21. Jan
|antalfag= 8
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Engelsk IT2 KT2 januar 2010|Engelsk]]
|emne = -
|aktivitet = Praktik
|tid = 12:00 - 12:45
|lokale = [[olc]]
|lærer = soch
}}

{{Infobox ugeskema/dagfag2
|fag = [[Engelsk IT2 KT2 januar 2010|Engelsk]]
|emne = -
|aktivitet = Praktik
|tid = 12:45 - 13:30
|lokale = [[olc]]
|lærer = soch
}}

{{Infobox ugeskema/dagfag2
|fag = [[Engelsk IT2 KT2 januar 2010|Engelsk]]
|emne = -
|aktivitet = Praktik
|tid = 13:45 - 14:30
|lokale = [[olc]]
|lærer = soch
}}

{{Infobox ugeskema/dagfag2
|fag = [[Engelsk IT2 KT2 januar 2010|Engelsk]]
|emne = -
|aktivitet = Praktik
|tid = 14:30 - 15:15
|lokale = [[olc]]
|lærer = soch
}}
}}
{{Infobox ugeskema/dag
|ugedag = Fredag
|dato = 22. Jan
|antalfag= 4
|dagfag=

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:00 - 08:45
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 08:45 - 09:30
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 09:55 - 10:40
|lokale = [[olc]]
|lærer = shan
}}

{{Infobox ugeskema/dagfag2
|fag = [[Netværk II IT2 KT2 januar 2010|Netværk II]]
|emne = -
|aktivitet = Praktik
|tid = 10:40 - 11:25
|lokale = [[olc]]
|lærer = shan
}}
}}
}}

2010-01-15T08:27:17Z

Sahan109:

Netværk II IT2 KT2 januar 2010

2010-01-13T14:10:50Z

Opgave CCDP - Firewall

2009-08-13T11:46:13Z

Sahan109:

{{In progress}}
[[Opgave CCDP]]
[[Image:CCDP-Edge.png|800px|center|thumb|Enterprise Edge Design]]
__NOTOC__
 
=Internet=
[[Image:CCDP-WAN.png|500px|right|thumb|Multihomed Single Boarder Router Architecture]]
Internet bliver leveret af 2 forskellige ISP'er med alternativt fremførte linier, for at sikre sig mod kabelbrud, eller interne routnings problemer. Vi kører Routning med de 2 ISP'er og importerer alle internet routes til vores internet switch. 
Dette gør vi for at kunne vores sekundære ISP hvis den primære har routnings problemer, men kun for de routes det er nødvendige. 
Vores primære internet forbindelse bliver en 100Mbit, der bliver brugt til alt, dog med regler for at StudNet og PaNet maks kan bruge 50% så der altid er plads til dem der arbejder. Den sekundære ISP linie bliver en 50Mbit, som folk fint kan leve med, indtil den primære bliver fikset igen.
Skulle det vise sig at hastigheden bliver uacceptable kan linierne opgraderes. 

For at sikre os at alt trafik løber den rigtige vej ud af vores netværk skal BGP localpreference værdien på den primære linie sættes op, så det altid er den der bliver valgt til udgående trafik. Ved BGP er der utrolig mange parametre man kan bruge for at styre trafikken ud af sit netværk, men knap så mange man kan bruge til indgående. 
Nogle af dem man kan bruge er AS_PATH prepending. Det vil sige man tilføjer nogle dummy AS numre. Da BGP måler afstand i AS hops, vil den tage den korteste vej fra kilde til destination. Ved at lave AS_PATH prepending på det ene link, vil AS Hop længere ud i netværket bliver større og routen vil være knap så atraktiv.
 
For at sikre sig at alt trafik i en optimal situation kommer den rigtige vej ind i ens netværk, laver man AS_PATH prepending på det link der ikke skal bruges, linket vil så se ud som om det hat en længere AS_PATH til dit netværk og derfor mindre attrativ. Dette kan gøres sådan:
<pre>
router bgp 300
network 10.0.0.0

neighbor 10.10.10.10 remote-as 100

neighbor 20.20.20.20 remote-as 200
neighbor 20.20.20.20 route-map as_path_prepending out

!Tilføjer 2 ekstra hops til dit netværk
route-map as_path_prepending permit 10
set as-path prepend 300 300
end
</pre>

===Filtrering af trafik===
Når man laver en multihomed løsning er der nogle faldgrupper man skal passe på. Hvis man ikke filtrerer på de AS numrer man importerer kan man importere sin egen routing tabel, gennem sin ISP og lave et loop. Eller hvis man ikke filtrere på de paths man sender vidre, kan man være transit AS for trafik der skal et andet sted hen. Lad mig komme med nogle eksepler.

===Transit trafik filtrering===
Hvis man har flere ISP'er og kører fuld routning med dem via eBGP får man alle deres routes, for at forhindre trafik mellem AS 100 og AS 200 vil løbe igennem ens netværk kan man filtrere alle eksterne AS'er fra i de udgående AS_PATH's. Det vil sige at AS 100 kun kender til AS 300 gennem linket og AS 200 også kun kender til AS 300 gennem linket til vores enterprise netværk. Dette vil forhindre at de 2 ISP'er kender nogle andre veje igennem os end til AS 300. 
Et eksempel på configuration med transit trafik filtrering hvor man ikke sender nogle andre AS numre med i sine udgående routes.
<pre>
router bgp 300
network 10.0.0.0

neighbor 10.10.10.10 remote-as 100
neighbor 10.10.10.10 route-map localonly out

neighbor 20.20.20.20 remote-as 200
neighbor 20.20.20.20 route-map localonly out

ip as-path access-list 10 permit ^$

route-map localonly permit 10
match as-path 10
end

</pre>

===Inbound Filtering===
For at forhindre at man laver et black hole hvor trafik fra sig selv, til sig selv, ryger ud til ISP A og routed videre til ISP B hvorefter det kommer ind til dig selv igen, filtrere man sine egne ipadresser fra i indkomne routing updates. Derved sikrer man at ens netværk ikke kender andre veje til sig selv. 
De 2 primære grupper man skal være opmærksom på:
*Martian adresse områder
**RFC 1918 adresser. Skal bruges internt i en virksomhed og aldrig komme ud på internettet. 10.0.0.0/8, 172.16.0.0/12 & 192.168.0.0/16
**Loopback adresser. 127.0.0.0/8 adresserne er reserveret til internt brug på en host, og skal derfor aldrig modtages udefra, eller routes.
**Host autokonfigurations blok. 169.254.0.0/16 adresse området skal bruges for automatisk adresse tildeling når en DHCP server ikke forefindes.
**0.0.0.0/8 adresser. 0.0.0.0/8 adresserne er ikke tildelt og selv om nogle firmaer bruger dem, skal de ikke findes på internettet.
**Test netværks adresser. 192.0.2.0/24 er reserveret for test og beregnet til brug i dokumentation og sample kode.
**Klasse D og E adresser. Klasse D adresser bruges til multicast og bør derfor ikke bruges til unicast routning. Klasse E adresser er reserveret og derfor ikke i brug. Klasse D adresser = 224.0.0.0/4. Klasse E adresser = 240.0.0.0/4
*Sit eget netværk, for at undgå black holing
Da vores offentlige adresser ikke er fastlagt har jeg ikke smidt dem i configurationen:
<pre>
ip prefix-list martians seq 5 deny 0.0.0.0/8 le 32
ip prefix-list martians seq 10 deny 10.0.0.0/8 le 32
ip prefix-list martians seq 15 deny 172.16.0.0/12 le 32
ip prefix-list martians seq 20 deny 192.168.0.0/16 le 32
ip prefix-list martians seq 25 deny 127.0.0.0/8 le 32
ip prefix-list martians seq 30 deny 169.254.0.0/16 le 32
ip prefix-list martians seq 35 deny 192.0.2.0/24 le 32
ip prefix-list martians seq 40 deny 224.0.0.0/4 le 32
ip prefix-list martians seq 45 deny 240.0.0.0/4 le 32
ip prefix-list martians seq 50 permit 0.0.0.0/0
</pre>
Info trukket fra RFC1918<ref>http://www.isi.edu/in-notes/rfc1918.txt</ref> & RFC3330<ref>http://www.rfc-editor.org/rfc/rfc3330.txt</ref>

===DMZ===
Der oprettes DMZ zoner til hver logiske funktion, f.eks Mail og webservere i hver sin zone. For at samle og lette administration samles de forskellige zoner i en separat dmz context.
{|
|[[Image:dmz-context.png|300px|left|thumb]][[Image:FW-trekant.png|300px|right|thumb]]
|}
==WAN==
På Univeristets hospitalet installeres 2 alternativt fremførte 500Mbit MPLS linjer fra samme udbyder da det er her hele regionens patient data er centralizeret og den vil fungere som hub for de andre sygehuse i regionen. Hvert af de andre regions hospitaler får en redundant 100Mbit MPLS. 
Nogle af de overvejelser vi har gjort os omkring MPLS linierne er at de måske skal være dynamiske. Det vil sige man får en hurtig forbindelse men gennemsnittet skal holdes under en given trafik mængde. Vi har snakket om det da gennemsnits trafikken sikkert ikke vil være mere en hvad en 50Mbit kunne klare, men skal man fx bruge en 4 GB fil ville det tage 4000*8/50=640=6 min 40 sekunder at overføre filen. Dette er lang tid hvis man skal bruge den her og nu. En måde man kan lave flex forbindelser er ved at installere en 500Mbit forbindelse, men at man kun bruger de 500Mbit i bursts, og at gennemsnitet skal ligge på 50Mbit eller under. Dette ville gøre at samme fil kun tog lidt over et minut at hente.

===QoS===
I samarbejde med MPLS udbyderen tilkøbes der QoS for at så vidt muligt at kunne levere end to end traffik prioritering. Detaljerne om hvilke QoS muligheder der er vil afhænge af udbyderen men et eksempel kunne være 5 forskellige klasser baseret på IP precedence, med en kø dedikeret til IP telephony. Desværre har man sjældent som kunde nogen indflydelse på hvad der ryger i hvilke kører og båndbredde tildelingen. Så man må typisk remarkere pakkerne i sin edge.
Det kan skabe problemer hvis man skifter mpls udbyder da to selskaber sjældent benytter den samme QoS model, eller hvis man benytter 2 forskellige udbydere, da pakker skal markeres forskelligt.

=Sikkerhed=

==Network Management==
På alle netværks enheder opsættes syslog til en central server i datacenteret, for bedre at kunne overvåge udstyret og bistå i fejlfinding. Alle enheder sættes også i samme omgang til at rapportere ind til en MARS appliance boks også placeret i datacenteret, for at kunne give et mere komplet billede af en sikkerheds situation.
For at lette administration og configuration af sikkerheds enhederne installeres CSManger som giver et centralt adgangspunkt til udstyret.

CiscoWorks benyttes til at håndtere configurations ændringer samt bistå som syslog server for at hutigt og effiktivt at kunne mitigere fejl på netværket.
SNMP traps for udvalgte begivenheder sendes til en central opsamler, her bør der benyttes SNMPv3 for at kunne benytte kryptering imodsætning til SNMPv1+2 hvor community strengene sendes i klar tekst. Et ressource monitorerings system opsamler via SNMPv3 statestik for de enkelte enheder såsom båndbredde, interface statistik, hukommelsesforbrug osv. Alle porte skal monitoreres selv access porte, da man så vil kunne se hvor eventuelle flaskehalse opstår.

Alt adgang til netværks enhederne håndteres med Tacacs mod en ACS server som authentikerer op imod AD'et. Gruppe politikker sættes op således at kun netværks administratorene har adgang. I de tilfælde hvor udstyret ikke kan nå acs eller Domain controllerne benyttes et lokalt brugernavn og password på de enkelte bokse. Der anbefales at der fastlægges en runtine hvor disse passwords med jævne mellemrum ændres.

==IDS==
Intrusion Detection System(IDS) er en enhed der overvåger det netværkstrafik den får tilsendt, og via nogle algoritmer og kendte signaturer kan finde og overvåge skidt trafik og give alarmer når der skal tages affære. 
Der placeres en IDS sensor på den offentlige side af netværket for at kunne monitorere eventuelle angreb udefra og man kan derved hurtigt og effiktivt tage hånd om problemer indefra og udefra herunder DoS og reconnacence. Dette kan involvere et tæt samarbejde med internet udbyderne.
Derudover tilknyttes der også IDS sensore til edge distribution da det er det centrale knudepunkt for data til og fra hele wan og dmz og remote access til enterprise campus.

==Ekstern adgang==
Eksterne firmaer som skal have adgang til interne ressourcer håndteres med minimal belastning på IT afdelingen, som i praksis udeler et brugernavn, password, definerer de tilladte ip addresser, og en vejledning til hvordan de installerer og opsætter vpn klienten.
Løsningen består af vpn termination på en sæt ASA appliance bokse hvor der oprettes en access-liste til hvert firma eller person således at der kun er adgang til de nøvendige ressourcer og ikke hele det interne netværk. Til dette benyttes også en certificat server placeret i DMZ'en. Afhængigt af virksomhedens præferance kan Anyconnect<ref>http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080972e4f.shtml</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

Al vpn terminering sker på et sæt ASA bokse som sidder parallelt med internettet. Vpn loadbalancing slåes til for at udnytte de tilgændelige ressourcer bedst muligt. Det anbefales at kasserne er ens, men det er ikke et krav. Der kan tilmed benyttes en vpn concentrator i clusteret.

 
Eksempel på dele af configuration af et eksternt firma:
<pre>
<output omitted>
access-list companyXXX line 1 extended permit ip any <ip address> <subnet mask>

access-list companyXXX extended deny ip any any log disable
group-policy companyXXX internal
group-policy companyXXX attributes
vpn-filter value companyXXX
banner value companyXXX

ldap attribute-map AD_to_group_map
map-value memberOf CN=companyXXX,LDAPCN companyXXX
<output omitted>
</pre>

For medarbejdere der arbejder hjemmefra eller som har behov for at tilgå interne ressourer fra andre netværk, benyttes microsofts indbyggede remote access klient, hvor al opsætning styres via gruppepolitikker i AD'et.

==Firewall==
Firewallen skal bestå af 2 ASA 5540 som skal have et context (virtuel firewall) for hver net (StudNet, AdmNet, PaNet, MedNet) og det vil være med til at lave Active-Active. Når 2 ASA'er bliver bundled, ses de som en maskine, med en configuration, hvor man så deler context ud til hver af dem, så ASA 1 fx bliver aktiv for StudNet og PaNet, og ASA 2 bliver aktiv for AdmNet og MedNet, samt de er backup for hinanden.
 
Hver context er sin egen virtuelle firewall med seperate sikkerhedspolitikker og fungerer som havde det været adskilt i fysisk seperate enheder. En ting man dog skal være opmærksom på er at når en asa er i firewall multimode understøttes følgende features ikke:
*VPN
*Dynamisk routings protocol
*QoS
*Multicast routing
 
I vores foreslåede setup vil de forskellige context dele den offenlige ip addresse via et shared interface og nat tabellen bruges til classifier ind og på udgåede traffik klafficeres der på interfacet.<ref>http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/contexts.html#wp1133984</ref>
[[Image:FW_context_out.png|300px|left|thumb]][[Image:FW_context_in.png|300px|center|thumb]]
 

<pre><output omitted>
hostname(config-if)# interface gigabitethernet 0/1.1
hostname(config-subif)# vlan 101
hostname(config-subif)# context MedNet
hostname(config-ctx)# allocate-interface gigabitethernet 0/1.1
hostname(config-ctx)# allocate-interface gigabitethernet 1/1
hostname(config-if)# interface gigabitethernet 0/1.2
hostname(config-subif)# vlan 102
hostname(config-subif)# context StudNet
hostname(config-ctx)# allocate-interface gigabitethernet 0/1.2
hostname(config-ctx)# allocate-interface gigabitethernet 1/1
<output omitted>
</pre>
For at sikre os mod at brugerne i en context ikke tager alle firewallens ressourcer(cpu,ram) ved et overdrevet antal nat translations og samtidinge forbindelser tildeles hver context en procentdel af enhedens totale ressourcer. Det er dog ikke alle ressourcer hvor det kan lade sig gøre såsom antal hosts og application inspections.<ref>http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/mngcntxt.html</ref> Bemærk at tallene i følgende eksempel måske ikke er retvisende da det vil kræve en større indsigt i den pågældende virksomheds traffik mønster.

<pre>
hostname(config)# class MedNet
hostname(config-class)# limit-resource conns 40%
hostname(config-class)# limit-resource hosts 3000

hostname(config)# class AdmNet
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 2000

hostname(config)# class PaNet
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 2000

hostname(config)# class Default
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 9000
</pre>
 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-13T11:43:39Z

Sahan109: /* DMZ */

{{In progress}}
[[Opgave CCDP]]
[[Image:CCDP-Edge.png|800px|center|thumb|Enterprise Edge Design]]
__NOTOC__
 
=Internet=
[[Image:CCDP-WAN.png|500px|right|thumb|Multihomed Single Boarder Router Architecture]]
Internet bliver leveret af 2 forskellige ISP'er med alternativt fremførte linier, for at sikre sig mod kabelbrud, eller interne routnings problemer. Vi kører Routning med de 2 ISP'er og importerer alle internet routes til vores internet switch. 
Dette gør vi for at kunne vores sekundære ISP hvis den primære har routnings problemer, men kun for de routes det er nødvendige. 
Vores primære internet forbindelse bliver en 100Mbit, der bliver brugt til alt, dog med regler for at StudNet og PaNet maks kan bruge 50% så der altid er plads til dem der arbejder. Den sekundære ISP linie bliver en 50Mbit, som folk fint kan leve med, indtil den primære bliver fikset igen.
Skulle det vise sig at hastigheden bliver uacceptable kan linierne opgraderes. 

For at sikre os at alt trafik løber den rigtige vej ud af vores netværk skal BGP localpreference værdien på den primære linie sættes op, så det altid er den der bliver valgt til udgående trafik. Ved BGP er der utrolig mange parametre man kan bruge for at styre trafikken ud af sit netværk, men knap så mange man kan bruge til indgående. 
Nogle af dem man kan bruge er AS_PATH prepending. Det vil sige man tilføjer nogle dummy AS numre. Da BGP måler afstand i AS hops, vil den tage den korteste vej fra kilde til destination. Ved at lave AS_PATH prepending på det ene link, vil AS Hop længere ud i netværket bliver større og routen vil være knap så atraktiv.
 
For at sikre sig at alt trafik i en optimal situation kommer den rigtige vej ind i ens netværk, laver man AS_PATH prepending på det link der ikke skal bruges, linket vil så se ud som om det hat en længere AS_PATH til dit netværk og derfor mindre attrativ. Dette kan gøres sådan:
<pre>
router bgp 300
network 10.0.0.0

neighbor 10.10.10.10 remote-as 100

neighbor 20.20.20.20 remote-as 200
neighbor 20.20.20.20 route-map as_path_prepending out

!Tilføjer 2 ekstra hops til dit netværk
route-map as_path_prepending permit 10
set as-path prepend 300 300
end
</pre>

===Filtrering af trafik===
Når man laver en multihomed løsning er der nogle faldgrupper man skal passe på. Hvis man ikke filtrerer på de AS numrer man importerer kan man importere sin egen routing tabel, gennem sin ISP og lave et loop. Eller hvis man ikke filtrere på de paths man sender vidre, kan man være transit AS for trafik der skal et andet sted hen. Lad mig komme med nogle eksepler.

===Transit trafik filtrering===
Hvis man har flere ISP'er og kører fuld routning med dem via eBGP får man alle deres routes, for at forhindre trafik mellem AS 100 og AS 200 vil løbe igennem ens netværk kan man filtrere alle eksterne AS'er fra i de udgående AS_PATH's. Det vil sige at AS 100 kun kender til AS 300 gennem linket og AS 200 også kun kender til AS 300 gennem linket til vores enterprise netværk. Dette vil forhindre at de 2 ISP'er kender nogle andre veje igennem os end til AS 300. 
Et eksempel på configuration med transit trafik filtrering hvor man ikke sender nogle andre AS numre med i sine udgående routes.
<pre>
router bgp 300
network 10.0.0.0

neighbor 10.10.10.10 remote-as 100
neighbor 10.10.10.10 route-map localonly out

neighbor 20.20.20.20 remote-as 200
neighbor 20.20.20.20 route-map localonly out

ip as-path access-list 10 permit ^$

route-map localonly permit 10
match as-path 10
end

</pre>

===Inbound Filtering===
For at forhindre at man laver et black hole hvor trafik fra sig selv, til sig selv, ryger ud til ISP A og routed videre til ISP B hvorefter det kommer ind til dig selv igen, filtrere man sine egne ipadresser fra i indkomne routing updates. Derved sikrer man at ens netværk ikke kender andre veje til sig selv. 
De 2 primære grupper man skal være opmærksom på:
*Martian adresse områder
**RFC 1918 adresser. Skal bruges internt i en virksomhed og aldrig komme ud på internettet. 10.0.0.0/8, 172.16.0.0/12 & 192.168.0.0/16
**Loopback adresser. 127.0.0.0/8 adresserne er reserveret til internt brug på en host, og skal derfor aldrig modtages udefra, eller routes.
**Host autokonfigurations blok. 169.254.0.0/16 adresse området skal bruges for automatisk adresse tildeling når en DHCP server ikke forefindes.
**0.0.0.0/8 adresser. 0.0.0.0/8 adresserne er ikke tildelt og selv om nogle firmaer bruger dem, skal de ikke findes på internettet.
**Test netværks adresser. 192.0.2.0/24 er reserveret for test og beregnet til brug i dokumentation og sample kode.
**Klasse D og E adresser. Klasse D adresser bruges til multicast og bør derfor ikke bruges til unicast routning. Klasse E adresser er reserveret og derfor ikke i brug. Klasse D adresser = 224.0.0.0/4. Klasse E adresser = 240.0.0.0/4
*Sit eget netværk, for at undgå black holing
Da vores offentlige adresser ikke er fastlagt har jeg ikke smidt dem i configurationen:
<pre>
ip prefix-list martians seq 5 deny 0.0.0.0/8 le 32
ip prefix-list martians seq 10 deny 10.0.0.0/8 le 32
ip prefix-list martians seq 15 deny 172.16.0.0/12 le 32
ip prefix-list martians seq 20 deny 192.168.0.0/16 le 32
ip prefix-list martians seq 25 deny 127.0.0.0/8 le 32
ip prefix-list martians seq 30 deny 169.254.0.0/16 le 32
ip prefix-list martians seq 35 deny 192.0.2.0/24 le 32
ip prefix-list martians seq 40 deny 224.0.0.0/4 le 32
ip prefix-list martians seq 45 deny 240.0.0.0/4 le 32
ip prefix-list martians seq 50 permit 0.0.0.0/0
</pre>
Info trukket fra RFC1918<ref>http://www.isi.edu/in-notes/rfc1918.txt</ref> & RFC3330<ref>http://www.rfc-editor.org/rfc/rfc3330.txt</ref>

===DMZ===
Der oprettes DMZ zoner til hver logiske funktion, f.eks Mail og webservere i hver sin zone. For at samle og lette administration samles de forskellige zoner i en separat dmz context.
[[Image:dmz-context.png|300px|left|thumb]][[Image:FW-trekant.png|300px|right|thumb]]

==WAN==
På Univeristets hospitalet installeres 2 alternativt fremførte 500Mbit MPLS linjer fra samme udbyder da det er her hele regionens patient data er centralizeret og den vil fungere som hub for de andre sygehuse i regionen. Hvert af de andre regions hospitaler får en redundant 100Mbit MPLS. 
Nogle af de overvejelser vi har gjort os omkring MPLS linierne er at de måske skal være dynamiske. Det vil sige man får en hurtig forbindelse men gennemsnittet skal holdes under en given trafik mængde. Vi har snakket om det da gennemsnits trafikken sikkert ikke vil være mere en hvad en 50Mbit kunne klare, men skal man fx bruge en 4 GB fil ville det tage 4000*8/50=640=6 min 40 sekunder at overføre filen. Dette er lang tid hvis man skal bruge den her og nu. En måde man kan lave flex forbindelser er ved at installere en 500Mbit forbindelse, men at man kun bruger de 500Mbit i bursts, og at gennemsnitet skal ligge på 50Mbit eller under. Dette ville gøre at samme fil kun tog lidt over et minut at hente.

===QoS===
I samarbejde med MPLS udbyderen tilkøbes der QoS for at så vidt muligt at kunne levere end to end traffik prioritering. Detaljerne om hvilke QoS muligheder der er vil afhænge af udbyderen men et eksempel kunne være 5 forskellige klasser baseret på IP precedence, med en kø dedikeret til IP telephony. Desværre har man sjældent som kunde nogen indflydelse på hvad der ryger i hvilke kører og båndbredde tildelingen. Så man må typisk remarkere pakkerne i sin edge.
Det kan skabe problemer hvis man skifter mpls udbyder da to selskaber sjældent benytter den samme QoS model, eller hvis man benytter 2 forskellige udbydere, da pakker skal markeres forskelligt.

=Sikkerhed=

==Network Management==
På alle netværks enheder opsættes syslog til en central server i datacenteret, for bedre at kunne overvåge udstyret og bistå i fejlfinding. Alle enheder sættes også i samme omgang til at rapportere ind til en MARS appliance boks også placeret i datacenteret, for at kunne give et mere komplet billede af en sikkerheds situation.
For at lette administration og configuration af sikkerheds enhederne installeres CSManger som giver et centralt adgangspunkt til udstyret.

CiscoWorks benyttes til at håndtere configurations ændringer samt bistå som syslog server for at hutigt og effiktivt at kunne mitigere fejl på netværket.
SNMP traps for udvalgte begivenheder sendes til en central opsamler, her bør der benyttes SNMPv3 for at kunne benytte kryptering imodsætning til SNMPv1+2 hvor community strengene sendes i klar tekst. Et ressource monitorerings system opsamler via SNMPv3 statestik for de enkelte enheder såsom båndbredde, interface statistik, hukommelsesforbrug osv. Alle porte skal monitoreres selv access porte, da man så vil kunne se hvor eventuelle flaskehalse opstår.

Alt adgang til netværks enhederne håndteres med Tacacs mod en ACS server som authentikerer op imod AD'et. Gruppe politikker sættes op således at kun netværks administratorene har adgang. I de tilfælde hvor udstyret ikke kan nå acs eller Domain controllerne benyttes et lokalt brugernavn og password på de enkelte bokse. Der anbefales at der fastlægges en runtine hvor disse passwords med jævne mellemrum ændres.

==IDS==
Intrusion Detection System(IDS) er en enhed der overvåger det netværkstrafik den får tilsendt, og via nogle algoritmer og kendte signaturer kan finde og overvåge skidt trafik og give alarmer når der skal tages affære. 
Der placeres en IDS sensor på den offentlige side af netværket for at kunne monitorere eventuelle angreb udefra og man kan derved hurtigt og effiktivt tage hånd om problemer indefra og udefra herunder DoS og reconnacence. Dette kan involvere et tæt samarbejde med internet udbyderne.
Derudover tilknyttes der også IDS sensore til edge distribution da det er det centrale knudepunkt for data til og fra hele wan og dmz og remote access til enterprise campus.

==Ekstern adgang==
Eksterne firmaer som skal have adgang til interne ressourcer håndteres med minimal belastning på IT afdelingen, som i praksis udeler et brugernavn, password, definerer de tilladte ip addresser, og en vejledning til hvordan de installerer og opsætter vpn klienten.
Løsningen består af vpn termination på en sæt ASA appliance bokse hvor der oprettes en access-liste til hvert firma eller person således at der kun er adgang til de nøvendige ressourcer og ikke hele det interne netværk. Til dette benyttes også en certificat server placeret i DMZ'en. Afhængigt af virksomhedens præferance kan Anyconnect<ref>http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080972e4f.shtml</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

Al vpn terminering sker på et sæt ASA bokse som sidder parallelt med internettet. Vpn loadbalancing slåes til for at udnytte de tilgændelige ressourcer bedst muligt. Det anbefales at kasserne er ens, men det er ikke et krav. Der kan tilmed benyttes en vpn concentrator i clusteret.

 
Eksempel på dele af configuration af et eksternt firma:
<pre>
<output omitted>
access-list companyXXX line 1 extended permit ip any <ip address> <subnet mask>

access-list companyXXX extended deny ip any any log disable
group-policy companyXXX internal
group-policy companyXXX attributes
vpn-filter value companyXXX
banner value companyXXX

ldap attribute-map AD_to_group_map
map-value memberOf CN=companyXXX,LDAPCN companyXXX
<output omitted>
</pre>

For medarbejdere der arbejder hjemmefra eller som har behov for at tilgå interne ressourer fra andre netværk, benyttes microsofts indbyggede remote access klient, hvor al opsætning styres via gruppepolitikker i AD'et.

==Firewall==
Firewallen skal bestå af 2 ASA 5540 som skal have et context (virtuel firewall) for hver net (StudNet, AdmNet, PaNet, MedNet) og det vil være med til at lave Active-Active. Når 2 ASA'er bliver bundled, ses de som en maskine, med en configuration, hvor man så deler context ud til hver af dem, så ASA 1 fx bliver aktiv for StudNet og PaNet, og ASA 2 bliver aktiv for AdmNet og MedNet, samt de er backup for hinanden.
 
Hver context er sin egen virtuelle firewall med seperate sikkerhedspolitikker og fungerer som havde det været adskilt i fysisk seperate enheder. En ting man dog skal være opmærksom på er at når en asa er i firewall multimode understøttes følgende features ikke:
*VPN
*Dynamisk routings protocol
*QoS
*Multicast routing
 
I vores foreslåede setup vil de forskellige context dele den offenlige ip addresse via et shared interface og nat tabellen bruges til classifier ind og på udgåede traffik klafficeres der på interfacet.<ref>http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/contexts.html#wp1133984</ref>
[[Image:FW_context_out.png|300px|left|thumb]][[Image:FW_context_in.png|300px|center|thumb]]
 

<pre><output omitted>
hostname(config-if)# interface gigabitethernet 0/1.1
hostname(config-subif)# vlan 101
hostname(config-subif)# context MedNet
hostname(config-ctx)# allocate-interface gigabitethernet 0/1.1
hostname(config-ctx)# allocate-interface gigabitethernet 1/1
hostname(config-if)# interface gigabitethernet 0/1.2
hostname(config-subif)# vlan 102
hostname(config-subif)# context StudNet
hostname(config-ctx)# allocate-interface gigabitethernet 0/1.2
hostname(config-ctx)# allocate-interface gigabitethernet 1/1
<output omitted>
</pre>
For at sikre os mod at brugerne i en context ikke tager alle firewallens ressourcer(cpu,ram) ved et overdrevet antal nat translations og samtidinge forbindelser tildeles hver context en procentdel af enhedens totale ressourcer. Det er dog ikke alle ressourcer hvor det kan lade sig gøre såsom antal hosts og application inspections.<ref>http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/mngcntxt.html</ref> Bemærk at tallene i følgende eksempel måske ikke er retvisende da det vil kræve en større indsigt i den pågældende virksomheds traffik mønster.

<pre>
hostname(config)# class MedNet
hostname(config-class)# limit-resource conns 40%
hostname(config-class)# limit-resource hosts 3000

hostname(config)# class AdmNet
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 2000

hostname(config)# class PaNet
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 2000

hostname(config)# class Default
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 9000
</pre>
 

==Referenceliste==
<references/>

[[Category:CCDP]]

2009-08-13T10:22:47Z

Sahan109: /* Alternativer */

{{In progress}}
[[Opgave CCDP]]
[[Image:CCDP-Edge.png|800px|center|thumb|Enterprise Edge Design]]
__NOTOC__
 
=Internet=
[[Image:CCDP-WAN.png|500px|right|thumb|Multihomed Single Boarder Router Architecture]]
Internet bliver leveret af 2 forskellige ISP'er med alternativt fremførte linier, for at sikre sig mod kabelbrud, eller interne routnings problemer. Vi kører Routning med de 2 ISP'er og importerer alle internet routes til vores internet switch. 
Dette gør vi for at kunne vores sekundære ISP hvis den primære har routnings problemer, men kun for de routes det er nødvendige. 
Vores primære internet forbindelse bliver en 100Mbit, der bliver brugt til alt, dog med regler for at StudNet og PaNet maks kan bruge 50% så der altid er plads til dem der arbejder. Den sekundære ISP linie bliver en 50Mbit, som folk fint kan leve med, indtil den primære bliver fikset igen.
Skulle det vise sig at hastigheden bliver uacceptable kan linierne opgraderes. 

For at sikre os at alt trafik løber den rigtige vej ud af vores netværk skal BGP localpreference værdien på den primære linie sættes op, så det altid er den der bliver valgt til udgående trafik. Ved BGP er der utrolig mange parametre man kan bruge for at styre trafikken ud af sit netværk, men knap så mange man kan bruge til indgående. 
Nogle af dem man kan bruge er AS_PATH prepending. Det vil sige man tilføjer nogle dummy AS numre. Da BGP måler afstand i AS hops, vil den tage den korteste vej fra kilde til destination. Ved at lave AS_PATH prepending på det ene link, vil AS Hop længere ud i netværket bliver større og routen vil være knap så atraktiv.
 
For at sikre sig at alt trafik i en optimal situation kommer den rigtige vej ind i ens netværk, laver man AS_PATH prepending på det link der ikke skal bruges, linket vil så se ud som om det hat en længere AS_PATH til dit netværk og derfor mindre attrativ. Dette kan gøres sådan:
<pre>
router bgp 300
network 10.0.0.0

neighbor 10.10.10.10 remote-as 100

neighbor 20.20.20.20 remote-as 200
neighbor 20.20.20.20 route-map as_path_prepending out

!Tilføjer 2 ekstra hops til dit netværk
route-map as_path_prepending permit 10
set as-path prepend 300 300
end
</pre>

===Filtrering af trafik===
Når man laver en multihomed løsning er der nogle faldgrupper man skal passe på. Hvis man ikke filtrerer på de AS numrer man importerer kan man importere sin egen routing tabel, gennem sin ISP og lave et loop. Eller hvis man ikke filtrere på de paths man sender vidre, kan man være transit AS for trafik der skal et andet sted hen. Lad mig komme med nogle eksepler.

===Transit trafik filtrering===
Hvis man har flere ISP'er og kører fuld routning med dem via eBGP får man alle deres routes, for at forhindre trafik mellem AS 100 og AS 200 vil løbe igennem ens netværk kan man filtrere alle eksterne AS'er fra i de udgående AS_PATH's. Det vil sige at AS 100 kun kender til AS 300 gennem linket og AS 200 også kun kender til AS 300 gennem linket til vores enterprise netværk. Dette vil forhindre at de 2 ISP'er kender nogle andre veje igennem os end til AS 300. 
Et eksempel på configuration med transit trafik filtrering hvor man ikke sender nogle andre AS numre med i sine udgående routes.
<pre>
router bgp 300
network 10.0.0.0

neighbor 10.10.10.10 remote-as 100
neighbor 10.10.10.10 route-map localonly out

neighbor 20.20.20.20 remote-as 200
neighbor 20.20.20.20 route-map localonly out

ip as-path access-list 10 permit ^$

route-map localonly permit 10
match as-path 10
end

</pre>

===Inbound Filtering===
For at forhindre at man laver et black hole hvor trafik fra sig selv, til sig selv, ryger ud til ISP A og routed videre til ISP B hvorefter det kommer ind til dig selv igen, filtrere man sine egne ipadresser fra i indkomne routing updates. Derved sikrer man at ens netværk ikke kender andre veje til sig selv. 
De 2 primære grupper man skal være opmærksom på:
*Martian adresse områder
**RFC 1918 adresser. Skal bruges internt i en virksomhed og aldrig komme ud på internettet. 10.0.0.0/8, 172.16.0.0/12 & 192.168.0.0/16
**Loopback adresser. 127.0.0.0/8 adresserne er reserveret til internt brug på en host, og skal derfor aldrig modtages udefra, eller routes.
**Host autokonfigurations blok. 169.254.0.0/16 adresse området skal bruges for automatisk adresse tildeling når en DHCP server ikke forefindes.
**0.0.0.0/8 adresser. 0.0.0.0/8 adresserne er ikke tildelt og selv om nogle firmaer bruger dem, skal de ikke findes på internettet.
**Test netværks adresser. 192.0.2.0/24 er reserveret for test og beregnet til brug i dokumentation og sample kode.
**Klasse D og E adresser. Klasse D adresser bruges til multicast og bør derfor ikke bruges til unicast routning. Klasse E adresser er reserveret og derfor ikke i brug. Klasse D adresser = 224.0.0.0/4. Klasse E adresser = 240.0.0.0/4
*Sit eget netværk, for at undgå black holing
Da vores offentlige adresser ikke er fastlagt har jeg ikke smidt dem i configurationen:
<pre>
ip prefix-list martians seq 5 deny 0.0.0.0/8 le 32
ip prefix-list martians seq 10 deny 10.0.0.0/8 le 32
ip prefix-list martians seq 15 deny 172.16.0.0/12 le 32
ip prefix-list martians seq 20 deny 192.168.0.0/16 le 32
ip prefix-list martians seq 25 deny 127.0.0.0/8 le 32
ip prefix-list martians seq 30 deny 169.254.0.0/16 le 32
ip prefix-list martians seq 35 deny 192.0.2.0/24 le 32
ip prefix-list martians seq 40 deny 224.0.0.0/4 le 32
ip prefix-list martians seq 45 deny 240.0.0.0/4 le 32
ip prefix-list martians seq 50 permit 0.0.0.0/0
</pre>
Info trukket fra RFC1918<ref>http://www.isi.edu/in-notes/rfc1918.txt</ref> & RFC3330<ref>http://www.rfc-editor.org/rfc/rfc3330.txt</ref>

===DMZ===
Der oprettes DMZ zoner efter hver funktion, f.eks Mail og webservere i hver sin.
[[Image:FW-trekant.png|300px|right|thumb]]

==WAN==
På Univeristets hospitalet installeres 2 alternativt fremførte 500Mbit MPLS linjer fra samme udbyder da det er her hele regionens patient data er centralizeret og den vil fungere som hub for de andre sygehuse i regionen. Hvert af de andre regions hospitaler får en redundant 100Mbit MPLS. 
Nogle af de overvejelser vi har gjort os omkring MPLS linierne er at de måske skal være dynamiske. Det vil sige man får en hurtig forbindelse men gennemsnittet skal holdes under en given trafik mængde. Vi har snakket om det da gennemsnits trafikken sikkert ikke vil være mere en hvad en 50Mbit kunne klare, men skal man fx bruge en 4 GB fil ville det tage 4000*8/50=640=6 min 40 sekunder at overføre filen. Dette er lang tid hvis man skal bruge den her og nu. En måde man kan lave flex forbindelser er ved at installere en 500Mbit forbindelse, men at man kun bruger de 500Mbit i bursts, og at gennemsnitet skal ligge på 50Mbit eller under. Dette ville gøre at samme fil kun tog lidt over et minut at hente.

===QoS===
I samarbejde med MPLS udbyderen tilkøbes der QoS for at så vidt muligt at kunne levere end to end traffik prioritering. Detaljerne om hvilke QoS muligheder der er vil afhænge af udbyderen men et eksempel kunne være 5 forskellige klasser baseret på IP precedence, med en kø dedikeret til IP telephony. Desværre har man sjældent som kunde nogen indflydelse på hvad der ryger i hvilke kører og båndbredde tildelingen. Så man må typisk remarkere pakkerne i sin edge.
Det kan skabe problemer hvis man skifter mpls udbyder da to selskaber sjældent benytter den samme QoS model, eller hvis man benytter 2 forskellige udbydere, da pakker skal markeres forskelligt.

=Sikkerhed=

==Network Management==
På alle netværks enheder opsættes syslog til en central server i datacenteret, for bedre at kunne overvåge udstyret og bistå i fejlfinding. Alle enheder sættes også i samme omgang til at rapportere ind til en MARS appliance boks også placeret i datacenteret, for at kunne give et mere komplet billede af en sikkerheds situation.
For at lette administration og configuration af sikkerheds enhederne installeres CSManger som giver et centralt adgangspunkt til udstyret.

CiscoWorks benyttes til at håndtere configurations ændringer samt bistå som syslog server for at hutigt og effiktivt at kunne mitigere fejl på netværket.
SNMP traps for udvalgte begivenheder sendes til en central opsamler, her bør der benyttes SNMPv3 for at kunne benytte kryptering imodsætning til SNMPv1+2 hvor community strengene sendes i klar tekst. Et ressource monitorerings system opsamler via SNMPv3 statestik for de enkelte enheder såsom båndbredde, interface statistik, hukommelsesforbrug osv. Alle porte skal monitoreres selv access porte, da man så vil kunne se hvor eventuelle flaskehalse opstår.

Alt adgang til netværks enhederne håndteres med Tacacs mod en ACS server som authentikerer op imod AD'et. Gruppe politikker sættes op således at kun netværks administratorene har adgang. I de tilfælde hvor udstyret ikke kan nå acs eller Domain controllerne benyttes et lokalt brugernavn og password på de enkelte bokse. Der anbefales at der fastlægges en runtine hvor disse passwords med jævne mellemrum ændres.

==IDS==
Intrusion Detection System(IDS) er en enhed der overvåger det netværkstrafik den får tilsendt, og via nogle algoritmer og kendte signaturer kan finde og overvåge skidt trafik og give alarmer når der skal tages affære. 
Der placeres en IDS sensor på den offentlige side af netværket for at kunne monitorere eventuelle angreb udefra og man kan derved hurtigt og effiktivt tage hånd om problemer indefra og udefra herunder DoS og reconnacence. Dette kan involvere et tæt samarbejde med internet udbyderne.
Derudover tilknyttes der også IDS sensore til edge distribution da det er det centrale knudepunkt for data til og fra hele wan og dmz og remote access til enterprise campus.

==Ekstern adgang==
Eksterne firmaer som skal have adgang til interne ressourcer håndteres med minimal belastning på IT afdelingen, som i praksis udeler et brugernavn, password, definerer de tilladte ip addresser, og en vejledning til hvordan de installerer og opsætter vpn klienten.
Løsningen består af vpn termination på en sæt ASA appliance bokse hvor der oprettes en access-liste til hvert firma eller person således at der kun er adgang til de nøvendige ressourcer og ikke hele det interne netværk. Til dette benyttes også en certificat server placeret i DMZ'en. Afhængigt af virksomhedens præferance kan Anyconnect<ref>http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080972e4f.shtml</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

Al vpn terminering sker på et sæt ASA bokse som sidder parallelt med internettet. Vpn loadbalancing slåes til for at udnytte de tilgændelige ressourcer bedst muligt. Det anbefales at kasserne er ens, men det er ikke et krav. Der kan tilmed benyttes en vpn concentrator i clusteret.

 
Eksempel på dele af configuration af et eksternt firma:
<pre>
<output omitted>
access-list companyXXX line 1 extended permit ip any <ip address> <subnet mask>

access-list companyXXX extended deny ip any any log disable
group-policy companyXXX internal
group-policy companyXXX attributes
vpn-filter value companyXXX
banner value companyXXX

ldap attribute-map AD_to_group_map
map-value memberOf CN=companyXXX,LDAPCN companyXXX
<output omitted>
</pre>

For medarbejdere der arbejder hjemmefra eller som har behov for at tilgå interne ressourer fra andre netværk, benyttes microsofts indbyggede remote access klient, hvor al opsætning styres via gruppepolitikker i AD'et.

==Firewall==
Firewallen skal bestå af 2 ASA 5540 som skal have et context (virtuel firewall) for hver net (StudNet, AdmNet, PaNet, MedNet) og det vil være med til at lave Active-Active. Når 2 ASA'er bliver bundled, ses de som en maskine, med en configuration, hvor man så deler context ud til hver af dem, så ASA 1 fx bliver aktiv for StudNet og PaNet, og ASA 2 bliver aktiv for AdmNet og MedNet, samt de er backup for hinanden.
 
Hver context er sin egen virtuelle firewall med seperate sikkerhedspolitikker og fungerer som havde det været adskilt i fysisk seperate enheder. En ting man dog skal være opmærksom på er at når en asa er i firewall multimode understøttes følgende features ikke:
*VPN
*Dynamisk routings protocol
*QoS
*Multicast routing
 
I vores foreslåede setup vil de forskellige context dele den offenlige ip addresse via et shared interface og nat tabellen bruges til classifier ind og på udgåede traffik klafficeres der på interfacet.<ref>http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/contexts.html#wp1133984</ref>
[[Image:FW_context_out.png|300px|left|thumb]][[Image:FW_context_in.png|300px|center|thumb]]
 

<pre><output omitted>
hostname(config-if)# interface gigabitethernet 0/1.1
hostname(config-subif)# vlan 101
hostname(config-subif)# context MedNet
hostname(config-ctx)# allocate-interface gigabitethernet 0/1.1
hostname(config-ctx)# allocate-interface gigabitethernet 1/1
hostname(config-if)# interface gigabitethernet 0/1.2
hostname(config-subif)# vlan 102
hostname(config-subif)# context StudNet
hostname(config-ctx)# allocate-interface gigabitethernet 0/1.2
hostname(config-ctx)# allocate-interface gigabitethernet 1/1
<output omitted>
</pre>
For at sikre os mod at brugerne i en context ikke tager alle firewallens ressourcer(cpu,ram) ved et overdrevet antal nat translations og samtidinge forbindelser tildeles hver context en procentdel af enhedens totale ressourcer. Det er dog ikke alle ressourcer hvor det kan lade sig gøre såsom antal hosts og application inspections.<ref>http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/mngcntxt.html</ref> Bemærk at tallene i følgende eksempel måske ikke er retvisende da det vil kræve en større indsigt i den pågældende virksomheds traffik mønster.

<pre>
hostname(config)# class MedNet
hostname(config-class)# limit-resource conns 40%
hostname(config-class)# limit-resource hosts 3000

hostname(config)# class AdmNet
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 2000

hostname(config)# class PaNet
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 2000

hostname(config)# class Default
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 9000
</pre>
 

==Referenceliste==
<references/>

[[Category:CCDP]]