Hello, and welcome again to Check Point Jump Start training. In this module, we will cover deploying a Check Point security gateway, a firewall. So we are going to look at network models. But this is not a networking class, so we're not going to spend a lot of time on the various models. But we will talk about packet filtering firewalls versus stateful inspection firewalls versus an application layer firewall. We'll also briefly cover how the firewall product can be deployed. We'll look at anti-spoofing, which is an integral feature of Check Point security gateways, also security zones. And then we'll demonstrate the setup of a security gateway and adding that security gateway as an object into your Check Point configuration using SmartConsole. So the OSI model, open systems interconnect, has been around for a few decades. And I'm, again, not going to spend a lot of time on this. I want to note that on a security gateway, which, again, is just a Linux host, the firewall functionality is mostly implemented as a kernel module. And that kernel module, when it's loaded, essentially hooks itself between layer 2, which we've received packets from the wire or the fiber, we've done some link level decoding as necessary. And layer 2 would normally hand a packet up to layer 3 for routing, what's the next hop that this packet needs to be sent to to get to its final destination. But the firewall kernel sits between layer 2 and layer 3. So as the packet is being passed up from layer 2 to layer 3, the firewall kernel receives the packet and implements the functionality of the firewall, or most of it. There's some functionality that's implemented elsewhere. And when the firewall kernel is done with the packet, assuming that your security policy says forward this packet, allow this packet, accept this connection, the firewall kernel will hand the packet up to layer 3. And perhaps the packet's been modified, perhaps it's been encrypted for a VPN, or perhaps network address translation has occurred. Layer 3 will then route the packet and send it down to layer 2 to be transmitted out the physical interface that's connected to the next pop at the firewall kernel, it's hooked between layer 3 and layer 2. So the outbound packet is also processed by the firewall kernel. And again, at this point, we may need to do network address translation or something else with the packet. Once the firewall kernel has completed processing of the outbound traffic, that packet is then passed down to layer 2 and transmitted to the next hop. But in the OSI model, we have three distinct layers of the top, session, presentation, and application, and that's not really how the Internet works. The Internet uses a simplified, sometimes referred to as TCP/IP model. And in this model, there are four layers. We've combined the top three layers, the session, the presentation, and the application, into just one, the application layer. And that reflects reality. Your web browser, for instance, implements session controls, it implements presentation where we decide, what kind of data am I sending? What kind of data am I receiving? How do I interpret that data? Also, how do I encode this data so that it can survive a trip through perhaps a text-only connection? And then again, the application layer, layer 7 in the OSI model, where we implement the functionality of whatever protocol this is. If you're doing HTTP, we implement the HTTP protocol, if you're sending email, we implement probably the STMP protocol. Also, we simplify the bottom layers a little bit. We just combine layer 1 and layer 2, the physical layer and the data link layer into a network interface layer. And the job of that network interface layer is to talk to directly connected local area network hosts. But from the OSI model, we do use the Internet layer, that's the Internet Protocol version 4 or version 6, and the transport layer, which is typically TCP or UDP, could be other protocols. The Internet layer gives us source IP address, destination IP address. The transport layer gives us, generally, with most transport protocols, the source port and the destination port and the protocol itself. Are we sending this as a UDP packet or a TCP packet? And destination port plus protocol 443 TCP equals service. This is the service that I want to communicate to. I'm going to connect out, do whatever destination IP address, destination port 443, and I'm going to use the TCP protocol, those two things. 443 TCP indicates this is an HTTPS connection. So Check Point uses various technologies to enforce your security policy and make decisions about incoming and outgoing traffic. Should this be permitted, should it not be permitted, should I alter the traffic somehow? And it starts with packet filtering. Packet filtering is the basic firewall functionality where we operate at layer 3 and layer 4. So again, layer 3, we're looking at source IP address, destination IP address of the packet. Layer 4, we're looking at destination port and protocol or service. We don't normally care about the source port because that's usually randomly chosen by whatever client operating system is initiating the connection. But in some circumstances, we do care about the source port. So packet filtering firewalls, they allow you to control network traffic based on layer 3 and layer 4 information. However, they have some flaws, including the fact that, well, in early packet filtering firewalls you had to have two sets of rules to allow, say, HTTP traffic. You Would have to have one rule for the outgoing traffic that permitted destination port 443, protocol TCP. And a second rule for the incoming traffic that permits source port 443, TCP, the return traffic from the web server. Now, later packet filtering firewalls did away with that. It was a pain to manage these pairs of rules. So, okay, a rule that allows traffic doubt implies that the return traffic is also allowed. Okay, we can do that. But another limitation of packet filtering firewalls is they have to examine the ruleset. They have to run the rules for each packet in every connection, and that can take some CPU time. Also packet filtering firewalls don't look at the higher layers. They don't have any intelligence to determine is this a dangerous HTTP request that might be encoding some sort of SQL injection attack, can't do that. Check Point developed stateful inspection, which when a packet arrives on the the security gateway, we first of all determine is this a start of a new connection. And if it's a TCP packet, that's easy to determine. With a TCP packet, a connection is always begun by sending a TCP packet with no data and the TCP header has one flag turned on, the SYN flag. And so, if I get a packet and it is a TCP packet and only the SYN flag in that packet is turned on, then this is the start of a new TCP connection. If not, then this is not the start of a new TCP connection. With UDP, you don't have the three-way handshake that involves the SYN packet. So, with UDP, we just have to, have I seen this traffic before? If I haven't seen this traffic, then I'm going to call it a new connection. And when we receive traffic that's initiating a new connection, we run the rules. We go through our firewall policy, doing packet filtering, level inspection, and determine is there a rule that matches the properties of this traffic. If so, what's the action of the rule? And in Check Point, the typical actions are drop, which we're done with the traffic. Or accept, in which case the traffic is going to be allowed pending other analysis. And if we decide to accept the connection, we create a state table entry. Which is essentially a hash table inside of the firewall kernel that allows us to quickly match subsequent traffic and not have to rerun our rule set. So, we hash the source and destination IP address, the source and destination port, in this specific instance source port is important. And the protocol, is it TCP, UDP or what? We hash that five pieces of information together. We get essentially a memory location in this hash table. There we put a note. At that position in the hash table, we make a note saying this connection is permitted. And so, when we proceed through the establishment of a TCP connection subsequent packets that arrived on the security gateway that are part of this connection. Well, it's not a new connection, because these packets will not have only the SYN flag set, so, this must be an existing connection. Hash those five values, and the resulting table location will tell us if this is a known approved connection. If we don't have a state table entry or the packet that has arrived at is apparently part of an existing connection. Then we're going to drop the packet for being out of state. And that helps protect against some forms of network scanning techniques that abuse the TCP protocol or other protocols. And allow the attacker to fool some firewalls into thinking, this traffic must be okay, because it's not the start of a connection, it's the middle of the connection, I can pass it through. Another thing that stateful inspection allows is when we have run our firewall policy, starting at the first rule and working our way down until a rule matches the properties of the packet, and that rule's action is accept. So, we created the state table entry, we're going to allow this traffic through. We can then allow other types of policy to examine the traffic. For instance, network address translation policy can decide that we need to modify the source IP address of this outgoing packet to be, say, the firewall's external IP address. Because we are doing network address translation of internal hosts. But more than that, we have Layer 7 policy that can examine what we have now. And at the start of a connection, beginning of a TCP or UDP connection, we don't have any Layer 7 data yet. So, the Layer 7 protections, they can't really do their job. But what they can do is say, this looks like an HTTP connection. I have protections that work on HTTP traffic. So, when you get subsequent traffic for this connection, let me take a look at it. Add an entry to the state table for this connection that we need to do this NAT rewriting. But we also need to pass the traffic to our Intrusion Prevention Blade so it can examine it once we have Layer 7 data being transmitted. So, stateful inspection really improved throughput, but I think more importantly, it allowed Layer 7 inspection of traffic. And so, we're not confined to just looking at a source IP, destination IP, destination port, and protocol. And so, that led to the development of the Application Layer firewall, where we have protections at really almost all of these layers. The IP Layer, we have protections against dangerous IP options, and others. We have at the Layer 4, TCP Level, the ability to determine that this is a TCP resource starvation attack, not normal TCP traffic. So I'm not going to allow this. And then at the higher layers, we have hundreds of layer 7 protocols which various software blades implement protections for. And those software blades, if enabled, can examine the layer 7 data of a connection, once we actually get to the point where we're transmitting layer 7. And make decisions whether or not this traffic should be allowed, should it be dropped, should we modify the traffic somehow for safety. And so that gives us the ability to implement intrusion prevention, but also recognize botnet traffic, do URL filtering, and antivirus, and more. So early application layer firewalls used various techniques, including proxy servers. But in Check Point, the bulk of the layer 7 protections are implemented in the firewall kernel, so they're very fast. Now, we'll talk a little bit about how you deploy a Check Point security gateway. A security gateway requires a management server to manage it, and we've already talked about deploying a management server appliance. So that sort of implies that we have a management server appliance and at least one security gateway appliance. In a very small shop, a very small deployment, it may not be necessary and cost may be an issue, so only want to buy one appliance. Well, you can do that, and the appliance can be both the security gateway and the security management server on the same appliance. That's known as a standalone deployment, and it works, but there are some limitations. If you have a security gateway that's in a standalone deployment, it can't be clustered. So you can't do high availability with that security gateway. Also, being a management server requires a decent amount of memory, and CPU time, and disk I/O. Which is robbing resources from the security gateway, which needs CPU to examine traffic, it needs memory to hold stuff. So it can limit throughput. The most common deployment that Check Point is deployed as is a distributed deployment. And in a distributed deployment, you have a management server somewhere else, on another appliance. So the security gateway is not managed locally by a local management server, that would be a standalone. Security gateway is managed over the network from a management server. We already discussed secure internal communications. In a standalone deployment, management server communications to and from the security gateway are inside of the same host. So a simplified form of secure internal communications is used. But across a network, in a distributed deployment, we use the full secure internal communication protocol to secure that traffic. Now, on a security gateway, and I will demonstrate this, you have to configure the various interfaces that will be dealing with network traffic. So I have an internal interface, I have a DMZ interface, I have an Internet-facing external interface, and I have a management interface on this security gateway appliance. Each of those interfaces needs to be configured at the operating system level. And then when you have a new security gateway that you're adding to your deployment, you need to create an object in the SmartConsole application that represents that security gateway, establish SIC to that security gateway. And as part of the initialization of that object, the network topology, the list of network interfaces, and IP address, subnet information for those network interfaces, default gateway information. Will all be imported over SIC from the security gateway to the SmartConsole application to populate this new security gateway object. So the security gateway object will have a list of interfaces, the IP addresses of each interface, subnet mask of each interface. And typically one of the interfaces, the one that connects out to the Internet, will be on the same subnet as the default gateway of this security gateway, because that's how routing works. I need an interface on the same subnet as the next hop, my default gateway, to be able to communicate with it. So the interface that is on the same subnet as the security gateway's default router, the default next hop, is designated the external interface. Every other interface is designated an internal interface. And this is used by anti-spoofing. Anti-spoofing is a protection that is on by default, it does not allow traffic from the wrong subnet in from a specific interface. So perhaps my internal network is a 192.168.1.whatever/24 network. That interface, with anti-spoofing protection enabled, will drop any traffic that arrives on that interface from a different subnet. So any traffic from 192.168.1 that arrives on this internal interface, okay, we pass anti-spoofing. But if it comes from, say, 172.16.12.1, that's a different subnet, doesn't match the subnet that this interface is connected to, it's a spoofed packet. Somebody is forging the source IP address of outgoing traffic for some reason. Now, sometimes anti-spoofing breaks valid traffic, it drops valid traffic. And when that happens, it's almost always because you have a more complicated network infrastructure connected to this interface than Check Point knows about. For instance, you may have another internal network, 172.16.12/24, that routes through the 192.168.1 subnet to get to the firewall. You have to configure the interface for the firewall to reflect the reality of your network topology, that this interface will see traffic from 192.168.1, but it will also see traffic from 172.16.12. And the way you do that is you create A network object that represents the 192.168.1, subnet another network object that represents the 172.16.12 subnet. You create a network group object that has as its members, both of these network objects. And then [COUGH] in the leads to field at the top of the security gateway interface topology settings you override the default this network and that simply means whatever the network interface that were configuring it subnet. We should only see traffic from its subnet, that's a very simplified view but it's the default view. Instead we want to override it and say I have a specific network topology that you need to be aware of. And then you would select the network group that contains both the 192.168.1 network and the 172.16.12 network. It's currently grayed out because we have it set to the default of just use the interfaces subnet. I want to point out that grayed out button interface leads to DMZ, the demilitarized zone. Demilitarized zone is sort of a widely accepted best practice where few have servers that must accept incoming connections from the Internet. You segregate, you isolate those servers on a restricted network with its own hardware and you then lockdown security policy. So only the traffic that must be allowed in from the Internet is permitted only the traffic that must be allowed out to the Internet is permitted. And best case would be no traffic is permitted from the DMZ to my internal networks because since the host, the servers in the DMZ are directly exposed to the Internet, they are at a higher level of risk for being compromised. And let's make it harder for an attacker to jump from a DMZ server host to an internal server by blocking traffic. And that's not always possible, but allow only what must be allowed. This interface leads to DMZ button. What it actually does is inform some of the protections that traffic that comes in on this interface is from the DMZ and so can be treated differently. And that's used for instance by the antivirus software blade, you can configure it to examine traffic that's coming into your internal network. But not traffic that's coming into the DMZ network because that's low risk, and we don't need the overhead, things like that. Also in this dialog box is the security zone. The security zone allows you to match traffic in your policy based on the type of interface the traffic arrived on. And by default internal interfaces are assigned to the internals security zone. And your external interface, the interface that is connected to the subnet that your default gateway is on, that interface is assigned to the security zone. And then these are objects that you can use to match rules in your policy. If the source is internal zone and the destination is external zone and the service is HTTP allow, will accept that traffic. So now I'm going to demonstrate finishing the configuration of a firewall host then adding that firewall host as a checkpoint object and setting up that object. At this point I have my web browser connecting to the web user interface of the security gateway appliance. And again recall that you're going to get an SSL warning because you're talking to a web server on a Linux host that initialized itself created its own internal certificate authority which is distinct from the checkpoint management servers internal certificate. And I'm presented with a website certificate digitally signed by the security gateways web server certificate authority, which I don't trust. And again best practice would be do not permit this sort of situation and definitely you should never be doing sensitive administration tasks like entering credentials over an SSL connection that's not secure. You're probably going to be okay, yeah, probably, but why not be sure. So I did what everybody does, I clicked through the SSL warning, and I have the login screen where the web user interface. And like the management server this security gateway appliance has not yet had the first time wizard run. So when I login to the web user interface, it presents the first time wizard. And I mentioned in our AD, the images are distinct between the installation image for management server and an installation image or security gateway. This is the security gateway appliance, so it's running the security gateway operating system image. But it looks just like the management server first time wizard at least to begin with. It allows me to configure the interface that will be used to manage this security gateway. And the IP address and subnet information for this first zero interface was entered when I did the installation of the appliance. You have a checkpoint appliance, you made probably don't have to install the operating system. Do you have to do some setup? This is not a checkpoint appliance, so I had to install the operating system. And just like on the management server, it wants some operating system level configuration. And again, you want to choose the hostname wisely, you don't want to have to change that. It's possible to change it, but it's a pain, And you need an IP, sorry, a DNS server IP address so that the security gateway host can resolve things like checkpoints update servers. So that it can download IPS signature updates if you have that, antivirus signature updates, if you have that. But also I talked about the checkpoint update service engine CPUs. And that will automatically check if there are any Gaia updates that are relevant for this host, need to be able to resolve the update servers. Correct time is important between the security gateway and the management server because secure internal communications, Uses Timestamp to prevent replay attacks and other things. Also certificates have a limited validity, and so we have to have an agreement about time between the management server and the security Gateway. Best practice would be set up your appliances to use network time protocol to sync against a common set of NTP servers which may be associated with your active directory deployment. If nothing else you can use publicly available NTP servers. For this demonstration I'm not going to set up NTP, but I do want to make sure the time zone is correct. And here it offers to be a security gateway and or security management server. You recall when I was running the first time wizard on the security management server it had no option to be a security gateway, that was grayed out. Again, that's because of that different image. It also has an option to be a multi domain server. That is grayed out, cannot be selected because this is a security Gateway image, but you may want to do a standalone deployment. So it does offer the option of installing a security management server as well, so this could be a standalone deployment. And that option is selected by default. So important safety note, uncheck the Security Management product option on a security gateway unless you intend to do a standalone installation. If you don't uncheck that it will be installed as a standalone installation and then you will not be able to correctly establish management sync from your actual management appliance. Here I can also designate whether or not this appliance is going to be used as part of a cluster, and there are currently two options for the clustering protocol, and Virtual Router redundancy protocol. I'm not going to set up clustering here, and you can leave this turned off, not part of a cluster, and then later enable it, so you don't have to make the decision yet. A security gateway may have a DHCP-assigned external IP address. You may not have a static IP address, and so it's asking is this a dynamically assigned IP address, DAIP? Normally not, but possible, in this case not. And now I need to provide an activation key to bootstrap the secure internal communications. This activation key, which I have managed to type in wrong, is used when you are creating the checkpoint security gateway object in smart dashboard. You provide the same activation key there. Meanwhile, as I install this security gateway and it completes the first time wizard, finishes its configuration, and it will restart the operating system because now we know we're a security gateway, we're going to install the firewall kernel module and so on. When that is done, the security gateway will be a firewall and it will have what's called the initial policy in effect, because I haven't yet sent a policy to the security gateway, it comes with an initial policy. That initial policy is very simple,it essentially says any network connections that this appliance wants to initiate out are allowed. And pretty much the only incoming connections that are permitted are the web user interface secure shell and secure internal communications. We don't know who our management server is going to be yet, so we accept incoming secure internal communication initiation connections from any IP address. Okay, that could be dangerous, so we protect it by a shared secret, this activation key. And when I create the object in smart console, I provide the activation key and I tell smart console to tell the management server initialize secure internal communications. There'll be a challenge response exchange where the management server has to prove it's the correct, bonafide, genuine management server, demonstrating that it knows the activation key. And so if it knows the correct activation key, you're my management server, I will trust you and will import the internal certificate authority information and so on. So this device is going to be a security gateway, not a standalone installation, so it's not going to be a security gateway and security management server. Confirm that I want the first time wizard to start the configuration process, and this is going to run for a while so I'll pause and come back when it's completed. So at this point the first time wizard has completed successfully, and as part of the first time wizard configuring a security gateway, it restarted the operating system. And when that happened, my web user interface session was lost, doesn't survive a reboot. You may recall with the management server, when the initial configuration completed there, it just took me into the web user interface that you normally see on Gaia host. I didn't have to log back in because there was no restart when the management server was configured. There is a restart with the security gateway, and you can see the web user interface looks the same on a security gateway versus a management server. Because it's an operating system level thing, though the specific options on the left hand menu, they differ a little bit. This doesn't offer me any options related to a management server. So the next thing I want to do is configure the other network interfaces. So this device has three physical interfaces, eth zero, which is my management interface, and that's already set up, that's how I'm communicating with Gaia host. And next I want to configure the internal network interface, eth one, so important to select that enable box that actually brings the link up when you apply the new configuration. The comment field is entirely optional, it's really just displayed here in the web user interface, and if you use the CLI as displayed there. Then I'm going to go ahead and use the 192.168 network for this example. And a subnet mask of 255 255 255 0, which is equivalent to a slash 24. And when I click OK that configuration change is applied, and you can see scrolling off to the right a little bit, it has the comment really squished down there. I also want to configure the external interface. Again, I want to make sure it's enabled. So now my interfaces are configured. Another thing I should do is set up at least one default gateway, add routes as needed. So there is this default get gateway object here in the web user interface, but it doesn't have any IP addresses or interfaces assigned to it. I'm going to add an IP address for the next hop, the default gateway. This is going to be on the same subnet as my external interface's IP address. And now I have a default route out to the Internet. Next I'll bring up smart console, and I'm going to create a security gateway object. So up here, this allows you to create a new object, and it's going to be a gateway object. I have two options for how I want to proceed in the smart console GUI. I can use wizard mode which is simplified, but I'm going to go ahead and choose classic mode so you can see more of the options. So right now it's busy creating this security gateway object, initializing it, and since we're on a virtual environment it's slow. You want to name the object the same host name as you configured in the operating system. So the operating system I used a-gateway, I'll use that here. Then provide the IP address that this management server should use to communicate with the security gateway. So I'm going to use the management interface's IP address on the security gateway. Next, secure internal communications. I have to provide the same one time shared secret, the activation key, that I provided during the initial configuration wizard. And don't click OK, that's a trap. You need to click the initialize button here, which transmits the activation key to the management server. The management server then establishes a connection to the security gateway, proves its identity by proving it knows the same activation key. And then the internal certificate authority information from the management server is sent to the security gateway. This is your trusted certificate authority. Also, certificate for the security gateway is digitally signed by the management server. So when the security gateway participates in future secure internal communications, it proves its identity by presenting a certificate that is digitally signed by the internal certificate authority that all of my checkpoint components trust. So once I okay out of that secure internal communications dialogue, the gateway's topology is fetched. And the gateway's topology is just a list of its network interfaces, their IP addresses and subnet masks, and the default gateway. So the default gateway is on the same subnet as eith two, so eith two is automatically designated the external interface. And anything that doesn't have a default gateway on the same subnet is automatically designated an internal interface. I will go ahead and dismiss that. If I then select the network management screen, you can see that the interfaces have been populated in this security gateway object. And if I edit a specific interface, I can see the properties of this interface, including the fact that the topology for this interface is just the interface's subnet. I haven't set anything more complicated. Security zone by default is not set, but you can do that by editing. And you can specify a specific security zone, for instance, there is a wireless zone for your guest Wi-Fi, DMZ zone which is another way of designating this interface is used for DMZ. The interface leads to DMZ radio button that's grayed out, essentially informs layer seven protections that this is the DMZ interface. The DMZ zone security zone is just an object that you can use in your security policy to say, hey, if the traffic is coming from this DMZ zone and the destination is my internal zone, deny that. I'm going to leave it to the checkpoint software to determine what the appropriate security zone is. Since this is an internal interface, it chooses by default internal zone. And so I'll just select that. [COUGH] And the anti-spoofing checks by default are enabled, you can disable anti-spoofing checks on a given interface. But if you do that, you will get warned incessantly. Every time you install policy there will be warnings about this object has an interface that Doesn't have anti-spoofing protection enabled. You can ignore the warnings. There's really, in my opinion, no compelling reason to disable the anti-spoofing protections if traffic is being dropped for being spoofed. That probably means is you need to go in and change the network topology settings from the default. Hey, it's just whatever subnet this interface is on. And describe to checkpoint what the actual network topology is behind that interface. That will usually, almost always, cure your traffic if being dropped for being spoofed. You can also disable it another way by setting the protections action to detect instead of prevent. So to log when it sees spoof traffic, but it won't drop it for being spoofed. Not a best practice. So I've configured my management interface be the internal zone, security zone. Or my internal network interface, Being slow to edit. I want to do a little bit more. This interface, I do want to set it to be the internal zone, security sone as well. But I also want to describe a more complex internal network topology than it's simply the subnet of this interface. So I'm going to tell it I have a specific topology to give you. And there are some predefined objects. Those aren't appropriate for this. I'm going to create a new network object that represents the primary internal network that this interface is on. This network as the IP address range of 192.168.1 dot whatever. That's a 255.255.255.0 subnet and the broadcast address option here, really just if somebody sends traffic to 192.168.1.255, which would be the broadcast address for this specific subnet. Should that be matched in this group or should it not match this group? And the default is let it match. I'm going to create another network object to represent a different internal network that is routed through my internal 192.168.1 network. Now I have these two network objects. I can only list one object here for the topology, so what I need to do is create a network group object, And add, The internal network object that I created, and the other internal network object that I created. And now that these two objects are in this network group object, I select the network group object as the topology for the network that this interface is connected to. And now anti-spoofing for this interface will accept incoming traffic from the 192.168.1 subnet, but also from the 172.16.12 subnet. For my third interface, the external interface, I want to set the security zone to be appropriate for the external interface. And again, checkpoint knows that this is the external interface because the subnet of this interface is the same subnet as the default gateway for this host. Well, this must be the interface that leads to the default gateway, that's the interface it gets us out to the internet, that by default is our external interface. So for the external interface, checkpoint will automatically select the external zone security zone object. And anti-spoofing is a little bit different on an external interface. When traffic is received on an external interface, we look to see is the source IP address of this traffic on any internal subnets that behind any of my internal interfaces. If so, why is the internet sending me traffic that says it's from one of my internal networks? That's spoofed, and I'll drop the traffic. So in an external interface, anti-spoofing checks to make sure that you aren't sending traffic for many internal network. On an internal interface, anti-spoofing checks is the traffic appropriate to this interface by default? Is it the same subnet as this interface? I've configured the network interfaces for this security gateway object. I wanted to just briefly point out, The log option here by default, logs are sent to the security sateway as management server. In a small deployment, that's fine. In a larger deployment, [COUGH] I may want to override the default log destination. And instead of sending it to my normal management server, I have a dedicated log server that logs should go too. A lot of the bulk of network traffic that process from the internet to your internal networks and back is HTTPS. There's HTTP as well, but more and more websites are deploying HTTPS because certificates are now free from certain certificate authorities. And there have been practical demonstrations of attacks on, for instance, session cookies, that if you're using HTTP, are being transmitted in plain text and are susceptible to sniffing and copying. So more and more websites are just doing HTTPS all the time. Which is good, that's secure. But the layer seven inspection protections, they lose visibility into HTTPS traffic because it's encrypted inside of a TLS tunnel. Checkpoint can intercept and decrypt HTTPS. It can decrypt the TLS and it does that by essentially launching a man in the middle attack. And as part of the man in the middle attack, the HTTPS inspection will create a fake certificate for the destination website. You were going to facebook.com, we'll create a fake certificate that says it's for facebook.com. And it will be digitally signed by a certificate authority that your web browsers don't trust by default. So if you want to enable HTTPS inspection, you either create a certificate authority on the security gateway, or you can create a certificate authority somewhere else like active directory. Then create a certificate for the gateway, that's digitally signed by your active directory certificate authority and import that into the security gateway. So it's not using its own certificate authority. It's using a trusted internal certificate authority, which again, is not the checkpoint management server internal certificate authority. It's only used for sick, it's used for other things such as VPNs, but I digress. Then activate the HTTPS inspection module service on the security gateway and now HTTPS inspection policy will decide if a given HTTPS connection out to some destination website should be decrypted or not. But we're not going to set that up now. I also want to just briefly point out the software blades here. All of these check boxes are software blades which are really just additional functionality, additional features that can be enabled on the security gateway. Every security gateway must have the firewall software blade enabled, because that provides the packet filtering and stateful inspection which are required to be a security gateway. Other protections depends on what you've licensed. So I save this object by clicking OK, and what I've done actually is made changes to my checkpoint configuration in this smart console session and those changes have yet to be published to the master, if you will, smart managment server database. So, if you have multiple administrators who are signed in via Smart console to the same management server, they can work simultaneously, concurrently, but changes that I make are not available to other administrators until I publish, though I can publish by clicking on this button here. Best practice would be to include a description of what changes you're publishing. Though it's in the audit logs. And then the publishing operation. It should not take long. I'm on a virtual environment. So we'll take longer than normal. Once the publishing operation is completed, then up at the top of Smart console, you'll see the number of unpublished changes goes away because I've published the changes. Also, my changes are now visible and accessible to other administrators. Any changes that they make that they publish become visible to my smart console. So now the gateway in servers view, there are two checkpoint objects listed. The management server, which it created the object as part of its initialization. It knows about itself and the gateway. We don't yet have status for the gateway among other things. The Gateway isn't properly licensed nor is the management server. There's a 15 day trial period where you don't need a license. After the first time wizard completes, when the 15-day trial is done, you need a license. So I demonstrated the first time Wizard final configuration of a security Gateway. And then as part of that, giving an activation key, which is used to bootstrap secure internal communications with Security Management server. We also looked at creating the security Gateway object in Smart dashboard and configuring that object. Verifying that the topology is correct, that it's in the correct security zone, and we also looked at creating a group of network objects to facilitate a more complicated internal network structure. So that this more complicated network structure doesn't have traffic drop by the anti-spoofing protections. And that's it for this module. We looked at the Firewall Kernel just briefly and network models. We discussed packet filtering which is layer three layer four versus stateful inspection, which is layer three layer four. But we can also designate traffic to be examined at higher layers, which leads to the application Layer Firewalls, which has layer seven awareness of protocols and can provide protections that are specific to a protocol. We looked at the two major deployment options, Standalone, where the management server is on the same host as the security Gateway. And distributed which is the most common where the management server is its own appliance, security gateway is its own appliance. Anti-spoofing protection, which is on by default and security zones, which you can use in your policy demonstrated this, So thank you for attending this module of jump start training.
