CompTIA Network+ N10-008 – Network Management

1. Simple Network Management Protocol

The Simple Network Management Protocol, or SNMP Now, SNMP is used to be able to send and receive data from managed devices like routers, switches, and servers back to a centralised network management station. The SNMP manager is going to be able to send and receive these messages to these devices using three different messages. There are two types of traps: set get and trap. With Set, your managed device is going to send information back to your manager.

Get is when your manager is going to request information from those managed devices, which could be a switch, a router, or a server. And then you have trap messages. Trap messages are unsolicited information being sent from managed devices back to your network manager. Well, this is stuff like uptime configurations and other essential information on your network that is used to do monitoring and detection to detect any kind of unforeseen events or network outages.

Now, there are three versions of SNMP. There is version one, version two, and version three. When you deal with SNMP versions one and two, these use a community string to give them access to the device as their security mechanism. The problem with that is that the default community strings are public read-only or private read-write, and the devices are considered a huge security risk because these community strings are vulnerable to attack. To address these concerns, SNMP version three added some extra security. To address this vulnerability with the community strings, SNMPv3 addressed it. By giving three enhancements, they started adding integrity, authentication and confidentiality.

How did they do this? Well, for integrity, they started hashing messages before they were transmitted to make sure nobody could alter the data being sent from these routers or switches. They began validating the sources of the messages for authentication now. And for confidentiality, they added encryption and started using DESK. 56-bit keys provide confidentiality and privacy. Now, you may remember when we talked about Des before and said it wasn’t very strong, and that still holds true, but it is better than version one or version two. And so by using DE with version three, at least it gives us some semblance of encryption, confidentiality, and privacy. Now, SNMP Version 3 also groups our SNMP components into different entities to increase security. So I might have the network monitoring station (SNMP entity) on the left and the managed nodes on the right. The agent on the managed node can then report back to other agents and then send that over to the managed manager. And if I’m dealing with the network monitoring system, I have these applications that are then feeding into the manager as well. By breaking these into smaller groups, they can then be protected more securely in those smaller groups.

2. Network Logging

Network logging. So another way to monitor our network is based on our network logs. And one of the easiest ways to gather all of these logs across all of our routers and switches and bring them back to a central point is to use something called Syslog. Now our routers, switches, and servers—all of our devices—start getting log information, which they can all send back to this centralised Syslog log server. This allows an administrator or an analyst to better correlate events and see trends. Because not only will I see that there’s some ping sweep going on my firewall, but I might be able to see that the same IP address has attacked one of my servers or one of my clients. There are two primary components to configuring a Syslog server. You have to have the server, and you have to have the client.

The server is going to receive and store the logs from all of its clients. And those clients can be workstations, servers, routers, switches, or firewalls. The client is just the device that is going to send that log information to the Syslog server. Now, when we look at syslog entries, there are different levels of security. We start with zero and go all the way down to seven. The lower the number, the more severe the issue is. So for an emergency, this is the most severe condition. It’s level zero. If you start getting alerts, that’s a level one, which is some condition that requires immediate attention, like a computer that’s running out of disc space. For instance, if you go to critical, that’s level two. This is a less severe condition, but still something that needs to be addressed pretty quickly before there’s an interruption to service. Errors are classified as level three. This is where notifications about errors happen. Now, this won’t break your system, but these are things you want to look into and figure out why they’re occurring. For instance, if you had a login error, that might be here in level three.

Next you have warnings, and that would be level four. Warnings are notifications that specific operations have failed. For example, there might be a file that you’re trying to write but isn’t able to be written. That might be a warning. Next, we have notifications. This is number five, or level five. This is a non-error condition, but still something that the administrator might want to know about. Then you have informational things, which are level six. These are just detailed descriptions of normal things that happen on the system. For example, if you had a successful login, that would be informational. Lastly, we have category seven, which is debugging. Debugging is highly detailed information, maybe even about individual packets that we’re going to use, and is usually used in troubleshooting.

Now, you can configure what level you’re logging at and how long these logs are kept in the Syslog server. I recommend keeping all of the information, but that’s going to take a lot more hard drive space. As a result, some people will not log informational, may not log debugging, and will say anything rated five or lower. Those are things we’re going to log but we’re not going to bother with six or seven because that’s just going to fill up our space. This all depends on your organisation and how you want to do business. Now let’s look at what a log actually looks like. Here is an example from a system log. Here we have the date, the time, and the location, and then we have the log level, and you can see the alerts: emergency, error, warning, notice, informational, et cetera. Then you have the machine, the hostname, or the IP in the next column. You now understand which machine reported this error, information, or warning.

And then you have the actual text of the log message itself that will say that this is a test message or that this is the error that I had. And by having this information and understanding what it is, you as an analyst can start going back and figuring out what the incident is and what’s actually occurred. What about Syslog do you need to know for the exam? Well, you need to understand those levels. You might get asked, “What is level three in Syslog?” and you’re going to have to say error. So make sure you understand that chart. Next, we have logs, and we’re talking about Syslog being a collection of all these logs. Well, what are some of these log types? Well, all different operating systems on network clients and servers produce logs. In Windows, there is a thing called the Event Viewer where you can view those logs.

Now what are some of those types of logs? Well, the first one is an application log in Windows. This is going to contain information about software running on your client or server. It will be an informational warning or error. Those are the three severity levels here. For example, if you have Microsoft Word and it keeps crashing, you might want to check the application log to figure out why it keeps crashing. Next, we have security logs, which are going to contain information about the security of your client or server. This is going to have things like successful and failed login attempts and other pertinent security information. This will be an audit successor audit failure, as that is how they categorise things in the security logs. Next, we have the system logs, which contain information about the operating system itself. And this is an informational warning or error notice. On the screen, we have four errors, and the rest are informational. An error is denoted by that red exclamation mark. Whereas if you have a warning, it’s a yellow triangle, and information is a white circle with a blue eye on it.

3. Remote Access

SFTP stands for Secure File Transfer Protocol, and this operates over port 22 because it does file transfers over secure shell to increase the security. And it’s one that’s used by most organisations today. The last one we have is TrivialFTP, and this operates over port 69. It is the UDP version of File Transfer Protocol, and it sacrifices reliability for efficiency.

Usually, this is going to be used to get configurations or log files from devices if you want to get additional speed. But again, you’re sacrificing reliability because you’re using UDP instead of TCP. Next, we have VPNs. And VPNs are going to permit secure connections to different parts of the network for management or access. We’re going to use things like IPsec, SSL, TLS, and DTLs; site-to-site VPNs; and client-to-site VPNs. With IPsec, we’re ensuring authentication, integrity, and confidentiality. If you want to learn more about IPsec, go back and watch our video on IPsec. This is going to use web browsers for secure VPN connections. Return to our dedicated lecture on VPNs site-to-site and client-to-site with site-to-site if you want to learn more about this. We’re connecting one network to another.

So I might have two management networks tied together or two operational networks tied together when I deal with clients on site. This might be useful. If you’re going to be working remotely from home, you’re going to connect to your management network and make those changes. This allows a single client to connect to the network. Now, all of these VPNs were covered in detail in the VPN, or virtual private networking, lesson. Lastly, we have out-of-band management, which is by far the most secure way to configure your routers and switches.

This can be done by connecting the device using a modem, a console router, or a direct cable like the blue one shown on the screen. This allows for a separation of data between your data networks and your management networks, providing you with additional layers of security. This will require additional configuration and equipment to implement, though. So, if you want to have a management network and a user network, you’ll need two sets of routers and two sets of switches, which will cost you more money. But it is a good practice, especially in large-scale networks where you can’t physically walk to every single switch or router when you want to reach it.

4. Configuration Management

Configuration management. Now, when we deal with configuration management, it focuses on maintaining up-to-date documentation of our network configuration. I can’t count the number of times I’ve gone into a network to conduct an incident response and asked for their diagrams. And the diagrams look nothing like what the real network looks like.

Now, in your networks, you need to have a lot of different procedures. And these will include things like asset management, baseline cable management, change management, and network documentation updating. You can maintain good network configuration management by combining all of these policies. Because if you don’t know what your network looks like, hopefully the bad guys don’t either, because if they do, they’re going to be ahead of you, and you don’t want that. So when we look at asset management, this is a formalized system of tracking your network components and managing the component lifecycle. You need to prepare and budget for those items, and ensure that you gather all the requirements so that you know what you’re going to be buying. You need to plan and determine what components you’re going to buy. You need to design and determine the best configuration for all of those devices. You need to implement it by installing it, purchasing it, configuring it, and putting it into your network. You need to operate and maintain the operations and provide support on a daily basis. And here again, this is where you’re going to spend 70% of your time.

And then you need to optimize it, make it run smoothly, efficiently, and reliably, and improve the network design by implementing new devices and reconfiguring the ones you already have. All of this falls under asset management. Now the next thing you need to do is create a baseline, which means collecting your data under normal conditions. It’s useful if there’s an incident and you’re trying to troubleshoot something. You can say, “This is what normal looks like,” and “This is what it looks like.” Now, what’s the difference and what’s wrong? You’ll never know what abnormal is if you don’t know what normal looks like. And so creating a baseline is really important to your troubleshooting efforts. Next, we have cable management. And this is the process of documenting your network’s entire cable infrastructure. That’s going to include things like your diagrams, how you label your cables, where your punch-down blocks are located, the source of all your different cable locations, and the destination of all your cable locations. Notice my picture on the right here.

This is good cable management. You can clearly see each cable coming out and going into the run. On the left, you can see each cable has been labeled. Each router and switch here has been labeled. As a result, we know which one is which. And this is extremely important when you’re dealing with large environments. Now, if you’re dealing with a small network, like in a small office where you have one router, one switch, and ten computers, Yeah, your cable management is not going to be too difficult, and you probably don’t even need to label it, even though it’s still a best practice. But when you start dealing with hundreds of thousands or 10,000 devices on a network, you really need to understand where those devices are and label every single piece appropriately.

Now, when you label things, I recommend using a standard naming convention. For example, if it’s in the HR department, I would have it labelled HR underscore D, underscore room 102, underscore 0012. Now what does that tell me? This tells me that this desktop computer (notice the letter D) is in the HR department. It’s in room 102, and it’s the 12th machine in that room. Now, if I look at it, for instance, I would see something that says the IT department has this laptop in Room 205, and it’s the fourth laptop. This is a common way to do your numbering by having the building or department give the room number and then the device number, giving it a unique serial ID for every single device. If it’s a switch, I might have an S; if it’s a router, I might have an R; and an F for a firewall, ETCA.

You get the idea, but label everything and make sure your diagrams are updated. Next, we have change management. So let’s say that you spent all this time and all this money building this perfect network. How are you going to keep it up to date? Well, that’s where change management comes in. This is a coordinated system to account for any upgrades, installations, or network outages and repairs. A simple router or switch upgrade can result in significant downtime.

And so we have to pre-coordinate these actions. For example, if I take one switch out and replace it, everyone downstream of that switch will lose access. So I want to coordinate that for the best time of day and the time that will have the least impact on the business. You want to consider downtime, impacts, vulnerabilities, and all of these other things that can be introduced. Because every time you make a change, there is the possibility that something will go wrong. We want to make sure our uptime is going up, not down. And change management is crucial to that. When a change is approved, those diagrams and labels are updated as part of the change management process. So that way, we keep our network fully documented and ready to go.

Next, we have our network documentation. And as I’ve been saying, it’s really important to keep your network documented appropriately. You have to keep these things up to date because when I update a new machine, that changes the network, which changes the topology and the vulnerabilities, and by documenting it, we understand that this is going to include all sorts of things beyond your diagrams. even though we’re going to have things like our diagrams and our wiring schematics. We also want to have things like contact information for our network administrators. Who do I call when something goes wrong? I need to have my policies.

What are the policies that govern my networks? I need to have my network maps and my diagrams. I need to have documentation, such as, “Who are my vendors?” Who do I call when something breaks? Is this item under warranty? All of this stuff is part of your documentation. I’ll have my wiring schematics and, of course, my standard operating procedures and instructions. So if I want to go upgrade my switches, do I have a procedure for that? If I do, that’s going to be helpful for whoever that junior technician is who has to do that at midnight when we’re upgrading that switch. So we’re going to take all of this together and put it into a big binder or a shared drive or a SharePoint site or something that gives us a consolidated knowledge base of what our networks are.