You are on page 1of 29

Robert Ian Hawdon

Artefact

University of Sunderland

University of Sunderland
Department of Computing, Engineering and Technology Robert Ian Hawdon 099085085 CSE307 Artefact

Overview
Sunderland Commitment Networking Services (SCNS) Ltd. is a company that sub-rents rack space to small businesses setting up e-commerce websites. The clients will be based in the same building as SCNS and will use SCNSs services to power their datacentre as well as their web presence. SCNS focus on security as that is the utter most important aspect of running a datacentre, as clients want to make sure that their data and digital property are safe from malicious attacks which could put their company at risk, this in turn would be bad for SCNS as their reputation would be servilely affected. SCNS rent space in a class 2 datacentre, with each cabinet they rent costing them 3000, and, after adding value, reselling this space to clients. The clients expect a high level of professionalism from SCNS with their service not only offering sufficient bandwidth and availability, but also the space to allow these businesses to grow. SCNS, though, arent experts at network security so have haired external assistance in setting up their system to make sure its secure for customers to use.

Requirements
The first thing that had to be done was to get the requirements from our client (SCNS) for what was expected and how to go ahead building a prototype. From the meeting with the SCNS representative, a clear list of both functional and non-functional requirements could be drawn up.

Functional Requirements
The main requirement is that, as portions of the final product will be sub rented to smaller clients, each portion of the system remains isolated from each other. This means, although they share some hardware, clients must not be able to directly access each others network. The routers that need to be used to develop on must be Cisco 2800s, as thats whats used by SCNS , and building a system tailored for anything else would be counterproductive.

Page 1 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

Security must be in the form of a hardware firewall, this means using the routers built in firewall functions, which are powerful enough for whats needed for this project. Each client requires 3 separate zones in their network: An internal zone for their office computers and intranet servers. This zone must not be accessible from anyone outside the clients company (including other companies using SCNSs services). The internal zone needs to be able to access a public (internet) zone. A DMZ (Demilitarised Zone) the area where the server(s) of the client are based. There should be access to this zone from both the internal zone, and the public (internet) zone. Machines in this zone however, should not be able to start communication with either of the other zones. The public (internet) zone this is the zone to the outside world, the internal network needs to be able to access this, but connections originating from outside must not be able to get into the internal zone. Access to the computers in the DMZ should be available publically.

Each router also has whats known as a Self Zone which should be disabled for both the Public and DMZ zones. Disabling this zone means that the affected computers cannot physically see the interfaces on the router, and pinging them would result in a failed result. The use of a DMZ to host the clients server(s) adds an extra layer of security. Using this configuration, allows for the clients server(s) to be totally isolated from the clients internal network. This means if a weakness is exploited in their server setup, it should not be possible for a potential hacker to get into the internal network. As the connection to the internet is converged, for each client, the connection needs to be optimised to allow for the services a client may wish to use, for example, if a client wishes to specialise in VoIP services, the router needs to be configured to give a higher priority to voice traffic than the internal data networks using a Quality of Service (QoS) policy. Each client is to remain a separate entity, this means connections between internal networks for each client cant be possible (without the use of 3rd party hardware, which would be against the Service Level Agreement (SLA) ) this will mean that if two clients want to interact with each other, they would need to communicate via the internet. Essentially, the clients will see each other as if they were in separate parts of the world.

Non-Functional Requirements
The system, though secure, needs to be fast. Its no good having a system that not only blocks malicious traffic, but affects good traffic too. The systems set up for SCNS needs to be configured to reduce this issue. There should also be a backup system in place if one of the client servers goes down, an SCNS server can display a page acknowledging that theres a problem with that server, so potential customers to that client dont think the company has simply vanished. Backup systems need to in place to ensure that data stored on servers at SCNS is safe. Regular backups to the servers hard drives need to be made and stored off site in case of physical damage.

Page 2 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

The datacentre rack where the servers, routers, and switches will be stored, needs to be in a secure, locked, room which will increase security on a physical level. Sufficient security surveillance systems need to be in place and only certain people can ever have access to the datacentre room. Protecting the machines on a physical level ensures that no-one working in the same building can access secure data on either the servers, or create a backdoor network link. Finally, sufficient documentation of all aspects of the system needs to be created and maintained, including network connections, configuration files, operating systems, etc. This will help new employees understand how the system is set up, or refresh the memories of someone who needs to update the system months after its initial set up. It is imperative that the documentation is kept up to date to ensure the system runs smoothly for years to come.

Project Plan
The first thing that needs to be done is to arrange an initial interview with the client (SCNS), this will help gain a better understanding in what the client wants, by giving a set of requirements for the solution. After this, a Terms of Reference (ToR) needs to be written up (See Appendix A). A ToR allows the client to look over what you propose to do, and make any changes if necessary. After the ToR is signed off by the SCNS client, its then possible to design a topology, showing how the network will be laid out, in an easy to read diagram.

This diagram shows three clients connected to the SCNS system, plus some machines simulating the outside world. The diagram shows four Cisco 2811 routers (to represent the Cisco 2800 routers SCNS have), four Cisco 2950 switches, six servers, and four PCs. Each client is represented by an outlined box, and each client has their own Cisco 2811 router, with one Serial link to the cloud simulation router, and two Fast Ethernet links, one to the internal network switch, and the other to their server in the DMZ. (Client 1 also has a server running in their internal network showing how an intranet server can be placed internally, and cannot be accessed from the outside world.) After the topology is approved by the client, its time to start researching which features of the cisco 2800 routers can be used to enhance the security of the system. The topics that need researching are: Access Control Lists (ACLs), Context-Based Access Control (CBAC), and Zone Based Firewalls (ZBF). Page 3 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

After deciding which form of security to use, a prototype can be built in the Packet Tracer simulator, which will allow the system to be tested on a basic level. The benefit of using Packet Tracer for initial development is that it will allow for changes to the system to be made without having to spend money on physical hardware. It also saves time as you can quickly change things on screen, rather than physically swapping hardware. Some features of a Cisco 2800 router are missing in Packet Tracer, so when it comes to using those features, the simulation will then need to be reproduced on the physical equipment, transferring the configuration from the simulation to the real hardware is relatively simple, meaning it wont take much time to set up the hardware, and continue the final parts of the development on the routers themselves. After the development of the router configurations are complete, testing needs to be carried out. Initial testing can be done on Packet Tracer Testing Pings between machines to make sure only certain machines can access each other. After that, certain functions can only be tested on real equipment such as Data and Voice protocols. Once the testing is complete, and the bugs have been ironed out of the final solution, the system is shown to the client, and the project is signed off. Documentation is finalised, then the project can be signed off by the client.

Best practice for implementing security


Zone Based Firewall
Cisco provide a selection of tools to improve security on their routers, after some research, it was decided that using the Zone Based Firewall method would be the ideal method as theres more control over multiple interfaces. Zone Based Firewalls, according to Cisco, are set to replace CBAC and CBAC is included for backward compatibility purposes. Zone based firewalls differ from CBAC in that rather than configuring the firewall on a per interface level, each interface can be assigned into a group (or zone), and the firewall rules are then applied to the zone. This means that rather than repeating pages of configuration on each interface, or changing many rules if a rule on a group of interfaces needs updating, the configuration need only be changed in one place, and each interface that is a member of that zone will update accordingly. Using zones can also be easier to manage, as zones can be named after what youre intending to use them for. An example of this is calling a zone DMZ for use in the DMZ. When looking over the configuration, it will then be easy to spot the DMZ rules over other rules in the firewall. To use Zone Based Firewall solutions, the Cisco device needs to be running the IOS 12.4(6) or above, anything lower, and CBAC is the next best option.

Alternate solutions
A great advantage of using Zone Based Firewalls is that it makes it easy to add interfaces to the same set of rules. But in the solution designed for SCNS, each zone will only be assigned to one interface. In theory, this means CBAC would be sufficient, but its recommended to use Zone Based Firewalls in all solutions now, as CBAC is a depreciated solution and is included in current versions of the IOS as a Page 4 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

backward compatibility solution for businesses who arent ready to upgrade their whole firewall infrastructure to Zone Based Firewalls yet, or are using devices with versions of the IOS being lower than 12.4(6). Another solution is to invest in a hardware firewall unit. These provide greater protection than whats offered by the IOS but at a much greater cost. The brief from the SCNS client states that the Firewall solutions provided by the IOS in Cisco 2800 routers is enough. The final solution is to install software firewalls on every client and server. This could be very expensive, and will not protect routers from attackers. Combining a software firewall with the firewall solutions in Cisco 2800 routers would create a better barrier from potential hackers, but could also cause more problems if misconfigured.

The Solution
After the plan was accepted by the SCNS client, development on the solution could begin. For a simulation to be built in Packet Tracer, the real equipment needed to be looked over so an accurate clone of them could be created in the simulator. It was decided, the demo system was to consist of three clients, each using a Cisco 2800 router for their routing and firewall functions, and an additional Cisco 2800 router to act as a gateway to the internet, and demonstrate how the clients networks would look to the outside world. The client routers were set up in the following configuration:

Here, the router has its standard two Fast Ethernet interfaces identifying themselves as Fa0/0 and Fa0/1. The intention is to connect the clients internal network switch to Fa0/0 and configure that interface to an Internal Zone and connect the clients server to Fa0/1 and configure that interface to the DMZ Zone. The router also has had one dual Serial WIC card installed in the first slot (Slot 0), this will provide two serial interfaces on the device, S0/0/0 and S0/0/1. Only the first Serial interface (S0/0/0) will be used, and it will be connected to the router providing the internet, this interface will be configured in the firewall as a Public Zone. The three client routers are set up identically, which makes it easier when configuring them as their interfaces are identified in the same way on each device. The internet router was configured in the following manner:

Page 5 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

The only difference between this and the client routers is the addition of an extra two port Serial WIC in the third slot (Slot 2) which adds two more serial interfaces: S0/2/0 and S0/2/1. Slot 2 was chosen over Slot 1 to match the routers already in uses at SCNS. This router will provide the routing functions between the three client routers, as well as allowing for testing from a public users point of view with the use of the Fast Ethernet ports. Should SCNS acquire more clients, extra WICs (WAN Interface Cards) and an NM (Network Module) can be installed to provide more serial ports. At a push, the extra, unused serial interface on client routers could be used to forward through if an appropriate firewall rule is applied. For the current solution though, this wont be necessary. After deciding how to build the routers, it was then possible to build the simulation in Packet Tracer, the first step was to add the devices into the simulation. At this point, the solution includes the following: 4 Cisco 2811 Routers 4 PCs 3 Servers

After the initial devices were in place, they needed to be linked up. The three client routers were serial linked to the internet router. One PC was connected to the internet router via a crossover cable. Each client has a PC and Server connected to each of their routers using crossover cables. Page 6 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

In this state, none of the computers can access each other, it was decided that some switches should be placed in the topology to allow for expansion on the networks. An early idea, which was quickly dropped, was connecting the client routers to the internet through Ethernet via a switch. This was a more expensive option, which would also put a lot of strain on one Ethernet port.

What was achieved, however, was basic routing using EIGRP, which allowed all devices on the networks to communicate with each other. At this stage, it was possible for any device to Page 7 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

communicate with any other device. This was be design, as it allows the network layer of the OSI Model (Layer 3) to be tested, and any issues with the network itself to be ironed out without the firewall being a possible factor. After that, it was then possible to decide what each client network was going to show in the demo. Each client needed to show something different, and reflect this on the outside world computer. It was decided the three clients in the demo would be using these configurations: Client 1 A public website (HTTP) with only Internal data (FTP) access for administration Client 2 A public website (HTTP) and public voice (VoIP) solution Client 3 A public website (HTTP) and public data (FTP) access

Having this clear goal in mind, it was easier to write out a plan explaining the firewall rules for each router, and which interfaces would be members of that zone:

Firewall Rules
Client 1 Internal network (Fa0/0) Can access DMZ on port 80 (HTTP web access), ports 20 and 21 (FTP access), and ICMP (Ping) packets Can access the Internet on all ports Will be blocked if the IP address of the PCs are not in the 193.168.1.0 subnet Anything else will be blocked

Internet (S0/0/0) Can access DMZ on port 80 (HTTP web access), and ICMP (Ping) packets Anything else will be blocked

DMZ (Fa0/1) Any communication initiating from this zone will be blocked

Client 2 Internal network (Fa0/0) Can access DMZ on port 80 (HTTP web access), ports 5004-5082 (VoIP signalling), ports 10000-20000 (VoIP data), and ICMP (Ping) packets Can access Internet on all ports Will be blocked if the IP address of the PCs are not in the 193.168.3.0 subnet Anything else will be blocked

Internet (S0/0/0) Can access DMZ on port 80 (HTTP web access), ports 5004-5082 (VoIP signalling), ports 10000-20000 (VoIP data), and ICMP (Ping) packets Anything else will be blocked Page 8 of 29

Robert Ian Hawdon DMZ (Fa0/1)

Artefact

University of Sunderland

Any communication initiating from this zone will be blocked

Client 3 Internal network (Fa0/0) Can access DMZ on port 80 (HTTP web access), ports 20 and 21 (FTP access), and ICMP (Ping) packets Can access the Internet on all ports Will be blocked if the IP address of the PCs are not in the 193.168.5.0 subnet Anything else will be blocked

Internet (S0/0/0) Can access DMZ on port 80 (HTTP web access), ports 20 and 21 (FTP access), and ICMP (Ping) packets Anything else will be blocked

DMZ (Fa0/1) Any communication initiating from this zone will be blocked

Configuration
Once this plan of action was in place, it was reliably easy to transfer this into the routers. This is a 5 step process: 1. Access Lists need to be written, these are the firewall rules. They permit or deny certain traffic depending on which protocol or port (amongst other things) is being requested 2. Class Maps are used to define a set of rules (mixing and matching access lists) under a keyword. This means rather than repeating certain firewall rules that are going to be reused in multiple access lists, for multiple class maps to refer to the same access list. 3. Policy Maps are used to tell the router which rules to choose in a certain situation. Appropriately naming these will allow for an easier understanding as to what each map does. E.g. PrivateToDMZ suggests that the policy map is in place for all connections originating in the private network going to the DMZ. 4. Zones are what each interface is configured under. Making Fa0/0 a member of the Private zone ensures that anything running off that interface cant be accessed from an interface configured to be a member of the DMZ zone. 5. Zone Pairs will connect two Zones in one direction with a policy map. This means one rule can be set for traffic going one way and another for traffic going the other. Access Lists On the client routers, there were three access lists created. The first one was for the internal network to be able to access the internet without restriction. This was defined by the following two lines (the following examples are from the Client 1 router):

Page 9 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

access-list 100 permit ip 193.168.1.0 0.0.0.255 any access-list 100 deny ip any any

Then there was an access list created for the internal network to access the DMZ on selected services:
access-list www access-list 21 access-list 20 access-list access-list 101 permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq 101 permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq 101 permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq 101 permit icmp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 101 deny ip any any

The three lines allow the devices in the internal network subnet to have access to the web and FTP services on the server(s) hosted in the DMZ, the 4th line allows devices in the internal network ping the server(s) in the DMZ. The last line makes sure any other traffic is denied. In these two access lists, destined for use with traffic originating from the private network, the source IP address subnet 193.168.1.0 is defined. This means if any other machine is connected to that network, and is using a different IP outside of the subnet, the router will run the last line of the access list to that machine and deny all traffic. The last access list deals with traffic originating from the internet:
access-list 102 permit tcp any 193.168.2.0 0.0.0.255 eq www access-list 102 permit icmp any 193.168.2.0 0.0.0.255 access-list 102 deny ip any any

This will allow access from any IP address to the web service on the server(s) in the DMZ, as well as pings. This has the added layer of security in case the access list is applied to the wrong zone, in only allowing these services through on the subnet running behind the DMZ. If this access list was accidently applied to the internal network zone, none of the destination IPs would match the list, and all traffic will be blocked. Class Maps There were 4 class maps set up on the client routers, these were named: AllowedDMZ, AllowedOut, ExternalAccess, and AllTraffic.
class-map type inspect match-all match access-group 101 class-map type inspect match-all match access-group 100 class-map type inspect match-all match access-group 102 class-map type inspect match-all match any match not protocol eigrp AllowedDMZ AllowedOut ExternalAccess AllTraffic

Page 10 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

AllowedDMZ is set to match access list 101, and is called upon when a connection originating in the private network is attempted to access the DMZ AllowedOut is set to match access list 100, and is called upon when an internal network device is attempted to access a location on the internet ExternalAccess is set to match access list 102, and is used by any device trying to access the network from the outside world. AllTraffic is a class map which is set to match any traffic from any location except EIGRP traffic.

Policy Maps There are four policy maps on the client routers, each one named to give an idea what role it plays in the firewall:
policy-map type inspect PrivateToDMZ class type inspect AllowedDMZ inspect ! policy-map type inspect PrivateToInternet class type inspect AllowedOut inspect ! policy-map type inspect InternetToDMZ class type inspect ExternalAccess inspect ! policy-map type inspect DenyAllTraffic class type inspect AllTraffic drop

PrivateToDMZ is told to check all traffic thats in the AllowedDMZ class and allow it through if its verified as good traffic defined in its access group (101) PrivateToInternet is told to check all traffic thats in the AllowedOut class and allow the verified traffic through from its access group (100) InternetToDMZ checks the ExternalAccess class and allows traffic through as defined in its access list (102) DenyAllTraffic looks up any traffic thats left and has fallen into the AllTraffic class, and drops it. (Except EIGRP traffic, as defined in the Class Map)

Zones The zones which the firewall is going to use need to be defined before the pairing process can be done.
zone security Private zone security Internet zone security DMZ

Page 11 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

At this point, the zone pairs can be defined, but its good practice to assign these newly defined zones to the relevant interfaces to avoid the chance of forgetting later, which would leave the network wide open. This is achieved by going into the configuration of the relevant interface (lets say Fa0/0) and adding the line:
zone-member security Private

Which will tell Fa0/0 that its part of the Private zone. Zone Pairs Finally, to tie all these together, the policy maps need to be arranged to tell the router which direction the firewall should be applying these rules, and to which zones.
zone-pair security DMZ_Self source DMZ destination self service-policy type inspect DenyAllTraffic zone-pair security Internet_DMZ source Internet destination DMZ service-policy type inspect InternetToDMZ zone-pair security Internet_Self source Internet destination self service-policy type inspect DenyAllTraffic zone-pair security Private_DMZ source Private destination DMZ service-policy type inspect PrivateToDMZ zone-pair security Private_Internet source Private destination Internet service-policy type inspect PrivateToInternet

When two pairs are defined, it is then linked to one of the policy maps defined above. The Self zone is a special reserved zone for the internal interfaces of the router. Two of the zone pairs (DMZ_Self and Internet_Self) are set to drop all traffic. This will prevent anyone in untrusted zones (DMZ and Internet) from accessing the router directly.

Setting up the simulation


Each of the client routers in Packet Tracer were set up using the configuration guidelines above using the terminal emulator. The resulting configurations were saved to the startup-configuration section, and saved to file. (See Appendix B)

Page 12 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

An extra server was placed in the internal network of Client 1 to demonstrate that an intranet can be configured and no-one outside of the company can access it. At this point, initial testing could begin.

Testing Plan
After setting up the system, it was important to have a plan on how itd be tested, which would ensure that nothing was missed out and that the tests were thorough. Firstly, testing needs to be done to make sure the devices that are supposed to be blocked are indeed blocked, and the ones that should still be visible are. A simple Ping test on each device from three key areas should be tested. The PC from the outside world which should only be able to access itself, and the servers in the DMZ of each of the clients; A PC inside one of the c lients private networks which should be able to access other computers on the same network, the DMZ on the three clients, and the internet; and the DMZ servers which shouldnt be able to access anything but themselves. The initial testing could be done in the packet tracer simulator, but for more advanced features, such as FTP and VoIP testing, the simulation will need to be rebuilt in the real kit. Once on the real equipment, the DMZ servers can be configured to work as Web, Data, and Voice servers and testing of these services can be performed too. Installing the same services on the three DMZs will allow for testing the firewalls capabilities on blocking specific types of traffic.

Evaluation
Testing

Page 13 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

It is important to note at this point that Packet Tracer is limited in what it can do in regards to testing, so this testing report is split in two parts, the simulated tests, and then the testing on the real equipment. The first thing that had to be tested was which devices could still be pinged from the outside world. From the PC marked Joe Public in the simulation, the following IPs were pinged: Out of these, only the DMZs responded with successful pings. Now the firewall is known to be blocking the correct devices (at least, from the outside worlds point of view), services on the DMZ could be tested. Packet Tracer allows for the simulation of a web server, and this was tested on all three clients, all of which could be accessed from the public computers web browser. After this, it was then important to test the firewall rules on the other devices. The same IP addresses were pinged, with the following results: Client PCs Were able to ping themselves, all the DMZs, the Public PC, and their own router. Servers in the DMZ Were able to ping themselves, but nothing else. Client Routers Were able to ping the Clients internal PC, All the DMZs, the Public PC, and itself. 193.168.1.1 Client 1s Router 193.168.1.2 Client 1s Private Network PC 193.168.2.2 Client 1s DMZ 193.168.3.1 Client 2s Router 193.168.3.2 Client 2s Private Network PC 193.168.4.2 Client 2s DMZ 193.168.5.1 Client 3s Router 193.168.5.2 Client 3s Private Network PC 193.168.6.2 Client 3s DMZ 192.168.1.2 The public PC (self)

To be able to do further testing, such as FTP and VoIP, the simulation needed to be transferred over to real devices.

Page 14 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

Because the simulation was set up with the real devices in mind, copying the configuration into the terminal window would allow for quick configuration of the routers. After doing so, the interfaces need to be brought up to allow communication to be passed through them. After setting up the ping test was run again, to make sure the configuration behaved the same way on the real kit as it does in Packet Tracer. A web server was set up on the DMZs and the web test was performed again. Again, to make sure the configuration behaved correctly. After confirming the configuration was now working on real Cisco equipment, an FTP server was installed on both Client 1 and Client 3s DMZ, and the Asterisk VoIP server was set up and configured on Client 2s DMZ. Firstly, the public machine was used to see if it could access FTP on Clients 1 and 3. Client 3s FTP connection succeeded, whilst Client 1s failed. This was by design, as Client 1s FTP access is strictly restricted to the private network for Client 1s employees. Testing FTP from Client 1s internal network showed there to be both access to the FTP server in both Client 1 and Client 3s DMZ. Next, the Voice portion was tested from Client 2. The Asterisk server was configured in Client 2s DMZ, whilst X-Lite, a VoIP softphone, was configured in Client 2s internal network. A second X-Lite softphone was configured in Client 1s internal network, and a phone call was placed between the two phones. This completed successfully showing that Voice was configured correctly over the infrastructure. These tests were then reproduced in front of the SCNS client, who signed off the project as a success as it met the needs that were stated in the Terms of Reference.

Critical Reflection of Solution


Overall, the project was a success, as the firewall the SCNS client asked for was in place and functional. There were however a few issues that were run into during the duration of the project. The real equipment was unavailable during the time the project was ready to be tested, meaning further testing needed to be done in the simulation. This restricted time the project could be thoroughly tested. Another issue that pushed the project back was the inability to configure a Zone Based Firewall on one of the physical devices, after a bit of research, it turned out that Cisco didnt implement Zone Based Firewall solutions into the IOS until version 12.4(6) and this particular router was running IOS 12.4(3). Due to these setbacks, certain aspects of the project needed to go on the backburner, including setting up the NAT which would have allowed for access to the DMZ with the use of the public IP address of the router. As the project was focusing on the Zone Based Firewall configuration portion of the security system, the NAT configuration wasnt essential for the success of the project.

Page 15 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

Reflection
The project that was set out to create a network infrastructure for SCNS, a company providing network rack space in a class 2 datacentre, which would provide a level of security to allow for privacy between clients, as well as sufficient security from malicious users in the outside world. The technology used to achieve the protection was Ciscos Zone Based Firewall solution which is included in recent IOS releases (12.4(6) and above). This allows for more control over which services are restricted, even down to the direction data can flow. There werent many issues with using this technology, as long as it was known how the services that were being configured worked. For example, knowing the ports a service uses, and if they use TCP or UDP traffic. Planning is the key to a successful project, and on reflection, planning could have been executed better, other commitments did sometimes get in the way of this project, and lack of sufficient planning and organisation meant some sections needed to be redone, as insufficient documentation was kept. A key lesson learnt here is that up to date documentation is essential to being able to pick up a project at a later date. The project turned out to be successful and the SCNS client was happy with the outcome (See Appendix C), but certain aspects of it would have been much easier if better planning and organisation strategies were in place.

Page 16 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

Appendix A Terms of Reference

Network Data Centre Rack Robert Ian Hawdon (099085085) B.Sc. Network Systems Requirements Specification Document
Overview
The company requires rack space set up with the idea of sub renting portions of it to clients. The rack will be hosted at a calls 2 data centre, which is guaranteed to have at least a 99.741% uptime. The clients who rent from this rack will be in charge of setting up their servers, and we configure the network to ensure that the clients are unable to access each others servers. The solution to this project needs to work on Cisco 2800 routers.

Product to be delivered to client


The client is looking for a network rack to subrent, which will allow small business clients have an online existence whilst providing an internal network whilst keeping each client isolated from each other.

Client requirements
The client requires the following: A topology to base the final solution on A prototype rack with one Cisco 2800 router Each sub client will have 3 networks: Internal, DMZ (Voice, Data and Webhost), and Internet The router will be hardened to prevent clients seeing each others networks

Constraints
Theres a limitation to only use one router per client, this will save costs, and make the network easier to manage.

Resources
For this project to be a success, the following resources need to be available. RV208, the room with the test routers Library E-Journels White Papers Cisco Packet Tracer (for early design and testing)

Page 17 of 29

Robert Ian Hawdon


Cisco 2800 routers.

Artefact

University of Sunderland

Evaluation
Evaluating the solution will be done be comparing how well the system works against industry standards, and if the final solution actually works to the specifications laid out by the client.

Sponsor Sign-off

Signature

Date

Page 18 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

Appendix B Configuration Files


Client 1 Router Configuration
! version 12.4 no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption ! hostname R1 ! ! ! enable secret 5 $1$mERr$9cTjUIEqNGurQiFU.ZeCi1 ! ! ! ! ! ! ! ! ! ! ! ! spanning-tree mode pvst ! class-map type inspect match-all AllowedDMZ match access-group 101 class-map type inspect match-all AllowedOut match access-group 100 class-map type inspect match-all ExternalAccess match access-group 102 class-map type inspect match-all AllTraffic match any match not protocol eigrp ! policy-map type inspect PrivateToDMZ class type inspect AllowedDMZ inspect ! policy-map type inspect PrivateToInternet class type inspect AllowedOut inspect ! policy-map type inspect InternetToDMZ class type inspect ExternalAccess inspect ! policy-map type inspect DenyAllTraffic class type inspect AllTraffic drop

Page 19 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

! ! ! zone security Private zone security Internet zone security DMZ zone-pair security DMZ_Self source DMZ destination self service-policy type inspect DenyAllTraffic zone-pair security Internet_DMZ source Internet destination DMZ service-policy type inspect InternetToDMZ zone-pair security Internet_Self source Internet destination self service-policy type inspect DenyAllTraffic zone-pair security Private_DMZ source Private destination DMZ service-policy type inspect PrivateToDMZ zone-pair security Private_Internet source Private destination Internet service-policy type inspect PrivateToInternet ! interface Loopback0 ip address 10.1.1.1 255.255.255.0 ! interface FastEthernet0/0 ip address 193.168.1.1 255.255.255.0 zone-member security Private duplex auto speed auto ! interface FastEthernet0/1 ip address 193.168.2.1 255.255.255.0 zone-member security DMZ duplex auto speed auto ! interface Serial0/0/0 ip address 169.12.0.2 255.255.255.252 zone-member security Internet ! interface Serial0/0/1 no ip address clock rate 2000000 ! interface Vlan1 no ip address shutdown ! router eigrp 212 network 169.11.0.0 network 169.12.0.0 network 193.168.1.0 network 193.168.2.0 auto-summary ! ip classless !

Page 20 of 29

Robert Ian Hawdon


! access-list 101 www access-list 101 21 access-list 101 20 access-list 101 access-list 101 access-list 100 access-list 100 access-list 102 access-list 102 access-list 102 ! no cdp run ! ! ! ! ! line con 0 password cisco login line vty 0 4 password cisco login ! ! ! end

Artefact

University of Sunderland

permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq permit icmp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 deny ip any any permit ip 193.168.1.0 0.0.0.255 any deny ip any any permit tcp any 193.168.2.0 0.0.0.255 eq www permit icmp any 193.168.2.0 0.0.0.255 deny ip any any

Client 2 Router Configuration


! version 12.4 no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption ! hostname R2 ! ! ! enable secret 5 $1$mERr$9cTjUIEqNGurQiFU.ZeCi1 ! ! ! ! ! ! ! !

Page 21 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

! ! ! ! spanning-tree mode pvst ! class-map type inspect match-all AllowedDMZ match access-group 101 class-map type inspect match-all AllowedOut match access-group 100 class-map type inspect match-all ExternalAccess match access-group 102 class-map type inspect match-all AllTraffic match any match not protocol eigrp ! policy-map type inspect PrivateToDMZ class type inspect AllowedDMZ inspect ! policy-map type inspect PrivateToInternet class type inspect AllowedOut inspect ! policy-map type inspect InternetToDMZ class type inspect ExternalAccess inspect ! policy-map type inspect DenyAllTraffic class type inspect AllTraffic drop ! ! ! zone security Private zone security Internet zone security DMZ zone-pair security DMZ_Self source DMZ destination self service-policy type inspect DenyAllTraffic zone-pair security Internet_DMZ source Internet destination DMZ service-policy type inspect InternetToDMZ zone-pair security Internet_Self source Internet destination self service-policy type inspect DenyAllTraffic zone-pair security Private_DMZ source Private destination DMZ service-policy type inspect PrivateToDMZ zone-pair security Private_Internet source Private destination Internet service-policy type inspect PrivateToInternet ! interface Loopback0 ip address 10.1.3.1 255.255.255.0 ! interface FastEthernet0/0 ip address 193.168.3.1 255.255.255.0

Page 22 of 29

Robert Ian Hawdon


zone-member security Private duplex auto speed auto

Artefact

University of Sunderland

! interface FastEthernet0/1 ip address 193.168.4.1 255.255.255.0 zone-member security DMZ duplex auto speed auto ! interface Serial0/0/0 ip address 169.12.0.6 255.255.255.252 zone-member security Internet ! interface Serial0/0/1 no ip address clock rate 2000000 shutdown ! interface Vlan1 no ip address shutdown ! router eigrp 212 network 169.11.0.0 network 169.12.0.0 network 193.168.3.0 network 193.168.4.0 auto-summary ! ip classless ! ! access-list 100 permit ip 193.168.3.0 0.0.0.255 any access-list 100 deny ip any any access-list 102 permit udp any 193.168.4.0 0.0.0.255 range 10000 20000 access-list 102 permit udp any 193.168.4.0 0.0.0.255 range 5004 5082 access-list 102 permit tcp any 193.168.4.0 0.0.0.255 eq www access-list 102 permit icmp any 193.168.4.0 0.0.0.255 access-list 102 deny ip any any access-list 101 permit udp 193.168.3.0 0.0.0.255 193.168.4.0 0.0.0.255 range 10000 20000 access-list 101 permit udp 193.168.3.0 0.0.0.255 193.168.4.0 0.0.0.255 range 5004 5082 access-list 101 permit tcp 193.168.3.0 0.0.0.255 193.168.4.0 0.0.0.255 eq www access-list 101 permit icmp 193.168.3.0 0.0.0.255 193.168.4.0 0.0.0.255 access-list 101 deny ip any any ! no cdp run ! ! !

Page 23 of 29

Robert Ian Hawdon


! ! line con 0 password cisco login line vty 0 4 password cisco login ! ! ! end

Artefact

University of Sunderland

Client 3 Router Configuration


! version 12.4 no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption ! hostname R3 ! ! ! enable secret 5 $1$mERr$9cTjUIEqNGurQiFU.ZeCi1 ! ! ! ! ! ! ! ! ! ! ! ! spanning-tree mode pvst ! class-map type inspect match-all AllowedDMZ match access-group 101 class-map type inspect match-all AllowedOut match access-group 100 class-map type inspect match-all ExternalAccess match access-group 102 class-map type inspect match-all AllTraffic match any match not protocol eigrp ! policy-map type inspect PrivateToDMZ class type inspect AllowedDMZ inspect

Page 24 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

! policy-map type inspect PrivateToInternet class type inspect AllowedOut inspect ! policy-map type inspect InternetToDMZ class type inspect ExternalAccess inspect ! policy-map type inspect DenyAllTraffic class type inspect AllTraffic drop ! ! ! zone security Private zone security Internet zone security DMZ zone-pair security DMZ_Self source DMZ destination self service-policy type inspect DenyAllTraffic zone-pair security Internet_DMZ source Internet destination DMZ service-policy type inspect InternetToDMZ zone-pair security Internet_Self source Internet destination self service-policy type inspect DenyAllTraffic zone-pair security Private_DMZ source Private destination DMZ service-policy type inspect PrivateToDMZ zone-pair security Private_Internet source Private destination Internet service-policy type inspect PrivateToInternet ! interface Loopback0 ip address 10.1.5.1 255.255.255.0 ! interface FastEthernet0/0 ip address 193.168.5.1 255.255.255.0 zone-member security Private duplex auto speed auto ! interface FastEthernet0/1 ip address 193.168.6.1 255.255.255.0 zone-member security DMZ duplex auto speed auto ! interface Serial0/0/0 ip address 169.12.0.10 255.255.255.252 zone-member security Internet ! interface Serial0/0/1 no ip address clock rate 2000000 shutdown !

Page 25 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

interface Vlan1 no ip address shutdown ! router eigrp 212 network 169.11.0.0 network 169.12.0.0 network 193.168.5.0 network 193.168.6.0 auto-summary ! ip classless ! ! access-list 101 permit tcp 193.168.5.0 0.0.0.255 193.168.6.0 0.0.0.255 www access-list 101 permit tcp 193.168.5.0 0.0.0.255 193.168.6.0 0.0.0.255 443 access-list 101 permit tcp 193.168.5.0 0.0.0.255 193.168.6.0 0.0.0.255 20 access-list 101 permit tcp 193.168.5.0 0.0.0.255 193.168.6.0 0.0.0.255 21 access-list 101 permit icmp 193.168.5.0 0.0.0.255 193.168.6.0 0.0.0.255 access-list 101 deny ip any any access-list 100 permit ip 193.168.5.0 0.0.0.255 any access-list 100 deny ip any any access-list 102 permit tcp any 193.168.6.0 0.0.0.255 eq www access-list 102 permit tcp any 193.168.6.0 0.0.0.255 eq 443 access-list 102 permit tcp any 193.168.6.0 0.0.0.255 eq 20 access-list 102 permit tcp any 193.168.6.0 0.0.0.255 eq 21 access-list 102 permit icmp any 193.168.6.0 0.0.0.255 access-list 102 deny ip any any ! no cdp run ! ! ! ! ! line con 0 password cisco login line vty 0 4 password cisco login ! ! ! end

eq eq eq eq

Page 26 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

Internet Router Configuration


! version 12.4 no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption ! hostname INTERNET ! ! ! enable secret 5 $1$mERr$9cTjUIEqNGurQiFU.ZeCi1 ! ! ! ! ! ! ! ! ! ! ! ! spanning-tree mode pvst ! ! ! ! interface FastEthernet0/0 no ip address duplex auto speed auto shutdown ! interface FastEthernet0/1 ip address 192.168.1.1 255.255.255.0 duplex auto speed auto ! interface Serial0/0/0 ip address 169.12.0.1 255.255.255.252 clock rate 2000000 ! interface Serial0/0/1 ip address 169.12.0.5 255.255.255.252 clock rate 2000000 ! interface Serial0/2/0 ip address 169.12.0.9 255.255.255.252 clock rate 2000000 ! interface Serial0/2/1

Page 27 of 29

Robert Ian Hawdon


no ip address clock rate 2000000 ! interface Vlan1 no ip address shutdown ! router eigrp 212 network 169.12.0.0 network 192.168.1.0 auto-summary ! ip classless ! ! ! ! ! ! ! line con 0 password cisco login line vty 0 4 password cisco login ! ! ! end

Artefact

University of Sunderland

Page 28 of 29

Robert Ian Hawdon

Artefact

University of Sunderland

Appendix C Demonstration & Sign-off documentation

Page 29 of 29