Alert / Dashboard based on primary IP


I had heard of an incident of a user accidently having their offsite asset exposed to the internet, caused some issues…

anyone know of a way to alert on (or create a dashboard) if an asset has its “primary ip” is something other than a “Non-Routable Address Space” ip?

I noticed that in agent management that information is tracked.

(asking for a friend :slight_smile: )
thanks in advance…

Hi @pete_jacob if you happen to be a Managed IDR customer you will have agent beacons in log search. Within the agent beacons we list the IP addresses of the interfaces. It would be possible to build a custom alert to fire if any of those interfaces happened to be assigned a public Ip address.

See an example here

Screen Shot 2022-01-11 at 3.26.19 PM

You would need to add a custom pattern detection alert to trigger on

agentNetworkInterfaces.0.privateIps.0 for example


1 Like

@pete_jacob what @david_smith said, if you need help with the queries, lemme know man!

1 Like

@SDavis yeah I most likely will but let me give it a try first.

you guys rock

1 Like

I was trying out some queries and it looks like a pattern detection alert such as this would do the trick


What this effectively checks is if any privateIP in the array of network interfaces (thats what the wildcard “*” does) is not equal to a private IP range it will match.

It could be worth reviewing some sample logs in log search to see if you get any hits for this before building the alert. Adding any exceptions or tweaks if necessary.


1 Like

Thank for your help. This is working perfect for a log search and dashboard.

For an alert it seems to having an issue… for the alerts it will alarm on anything that does not have the field agentNetworkInterfaces.1.privateIps.0

does this make sense? I can attach some alerts for contex

If you use the wildcard does that also occur?

One thing I’m thinking is to use this to check if the key value is always present



1 Like

@david_smith how would you use a “does not equal” with this?

this is invalid, is this because that is a regex and it won’t work with the IP(


Your posted query is where(agentNetworkInterfaces..privateIps.0=/./!=IP( - I’m pretty sure you can’t have your agentnetworkinterface keyword equal the wildcard then immediately have it not equal your CIDR IP without adding the keyword again, take a quick look below:

Without being able to test, have you tried something similar to:

where(agentNetworkInterfaces..privateIps.0=/./ AND agentNetworkInterfaces.*.privateIps.0!=IP(

1 Like

The formatting in the forum can be a little tricky, it drops the asterix “*” sometimes. But Stephen is right it should be

where(agentNetworkInterfaces.*.privateIps.0=/.*/ agentNetworkInterfaces.*.privateIps.0!=IP(

that should work. One thing to note an AND operator can be used or ommitted. As a whitespace " " is also considered a logical AND. Up to the user for legibility.


@david_smith @david_smith
Sorry to be a pita about this guys.
I think I understand what is going on.

if you look in the agent bacons most assets will have a primary ip on either
agentNetworkInterfaces.0.privateIps.0 or agentNetworkInterfaces.1.privateIps.0
but will also have a loopback interface that is

so in this query it won’t work correctly

2022-01-18 14_50_21-Window

its like you have to say:
any interface that is present
not equal to the ip’s (listed above)
and btw totally ignore looking at the loopback interface

does this make sense?
I also noticed some agent bacons in the logs that just show the loopback interface (
with no indication of a agentNetworkInterfaces.*.privateIps.0 (this seems odd)
2022-01-18 14_47_21-Window

sorry guys
I ended up just creating an alert for agentNetworkInterfaces.1.privateIps.0 and a second for

this solved my problem and is working like I want. my goal was to alert on assets that have a public ip
having two alerts for this is fine. log search and alerts can really be interesting.

here is one of the alerts:
2022-01-18 15_41_00-Window

1 Like

Interesting, I will say when custom pattern detections support LEQL there will be a great time to adjust this query and tidy it up a bit.