Tuesday, July 24, 2018
Wednesday, June 20, 2018
Monday, June 18, 2018
Blades Flow
Diagram shows how a packet traverses a Checkpoint Firewall
- L2-L4 Traffic (IPSec/VPN, Identity Awareness, Layer 4, Alert/Logs, Packet Decision)
- Fast Path (Are Blades Enabled) Packet Decision
- L4-L7 Traffic (Stream Reassemble, SSL Decryp, CoreXL (IPS, App, URL, AV, AB) SSL Encryp, L4-L7 Packet Decision
Wednesday, May 30, 2018
TCP packets dropped due to “out of state” error
TCP packets dropped due to “out of state” error
Description:
Some TCP packets, and therefore connections, are being dropped due to an invalid state. In the firewall logs these appear as “TCP packet out of state”. The list of affected connections is below. The firewall keeps a state table that is used to ensure TCP connections are tracked from beginning (SYN) to end. It is possible for a connection that used to appear in that table to no longer appear in it.
Indeni will re-check this alert every 1 minute. If indeni will determine the issue has been resolved it will automatically be flagged as such.
Affected TCP Connections:
- src: 192.168.10.14 dst: 10.3.1.81, service: (TCP 22)
- src: 192.168.10.10 dst: 10.3.1.81, service: (TCP 5000)
- src: 10.3.1.81 dst: 10.3.1.75, service: (TCP 41983)
- src: 192.168.10.10 dst: 10.3.1.81, service: (TCP 443)
- src: 192.168.10.10 dst: 10.3.1.81, service: (TCP 22)
- src: 10.3.1.81 dst: 10.3.1.75, service: (TCP 36931)
- src: 10.3.1.81 dst: 10.3.1.75, service: (TCP 33356)
Manual Remediation Steps:
There are multiple known causes:
There are multiple known causes:
- Asymmetric routing: one direction of the connection is flowing through this firewall and another through a different firewall (not part of the same cluster).
- The connection does not comply with the TCP standard or an attack is being attempted.
- The connection was inactive for more than the TCP idle connection timeout (default 3600 seconds for Check Point firewalls). To resolve this, you may increase the TCP connection timeout. A better solution, however, would be to contact the developers of the application using the connection and have them implement a keep-alive in the connection to avoid a timeout. This latter option will ensure the application is in better compliance with complex network equipment and would help avoid increasing the TCP connection timeout which may result in the connection table filling up. Aggressive aging is removing TCP connections.
fw monitor
If you want to check the traffic flowing through a Checkpoint firewall without using the SmartView Tracker, you can use “fw monitor” command.
I will show you how to use fw monitor the way I use it for my troubleshooting process.
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
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
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) |
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
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.
Tuesday, May 15, 2018
R80.10 Training
Upgrade Methodology
--------------------------------
Upgrade Blink (isomorphic)
Image Gateway
Cpuse – upgrade
- clean install
CDT – Central Deployment Tool
(hotfix/upgrade
Smart upgrade
Smart distributor = smart update
Can dlp or dlp light scan ocr and
pdf
Smart logger - Boelian
numbers, free from text CMA
Smart workflow - monitor logs
summary /details/logs/history
Service Now – API to integrate -
CB has a video
•Shared
layer to all the gateway (gateway and management must be on R80.10)
•Do
allow spaces in Object Name in R80.10
•
•
Corp Policy
Policy Type (Access Control/Threat Prevention)
•Access Control
•Network
•Web
access Layer
•Threat Prevention
•Threat
Prevention
•IPS
only
<Manage & setting> <Permission and Administrator>/Revision
- (similar to database revision)
Loggin -
Enable Accounting extended and detail session /payload
What are layers
•Unified
policy
•2
components
•access
control – Firewall , vpn Url
filtering, appl
control, control awareness
•threat
prevention – threat emulation,
•Layers
in inline mode
•Layers
in ordered mode
•
•Benefits
•Admin
delegation for specific order layers
•Could
have combination of blades per layer
Compatible
with R77.20 gateways
Thursday, May 10, 2018
Understanding VSX -
Key Terms
- VSX Gateway
- Physical appliance that hosts virtual firewall gateway
- Virtual System
- is a virtual firewall that provides the functionality of a security gateway with full firewall and vpn facilities.
- you can have multiple virtual system running concurrently on a single VSX gateway
- Wrap Link
- is a virtual point to point connection between a virtual system and a virtual router or virtual switch.
- each side of the warp link represents a virtual interface of the appropriate device
- Virtual Router
- A software equlivent of a physical router
- Virtual Switch
- A software equlivent of a physical switch
- VSLS
- Virtual System Load Sharing is a VSX cluster technology that assigns virtual system traffic to different active cluster members.
- DMI - Dedicate Management Interface
Subscribe to:
Posts (Atom)