Hello and welcome again to Check Point Jumpstart training. In this module, we'll be examining how Check Point logging works, how you configure it, and how you can access the log data. So we'll start by discussing deploying setting up logging, then using the track action in your security policy to determine which rules that have traffic matching them should generate log data and how verbose that log data should be. We'll then take a look at the smart log component of SmartConsole, which allows you to intuitively search for and display the detailed log data that is being generated. We'll also look at the functionality in both SmartConsole and external applications that permit you to get at a glance update of the status of your Check Point deployment, as well as getting more detailed information about your Check Point deployment. Also the SmartView web application, which provides a platform independent way of accessing log data. You don't have to have a Windows desktop machine with the Check Point SmartConsole software installed, you just need a standards-compliant web browser. We'll also demonstrate this how to setup logging, configure log actions and policy, and then examine log data, examine the status of your Check Point deployment and we'll take a look at the SmartView web application. So a central theme in Check Point is the three-tier architecture where we have security gateways that are examining network traffic, applying your security policy to that network traffic, determining which connection should be permitted, which connections should not be permitted, or perhaps which connections we're going to allow, but we're going to watch with say, Layer 7 awareness of what is acceptable for this protocol and what isn't. So security gateways are doing that and as they do that, they're generating log data. The log data is sent securely using secure internal communication, S-I-C, SIC to a designated log server and by default that's going to be your Security Management Server. But in a large deployment, you may want to move that load, that overhead off of your Security Management Server and have it handled by another appliance and you can do that. You can set up a dedicated log server. Similarly, we'll take a look at the SmartEvent component, which allows you to see event data that is by default processed on your Security Management Server. That can be a lot of processing, a lot of overhead, so you can deploy another appliance and configure that appliance to be where SmartEvent processing is done. Finally, there's the SmartConsole component which again, is a Windows application that connects to the management server or the log server or the SmartEvent server and displays the data that is available, the log files, for instance. So in order to have logging worked, you need at least one log server. Again, by default that's your management server and the screenshot to the right shows a management server and you can tell that it's a management server because it has the Network Policy Management Blade enabled. In fact, it's the primary management server so there's no option to turn that off. It has to be the management server and also selected as a feature, a component of Blade, is the login and status. If you deploy a dedicated log server, one, you would configure it to be a dedicated log server using the Web User Interface First Time Wizard Configuration. Then you would create a Check Point object to represent that dedicated log server, establish SIC to that appliance, and then in the Check Point object that you created for that log server you would select logging and status, and perhaps also you want it to handle SmartEvent processing, you can select the SmartEvent components. Not going to get into details on that, but there are two, the SmartEvent server, which is where the event database is kept, and the SmartEvent Correlation Unit, which is pulling log data from various sources, primarily Check Point log data, but we can also pull in from third parties and analyzing to see do we have something here that looks like an event. That can all be done on your management server, but that's a lot of overhead so you can offload it to a dedicated log server that also handle SmartEvent or you can have a dedicated just SmartEvent. I think I want to go back. So cut this part out, and we'll go back, and we'll start. So as I said, by default, your management server is the designated log server. If you change that, if you deploy a dedicated log server, you have to make sure that dedicated log server has a checkpoint object to represent it, seek is established, that object has the login and status feature enabled and you have to configure the security gateways to override their default setting of sending log data to the management server and instead configure them to send log data to the log server. That's a setting in each security gateways checkpoint object, and I'll demonstrate that. So login is automatically set up for you. You don't have to do any additional steps, your management server will handle logs. Larger deployment, you may want to change that default behavior. Now, we need log data to be generated, and a primary source of log data is your security policy where we have access control policy with firewall rules and each firewall rule has a track action, a brand new rule, the track action is set to none and traffic that matches that rule does not generate a log entry. Generally, that's not what you want, that's not best practice. So what is best practice is to change the track action of every rule to be log. Now there are always exceptions, for instance, routine frequent chatty protocols such as perhaps DHCP or various router discovery protocols, you may not want a lot of log data generated for those protocols. You may have a rule that either allows that or drops that and it's tracking action is none because I'm not interested in log data about this particular protocol, and that's okay, but most of your rules should have at least log as a tracking action. If you select log under the More menu option, when you are editing the tracking action of a rule, you have the option of also selecting detailed log and extended log, and both of those contribute logged data just like a log setting does, but they have more information. Information pulled from the layer seven where blades, such as application control, URL filtering, content awareness, and that can be displayed in the smart log view which we'll demonstrate. There are some other options such as alerts. If you select an alert option, the default is no alerts, then when this rule with an alert action is matched aside, in addition to creating a log entry, we can also asynchronously alert somebody. So the basic alert option will simply give you a pop-up message, you have to be running the correct smart console component to see that pop-up message. So what might be more useful is a SNMP, simple network management protocol trap that is configured to alert whatever SNMP management solution you have that this asynchronous event has occurred. We can also generate an e-mail. Now you want to be careful with that, I don't want to be inundated with tens of thousands of e-mail messages, but that might be appropriate in certain circumstances. Finally, user-defined alert, which actually just runs a script on the host that's generating the alert, and that script can do whatever you can imagine and implement in a script. Gaia uses the Linux operating system. Linux operating system provides, for instance, bash, the bourne-again shell and that can be used for scripting and is extremely powerful, so we can use a user-defined alert to send, for instance, both NS and MP trap and an e-mail message and something else like start the coffee maker. Now to view log data, we start with SmartConsole and over on the left, that vertical menu, we select logs in monitor and that is a tabbed interface. So if we don't already have a logs tab, then we will click on the new tab and say, I would like to see logs in this tab. So this SmartConsole logs view is actually smart log, which is also a separate SmartConsole application, but it's also integrated here and it has a lot of different features that make it easy to tune what it's showing you, do precisely what it is you want to see. So for instance, at one, you can have already defined queries saved, those searches for log data that you routinely do. For instance, I want to see log data about IPS protections that have a severity of high or critical that were detected but not enforced, or I want to see logged data for anti bot blade log entries that display information about here as an internal host which is sending suspicious botnet related traffic. You can also quickly restrict the amount of logs by a time period. So in two, you say, I only want to see logged data for the last hour or the last 24 hours or since midnight today, and you can be very granular, I want to see log data starting Tuesday at 2:00 AM through Wednesday at 1:00 PM, and it will display only the log entries that are within that time period. At three, the query search bar allows you to further restrict the logs that are shown and it's natural language search syntax. You can, for instance, say I want to see, I would say I want to see all TCP logs from this source IP address to this destination that are HTTP and that will happen. Once you have a query that's displaying the data that you need to see if that's something you're going to be doing on a frequent basis, you can save that as a favorite query. Over on the right at four, you can see high-level event statistics such as what's the top sources of traffic, of connections? What are the most frequently connected to destinations? What services are we seeing the most? So on and so forth. Then in five, that's the major part of this view. You can see the results. If you double-click or right-click and select a log entry, it will bring up a log details window that is packed with information. Now what information is displayed in this log details window depends on the policy that created or of the component that created this log entry tracking level that was designated in that rule. Also what happened to the traffic, traffic that is dropped, we do that with the initial connection, so we never see layer seven data for dropped connections. Traffic that was accepted, we progress to the layer seven application exchange, and so there may be more logged data. So in this particular screenshot, note at the top-left origin, that's the security gateway that generated, contributed this log entry and then the time of day relative to that security gateway. The blades, the components, the features that contributed to this log entry. So in this example, both the firewall blade, which is basic packet filtering, stateful inspection, and the application control blade, which allows you to categorize typically HTTP and HTTPS connections based on, what sort of website is that? Whose website is that? Product family, it was an access control policy or was it threat prevention policy that contributed this log entry. Over on the right, you can see the source host name, if known IP address, source port, which is typically not important, that's generally randomly selected. The security zone of the source destination host name, if known, IP address, the destination security zone, and then the service destination port and protocol, TCP 443 is HTTPS. Also the interface in which the traffic was accepted, the traffic was received on and if we have layer seven awareness that has contributed to the log data in this example, the application control feature. Then we can see additional information such as this destination, which has the inscrutable host name, lga15s47, etc, is actually part of Google services. That's the application and so if you have application control policy, you can make access control decisions, are you allowed to go to Google services or not? That's independent of the domain name and that frees you, the security administrator, up from having to research and find out currently what every Google service domain name is. Then create policy to block or allow just those domains, Application Control knows that information. Also, I'd like to note the matched category. This is URL filtering. So this destination was categorized by URL filtering as computer slash internet and an application risk level was determined to be low. Back to the right, you can see the policy information. The action for this connection was except policy package that processed this connection as the Alpha standard. That policy was last updated today and we matched rule number six, the outgoing rule, and that's from the name, "column of the rule". One final thing, you can't see much of it, but at the bottom left, this traffic was rewritten by the network address translation policy. So while the Source Address of the original traffic was, 10.1.1.201, net translated that source address to be the external IP address in this example, a cluster could also be just a single security gateway. So what the Google services destination received was a packet from 203.0.113.1, and so return traffic from the Google services hosts will be addressed to 203.0.113.1 and that will translate it back to the original IP. So I mentioned that it's a fairly flexible natural language entry search query system. So for instance, you can query log entries that are drop or accept or something else based on the action column of the rule that matched. You can restrict your searches to log entries that were contributed by a specific blade. Again, I want to only see anti-bug related logs. You can say blade Poland anti-bug, source, destination port and if you, for instance, have identity-based policy where you are determining who is the user that is originating this traffic, you can search based on the identity. So show me traffic from, User Tom that is the HTTPS protocol that was accepted. So some more examples, searching by a particular user, Richard, searching for an IP address or a range of IP addresses, in this case a subnet, show me anything in the, 10.0.0 subnet. You can also say show me anything from 10.0.0.1 through 10.0.0.149. Search for IPV6 addresses, host names over on the right, searching for a range of ports. Though, note that we overflow here. So that's sort of a bug in the slide, just to see if you would notice because the maximum port number 65535, searching by destination or Source, you would prefer it with SRC colon or DST colon to say, I only want to see traffic from this source or this destination. You can also say, I only want to see log entries where this specific fields such as network address translation or destination host name is blank. So "DST host colon,". The two quotes or the empty square brackets designate node data in that field. Another nice feature that SmartConsole provides is a high level overview of the health of your checkpoint deployment. So this will display the health of all checkpoint devices that have SEC established to your management server, as well as the management server itself. Here we can see that there are three devices that we have SEC established to or two devices that we have SEC established to plus the management server. But those two devices are part of a cluster. We're not going to get into clustering in this training, but just briefly, when you have a cluster the individual components of the cluster are generally not access, not configured individually instead you configure the cluster object that contains those individual security gateways. But in this context it is important to know not only the overall cluster status but the status of the components of the cluster. So not only is the cluster object displayed here but the individual gateway objects that are members of that cluster are also displayed. Note the status column on the left, green circle with a check mark inside of it means everything is good. A yellow triangle means that at least one component, one portion of this checkpoint host has a warning for you. If that status symbol is not yellow, it's red instead, that means that at least one component of that checkpoint host has a critical issue that you need to address. Critical issues could be, I can't talk to it right now because the network is down or that device is down, it could mean that a license has expired, it mean that it is critically overloaded. I also want to note under recommended updates, there are no currently recommended updates that have not been applied to the three checkpoint hosts, the management server and the two security gateways up-to-date. That's that CPU's component which is a Gaia level component that on that Gaia host will automatically reach out to checkpoint and determine, are there any updates that are applicable to this version of Gaia in this role of Security Gateway management server, what have you, and so right now, no. You can also see CPU usage and there's other things I'd like to know about network throughput on a security gateway, memory utilization and you can get that information by selecting one of the lines here, A-GW cluster or A-SMS or an individual security gateway. Then at the bottom, more information is displayed, more verbose information. So we've selected A gateway cluster and at the bottom you get details of a gateway cluster, and you can further drill into the details by clicking on either the license status, "Okay," which is a hyperlink or device and license information and that will bring up even more information about licensing or the components of the device. For instance on a security gateway, a few have the IPS intrusion prevention blade enabled. What's the status of the IPS Blade? When was it last updated with signatures and protections? Now the SmartView Web Application is new in RAT to access it by default you go to https colon slash slash whatever your management server is, that could be a host name, could be an IP address, could be a fully qualified domain name, whatever. You would not literally type in all caps MGMT HOST, replace with the IP address or host name of your management server slash smartview. Perhaps click through TLS warning about the certificate of this management host. Once you've clicked through, you'll be asked to authenticate as a checkpoint administrator, and once successfully authenticated, you will see something like the logs view of smart console, only a browser based. This is really handy for instance, auditors or help desk or security analysts who need to be able to see what the current security posture of your checkpoint deployment is or looking at logged data. So I'm going to demonstrate the various logs and status views in smart console. Will do some queries, will also take a look at SmartEvent We'll look at the various log options as well as alert options and the SmartView Web Application. I want to show you how to see status and logs in SmartConsole, and first status, if you go to the gateway and servers view on the left-hand side menu, you get a quick, easy overview of the status of your checkpoint deployment. So all checkpoint devices starting with the management server and then including every checkpoint device that you have SEC established with, will be displayed here and the first column, the status column, you get a green circle with a checkmark if that device currently has no critical issues and no warnings. If it has at least one warning, no critical issues, there will be a yellow indicator. If it has at least one critical issue, there'll be a red indicator. Selecting one of the checkpoint devices displayed will bring up more information down at the bottom in the summary tab. So for instance, we can see CPU and memory utilization, whereas at the top half we only see CPU. It'll tell us if it's a security gateway or management server or something else, this example it's a security gateway and it has the example coal policy installed, that was done at this date and time. You can also see tasks that were performed on this Check Point host, and those task can be automated through the application programming interface, but it could be something that an administrator kicked off manually by, for instance, right-clicking on the "Device" and going to Actions or Scripts, or for instance, do a backup. Then any errors that have been recorded on that device and right now there's no data. Back in the Status tab, if you click on "Device & License information," you get a pop-up window with additional details. So on this particular security gateway, there are several features use we call security Blades enabled, the firewall is basic, that's packet filtering, stateful inspections got to be there. But we've also enabled URL filtering application control, intrusion prevention, and Anti-Bot. All but the firewall feature are going to require occasional updates. URL filtering, for instance, as new websites are deployed on the Internet, we need to know what the category of that website is. Anti-Bot as new command and control hosts are discovered, we need know their IP address or new botnet malware may have a different protocol used for command and control. We need to update our signatures to be aware that this is botnet command and control traffic. IPS, intrusion prevention protections, are updated, new ones are added as new threats are identified, so we're going to need those updates. Now, the green check mark here means that none of these blades are complaining, none of these features have had an issue, for instance, with fetching an update. If the last update did not succeed, then there may be a yellow warning. If it's been a long time since we had a successful update or we have a license issue or something like that, there may be a red critical marker. Then we also have License Status, and this is a virtual lab environment. It's using a evaluation license, which automatically enables pretty much everything, but has a time limit. System Counters and traffic, really only useful on security gateway. This allows you to see, for instance, system counters, CPU utilization, memory utilization, hard drive utilization. Traffic allows you to see fairly real-time information on what traffic is moving through the security gateway, and you have other options, for instance, how large the packets are we seeing. Then moving away from monitoring to more logging and status, under Logs and Monitor, this new tab, which if it's not displayed you can click the "Plus" sign here to get the new tab, offers you different views. What view do you want displayed in this new tab? I've already selected the logs view in a tab. But this is log data that is being contributed, usually by a security gateway, and this origin column here will tell you which Check Point host contributed the log entry. So most of these log entries are coming from my security gateway, a gateway, but there have been a couple from other Check Point host. Typically, log data is generated when a rule matches in your security policy, and that rule has a tracking action. But there can be other reasons why your security gateway or some other type of Check Point device generated a log entry, including the device restarted or we have a cluster and a cluster member has fallen out of the cluster, or it's come back into the cluster, perhaps it restarted or something else happened. By default, the logs shown here are not updated without user interaction. I can click this "Refresh" icon and it will go out and fetch new log data and I currently have the view limited to just log entries in the last hour. You can make it last Wednesday through last Thursday, if you need it to. I also have a query, I'm only interested in log data that came from a gateway, so not my event server, not my management server, only the specific host, a gateway and where the service is HTTPS, only show me log entries that match that in the last hour. Most of the log entries here are the result of HTTPS connections happening in the background from my Windows host going out to some website on the Internet, and I have HTTPS inspection enabled on a gateway. So when an HTTPS connection is received on a gateway, it runs its HTTPS inspection policy. It decides should I decrypt this HTTPS connection or not. Most of the time, yes, decrypt. That shows up as an inspect log entry. Now, if you double-click on a log entry, brings up a details window with additional information. For instance, this log entry was a connection out to apparently Google, gstatic.com, which is categorized by my URL filtering feature as computer/Internet. Again, this connection was decrypted. The HTTPS inspection policy matched a rule whose action was inspect. So we decrypted the connection. Some of these other views, such as the General Overview view, which again you can get by creating a new tab and selecting the General Overview. This is not so much log entry focused as issue focused or event focused. So for instance, over on the right-hand top, we have account of infected host, which would be contributed mostly by the Anti-Bot feature. The Anti-Bot feature detects this internal host is attempting to connect out to a known command and control server or IC traffic that matches known botnet command and control signatures, then that's a host you need to go look at, or IPS or antivirus might be populating the critical attack types. But again, this is a fairly quiescent lab environment, so there's not a lot of data available showing attacks or even just regular traffic. The audit logs view is for administrators. So for instance, it shows changes to your security policy, rule was created, a rule was moved to a different position, a rule was updated with this source object and so on. This is useful for figuring out who changed this rule. Now there are other ways to do that in SmartConsole. This is one way to go back and review, well, how did this change that broke the Internet happen? Who did it? What did they change? But also you can see administrator logins, logouts, and other actions. There are plenty of other views available, such as the compliance view. If you have the compliance feature enabled, you configure that compliance feature with the list of frameworks or standards that you need to be compliant with. That could be, for instance, the payment card industry data security standard or something specific to your country or something international such as ISO 27002. Then the compliance feature will give you a report here, in this compliance view, of how compliant you are. Down at the bottom left under external apps, we have a link to open a legacy SmartEvent application that allows you to configure event policy, what constitutes an event, what doesn't. Then tunnels and user monitoring, that opens another legacy application related to the monitoring that allows you to see, for instance, with a site-to-site VPN between your headquarters and some branch office. Which VPN tunnels are currently active? You can designate VPN tunnels to be permanent. Have them active even if they haven't had any traffic moving through them. So you can see which tunnels are marked as permanent, and are there any permanent tunnels that aren't currently established? If so, do we know why? The user monitoring part of that is mostly for remote access VPNs, where I have an individual device that initiates an IPSec VPN connection to my security gateway, usually to get access to some internal exchange server, or something like that. You can see who authenticated over that VPN connection, where they're coming from, what VPN client they're using, and more. This SmartView is new. It's nice. It's a web-based interface into your logs. So the URL for this is HTTPS:// IP address or host of your log server. In this case, it's the management server slash SmartView. I'm already logged in. Typically, you would have to log in as a Check Point Administrator, just like you do with SmartConsole. This is where the administrator permission profiles come in handy because in SmartConsole, you can configure a Check Point Administrator permission profile that has limited access, limited privileges, no right access to anything. Instead, we have read-only access to the SmartView web-based interface for these types of logs, and that's it. So you can create a permission profile or you could clone the existing read-only permission profile and start from there. Now, once you have that permission profile locked down to only permit what a specific role, a specific employee should be allowed to do and nothing else, then you can create Check Point Administrator user, assign it that restricted permission profile, and then give the Administrator credentials to whoever. When they attempt to authenticate as that Check Point Administrator, they're only allowed to access the functionality that is permitted by the permission profile, which for instance, may be only the SmartView web interface, nothing else. Read only access those SmartView web interface doesn't really have a lot of opportunity for writing and only these types of logs. Now, one other thing I wanted to show you was in the tracking column of your security policy. So here, this security policy is very simple. It has two rules. Rule number one, if it's matched, its action is not accept or drop it's run another policy layer in line. So the name of that policy layer is content awareness. So if we match rule number 1, we start evaluating the content awareness policy layer, and that policy layer shows up as sub rules; rule 1.1, rule 1.2. Rule 1.1 has a tracking action that the default for a new rule would be none. No tracking best practice says every rule should have at least a log tracking action, unless there's a really good reason why you don't want this rule to generate log entries. But if you select log, then under More you have the option to get detailed and extended logged data. This is pretty much layer 7 data. So if a log entry is being generated by the firewall itself, that doesn't really do layer 7. So if you have that except action in a rule with an extended log tracking action, you're not really going to get any layer 7 data. On the other hand, if the log entry includes contributions from say, content awareness, application control, URL filtering, threat prevention, those are layer 7 aware. So if you have a detailed or extended log tracking action, then you're going to get some layer seven information. I also wanted to talk a little bit about alerts. Which is another type of tracking action that's available. There are several different types of alerts. The default is don't alert. But you can have an alert which creates a log entry as normal, but also in cars an alert to appear in monitoring, what's usually chosen here is SNMP, simple network management protocol. With that as your alert, you can set up an SNMP trap to be sent asynchronously from the security gateway that process, the connection match the rule that had the SNMP alert action. That is sent to whatever SNMP manager you designate, and the SNMP manager can then do whatever it does, for instance, use its own alerting functionality to tell administrators or contribute the alert to some log consolidation product, whatever you need the SNMP manager to do. Another alert action is mail, which sends an e-mail message and you can designate who the e-mail message goes to. Subject and body can be built with information from the connection. Now, understand that if you choose a mail alert action, every time that rule is matched, you're going to get an e-mail, and that could be a denial-of-service attack in and of itself. Then we have user alert 1, 2, and 3. When you select one of those, a user alert script on the security gateway that has this alert action will be run. The default scripts provided by Check Point don't really do a whole lot. You can edit those. Those are simply Bash, bourne-again shell scripts and add whatever you need it to do. Something I've seen some customers do is, when this user alert script is run, I want you to take information passed to it about the connection and generate something called a suspicious activity monitoring rule, which is a temporary block. It's not policy. It doesn't show up here under security policies. It's somewhere else in the firewall kernel, but it dynamically allows you to block a connection. So we can have that done via the user alert script, or you can have it start the coffeemaker, whatever you need done that you can do using Bash shell programming and Linux utilities. In this module, we looked at how logging and monitoring of status are done in a Check Point deployment. So how do you get logging deployed? What are your options for having logs processed? Then in policy, the track column and the possible settings there. The default none, which is usually not what you want. Log, some of the options with log, and then alerts. Using the LogView and SmartConsole to display the specific log data that you need to see using search queries. We also looked at monitoring gateway status both in the SmartConsole application as well as via an external application. We demonstrated that. So thank you for attending this jump start training.
