Appliance Monitoring

1. Appliance Monitoring (Introduction)

In this section of the course,we're going to cover appliance monitoring. Our focus in this section is going to continue in domains three and four with objectives 3132 and four three.Objective three states that given a scenario, you must analyse data as part of security monitoring activities. In particular, we're going to focus in particular on log review and analysis. Objective three states that, given a scenario, you must implement configuration changes to existing controls to improve security. This is going to include things like firewall controls, ACLs, and IPS rule sets. Objective four three states that given an incident, you must be able to analyse potential indicators of compromise. So this is going to focus on your ability to read and analyse a log to identify an emerging threat against a system or a network. As we move through this section, we'll start by reviewing firewall logs and configurations. Then we're going to move into proxy logs and a specialised type of firewall called a web application firewall. After that, we'll explore the configuration of IDs and IPS devices and how to conduct law reviews on those devices. Then we're going to take a look at port security and the configuration of network access control, or NAC. Finally, we're going to move into a hands-on demonstration that shows you how to analyse output from some security appliance logs like you would in the real world as an analyst.

2. Firewall Logs (OBJ 3.1)

There is a large amount of security data that we can obtain from our various network appliances, such as our firewalls and intrusion detection and prevention systems. In this lesson, we're going to focus on a review of firewall logs to determine the security posture of our networks. Now, this lesson and this course assume you already are familiar with the basic functions of a firewall and the basic configurations of one because you've already taken Network Plus and Security Plus in your past studies. As you probably remember, a firewall is designed to provide you with a line of defence at the network's boundary to limit the types of traffic that passes in and out of a given network. It usually does this by using an access control list. An access control list is a list of permitted and denied network connections based on either an IP address, a port, or the applications in use. As you start to analyse firewall logs, you're going to notice that they provide you with four types of useful security data. First, they provide you with connections that are either going to be permitted or denied. You can start noticing these patterns within the logs, and this will help you identify holes within your security posture. Second, they have port and protocol usage. This is going to tell you what ports and protocols are being used on your network, which ones you want to allow,and maybe which ones you want to start blocking. Third, your logs can show you bandwidth utilisation with the duration and the volume of usage for particular connections. This way, you can break down connection by connection, user by user, department by department, or server by server, and figure out which ones you want to focus on. And fourth, they provide you with an auditlog of all of the address translations, whether they're network address translations or port address translations, that have occurred within your networks. If you ever find yourself responding to an instantresponse, you're going to find yourself going through these firewall logs to determine which hosts had that particular IP at any given time, especially since so many enterprises use DHCP for their internal addressing. So what does a firewall log look like? Well, each firewall log format is going to be different based on the vendor that you're using. Each one has its own specific format. I'm going to cover two tools and show you what their logs look like. First, Iptables. Iptables is a Linux-based firewall that uses the Syslog file format for all of its logs. This is what they look like, as you can see here on the screen. As you can see, there is a lot of detail inside, and this is just two lines out of a log. Now, each of these indicates one attempted connection, either going in or out. And we're going to walk through these logs to make sure you understand how to read them. Each log entry is prefixed with a timestamp,a device ID or hostname, and a facility, which is usually going to be the kernel. After that, each log rule is going to have a logprefix value or a log level and this will tell you which rule is being applied when this was logged. In this case, you see Iptables input drop, which tells me this was a drop rule that was being applied. Now, in this area, sometimes you also have an analogue level value which will tell you from zero to seven on the syslog scale what it is. I'll talk about those a little bit more later on. In this particular log, you don't see that being shown. Following the header values, we then have the actual contents of the log message. This includes a lot of attribute value pairs,each one delivered by commas or spaces. Following that header information, we are going to have a set of attribute pairs showing the attribute equalsvalue as it goes through, and each one is going to be in a deliminated format. Now here you can see the first ones we have are our interfaces. This is going to tell us which firewall host interfaces were involved. In this case, it was an inboundinterface called ETH zero, or Ethernet zero. There was no outbound because this was something attempting to get into our network. Next we have which Mac addresses are involved, both the source and the destination. After that, we have the source and destination IP addresses and this is going to be logged as well. After you have that, you're going to have some information about the packet itself. This will include things like its length, the tos, the precedent, the time to live and lots of other details. You'll also see the protocol used. Was it TCP or UDP? You'll see what the source port was and the destination port is. You'll see the window and all the other information that is important to you as you look at that packet header. Now as we take a look at these two packets that were dropped, the first one on the top is actually showing a destination port of 23. So as something was trying to come into our network,the firewall saw it was destined for port 23, which is telnet, and said "I don't have a telnet server,that port doesn't open and it dropped this packet." Now the second one on the bottom, as you can see, is a destination port of 21. Similarly, there's no FTP store being run. This port was closed, so the firewall is going to drop it and reject that request. This is what it looks like when you start looking for something in IP tables in the syslog format. Now earlier, I mentioned that there was a syslogvalue that could be used anywhere from zero, which is emergency, up to seven, which is debug. Here on the screen you can see all the categories from zero to seven. This chart should be reviewed for you because it is covered in Network Plus and Security Plus. I'm putting it here on the slide just for your reference because you may see questions about this on the exam. Now, as I said, this syslog format is used by Iptables and Linux. But what if you're using a Windows firewall? Well, Windows uses a Windows-based firewall that uses the W3C extended log file format. Now, here's what this looks like. The nice thing about the Windows Firewall log format is that it is a lot easier to read because they put comment lines above it. So it tells you right off the bat. What software are you running? In this case, the Microsoft http server API 20. What version of the software are you running? What was the date this file was written? So, what other fields are there? And this is really important because this is your key to the next piece of information as you go through the logs. That last line that you see on my screen is the log file itself. Now, all the information above is the beginning of that log file that shows comments. But as we start logging multiple things,we're just going to get repeats of that bottom line with the different details. So let's go ahead and read through that. Notice that we have that commented line of fields? It tells us exactly what is being covered here. So first we have the date and you can see the matching date, 2002, five, two. Then we have the time, in this case, 1742 and 15 seconds. Then we have the client IP. Where was this request coming from? In this case, 100 and 322-225-5255. Then we have the client's username. In this case, we didn't have one. So it just shows up as a dash. Then we have the server IP. In this case, that's 107, 23255, and 255. And then we have the server port we're trying to connect to, in this case, port 80. Then we have the method, and this is going to be the client method that was used in this case. It was the Get method, which we talked about in the previous lesson when we talked about the HTTP methods. After that, we have the client Uri stem. What resource was it trying to access? In this case, it was the picture.jpeg file inside the images directory. And then we have the Csuri query. And in this case, it has a dash because there was no query being made. If we were using something like a postmethod instead, we would have a query associated with it and that would be shown here. And then we have our SC status. And if you remember back in our HP lesson,we talked about the fact that 200 meant it was okay, it was a successful status. So this tells me this get request actually worked; they were able to access that server and get that file that they wanted and have it downloaded. The final thing we have is what's called our client user agent. And this is that long string there at the bottom. This is Mozilla, and then it tells us some information about it. So by reading this, I know that they're using the Mozilla browser. In this case, it's most likely Firefox. And it also tells me what type of client it was used on. In this case, the Windows 2000 server This gives me some details about the client that was actually accessing this andgoing through the firewall making this attempt. So before we go any further, I want to take a quick pause and talk about a quick exam tip for you. For the exam, you should feel comfortable reading these types of logs. You need to be able to understand what has occurred. For example, if on the exam they give you five to ten lines from the Windows Firewall log, you should be able to tell if the client requested a file from the server if that request was successful. For example,did they get that status code 200? Or if a post request was successful, send a file to a remote server. You don't have to be a firewall expert here,but you do have to have a solid understanding of reading these Iptable logs and these Windows Firewalllogs because that is going to be essential to you passing the Cystlex exam. All right, so we have all these log files, and we start collecting a tonne of data. What do we do with it? Well, the first thing you should do is employ a log collection tool to gather the large volume of firewall logs for later analysis. You can't have them sitting on one single machine because if that machine goes down, you lose all the logs. Also, a single machine probably can't hold all these logs because there is so much data here. Now, one of the big things is that you can become overloaded with information, so you have to scope your logging properly. How much do you really want to log? What are the important things to log? Where are you going to place these sensors? Where are you going to place these firewalls to collect the information and provide the best protection? These are all things you have to think about. If you don't think about this, and you don't scope your logging properly and you try to log everything, you may become overloaded with events and it may make it really hard to analyse later, or your system can actually be blinded. And this is known as a blinding attack. A blinding attack is a condition that occurs when a firewall is under-resourced and it simply can't log all the data fast enough. And therefore, some of that data is going to be missing in the logs and you're not going to be able to analyse it later. Another thing you have to determine is how long you're going to retain these logs. Log retention should be determined by the number of events that are being generated and your available storage capacity. But it also has to be determined based on your business case. If you have a business case to keep all these logs, then you may need to buy more storage capacity to be able to handle that. For example, if you've been attacked in the past and you want to be able to go back and look at that, if you don't have long-term retention, you're not going to be able to do that. So some companies might say they're willing to keep logs for three months. Some say six months, some say twelve months, some say forever. It really depends on your organisation and what you're willing to spend. Now, if you have the threat of an apt, remember that, on average, an apt can be in your network for five, six,or seven months before you ever determine they're there. And that means you probably need to keep your logs for at least six to twelve months, so you have an opportunity to find out how they got in and how you can stop them next time. Now, I get asked a lot by students. How do I practise this stuff? Jason, where can I find the log files? Well, one of the best things to do is actually set up your own firewall on your home network. This way, you can turn it on and start analysing those files. And if you want to do this,there's a great tool called Pfsense. Pfsense is a unified threat manager, which includes a firewall, and it is a free open source program. You could take an old laptop or an old desktop, install Pfsense on it, and run it to protect your network. You'll also be able to log that information, go through those logs, and be able to determine what they look like and get comfortable reading them. There is nothing better than reading real world logs to get a real sense of what's going on out there and really get yourself better at doing this.

3. Proxy Logs (OBJ 3.1)

Proxy logs In this lesson, we're going to discuss proxy logs. Now, going back to your earlier certification studies,you should remember that a proxy server acts as a gateway between you and the Internet. Basically, it's an intermediary server that separates the end users from the websites they're trying to browse. Proxy servers are going to provide varying levels of functionality, security, and privacy, depending on your needs, case, and company policy. Now the first type of proxy server we have is what's known as a forward proxy. A forward proxy is a server that mediates the communications between a client and another server, and it can filter or modify communicationsand provide caching services to improve performance. Now, basically, a forward proxy is going to act on behalf of your internal host or workstation and forward their HTTP request to the intended destination. Basically, when I'm sitting at work, I'm on my computer. It's going to go from me to the proxy server and then from the proxy server to the website I want to connect to. Proxies can now be classified in one of two ways. They can either be non-transparent or transparent. When I talk about a nontransparent proxy, this is a server that redirects requests and responses from clients configured with the proxy address and their port. Now these nontransparent proxies are ones where you know there's a proxy there. If you go into your Internet settings of your browser,you're going to see that there is a proxy configured and that your traffic is going from you to that proxy and from that proxy out to the Internet. On the other hand, we now have transparent proxies. These are forced or intercepted proxies. This is when a server redirects requests and responses without the clients' being explicitly configured to use it. This is often used if you want to make sure your employees aren't turning off your proxy because this is done at a network layer. So all the machines are going to go through this transparent proxy, not just the ones that are configured for it. An analysis of your proxy logs can reveal a lot of information for you about the exact nature of these different web requests. This includes websites that the users visit and the contents of each request. By using a proxy server and logging all this information, you can actually understand exactly what your users are doing, which websites they are going to, and how long they spend there. Now a proxy is going to use different log formats depending on the proxy you're using. But one of the most common is the common log format. This is the same one used by web servers. We took a look at this earlier when we looked at the Microsoft logs on the firewall lesson. Here again, you see the information in those last couple of lines. This tells you the date, the time, the destination, the type of request it was, what port it went to,what the action was, and things like that. This is the same type of log file that we talked about when we talked about Windows firewalls. Inside this you'll see information like the user ID of the client when it's authenticated to the proxy. The request method that was being used, like a get or post request, will tell you the status code,such as status code 200 or 403 or 404, and the size of the invites and the type of information that was returned to the client, whether it was a text file or a picture or something like that. Now proxies that are set up to intercept or block traffic can also record the rule that their request matched to determine the employee's intent. So if somebody is going out and trying to access something, you can determine if there is malicious intent or harmless intent. Let's take a look at an example here. Here on the screen you can see a Squid access table. This comes from a Squid log programme, which is a proxy server. Now here, if we start from the bottom up, we go from the oldest entries to the newest entries. As we look through these logs, what do we think is happening here? Well, as we start looking, we start seeing this website, 550.web.net. And you can see there was a code 200. If you remember back to our HTTP lesson, code 200 means a successful attempt. So this was an okay permitted-access action at this particular time. About seven minutes later, they tried again, and instead they went to www.fiveonefiveweb.net. And again, this was allowed. About 90 seconds after that, we see they try to go back to that same website, www.550.web.net. And you'll notice here there's a 403 error. What happened? It's different. Well, between those 90 seconds, somebody released a policy update, and it told the proxy server, from now on, that website is considered something that's not allowed,and so it's being blocked by the proxy. And you can see that there with TCP underscoredenied as the status and a 403 error. This is just some of the information you can find when looking through these proxy logs. This particular snippet only shows a couple of the columns. You're not seeing all the content and mime data inside of those requests. I just showed you the status of the address, the IP address, and the date for this particular example. Another type of proxy we have is known as a reverse proxy. And this is a type of proxy server that protects servers from direct contact with client requests. The idea of the reverse proxy is to provide for protocol-specific inbound traffic. When we get a request from the public internet, it goes to the proxy server first. Then that proxy server can create the appropriate request to the internal server, whether it's a mail server, or an aweb server, or something like that, get that request and send it back to the external client. This means the external client never directly touches your servers. It only touches your proxy server. And this can help protect things from malicious traffic. Now, the other great thing about doing this is that you get a great source of logs right at that reverse proxy that you can analyse for indicators of attacker compromise, such as malicious code in HTTP Request headers or URLs. This way, you have a single point to check all those logs because everything is going in through that proxy. Anything from the outside Internet coming into your network has to be able to touch one of your internal servers. So this is a great way to do this. Now, here on the screen you can see another example of a Squid log from a proxy server. This one comes from a reverse proxy. Notice everything coming in from the IPS is an external IPS. Every destination is an internal server, and the proxy here is in the middle. And it's the one that's seen the information passing those requests back and forth from the external side over to the internal server. That way, your internal servers only touch your proxy server. They do not touch the external client directly. And this gives us a single point where we can start looking at all of the status messages and start doing statistical analysis of those different responsecodes to be able to identify any suspicious trends or anomalous deviations from the baseline traffic.

ExamSnap's CompTIA CS0-002 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, CompTIA CS0-002 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.