Friday, December 28, 2018
fw monitor debugging traffic
If SecureXL is on, please turn off the secureXL
#fwaccel off // to turn it off
#fwaccel stat // to check status
#fw monitor -e "accpet host(srcIP) and host(dstIP);" -o filename.pcap
eg:
#fw monitor -e "accept host(17.16.202.89) and host(100.25.219.39) or host(100.25.219.39);" -o captures.pcap
#fwaccel on // to turn on SecreXL
Run below traffic captures at internal and external interface:
tcpdump -t -enni <interface_name> host Src.IP and host dst.IP
tcpdump -t -enni eth2-04 host + and host 208.94.8.8 -w filename1.pcap
fwaccel off
fw monitor -e "accpet host(17.16.202.80);" -o filename.pcap
fw ctl zdebug drop | grep 17.16.202.80
fw monitor -e "accept host(17.16.202.80);"
fw monitor -e "accept host(17.16.202.80);" -T -T is for time stamp
[fw_0] 20Dec2018 10:35:28.713159 eth2-04:I[200]: 17.16.202.80 -> 10.13.4.17 (UDP) len=200 id=2656 UDP: 24628 -> 9980 [vs_0]
[fw_0] 20Dec2018 10:35:28.713168 eth2-01:o[200]: 17.16.202.80 -> 10.13.4.17 (UDP) len=200 id=2656 UDP: 24628 -> 9980 [vs_0]
[fw_0] 20Dec2018 10:35:28.713175 eth2-01:O[200]: 17.16.202.80 -> 10.13.4.17 (UDP) len=200 id=2656 UDP: 24628 -> 9980 [vs_0]
[fw_0] 20Dec2018 10:35:28.720730 eth2-01:i[200]: 10.25.220.68 -> 17.16.202.80 (UDP) len=200 id=37057 UDP: 21416 -> 21898 [vs_0]
[fw_0] 20Dec2018 10:35:28.720749 eth2-01:I[200]: 10.25.220.68 -> 17.16.202.80 (UDP) len=200 id=37057 UDP: 21416 -> 21898 [vs_0]
I and i are for In
O and o are for Out
Upper Case I is for after Inspection
lower case i is for before inspection
Thursday, November 8, 2018
Troubleshooting Tools
Troubleshooting Tools
Take into consideration the following:
1. If you have a cluster, this command will show traffic flowing through the active firewall.
a. To check active status issue: cphaprob state
2. If you have SecureXL enabled, some commands may not show everything.
a. To disable SecureXL: fwaccel off
b. To enable SecureXL: fwaccel on
“fw monitor” command
fw monitor -e “accept host(x.x.x.x);”
Example
CP-Firewall> fw monitor -e "accept host(192.168.1.86);"
Compiled OK.
1-way network flow:
fw monitor -e “accept (src=x.x.x.x and dst=x.x.x.x); ”
Example (from 173.16.25.44 to 192.168.2.134)
CP-Firewall> fw monitor -e "accept (src=173.16.25.44 and dst=192.168.2.134); "
2-way network flow:
fw monitor -e "accept (src=x.x.x.x and dst=x.x.x.x) or (src=x.x.x.x and dst=x.x.x.x);"
Example (from/to 172.16.125.81 to 192.168.1.84)
CP-Firewall> fw monitor -e "accept (src=172.16.125.81 and dst=192.168.1.84) or (src=192.168.1.84 and dst=172.16.125.81);"
monitorfilter:
In this example, you can see the ingress interface (eth3) and the egress interface (eth1). Also, you can see the 4 capture points (iIoO):
pre-inbound i (lowercase i)
post-inbound I (uppercase i)
pre-outbound o (lowercase o)
post-outbound O (uppercase o)
You can also use set the capture points:
CP-Firewall> fw monitor -e "accept host(192.168.1.86);" -m iO
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_6] eth3:i[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000
[vs_0][fw_6] eth1:O[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000
- fw monitor
- fw ctl zdebug + drop
Take into consideration the following:
1. If you have a cluster, this command will show traffic flowing through the active firewall.
a. To check active status issue: cphaprob state
2. If you have SecureXL enabled, some commands may not show everything.
a. To disable SecureXL: fwaccel off
b. To enable SecureXL: fwaccel on
“fw monitor” command
fw monitor -e “accept host(x.x.x.x);”
Example
CP-Firewall> fw monitor -e "accept host(192.168.1.86);"
Compiled OK.
1-way network flow:
fw monitor -e “accept (src=x.x.x.x and dst=x.x.x.x); ”
Example (from 173.16.25.44 to 192.168.2.134)
CP-Firewall> fw monitor -e "accept (src=173.16.25.44 and dst=192.168.2.134); "
2-way network flow:
fw monitor -e "accept (src=x.x.x.x and dst=x.x.x.x) or (src=x.x.x.x and dst=x.x.x.x);"
Example (from/to 172.16.125.81 to 192.168.1.84)
CP-Firewall> fw monitor -e "accept (src=172.16.125.81 and dst=192.168.1.84) or (src=192.168.1.84 and dst=172.16.125.81);"
monitorfilter:
In this example, you can see the ingress interface (eth3) and the egress interface (eth1). Also, you can see the 4 capture points (iIoO):
pre-inbound i (lowercase i)
post-inbound I (uppercase i)
pre-outbound o (lowercase o)
post-outbound O (uppercase o)
You can also use set the capture points:
CP-Firewall> fw monitor -e "accept host(192.168.1.86);" -m iO
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_6] eth3:i[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000
[vs_0][fw_6] eth1:O[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000
Wednesday, November 7, 2018
IP Subnetting
The main purpose of subnetting is to help relieve network congestion.
1. Improve network performance and speed
2. Reduce network congestion
3. Boost network security
4. Control network growth
5. Ease administration
Bits Subnet-Mask
11111111 /32 .255
1111111 /31 .254
111111 /30 .252 64 Nets 2 hosts
11111 /29 .248 32 Nets 6 hosts
1111 /28 .240 16 Nets 14 hosts
111 /27 .224 8 Nets 30 hosts
11 /26 .192 4 Nets 62 hosts
1 /25 .128 2 Nets 126 hosts
Class C first octet 192-223
/24 .0
/23 .254
/22 .252
/21 .248
/20 .240
/19 .224
/18 .192
/17 .128
Class B first octet 128-191
/16 .0.0
/15 .254
/14 .252
/13 .248
/12 .240
/11 .224
/10 .192
/9 .128
Class A first octet 1-126
/8 .0.0.0
/7 .254
/6 .252
/5 .248
/4 .240
/3 .224
/2 .192
/1 .128
/0
Example Giving 172.16.200.0/29
1. How many Networks are created?
2. How many Hosts are created?
3. What is the Network Number?
4. What is the Subnet mask?
5. What is the Broadcast?
Calculation
For a /24 network 00000000 to be used as a /29 11111000, it means, you will have to borrow 5 host bits 11111 to be used as network, and that leaves us with 3 bits 000 for hosts.
11111000 /29 .248 32 Nets 6 hosts
1. How many Networks are created?
Formula n^2 (number of network bits raised to the 2nd power)
n^2 = 5^2 = 32 Networks created
2. How many Hosts are created?
Formula 2^n -2 (2 raised to the number of host bit power, minus 2 for network mask and subnet mask.
2^n -2 = 2^3 -2 = 8-2 = 6 hosts per subnet
3. What is the Network Number?
Examples of the 32 subnets
172.16.200.0/29 Network .0 Hosts .1 .2 .3 .4 .5 .6 Broadcast .7
172.16.200.8/29
172.16.200.16/29
172.16.200.24/29
172.16.200.32/29
172.16.200.40/29
172.16.200.48/29
172.16.200.56/29
172.16.200.64/29
4. What is the Subnet mask?
1 1 1 1 1 0 0 0
00000000 = 2^7 + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 2^0
11111000 = 128 + 64 + 32 + 16 + 8 + 0 + 0 + 0
= 248
So subnet mask = 255.255.255.248
5. What is the Broadcast?
172.16.200.0/29 = Network 172.16.200.0 subnet mask 255.255.255.248 net mask /29
Broadcast 172.16.200.7
IP Addressing IP addressing refers to assigning a 32-bit logical numeric address to a network device. Every IP address on the network must be unique. An IP address is represented in a dotted decimal format, for example: 159.101.6.8
As you can see the address is divided in 4 parts, these parts are called octets. IP is defined at Layer 3 (Network layer) of the OSI model and is routable. In order to be routable a network address must have two parts: a network and a host portion. Subnet masks are used to determine which part represents the network portion and which part represents the host portion. By default the subnet mask is based on the class to which the IP address belongs. The following table lists the classes and corresponding values of the first octet (in the IP address) and the default subnet mask.
| Major classes | First octet | Default mask |
| Class A | 1 - 126 | 255.0.0.0 |
| Class B | 128 - 191 | 255.255.0.0 |
| Class C | 192 - 223 | 255.255.255.0 |
Subnetting
Before we go to actually calculating subnets (i.e. subnetting) I want to stress the meaning of the word “subnet mask”. As the name implies, it is a mask that determines what portion of an IP address is the (sub-)network portion. Combined with knowing the class of the IP address it also determines the number of subnets. Although that automatically gives us the host portion as well, it important to realize the class does not influence the number of hosts in a subnet. For example, a class A network with a subnet mask of 255.255.255.0 allows for 254 hosts, which is the same for a class B or class C network with the same subnet mask of 255.255.255.0.
So to determine the maximum number of hosts in a (sub-)network, all you need to know is the subnet mask, or even better: the “prefix”. The class and even the IP address itself are irrelevant when it comes to calculating the maximum number of hosts.
For example, a typical subnetting exam questions might present you with an IP address and a subnet mask or prefix and ask for the total number of hosts and/or subnets. Let’s say the network address is 192.168.1.0 255.255.255.224. To determine the number of hosts we need to translate the mask to a prefix, because that gives us the maximum number of bits we have left for hosts. In this case the prefix is /27 (we’ll get to translation process in detail later) which leaves 5 bits from the 32 bits in an IPv4 address in total. So that’s 5 bits for hosts, which is 5^2 = 32. However, the first address is the network address for the subnet, and the last is the broadcast address, so we need to subtract 2 for those, leaving us with 30 addresses for hosts.
Now, what if the IP address would have been 10.12.3.88, or 179.192.32.254? Or if no IP address was mentioned at all and all we got to go on was the mask? Exactly, it would have made no difference to the number of maximum hosts. So to conclude, the subnet mask doesn’t merely determine what portion of a given IP address is the network portion and what portion is for host, but by itself, without any additional info, a subnet mask can tell you directly how much space it allows for host addresses “per subnet”.
More often we (also) need to know the number of subnets, for which we need one more piece of info than just the subnet mask or prefix, and that’s the class of the IP address. The IP address itself is again irrelevant, except for the first octet, which as shown in the intro above determines the class.
So far we stressed the importance of knowing the prefix and knowing the default subnet mask for the major IP address classes. There is one more thing you need to add to your subnetting toolkit, or actually should be in there already, and that is basic binary math. In particular there are two essential “formulas” you cannot do without:
1. Calculate the maximum number of different decimal values a given amount of bits can represent:
This is really basic binary math. 1 bit allows for 2 different values, 2 bits allows for 4 different values, 3 bits allow for 8 different values. So for every bit you add, the number of possible different values doubles. This can also be written as b^2 where b is the number of bits. Memorizing the first 10 or so is as easy as learning basic multiplication tables back in high school:
1 bit – 2 values
2 bits – 4 values
3 bits – 8 values
4 bits – 16 values
5 bits – 32 values
6 bits – 64 values
7 bits – 128 values
8 bits – 256 values
9 bits – 512 values
10 bits – 1024 values
Again, extending the list is easy because all you need to do is double the previous amount of values for every bit you add. Just remember to start with 2 for the first bit (value 0 and value 1).
The b^2 formula is used to determine the maximum number of subnets and the maximum number of hosts per subnet. For example if you have a class B network with a prefix of /18 you have 2 bits for subnets, which according to the formula and table above means space for 4 different subnets.
When determining the maximum number of hosts in a subnet you need to subtract 2 of the results, one for the network address of the subnet and one for the broadcast address. So basically the formula for hosts is (b^2) - 2.
2. Translate octets from their binary value to their decimal equivalent and back.
The second “bit” of binary math you need to master is translating 8 bits (a byte) to its decimal equivalent (an octet). So instead of looking for the maximum number of different values, we’re going to determine the actual decimal value a given number of bits represent.
Each octet represents 8 bits, for example the IP address 159.101.6.8 mentioned earlier can also be displayed in dotted binary format: 10011111.01100101.00000110.00001000
Converting the decimal address to a binary format (and vice versa) is a fairly easy process. The lowest decimal number you can represent with 8 bits is 0 (when all bits are zero, as in turned off), the highest is 255 (all bits turned on) as shown in the following translation table:
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| 128 + | 64 + | 32 + | 16 + | 8 + | 4 + | 2 + | 1 | = 255 |
| 0 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | |
| 0 + | 0 + | 0 + | 0 + | 8 + | 4 + | 0 + | 1 | = 13 |
| 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |
| 128 + | 0 + | 32 + | 0 + | 8 + | 0 + | 2 + | 0 | = 170 |
| Binary | Decimal |
| 00000000 | 0 |
| 00000011 | 3 |
| 10000000 | 128 |
| 10000001 | 129 |
| 10111111 | 191 |
| 11111010 | 250 |
Although this works for IP addresses and subnet masks, the latter are a little special. In subnet mask the bits are always consecutive. For example, the subnet mask 255.0.0.0 is written in binary as 11111111.00000000.00000000.00000000 and the subnet mask 255.255.240 is written as 11111111.11111111.11110000.00000000. The number of consecutive ‘1’ bits equals the prefix. So for the first example, the subnet mask 255.0.0.0, the prefix is 8 bits, and for the last example, the subnet mask 255.255.240, the prefix is 8+8+4=20 bits. To determine the decimal value for the third octet (11110000) we add up the first 4 values (1 for each bit turned on) in our translation table, starting from the left: 128+64+32+16 = 240.
After some practice this should become basic and easy math, but since the bits in a mask are always consecutive there is a limit to amount of possible values in a mask. Specifically the following 8:
8 bits = 11111111 = 128+64+32+16+8+4+2+1 = 255
7 bits = 11111110 = 128+64+32+16+8+4+2= 254
6 bits = 11111100 = 128+64+32+16+8+4 = 252
5 bits = 11111000 = 128+64+32+16+8 = 248
4 bits = 11110000 = 128+64+32+16 = 240
3 bits = 11100000 = 128+64+32 = 224
2 bits = 11000000 = 128+64 = 192
1 bits = 10000000 = 128 = 128
0 bits = 00000000 = 0 = 0
Simplified the table looks like this:
8 bits = 255
7 bits = 254
6 bits = 252
5 bits = 248
4 bits = 240
3 bits = 224
2 bits = 192
1 bits = 128
0 bits = 0
The decimal values on the right are the only valid values you will find in a subnet mask and I highly recommend memorizing this table (and if needed dump it on the sheet you get during the exam for quick reference). Besides translating individual octets, the table above is very helpful to determine the prefix based on the subnet mask. For example, the subnet mask 255.255.192.0 obviously equals a prefix of 8+8+2= /18. The other way around is almost as easy and becomes more obvious when written in binary format. For example, if you take the prefix /25 and write it in binary format you end up with:
11111111.11111111.11111111.10000000
This according to our table, if we translate the octets individually, is 255.255.255.128. Basically for every prefix above /8 you subtract 8 and write an octet of 255 until you have 8 bits or less left.
Determine the network and broadcast address
Besides calculating the number of subnets and hosts, another common task regarding subnetting is to determining the network and broadcast address for a given subnet. The network address is the first address in a subnet and the broadcast address is the last address. For example, in the class C network 192.168.1.0 using the default subnet mask 255.255.255.0 (a prefix of /24), the network address is 192.168.1.0 and the broadcast address is 192.168.1.255. When you divide this network into subnets, each subnet will get its own network address and broadcast address. For example, if we divide it into two subnets by using a subnet mask of 255.255.255.128, the network address of the first subnet is 192.168.1.0 and the broadcast address is 192.168.1.127. The network address for the second subnet would be 192.168.1.128 and the broadcast address 192.168.1.255.
In a class C network, or any other network with a prefix of 24 or more, it is easy to determine the network address and broadcast address by simply adding up the number of hosts per subnet, butin general writing out the addresses in binary format is the way to go. For example, to determine the network address of the subnet in which the IP address 10.4.220.36 with subnet mask 255.255.248.0 (prefix 21) resides:
| Subnet A | 00001010.00000100.11011100.00100100 |
| Subnet B | 11111111.11111111.11111000.00000000 |
| ------------------------ | ----------------------------------------------------- |
| Network Address: | 00001010.00000100.11011000.00000000 |
| Network Address: | 00001010.00000100.11011000.00000000 |
| Broadcast Address: | 00001010.00000100.11011111.11111111 |
The valid host range for a subnet consists of all addresses between the network address and the broadcast address.
VLSM
VLSM stands for Variable Length Subnet Masking and allows you to use the available address space more efficiently. For example, if you divide a class C network into two subnets, you can still divide one of the two subnets into additional subnets. An example network using VLSM is depicted below:
In this example network, a Class C network is divided into variable length subnets. Subnet A uses a prefix of /25, which basically divides the network into two subnets (a class C uses 24 bits for the network portion by default, so 1 additional bit is used for subnets, which allows for 2 different subnets).
Subnet A: 192.168.0.0/25 ranges from 192.168.0.0 – 192.168.0.127, allowing for 126 hosts in total (after subtracting the network address and broadcast address for the subnet). Without VLSM that would automatically leave us with 192.168.0.128 – 192.168.0.255 for the second subnet. However, by assigning a higher prefix/mask to the second subnet we can divide it further into smaller subnets.
Subnet B: 192.168.0.128/26 ranges from 192.168.0.128 – 192.168.0.191, allowing for 64 addresses, minus two for the network (192.168.0.128 ) and broadcast address (192.168.0.191) leaves 62 valid host addresses.
That still gives us 192.168.0.192 – 192.168.0.255, which could be used for another subnet with 62 hosts, but can also be divided into smaller subnets yet again:
Subnet C: 192.168.0.192/27 ranges from 192.168.0.192 – 192.168.0.223, allowing for 30 hosts. To summarize, we end up with the following subnets:
| Subnet | Network Address | Hosts |
| Subnet A | 192.168.0.0/25 | 126 |
| Subnet B | 192.168.0.128/26 | 62 |
| Subnet C | 192.168.0.192/27 | 30 |
| Unassigned | 192.168.0.224/27 | 30 |
Supernetting
Supernetting is more or less the opposite of subnetting but instead of dividing networks into subnets, networks can be combined in to a larger supernet. In practice this comes down simply to using a smaller prefix/mask than the default for a particular class. For example, a class C network with a prefix of /23 (mask: 255.255.254.0) would allow for twice as many hosts as a regular “classful” class C network using the default mask of 255.255.255.0. The supernet 192.168.0.0/23 for example ranges from 192.168.0.0 - 192.168.1.255 (the first being the network address, the last being the broadcast address and everything in between, 510 addresses, for hosts).
Thursday, October 18, 2018
Checkpoint Gaia R80.20
There are two different installation ISOs for R80.20:
- One that supports gateways and standalone installs with the older (2.6.18) kernel
- One for Security Management only that has the newer (3.10) kernel
So yes, you can upgrade a standalone to R80.20.
After playing around with R80.20GA gateway for a few hours, the following things caught my eye:
1) Gaia is now required to be 64-bit.
2) Geo Protection can now be directly configured in a whitelist configuration (allow some countries and deny all others).
3) R80.20 gateway ClusterXL does not support Load Sharing (Active/Active) yet? Not a huge fan of load sharing to begin with but this is taking it to another level... :-)
4) R80.20 gateways cannot be managed by an R80.20M1 SMS.
5) cphaprob state command now reports *far* more detail about ClusterXL state, including why the current member is active, last state transition & failover count, and active pnote problems. This extra information appears to be available separately via the new cphaprob show_failover command.
6) cphaconf set_ccp has two new options: auto and unicast (the latter only works with a 2-member cluster); used to just be broadcast and multicast.
7) Syn Attack (Syn Flood) protection is now implemented in SecureXL and will not cause all traffic handled by it to go F2F.
8) The undocumented ability for certain ports to be bypassed in the Dynamic Dispatcher appears to be officially supported via the fw ctl multik add_bypass_port command among others.
9) The new fw ctl multik get_instance command can be used to identify which Firewall Worker core is handling a connection with the matching attributes specified on the command line.
10) The new fw ctl multik print_heavy _conn command will show the attributes of all "heavy" (elephant flow) connections currently pounding the Firewall Worker cores.
11) The new fw ctl multik utilize command will show the size & utilization of the Firewall Worker packet queues.
12) Many new screens added to cpview including Dynamic Routing Stats (routed), Hardware Health & Sensors, Disk I/O utilization, and Advanced...CPAQ.
13) Apparently fw monitor can now capture all traffic traversing the firewall regardless of whether it is accelerated by SecureXL. Haven't had a chance to verify this myself yet.
14) The long-awaited Network defined by routes antispoofing topology option checks the gateway routing table every second for any route changes that might impact antispoofing enforcement, the timer controlling this interval is located in the SmartConsole under Manage & Settings...Preferences.
15) I don't see the option to define VPN domains per VPN Community, at least not in the SmartConsole.
16) Ensuring that "Font Smoothing" is enabled in your RDP client substantially improves the graphical performance of the SmartConsole inside an RDP Session.
Load Sharing (Active/Active) configuration
Load Sharing here is the Known Limitation from sk122486: R80.20 GA and R80.20 Management Feature Release Known Limitations
| MB-30 |
R80.20 ClusterXL does not support Load Sharing mode. Therefore, R80.20 SmartConsole blocks such configuration with a warning message.
This limitation is planned to be resolved during H1 2019.
|
R80.
|
just because you were able to do so doesn't mean it is a supported configuration based on the above.
R80.20, part of the Check Point Infinity architecture, delivers the most innovative and effective security that keeps our customers protected against large scale, fifth generation cyber threats.
The release contains innovations and significant improvements in:
- Gateway performance
- Advanced Threat Prevention
- Cloud Security
- Access policy
- Consolidated network and endpoint management capabilities
- And much more
This release is initially recommended for customers who are interested in implementing the new features. We will make it the default version (widely recommended) after significant adoption and make it available in the 'Showing Recommended Packages' section in the CPUSE tab in Gaia portal.
Performance Enhancements
Performance Enhancements
- HTTPS Inspection performance improvements
- Session rate improvements on high-end appliances (13000, 15000, 21000 & 23000 Security Gateway models).
- Acceleration remains active during policy installation, no impact on Security Gateway performance.
VSX Gateways
- Significant boost to Virtual Systems performance, utilizing up to 32 CoreXL FW instances for each Virtual System.
- Dynamic Dispatcher - Packets are processed by different FW worker (FWK) instances based on the current instance load.
- Changes in the number of FW worker instances (FWK) in a VSLS setup do not require downtime.
- SecureXL Penalty Box supports the contexts of each Virtual System, see sk74520.
Advanced Threat Prevention
- Enhanced configuration and monitor abilities for Mail Transfer Agent (MTA) in SmartConsole for handling malicious mails.
- Configuration of ICAP Server with Threat Emulation and Anti-Virus Deep Scan in SmartConsole.
- Automatic download of IPS updates by the Security Gateway.
- SmartConsole support for multiple Threat Emulation Private Cloud Appliances.
- SmartConsole support for blocking archives containing prohibited file types.
- Threat Extraction
- Full ClusterXL HA synchronization, access to the original files is available after a failover.
- Support for external storage.
- Advanced Threat Prevention Indicators (IoC) API
- Management API support for Advanced Threat Prevention Indicators (IoC).
- Add, delete, and view indicators through the management API.
- Advanced Threat Prevention Layers
- Support layer sharing within Advanced Threat Prevention policy.
- Support setting different administrator permissions per Advanced Threat Prevention layer.
- MTA (Mail Transfer Agent)
- MTA monitoring, e-mails history views and statistics, current e-mails queue status and actions performed on e-mails in queue.
- MTA configuration enhancements
- Setting a domain object as next hop.
- Ability to create an access rule to allow SMTP traffic to a Security Gateway.
- Create a dedicated Advanced Threat Prevention rule for MTA.
- MTA enforcement enhancements
- Replacing malicious links in an email with a configurable template.
- Configurable format for textual attachments replacement.
- Ability to add a customized text to malicious e-mails' body or subject.
- Tagging malicious-mails using X-header
- Sending a copy of the malicious e-mail to a predefined recipients list
- Improvements in policy installation performance on R80.10 and above Security Gateways with IPS
- Performance impact of "Suspicious Mail Activity" protection in Anti-Bot was changed to "High" and is now off by default
CloudGuard IaaS Enhancements
- Automated Security Transit VPC in Amazon Web Services (AWS) - Automatically deploy and maintain secured scalable architecture in Amazon Web Services.
- Integration with Google Cloud Platform.
- Integration with Cisco ISE.
- Integration with Nuage Networks.
- Automatic license management with the CloudGuard IaaS Central Licensing utility.
- Monitoring capabilities integrated into SmartView.
- Data center objects can now be used in access policy rules installed on 41000, 44000, 61000 and 64000 Scalable Platforms.
Access Policy
- Updatable Objects – a new type of network objects that represent an external service such as Office 365, Amazon Web Services, Azure GEO locations and more, and can be used in the Source and Destination columns of an Access Control policy. These objects are dynamically updated and kept up-to-date by the Security Gateway without the need to install a policy.
- Wildcard network object in Access Control that represents a series of IP addresses that are not sequential.
- Only for Multi-Domain Server: Support for scheduled policy installation with cross-Domain installation targets (Security Gateways or Policy Packages).
- Rule Base performance improvements, for enhanced Rule Base navigation and scrolling.
- Global VPN Communities (previously supported in R77.30).
- Support for using NAT64 and NAT46 objects in Access Control policy.
- Security Management Server can securely connect to Active Directory through a Security Gateway, if the Security Management Server has no connectivity to the Active Directory environment and the Security Gateway does.
Identity Awareness
- Identity Tags support the use of tags defined by an external source to enforce users, groups or machines in Access Roles matching.
- Improved SSO Transparent Kerberos Authentication for Identity Agent, LDAP groups are extracted from the Kerberos ticket.
- Two Factor Authentication for Browser-Based Authentication (support for RADIUS challenge/response in Captive Portal and RSA SecurID next Token/Next PIN mode).
- Identity Collector
- Support for Syslog Messages - ability to extract identities from syslog notifications.
- Support for NetIQ eDirectory LDAP Servers.
- Additional filter options - "Filter per Security Gateway" and "Filter by domain".
- Improvements and stability fixes related to Identity Collector and Web API.
- New configuration container for Terminal Servers Identity Agents.
- Active Directory cross-forest trust support for Terminal Servers Agent.
- Identity Agent automatic reconnection to prioritized PDP gateways.
- Security Management Server can securely connect to Active Directory via a Security Gateway if the Security Management Server has no connectivity to the Active Directory environment
HTTPS Inspection
- Hardware Security Module (HSM) support – outbound HTTPS Inspection stores the SSL keys and certificates on a third party dedicated appliance
- Additional ciphers supports for HTTPS Inspection (for more information, see sk104562)
Mirror and Decrypt
- Decryption and clone of HTTP and HTTPS traffic
- Forwarding traffic to a designated interface for mirroring purposes
Clustering
- New CCP Unicast - a new mode in which a cluster member sends the CCP packets to the unicast address of a peer member
- New Automatic CCP mode - CCP mode is adaptive to network changes, Unicast, Multicast or Broadcast modes are automatically applied according to network state
- Enhanced cluster monitoring capabilities
- Enhanced cluster statistics and debugging capabilities
- Enhanced Active/Backup Bond
- Support for more topologies for Synchronization Network over Bond interfaces
- Improved cluster synchronization and policy installation mechanism
- New grace mechanism for cluster failover for improved stability
- New cluster commands in Gaia Clish
- Improved clustering infrastructure for RouteD (Dynamic Routing) communication
Gaia OSUpgraded Linux kernel (3.10) - applies to Security Management Server only
- New file system (xfs)
- More than 2TB support per a single storage device
- Enlarged systems storage (up to 48TB)
- I/O related performance improvements
- Support of new system tools for debugging, monitoring and configuring the system
iotop(provides I/O runtime statistics)lsusb(provides information about all devices connected to USB)lshw(provides detailed information about all hardware)lsscsi(provides information about storage)ps(new version, more counters)top(new version, more counters)iostat(new version, more counters)Advanced Routing:
- Allow AS-in-count
- IPv6 MD5 for BGP
- IPv4 and IPv6 OSPF multiple instances
- Bidirectional Forwarding Detection (BFD) for gateways and VSX, including IP Reachability detection and BFD Multihop
- OSPFv2 HMAC-SHA authentication (replaces OSPFv2 MD5 authentication)
ICAP Client
- Integrated ICAP Client functionality
SmartConsole
- SmartConsole Accessibility features
- Keyboard navigation - ability to use the keyboard alone to navigate between the different SmartConsole fields
- Improved experience for the visually impaired, color invert for all SmartConsole windows
- Required fields are highlighted
- Multiple simultaneous sessions in SmartConsole. One administrator can publish or discard several SmartConsole private sessions, independently of the other sessions.
Logging and Monitoring
- Log Exporter - an easy and secure method to export Check Point logs over Syslog to any SIEM vendor using standard protocols and formats
- Ability to export logs directly from a Security Gateway (previously supported in R77.30)
- Unified logs for Security Gateway, SandBlast Agent and SandBlast Mobile for simplified log investigation
- Enhanced SmartView in browser:
- Log viewer with log card, column profile and statistics
- Export logs with custom or all fields
- Automatic-refresh for views
- Relative time frame support
- Improved log viewer with cards, profiles, statistics and filters
- I18N support for 6 languages (English, French, Spanish, Japanese, Chinese, Russian)
- Accessibility support - keyboard navigation and high contrast theme
SmartProvisioning
- Integration with SmartProvisioning (previously supported in R77.30)
- Support for the 1400 series appliances
- Administrators can now use SmartProvisioning in parallel with SmartConsole
Mobile Access
- Support for reCaptcha, keep abusive automated software activities from interfering with regular portal operations
- Support for One Time Password (OTP) without any hardware tokens
Endpoint Security Management ServerEndpoint Security Server is now part of the main train.
- Support for SandBlast Agent, Anti-Exploit and Behavioral Guard policies
- SandBlast Agent push operation to move/restore files from quarantine
- Directory Scanner initial scan and full rescan takes significantly less time
- Stability and performance enhancements for Automatic Synchronization (High Availability)
Endpoint Security Management features that are included in R77.30.03:
- Management of new Software Blades:
- SandBlast Agent Anti-Bot
- SandBlast Agent Threat Emulation and Anti-Exploit
- SandBlast Agent Forensics and Anti-Ransomware
- Capsule Docs
- New features in existing Software Blades:
- Full Disk Encryption
- Offline Mode
- Self Help Portal
- XTS-AES Encryption
- New options for the Trusted Platform Module (TPM)
- New options for managing Pre-Boot Users
- Media Encryption & Port Protection
- New options to configure encrypted container
- Optical Media Scan
- Anti-Malware:
- Web Protection
- Advanced Disinfection
Compliance
- User can create custom best practices based on scripts
- Support for 35 regulations including General Data Protection Regulation (GDPR)
Subscribe to:
Posts (Atom)