Hello!
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 
)
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
You would need to add a custom pattern detection alert to trigger on
agentNetworkInterfaces.0.privateIps.0 for example
David
@pete_jacob what @david_smith said, if you need help with the queries, lemme know man!
@SDavis yeah I most likely will but let me give it a try first.
you guys rock
I was trying out some queries and it looks like a pattern detection alert such as this would do the trick
agentNetworkInterfaces.*.privateIps.0!=/(^127\..*)|(^10\..*)|(^172\.1[6-9]\..*)|(^172\.2[0-9]\..*)|(^172\.3[0-1]\..*)|(^192\.168\..*)/
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.
David
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
agentNetworkInterfaces.*.privateIps.0=/.*/
David
@david_smith how would you use a “does not equal” with this?
where(agentNetworkInterfaces..privateIps.0=/./!=IP(192.168.0.0/16)
this is invalid, is this because that is a regex and it won’t work with the IP(192.168.0.0/26)
Your posted query is where(agentNetworkInterfaces..privateIps.0=/./!=IP(192.168.0.0/16) - 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(192.168.0.0/16)
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(192.168.0.0/16))
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
@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 127.0.0.1
so in this query it won’t work correctly
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 (127.0.0.1)
with no indication of a agentNetworkInterfaces.*.privateIps.0 (this seems odd)
sorry guys
I ended up just creating an alert for agentNetworkInterfaces.1.privateIps.0 and a second for
agentNetworkInterfaces.0.privateIps.0
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:
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.