The 4G Blog

In this post, I will discuss other methods of securing a network, In particular, I’ll share specific examples we use to secure network access on our firewalls and switches.

Physical Methods

First, of course, we try to keep all network equipment in a locked room, to which access is only granted to those who must have it – the Principle of Least Privilege. From the MDF/IDF network closets, which are locked, cables are run from patch panels to wall ports. Users will only have access to wall ports that we know are in use; we keep unused ports unpatched in our switches, and plastic caps are placed over the switch ports to indicate they’re not in active use. We also place caps at remote locations to prevent users from plugging devices into inappropriate ports on a firewall – a computer plugged into the ISP’s port will cause a complete outage.

Logical Methods

The first method we use is changing the default access accounts to our devices, both by changing the default username (when appropriate), the default password, as well as the default access methods (non-standard ports). We can tell this provides some effect in access logs, where we can see attackers attempting to login to the standard ports with the default credentials.

For our accounts, we also apply the Principle of Least Privilege – different employee levels are provided different levels of access to what can be changed or viewed on the network equipment. While Tier-1 can view some items that may need to be shared with clients (like a wifi password or an IP address), they cannot change anything. Other users may be able to modify certain areas of the network equipment, but cannot change other accounts or security features.

For the actual network traffic itself, we first determine the level of default access. For many client sites, we allow any devices on the network to have access as there’s a limit to what we, as a third-party, can limit. Other areas with more sensitive information limit access to known devices through 1) disabling DHCP, 2) setting up an Access Control List to only allow certain devices to connect (after being set Static IP settings, of course).

The traffic itself is then divided into Zones, depending on where it’s physically or logically connected, and what it should be connecting to. We restrict access between Zones by default and only whitelist traffic specifically via ACL. For example, security cameras need network access, but the access doesn’t need to be complete. We limit traffic to those who must have access to the cameras and block all the rest.

We also place Guest traffic in an untrusted zone that is isolated from everything else. Hyper-sensitive devices, like credit cards, are placed in a highly-restricted zone that is heavily locked down to the bare minimum methods needed.

Finally, even the traffic itself is regulated. Since we use Next-Generation Firewalls (NGFW), we can inspect every packet to determine exactly what its purpose is, and can limit network access not only be source & destination IP, but by application (Microsoft SQL? Our software? Email? Facebook?) and decide if it’s allowed. We can also add features that will reject traffic if the remote destination fails an SSL inspection, and we have features that will block traffic if it resembles a malicious actor. We can also limit traffic based on the country of destination, or limit it to specific websites and domains (either via IP or FQDN).

These are just some of the methods we use to secure the actual network traffic, in addition to access to the network management itself, discussed in another post.

Proper network security is important for multiple reasons – prevention of liability that might arise from secrets, confidential information, or Personally Identifiable Information (PPI) being leaked, as well as prevention of general network instability and losses arising from said instability and delays in network operations.

Security Terms

Network security revolves around several key terms, several of which have been mentioned in other posts. The main terms used are risk, vulnerability, and threat.

A Threat is probably the first thing people think of – a threat is an actor that causes network problems, either an external actor (such as a hacker, ransomware, phishing, or cyber attacker), or an internal actor (such as a disgruntled employee, or possible just someone who doesn’t realize the consequences of their actions). Threats should be identified and some mitigation done (mentioned later) to minimize the potential for the threat to be realized.

A Vulnerability is some flaw in the network or security design that allows an actor (internal or external, malicious or accidental) to cause a problem. A user who doesn’t understand what phishing is a threat; an email system that allows phishing emails to be delivered to users is a vulnerability. Vulnerabilities can be mitigated with best practices, and should be thought of as the doorway through which a threat enters the network.

Finally, Risk is the consequence of a threat exploiting (purposely or accidentally) a vulnerability. In other words, Risk = Vulnerability x Threat. A larger vulnerability, or a larger threat, can magnify the consequences and the risk that can arise – financial, reputational, or other – even in the absence of the other being large.

Audits

Network audits can be done by general staff, or they can be performed by experts in the field. Network auditors will work to identify vulnerabilities by leveraging their understanding of network operations with existing threats. They will utilize knowledge of common vulnerability exploits to find weak points in the network design. After doing this, they will seek to assign possible risks that can arise, mitigation strategies, and assist in implementing a strategy to reduce vulnerabilities, identify threats, and thereby reduce possible risks. An auditor can even try to obtain physical access to network resources to test physical, as well as logical, security.

Logical Security

Logical Security covers methods involving, primarily, software – means to secure the network against vulnerabilities and threats. These can include forms of encryption – commonly, installing network certificates to provide security that resources being used are what they appear to be. Logins can be synced across multiple systems to provide some type of SSO (Single Sign-On) so that more powerful methods of authentication can be leveraged, and users won’t have to remember as many passwords. MFA (Multi-factor authentication) can be used so that, if one type of authentication is stolen from a legitimate user, the login still fails in the absence of a second form of authentication.

Networks can also be designed so that users only have access to the parts of the network needed. VLANs – Virtual Local Area Networks – can be setup so that users are prohibited from access to network resources and other areas of the network that are outside the scope of their job responsibilities. The Human Resources department may need access to network shares and HR software, for example, but they don’t need access to manage the SQL databases behind that software. A Guest Wifi can be set up and logically isolated from the rest of the network so that company guests (or employees’ own personal devices) can have internet access without secure network access. BYOD (Bring Your Own Device) setups can be even more restrictive, and isolate all devices from others.

Principle of Least Privilege

In all of these designs, the “Principle of Least Privilege” should be kept in mind – users should have the absolute bare minimum access required for proper job performance. While it can be tempting to provide “all access” to simplify management, this provides opportunities for an employee to become an internal threat (deliberate or accidental) by leaking access through a vulnerability to a system they should have never had in the first place.

In another post, I will discuss Physical security methods (locks, port disabling, and so on) that can also be used to secure network resources.

In this post, I’ll document various network-related problems I’ve encountered, as well as steps and tools to troubleshoot them.

Common Issues

Loops – a loop happens when, through however many hops, devices, and cables, a device ends up plugged into itself. This could happen when both ends of the same cable are plugged into two different ports on a device, or when a device is plugged into another device twice, or any series of connections that result in a loop. Although STP (Spanning Tree Protocol) is supposed to prevent this from causing a problem, we’ve had limited success simply relying on that.

The problem with loops arises when broadcast information is put onto the network – this is a message that should be received by the device and then sent out on all appropriate ports. The problem is when that broadcast comes back through the loop on the other side – the network device sees it as a new broadcast, and so broadcasts it again. This causes massive network congestion, and in our experience generally comes across as network instability – the connection drops randomly, or is sometimes slow, etc. It can be difficult to track down since it’s an inherently-physical problem that has to be handled in-person.

The easiest troubleshooting is probably to ask, “Was something new plugged into the switch/device, or were any changes made to what’s plugged in?” Occasionally this is enough to find the troublesome cable. Other basic troubleshooting is simply to unplug cables and then plug them back in until the issues comes back. Additionally, cables can be traced – either physically or with a cable tracer/toner (see next post) to see if the signal comes back on a different line. When the troublesome cable is identified it can be removed.

Network port covers/caps can be put into unused ports on a network device to make this harder to accidentally do in the future.

IP-Assignment Issues

This comes in several forms. Two of the more common are, first, DHCP Exhaustion, where there are more devices on the network asking for an IP address than the scope allows, and secondly, Duplicate IPs, where two devices have the same IP. The first can be resolved by lowering the lease time (so disconnected IPs are freed up quicker) or expanding the scope to allow more devices. The second issue, where two devices have the same IP, arises when one (or both) devices are set static – usually when one device is static, but its IP address is within the DHCP scope so it’s assigned to something else. The best way to avoid this is either to make sure static IPs are outside the scope, or (more safely) to add DHCP reservations even for devices that  are static (which has the added benefit of assigning the correct IP if the device somehow loses its static settings and reverts to a more factory-default DHCP mode).

Routing Issues

        Occasionally, an issue arises where a device simply fails to communicate with the destination. This can be caused by a bad subnet mask, where the device has a faulty “understanding” of what its local network is, or it can be caused by routing issues caused either by bad (or missing) static routes, or a Default Gateway that is not actually on the local network. This is resolved by putting the correct information in the device.

Tools Referenced Above

• Ipconfig – this returns the IP information for the device. With the -all flag, it will return ALL information to have a network connection, as well as the device MAC address and other features.
• Ping – this is used to test connectivity to a given IP address. With the -a flag, it will attempt to resolve the hostname of the IP. With the -t flag, it will ping continuously until interrupted, in contrast with normal ping which a set number of attempts.
• Tracert/traceroute – mentioned in a previous post, this will return a list of all IPs encountered between the source and destination.
• Arp – this will return a list of MAC addresses and matching IP addresses.
• Nslookup – this command will query DNS for the hostname of a given IP address.

Physical Tools:

Cable tester & toner – in contrast to the above, these are physical tools used to determine a cable type, length, design, and check for faults and other issues (in the case of a tester). A toner will put a signal on the cable that, when paired with a probe, will return an audible sound allowing you to match one end of the cable to the other.

When troubleshooting a network problem, it’s important to follow the proper troubleshooting methodology before trying to fix something.

Methodology

First, identify clearly what the issue is. Be aware that users may not use terminology in the proper way – “we have no internet connection” doesn’t necessarily mean there’s an internet outage: this could also be caused by DNS failures, or DHCP scope exhaustion, and more – all of which would look like an internet outage. “I can’t start up my computer” would sound like a power/hardware issue, but if by that they mean that they can’t remote into a remote server that is very different from what they said. Therefore, it’s best to SEE what the issue precisely is, either by remoting into the PC or having the user read all errors off and walk through what they’re doing. It can also be important to verify if it’s just one user or all users/devices at a location.

Next, establish the probable theory of what’s wrong. If you can Ping an external IP but can’t Ping a domain name, it’s probably a DNS issue. If the device is getting an APIPA address (169.254.*.*), confirm that the network connection is good. Then check if the DHCP scope is exhausted – there just might not be any IP addresses left to lease to the device. If a user can’t log onto the PC because the domain isn’t available, check the network flow from the PC to the domain controller.

As an aside, I think it’s important to have a good mental map of the entire network flow. Give thought to the user’s inputs, and then consider the flow of data from start to finish and test each step. For a user who’s logged into a remote session and printing via port forwarding to a local printer, if the print is failing, you can immediately rule out an ISP outage – the user is still in the remote session. So consider the flow: Windows Print Spooler to the remote firewall, over the internet (either public or IPSec tunnel), to the local firewall, over the local network infrastructure, to the physical printer. Check if you can ping it locally. Can you send a test page locally? If so, then the issue is between the remote server and the local firewall. If you can’t, the issue is on the local network. Try a known-good cable and/or port. Confirm the printer is on.  The mental model of the packet flow is crucial to troubleshooting this.

(yes this is a common issue with our Tier-1 staff).

Finally, after resolving what seems to be the problem, test that it’s resolved. Aside from pings/etc., the best way is to actually confirm that the initial problem is now working. If so, you’re done. If not, you’ll then need to continue gathering information.

DOCUMENTATION!

Finally, perhaps the most crucial part – document your findings! In the simplest cases (a cord went bad, a connection was unplugged, the printer was offline), simply add a note to check that for the next user. That way something obvious won’t be repeatedly missed because someone thought it was TOO obvious – it’s important to remember that end users can be utterly confused by things that we take for granted within the industry – insider knowledge can lead to overlooking common issues AND create frustrated clients who may feel insulted or belittled or talked-down to. Adding a note to confirm those easy things – possibly even with a comment to the user of, “You may have already checked this, but can you confirm if…” can go a long way.

On the other hand, occasionally the problem is caused by something we’ve done wrong on our end in configuration – perhaps we set a DHCP reservation wrong (or forgot one), or we just have a fundamentally bad network design. In those cases, it’s important to document that as well so that, moving forward, the problems can be mitigated before they arise – and perhaps work can be done to clean up the technical debt of this potential problem lurking at other locations.

In my next post, I’ll give details on some specific common issues & how to resolve and test them.

(Yes, this entire post is written from hard-won experience…)

There are several encrypted ways to access a network remotely, as well as several ways to manage the network itself.

Encrypted Access

We use two primary ways to get a device onto a remote network in a way that seems, to the device, that it’s locally available.

The first of these is through a client-side VPN (Virtual Private Network) application. In our setup, this application features a login username and password and optionally a two-factor authentication method. This account is setup on the remote location’s firewall (either through local accounts setup on the firewall, OR via an LDAP connection to a domain controller handling accounts). After authentication, the client PC is assigned an IP from a dedicated range set aside for SSL-VPN connections. Traffic from that IP block to the rest of the network is controlled via firewall policies. This allows the client machine working remotely to interact with the local network seamlessly (from the client perspective) while the firewall handles the actual routing.

There are two ways to handle the traffic over the client-side VPN – split or full tunneling. In split tunneling, ONLY the traffic that must be routed to the network – file shares, authentication, and so on – actually travels over the tunnel. In full tunnels, ALL traffic flows over the tunnel. While this does increase network traffic over the tunnel itself (which can reduce network throughput), for security reasons it can be advantageous to have all network traffic flowing through a secure tunnel to a remote location which reduces tracking and monitoring on the client side.

The second method to connect networks is via site-to-site VPN. In this setup, instead of individual devices connecting to the remote location via a device-side application, the two firewalls themselves are connected using native features (in our case, encrypted IPSec tunnels). The firewalls on each end handle the routing of traffic via subnets, and again the devices don’t see it as separate networks. In this setup, ONLY the traffic that must flow to the other network does so, the rest is handled by routes on the local network. The advantage with this setup is that individual devices don’t require any extra applications or work for the users. The downside is that, without deliberate security applied, any device on the network can reach the remote network as well if it attempts to do so.

Network management connections

We use three methods to manage our networks, although two function in practice very similarly.

The first is the GUI – the Graphical User Interface. The GUI is a manufacturer-provided visual system for making changes as needed. It’s a webpage hosted on the device itself that allows most network changes to be made, and while easiest for beginners since the information is laid out fairly intuitively, exposing ALL features would make it overwhelming, so more advanced features aren’t, by default, visible on the GUI.

The second method is via the Console – this is a text-based management method using a manufacturer-provided domain language to code the devices themselves. While it exposes all features, it does require learning the command line code to take full advantage of it. The console is only available when logged into the device itself.

The third method we use is SSH – this is also a text-based connection method, detailed in an earlier post. Once connected, the Console (method 2 above) is exposed to a remote connection and can be programmed as normal.

I’ve come to prefer the console, as it allows a lot more automation than the GUI. Since all GUI methods involve mouse moves and clicking, it’s harder to automate. With the console/SSH connection, programming and reconfiguring can be done via copy/pasting of commands which has allowed me to drastically speed up network device configuration (from hours to minutes).

MDF & IDF

The “heart” of the network at a facility is the MDF – the Main Distribution Frame. Although most facilities we work with only have the MDF, some will occasionally have an IDF – an Intermediate Distribution Frame. These are the rooms at a building where the hub of a network equipment is.

In the MDF, the external circuit from the Internet Service Provider (ISP) generally come in and is plugged into the firewall. This is the Demarc zone for us – the ISP is responsible for their equipment being setup and configured properly and plugging into our firewall, as well as everything “behind” that (that is, on the outside). We’re responsible for the firewall and everything “inside” the network.

At smaller facilities, the MDF is the only network room. It will have the firewall, ISP equipment, switches (for larger facilities), any servers and other computing hardware, and the patch panels. The patch panels are outlets where cables will run from the networking equipment into the panels. From the back of the panel, more permanent wires run into the walls/ceilings/other plenum spaces and throughout the building to wall ports around the facility. Those wall ports will, in turn, have the client devices plugged into them.

Larger & multi-story or multi-building locations will have an IDF per floor or building. The size of this varies, but it’s usually a smaller version of the MDF that will only have the switches and patch panels. These are connected back to the MDF typically by fiber cables which can handle the larger distance and higher bandwidth needs that a single Ethernet cable can’t. We generally run fiber through underground conduit. From the IDF, the patch panels and permanent cabling function the same.

Physical Security

Both of these rooms – the MDF & and IDFs – should have locks on the door with access limited to those who need access. We have uncounted numbers of issues where end users attempt to troubleshoot a network problem OR “tidy up some cables” and bring an entire facility down.

Network Racks

As much as possible, all of the networking equipment and servers are mounted into a rack – a large cabinet with mounting brackets following a standard size. Racks are measured in “U”s, with a U being a standard Unit of measurement for equipment. Equipment is  measured in U’s – a switch is 1U, whereas a large server may be 2, 3, or more U’s.  One side of the rack is designated the intake, and the other side the exhaust. The intake is the “cold” side where air conditioning provides cooling, while the exhaust is the “hot” side and is shunted away from the equipment to keep it from overheating.

Environmental & Power Consistency

In addition to environmental monitoring via air conditioning, as well as dehumidifiers that maintain a certain range of humidity (too much can cause moisture accumulation, while too little can cause static electricity buildup), consistent power is important. All equipment is on some type of Uninterruptible Power Supply, a battery which will kick in the moment power to the facility is interrupted. A PDU – power distribution unit – functions like a high-quality “power strip” which can include additional features like network monitoring and the ability to toggle individual power ports. For mission critical facilities, an outside gasoline generator is installed for longer outages.

Summary

This concludes a brief look at the physical network facilities. Power backup & strict environmental monitoring provides a good room for the rack-mounted network hardware to function. From the MDF hub, IDF spokes provide network access to more remote facilities. Proper physical security restricts the ability of uninformed or malicious actors from bringing an entire facility offline.

Routing is the method whereby a network packet travels from one device to another. There are several ways routing is setup – dynamic vs static – as well as different ways for the router (the device doing the routing) to determine which route is best.

Why Route

First, as a quick refresher, routing through different gateways is really only an issue when a network packet needs to get from one network to another – if the source and destination are on the same network, there’s no real need to route it to a different network, obviously. The way a device determines how to send the packet is by comparing its IP Address and Subnet Mask to the IP of the destination. The Subnet Mask is essentially a formula applied to its IP address to determine what other IPs are part of the same network. If the formula determines the destination is outside the network, the sender will then route the packet to the IP address set in its Default Gateway, which is responsible for routing the packet appropriately.

As an aside, this is why I remind our tier-1 folks that packet will never get where it should if the IP address, subnet mask, and default gateway aren’t defined properly. That’s the bare minimum for a DHCP or static device.

Routing Methods

There are two ways that the routing table is filled – static or dynamic. At work we tend to define everything manually (static), as it gives us control over exactly where the traffic flows. The downside to this is that it takes a lot of work – every route must be manually defined.

The alternative is to let the routes be determined dynamically – the work of building the routing table is handled by the actual router as part of its functionality. But obviously this removes some of the advantages to manually-defining the routes.

For the most part, we statically-define the routes at a high level (specific subnets are defined manually, and the rest is handled by the router).

Distance and Metric/Priority

The router may occasionally find itself with multiple routes – how does it know which to use? This is where Administrative Distance and Metric/Priority come in (I use priority as that’s what our hardware uses, instead of Metric).

Generally, this more attractive/faster route has a lower number than worse ones. This can occasionally cause confused when a “higher” administrative distance can either mean a higher number (which will be less prioritized) or it can mean a higher-priority (use this!) which is a lower number. So 0 is a higher-priority than 10, though 10 is higher than 0 numerically.

Administrative Distance is mainly used when different Routing Protocols are in place. For example, something may be plugged directly into the router – this would be more ideal than something that spans across multiple networks. A Static Route (defined manually) also usually has a lower distance than other methods like RIP, OSPF, etc. The Administrative Distance is set to determine which routing methods are preferred.

The Metric, on the other hand, can be thought of as “how hard this route is” for routes that use the same method. If multiple static routes are set, the metric/priority is used to determine which ones should be preferred. On our hardware, since we primarily use Static Routes, we leave Administrative Distance alone and only change the Metric (called Priority on our systems). This again can introduce some confusion, as a “higher priority route” has a lower number than a “lower priority” route.

No matter how secure and well-planned a facility is, there will eventually be some issue that requires recovery operations. These plans should be formulated beforehand so that the time of recovery is restricted simply to following the plan, rather than having to figure out what to do.

Foreplanning

The first part of a disaster recovery plan is to determine what the most likely problems are, and how severely they will affect the functioning of the facility. A common way to determine this is via various metrics, such as

• How long can a network outage be sustained? All outages will impact functioning, but facilities that require constant network connectivity to function and that will lose large amounts of money while being down should be treated differently from a facility for which an outage is a mere inconvenience
• How long will it take to get a facility back online for various outages? What is the cost of this downtime?
• How often can outages be expected? Certain areas are more prone to ISP outages and other  types of problems than others. Our more rural clients are used to outages that our big city clients would never tolerate.

These, and other, criteria should be used to formulate a plan that takes into account the most likely problems, the most expensive problems, and the problems that will be the most difficult to mitigate. All of this will combine to determine the best plan of attack in case of emergencies and disasters.

DR Sites

Disaster Recovery Sites come in several different “flavors” – cold, warm, and hot. These relate to the amount of time it will take to move operations to the new site. A “cold” site is available, but will take some time to get setup – perhaps equipment will have to be physically relocated to it, or an ISP-circuit will have to be activated. A “hot” site is, essentially, always ready to go and take over operations. A warm site sits between these two extremes.

Obviously, there is a tradeoff between mitigation time and expense with regards to the type of plan to implement. For our smaller clients, their version of a “cold” site involves us configuring and then shipping/delivering replacement equipment, which can take 1-2 days. More mission-critical clients will have a hot site – there is redundant equipment available in a second location that just needs to be configured to handle the workload. Often, this takes the place of virtual machines and other cloud appliances that just take some DNS updates to begin routing the traffic to them.

High-Availability

Our typical HA approach uses dual firewalls, wherein one is a clone of the other. We also have dual internet circuits running into both machines, with a setting on the firewall designating one firewall as the primary and the other as the HA secondary. If the primary firewall fails, the secondary will begin handling traffic within seconds. If one of the ISP circuits fails, the other will almost immediately begin handling that traffic.

Downstream from that, we have dual switches running into the physical on-prem servers dual (or more) ports; if one fails the other will handle all the traffic.

If the physical machine fails, we can route traffic through the cloud virtual machine (which can be cloned & duplicated from backup if that fails as well).

We haven’t had any equipment failures, fortunately, and ISP outages are handled by the equipment with no interaction required from us. The only disaster recovery we’ve had to use is from power outages, which, if the batteries & UPS begin to alert low capacity available (we have about 1.5 hours battery time), we can manually switch the flow from the primary power circuit to the generator (which will automatically turn on in a power outage).

Testing

Testing is our weak point – our guaranteed uptime is 99.999%, and unfortunately our contract does not make any distinction between testing, actual disasters, software or hardware upgrades. So our 0.001% downtime is almost always consumed by software updates & reboots. But when disasters have struck our DR plan has functioned well. In an ideal scenario, user buy-in would allow testing and even encourage it, as planned downtime is better than unplanned.

In this article, I’ll discuss the IP address space, and the different classes (A-E) as well as the difference between public & private address. I’ll focus on IPv4, as it’s still the primary version the US uses (and all I use at work). Therefore whenever I discuss “IP” below, I’m referencing IPv4.

What is an IP?

First, an IP address is a series of 4 numbers ranging from 0-255, separated by dots. A few IPs are 172.31.9.12, or 8.7.6.5, or 192.168.1.11. Each number is a decimal representation of a single byte, which is a series of 8 bits that are either a 0 or a 1. So a byte, written in binary, may be 11001001, which is 201 in decimal. See the Wikipedia article on binary for more details on binary. The basic purpose is that a computer can only understand numbers – in this case, 0 or 1, which correspond to “an electrical signal is present (1) or not (0)”.

So, an IP address is a series of numbers used to indicate the network address for a device (which may be hosting a webpage, or an app, or a database, or something else).

Public vs Private Ranges

Each IP space within a class is designated public or private. Public IPs are used for internet-facing devices, while private IPs are used within internal networks and cannot be routed over the internet.

Subnet Masks

The “size” of a network is determined by its subnet mask (references in an earlier blog post). This is another 4-digit number, like IP addresses, although it’s used differently as it must be an uninterrupted series of 1’s before an uninterrupted series of 0’s finishes it.

The  first three Classes of networks (see below) have different subnet masks. Each subnet is a tradeoff between network size (how many devices can be on this network) and how many networks there can be. Class A has the largest number of hosts per network available (about 17 million) but the fewest possible number of networks (126). Class C has the smallest number of hosts per network (254) but the largest number of networks available (about 2.1 million). Class B is in the middle with about 66,000 hosts per each of the 16.3 thousand networks.

IP Address Classes

The IP address space ranges from 1.0.0.0 – 255.255.255.255.  Not that 0.0.0.0 could technically be used, I suppose, but would have routing issues since it’s all 0’s. The space is then divided into 5 “classes”, which have different purposes. Additionally, in general usage, each subsequent space is smaller than the ones preceding it. So a Class A space will be the largest networks, while class C-E are the smallest.

Classes A, B, and C have designated private scopes, which each subsequent class having a smaller number of IPs available to the private network.

• Class A – 1.0.0.0.-127.0.0.0 (first Octet [number] ranges from 1-127)
  • The private range of this class is 10.0.0.0-10.255.255.255. This is the largest class available for private/non-internet facing networks.
• Class B – 128.0.0.0 – 191.255.0.0 (first octet is 128-191)
  • The private range in this class is 172.16.0.0-172.31.255.255.
• Class C – 192.0.0.0-223.255.255.0 (first octet 192-223)
  • The private range in this class is 192.168.0.0-192.168.255.255. This is the most common private IP range in home networks, and is probably what your home computer is using now.
• Class D – 224.0.0.0-239.255.255.255 (first octet 224-239)
  • This is a special range – it’s used for multicasting, wherein a host broadcasts data to a bunch of other hosts over the internet.
• Class E – 240.0.0.0-255.255.255.255
  • This is another special range and is not used (aside from personal experimentation or research).

You may notice that Class A ends with 127.0.0.0, but class B starts at 128.0.0.0.  The range in between those – 127.0.0.1-127.255.255.255 – is used for internal network testing. The prime example of this is 127.0.0.1 which is usually interpret by a computer as referring to itself. This is the “localhost”.

DHCP

The most important network service to setup is DHCP – Dynamic Host Configuration Protocol. Although the network information can be manually configured on each device  – a “static” connection – the device will immediately stop working if there are any changes to the network, or if the device is taken to a new network. For this reason, devices can be set to “DHCP” mode, in which they will send out a query on the network requesting a Configuration.

The designated DHCP server (in most cases on our firewalls, although an actual server still exists at some locations) will reply with the key pieces info information:

• An available IP address for the device
• The subnet mask for the network (so the device knows if an IP is on the same network or not)
• The IP of the Default Gateway (so the device can route network traffic to that if the destination is not on the same network)

There are additional DHCP settings that can be sent (like the local domain of the network) but those aren’t required.

The DHCP server is responsible for handling its Scope (the IP range that can be handed out, and which should be within the subnet mask), the lease time (how long to keep an IP held for a device that may not still be on the network), and other options. It can also serve as a Relay if there are other DHCP servers on the same network.

Additionally, some IPs should ALWAYS be given to the same device, even if it’s offline and outside the lease time. For those, a DHCP reservation is created, where the device’s MAC address (a globally-unique ID for all pieces of network-capable hardware) is used to make sure that the IP is ALWAYS given to the device and NEVER given to anything else.

DNS

The second most important network service is DNS – the Domain Name Service. As mentioned in an earlier post, computers only know numbers (binary 1’s and 0’s but expressed to humans as IP addresses), whereas humans are better at remembering domain names – google.com, facebook.com, etc. The DNS server is responsible for translating IPs into domain names, and vice versa. DNS is an older protocol, so like others, it has more modern versions with additional security and encryption features, such as DNSSEC and DoH (HTTPS) and DoT (TLS).

Smaller & more local DNS servers will pass the request up the chain, but eventually some server has to be the official Authoritative source for a DNS entry. When managing a domain name, YOU are managing the Authoritative Nameserver, so DNS Records must be added. There are many record types, but the main ones are

• A (and AAAA for IPv6) – returns an IP address for a given domain name
• CNAME – Canonical name. returns a different domain name for a given domain name (used, for example, if your private email address is actually hosted by a larger company like Office 365)
• MX – mail exchange. Returns the A record (required) of the servers that will handle email for the domain.
• TXT – text records. Used for many things – domain authentication, email authentication checks, proof of domain ownership, and more.
• NS – NameServer. The official source for DNS records
• PTR – Pointer. Returns the CNAME for a request. Most commonly used in reverse DNS lookups to determine what the domain name is for a given IP address.

In addition to querying a DNS server, a device can also have a hosts file. This is a file on the device that will keep hardcoded DNS entries if, for example, you want to specify DNS records without having to run a server at all.

NTP

The Network Time Protocol is used by devices to keep their clocks synced to a central authority. We try to avoid using this and just let devices sync to a central authority online somewhere.