Teknologisk videncenter - User contributions [en]

Performance test af Cisco udstyr

2009-10-15T14:03:20Z

Fatman: /* Baseline test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
===Iperf===
TCP server: <pre>iperf -s</pre>
TCP client: <pre>iperf -c <ip> -t 60 -i 5</pre>
UDP server: <pre>iperf -s -u</pre>
UDP client: <pre>iperf -c <ip> -u -t 60 -i 5 -b 1G</pre>

----
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre M55 8808-CTO
*Intel® Core 2 Duo Processor E6400
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler
==Udstyrstest==
===3560===
===2821===

Performance test af Cisco udstyr

2009-10-15T14:01:43Z

Fatman: /* Iperf */

Performance test af Cisco udstyr

2009-10-15T14:01:12Z

Fatman: /* Iperf */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
===Iperf===
TCP server: <pre>iperf -s</pre>
TCP client: <pre>iperf -c <ip> -t 60 -i 5</pre>
UDP server: <pre>iperf -s -u</pre>
UDP client: <pre>iperf -c <ip> -u -t 60 -i 5</pre>

----
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre M55 8808-CTO
*Intel® Core 2 Duo Processor E6400
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T14:01:01Z

Fatman: /* Iperf */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
===Iperf===
TCP server:
<pre>iperf -s</pre>
TCP client: <pre>iperf -c <ip> -t 60 -i 5</pre>
UDP server: <pre>iperf -s -u</pre>
UDP client: <pre>iperf -c <ip> -u -t 60 -i 5</pre>

----
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre M55 8808-CTO
*Intel® Core 2 Duo Processor E6400
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T14:00:22Z

Fatman: /* Iperf */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
===Iperf===
TCP server:
<pre>iperf -s</pre>
TCP client: iperf -c <ip> -t 60 -i 5 
UDP server: iperf -s -u 
UDP client: iperf -c <ip> -u -t 60 -i 5 

----
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre M55 8808-CTO
*Intel® Core 2 Duo Processor E6400
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T13:59:44Z

Fatman: /* Test beskrivelse */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
===Iperf===
TCP server: iperf -s 
TCP client: iperf -c <ip> -t 60 -i 5 
UDP server: iperf -s -u 
UDP client: iperf -c <ip> -u -t 60 -i 5 

----
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre M55 8808-CTO
*Intel® Core 2 Duo Processor E6400
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T13:57:48Z

Fatman: /* Baseline test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre M55 8808-CTO
*Intel® Core 2 Duo Processor E6400
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T13:55:26Z

Fatman: /* Baseline test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre M55 8808-CTO
*Intel® Core 2 Duo Processor E6400
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

----

Performance test af Cisco udstyr

2009-10-15T13:49:44Z

Fatman: /* Baseline test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre M55 8808-CTO
*Intel® Core 2 Duo Processor E6400
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T13:40:09Z

Fatman: /* Baseline test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre M55 8808-CTO
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T13:39:29Z

Fatman: /* Baseline test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCentre maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCentre 8808-CTO
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T13:37:30Z

Fatman:

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
 
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
 
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCenter maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCenter
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Netband Project - Windows server

2009-10-15T13:36:41Z

Fatman: /* NTP Client */

=Windows 2003 Server=
This page is part of the [[Netband_Project|Netband Project]]
__TOC__

==DHCP==

*Install DHCP from add/remove programs > Windows components > Network Services > Dynamic Host Configuration Protocol(DHCP)

*Right click on the server in DHCP management and select new scope.

*Follow the wizard and configure the scope according to specifications

[[Image:DHCP1.png|thumb|none|400px|DHCP Scope name]]
[[Image:DHCP2.png|thumb|none|400px|DHCP Scope Addresses and subnetmask]]
[[Image:DHCP3.png|thumb|none|400px|DHCP Scope Lease duration]]

*Click yes when it asks to configure Scope options
[[Image:DHCP4.png|thumb|none|400px|DHCP Scope Default Gateway]]
[[Image:DHCP5.png|thumb|none|400px|DHCP Scope Client Domain and DNS server]]

*Skip WINS server options
* Activate the scope now or later
[[Image:DHCP6.png|thumb|none|400px|DHCP Scope Activation]]

The Scope is now active and working for the Phone LAN.

==Active Domain==

*On the first server run a dcpromo and create a new domain(New tree in a new forrest)
*Create a domain admin account for the domain, this will be used to create users and add computers and new controllers to the domain.
*When the domain is up and running do a dcpromo on the second controller and add it to the domain with the new AD account

===Sites and Services===

The Sites and services in an AD is used to control userloggons. If you have multiple sites it is important that users always logon to the closest DC. No need to loggon over the WAN.

*In the Active Directory Site and Services create the subnets for each site
*Create a site for the HQ and the different Braches.
[[Image:ADSites1.png|thumb|none|700px|AD Sites and Services Create new site]]
*Drag the newly created domain controller into the new site, and set up bindings between the subnets and the sites.
*Make sure there is a IP site link across the to sites.

It should look something like this.
[[Image:ADSites2.png|thumb|none|700px|AD Sites and Services]]

==DFS==
Before DFS one server share some folders and another server shared other folders. To finde de right share you would need to look on different servers and sometimes the files you needed were on a remote location. DFS solves all the diffuculties in senarios like this. Both on the administrator side and on the user side. 
DFS is used to create a namespace where all the shares on different server is mounted into. All the shares will now look like its on the same server from the user perspective. 
With DFS Replication it is also possible to merge 2 folders on 2 servers to one, so every file creation, deletion, or change will be replicated to the other servers in the replication group. Users on the different locations will always access the files on the server nearest to them. This means that files will exist in all locations.

In this project we used:
*2 locations
*2 servers
*1 shared folder on each server(only local)
*1 shared folder on each server(replicated between the locations)
===DFS Root===
First we need to create a root server for the DFS. With a root folder on the server, this i just a pseudo folder with all the links to the other shares/servers. In this example D:\DFS will be used. And the DFS name will be \\domain.netband.dk\DFS.
[[Image:DFS3.png|thumb|none|700px|DFS name]]
[[Image:DFS4.png|thumb|none|700px|Root server]]
[[Image:DFS5.png|thumb|none|700px|Root Folder]]
=== DFS Folder Replication===
On the first server a new folder called D:\ReplicaFolder has to be created and shared also a folder called D:\LocalHQFolder should be created and shared.
 
On the second server the same two folders should be created but rename the second folder to LocalB1Folder(B1 for brach 1)
{|
|[[Image:DFS1.png|thumb|none|400px|D: Drive on HQ server]]
|[[Image:DFS2.png|thumb|none|400px|D: Drive on Branch server]]
|}
 
On the new DFS Root reight click and make a new link, name it ReplicaFolder and point it to the shared ReplicaFolder on server 1. Now click on the new link and click new target. Add the ReplicaFolder on the second server and follow the replication wizard.
[[Image:DFS6.png|thumb|none|700px|ReplicaFolder]]
Remember to change the sie of the staging area to allow files greater than 675840KB. The staging area is the replication cache and will be used to hold new files until they are replicated.
[[Image:DFS8.png|thumb|none|700px|Stage area size in KB]]

===Local site shares===
Now create a link for each of the shared folders on the servers, the local folder. LocalHQFolder and LocalB1Folder
 
Now in \\domain.netband.dk\DFS there is 3 folder. ReplicaFolder, LocalHQFolder and LocalB1Folder.
*ReplicaFolder is on both the servers and you will allways access the one closests, Both folders will contain the same files also
*LocalHQFolder is located in the Headquarter and only exists on 1 server.
*LocalB1Folder is located in the Brache and only exists on 1 server.
[[Image:DFS7.png|thumb|none|700px|The Final namespace]]
The replication part is greate on remote locations, because all data located in the HQ is up-to-date and you only need to back it up one place.

===DFS Links===
Introduction to DFS: 
http://www.microsoft.com/windowsserver2003/docs/dfs.swf 
http://www.microsoft.com/windowsserver2003/technologies/storage/dfs/default.mspx 
http://technet.microsoft.com/en-us/library/cc787066.aspx 

==NTP Client==
http://support.microsoft.com/kb/314054
[[Category:network]][[category:students]][[Category:Windows 2003]][[Category:Windows]]

Netband Project - Zone based Firewall(ZFW)

2009-10-15T13:25:02Z

Fatman: /* Security zones */

=Zone based Firewall(ZFW)=
This page is part of the [[Netband_Project|Netband Project]] 
__NOTOC__
==Branch router with DMZ==
In this example the configuration will what you would expect from a branch office with an inside, outside and a DMZ interface for local servers.
ZFW is not like IOS firewalling with ip inspect, the inspect firewall is a per interface rule firewall where ZFW is a direction firewall with one-to-one, one-to-many or many-to-many.
===Vlans===
Creating vlans to make the vlan interfaces on
<pre>vlan 2
name INSIDE
vlan 3
name OUTSIDE
vlan 4
name DMZ
</pre>
===Security zones===
Declaring Zones which will be mapped to the interfaces
<pre>zone security INSIDE-ZONE
zone security OUTSIDE-ZONE
zone security DMZ-ZONE
</pre>

===Vlan interfaces===
Creating vlan interfaces for the different zones
<pre>interface vlan 2
description Inside interface
ip address 10.0.0.1 255.255.255.0
zone-member security INSIDE-ZONE
!
interface vlan 3
description Outside interface
ip address 80.225.34.13 255.255.255.0
zone-member security OUTSIDE-ZONE
!
interface vlan 4
description DMZ interface
zone-member security DMZ-ZONE
</pre>
===Customizing your matches===
If you need a custom tcp port to be allowed to pass through the zones
<pre>ip port-map user-streaming port tcp 8000 description Custom Video Streaming port
</pre>
Create a parameter map of regular expressions your http requests will be matched against
<pre>parameter-map type regex URLS-PARAMAP
pattern ..*cmd.exe.
pattern ..*sex.
pattern ..*gambling.
</pre>

===Class-maps===
This will specify what traffic the class-maps will match on.
<pre>class-map type inspect match-any INSIDE-OUTSIDE-CMAP
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any INSIDE-DMZ-CMAP
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any OUTSIDE-DMZ-CMAP
match protocol http
match protocol https
match protocol user-streaming
!
class-map type inspect http match-all URLS-CMAP
match request uri regex URLS-PARAMAP
</pre>
===Policy-maps===
This will make a policy-map witch will descripe what actions to take on the trafik that matches our class-maps
<pre>policy-map type inspect http URLS-PMAP
class type inspect http URLS-CMAP
reset
class class-default
!
policy-map type inspect OUTSIDE-DMZ-PMAP
class type inspect OUTSIDE-DMZ-CMAP
inspect
class class-default
drop
!
policy-map type inspect INSIDE-OUTSIDE-PMAP
class type inspect INSIDE-OUTSIDE-CMAP
inspect
service-policy http URLS-PMAP
class class-default
drop
!
policy-map type inspect INSIDE-DMZ-PMAP
class type inspect INSIDE-DMZ-CMAP
inspect
class class-default
drop
</pre>
===Zone-pairs===
And the we need to map zones together in zone-pairs with a traffic direction and connect the policy-maps to them
<pre>zone-pair security INSIDE-OUTSIDE-ZONEP source INSIDE-ZONE destination OUTSIDE-ZONE
service-policy type inspect INSIDE-OUTSIDE-PMAP
!
zone-pair security INSIDE-DMZ-ZONEP source INSIDE-ZONE destination DMZ-ZONE
service-policy type inspect INSIDE-DMZ-PMAP
!
zone-pair security OUTSIDE-DMZ-ZONEP source OUTSIDE-ZONE destination DMZ-ZONE
service-policy type inspect OUTSIDE-DMZ-PMAP
</pre>

==Nifty Features==
All this zone-based firewalling is not only a layer3 thing. 
Try creating a bridging interface and make it your Layer3 link and assign two vlan to that bridge group. Now it is possible to place 2 servers in different vlans, but in the same layer 2 subnet and still have a firewall between them. 
Now you have a Layer 2 firewall:-)

==External links==
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00808bc994.shtml
 
http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_zone_polcy_firew.html
[[Category:network]][[Category:CCNP]][[category:students]][[category:CCNP4]]

Netband Project - Device hardening

2009-10-15T13:20:32Z

Fatman:

=Device hardening=
This page is part of the [[Netband_Project|Netband Project]] 

==Exclusive Configuration Change Access==
*ensures that only one administrator makes configuration changes to a Cisco IOS device at a given time.
<pre>B1rt1(config)#configuration mode exclusive auto
!
B1rt1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
B1rt1(config)#
Apr 16 13:02:58.746: Configuration mode locked exclusively. The lock will be cleared once you exit out of configuration mode using end/exit
</pre>
<pre>B1rt1(config)#interface fa0/0
Configuration mode locked exclusively by user 'admin' process '56' from terminal '195'. Please try later.
</pre>
For more information see: [http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_exclu.html Exclusive Configuration Change Access]

==Cisco IOS Software Resilient Configuration==
*stores a copy of the Cisco IOS software image and device configuration that is currently being used by a Cisco IOS device.
*Can only be disabled through console access
<pre>secure boot-image
secure boot-config
</pre>
<pre>B1rt1#sh secure bootset
IOS resilience router id FCZ111910E5

IOS image resilience version 12.4 activated at 11:05:51 UTC Thu Apr 16 2009
Secure archive flash:c2801-advipservicesk9-mz.124-9.T.bin type is image (elf) []
file size is 30588892 bytes, run size is 30754576 bytes
Runnable image, entry point 0x8000F000, run from ram

IOS configuration resilience version 12.4 activated at 11:06:11 UTC Thu Apr 16 2009
Secure archive flash:.runcfg-20090416-110611.ar type is config
configuration archive size 4555 bytes
</pre>
<pre>B1rt1(config)#no secure boot-config
%You must be logged on the console to apply this command
</pre>
<pre>B1rt1(config)#secure boot-config restore flash:rescueconf
ios resilience:configuration successfully restored as flash:rescueconf
</pre>
For more information see: [http://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gtrescfg.html Cisco IOS Resilient Configuration]

==Reserve Memory for Console Access==
*used in order to reserve enough memory to ensure console access to a Cisco IOS device
<pre>memory reserve console 4096
</pre>
For more information see: [http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ftresmem.html Reserve Memory for Console Access]

==Memory Leak Detector==
*used in order to check the memory structures of a device and acquire the latest crash information to determine what processes corrupt the chunks.
<pre>
scheduler heapcheck process memory
</pre>
For more information see: [http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtmleakd.html Memory Leak Detector]

==Buffer Overflow: Detection and Correction of Redzone Corruption==
*A memory block overflow problem is detected in the Cisco IOS software when the value of an area in the memory block called the "redzone" is checked
*When a memory block overflow problem is detected in packet memory, software will change the memory block header data back to its correct value.
<pre>exception memory ignore overflow io
exception memory ignore overflow processor
</pre>
<pre>
show memory overflow
</pre>
For more information see: [http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtbufflo.html Buffer Overflow: Detection and Correction of Redzone Corruption]

==EXEC Timeout==
*logs out sessions on vty or tty lines that are left idle.
*Default is 10 minutes
<pre>
line con 0
exec-timeout 5
line vty 0 4
exec-timeout 5
</pre>
*on some older IOS versions the default is, no timeout
*when all lines are occupied, no one can log in until the device is restarted or the sessions are cleared through the console
<pre>B1rt1#sh users
Line User Host(s) Idle Location
* vty 194 admin idle 00:00:00 10.1.2.50
vty 195 admin2 idle 00:00:03 10.1.2.50

B1rt1#clear line 195
[confirm]
[OK]
B1rt1#
</pre>

==Disable Unused Services==

<pre>no ip finger
ip dhcp bootp ignore
no service pad
no ip http server
no service config

On versions prior to 12.0, also do:
no service udp-small-servers
no service tcp-small-servers
</pre>
==No Service Password-Recovery==
*Disables password recovery through ROMMON
*The router can be reset to factory default configuration, but the stored configuration is lost
<pre>no service password-recovery
</pre>
For more information see: [http://www.cisco.com/en/US/docs/ios/12_3/12_3y/12_3ya8/gtnsvpwd.html#wp1056707 No Service Password-Recovery]
==Password Management==
*Uses Message Digest 5 (MD5) for password hashing
<pre>enable secret cisco
</pre>
*prevents casual observers from reading passwords
*weak password encryption
<pre>
service password-encryption
</pre>

==Login Password Retry Lockout==
*locks an user account after a configured number of failed attempts
*must be manually unlocked again
*A user with privilege level 15 cannot be locked out
<pre>
aaa new-model
aaa local authentication attempts max-fail 3
aaa authentication login default local
!
username admin2 privilege 14 secret cisco
</pre>
<pre>Apr 16 12:36:41.257: %AAA-5-USER_LOCKED: User admin2 locked out on authentication failure

B1rt1#clear aaa local user lockout username admin2

Apr 16 12:39:57.474: %AAA-5-USER_UNLOCKED: User admin2 unlocked by admin on vty0 (192.168.0.11)
</pre>
For more information see: [http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/g_cilprl.html Login Password Retry Lockout]

==Cisco IOS Login Enhancements==
*adds a delay between successive logins
*login shutdown(quiet mode) for a specified period of time
*Allows for speficied hosts or subnets to login in during quiet mode
<pre>login block-for 120 attempts 2 within 30
login delay 2
login on-failure log
login quiet-mode access-class 2
access-list 2 permit 10.0.0.0 0.255.255.255
</pre>

<pre>Apr 16 15:30:29.249: %SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 0 secs, [user: ] [Source: 192.168.3.12] [localport: 22] [Reason: Login Authentication Failed] [ACL: sl_def_acl] at 15:30:29 UTC Thu Apr 16 2009

Note: The sl_def_acl is created by the system and cannot be removed or modified
Extended IP access list sl_def_acl
10 deny tcp any any eq telnet log
20 deny tcp any any eq www log
30 deny tcp any any eq 22 log
40 permit tcp any any eq 22 log

Apr 16 15:32:29.252: %SEC_LOGIN-5-QUIET_MODE_OFF: Quiet Mode is OFF, because block period timed out at 15:32:29 UTC Thu Apr 16 2009
</pre>
<pre>B1rt1#sh login failures
Total failed logins: 7
Detailed information about last 50 failures

Username SourceIPAddr lPort Count TimeStamp
10.248.10.98 22 2 07:30:17 UTC Sun Dec 14 2008
10.1.0.53 22 1 21:27:15 UTC Mon Dec 22 2008
192.168.3.10 22 2 15:02:23 UTC Thu Jan 8 2009
192.168.3.12 22 2 15:30:17 UTC Thu Apr 16 2009
</pre>
<pre>B1rt1#sh login
A login delay of 2 seconds is applied.
Quiet-Mode access list 2 is applied.

Router enabled to watch for login Attacks.
If more than 2 login failures occur in 30 seconds or less,
logins will be disabled for 120 seconds.

Router presently in Normal-Mode.
Current Watch Window
Time remaining: 8 seconds.
Login failures for current window: 0.
Total login failures: 7.
</pre>

==Encrypting Management Sessions==
*use SSH instead of telnet
*use HTTPS instead of HTTP
<pre>
ip domain-name netband.dk
!
B1rt1(config)#crypto key generate rsa
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]:2048
% Generating 2048 bit RSA keys, keys will be non-exportable...[OK]

B1rt1(config)#
Apr 16 12:50:47.916: %SSH-5-ENABLED: SSH 2.0 has been enabled

B1rt1(config)#ip ssh time-out 60
B1rt1(config)#ip ssh authentication-retries 3

B1rt1#sh ip ssh
SSH Enabled - version 2.0
Authentication timeout: 60 secs; Authentication retries: 3
</pre>

<pre>B1rt1(config)#no ip http server
B1rt1(config)#ip http secure-server
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
</pre>

== Control vty and tty Lines ==

*Disable unwanted access methods to and from the virtual lines
*Use access-lists to control access to the virtual lines
<pre>line vty 0 4
transport input ssh
transport output ssh
access-class 2 in
line vty 5
transport input ssh
transport output ssh
access-class 2 in
!
access-list 2 permit 10.0.0.0 0.255.255.255
</pre>

==Mangement Plane Protection==
*restricts management to one or more logical or physical interfaces
*Can be used as an alternative to vty access-list and interface access-lists
*Works with ftp, http, https, ssh, telnet, tftp and snmp
<pre>control-plane host
management-interface FastEthernet0/0 allow ssh

Apr 16 20:04:32.067: %CP-5-FEATURE: Management-Interface feature enabled on Control plane host path
</pre>
<pre>B1rt1# show management-interface
Management interface FastEthernet0/0
Protocol Packets processed
ssh 223981
</pre>
For more information see: [http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htsecmpp.html#wp1049489 Management Plane Protection]

==External links==
[http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml Cisco Guide to Harden Cisco IOS Devices]
[[Category:network]][[Category:CCNP]][[category:students]][[Category:CCNP4]]

Performance test af Cisco udstyr

2009-10-15T13:15:03Z

Fatman: /* Performance test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
Sådan kommer udstyret til at blive koblet
[[Image:Setup.png]]
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==
[[Image:Baseline.png]]
For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCenter maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCenter
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

File:Setup.png

2009-10-15T13:13:35Z

Fatman: Setup diagram for performance test

Setup diagram for performance test

File:Baseline.png

2009-10-15T13:13:04Z

Fatman: Baseline setup for performance test

Baseline setup for performance test

Performance test af Cisco udstyr

2009-10-15T11:23:53Z

Fatman: /* Baseline test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==

For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCenter maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCenter
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 Server 64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T11:23:02Z

Fatman: /* Performance test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da Cisco's egne test ikke altid giver et konkret svar, vil jeg prøve det af og skrive lidt om det her.
 
 
Er du selv i besidelse af noget udstyr skal du være velkommen til at teste det og poste resultatet her.
==Test beskrivelse==
Testen går ud på at se hvor meget netværks trafik der kan trækkes igennem ustyret, derfor vil disse tests blive udført:
*TCP session i en retning
*TCP session i den anden retning
*TCP session i begge retninger på samme tid
*UDP session i en retning
*UDP session i den anden retning
*UDP session i begge retninger

Til disse tests vil iperf blive brugt. 
Hvis nogle kender et bedre program, der evt. også kan teste no. new connection per second, vil jeg meget gerne høre fra jer.

==Baseline test==

For at lave en baseline på hvad test udstyret kan klare har jeg sat 2 Lenovo ThinkCenter maskiner op mod hinanden og kørt testene på dem.
 
*Lenovo ThinkCenter
*1GB Ram
*Gigabit onboard netkort
*Ubuntu Jaunty 9.04 AMD64bit
*Cat 5e UTP kabler

Performance test af Cisco udstyr

2009-10-15T10:46:21Z

Fatman: /* Performace test */

=Performance test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da ciscos egne test ikke altid
==Test beskrivelse==

==Baseline test==

Performance test af Cisco udstyr

2009-10-15T09:34:43Z

Fatman: New page: =Performace test= Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da ciscos egne test ikke altid ==Test beskrivelse== ==Baseline test==

=Performace test=

Man bliver ofte mødt med spørgsmål om hvor meget cisco udstyr egentlig kan trække, og da ciscos egne test ikke altid
==Test beskrivelse==

==Baseline test==

IPsec and SSL VPN Design

2009-08-19T10:30:29Z

Fatman: /* DMVPN */

Kapitel 9 fra [[CCDP|CCDP ARCH]] bogen.
{{In progress}}
__TOC__

= IPsec VPN =
Behandlet i [http://mars.tekkom.dk/cisco/ccnp2/ch3/main.html CCNP 3 ISCW] omhandlende
*Site-to-Site IPsec VPN
*Cisco VPN Client
= SSL VPN =
[[Image:SSL1.png|300px|right|thumb|Problemer med certifikatet]]
SSL - Secure Socket Layer - er en teknologi udviklet af Netscape for at kryptere kommunikationen mellem en WEB-browser og en WEB-Server. SSL anvender asymetriske nøgler.
#En klient ønsker at sende fortrolige data til WEB-serveren.
#Browseren henter serverens sikkerheds-certifikat som indeholder den offentlige nøgle
#Browseren checker om certifikatet er udstedt af en CA (Certificate authority) som der stoles på og checker certifikatet.
== Tynd SSL Client ==
Giver adgang gennem en Client program på PC'en som port-forwarder det usikre program
Det usikre programs data Port-forwarders internt på PC'en gennem den tynde-klient som krypterer dataene og sender dem krypteret videre til VPN-appliance i den anden ende som dekrypterer og afleverer dataene til Serveren.
{|
|[[Image:SSL2.png|400px|thumb|left|Thin Client (Port forwarding)]]
|}
== Tyk klient ==
Den tykke klient laver et virtuelt netkort som al kommunikation kan gå igennem.
{|
|[[Image:SSL3.png|400px|thumb|left|Thick Client (Port forwarding)]]
|}

= VPN Arkitektur =
I eksemplet nedenfor er der VPN adgang for både ansatte og forretnings partnere. De ansatte benytter sig af IPsec og forretnings partnerne benytter sig af SSL. Alle opkoblinger - både IPsec og SSl - Authenticates på AAA serveren.
{|
|[[Image:SSL4.png|600px|thumb|left|Eksempel på VPN arkitektur]]
|}
= Site-to-Site VPN's =
Site-to-Site VPN kan anvendes mellem en virsomheds filialer i stedet for andre WAN-services (MPLS) for at reducere omkostningerne, eller kan anvendes som Redundans hvis den primære WAN går ned.
== Cisco Router performance ==
{|
|[[Image:VPN1.png|700px|left|thumb|Cisco Router performance med IPsec VPN's]]
|-
|[[Image:VPN2.png|700px|left|thumb|Cisco Router performance]]
|}
== Cisco ASA 5500 serie performance ==
{|
|[[Image:VPN3.png|700px|left|thumb|Cisco ASA 500 serie performance]]
|}
== Typiske VPN løsninger ==
{|border=1 ;style="margin: 0 auto; text-align: center;cellpadding="5" cellspacing="0"
|+ Typiske VPN løsninger
|- bgcolor=lightgrey
! Anvendelse !! model
|-
| Teleworkers || Cisco 850 og 870
|-
| Small Office/Home Office (SOHO) || Cisco 850, 870 or ASA 5505
|-
| Small branch || Cisco 1800 or ASA 5510
|-
| Medium branch || Cisco 2800 or ASA 5520
|-
| Enterprise branch || Cisco 3800 or ASA 5540 / 5550
|-
| Enterprise Edge || Cisco 7200 and 7301
|-
| Enterprise headquarters or Data Center ||| Catalyst 6500, Cisco 7600 or ASA 5550
|}
= VPN device placement design =
== Parallel to firewall ==
*Fordele
**Simpel implementering da firewall opsætning ikke skal ændres
**Stor skalerbarhed da flere VPN enheder kan placeres parallelt med Firewallen
*Ulemper
**IPsec dekrypteret trafik inspiceres ikke af firewallen
**Inget central logning eller inspektion af data/brugere finder sted.
{|
|[[Image:VPN4.png|600px|left|thumb|VPN device placement: Parallel to firewall]]
|}
== På firewall DMZ zone ==
*Fordele
**Firewallen kan inspicere dekrypterede data.
**Forholdsvis god skalabilitet da der kan tilsluttes flere VPN enheder
*Ulemper
**Konfigurationen bliver kompliceret da Firewallen skal supportere flere interfaces. Firewallen skal supportere Policy-Routing for at kende forskel på VPN-trafik og almindelig trafik.
**Firewallens kapacitet.
{|
|[[Image:VPN5.png|600px|left|thumb|VPN device placement: DMZ-zone on firewall]]
|}
== Integreret Firewall og VPN ==
*Fordele
**Firewallen kan inspicere dekrypteret trafik
**Designet er nemmere at vedligeholde og der er mindre antal enheder
*Ulemper
**Manglende skalerbarhed da en enkelt enhed har flere ansvar.
**Kompleks konfiguration da der er samlet flere funktioner i enheden.
{|
|[[Image:VPN6.png|600px|left|thumb|VPN device placement: DMZ-zone on firewall]]
|}
= IPsec VPN teknologier =
*Cisco Easy VPN
*GRE tunneling
*Dynamic multipoint VPN (DMVPN)
*Virtual Tunnel Interfaces (VTIs)
*Group Encrypted Transport VPN (GET VPN)
== Easy VPN ==
Til fjernopkoblede medarbejdere og kontorer.
=== Easy VPN server Wizard på Cisco SDM ===
{|
|[[Image:VPN7.png|700px|left|thumb|Easy VPN Server Wizard på SDM]]
|-
|[[Image:VPN8.png|700px|left|thumb|Easy VPN Remote Wizard på SDM]]
|}
== GRE over IPsec ==
IPsec kan kun transportere IP unicast trafik, og er derfor ikke velegnet som VPN mellem sites hvor der for eksempel skal udveksles trafik mellem Routnings protokoller.
{|
|[[Image:VPN9.png|900px|left|thumb|GRE over IPsec tunnel]]
|}
=== Anbefalinger ===
*Op til 500 peers for Cisco 7200VXR routere med Network Engine G1 (NPE-G1)
*Op til 600 peers for Cisco 7200VXR routere med Network Engine G2 (NPE-G2)
*Op til 1000 peers for Cisco 7600 Routere og Catalyst 6500 serie switche med Supervisor Engine 720
{|
|[[Image:VPN10.png|700px|left|thumb|GRE over IPsec]]
|}

== DMVPN ==
Normal Hub and Spoke konfiguration skalerer ikke så godt hvis der er mere end 10 sites. Al trafik mellem Spokes skal igennem Hubben. DMVPN kan lave dynamiske tunneller mellem Spokes når der er brug for det. DMVPN er en kombination mellem IPsec, GRE og Next Hop Resolution Protocol (NHRP)
*Fordele
**Antallet af tunneller er meget mindre end et fuldt MESH, som skalerer dårligt.
**Hvis der tilføjes en ny Spoke skal de andre Spokes ikke omkonfigureres. Sker dynamisk fra Hubben.
{|
|[[Image:VPN11.png|700px|left|thumb|Eksempel på DMVPN topologi]]
|}
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008075ea98.pdf

== Virtual Tunnel Interface ==
*[http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629_ps6635_Products_White_Paper.html Cisco Configuring a Virtual Tunnel Interface with IP Security]
*[http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/V3PNIPmc.html Cisco Multicast over IPSec VPN Design Guide]
== Group Encrypted Transport VPN ==
Er en krypteret facilitet der ude tunneller tilbyder End-to-End sikkerhed for Voice, Video og data i Native mode til et Full-Meshed netværk i et privat WAN. Det benytter sig af det private WAN's muligheder for at replikere trafikken (Multicast). Anvendes for eksempel i forbindelse med [[MPLS]]. Anvender en Key-Server hvortil Group-members tilslutter sig. To Group-members kan udveksle krypteret trafik imellem hinanden. hvis der tilsluttes flere group-members er det kun Key-server og den nye Group-member der skal konfigureres.
{|
|[[Image:VPN12.png|700px|left|thumb|GET VPN topologi]]
|}
= Anbefalinger for managing VPN's =
*SDM - Security Device Management GUI (Routere fx. Cisco 2800)
*ASDM - ASA SDM
*
= Scaling VPN's =
{|border=1 ;style="margin: 0 auto; text-align: center;cellpadding="5" cellspacing="0"
|+ Enterprise WAN kategorier
|- bgcolor=lightgrey
! Funktion !! Point-of-sale !! Teleworker !! Integrated services Branch
|-
| Number of branches || Extra Large 1.000 - 10.000 || Large 1.000 - 3.000 || Medium 500 - 1.000
|-
| VoIP support || No || Yes, usually one call || Yes - up to 33% bandwidth
|-
| Multicast || generally not || Nice to have || Yes
|-
|Avilability ||required Asynchronous Dialbackup || To costly, Dial bandwidth insufficient for VoIP || Multiple WAN links
|-
| Physical interface || Broadband or POTS || Broadband|| Leased line
|}
== QoS Traffic profiles ==
{|
|[[Image:VPN13.png|600px|left|thumb|QoS traffic profiles for branch Router]]
|-
|[[Image:VPN14.png|800px|left|thumb|Enterprise mixed packet size]]
|-
|[[Image:VPN15.png|800px|left|thumb|Enterprise PPS based on branch profile]]
|-
|[[Image:VPN16.png|800px|left|thumb|Eksempel: NetFlow Analyzer 5 Packet and application view]]
|}

For en dybere forklaring se [http://en.wikipedia.org/wiki/Transport_Layer_Security Wikipedia] eller RFC 5246
[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-13T12:47:00Z

Fatman: /* 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. Grunden til man deler den op skal bl.a. findes i sikkerhed, hvis man havde en stor DMZ ville man kunne bruge en kompromiteret server som springbræt til alle de andre servere. Med opdelingen ville man kun tilgå servere i samme gruppe, og da de forskellige grupper ikke ville have noget at snakke sammen om, bliver der nok en stor fed deny any any imellem dem.
{|
|[[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-12T13:12:22Z

Fatman: /* 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>

==Alternativer==

==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. 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.

=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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 udgåede 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 såsom antal nat translations og samtidinge forbindelser. Det anbefales at man sætter ressourcerne som 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 reetvisende 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-12T13:12:09Z

Fatman: /* 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>

==Alternativer==
RFC 1918

==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. 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.

=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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 udgåede 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 såsom antal nat translations og samtidinge forbindelser. Det anbefales at man sætter ressourcerne som 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 reetvisende 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-12T13:07:31Z

Fatman: /* Internet */

{{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>

==Alternativer==
==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. 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.

=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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 udgåede 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 såsom antal nat translations og samtidinge forbindelser. Det anbefales at man sætter ressourcerne som 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 reetvisende 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-12T13:06:54Z

Fatman: /* IDS */

{{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 s_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>

==Alternativer==
==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. 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.

=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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 udgåede 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 såsom antal nat translations og samtidinge forbindelser. Det anbefales at man sætter ressourcerne som 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 reetvisende 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-12T09:57:39Z

Fatman: /* Filtrering af trafik */

{{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 s_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>

==Alternativer==
==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. 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.

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 udgåede 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-ctx)# context MedNet
hostname(config-ctx)# allocate-interface gigabitethernet0/1 int1
hostname(config-ctx)# allocate-interface gigabitethernet0/0.102 int2
<output omitted>
</pre>
For at sikre os mod at brugerne i en context ikke tager alle firewallens ressourcer såsom antal nat translations og samtidinge forbindelser. Det anbefales at man sætter ressourcerne som 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 reetvisende 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-12T08:17:04Z

Fatman:

{{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 s_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 en 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>

==Alternativer==
==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. 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.

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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
 
For at sikre os mod at brugerne i en context ikke tager alle firewallens ressourcer såsom antal nat translations og samtidinge forbindelser. Det anbefales at man sætter ressourcerne som 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>
[[Image:FW_context_out.png|300px|left|thumb]][[Image:FW_context_in.png|300px|center|thumb]]
<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-12T08:16:47Z

Fatman:

[[Opgave CCDP]]
{{In progress}}
[[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 s_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 en 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>

==Alternativer==
==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. 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.

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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
 
For at sikre os mod at brugerne i en context ikke tager alle firewallens ressourcer såsom antal nat translations og samtidinge forbindelser. Det anbefales at man sætter ressourcerne som 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>
[[Image:FW_context_out.png|300px|left|thumb]][[Image:FW_context_in.png|300px|center|thumb]]
<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 - Datacenter design

2009-08-12T08:15:35Z

Fatman:

=Generel opbygning=
I de fleste tilfælde, vil et datacenter i et large enterprise netværk bestå af et tree-tier design. Dette består af et access, aggregation- og core layer. I small eller medium enterprise datacenters vil man typpisk have et two-tier med lag 3 access forbundet til en collapsed core (core og aggregation layer).
Three-tier vs. Two-tier design afhænger af størrlsen af datacenteret eller antal hosts forbundet til access-laget. Et three-tier design er mere scallerbart til større netværk mens two-tier er ideelt til mindre netværk.
En udvidelse af datacenteret til tage udgangspunkt i aggregationlaget. Uden et datacenter corelag, vil en udvidelse medføre flere uplinkporte til campus core. Et three-tier design er derfor anbefalet.
Man opbygger et datacenter efter servernes funktion. Server med samme funktion eller på samme VLAN sidder ofte på samme switch-par i accesslaget. Med dette opnår vi så få VLAN som muligt i access-laget og hurtigere konvergeringstid i lag 2 delen af datacenteret.

=Three-tier design=
===Core===
High-speed packet switching ind og ud af datacenteret. Forbundet til campus core og datacenter aggregation laget. Der skal være en 1:1 mellem campus core og datacenter core.
===Aggregation===
Kan sammenlignes med distributionlaget i campus. Det er her vi foretager polici-based distribution. Aggregationlaget har følgende funktioner:

*Spanning-tree processing
*Redundant default gateway for lag 2
*Service module integration (dette kræver minimum en Catalyst 6500 series switch):
**Firewall
**Load balancing
**Content switching
**Secure sockets layer (SSL) offload
**Intrusion detection (IDS)
**Netværksanalyse

===Access===
Fysisk forbindelse for hosts/server/clusters i datacenteret.

Lag 2 vs. Lag 3 i accesslaget
Man opbygger accesslaget efter servernes funktion. Der er forskellige fordele ved brug af enten lag 2 eller 3:

*Lag 2:
**Mulighed for NIC teaming og lag 2 naboskab over et større område (ALB – Adaptive load balancing)
**Supportere High-availability clustering
**Udbrede VLAN udover accesslaget

*Lag 3:
**NIC teaming kan der benyttes SFT – Switch fault tolerance. Den ene port er aktiv mens den anden er i standby
**Bedre håndtering af loops
**Hurtigere konvergering af netværket
**Minimere broadcast-domains, som medfører større stabilitet

=Routing protokol=
Det anbefales at der benyttes OSPF eller EIGRP i lag 3 i datacenteret. Der skal være load-balancing mellem campus-core og core aggregation laget i DC ved at bruge Cisco Express Farwarding (CEF) (side 182 afsnit 3)
En option er at bruge layer 3 IP plus layer 4 port-based CEF load-balance. Dette giver en bedre fordeling idet det præsentere flere informationer til CEF-algoritmen. CLI-kommando: ”mls ip cef load full”
EIGRP har en hurtigere konvergeringstid end OSPF. (side 103)
(EIGRP/OSPF side 101 og 108)

==Huskenotes ved brug af OSPF (side 182)==
*Ved 10 Gigabit Ehternet sættes ”auto-cost reference-bandwidth 10000” . OSPF har en default reference på 100Mbit/s til en cost på 1
*Brug loopback interfaces til at definere router ID. Dette simplificere troubleshooting
*Brug ”passive-interface default” og brug ”no passive-interface” kun på de interfaces, som er med i routing-processen
*Brug OSPF authentication for at undgå udvedkommende.
*Tune OSPF timers med ”timers throttle spf” for at opnå sub-second konvergeringstid

==Huskenotes ved brug af EIGRP (side 184)==
*Lav en default summary route ind i DC-laget (retning mod aggregation laget) med ”ip summary-address eigrp”
*Summarize datacenter subnets i aggregation laget (retning mod DC core) med ”ip summary-address eigrp”
*Brug ”passive-interface default” og brug ”no passive-interface” kun på de interfaces, som er med i routing-processen

=Default-gateway=
==Huskenotes ved redundant default-gateway (side 186)==
*HSRP er den mest udbredte protokol i et enterprise datacenter.
*Cisco anbefaler ikke flere end 500 HSRP instanser pga. CPU ressourcer.
*1 sek. hello og 3 sek. Holdtime
==STP design (side 187)==
*RPVST+ anbefales i forhold til MST pga. hurtigere konvergeringstid.
*Root guard på aggregation porte med retning mod access laget.
*Loop guard på access porte med retning mod aggregation laget.
*Loop guard mellem aggregation switche.
*BPDU guard på access porte med retning mod hosts/servere.
*ULDL er globalt enabled,

=Løsning=
[[Image:CCDP_DatacenterDesign1.png|500px|right|thumb|Datacenter Design]]
Vi har designet et three-tier funktionsopbygget datacenter. Billedet ovenover er blot en logisk opbygningen af netværket. Vi har lavet de 3 grupperinger af serverne med WLC, CUCM og DATA.
Ud fra netværkets størrelse, har vi medtaget et corelag i tilfælde af udvidelse i aggregationslaget. Corelaget gør netværket mere skalerbart.
===Core===
Corelagets funktion er hurtig switching mellem aggregationlaget og campus core.
===Aggregation===
Aggregationlaget er modulopbygget og fungerer som policy-based distribution. Det anbefales at bruge en Catalyst 6500 series switch i aggregation laget.
På hver aggregation-switch er der behov for følgende moduler:
*2 stk. 48 ports switchmoduler
*Intrusion detection (IDS)
*Firewall
*Network analysis

IDS benyttes til at fange evt. uautoriseret data-/servertilgang. Firewall bruges til at kontrollere og filtrere tilgang mellem VLAN og servere. Etherchannels bundles på tværs af de 2 switchmoduler.
Mod corelaget er der etherchannels. Mod accesslaget er der 1 link pr. aggregation switch til 1 funktionsopdelt switchblok.

===Access===
Der er taget udgangpunkt i et Layer 2 Looped Square design, hvor der er lag 2 i accesslaget.
Denne model tillader aktiv/aktiv på servicemoduler i aggrationslaget. I aggrationslaget er der en HSRP-instans pr. VLAN, hvor VLANs fordeles lige over par af aggretionsswitche som HSRP aktive og standby.

==Spanning tree==
Der benyttes RPVST+ som spanning-tree protokol. Denne protokol anbefales af cisco til brug i et datacenter. Der vil kun være de VLANS ude i accesslaget, som der er behov for. Dette forbedrer konvergeringstiden i accesslaget.
I takt med den lige fordeling af aktive og standby HSRP-instanser pr. VLAN, skal RPVST+ være root primary og secondary på samme VLANs.
Der skal være et link mellem de 2 funktionsopdelte switche. Dette link bliver lukket af spanning-tree og tages i brug, hvis ét af uplinkene til aggregationlaget fejler.
==Routingsprotokol==
MANGLER

==IP-scheme (Datacenter = 10.128.0.0/10)==
Vi grupperer hver type af server i hver sin switchblock med hvert sit subnet (role-based addressing) (side 89 midt).

2. Octet er skabsnummer eller nummer på lag 3 switch.

3. Octet er VLAN-nr.

4. Octet er hosts. (side 90 for ”tommelfingerregel”)

===LAG3 switche===
*10.128.0.0 / 16 - DCcore1
*10.129.0.0 / 16 - DCcore1
*10.130.0.0 / 16 - DCagg1
*10.131.0.0 / 16 - DCagg2
*10.132.0.0 / 16 - CUCMswitch1
*10.133.0.0 / 16 - CUCMswitch2

===VLAN===
*10.130.10.0 / 24 - WLC
*10.130.20.0 / 24 - DATA1
*10.130.30.0 / 24 - ..
*10.130.40.0 / 24 - ..

*10.132.10.0 / 24 - VOICE

===Point-to-point===
*10.191.255.0 / 30 - DCcore1 --> Campus core1
*10.191.255.4 / 30 - DCcore1 --> Campus core2
*10.191.255.8 / 30 - DCcore1 --> DCagg1
*10.191.255.12 / 30 - DCcore1 --> DCagg2
*10.191.255.16 / 30 - DCcore2 --> Campus core1
*10.191.255.20 / 30 - DCcore2 --> Campus core2
*10.191.255.24 / 30 - DCcore2 --> DCagg1
*10.191.255.28 / 30 - DCcore2 --> DCagg2
*10.191.255.32 / 30 - DCagg1 --> CUCMswitch1
*10.191.255.36 / 30 - DCagg2 --> CUCMswitch2

Fordel for globale ACL og i edge (side 90 nederst)
 

=Uddrag fra konfigurationer=
==Etherchannel==
===Lag 3===
DCcore1# configure terminal

DCcore1(config)#interface port-channel 1

DCcore1(config-if)# ip address 10.191.255.1 255.255.255.252

DCcore1(config-if)# switchport trunk encap dot1q

DCcore1(config-if)# switchport mode trunk

DCcore1(config-if)# exit

DCcore1(config)# interface range gigabitethernet 0/1 - 2

DCcore1(config-if-range)# channel-group group 1 mode desirable

DCcore1(config-if-range)# no shutdown

DCcore1(config-if-range)# end

===Lag 2===
DCagg1# configure terminal

DCagg1(config)# interface range fastethernet 0/1 - 2

DCagg1(config-if)# channel-group group 1 mode desirable

DCagg1(config-if)# exit

DCagg1(config)#interface port-channel 1

DCagg1(config-if)# switchport mode trunk

DCagg1(config-if)# exit

===Load balance===
DCcore1(config)# port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip |src-dst-ip}

==HSRP==
Eksempel med VLAN 10 og 20. DCagg1 er den foretrukken default-gateway for VLAN 10 og DCagg2 er den foretrukken default-gateway for VLAN 20.

DCagg1# configure terminal

DCagg1(config)# interface Vlan 10

DCagg1(config-if)# description WLC

DCagg1(config-if)# ip address 10.130.10.1 255.255.255.0

DCagg1(config-if)# standby 10 ip 10.130.10.254

DCagg1(config-if)# standby 10 preempt

DCagg1(config-if)# standby 10 track GigabitEthernet <slot/port to DCcore1>

DCagg1(config-if)# standby 10 track GigabitEthernet <slot/port to DCcore2>

DCagg1(config-if)# end

DCagg1# configure terminal

DCagg1(config)# interface Vlan 20

DCagg1(config-if)# description DATA

DCagg1(config-if)# ip address 10.130.20.1 255.255.255.0

DCagg1(config-if)# standby 20 ip 10.130.20.254

DCagg1(config-if)# standby 20 track GigabitEthernet <slot/port to DCcore1>

DCagg1(config-if)# standby 20 track GigabitEthernet <slot/port to DCcore2>

DCagg2# configure terminal

DCagg2(config)# interface Vlan 10

DCagg2(config-if)# description WLC

DCagg2(config-if)# ip address 10.130.10.2 255.255.255.0

DCagg2(config-if)# standby 10 ip 10.130.10.254

DCagg2(config-if)# standby 10 track GigabitEthernet <slot/port to DCcore1>

DCagg2(config-if)# standby 10 track GigabitEthernet <slot/port to DCcore2>

DCagg2(config-if)# end

DCagg2# configure terminal

DCagg2(config)# interface Vlan 20

DCagg2(config-if)# description DATA

DCagg2(config-if)# ip address 10.130.20.2 255.255.255.0

DCagg2(config-if)# standby 20 ip 10.130.20.254

DCagg2(config-if)# standby 20 preempt

DCagg2(config-if)# standby 20 track GigabitEthernet <slot/port to DCcore1>

DCagg2(config-if)# standby 20 track GigabitEthernet <slot/port to DCcore2>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-12T07:21:40Z

Fatman: /* Inbound Filtering */

[[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 s_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 en 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>

==Alternativer==
==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. 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.

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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
 
For at sikre os mod at brugerne i en context ikke tager alle firewallens ressourcer såsom antal nat translations og samtidinge forbindelser. Det anbefales at man sætter ressourcerne som en procentdel af enhedens totale ressourcer. Det er dog ikke alle ressourcer hvor det kan lade sig gøre såsom antal hosts

<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-12T07:20:14Z

Fatman: /* Inbound Filtering */

[[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 s_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 en 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>

==Alternativer==
==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. 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.

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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
 
For at sikre os mod at brugerne i en context ikke tager alle firewallens ressourcer såsom antal nat translations og samtidinge forbindelser. Det anbefales at man sætter ressourcerne som en procentdel af enhedens totale ressourcer. Det er dog ikke alle ressourcer hvor det kan lade sig gøre såsom antal hosts

<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-12T07:15:46Z

Fatman: /* Inbound Filtering */

[[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 s_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 en 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>

</pre>

==Alternativer==
==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. 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.

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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. 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-12T07:11:38Z

Fatman: /* Inbound Filtering */

[[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 s_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 en 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

==Alternativer==
==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. 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.

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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. 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-12T06:46:56Z

Fatman: /* Internet */

[[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 s_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 en 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.

==Alternativer==
==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. 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.

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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. 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-12T06:34:00Z

Fatman: /* Transit trafik filtrering */

[[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.

===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 en 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.

==Alternativer==
==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. 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.

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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. 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-11T20:43:26Z

Fatman: /* WAN */

Opgave CCDP - Firewall

2009-08-11T20:25:38Z

Fatman: /* WAN */

Opgave CCDP - Firewall

2009-08-11T20:12:50Z

Fatman: /* WAN */

Opgave CCDP - Firewall

2009-08-11T11:57:54Z

Fatman:

Opgave CCDP - Firewall

2009-08-11T11:40:34Z

Fatman: /* IDS */

[[Opgave CCDP]]

[[Image:CCDP-Edge.png|800px|center|thumb|Enterprise Edge]]
__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.

===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 en 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
===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.

==Alternativer==
==WAN==

=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 tage 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 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. 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-11T11:40:21Z

Fatman: /* IDS */

[[Opgave CCDP]]

[[Image:CCDP-Edge.png|800px|center|thumb|Enterprise Edge]]
__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.

===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 en 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
===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.

==Alternativer==
==WAN==

=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 tage affære.<br
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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 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. 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-11T11:24:27Z

Fatman: /* IDS */

[[Opgave CCDP]]

[[Image:CCDP-Edge.png|800px|center|thumb|Enterprise Edge]]
__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.

===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 en 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
===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.

==Alternativer==
==WAN==

=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==
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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 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. 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-11T10:28:01Z

Fatman: /* Internet */

[[Opgave CCDP]]

[[Image:CCDP-Edge.png|800px|center|thumb|Enterprise Edge]]
__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. 

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.

===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 en 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
===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.

==Alternativer==

=Sikkerhed=

[[Image:CCDP-Edge.png|500px|center|thumb|Enterprise Edge]]

==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==
Der placeres en IDS sensor på den offentlige side af netværket for at kunne monitorere evtuelle 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 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. 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-11T10:24:42Z

Fatman:

[[Opgave CCDP]]

[[Image:CCDP-Edge.png|800px|center|thumb|Enterprise Edge]]
__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 200Mbit, 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. 

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.

===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 en 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
===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.

==Alternativer==
=Sikkerhed=

[[Image:CCDP-Edge.png|500px|center|thumb|Enterprise Edge]]

==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==
Der placeres en IDS sensor på den offentlige side af netværket for at kunne monitorere evtuelle 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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 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. 

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-11T10:20:08Z

Fatman: /* Alternativer */

[[Opgave CCDP]]
=Firewall=
Firewallen skal bestå af 2 ASA 5540 som skal have et context 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. 

=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 200Mbit, 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. 

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.

===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 en 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
===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.

==Alternativer==
=Sikkerhed=

[[Image:CCDP-Edge.png|500px|center|thumb|Enterprise Edge]]

==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==
Der placeres en IDS sensor på den offentlige side af netværket for at kunne monitorere evtuelle 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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.

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-11T09:54:27Z

Fatman: /* Network Management */

[[Opgave CCDP]]
=Firewall=
Firewallen skal bestå af 2 ASA 5540 som skal have et context 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. 

=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 200Mbit, 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. 

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.

===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 en 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
===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.

==Alternativer==

[[Image:CCDP-Edge.png|500px|center|thumb|Enterprise Edge]]

==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==
Der placeres en IDS sensor på den offentlige side af netværket for at kunne monitorere evtuelle 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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.

==Referenceliste==
<references/>

[[Category:CCDP]]

Opgave CCDP - Firewall

2009-08-11T08:24:35Z

Fatman: /* Ekstern adgang */

[[Opgave CCDP]]
=Firewall=
Firewallen skal bestå af 2 ASA 5540 som skal have et context 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. 

=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 200Mbit, 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. 

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.

===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 en 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
===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.

==Alternativer==

[[Image:CCDP-Edge.png|500px|center|thumb|Enterprise Edge]]

==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.
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.

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==
Der placeres en IDS sensor på den offentlige side af netværket for at kunne monitorere evtuelle 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.

==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 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/docs/security/vpn_client/anyconnect/anyconnect23/release/notes/anyconnect23rn.html</ref> klienten installeres permanent eller installere/afinstallere sig selv efter behov.

 
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.

==Referenceliste==
<references/>

[[Category:CCDP]]