In this chapter, we will put all of the components together and discuss the architecture that can support the scenarios we have covered throughout the book. We will be discussing the following topics:
- Creating the layered architecture
- Integrating decoys and honeypots
- Attacking the cyber range
- Recording the attack data for further training and analysis
This chapter will provide us with a complete architecture that we can use to perform our testing. This design will allow us to plug in any required components that we might have. Furthermore, it will provide you with the capability to test all types of testing that you might need.
As we have discussed throughout the book, the goal of the ranges we create is to provide the capability to hone and improve our skills so that when we go on the site, we have already practiced against as many similar environments as the client might have.
With VMware Workstation, we can take advantage of its capability to create a number of different switches that will allow us to perform a variety of scenarios when we build or test ranges.
Our approach is to create a segmented architecture that takes advantage of the switch options within the virtualization framework. Furthermore, we want to build different types of segments so that we can test a combination of flat and layered networks. We have discussed these architectures a number of times throughout the book. An example of our initial proposed architecture is shown in the following diagram:
A review of the previous diagram shows that we have a number of different architectures that we can explore with our design. The first one that we will discuss is that of a public DMZ; this is created when we have a buffer zone between our internal network and the external Internet. We consider it public as it will be, for the most part, accessible to anyone who wants to use the services that are running there. The location of the public DMZ is between the perimeter or screening router and the Bastion Host that is usually running our firewall software. For our example, this would be connected to the VMnet2 subnet.
An example of this configuration is shown in the following diagram:
The problem with this approach is that the public DMZ is only protected by a screening router and, as such, is at risk of an attack; so, a potential solution to this problem is to move the DMZ.
As a solution to the protection problem of the public DMZ, we can use a private DMZ or a separate subnet DMZ, as it is sometimes referred to. The concept of having a separate subnet DMZ is to provide an extra layer of protection over that of the public DMZ. Furthermore, this configuration also has an added benefit; if communications are compromised in the DMZ, then the only thing that is compromised is the data that is passed in that DMZ. This is not the case in a public DMZ, because the communications between the internal and external networks traverse through the public DMZ, so if anything is compromised in that DMZ, then the data is compromised as well. This is the approach of many sensitive networks like those found in the military where the internal host is air gapped, making it even more difficult to update systems, but isolating the inside from the outside.
An example of this configuration is shown in the following diagram:
As the previous diagram shows, we now have two layers of defense protecting the machines that are placed in the private DMZ. Having said that, there is one disadvantage of this approach, and that is the fact that we are allowing our public services all the way in through our firewall. Consequently, the bandwidth is shared by all the traffic to and from the Internet. We will look at a potential solution to this in the following section.
As we mentioned earlier, with the subnet configuration of private or separate services, we have to allow the traffic into our second layer of defense. We will now discuss the concept of a decoy DMZ. With this concept, we leave the public DMZ as originally discussed, and then, we only place monitoring devices within that segment as we want to configure rules to alert us on any unwanted traffic that is received. For example, if we see any port 80 destination traffic, then we know that it is malicious, and as such, we generate alerts.
Another benefit of this configuration is the fact that we can bind ports inside the firewall for the users and then only bind the bare minimum of the ports on the external interface. An example of this is shown in the following diagram:
An advantage of the architecture in the previous diagram is that the performance of the network tends to improve as the main traffic to and from the Internet is not shared with the traffic to and from the services in the public DMZ. As we have concentrated on attacking throughout the book, we will not cover the advantages from a defense standpoint. However, for those of you who want to learn more, you can check out the Advanced Network Defense course in the Center of Advanced Security Training section that I have created. You can read more at the following link: http://www.eccouncil.org/Training/advanced-security-training/courses/cast-614.
We have covered a number of the different segments for our layered approach, the next thing we want to do is create an architecture that takes a number of these things into consideration. This architecture will allow us to emulate designs that are similar to the latest types of network segmentations that are being deployed within sites that are implementing the latest recommendations with respect to security. An example of this complete architecture is shown in the following screenshot:
As you review the previous diagram, think of ways you can emulate a number of different types of enterprise environments you may encounter. This diagram deploys the popular method of deploying two inline firewalls (Bastion Hosts). Once you have built this range you just connect different machines into the different locations and experiment with the concepts we have discussed throughout the book; furthermore, you can deploy sensors for IDS and pretty much anything that you want to test. An example of some of the machines that you can add to the architecture is shown in the following screenshot:
As the previous screenshot shows, we can set up an entire enterprise range and use it to test any environment that we might encounter in our research, and that is the ultimate goal when building a pen testing cyber range.