Es posible bloquear una IP en cortex xdr pro

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Es posible bloquear una IP en cortex xdr pro

L2 Linker

Hello Community,

I am working with Cortex XDR Pro and investigating the "Endpoint Blocked IP Addresses" section within the Action Center. I have a few specific questions regarding how entries are populated in this table and the best practices for targeted blocking:

  1. Orchestration: How exactly are IPs added to this list? Does it only reflect automated response actions triggered by a playbook/prevention policy, or does it also include manual "Block IP" actions initiated by an analyst from an Incident or Causality view?

  2. Granular Blocking: If I want to block a specific remote IP (e.g., an internal host performing a port scan) on a specific endpoint only, what is the recommended workflow if the "Block IP" option is not appearing in the Incident artifacts?

  3. IOC/BIOC vs. Restriction Profiles: Is it possible to trigger a persistent block in this section by creating an IOC (providing the indicator, type, and severity)? Or should this be handled strictly through IP Lists within Restriction Profiles in the Endpoint Policy Management?

  4. Action Persistence: According to documentation, these actions expire after 90 days. If a block needs to be permanent, should it be moved from the Action Center to a Global Block List?

I recently encountered a "Suspicious Port Scan" alert from an internal host (XDR Analytics source). While the alert was generated, the IP was not automatically blocked. I am trying to determine the most efficient way to manually push that IP to the blocked list for the targeted server.

Any insights on the internal logic Cortex uses to populate this specific view would be greatly appreciated.

QuestionAb_0-1777933071076.png

 

1 accepted solution

Accepted Solutions

L5 Sessionator

Hello @QuestionAb ,

 

Greetings for the day.

 

Based on the internal sources and support resources for Cortex XDR, here is a detailed breakdown of the internal logic for the "Endpoint Blocked IP Addresses" section and the recommended workflows for IP blocking.

 

1. Orchestration: How IPs are Added to the List

The Endpoint Blocked IP Addresses tab within the Action Center is primarily designed to reflect automated response actions performed by the Cortex XDR agent.

  • Automated Logic: IPs are added to this list when the "Respond to Malicious Causality Chains" feature is enabled in the Malware Security Profile. The agent automatically blocks a remote IP if it identifies a network connection as part of a causality chain that triggered a high-confidence prevention alert (e.g., ransomware behavior or malicious script execution).
  • Manual Actions: While some administrative tasks are tracked in the Action Center, manual IP blocking is not natively performed via a "Block IP" button in the same way file hashes are added to the block list. Manual enforcement of specific IP blocks is instead handled through the Host Firewall module.

2. Granular Blocking: Recommended Workflow

If the "Block IP" option is not available (as it is not a standard manual artifact response for IP addresses) and you need to block a specific internal host (e.g., a port scanner) on a specific server, the recommended workflow is to use Host Firewall Profiles:

  1. Navigate to: Endpoints → Policy Management → Extensions → Host Firewall
  2. Create a new Host Firewall Profile (or edit an existing one applied to the target server).
  3. Add a rule with the following configuration:
    • Action: Block
    • Direction: Inbound (or Both)
    • Remote IP Address: Enter the specific IP of the internal host.
  4. Ensure this profile is attached to a policy rule targeting the specific server.

Why the Port Scan Alert Did Not Trigger a Block

The "Suspicious Port Scan" alert from XDR Analytics is a server-side detection based on ingested logs. The automated blocking mechanism ("Respond to Malicious Causality Chains") only triggers when the agent's local BTP/Malware engine identifies a high-confidence prevention event in real-time on the endpoint. Since Analytics alerts are generated after log processing on the server, they do not automatically trigger the agent-side WFP block rules.

Troubleshooting Tip: Checking Local Blocks

You can verify if an IP is currently blocked on an endpoint by using the cytool utility:

 
"C:\Program Files\Palo Alto Networks\Traps\cytool" unblock_remote_ip operation list

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

Thanks & Regards,
S. Subashkar Sekar

View solution in original post

1 REPLY 1

L5 Sessionator

Hello @QuestionAb ,

 

Greetings for the day.

 

Based on the internal sources and support resources for Cortex XDR, here is a detailed breakdown of the internal logic for the "Endpoint Blocked IP Addresses" section and the recommended workflows for IP blocking.

 

1. Orchestration: How IPs are Added to the List

The Endpoint Blocked IP Addresses tab within the Action Center is primarily designed to reflect automated response actions performed by the Cortex XDR agent.

  • Automated Logic: IPs are added to this list when the "Respond to Malicious Causality Chains" feature is enabled in the Malware Security Profile. The agent automatically blocks a remote IP if it identifies a network connection as part of a causality chain that triggered a high-confidence prevention alert (e.g., ransomware behavior or malicious script execution).
  • Manual Actions: While some administrative tasks are tracked in the Action Center, manual IP blocking is not natively performed via a "Block IP" button in the same way file hashes are added to the block list. Manual enforcement of specific IP blocks is instead handled through the Host Firewall module.

2. Granular Blocking: Recommended Workflow

If the "Block IP" option is not available (as it is not a standard manual artifact response for IP addresses) and you need to block a specific internal host (e.g., a port scanner) on a specific server, the recommended workflow is to use Host Firewall Profiles:

  1. Navigate to: Endpoints → Policy Management → Extensions → Host Firewall
  2. Create a new Host Firewall Profile (or edit an existing one applied to the target server).
  3. Add a rule with the following configuration:
    • Action: Block
    • Direction: Inbound (or Both)
    • Remote IP Address: Enter the specific IP of the internal host.
  4. Ensure this profile is attached to a policy rule targeting the specific server.

Why the Port Scan Alert Did Not Trigger a Block

The "Suspicious Port Scan" alert from XDR Analytics is a server-side detection based on ingested logs. The automated blocking mechanism ("Respond to Malicious Causality Chains") only triggers when the agent's local BTP/Malware engine identifies a high-confidence prevention event in real-time on the endpoint. Since Analytics alerts are generated after log processing on the server, they do not automatically trigger the agent-side WFP block rules.

Troubleshooting Tip: Checking Local Blocks

You can verify if an IP is currently blocked on an endpoint by using the cytool utility:

 
"C:\Program Files\Palo Alto Networks\Traps\cytool" unblock_remote_ip operation list

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

Thanks & Regards,
S. Subashkar Sekar

  • 1 accepted solution
  • 57 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!