[VIRTUAL SECURITY BEST PRACTICES ] CNIT 399- Virtual Security Best Practices. Thomas (T.J.) Busch

Transcription

1 2012 CNIT 399- Virtual Security Best Practices Thomas (T.J.) Busch [VIRTUAL SECURITY BEST PRACTICES ] A guide for anyone designing/building/managing a virtual environment and the architectures / services and management functionality that can be implemented to maintain a secure, but functional computing environment.

2 P a g e 1 Contents Introduction... 3 Problem... 3 Objectives... 3 Equipment List... 4 Timeline... 4 Technologies Implemented... 5 Initial Scans... 6 Windows 7, No Patches, Remote Desktop Enabled... 6 ESXi Server 5.0, No Patches... 7 Centos, Patched, DNS Service... 7 Server 2008 R2, Patched... 7 Design Process Recommendations... 9 Physical Architecture... 9 Physical Switching Environment... 9 Vmotion between ESXi hosts... 9 Vsphere SAN Architecture Dual Virtual Firewall DMZ Segmentation InnerDMZ/Server/Client Segmentation IP Addressing Scheme Services Mail Relays DNS Relays RADIUS Web/Reverse Proxies Client Access VPN Intrusion Prevention System Management Separate Layer 2 Subnet for MGMT AD authentication for VMware Management Console... 20

3 P a g e 2 Results Takeaways Further Enhancements Bibliography Appendix... 25

4 P a g e 3 Introduction Problem In today s every changing technological world the security of computer systems is key to ensure that the data and infrastructure that composes a system functions properly and ensures that the data in delivered in a secure manner. While advanced strives have been made in the industry to help protect systems from attack, there is a lack of understanding and knowledge that exists for the average IT specialist that design, build, and manage these systems. With the widespread implementation of virtualized environments over the past couple of years, the importance of ensuring that these systems are secured is more important than ever before. This is due to the following key issues: 1. Infrastructure changes are done via software / Remote Connections as opposed to requiring physical access to the device itself 2. Virtual Machines can be created at the click of a button resulting in machines that may be non-compliant with existing security policies 3. Virtual Machines can be created and used to steal company data then removed taking all logs with it. 4. There is no existing software that can automatically monitor for rouge Virtual machines. 5. System administrators are usually managing all virtual machines and infrastructure. They have a lack of knowledge of the effects of allowing all traffic over the same network segment because it is out of their area of expertise. 6. Documentation published by virtualization platform providers is complicated to understand/comprehend for IT personal not familiar with that particular technology. This independent study interests me because it allows me to apply the ever changing world of security and the best practices to a virtual environment. The same practices that apply to a physical environment can be applied in a virtual environment with no additional costs, unlike the physical counterpart. However, these changes are never implemented either because of time constraints, lack of understanding, or the matter security was never considered into the original process. Being able to research the effects of taking a system that is insecure and apply different segmentation, AAA, and network intrusion / Firewall implementation and weave it into a guide that can be used to showcase a secure system would be beneficial not only to myself but to any IT personal that come in contact with a virtual machine or virtualized infrastructure component. Objectives 1. Showcase the flaws with a single Ethernet connection on a VM 2. Showcase the amount of attack vectors that exist on a virtual machine in the following settings a. Windows 7, No Patches, Remote Desktop Enabled b. Centos: Patched, DNS Service c. Server 2008 R2: Patched d. ESXi Server, No Patches 3. Scan the above machines with Nessus to determine attack vectors that exist on each setup

5 P a g e 4 4. Using the above scans implement a small enterprise network that provides a secure environment and minimized the chance of an attack on the network 5. Provide a mechanism that watches for traffic that has the potential to cause substantial damage to a network / Data stored on the network. 6. Provide a mechanism that track access to secure segments on the network 7. Scan the Network from the Internet and from within the firewall using Nessus. 8. Showcase a security measure that protects on each of the 7 layers of the OSI model. 9. Provide analysis of the two tests and how implementing said feature is beneficial to the overall security of the network. 10. Talk about software specific features that can open the best of systems to an attack (People training) Equipment List In order to provide an environment that would be similar of a small enterprise environment it was required that the following equipment be utilized to provide a similar environment, while still at the same time not require a large amount of resources. 2 Dell 990 Desktops (ESXi 5.1) 1 Dell Optiplex Desktop (SAN) 1 Additional NIC for SAN 1 GS108T (Network Switch) Once setup was completed using a borrowed keyboard/mouse/monitor the servers were managed remotely by either the VMware client console or through OpenFiler s Web GUI interface. Timeline Week 1: In week one the initial configuration will be performed. This includes the installation of the two ESXi 5.0 hosts along with the OpenFiler SAN server software. OpenFiler will then be configured to host an ESXi datastore via an iscsi target. After proper operation is determined, a vcenter instance will then be created and each ESXi host will be linked to the vcenter instance Week 2: The three individual VMs will be created and configured with the settings / services that were listed above. A Nessus scan will then be initiated against each of the machines and the resulting report will be used to enhance the backing of how an improperly designed network can lead a system to become open to attacks. These reports will then be used to help formulate some suggestions of how to segment the network and provide mechanisms to ensure only authorized users can access devices and how the segmentation of the network can help contain the damage if a system is compromised. Week 3 12: Implementation of a small enterprise network that provides , Active Directory, DNS, and Web. These machines will be implemented into the network and utilizing the Nessus reports generated in Week 2, proper network segmentation, and security architecture techniques (DMZ) will be implemented. Additional security mechanisms will also be implemented to showcase security measures that can be used to protect services that run at higher layers (application gateway controllers, proxies) as well as proactive monitoring / filtering solutions that can be used at the edge of the network segments to prevent packets being used to transmit exploitation code. On segments that control administrative

6 P a g e 5 functions or require logging / controlled access, AAA servers will be implemented to showcase how these can be used to help prevent remote access. Additional services may be configured during this time, to provide monitoring, and logging of access in order to provide evidence of the variety of attacks that will be launched against the system during week Week 12-14: Week 13 and 14 will be used extensively to write the whitepaper and complete any additional scans or get screenshots to be included in the paper. A Rough Draft of the paper will be submitted sometime during Week 13 and 14 for constructive criticism. Week 15: Week 15 will be used to polish the whitepaper and to create a quality final draft to then be presented to Prof. Rawles for grading. A final progress meeting will occur when the final draft is turned in. Technologies Implemented Over the course of the 16 weeks the following technologies where implemented in order to implement a secure network infrastructure. Due to time / budget constraints please note that the technologies implemented tended to be those that were free or had a trial version that would suffice for the timeframe of the project. For example, VMware ESXi and VMware vcenter had a trial key that sufficed for the duration of the project. However these services would require an official license key after the trial time frame in order for the proposed secure network solution to continue to work. Operation Systems Services ESXi 5.1 vcenter 5.0 Appliance OpenFiler Centos pfsense Firewall Appliance Windows 7 Windows Server 2008 R2 Backtrack 5.1 Virtual Machine Active Directory Apache BIND PPTP Client Access VPNs RADIUS Sendmail Snort Squid

7 P a g e 6 Initial Scans Before retailoring the small enterprise network to be more secure, a Nessus scan was performed against each of the test machines to showcase the threat(s) that are exposed in the system itself or in the additional services that are being run. For this test, four common operating systems were chosen to be tested. All four ran an additional commonly used service or application to showcase that the vulnerability may come from the application itself and not the OS necessarily. All services were exposed to the same simulated public IP address. **Full Reports are available at the end of this report Windows 7, No Patches, Remote Desktop Enabled One operating system that is commonly deployed in an enterprise level setting is Microsoft Windows 7. These systems are typically utilized by the employees of companies making them the highest base target for attack due to their wide usage base. In this particular test, it was important to showcase the threat that is introduced when a regular patching cycle is not being followed. The Nessus scan (Figure 1) provided that there was a known exploit with the Remote Desktop service being ran on this system. This exploit would allow the Windows 7 host the ability to remote arbitrary code and potentially allow a remote attacker to gain full access into the system. This could provide the attacker the foothold they require and allow them to perform additional attacks that could ultimately lead them to stealing usernames and passwords and gaining access to company secrets. There was also an additional exploit on this machine related to DNS functionality that would provide the same results. Figure 1 Windows 7 Exploits These known exploit points are utilized in the wild to gain access into devices. However these holes have had patches designed for them and rolled out. All it would take to remediate this issue, and close the threat, is to apply the patches. If this machine existed in a secure subnet with limited access, the patch becomes not as large of an issue, but is still considered best practice to apply the patch in order to reduce the overall threats that exist within the network.

8 P a g e 7 ESXi Server 5.0, No Patches ESXi is the operating system that runs most large enterprises virtual machines. Although many think that this software is highly complex, the system is nothing more than a modified version of Red Hat Linux, leaving it vulnerable to the same types of exploits. Since a large amount of large enterprises utilize this software for critical servers and services that serve the main purpose of the organization. The Nessus scan (Figure 2) provided that this system coming straight from the installed disk has known critical security issues. A check of the VMware website reveals that these exploits range anywhere from arbitrary code execution to the ability for a user to crash the ESXi machine, causing all machines running on the device to go down as well. Figure 2 ESXi Exploits As with the Windows 7 host, patches exist for these exploits and can be applied fairly easily and affectively remove any threats associated with this. Because these systems are critical to the running organization, it is best practice to ensure that the management IPs associated with these devices are located in a dedicated management subnet, or utilizing a private IP. Centos, Patched, DNS Service Linux systems are widely utilized in large enterprises to run critical services, such as database, DNS, and systems. These systems are typically chosen because they can perform tasks quickly and since there is not GUI, most of the resources can be spent on running the service at hand. The system in question is running the DNS service, which is used to translate between URLs and IP addresses. The Nessus scan provided that with this system and service there was no exploits located in this system. This showcases by ensuring that systems remained patched and secure, the risks for exploitation is reduced and there is no potential for the exploit to be utilized by an attacker. Server 2008 R2, Patched The last system we checked was using Windows Server 2008 R2. This operating system is typically used in large enterprises when the service or solution being implemented requires that Microsoft be used. The Nessus scan (Figure 3) provided that with this system there was a known exploit. This exploit provides a remote attacker the ability to run arbitrary code against the DNS service

9 P a g e 8 and potentially gain full access to the server. This exploit is the same exploit that was found on the Windows 7 host showcasing the importance of ensuring when patches are released from a vendor, you update all the machines since the exploit could exist between the different versions. Figure 3 Windows 2008 Exploits As with the Windows 7 host, patches exist for these exploits and can be applied fairly easily and affectively remove any threats associated with this exploit.

10 P a g e 9 Design Process Recommendations Physical Architecture Physical Switching Environment The switching architecture that was put into use in our implementation only consisted of an Eight Port Gigabit Switch. However this switch was designed to implement VLANs extensively. This will provide the opportunity for the network to grow and allow for additional ESXi hosts and physical clients to be added to existing network segments when the time. VLANS were utilized in order to provide an isolated network segment to services that require this type of isolation. Some of these services include VMware s vmotion, all SAN traffic within the network, and any management function. In our test environment a total of 10 VLANs were implemented. They are as follows. VLAN ID Description Subnet 1 Unused* 2 Default Gateway /27 10 DMZ Mail/DNS /27 11 DMZ Proxy /27 12 DMZ Web /27 16 InnerDMZ /24 17 Servers /24 18 Clients / iscsi Network / MGMT / vmotion /24 VLAN 1 was chosen not to be utilized in our environment due to the dangers associated with this default VLAN. By segmenting different networks across our entire enterprise it allowed for mechanisms such as vmotion to occur and allow hosts to create additional machines when the load demanded or move machines to other VMs when the demand wasn t as high. To ensure that the switching management interface was not accessed by unauthorized users, it was moved to the management subnet to ensure that any changes were tracked and could be coordinated to the user that made the particular change. Vmotion between ESXi hosts One key aspect that helps to provides an almost 100% uptime in today s virtual environments is the ability for VMs to migrate across various hypervisors without any downtime occurring and no adverse effects on the end user. However this type of traffic will create a lot of messages when VMs are not being transferred to ensure that hosts are up and can receive transferred VMS. Additionally an even larger amount of traffic

11 P a g e 10 between ESXi hosts will be generated when VMs are actively being transferred across the network segment. For this reason when the network was designed this traffic was isolated from the rest of the network. This was largely because all communication that this service needs to remain internal to the server network and to remain secured to ensure that a rouge ESXi server or computer on the segment cannot intercept a transferring VM. These requirements were accomplished by assigning the traffic with a RFC 1918 private address and by securing this private address inside of its own VLAN. To ensure that this traffic would never leave the local server network, on the external firewall the gateway for the private IP subnet was denied any access out to the internet. Vsphere SAN The introduction of centralized storage has helped to relieve some of the work that has plagued IT for years, Backups. With the introduction of these devices, backups can occur from one set of disks that are all contained in the same device and appear as one big giant disk, as opposed to hundreds of disk spread across every piece of server hardware. However these systems introduced a new equation into the mix of computer security. How can data be securely sent to every piece of hardware that requires storage space without introducing a large amount of overhead or latency into the mix that could cause data to be lost? Common practices dictate that a separate Ethernet network be utilized to carry the storage network traffic in an IP packet, to system where there are dedicated interfaces and network devices that can cost thousands of dollars. In our network it was determined due to constraints with both time and equipment that we would utilize the same 1GB Ethernet connection that was being utilized to provide us network connectivity. Although best practices dictate that this type of traffic should have its own layer 2-3 network we determined that the link would be able to handle the load of both the network and the ISCSI traffic without any loss of packets on either traffic segment. However to ensure that this type of traffic was secure and not affect by high utilization on the data network, the storage network was segmented into its own VLAN. By the nature of how VLANs work, this gave the illusion that the storage network was in fact its own layer 2 network. Another important aspect that is vital for storage networks is insuring that this type of traffic never is allowed to leave the physical room that the servers are located in. In order to ensure this practice the VLAN chosen was then assigned a RFC 1918 private address. This ensures that if the traffic would ever be able to reach an internet facing gateway, the packets would be dropped as soon as they hit their first hop out into the internet. In our setup we ensured this step by never defining a gateway for the device since all traffic would only traverse the same network segment.

12 P a g e 11 Architecture In our tests it was determined that this setup was the most secure for the type of network being put in place. By the inherit nature of the design the only devices connecting to storage network were the ESXi servers and the storage servers themselves. And all these devices management functionality were controlled via a restricted access IP subnet, where all connections to/from were monitored and the systems would also log to a centralized logging mechanism to ensure that any changes could be tracked back to the user / changes made. Any physical connections to the corresponding VLANs were also minimized due to the switching environment management access being restricted to the same subnet as the other systems. Dual Virtual Firewall In order to provide the highest level of edge security to our environment, it was determined that dual firewalls be deployed at the network edge and as the main central router of the inner network. This setup was configured that the first firewall would filter out most of the junk that was being sent to our network and only allow the allowed traffic to the inner network firewall. This firewall was also responsible for any DMZ related traffic to and from the internet and internal network segments. In this setup there is less risk associated with outside attacks due to the fact there is the need to penetrate two firewalls in order to reach the inner network. This setup also helps protect against any potential misconfigurations on one of the routers exposing those network segments to outside attacks. For example to test for this type of functionality, all traffic was allowed to flow from the external firewall into the WAN internal firewall interface. The results of this test concluded that even though the outside firewall allowed all connections to the inner firewall, the rules on the inner firewall would need to be misconfigured to allow traffic to potentially be allowed into the private network segment. However, if this was a single firewall, all traffic would have been effectively allowed into the network. Figure 4 Firewall Misconfiguration Port Map Results

13 P a g e 12 Although not tested in our setup, this design can be enhance by introducing two different firewalls from two different vendors. This will help to prevent breaches to firewalls due to security vulnerabilities, since the likelihood that both firewalls would suffer from the same vulnerabilities is low. DMZ Segmentation In traditional network design a singular DMZ is implemented in order to segment those hosts that provide anonymous internet access for those particular services. These services typically include services like , web and DNS systems. This DMZ structure is typically provided by some sort of firewall solution in order to provide the separate segment, as well as control access to those segments. In our test environment a dual firewall approach DMZ design was adopted in order to provide the highest level of security possible as described above. This was designed so that the first firewall would only allow anonymous traffic to the DMZ services that were being hosted within the DMZ. However to ensure the most secure DMZ possible, the DMZ was segmented down further to help isolate the hosts and services that could be exploited if a DMZ host could be compromised. As you can see by Figure 5 the entire DMZ structure was split into three different zones. Figure 5 DMZ Subnets The first zone was our DMZ Mail/DNS segment, which contains any host that hosts those services. DMZ Web is a DMZ Zone devoted entirely to hosting any public facing web server. Finally the DMZ Proxy zone contained any proxy server including the Reverse Web Proxy, also serving as a load balancer and a Reverse webmail proxy as well. Finally included in this zone was a transparent web proxy for all outgoing http traffic in the private client space. Firewall rules located on the first Edge firewall helped enhance the protection that these segmented DMZ provided. For example, it was determined that all traffic destined to the web servers would need to go through the reverse web proxy first. This

14 P a g e 13 allowed the rules on the firewall to isolate the DMZ Web space from the Internet therefore eliminating some of the risks that would be apparent in a single DMZ approach. InnerDMZ/Server/Client Segmentation In a design choice similar to that of the DMZ solutions the internal network was designed to be segmented into four functional levels as depicted by Figure 6. Zone Subnet InnerDMZ /24 Servers /24 Clients /24 Management /22 Figure 6 Internal Subnets By providing a segmented design in the inner firewall as well, there was greater control over to where and who hosts could communicate. This combined with effective firewall rules helped prevent a compromised host from causing too much damage to other machines within the network. For example the InnerDMZ was designed for hosts that communicated with the DMZ (mail, and DNS). This segmentation from the rest of the inner network ensured that any compromised treat would remain in that subnet and not traverse further into the internal network. IP Addressing Scheme One overlooked design mechanism that can do wonders for network security is the type of IP address that is utilized for which segment. There are a total of two types of addresses used. There is the Public address space which is accessible anywhere on the Internet. The other type is the private address space which falls into three different IP ranges; /16, /12, and /8. This gives you a total of 256, 1,048,576 and a whopping 16,777,216 IP addresses to be used that aren t routable across the Internet making them a great choice for networks that primarily used for devices that don t need to allow incoming connections from the internet. In our environment it was determined that the following IP structure, depicted by Figure 7, be utilized to give us the most secure environment that was possible. *NOTE: The ISP used for this project utilizes a /8 private address scheme for its main IP allocation and a /12 private address for a secondary IP address. However in our experiment we treated these networks

15 P a g e 14 as though they were a public, routable IP address. No additional IP address that is located in the /8 or /12 space was used elsewhere in the network to avoid confusion. However this did not affect the outcome of the project and the same results would have been achieved if a true public IP address would have been utilized. Zone IP Subnet Internet (Given by ISP)* /24* - Segmented into a /27 DMZ /24 Segmented into three /27 Outer Inner Firewall Connectivity /24 Inner Network /16 Figure 7 IP Allocation per Functional Zone To ensure that Internet facing services could be accessible, the IP addresses utilized by our DMZ space would be our ISP assigned address ( /24), or a total of 254 usable hosts. Since this address space needed to be split in the following manner; three DMZ subnets, and one for Main connection points, it was determined that the space be split into four equal subnets. To allow connectivity in between the outer and inner firewalls the /24 network space that was assigned by the ISP. This address space was utilized because we needed an address that the ISP knew how to route traffic to. Since we only needed to provide a connection between the two devices, we still have a total of 252 addresses that can be utilized. These addresses were configured to serve as IPs for NAT purposes from the internal network. Finally for the internal network segments the /16 address space was utilized for all connections such as servers, clients, and the management subnet. Since this address space is not routable across the internet, it was required that NAT be put in place on the external interface of the inner firewall. This allows network connectivity out for those internal hosts, making these hosts more secure than their counterparts that are located in the DMZ. Services Mail Relays In order to provide a secure means for our network to receive from other parties not local to our enterprise there is an inherit risk that comes with those

16 P a g e 15 messages. Since is an un-authenticated protocol these messages can come from anyone from anywhere, even though they may say that they came from someone else. With these messages there may be poisoned links and attachments that when executed have the ability to get into the network and compromise security from the inside out. Any all it takes for this to happen is one misdirected click. But there is a way to prevent these attacks, through the use of a mail relay. In our environment a mail relay was implemented to provide the enterprise with three main functions to help keep our environment secure. The first was this host received all incoming messages and performed an anti-virus and SPAM scan against these messages to help filter out the junk mail that is sent to these mailboxes. The second functionality is that this host is used to send all s out of the organization to the internet. This feature helps to ensure that our internal server never talks directly to an unknown mail server, helping prevent any reverse attacks from causing too much damage. Finally this system also allows the ability for two different mail zones to be established, a c com and a c lcl. This ensures that a mail server located out on the Internet cannot talk directly to the internal mail server again insuring that all mail needs to be sent to the mail relay. DNS Relays In order to provide a mechanism for internal clients to resolve network names into addresses, these servers need to be able to resolve DNS records located locally to the network, as well as those located at the ISP and root levels. In order to provide a means to provide a secure solution to resolve these queries, a DNS relay be used in a similar manner as to what was implemented in the mail solution above. By implementing a DNS relay it provides two major security functions that help segment the network down. The first function is the ability to segment our DNS records into two groups one for the DMZ level servers and the other for the internal network. This setup can even be enhanced further by placing the internal network into an.lcl domain name, effectively isolating the internal network. Only those hosts that have a record in the.com domain have the ability to be resolved from the internet. The other function this setup will provide is a hierarchical level of DNS caching. By relaying DNS lookups through the.com DNS server it will store this information so commonly used sites will not have to be continuously be queried, saving that amount of traffic going across your main ISP connection. RADIUS RADIUS was utilized heavily in the network to provide a centralized mechanism for authenticating incoming VPN users against the Active Directory Domain controller.

17 P a g e 16 RADIUS provided a solution to a common problem of having a way to log when a connection was made and who requested the connection and what the outcome of that request was. This was made possible by configuring the RADIUS server to also run RADIUS accounting as well. This data could then potentially be used in the future if a particular change occurred and the IT team needed to learn who was on the network at that time. This information could also be used if the organization decided to charge each user for the provided services. In the environment RADIUS was used to provide authentication and logging for the Client and Management VPN connections. As you can see from Figure 8 these logs provide a long list of information that could be utilized in the future if the needs arise. It also can be used to log any potential failed attempts into the network by unauthorized users. Utilizing these logs, action could then be taken to reprimand that user, or block that user from being able to access the VPN server. Figure 8 RADIUS Log Event Web/Reverse Proxies In order for our network to provide web and webmail services to the Internet in some sort of secure manner it was required that reverse web proxies be implemented into the network design.

18 P a g e 17 In the case of the web services we decided that the reverse proxy would also be able to serve as a load balancer ensuring that a web host is not overloaded, while the other remains idle. This balancer also functions as a SSL accelerator in order to take that latency away from the servers themselves and allow them to instead devote most of their resources serving web pages. The other reverse proxy implemented into our network was for our webmail access outside of the internal network. This functionality allows employees that are not at the office or have access to the VPN, the ability to check their in a limited basis webpage, similar to that of what Gmail offers its users. Since this reverse proxy has access to the server, this proxy should be functioning as an Application Layer Gateway Firewall. However due to constraints and technical difficulty this functionality was not able to be implemented on this proxy. However, by running an IPS sensor on each main WAN interface and each interface on the DMZ segments, the threat of compromising the host is greatly minimized. Client Access VPN In order for clients to be able to securely access the internal network servers and services while outside of the office, a client VPN was setup. This is a great way to provide employees the ability to work from home and to have access to important documents and while outside of the office. However, this can be the easiest way for an attack to be launched against your network. In order to prevent the client access VPN from becoming an easy attack point a few additional security measures were put in place to ensure a high level of security, but not over tax the system and cause user frustration. Although there is not as high of level of security associated with it, a PPTP VPN solution was implemented into the network. This server utilized a RADIUS backend to authenticate users with their active directory credentials. To make firewall rule writing easier the clients were placed into their own virtual subnet. From here firewall rules were placed onto the virtual interface to control where the VPN clients had access to and what resources were available to them while connected. Intrusion Prevention System In order to help prevent intrusion attempts into our network a series of IPS sensors were placed on key entry points into the network. The IPS solution that was implemented was the open source Snort application. Snort came bundled with our firewall solution therefore simplifying the procedures and configurations that needed to occur for snort to be implemented. The following gateways were configured to be an IPS endpoint.

19 P a g e 18 Sensor Interface Sensor IP Address Sensor Device WAN Outer Firewall DMZ Mail/DNS Outer Firewall DMZ Proxy Outer Firewall DMZ Web Outer Firewall WAN Inner Firewall InnerDMZ Inner Firewall Clients Inner Firewall These endpoints were chosen to have sensors deployed on them due to nature of the devices that are connected to them and the risks that are associated with the services they offer and the users that interact with them. For example, all of the DMZ subnets were chosen because these hosts are typically used to gain a foothold into the organization and to serve as a base into the rest of the network. By placing the sensor at the interface, any type of traffic that can be harmful to our network can be stopped and trigger an alert that there is a potential host infected in that zone. Also, a prime target for the sensor was the client network. There is typically limited control on what the user is able to view once they leave for the night and go home. There is a strong possibility that their system could be infected with a backdoor or other malware that will start to spread as soon as it is connected to the network. However before it can spread to the rest of the network the sensor can stop this spread and again alert the IT team to this infection. Management One of the drastic changes that virtualization has brought into the IT sector is the way systems and devices are managed on a daily basis. Instead of having to walk over to the datacenter / server room and physically touch a system, those changes can be made from across the building or even from home by a simple VPN connection. There is no scrutiny of you being who you say you are, no fingerprint scans, no second factor authentication. If you have access to a system, you are basically handed the keys to whatever you want to do with the environment. There maybe system administrators in charge of designing internal ESXi networks because its considered a software feature, when in all reality it still falls upon a network engineer. That is why in my mind, management should be considered the second leading cause of security threats behind the threats cause by the Operating Systems. While there are multiple solutions to help solve this problem for this environment the following three solutions where implemented in order to not only limit who had access to the ESXi console itself, but also ensured there was a mechanism that would allow for segmentation of abilities within the ESXi console itself.

20 P a g e 19 Separate Layer 2 Subnet for MGMT As the IT world we live in today keeps getting more and more complex, there have been advancements that allow us to manage these systems from anywhere we can get access to the Internet, writher that is at home, on the road, or in the middle of a forest with a cell phone. While this makes computer management a job that you could do from anywhere there is a large security risk associated with trying to manage those devices. The risk is even higher if those devices have a global IP address that can be accessed from anywhere in the world. To help prevent these types of threats in this environment two different design mechanisms were implemented to help prevent the Internet and the curious internal user from running across the management functionality of the devices. The first thing that was done to help eliminate this threat was an additional NIC was added to each Virtual Machine and assigned a private IP address out of the Management subnet IP allocation ( /22). This subnet was also associated with its own VLAN across the switching infrastructure to ensure that anyone couldn t just plug in and get into the segment. The gateway of this device is also protected from any Internet traffic due to the nature of the private address space and the firewall the gateway resides on is performing NAT translation, as well as typical access control. Secondly the firewall rules for the subnet were trimmed down to allow no access out to anything or to allow access from any of the other subnets that reside on that firewall device. This effectively allows this subnet to be completely isolated from the rest of the network and gives us our closest ability to say we have unplugged the cord from the wall. To showcase this functionality a Port Scan was ran from within the other three segments that exist on the inside firewall to see if access was possible to the management subnet. As you can see from Figure 9, access into that subnet was not possible therefore creating a secure network from the outside. To make sure that this is secure from the Internet, all outbound traffic is denied on the firewall, therefore only allowing host to host connectivity. Figure 9 Internal Network Port Scan Results Management VPN In order to help combat part of this ongoing need to help prevent users from just stumbling onto the ESXi service console there need to be a way to segment the