Problem with conflicting IP fo Assets (Home Office)

Hey there,

i’m new here but i was told that you could help me out. :wink:
So I’ve tried to find anything regarding my issue here but i can’t find anything (or dont know the right keywords :roll_eyes: )

So we use the Insight Agent along with regular Scan Engines. Many of our employes are working from home or mobile.

Now I want to scan a device on our internal network that is on the 192.168.1.0/24 subnet. And of course I get feedback from various agents on assets that are in home/mobile office within exactly this address range, so that individual assets overlap with their IP addresses and I currently cannot correctly analyze the actual assets that are in our internal network.

Is there a way to tell InsightVM that the two assets (with the same IP) are not the same Asset?

Hope that was clear enough for you all. :sweat_smile:

Greeting
Lukas

Other than using a different RFC1918 address for your office?
Have you tried unchecking “Link Assets Across Sites”?
image

Hey @brandon_mcclure,

thanks for the quick reply.
Unfortunately changeing the RFC1918 address space is not a thing that we can implement quickly. But it’s on the list…

When i disable the “Link Assets Across Sites” is there a way to Match assets back together later on?

Cause there are also a some system with more than 1 Network Connection. Otherwise I have to weigh up the options of mixing scan results and manualy mark/link those assets with more than one interface.

@lwieners

1 Create a new dynamic asset group called Site Group - Not Rapid7 Insight Agents

  • Example filter in screenshotimage

2 Add the group to a site

  • Example in screenshot where to put the group image
1 Like

We are having the same problem. Can we exclude by scan engine? If it is found with this scan engine 1 put it in this site?

What are the details of the RFC 1918? I see the Asset linking which due to licensing we cant change right now.

I call that having Discovery Sites and Scan Sites.
looks like this
DISCOVERY SITE - > TAG
TAG - > DYNAMIC ASSET GROUP
SCAN SITE [INCLUDED ASSETS] < - DYNAMIC ASSET GROUP

Text Version
Maybe try a discovery-only site for each range(s). On that site make a tag called target-engine-x. Make a dynamic asset group pick up on the tag you made for each engine target tag. Apply asset group to included targets for scan site.

You can do this in several ways using sites/tags/dynamic asset groups/dynamic tags. You don’t really need tags, you could possibly do it with an asset group only. But using tags could help you scale better maybe. This is like bubble gum, no real good instructions on the package. Insert gum and figure it out kind of a thing.

This is not a silver bullet. Scanning duplicate IP space is a can of worms. Trying to answer your question but also want you to know this may not be the end of the road for you as you may find some issues based on how your infrastructure is living its best life.

Read up on asset linking. It may be that you need to disable it. At one time it did not exist and that was the way before it was added and then enabled by default.

Thank you, I was thinking about tags, and AGs but not individual sites… okay I made the site, made the asset group and tied it up with the tag. What do i put in the tag? Or is it supposed to grab it when I kick off a discovery scan? (do i add the network range in the tag? as i already discovered on this range but of course its giving me two assets on one ip- which we dont want)

Next question though, if I do set this off and put the network range in the site- what keeps it from giving me both aliases on one IP? (which in turn are two different assets)

Totally understand the asset linking, wish we could do that but if i were to turn that off, what would happen to scan history on particular ip?

I did attempt to exclude the dns name but it knows it as the ip so it wont let me, was hoping if i discovered ip it would just exclude that dns and keep one. (trickery)

Something will need to get scanned in a site before it will get tagged. Just make sure you give the tag a good name and you don’t get the tag types mixed up. sometimes people do not understand tags have types. maybe just use the type called custom for this.

The reason you want to use a site for discovery scanning is that you can use the engines IP routes for your filter to help figure out what it can route to. If all your engines have the same route then this doesn’t help. This plus disabling asset linking is going to be the only way to make sure it doesn’t mix up assets.

Trying without disabling asset linking may work just fine or it could be a train wreck, It just depends on your environment and the asset correlation with rapid7. It is a gamble. The product has an asset correlation process that will try its best and match up assets with the ones it knows about already. For example, in an authenticated scan it will grab the uuid from the linx and windows machines. so that is a pretty good indicator. Another example, not authenticated, no DNS resolution, 2 different machines have the same OS/open ports/services match/ and have same IP. Most likely it will correlate to the same asset and not work.

If you disable asset linking It should not remove the old scan history. You may gain an additional asset for that asset in each site. And then when you look at history you may have 2 for the same asset for a while until they age out with data retention. In your discovery site, unless you are doing a VM scan it won’t cost you a license.

It is an option for you to contact your rapid7 CSM and ask them to split your license from 1 to 2 consoles. let’s say you ask them to put 256 or 1024 on another license key and you can have your own dev box to do some testing. From my experience, they will split it up to 3 times without a charge.

If you have a dev box you could play around more and understand what happens.

You could also ask your CSM for a temp trial license for a short period of time to experiment with this.

If you are not comfortable doing this on your production box then I would suggest getting a dev box for your nexpose testing and development.

2 Likes