Error When Adding IP Address to Address Group via the XML API

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

Error When Adding IP Address to Address Group via the XML API

L0 Member

I am working on a SOAR automation workflow that automatically adds an IP address to a Block List if Palo Alto identifies it as a “CRITICAL” or “HIGH” vulnerability coming from outside to inside our network.

 

I am getting an error once the workflow reaches the part where it attempts to add the IP address to the block list. The error is the response to the XML API request and is: {"line": "<ADDRESS_GROUP_NAME> -> ip-netmask unexpected here"} where <ADDRESS_GROUP_NAME> is the name of the address group IP addresses get added to where they get auto-denied from entry to our network.

 

I'm using the Panorama “SET” action, and the XPATH I’ve specified is:

/config/devices/entry[@name='localhost.localdomain']/device-group/entry[@name='<DEVICE_LOCATION>']/address-group/entry[@name='<ADDRESS_GROUP_NAME>']

The element I’ve specified is:

 

<static>
	<member>
		{{["Action 1"].[event].[entryObject].[source_ip]}}
	</member>
</static>

 

Note: The odd-looking variable in the middle is a dynamic variable used by the SOAR tool that will put the Source IP of the vulnerability detection in there.

I came across some Palo Alto documentation here: Add a Shared Address Object Using XML API to Panorama 

This documentation mentions that the Network Mask needs to be specified in CIDR notation for the IP address to be added.

 

Where does that netmask come from? Is it based on the source IP being submitted, or is it based on our internal network? 

 

Thank you in advance.

1 REPLY 1

Cyber Elite
Cyber Elite

Hello,

I understand what you are attempting to accomplish and here are a few things to think about.

  • Inspect inbound traffic with Anti-Virus, Anti-Spyware, and Vulnerability protection
    • This should drop/block the traffic
    • Anti-Spyware policies can be made to automatically block traffic from the source for up to 1 hour.
  • Configure a Zone Protection Policy for your external interfaces (and internal). These can also block sources for up to and hour.
  • Configure DoS Protection and apply it to your inbound security profiles.
  • Utilize and block traffic to/from the predefined External Dynamic Lists
  • Turn on telemetry and send the data back to Palo Alto
    • This way Palo Alto can update their signatures
  • Whitelist the incoming IP's, if practical.

These are dynamic and require no input or additional resources to accomplish. Honestly play IP whack-a-mole is not a very good method. If the firewall is blocking it, then its doing its job. 

https://docs.paloaltonetworks.com/best-practices

 

Just my thoughts.

  • 1801 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!