Tuesday, 30 January 2018
Wednesday, 24 January 2018
How to See a Network Flow Through the CLI in a Checkpoint Firewall?
I will show you how to use fw monitor the way I use it for my troubleshooting process.
Take into consideration the following:
- If you have a cluster, this command will show traffic flowing through the active firewall.
- To check active status issue: cphaprob state
- If you have SecureXL enabled, some commands may not show everything.
- To disable SecureXL: fwaccel off
- To enable SecureXL: fwaccel on
Traffic to/from a Host
You can check the traffic that a host is receiving or sending with the following command:
fw monitor -e “accept host(x.x.x.x);”
Example
CP-Firewall> fw monitor -e "accept host(192.168.1.86);" Compiled OK. monitor: loading monitor: monitoring (control-C to stop) [vs_0][fw_6] eth3:i[71]: 173.16.25.44 -> 192.168.1.86 (TCP) len=71 id=0 TCP: 43637 -> 443 F..PA. seq=4a5c5909 ack=df3170c0 [vs_0][fw_6] eth3:I[71]: 173.16.25.44 -> 192.168.1.86 (TCP) len=71 id=0 TCP: 43637 -> 443 F..PA. seq=4a5c5909 ack=df3170c0 [vs_0][fw_6] eth1:o[41]: 173.16.25.44 -> 192.168.1.86 (TCP) len=41 id=0 TCP: 43637 -> 443 F...A. seq=4a5c5927 ack=df3170c0 [vs_0][fw_6] eth1:O[41]: 173.16.25.44 -> 192.168.1.86 (TCP) len=41 id=0 TCP: 43637 -> 443 F...A. seq=4a5c5927 ack=df3170c0 monitor: caught sig 2 monitor: unloading CP-Firewall>
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) |
Traffic to/from a Network
You can check the traffic to a network with the following command. You can use 32 as netmask and would work like a host as well.
fw monitor -e "accept net(x.x.x.x,yy); "
Example (network 192.168.1.64/26)
CP-Firewall> fw monitor -e "accept net(192.168.1.64,26); " Compiled OK. monitor: loading monitor: monitoring (control-C to stop) [vs_0][fw_11] eth2:i[44]: 172.16.10.149 -> 192.168.1.89 (TCP) len=44 id=36544 TCP: 7480 -> 443 .S.... seq=25d68d6c ack=00000000 [vs_0][fw_11] eth2:I[44]: 172.16.10.149 -> 192.168.1.89 (TCP) len=44 id=36544 TCP: 7480 -> 443 .S.... seq=25d68d6c ack=00000000 [vs_0][fw_11] eth1:o[44]: 172.16.10.149 -> 192.168.1.89 (TCP) len=44 id=36544 TCP: 7480 -> 443 .S.... seq=25d68d6c ack=00000000 [vs_0][fw_11] eth1:O[44]: 172.16.10.149 -> 192.168.1.89 (TCP) len=44 id=36544 TCP: 7480 -> 443 .S.... seq=25d68d6c ack=00000000
To see a one-way network flow:
You can check the traffic to a source and destination in one direction:
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); " monitorfilter: Compiled OK. monitor: loading monitor: monitoring (control-C to stop) [vs_0][fw_0] eth3:i[64]: 173.16.25.44 -> 192.168.2.134 (TCP) len=64 id=0 TCP: 31668 -> 443 .S.... seq=334241eb ack=00000000 [vs_0][fw_0] eth3:i[64]: 173.16.25.44 -> 192.168.2.134 (TCP) len=64 id=0 TCP: 10589 -> 443 .S.... seq=96f7c1ab ack=00000000 [vs_0][fw_0] eth3:i[64]: 173.16.25.44 -> 192.168.2.134 (TCP) len=64 id=0 TCP: 59589 -> 443 .S.... seq=b00da993 ack=00000000 [vs_0][fw_0] eth3:i[64]: 173.16.25.44 -> 192.168.2.134 (TCP) len=64 id=0 TCP: 24452 -> 443 .S.... seq=b7eab2df ack=00000000 [vs_0][fw_0] eth3:i[71]: 173.16.25.44 -> 192.168.2.134 (TCP) len=71 id=0 TCP: 24452 -> 443 F..PA. seq=b7eac473 ack=aaeba7f0 [vs_0][fw_0] eth3:i[71]: 173.16.25.44 -> 192.168.2.134 (TCP) len=71 id=0 TCP: 31668 -> 443 F..PA. seq=33425c0a ack=39f1e2fa [vs_0][fw_0] eth3:i[71]: 173.16.25.44 -> 192.168.2.134 (TCP) len=71 id=0 TCP: 59589 -> 443 F..PA. seq=b00db2f8 ack=5c949cea [vs_0][fw_0] eth3:i[71]: 173.16.25.44 -> 192.168.2.134 (TCP) len=71 id=0 TCP: 10589 -> 443 F..PA. seq=96f7c6d9 ack=9c027709 monitor: caught sig 2 monitor: unloading CP-Firewall>
To see a 2-way network flow:
You can check the traffic to a source and destination in both directions: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: Compiled OK. monitor: loading monitor: monitoring (control-C to stop) [vs_0][fw_17] bond1.102:i[84]: 192.168.1.84 -> 172.16.125.81 (ICMP) len=84 id=52498 ICMP: type=8 code=0 echo request id=22608 seq=1 [vs_0][fw_17] bond1.102:I[84]: 192.168.1.84 -> 172.16.125.81 (ICMP) len=84 id=52498 ICMP: type=8 code=0 echo request id=22608 seq=1 [vs_0][fw_17] bond1.101:o[84]: 192.168.1.84 -> 172.16.125.81 (ICMP) len=84 id=52498 ICMP: type=8 code=0 echo request id=22608 seq=1 [vs_0][fw_17] bond1.101:O[84]: 192.168.1.84 -> 172.16.125.81 (ICMP) len=84 id=52498 ICMP: type=8 code=0 echo request id=22608 seq=1 [vs_0][fw_4] bond1.101:i[84]: 172.16.125.81 -> 192.168.1.84 (ICMP) len=84 id=24621 ICMP: type=8 code=0 echo request id=13742 seq=30840 [vs_0][fw_4] bond1.101:I[84]: 172.16.125.81 -> 192.168.1.84 (ICMP) len=84 id=24621 ICMP: type=8 code=0 echo request id=13742 seq=30840 [vs_0][fw_4] bond1.102:o[84]: 172.16.125.81 -> 192.168.1.84 (ICMP) len=84 id=24621 ICMP: type=8 code=0 echo request id=13742 seq=30840 [vs_0][fw_4] bond1.102:O[84]: 172.16.125.81 -> 192.168.1.84 (ICMP) len=84 id=24621 monitor: caught sig 2 monitor: unloading CP-Firewall>As you can see, this is a very helpful and flexible command, you can combine the OR and AND operators as you need and capture the information into a .pcap file and analyze it later with Wireshark.
Types Of VPN Tunnels?
Types of tunnels and the number of tunnels can be managed with the following features:
Permanent Tunnels
This feature keeps VPN tunnels active allowing real-time monitoring capabilities.
Permanent Tunnels are constantly kept active and as a result, make it easier to recognize malfunctions and connectivity problems. Administrators can monitor the two sides of a VPN tunnel and identify problems without delay.
Each VPN tunnel in the community may be set to be a Permanent Tunnel. Since Permanent Tunnels are constantly monitored, if the VPN tunnel is down, then a log, alert, or user defined action, can be issued. A VPN tunnel is monitored by periodically sending "tunnel test" packets. As long as responses to the packets are received the VPN tunnel is considered "up." If no response is received within a given time period, the VPN tunnel is considered "down." Permanent Tunnels can only be established between Check Point Security Gateways. The configuration of Permanent Tunnels takes place on the community level and:
- Can be specified for an entire community. This option sets every VPN tunnel in the community as permanent.
- Can be specified for a specific Security Gateway. Use this option to configure specific Security Gateways to have permanent tunnels.
- Can be specified for a single VPN tunnel. This feature allows configuring specific tunnels between specific Security Gateways as permanent.
VPN Tunnel Sharing
This feature provides greater interoperability and scalability between Security Gateways. It also controls the number of VPN tunnels created between peer Security Gateways.
Tunnel test is a proprietary Check Point protocol used to see if VPN tunnels are active. Tunnel testing requires two Security Gateways and uses UDP port 18234. Third party gateways do not support tunnel testing.
VPN Tunnel Sharing provides interoperability and scalability by controlling the number of VPN tunnels created between peer Security Gateways. There are three available settings:
- One VPN tunnel per each pair of hosts
- One VPN tunnel per subnet pair
- One VPN tunnel per Security Gateway pair
How to Troubleshoot Check Point Firewall VPN Connection?
In this example the tunnel
between GWA (Gateway A) and GWB (Gateway B) is down. Both gateways could be
managed by the same management server, or different ones. Both could be Check
Point Firewalls or one could be another brand.
Since at least one gateway needs to be a Check
Point gateway managed by us, in this example this is GWA. GWB can either be
another one of our gateways or an external one.
SmartView
Monitor
Let’s see what this has to say about the tunnel. (Viewing VPN tunnels in SmartView Monitor requires a monitoring license installed on the management server, and enabled on the gateway itself).
Open the SmartView Monitor and go to “Tunnels
on Gateway”:
First select GWA in
the list and review if the tunnel in question is UP, DOWN or Up – Init. Up –
Init means that it is trying to establish the tunnel, and will probably mean
that in a few seconds the tunnel will go to DOWN state or UP state.
Now go to “Tunnels on Gateway” again and select GWB (if both gateways are managed by the same management server).
Now go to “Tunnels on Gateway” again and select GWB (if both gateways are managed by the same management server).
One issue we could see here is for example
that the tunnel is UP from GWA perspective, but DOWN from GWB perspective. If
the “Permanent tunnel” is activated on the VPN community (both gateways need to
be Check Point) they will exchange UDP tunnel test packages (Name: tunnel_test,
UDP/18234). If GWA does not receive these packets, it will think the tunnel is
down.
However we could be in a situation where
packets from GWA to GWB arrive, but not in the opposite direction (GWB to GWA).
We will then see that the tunnel looks to be up from one side, but not the
other. The reason for this is packets lost in transit, maybe due to DDoS
protections, routing on internet or other issues.
If we have a tunnel from our Check Point
gateway (GWA) to a non-check point gateway (GWB) we cannot use permanent
tunnels. This means that the tunnel will be down, and not appear in this list
until traffic is sent in it.
So why it is down could be as simple as no
traffic has been sent into the tunnel. Another issue could arise if GWB is not
a Check point gateway, but the permanent tunnel is activated anyway. The tunnel
will then show as down from GWAs perspective since it assumes that GWB will
send the tunnel test packages.
SmartLog/SmartViewTracker
Sort traffic with GWA as source, and GWB as destination. Then also check
the other way around, GWA as destination and GWB as source.
Here we could see if
the PSK (pre-shared key) is incorrect for example, or if IKE packets are
dropped. If the PSK is incorrect, make sure both sides have the same PSK and
remember that it cannot be longer than 64 characters (longer than that and it
will be cut off at 64 chars, see sk66660 on the
Check Point support portal.
If the tunnel broke
suddenly, check drops from the time the tunnel stopped working. There can be
situations where the drop log is not shown repeatedly. The most common thing
you would see here is the not so friendly error “Packet is dropped because there is
no valid SA – please refer to solution sk19423 in SecureKnowledge Database for
more information“. This means that the two gateways did not reach an
agreement. This is due to the fact that the proposals are different between the
gateways. The proposal contains for example the subnets in the encryption
domain.
The most common issue in Check Point has to do
with something called super netting. To understand why Check Point does this,
we need to understand how a VPN tunnel works. In a VPN tunnel one Phase1 will
be established and then one Phase2 per subnet pair. If you have two /24 subnets
on each side of the tunnel that need to speak to each other, that is 4x Phase2.
Check Point will create as few subnets as possible and therefore it will create
one /23 subnet instead of 2x /24 if possible. If the other side of the tunnel
has 2x /24 configured and the Check Point have one /23 in its proposal the
tunnel will fail. It’s not easy to check the proposals in the Tracker or
SmartLog, so for that we need to debug the VPN tunnel and check out the debug
file with IKEView (see next section below).
If you get the error “invalid certificate”
then the port 18264 is closed between the gateway and management server. This
port is used for GWA to verify GWB’s certificate in the case that both are
managed by the same management server. Then they do not use PSK.
IKEView
If we cannot
establish why the tunnel fails with the above methods we need to take a better
debug. You can refer to: sk63560 on the Check
Point support portal. Below is a summary.
On the active gateway, run:
Command:-
# vpn debug trunk
Now a debug file will be created at:
$FWDIR/log/ike.elg and $FWDIR/log/ike.elg.0
Do some resets on the
tunnel to get some data into this or of the tunnel is down, try to make it
establish the tunnel again by sending data into the tunnel, then download the
ike.elg file to your desktop and open it with IKEView (available from Check Point support site).
If you do not have the monitoring license to SmartView Monitor you can use the
CLI command:
# vpn tu
to reset tunnels on GWA. Select option (7)
Delete all IPsec+IKE SAs for a given peer (GW) and input GWBs IP address. In
this program you will see what data is being sent between the gateways, what
proposals etc., to see if there is anything not matching. It is sorted on the
remote gateway IP, and you can follow both what proposal GWA sends to GWB and
also what GWB sends to GWA. End the debug with:
# vpn debug off # vpn debug IKEoff
Optionally delete $FWDIR/log/ike.elg* to not
have old things in it the next time you troubleshoot.
zdebug
Another tool we can
use is zdebug. This is a tool for checking dropped packets and reasons.
Do you wonder why it’s called zdebug? Apparently the person who wrote this program had a name starting with Z.
Do you wonder why it’s called zdebug? Apparently the person who wrote this program had a name starting with Z.
There are times when we can have drops which
are not logged in the normal log, or the reason is not properly stated there.
Then zdebug is helpful. Go to GWA and run (in expert mode):
# fw ctl zdebug drop | grep IP_OF_GWB
This will show if we have any dropped IKE
packets etc. Example output:
;[cpu_5];[fw4_0];fw_log_drop_ex: Packet proto=17 REMOVED:500
-> REMOVED:500 dropped by fwpslglue_chain Reason: PSL Drop: ASPII_MT;
;[cpu_5];[fw4_0];fw_log_drop_ex: Packet proto=17 REMOVED:500 -> REMOVED:500
dropped by fwpslglue_chain Reason: PSL Drop: ASPII_MT; ;[cpu_5];[fw4_0];fw_log_drop_ex:
Packet proto=17 REMOVED:500 -> REMOVED:500 dropped by fwpslglue_chain
Reason: PSL Drop: ASPII_MT;
You can then search on
the Check Point user center for the part “fwpslglue_chain Reason: PSL Drop:
ASPII_MT” and you will in this example find issue sk90322 which
explains the issue and the solution for this specific example.
If nothing else works
If nothing can be solved by the methods above
and if time is critical there are some emergency measures that can be taken:
• Fail over the
cluster (if it is a cluster)
• Push policy
• Delete the Community and re-create it
• Make sure you use IKE v1 in the Community
• Push policy
• Delete the Community and re-create it
• Make sure you use IKE v1 in the Community
How to use the "vpn tu" command for VPN tunnel management?
Answer:
Run one of the following commands from the command line Security gateway:
vpn tu or vpn tunnelutil
This command will bring up a menu for you to choose from.
R77 Output
********** Select Option **********
(1) List all IKE SAs
(2) List all IPsec SAs
(3) List all IKE SAs for a given peer (GW) or user (Client)
(4) List all IPsec SAs for a given peer (GW) or user (Client)
(5) Delete all IPsec SAs for a given peer (GW)
(6) Delete all IPsec SAs for a given User (Client)
(7) Delete all IPsec+IKE SAs for a given peer (GW)
(8) Delete all IPsec+IKE SAs for a given User (Client)
(9) Delete all IPsec SAs for ALL peers and users
(0) Delete all IPsec+IKE SAs for ALL peers and users
(Q) Quit
*******************************************
Answer:
- vpn tu command shows the Security Gateway's Main IP address and not the VPN public IP address / Link Selection IP address.
Run one of the following commands from the command line Security gateway:
vpn tu or vpn tunnelutil
This command will bring up a menu for you to choose from.
R77 Output
********** Select Option **********
(1) List all IKE SAs
(2) List all IPsec SAs
(3) List all IKE SAs for a given peer (GW) or user (Client)
(4) List all IPsec SAs for a given peer (GW) or user (Client)
(5) Delete all IPsec SAs for a given peer (GW)
(6) Delete all IPsec SAs for a given User (Client)
(7) Delete all IPsec+IKE SAs for a given peer (GW)
(8) Delete all IPsec+IKE SAs for a given User (Client)
(9) Delete all IPsec SAs for ALL peers and users
(0) Delete all IPsec+IKE SAs for ALL peers and users
(Q) Quit
*******************************************
- If you are not certain what Phase 1 SAs are active on your gateway, select option 1 for all of them or option 3 if you know the IP address of the remote host involved with that SA.
- If you are not certain what Phase 2 SAs are active on your gateway, select option 2 for all of them or option 4 if you know the IP address of the remote host involved with that SA.
- Once you know which IKE or IPsec SAs exist on your gateway, select, according to this meu, options 5 through 0 to delete those SAs according to your needs.
- As a result, you can check what VPN tunnels are established, partially or fully, and existing VPN tunnels can be torn down, and required to re-establish their VPN connection.
- When viewing Security Associations for a specific peer, the IP address must be given in dotted decimal notation.
Tuesday, 23 January 2018
Firewall components ?
The major components that require licensing are listed below:
- Firewall module
- Management console
- Management GUI applications, that is, SMART Clients
A firewall module enforces your security policy and sends log information to a management console. This is typically referred to as the firewall. The management console is responsible for storing, compiling, and pushing the security policies out to the firewall modules. It also receives logging information from the firewall modules and processes alerts. The Management GUI applications allow you to view, edit, and install security policies; view logs; and see the status of all installed firewall modules. The Management GUIs communicate with the management console, which does all of the actual work.
With some exceptions, which I will note in the following sections, each of these components may exist on separate systems. You can even mix and match the platforms on which each of these components exist.[1] For example, you can have the firewall on a Nokia platform, the management console on Solaris, and the Management GUIs on Windows.
Inspection module flow chart?
Packets are not processed by higher protocol-stack layers, unless the Security Gateway verifies that they comply with Security Policies.
Packet Flow Through the INSPECT Engine If packets pass inspection, the Security Gateway passes the packets through the TCP/IP stack and to their destination. Packets pass through the NIC, to the Inspection Module, and up through the network stack. Some packets are destined for an operating system’s local processes. In this case, the Inspection Module inspects the packets and passes them through the TCP/IP stack. If packets do not pass inspection, they are rejected or dropped and logged, according to rules set in the Check Point Rule Base. (The Rule Base is a collection of individual rules that determine your Security Policy.)
Packets are not processed by higher protocol-stack layers, unless the Security Gateway verifies that they comply with Security Policies.
What is firewall?
A firewall is a device that allows multiple networks to communicate with one another according to a defined security policy.
They are used when there is a need for networks of varying levels of trust to communicate with one another. For example, a firewall typically exists between a corporate network and a public network like the Internet. It can also be used inside a private network to limit access to different parts of the network. Wherever there are different levels of trust among the different parts of a network, a firewall can and should be used.
Firewalls are similar to routers in that they connect networks together. Firewall software runs on a host, which is connected to both trusted and untrusted networks. The host operating system is responsible for performing routing functions, which many operating systems are capable of doing. The host operating system should be as secure as possible prior to installing the firewall software. This not only means knowing how the operating system was installed but also making sure that all of the security patches are applied and that unnecessary services and features are disabled or removed.
Monday, 22 January 2018
Checkpoint Interview based Questions With Answers:
1.What is Anti-Spoofing.
Ans- Anti-Spoofing is the feature of Checkpoint Firewall. which is protect from attacker who generate IP Packet with Fake or Spoof source address. Its determine that whether traffic is legitimate or not. If traffic is not legitimate then firewall block that traffic on interface of firewall.
2. What is Asymmetric Encryption.
Ans – In Asymmetric Encryption there is two different key used for encrypt and decrypt to packet. Means that one key used for Encrypt packet, and second key used to for decrypt packet. Same key can not encrypt and decrypt.
3. What is Stealth Rule in checkpoint firewall.
Ans – Stealth Rule Protect Checkpoint firewall from direct access any traffic. Its rule should be place on the top of Security rule base. In this rule administrator denied all traffic to access checkpoint firewall.
4. What is Cleanup rule In Checkpoint Firewall.
Ans – Cleanup rule place at last of the security rule base, Its used to drop all traffic which not match with above rule and Logged. Cleanup rule mainly created for log purpose. In this rule administrator denied all the traffic and enable log.
5. What is NAT.
Ans- NAT stand for Network Address Translation. Its used to map private IP address with Public IP Address and Public IP address map with Private IP Address. Mainly its used for Provide Security to the Internal Network and Servers from Internet. NAT is also used to connect Internet with Private IP Address. Because Private IP not route able on Internet.
6. What is Source NAT.
Ans- Source NAT used to initiate traffic from internal network to external network. In source NAT only source IP will translated in public IP address.
7. What is VPN (Virtual Private Network).
Ans – VPN (Virtual Private Network) is used to create secure connection between two private network over Internet. Its used Encryption authentication to secure data during transmission. There are two type of VPN
Site to Site VPN.
Remote Access VPN.
8. What is IP Sec.
Ans – IP Sec (IP Security) is a set of protocol. which is responsible for make secure communication between two host machine, or network over public network such as Internet. IPSec Protocol provide Confidentiality , Integrity, Authenticity and Anti Replay protection. There is two IPSec protocol which provide security 1. ESP (Encapsulation Security Payload) and 2. AH (Authentication Header).
9. What is Difference between ESP and AH IPSec Protocol.
Ans-
ESP – ESP Protocol is a part of IPsec suit , Its provide Confidentiality, Integrity and Authenticity. Its used in two mode Transport mode and Tunnel mode.
AH – Its is also part of a IPsec suit, Its provide only Authentication and Integrity, Its does not provide Encryption. Its also used to two mode Transport mode and Tunnel mode.
10. What is Explicit rule In Checkpoint Firewall.
Ans – Its a rule in ruse base which is manually created by network security administrator that called Explicit rule
Subscribe to:
Posts (Atom)