u/junimjorgeof

The interesting part of this pipeline is that a user can open a sanitized copy of a downloaded document immediately, while the original is still being detonated in the cloud sandbox. Threat Emulation is the sandbox, Threat Extraction is the Content Disarm and Reconstruction that hands over the clean copy. In the cloud both live under Threat Prevention > Web & Files Protection, and the browser extension is the front door.

The three copy behaviors you actually pick (when the mode is Prevent):

- Get extracted copy before emulation completes: the file name gets .cleaned appended and the user gets it right away. Least friction.

- Suspend download until emulation completes: the user waits, benign returns the original, malicious shows a block page. Most security, most delay.

- Emulate original without suspending: the original goes straight to the user even if it later turns out malicious. Least protective.

You set this per file type. Most people run extracted-copy-now for documents and live with the .cleaned handoff.

Extract Modes (the sanitized format): remove the malicious elements and keep the same file type, or convert to PDF. One gotcha from the guide: for right-to-left or Asian-font PDFs, use remove-malicious-elements, because the convert-to-PDF path does not handle those well.

The fail-open vs fail-closed decision that bites people: under Download Protection there is "Block downloads when emulation fails due to size limit or connectivity" (and a separate one for encrypted files). If a file is over the size limit or the sandbox is unreachable, you decide whether it is blocked or allowed. That is a real security vs usability call, and the default is worth checking.

The size limit itself: client E86.40 and higher supports up to 100 MB, older clients up to 15 MB. Anything over the limit hits the fail-open or fail-closed decision above.

Browser support gotcha: the extension covers Chrome, Edge, Firefox, Brave and IE on Windows, and Chrome, Firefox, Brave and Edge on macOS. Not Safari. So Safari users get no download emulation or extraction.

Exclusion gotcha: exclusions are by folder, domain or SHA1, and the domain matching is broad. Entering domain.com excludes www and all subdomains, while www.domain.com does not exclude sub.domain.com. Easy to over-exclude or under-exclude if you do not check the rule.

Do you run extracted-copy-now or suspend-until-done for documents, and do you fail open or closed when emulation cannot run? Curious where people land on that trade-off.

Full write-up with the full pipeline, the per-file-type actions and the cloud sandbox knobs is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Threat-Emulation-amp-Extraction-Deep-Dive-The-Sandbox/m-p/281234

Every client release brings the same question: how do you upgrade hundreds of agents without breaking FDE, flooding the WAN, or force-rebooting someone mid-meeting. A few mechanisms and a few gotchas that actually matter.

The "2 PM reboot" fix. Whether the client reboots silently or lets the user postpone is a policy setting, not luck. It lives in Installation and Upgrade Settings: a reminder interval, a "Force Installation and automatically restart after" timer (hours), and a maximum delay the user can postpone. Set the force timer to land outside business hours and that single setting keeps the upgrade off someone's screen during a meeting.

Automatic Client Update (cloud-managed, Windows only). Keeps clients on the latest approved version silently, from the Software Deployment policy. The defaults are what bite people:

- New tenants: ON.

- Newly cloned rules: ON (this is the recommended setup).

- Existing rules in an existing tenant: OFF.

- A rule exported from one tenant and imported into another: comes in ON.

So on an established tenant, do not assume hands-off upgrades are already running. Existing rules ship with it OFF, you turn it on deliberately.

Manual version bump, when you want to control the timing. Set the client version on a deployment rule and Install Policy. But changing the version upgrades every computer assigned to that rule, so scope the rule (OU, specific computers, or a Virtual Group) before you touch the version. Deployment rules are Windows and macOS, Linux is not supported for them yet.

Gradual rollout / pilot ring. Clone a rule scoped to pilot machines, upgrade only that rule, watch it, then roll the change to the rest. The blast radius is just the pilot. The predefined Virtual Groups (All Laptops, All Desktops) let you slice rings without touching AD. Note that a cloned rule has Automatic Client Update ON by default, so confirm it matches your intent before you Install Policy.

FDE discipline, the part that bricks machines if you ignore it:

- The Full Disk Encryption component cannot be removed during an upgrade.

- Do not upgrade while the disk is not fully encrypted.

- Do not start a second upgrade before the first finishes protecting.

- Do not uninstall an upgrade before the machine is fully protected by the new version.

Dynamic Package. One .EXE for any CPU, and with the Tiny Agent it installs only what each machine needs and cuts network traffic. Not for macOS or Linux. The "Minimize package size" option shrinks the download at the cost of build time.

How do you stage your rings, and has the "existing rules default to OFF" ever caught you assuming auto-updates were already running?

Full write-up with the two upgrade paths and the settings breakdown is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Agent-Upgrade-Best-Practices-Deployment-Rules-amp-Gradual/m-p/280952

Forensics runs automatically the moment another component detects something (Anti-Ransomware, Behavioral Guard, Anti-Bot, Threat Emulation, Anti-Malware, the Security Gateway, or a supported third-party AV) and assembles the whole attack sequence into a report. If the endpoint is offline when it happens, it caches locally and sends the data once connectivity is back.

The five sections, each answering one question:

- Entry Point: how the file got in.

- Business Impact: which files were affected and what was done. Restored files show up here.

- Remediation: which files were treated and their status. Deleted files show up here.

- Suspicious Activity: the unusual behavior during the attack.

- Incident Details: the full visual map of the attack paths.

That restored-in-Business-Impact vs deleted-in-Remediation split is the part that trips people up, worth memorizing.

The two playbooks are straight from the admin guide:

- Threat Emulation or Anti-Bot detection: open the report, use the Remediation tab for the attack components and treatment, delete the files the attack created, check Business Impact for files that might be affected, check Entry Point for the path, then update policy to prevent a repeat.

- Ransomware: open the report, Remediation tab. If Automatic restore and remediate is on, restoration is automatic (verify in Business Impact), otherwise walk the user through the manual restore.

Practical bits:

- In the cloud you open it from Logs (Statistics pane, Blade = Forensics), double-click the event, then Open or Download the Forensics Report. It downloads as JSON.

- You can trigger an analysis yourself: Threat Hunting > Actions > Trigger Forensic Analysis, or Push Operations > Analyze by Indicator on a URL, IP, file path or hash, which runs without installing policy.

- It also ingests third-party AV via the Windows Event Log (Defender, Symantec, ESET, Kaspersky, Cylance, McAfee, Trend Micro, F-Secure). Some do not write to the Event Log by default, so configure them and validate each with an eicar test.

- Storage is up to 1 GB of client disk by default, configurable up but not down, and the oldest data is dropped when it fills.

Do you run those two playbooks as your actual runbook, and has anyone wired third-party AV into Forensics through the Event Log? Curious how reliable that path is per vendor.

Full write-up with the section-by-section breakdown and the manual-trigger flows is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Anatomy-of-a-Forensics-Report-From-Detection-to-Root-Cause/m-p/280728

This one confuses a lot of people. You enable Endpoint Policy Management on the management server and suddenly Gaia Portal, SmartView or the Management API are not on 443 where you expect them. Here is what actually happens, and it depends on your version and how the blade was enabled.

First, the myth-buster: 4434 is not "the endpoint agent port." The agents talk to the server on 443 (and 80 for Anti-Malware signature updates). The 4434 business is an SSL split on the management side, not the agent path.

R80.40 and lower: enabling the blade moves Gaia Portal, SmartView and the Management API from 443 to 4434. Disabling moves them back. The endpoint keeps 443, the management web stuff goes to 4434.

R81 and higher, it depends on how the blade got enabled:

- Clean install with the blade, or the blade enabled after the upgrade: all services answer on 443, and endpoint SSL that arrives on 443 is internally redirected to 4434. So you reach Gaia, SmartView and the API on 443, and the agents also use 443.

- Upgraded with the blade already enabled: the old split is kept, endpoint on 443, everything else on 4434.

So the URL you use depends on the path:

- Gaia Portal: https://<ip> vs https://<ip>:4434

- SmartView: /smartview/ vs :4434/smartview/

- Management API: /web_api/ vs :4434/web_api/

You can flip which service owns 443 vs 4434 manually. Roughly:

dbset httpd:ssl_port 443 (or 4434)

dbset :save

$UEPMDIR/system/install/gaia_apache_conf_regenerate

# then set Listen and VirtualHost in $UEPMDIR/apache/conf/ssl.conf

cpstop ; cpstart

There are four supported certificate and port combinations.

Practical takeaway for anyone firewalling this: open 443 (and 80 for AM signatures) client-to-server for the agents, and remember that 4434 is about where the management UI/API lives, not the agent connection. That mixup sends people opening the wrong rule.

Anyone been bitten by this after enabling Endpoint on an existing management, portal suddenly on :4434? How do you standardize it across your estate?

Full write-up with the full port matrix, the heartbeat mechanics, and the manual cert/port scenarios is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Agent-to-Management-Communication-Ports-Heartbeat-and-the-443/m-p/280303

The design choice I find interesting here is that Anti-Ransomware assumes some ransomware will actually start running, and it still recovers. The sequence is monitor, back up before encryption, detect, stop, delete, restore.

Two parts do the heavy lifting.

Honeypot / canary files. Anti-Ransomware plants decoy files across many folders. The moment ransomware modifies one, the attack is stopped. Details from the admin guide worth knowing:

- They are real documents, images, videos and music, you can actually open them.

- Their names contain strings like CP, CheckPoint, Check Point, Check-Point, Sandblast Agent, Sandblast Zero-Day, Endpoint.

- If a user deletes one, it is recreated after the next boot.

Practical tip: tell your helpdesk about these. Users find them, assume they are junk, and delete them. It is harmless, but the tickets are avoidable.

Pre-encryption backup and rollback. Before the encryption starts, the files being touched are copied to a safe location. After the attack is stopped, remediation deletes the files the attack created, including the encrypted ones, and restores the originals to their original location. What you actually configure:

- Automatic restore and remediate, or leave it manual so the user starts the restore.

- Maximum backup size on disk (the guide's best practice is 1 GB).

- A backup interval (each file is backed up once per interval, even if changed many times) and which file types to back up.

- Backup exclusions by folder, process (name plus optional signer), or certificate.

Why behavior instead of a signature: modern ransomware checks whether it is in a VM, sandbox or debugger and stays quiet if it thinks it is being watched, which a static scanner can miss. A canary does not care how the sample hid. The moment it starts encrypting it trips the tripwire, and the pre-encryption backup lets you roll back regardless.

If you run this, have you tested the rollback end to end, and how did you size the backup and pick the file types? Curious what people include beyond Office docs.

Full write-up with the detection-to-rollback flow and the Forensics report sections is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Anti-Ransomware-Deep-Dive-Honeypots-Pre-Encryption-Backup-amp/m-p/279968

If you are firewalling a Harmony Endpoint on-prem deployment, the single most useful thing to internalize is this: the endpoint client always initiates the connection. The management/policy server never connects "down" to a client. Get that wrong and you open rules that are never used and still end up with agents that do not talk.

The ports that actually matter (client to server), all client-initiated:

- HTTPS TCP/443 for almost everything: registration, heartbeat, policy downloads (the policy files themselves are AES-encrypted), Application Control reputation queries, log uploads, and client package downloads (packages are signed and verified before install).

- HTTP TCP/80 for Anti-Malware signature updates (the engine verifies signatures before loading and during the update).

- A proprietary Check Point protocol for the sensitive stuff: FDE recovery data upload, Media Encryption and Port Protection key exchange, and FDE user acquisition / credentials.

Between the servers and console (SIC, certificate-authenticated):

- TCP/18190 to 18193: SmartEndpoint console to management, and Endpoint Policy Server to management.

- TCP/18221: secondary to primary management (HA).

- HTTPS/443: Endpoint Policy Server to primary management for monitoring events.

The heartbeat: every 60 seconds by default, client-initiated. It confirms connectivity, reports policy status changes, and updates the compliance state. By default a client is moved to Restricted after 5 consecutive out-of-compliance heartbeats, so it is not just a keepalive, it drives the compliance state machine.

The classic "agent not communicating" root cause is almost always one of two things: HTTP/80 or HTTPS/443 blocked by a firewall or Application Control rule, or missing routing between the endpoint elements.

Two optional pieces worth knowing: the Endpoint Policy Server, which offloads most client communication (heartbeat, policy downloads, AM updates, logs) in large environments, and a Secondary Management Server for HA.

If you run on-prem management, how do you split the load: one policy server per site, a couple centrally, or all direct to management? And has the 80-vs-443 gotcha ever bitten you during a rollout?

Full write-up with the component map and the flow diagrams is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/Harmony-Endpoint-On-Premises-Architecture-Components/m-p/279803

If you run Check Point Harmony Endpoint on a decent-sized fleet, you have probably lived this one. You push an agent upgrade or a big signature package drops, and every machine on site goes out to grab the same thing at the same moment. The WAN link chokes, a quiet maintenance window turns into help desk tickets, and on a branch the traffic can even lean on the gateway. The endpoints are fine. It is the way updates get distributed.

The built-in fix is the Super Node, and honestly a lot of shops never switch it on. It is just one Windows endpoint running a specially configured client that also works as a small local proxy and mirror (NGINX under the hood). It pulls the packages and signatures once, keeps a local copy, and feeds everyone else on the LAN. Only that one box has to reach the update servers.

A few things I wish I had known before setting one up:

• Clients pick a Super Node at random from the list in Client Settings, General. If one fails they try another, and if all fail they go direct to the policy source. So put more than one in the list, otherwise it is a single point of failure.
• Open TCP 4434 and 4436 between the endpoints and the Super Node (4436 is the proximity check). Easy to forget the internal firewall rule and then wonder why nothing happens.
• Keep the Super Node on the same client version as the clients or newer. If it is older it answers with a 404 and the clients quietly fall back to pulling direct.
• Give it some room. The cache is 4 GB by default, clears files after 7 days idle, and it needs around 350 MB of headroom.
• There is an offline mode on newer clients where the Super Node is the only box with internet. Just know it drops VPN, IPv6 and a few other things in that mode.

Check Point describes the payoff in general terms (less WAN, less server load, better scale) instead of promising a number, so I would not quote a hard figure. But for anything multi-site or branch heavy it is one of those changes you wish you had done sooner.

How does everyone else deal with agent and signature distribution across sites? One box per branch, a couple per big site, or just eat the bandwidth?

Full write-up with the config, validation and troubleshooting is here if it helps (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Super-Nodes-in-Harmony-Endpoint-Cut-WAN-Bandwidth-with-a/m-p/280649