350-701: Implementing and Operating Cisco Security Core Technologies Certification Video Training Course

350-701: Implementing and Operating Cisco Security Core Technologies certification video training course by prepaway along with practice test questions and answers, study guide and exam dumps provides the ultimate training package to help you pass.

Cisco Telemetry Services

1. Cisco Telemetry Services

Okay, now in this video we'll discuss some of the multiple methods used by the administrator to monitor network activity. Because as an administrator, it's important for you to monitor the input activity and ensure that the network is up and running. So if any device fails, you probably need to get some alerts and reports, and based on that, we can troubleshoot.

So probably in this section we'll talk about some of the multiple options that we'll be using to do all these jobs and commands. We call it "telemetry methods" or "traffic." Telemetry methods: it's a word derived from the Greek roots where "Dele" stands for remote and "measure" is nothing but monitoring or calculating. So it's very important for the network administrator to detect what kind of traffic is actually moving into a network. If you find any unusual network traffic, like malicious traffic going on the network, you can monitor that and take appropriate action to prevent some kinds of attacks.

Also, if any kind of device fails, you need to get some alerts or have some information about the device for you to fix it if you get the information that the device is powered on. So there are multiple methods we'll be using here, like something called NTP. So NTP is an abbreviation for networks and protocol. It is primarily used for all devices that share a synchronised time because dates in time necessitate accurate and synchronised time across all devices. As a result, we will enable NTP, a common method of time synchronisation between networking devices. And apart from that, we are using something called SNMP or SNMP traps. Probably the SNMP feature allows you to monitor the securitization of the device, the memory utilisation of the device, or maybe the interface bandwidth—multiple things.

And these statistics can be filtered by the Snmb server, and based on that information, you can actually monitor the device status, the connectivity, and many other things. And also, we'll be engaging in something called logging. So logging is a feature that allows us to keep track of the events and changes that occur in the network.

We can specifically log and instruct the device to send log messages if any of the topic matching or incidents occur, such as the interface going down or the Eager neighborhood going down, or something similar. Apart from that, we can also use some other features, like Netflix. Netflix is a method used to collect network traffic statistics, and we can export selected traffic to some NetFlowcollective software, and based on that, it's going to give some statistics in a graphical way. So all these options are collectively referred to as "traffic elimination methods," and using these methods we can ensure that the network operates and is always available.

2. Device- Network Events Logging

So network devices by default generate log messages, and these log messages can be used to keep track of the events or changes occurring in your network. As an example, if I go to the command line whenever you make any changes, I'm currently in my device's console screen. So this is my console screen, let's say. And whenever you make any changes on this console screen, for example, if I try to shut down one of the interfaces, it is by default in upstate. So whenever you shut down the interface immediately, you'll see some messages appear here. This is an indication that this specific portfolio as one has been insured with these options on this date and time. And whenever I bring the interface up again, the interface comes back, and you see some messages here.

So like that, you'll see different types of messages in general on the console screen by default. Now these messages are typically referred to as "log messages," and these long messages are automatically generated. By using these messages, we can keep track of the events occurring in your network. Generally, some of the log messages that help us are like device failure notifications, like when you get a router and one of the interfaces fails or goes down, which is a log message. Or it could be another type of message, such as when you connect to a router and try to establish the EHRP neighborhood, and the neighbourhood fails, generating a message; or when you connect to a service portal network and have some BTB connections, and the neighbourhood fails, generating a log message in general.

Or you can also use specific log messages. For example, I can go to the router and configure the ACL to match a specific traffic pattern, and I can tell the router to generate log messages if any traffic matters, that particular pattern, which can be used for auditing or even troubleshooting. It's also useful if you have a router problem, such as when the neighbour ship goes down and the neighbour ship flails, or when the VPN fails to connect, something isn't working properly, and you just want to see what's going on in the back end. So we can enable the logging for the debug messages, and then we can see the back-end messages and what is going on in the back end. So there's also another reason for generating the log messages and keeping track of them.

And of course, you can also use it for foreign analysis, like for some kind of incident investigation. So let's say something occurred in your network, maybe some kind of attack, and you want to see some of these previous log messages that are generated on this particular device, where we can trace the victim and attacker and determine at which point it actually occurred. So we do enable some logging messages. Of course, the device generates some log messages to some extent, and we need to keep track of those messages for multiple reasons. We now have logging options such as console logging (VDI), a local buffer, and an external log service. Console logging is used whenever you connect to a device, such as a router, using a console cable.

Of course, I'm using GNS 3 to connect. But by default, when you open up the console, it's almost like a console connection here. As an example, suppose you connect your router to a physical console port and access the router through the console port. And by default, logging is enabled on this particular port. And whatever changes occur in your network will be displayed by default on the console port. But by default, these messages are not saved in general. So the console logging is by default enabled in all your router's features, and by default, they send the log messages to the console port, as I just discussed. And hence, only the users who are physically connected to the router console port can view these messages. So if I'm not using the console, I cannot see these messages. So the console access is currently on the router one. Now, by default, these messages are not saved.

For example, even if you try to enable some kind of debug messages in the back end, you will see some kind of debug messages in which hello messages are sent every 5 seconds. So those messages will also be displayed if you enable debug messages by using debug EHRP packets in production. It is recommended to enable console logging because a large amount of logging messages or outputs occur while in a debug process and are sent to the console. So a large amount of log data is sent to the console. By using some debugging, it will increase the necessary CPU load on the routers and can actually impact the control plane. Also, because it can prevent routers from forwarding packets or establishing the control plane. Or maybe it loses some kind of neighborhood. Issues may arise if the router receives too many log messages.

As a result, it is recommended to disable console logging because, in most operational networks, consoles are rarely used because we usually access a device via telnet or SSH from a remote device. And we only use console if there are any major issues, such as performing a password reversion or being unable to log into the web line, in which case you may need to troubleshoot a connectivity or other issue. So most of the time we don't use the console. So it's recommended to disable the console messages by using the no-login console.

So I can simply say "no login console," which is by default enabled. So once I disable this console, if I try to make some changes on the network, let's say my interface goes down, and as you can see, I don't see any log messages displayed here. Now, the other option in the console is that you can use something called buffer logging. In the case of buffer logging, whatever the log message is that is generated, we can tell the router to save these messages in the local buffer memory or the local RAM.

As a result, this type of log makes use of the router ramp to temporarily store log messages. And we can specify the buffer size—the number of bytes—as well as how many bytes should be used to store the log messages. So the buffer is nothing but the fixed size that we are going to allocate to generate the log messages, and the router is going to delete the old messages once it reaches the maximum size.

And let's say the router is receiving the log messages. Anything beyond this amount of memory would be allocated automatically. It will start removing the older entries. Now, buffer logging is by default not enabled. We can enable this by using a command called "log buffer." And if you want to verify the log messages, we can use something like the "Show login option." So let me just quickly enable this buffer logging here.

So in the previous step, I disabled the console login, so I'll try to enable the console login because at this point in time, I want to see the log messages in the logging buffer. And we can define what the buffer size is that you want to look at. Let's say I'm using just 4096, and if you want to verify, I can try deleting some messages, like I'll try to shut down the interface, and then I'll say no shutdown.

Also try to shut down one more interface, let's say "s one by zero," because on the router one, "s one by zero," interface, I'm connecting with router two and I have preconfigured EHRP here. So most likely, if I shut down the S-1 by Zero interface, I should also see that go down here. I think I didn't configure the EHRP. So I don't have EHRP configured. I simply don't have it. So you probably see the messages here; the interface has changed down; I'll make a backup, and now if you want to verify these log messages, we can use the showing logging option.

3. Syslog - Terminal Logging

The next logging option is something like Syslog Server Logging. In this option, we are going to tell the router to send those log messages to the external server or the external computer or PC, which is going to run some application called Syslog Server applications. So, of course, the log messages will be generated by the router.

So whatever the case, the log messages will be exported to some external device. Now we're going to run some external software, which will show you all of the log messages, as well as the date and time they were generated. Of course, if you're using some licence programs, you will have more options to log in again. So by default, this logging is not enabled. We need to login, and we need to enable this syslogging by using a command called Logging Host. You need to go to the login host, and then you need to tell it the IP address of that particular device. So you can also do the same thing on the router too, but make sure that from the router, you have reachability to this particular device that is routing reachable. Of course, in the production networks, we do have routing configured to provide readability between different networks. So I'll show you this option here. At this setup, I'm using my physical computer, which is using some software called Tftbd.

It's a free open source tool that I obtained from the internet. So here we need to select the appropriate interface. The first step is to select the syslog server because I want to use the syslog server application here and connect to the correct interface, which is your GM history. So in my scenario, I'm connecting this VM network to interface two, and it is using the IP address 110. So once you select the correct interface here, I can go to my router, and I can configure the router to generate the log messages. So I'm going to say simply "logging host," and I want all the log messages to be sent to the PC here. So you can see that some messages are appearing right away.

Whatever the message you see here—the same console message—it shows up here. And let's say I'm going to make some changes here. So let's say I'm trying to shut down this interface, and I should see the interface change to down. And again, I'm going to bring the interface back up. And you can see whatever log message is generated here automatically, the same message you normally see here, the production tools. You can use some kind of licence too. So with the licence to use, you will have more options to filter the log messages because in the production network, you have hundreds of devices, and maybe some of those devices send the log messages to a single server. As a result, you can filter those messages and see when they occurred.

And also, you can filter based on the date and time to see the actual events happening on the record. So based on these messages, you can at least come to know that this interface has been changed to "down" by some administrators. So Syslog is commonly used in production scenarios because you generally want all the log messages to be sent to the external server, where you have enough memory to save all those log messages. Now, the last option of the log messages is like terminal logging. Terminal logging is the equivalent of console logging. The only difference is that console logging is enabled by default, whereas terminal logging includes everything done from the VDP line. So let me take an example here. I'm going to use you to initiate a tenant connection to the outdoor one from your PC. I'm going to open the connection on port 23 and, I believe, enter the password.

So now I can see that this is my video line. And whatever you see on the screen is my console output. The screen is like my console, the one that I'm using here. And this is my video line. So most of the production networks use BTW lines to log in. Let's say I'm going to make some changes on the Internet. Let's say I'm trying to shut down. Of course, you can configure some EHRP and verify the neighbourhood and other things. And whenever I make any changes, you can see that it generates a log message. Of course, this log message is shown on the console screen. You can also see it on the syslog server if you have enabled the syslogs, but you don't see them on the PDF because by default the logging is disabled here. So, for the most part, we access the device remotely during the process. And whenever you are making any changes, you always want them to see them. If you're trying to configure some EHRP, you expect the neighbourhood to appear, or if you're making any changes to the interfaces or anything, you'd like to see these messages, some basic information messages. Now, for that, we need to enable the terminal pointer command.

So once I give the terminal point of command, if I make any changes, I'm going to bring the interface up. I can see the messages are displayed exactly the same way as you see them on the console screen. For most of the production network, it's recommended to disable console logging by using the no logging console command because, most of the time, you don't do anything on the console because most of the time we use Btwline. And we can enable this default logging, which is disabled, by using the terminal point of mine.

4. Network Time Protocol

NTP stands for "network time protocol." It's a protocol that allows you to have a common, synchronised time between the networking devices. Because when you're implementing a network, all the devices must have a common synchronised time. because there are some other services that are dependent on having a common time.

For example, you must have an accurate closing, which is required for accurate timestamp logging. In the previous sessions, we configured something like the Silog service, and all the devices sent log messages, whatever the log message is generated. As a result, these log messages can most likely be used to keep track of what is going on. Now it actually shows you the details of what event occurred and at what time on this device. Now, if you don't have a proper synchronised time, the problem is that you may not be able to see the correct details because you don't have a proper synchronised time.

So it will be difficult for the administrator to figure out those log messages and the events. Aside from that, you might be employing something akin to selves. You might want to deny a specific type of traffic, say ATV traffic, from 9:00 a.m. to 5:00 p.m. So, when the traffic is moving to the router, you must ensure that this device has a common or proper time, and that time must also match with the other devices, because if your server or the user who is sending the traffic has a different time and the router has a different time, the traffic will be lost. If you don't have a proper time, some time issues may not work.

Synchronization. Of course, if you're using some kind of advanced-security VPN, like we use some kind of digital certificate validation, or maybe for my web browsers, or maybe for VPNs, if you don't have a proper in-life certificate, your digital certificates may not be validated. And also for other mechanisms, like there's something called "single signal mechanisms." It's a kind of authentication used for multiple applications, and for them to work well, you also need to have a common synchronous time as well. In order to have a proper synchronous time, the NDP network usually gets its time from the source. We'll configure a device with an NDP server, and we expect all the devices to contact the NDP server.

And whatever the time present on this particular device, we can tell the device to synchronise the time between these devices. So we can either use our own internal server, where they can select any router, any server, any PC, or any device as an entity server, and synchronise the time from all the devices you can also contact. Or you can also configure an additional time source on the internet as well. So the NDP server usually gets the time from the authoritative time source. It's just like a radio clock or atomic clock attached to the time server, and then the server is responsible for distributing the time across the different computers across the complete network, which we call entity clients. With NTP, there is something called startup value.

Now, NTP servers can be of two types. A server on the internet, like the NTP server, is also an option. For example, we can configure a device or device to communicate with some external clocks via the internet. You'll find some external blocks on the Internet. For example, if you go to Google and search for some external clocks, NTP time servers, and servers, you'll probably find some different time servers. Now you can configure your device to contact this external clock service to synchronise the time.

So it can be an external clock that always has the starting value of zero. In terms of similar torpor, that is the hog; hop on us and we can configure my device. Let's say I have a router here, and this is my NDP client, and this device is going to contact my external clock server and get the time synchronized, and then I can configure my internal devices. Let's say I have some other routers and PCs that will contact this server, and this is my NTP server, and these are my clients.

So we can still configure this device to contact an additional server, but it is practically not scalable because you don't want each and every device to contact a regional clock and synchronise the time as per the region. That's the reason we can configure our own internal server, and we can either manually set the time on this particular server or I can configure this device to contact the external clock to synchronise the time from the external clock. So if I'm synchronising from an external clock, then this is going to be my client, and this is going to be my server. And then this is going to be a server for all my internal clients.

So by default, an external clock will have a default starter value of zero. That is the time server on the Internet. As a result, it will always be the first value of one on all servers that support NDP in general. So we can configure a startup value of two, like this server's external clock. If it is sending time to my server, which is my client, let's say this is my client. If this starter value is one here, then it becomes two, and it becomes a client for all the remaining devices. We have some other clients who are using this device to synchronise the time. And you can also configure this device to become a server for other clients. The starter value will increase automatically. So your starting value actually tells you how many potentially actual time sources you have. And the default starter value will be one for all the servers. We don't operate like time servers on the internet.

Prepaway's 350-701: Implementing and Operating Cisco Security Core Technologies video training course for passing certification exams is the only solution which you need.