Data Centre Practical Report

Robert Ian Hawdon Artefact University of Sunderland

University of SunderlandDepartment of Computing, Engineering and Technology

Robert Ian Hawdon

099085085

CSE307 – Artefact

OverviewSunderland 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 SCNS’s 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, aren’t experts at network security so have haired external assistance in setting up their system to make sure it’s secure for customers to use.

RequirementsThe 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 RequirementsThe 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 other’s network.

The routers that need to be used to develop on must be Cisco 2800s, as that’s what’s used by SCNS, and building a system tailored for anything else would be counterproductive.

of 29


Security must be in the form of a hardware firewall, this means using the router’s built in firewall functions, which are powerful enough for what’s 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 client’s company (including other companies using SCNS’s 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 what’s 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 can’t be possible (without the use of 3 rd 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 RequirementsThe system, though secure, needs to be fast. It’s 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 there’s a problem with that server, so potential customers to that client don’t 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 server’s hard drives need to be made and stored off site in case of physical damage.

of 29


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 PlanThe 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, it’s 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, it’s 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).

of 29


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 won’t 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 FirewallCisco 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 there’s 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 you’re 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 solutionsA 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 it’s 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

of 29


backward compatibility solution for businesses who aren’t 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 what’s 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 SolutionAfter 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 client’s internal network switch to Fa0/0 and configure that interface to an “Internal Zone” and connect the client’s 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:

of 29


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 user’s 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 won’t 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.

of 29


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

of 29


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 1Internal 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


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

of 29


DMZ (Fa0/1)




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)


Anything else will be blocked

DMZ (Fa0/1)


ConfigurationOnce 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 can’t 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 ListsOn 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):

of 29


access-list 100 permit ip 193.168.1.0 0.0.0.255 anyaccess-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 101 permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq wwwaccess-list 101 permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq 21access-list 101 permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq 20access-list 101 permit icmp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255access-list 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 wwwaccess-list 102 permit icmp any 193.168.2.0 0.0.0.255access-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 MapsThere were 4 class maps set up on the client routers, these were named: AllowedDMZ, AllowedOut, ExternalAccess, and AllTraffic.

class-map type inspect match-all AllowedDMZ match access-group 101class-map type inspect match-all AllowedOut match access-group 100class-map type inspect match-all ExternalAccess match access-group 102class-map type inspect match-all AllTraffic match any match not protocol eigrp

of 29


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 MapsThere 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 that’s in the AllowedDMZ class and allow it through if it’s verified as good traffic defined in its access group (101)

PrivateToInternet is told to check all traffic that’s 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 that’s left and has fallen into the AllTraffic class, and drops it. (Except EIGRP traffic, as defined in the Class Map)

ZonesThe zones which the firewall is going to use need to be defined before the pairing process can be done.

zone security Privatezone security Internetzone security DMZ

of 29


At this point, the zone pairs can be defined, but it’s 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 (let’s say Fa0/0) and adding the line:

zone-member security Private

Which will tell Fa0/0 that it’s part of the “Private” zone.

Zone PairsFinally, 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 DenyAllTrafficzone-pair security Internet_DMZ source Internet destination DMZ service-policy type inspect InternetToDMZzone-pair security Internet_Self source Internet destination self service-policy type inspect DenyAllTrafficzone-pair security Private_DMZ source Private destination DMZ service-policy type inspect PrivateToDMZzone-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 simulationEach 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)

of 29


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 it’d 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 client’s 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 shouldn’t 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 firewall’s capabilities on blocking specific types of traffic.

of 29


Evaluation

TestingIt 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:

193.168.1.1 – Client 1’s Router 193.168.1.2 – Client 1’s Private Network PC 193.168.2.2 – Client 1’s DMZ 193.168.3.1 – Client 2’s Router 193.168.3.2 – Client 2’s Private Network PC 193.168.4.2 – Client 2’s DMZ 193.168.5.1 – Client 3’s Router 193.168.5.2 – Client 3’s Private Network PC 193.168.6.2 – Client 3’s DMZ 192.168.1.2 – The public PC (self)

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 world’s 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 computer’s 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 Client’s internal PC, All the DMZs, the Public PC, and itself.

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

of 29


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 3’s DMZ, and the Asterisk VoIP server was set up and configured on Client 2’s DMZ.

Firstly, the public machine was used to see if it could access FTP on Clients 1 and 3. Client 3’s FTP connection succeeded, whilst Client 1’s failed. This was by design, as Client 1’s FTP access is strictly restricted to the private network for Client 1’s employees. Testing FTP from Client 1’s internal network showed there to be both access to the FTP server in both Client 1 and Client 3’s DMZ.

Next, the Voice portion was tested from Client 2. The Asterisk server was configured in Client 2’s DMZ, whilst X-Lite, a VoIP softphone, was configured in Client 2’s internal network. A second X-Lite softphone was configured in Client 1’s 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 SolutionOverall, 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 didn’t 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 wasn’t essential for the success of the project.

of 29


ReflectionThe 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 Cisco’s 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 weren’t 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.

of 29


Appendix A – Terms of Reference

Network Data Centre Rack

Robert Ian Hawdon (099085085)

B.Sc. Network Systems

Requirements Specification Document

OverviewThe 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 other’s servers.

The solution to this project needs to work on Cisco 2800 routers.

Product to be delivered to clientThe 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 requirementsThe 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 other’s networks

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

ResourcesFor this project to be a success, the following resources need to be available.

RV208, the room with the test routers Library E-Journels

of 29


White Papers Cisco Packet Tracer (for early design and testing) Cisco 2800 routers.

EvaluationEvaluating 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

of 29


Appendix B – Configuration Files

Client 1 – Router Configuration!version 12.4no service timestamps log datetime msecno service timestamps debug datetime msecno 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 101class-map type inspect match-all AllowedOut match access-group 100class-map type inspect match-all ExternalAccess match access-group 102class-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

of 29


class type inspect AllTraffic drop!!!zone security Privatezone security Internetzone security DMZzone-pair security DMZ_Self source DMZ destination self service-policy type inspect DenyAllTrafficzone-pair security Internet_DMZ source Internet destination DMZ service-policy type inspect InternetToDMZzone-pair security Internet_Self source Internet destination self service-policy type inspect DenyAllTrafficzone-pair security Private_DMZ source Private destination DMZ service-policy type inspect PrivateToDMZzone-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!

of 29


ip classless!!access-list 101 permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq wwwaccess-list 101 permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq 21access-list 101 permit tcp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255 eq 20access-list 101 permit icmp 193.168.1.0 0.0.0.255 193.168.2.0 0.0.0.255access-list 101 deny ip any anyaccess-list 100 permit ip 193.168.1.0 0.0.0.255 anyaccess-list 100 deny ip any anyaccess-list 102 permit tcp any 193.168.2.0 0.0.0.255 eq wwwaccess-list 102 permit icmp any 193.168.2.0 0.0.0.255access-list 102 deny ip any any!no cdp run!!!!!line con 0 password cisco loginline vty 0 4 password cisco login!!!end

Client 2 – Router Configuration!version 12.4no service timestamps log datetime msecno service timestamps debug datetime msecno service password-encryption!hostname R2!!!enable secret 5 $1$mERr$9cTjUIEqNGurQiFU.ZeCi1!!!!!!

of 29


!!!!!!spanning-tree mode pvst!class-map type inspect match-all AllowedDMZ match access-group 101class-map type inspect match-all AllowedOut match access-group 100class-map type inspect match-all ExternalAccess match access-group 102class-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 Privatezone security Internetzone security DMZzone-pair security DMZ_Self source DMZ destination self service-policy type inspect DenyAllTrafficzone-pair security Internet_DMZ source Internet destination DMZ service-policy type inspect InternetToDMZzone-pair security Internet_Self source Internet destination self service-policy type inspect DenyAllTrafficzone-pair security Private_DMZ source Private destination DMZ service-policy type inspect PrivateToDMZzone-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!

of 29


interface FastEthernet0/0 ip address 193.168.3.1 255.255.255.0 zone-member security Private duplex auto speed auto!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 anyaccess-list 100 deny ip any anyaccess-list 102 permit udp any 193.168.4.0 0.0.0.255 range 10000 20000access-list 102 permit udp any 193.168.4.0 0.0.0.255 range 5004 5082access-list 102 permit tcp any 193.168.4.0 0.0.0.255 eq wwwaccess-list 102 permit icmp any 193.168.4.0 0.0.0.255access-list 102 deny ip any anyaccess-list 101 permit udp 193.168.3.0 0.0.0.255 193.168.4.0 0.0.0.255 range 10000 20000access-list 101 permit udp 193.168.3.0 0.0.0.255 193.168.4.0 0.0.0.255 range 5004 5082access-list 101 permit tcp 193.168.3.0 0.0.0.255 193.168.4.0 0.0.0.255 eq wwwaccess-list 101 permit icmp 193.168.3.0 0.0.0.255 193.168.4.0 0.0.0.255access-list 101 deny ip any any!no cdp run!

of 29


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

Client 3 – Router Configuration!version 12.4no service timestamps log datetime msecno service timestamps debug datetime msecno 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 101class-map type inspect match-all AllowedOut match access-group 100class-map type inspect match-all ExternalAccess match access-group 102class-map type inspect match-all AllTraffic match any match not protocol eigrp!policy-map type inspect PrivateToDMZ

of 29


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 Privatezone security Internetzone security DMZzone-pair security DMZ_Self source DMZ destination self service-policy type inspect DenyAllTrafficzone-pair security Internet_DMZ source Internet destination DMZ service-policy type inspect InternetToDMZzone-pair security Internet_Self source Internet destination self service-policy type inspect DenyAllTrafficzone-pair security Private_DMZ source Private destination DMZ service-policy type inspect PrivateToDMZzone-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

of 29


shutdown!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 eq wwwaccess-list 101 permit tcp 193.168.5.0 0.0.0.255 193.168.6.0 0.0.0.255 eq 443access-list 101 permit tcp 193.168.5.0 0.0.0.255 193.168.6.0 0.0.0.255 eq 20access-list 101 permit tcp 193.168.5.0 0.0.0.255 193.168.6.0 0.0.0.255 eq 21access-list 101 permit icmp 193.168.5.0 0.0.0.255 193.168.6.0 0.0.0.255access-list 101 deny ip any anyaccess-list 100 permit ip 193.168.5.0 0.0.0.255 anyaccess-list 100 deny ip any anyaccess-list 102 permit tcp any 193.168.6.0 0.0.0.255 eq wwwaccess-list 102 permit tcp any 193.168.6.0 0.0.0.255 eq 443access-list 102 permit tcp any 193.168.6.0 0.0.0.255 eq 20access-list 102 permit tcp any 193.168.6.0 0.0.0.255 eq 21access-list 102 permit icmp any 193.168.6.0 0.0.0.255access-list 102 deny ip any any!no cdp run!!!!!line con 0 password cisco loginline vty 0 4 password cisco login!!!end

of 29


Internet – Router Configuration!version 12.4no service timestamps log datetime msecno service timestamps debug datetime msecno 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

of 29


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 loginline vty 0 4 password cisco login!!!end

of 29


Appendix C – Demonstration & Sign-off documentation

of 29

Data Centre Practical Report

Documents

Transcript of Data Centre Practical Report