Secure Network Topologies – CompTIA Security+ SY0-501 – 3.2

When you’re building a network, you can make design decisions that can provide additional security. In this video, you’ll learn about designing secure network topologies.

<< Previous Video: Defense-in-Depth Next: Network Segmentation >>

At home, your network is probably one single subnet, and one device has exactly the same access to all of the other devices on the network. But in the Enterprise, we’ve built secure network typologies so that we can maintain the security of all of our IT systems. One type of secure typology that we built is DMZ, that stands for demilitarized zone. It’s a military term that describes the midpoint between two warring factions. In this case, the two warring factions would be the internet and you. You’re trying to keep all the bad guys from getting to the inside of your network, but you also want to be able to provide services for your customers. So the IDMZ is a perfect middle point. People coming from the internet can access the DMZ and all of the resources that might be stored in that DMZ, and anybody coming from the internet would not have access to the internal network when they’re accessing those important resources.

In many networks we have third parties that we trust, and we need to provide them with access to resources on the inside of our network. For those third parties like vendors and suppliers, we create extranets. You can think of an extranet as a private DMZ. This extranet would not be on the internal network, but it would still provide access from the internet. And anybody who’s accessing the extranet would need to provide the correct authentication credentials to be able to gain access to those resources. A type of network typology that is only available from the inside of your network, is an intranet. This is one where you might put important resources in the center of the network, and it doesn’t matter if you’re at headquarters or one of the remote sites, you’re able to access those resources. These would be things that would be for employees only like company announcements and important internal documents. There is no access from the outside into this intranet. If someone did need to gain access they would need to be an employee, they would generally connect to the internal network with their VPN client, and only then would they have access to this intranet.

A wireless network at work is very convenient, but it does come with some significant security concerns. That’s why most people will build out an internal wireless network, and if you do need access for guests you would usually build out a separate wireless infrastructure just to be used by guests. If someone needs access to the internal wireless network we would always require some type of authentication. It’s common to have people use their normal network login credentials using the 802.1X standard to provide that authentication into the internal network, and it’s probably integrating with some type of existing name services. That way when somebody leaves the organization those credentials are automatically disabled. It’s important here that we’re not using something like a shared wireless passphrase that would be shared by others who need access to the wireless network. For something like an internal wireless connection, you would always want to require some type of authentication.

There’s a lot of good reasons to provide guest access to your network, usually in a conference room where there are meetings or demonstrations, people need to connect and provide access to the internet. It’s common to design these networks with access to the internet and no access to the internal network. If somebody is in this meeting room and they need access to internal resources, they would use their VPN client and normally authenticate with their credentials. If you wanted to add another layer of security for the guest users you could integrate a captive portal and require that all of your users obtain a username and password to gain access to the network for the day.

But of course an access point is not required for wireless communication. You can have two devices connected to each other directly using ad hoc wireless networking. We commonly see this type of ad hoc wireless connection with applications that transfer files, such as AirDrop or contact sharing applications. But it’s difficult to manage if you have people that are connecting directly to each other. In those cases, you may want to configure your Mobile Device Manager to either allow or disallow this ad hoc functionality. Your Mobile Device Manager might allow you to set parameters on this ad hoc usage. It might require credentials that you log in before you can use the ad hoc functionality, or maybe it’s only used for certain applications on your mobile device.

Some organizations will use honeypots and honeynets as a way to watch what the bad guys are doing. These are virtual systems that are designed to look very attractive to the bad guys. Most of the time the devices that are hitting your network and looking for anything that might be open are scripts and automated processes. These honeypots and honeynets are designed to track what these automated processes are doing and provide you with more intel about what the bad guys are looking for on your network. We traditionally think of a honeypot as a single use or single system that someone may be trying to gain access to, and a honeynet would be a larger group of honeypots that are all connected together. If you’d like more information on honeypots you can read more about it at

It’s estimated that there are over 20 billion devices connected to and communicating across the internet. But of course, our IPv4 addressing system can only support 4.29 billion addresses. There is no more address space in IPv4 that we can allocate for new systems. So how are we able to have 20 billion devices communicate using protocols that are designed for just over 4 billion devices? We are able to accomplish this by using NAT, or Network Address Translation. This conservational IP addresses isn’t the only use of network address translation, but it is something that we often use to be able to minimize the impact of this IP version 4 shortage. Network address translation, in itself, is not a security mechanism. It’s simply a way to convert from one IP address to another while the traffic is going through the network.

Some people think that if you’re hiding what your real IP address is that this provides some type of security. But in the security world we call this security through obscurity. Just by hiding something doesn’t actually make it more secure. In fact, as we’ve seen with NAT, it doesn’t provide any security at all. The bad guys know how to get around Network Address Translation, and if there’s no other type of protections in place it’s very easy for the bad guys to gain access to our internal systems. In most cases, we often see Network Address Translation combined with a stateful firewall. In those cases, it’s the firewall that’s actually providing the security mechanism. The Network Address Translation is just a mechanism to get traffic from one side of the network to the other.