Post Syndicated from Shane Queeney original https://blog.rapid7.com/2022/09/12/insightvm-best-practices-to-improve-your-console/

Over the years, our recommendations and best practices for the InsightVM console have changed with the improvements and updates we’ve made to the system. Here are some of the most common improvements to help you get the most out of your InsightVM console in 2022.

Ensure everything is up to date

The first step to ensuring the health of your console is ensuring it is up to date. For InsightVM product updates, the typical release schedule is weekly on Wednesday, with the occasional out-of-band update. To stay on the latest version, you can set the update frequency to every 24 hours and set it to off-hours to perform that check. This will ensure the latest update is being applied and the console isn’t rebooting in the middle of the workday.

The InsightVM content updates include new vulnerabilities updated every 2 hours. As these don’t require a system reboot, it is recommended to leave them set to automatically update.

Make sure your scan engines are properly updated as well. As long as the scan engine has enough storage space and can reach the InsightVM console, it should be able to receive the latest update.

Unless you are on a Rapid7-hosted console, you are also in charge of updating the underlying operating system. That means not just applying the latest security patch, but also making sure the OS version itself is not end-of-life.

Lastly, you want to make sure you’re running the latest version of the InsightVM postgreSQL database — version 11.7. If you are still running version 9.4, this can cause some potential issues with the database, as well as general slowdown in the console and running reports.

With the latest InsightVM product updates, we also have a database auto-tune feature which automatically tunes based on the amount of RAM on the console server. This feature does not work if you are still on version 9.4. If you are on version 11.7, to activate it, go to Administration -> Run and then run the command tune assistant to make sure everything is tuned correctly. This will have a greater impact if you have 64GB RAM or above.

Check out this doc on tuning the PostgreSQL database for more detail. If you don’t feel comfortable tuning your own database, you can always contact Rapid7 support for assistance.

Reduce the number of sites

One of the largest improvements to the console is the increase in scan efficiency. Before October 2020, the discovery portion of the scan would only hit 1,024 assets simultaneously. Now, we are running discovery against 65,535 IPs at once. This leads to much faster discovery of larger IP ranges. Because of this, we recommend having fewer sites with larger IP scopes, such as /16 or /8 CIDR ranges.

The best way to organize these new, larger sites is based around function or geographical region – for example, having a separate site for all stores and one for all corporate ranges. Another example would be to break up the sites based on continents, or as large of a geographical region as possible.

Having fewer sites with a larger scope will help reduce the micromanagement of schedules and allow for ease of scalability when scanning more devices. For granular reporting, use asset groups, which are much more flexible than IP ranges and are designed to let you set the scope for reports and access management.

Prevent scan overlap

Besides having too many sites, the next-largest problem most consoles face is when scans overlap on the same scan engine. Having fewer sites helps with having fewer scheduled scans, but you should still be aware what scan engine is being used for those sites. Running a scan uses up RAM on the scan engine, and having too many scans running at once can cause scan slowdown or potentially engine crashes due to lack of memory.

The best-case scenario is to have one scan engine per site. That way, your sites can be scanned at the same time without any chance of them overloading a single engine. If you have some sites or locations that are much larger than others, you can always deploy more engines to that location and pool them together for even greater scan efficiency.

And remember, if you’re scanning more than 2,000 devices or have a segmented network, you should not be using the local scan engine, as that takes away resources from the console and PostgreSQL database.

Optimize scan templates

After making sure your scans aren’t overlapping on the same engine, the next step is to speed up the scans by optimizing your scan template. My colleague Landon Dalke wrote a great blog post documenting the best practices for your scan templates. Here are a few highlights from his post:

Assets scanned simultaneously per scan engine: Please use the following table for reference depending on how much CPU and RAM your scan engines have. Make sure your engines have a 1:4 ratio of CPU to memory for the best performance. Also, if your scan engines are virtual, make sure to reserve the allocated memory to avoid insufficient memory issues.

Send UDP packets to ports: We recommend disabling. It’s unlikely a device will be reachable that doesn’t respond to ICMP, ARP, or TCP but is somehow found only using UDP.

Do not treat TCP reset responses as live assets: We recommend enabling. This will help prevent “ghost assets” with no hostname or operating system from appearing, as some routers or IDS/IPS send TCP reset responses.

Nmap Services Detection: We recommend disabling this, as it can cause scans to take five to 10 times longer to run. Having a credential or agent on a device gives the same information.

Skip checks performed by the Insight Agent: We recommend enabling. If the agent is detected on a device, it will skip the vulnerability checks the agent is already performing, reducing scan time.

If all of your scan engines have the same resources, you can get away with needing one optimized scan template, reducing potential confusion and further simplifying your scan configurations.

After following these steps, your console should be in a much better place to reduce micromanagement and improve overall efficiency. If you need continued help and support, don’t hesitate to reach out to Rapid7 Support or your Customer Success Manager.

Additional reading:

• 5 Steps for Dealing With Unknown Environments in InsightVM
• What’s New in InsightVM and Nexpose: Q2 2022 in Review
• InsightVM Release Update: Let’s Focus on Remediation for Just a Minute
• Maximize Your VM Investment: Fix Vulnerabilities Faster With Automox + Rapid7

Post Syndicated from John Hartman original https://blog.rapid7.com/2022/09/06/5-steps-for-dealing-with-unknown-environments-in-insightvm/

Trying to deal with a large network can be difficult. All too often, engineers and admins don’t know the full scope of their environment and have trouble defining the actual subnets and the systems that exist on those subnets. They know of a couple /24 subnets here or there, but it’s very possible they’re missing a few. Once you get over a couple thousand assets, it can get fairly unruly pretty quick. Different teams own different servers and different network ranges. With regards to InsightVM, how do you know what sites create if you don’t even know what you own?

Luckily, in InsightVM, we can use a little bit of SQL, an overarching site with a ping sweep, and a nifty little tag to help get a handle on things – all outside any third-party software or  other management tools you may acquire to help you wrangle in your IP space. This method in InsightVM lets you find all live assets and identify all network spaces being used in your environment. Then, we can correlate this list against our known subnets and begin building out defined sites for scanning. As we create our known sites, we can start whittling down the number of unknown or undefined subnets.

1. Ping Sweep template

The first step is to create a new scan template dedicated solely to a ping sweep. This template isn’t scanning for any other services or ports, fingerprinting, or performing any other action –  it is simply sending pings to see what is alive. If we get a response back, we assume there is a live asset there, and this will help build out our known networks.

Create your template using these screenshots as guidance. Note that pretty much everything is off except ICMP and ARP pings, and we’re not treating TCP resets as live assets (we don’t want firewalls throwing us off). This scan should take just a few minutes to complete, as it’s not doing all the other functions that a typical scan can do.

2. Overarching site

The second step in this process is to create an overarching site. Give it a simple name like “Full Network” or whatever floats your boat. What’s important is that, within this site, you define as large of a network range as you know of. Think /16 here, or even a couple /16 networks. I don’t know your network, so use your judgment as to what you think exists. The idea is to be as broad as possible.

Now, within this site, set the default scan template as your “.Ping Sweep” template, as in my example above. Set your default scan engine or pool, and then save and scan.

What you should get back now is a full list of every live IP that exists within the defined network. If your defined network includes all the possible IP space, and we are assuming that all assets are online and able to respond, then you should have a pretty robust list of found assets.

3. Known Networks report

The next step is to go to the Reports tab and create a SQL Query Export. Throw the following SQL query in the definition, and scope the query from the GUI to your “Full Network” site.

WITH a AS (
SELECT
asset_id,
CONCAT(split_part(ip_address,'.',1),'.',split_part(ip_address,'.',2),'.',split_part(ip_address,'.',3),'.0/24') AS Network
FROM dim_asset
)
 
SELECT DISTINCT Network
FROM a
ORDER BY Network ASC

Save and run this report, and you will get a CSV output of all the /24 networks that have at least one live IP in them. You can use this CSV to compare to your known list of networks and start defining the actual sites within your environment. For example, if this report lists out 10.0.0.0/24 and you know that network as your main corporate server’s VLAN, then you can include that network into a separate site for vulnerability scanning.

4. Dynamic tagging

Now that we’ve started defining our known networks into sites, we need to create a dynamic tag that gets applied to all assets within any site. Now, in my example, I exclude the Rapid7 Insight Agents site, because depending on your environment and whether people are working from home, the Insight Agent may report the IP of their computer when logged onto their home network. We obviously can’t scan home networks, so we want to exclude this site to deter any of that bad data.

Create a dynamic tag with several lines to include each site. Note that if your site structure is large enough that you have hundreds of sites, you may want to use the API for this part, but we won’t go into that here – that’s a whole other conversation.

In my example below, I only have four sites – keep in mind I did not select the Rapid7 Insight Agents or my Full Network site. Make sure the operator is set to match ANY of the specified filters. Apply a tag called “Defined Network” to this criteria to tag all assets within a defined site.

You could also optionally create a secondary tag for “Undefined Networks,” but it’s not exactly necessary for this process. The below query would get you the Undefined Network assets. Basically, the query is just looking for any assets that don’t have the Defined Network tag and are not in the Rapid7 Insight Agents sites.

5. Undefined Networks report

Now, we can set up our secondary SQL report to show us all networks that are not defined within the scope of a site. Once again, go to the Reports tab, create a SQL Query Export report, and throw this query into the definition.

WITH a AS (
SELECT
asset_id,
CONCAT(split_part(ip_address,'.',1),'.',split_part(ip_address,'.',2),'.',split_part(ip_address,'.',3),'.0/24') AS Network
FROM dim_asset
)
 
SELECT DISTINCT Network
FROM a
 
WHERE a.asset_id NOT IN (
SELECT DISTINCT asset_id
FROM dim_asset
LEFT JOIN dim_tag_asset USING (asset_id)
LEFT JOIN dim_tag USING (tag_id)
WHERE tag_name = 'Defined Network'
)
 
ORDER BY Network ASC

Save and run this report, and you will get a new CSV that lists out all /24 networks where there was at least one live asset found but the assets are within a /24 that has not been defined within the scope of a created site. You can use this CSV to work your way through those networks to determine what they are and who owns them and then ensure they are included in future or current sites.

Large environments with unknown network components can be difficult to manage and monitor for vulnerabilities. These five steps in InsightVM help make the process easier and more intuitive, so you can maintain better oversight and a stronger security posture within your environment.

Additional reading:

• What’s New in InsightVM and Nexpose: Q2 2022 in Review
• InsightVM Release Update: Let’s Focus on Remediation for Just a Minute
• Maximize Your VM Investment: Fix Vulnerabilities Faster With Automox + Rapid7

Post Syndicated from Emmett Kelly original https://blog.rapid7.com/2022/03/15/insightvm-scanning-demystifying-ssh-credential-elevation/

Written in collaboration with Jimmy Cancilla

The credentials to log into the assets on the network are one of the most critical inputs that can be provided to a vulnerability assessment. In order to capture and report on the full risk of an asset, the scan engine must be able to access the asset so that it can collect vital pieces of information, such as what software is installed and how the system is configured. For UNIX and UNIX-like systems, access to a target is primarily achieved through the Secure Shell Protocol (SSH). Thus, scan engines accessing these systems should have access to the appropriate SSH credentials.

However, this raises the question: What are appropriate SSH credentials? In order for a vulnerability or policy assessment to provide accurate and comprehensive results, the scan engine should ideally be able to gain root-level access to the systems being assessed. Understandably, many security teams are wary about providing the scan engine with root credentials to all of their systems. Instead, security teams prefer to provide a non-root set of credentials that are capable of elevating to become root. In this context, credential elevation means logging into a system with one set of credentials that has fewer privileges and then elevating that credential to gain root-level privileges. In this way, IT administrators can provide service users that can be monitored and easily disabled if necessary.

In the next section, we will look at the different ways that credentials can be elevated.

Elevation options

sudo

The sudo command enables users to run commands with the security privileges of another user, which by default happens to be the root user (superuser). The ability to use the sudo command to elevate to root is a privilege that is provided by the system administrator. The administrator explicitly grants users (or groups) permission to use the sudo command — this is typically done by modifying the /etc/sudoers file on Linux-based systems.

The benefit of having access to the sudo command means that a user does not need to know the root password in order to gain root-level privileges. However, the user attempting to elevate to root-level privileges via sudo may still need to authenticate themselves by providing their own password. This is different from the behaviour of the su command, which will be discussed later.

What this means in terms of configuring sudo elevation in the Security Console is that the Permission Elevation Password on the “Add Credentials” page must be set to the password of the user attempting to elevate to root.

su

Like the sudo command, the su command enables users to run commands with the security privileges of another user, the default being to run the commands as the root user (superuser). However, unlike the sudo command, the su command typically does not require a system administrator to provide explicit permission to use the command. Instead, users can use the su command to switch to any other user on the system but must provide the password of the target user. The implication of this is that in order to use the su command to elevate to root-level privileges, the user must authenticate by providing the root password.

What this means in terms of configuring su elevation in the Security Console, is that the Permission Elevation Password on the “Add Credentials” page must be set to the password of the root user.

sudo+su

If you have read the above sections on sudo and su, you may be asking yourself why you would need to combine the two commands. The answer comes down to a subtle but important difference between the two commands, namely the environmental context in which those commands are invoked. When using sudo to execute another command with root-level privileges, the command is run within the current user’s environment. This means that any environment-specific properties (for example, environment variables) are retained. When using su to execute another command with root-level privileges, su will invoke the default shell used by root and then run the command within that environment. This implies that any environment-specific properties loaded by default when logging into the root user will be set.

Given this explanation, combining the sudo and su commands provides a best of both worlds situation: It allows a user to elevate their privileges to root by providing their own user password, and it will execute the command within the context of the root environment (as opposed to the user’s environment). How does this work?

The first command executed is sudo, which will prompt the user to authenticate themselves by entering their own password. Then, the su command will be run. However, since it is running with root-level privileges, it won’t prompt for another password but instead will execute any commands within the context of the root environment. So to summarize, sudo+su allows for executing commands with root-level privileges within the context of root’s environment but without requiring knowledge of the root password.

What this means in terms of configuring sudo+su elevation in the Security Console, is that the Permission Elevation Password on the “Add Credentials” page must be set to the password of the user attempting to elevate to root.

Important note about sudo, su and sudo+su

The Permission Elevation User should be root. A common misconfiguration when configuring permission elevation is to set this value to the user’s username. This leads to the scan engine logging in as the initial user, then using permission elevation to attempt to elevate to the same user! The credential status will be reported as successful, but the scan results will not have the same accuracy of a correctly configured scan with root permissions.

pbrun

The pbrun command is a utility within the PowerBroker application provided by BeyondTrust. It works similarly to the sudo command in that it allows a user to elevate to root-level privileges without having to provide the root password.

Configuring privilege escalation with pbrun in the Security Console is fairly straightforward, as it does not require any additional passwords beyond the user’s password.

Cisco Enable / Privileged Exec

This option specifically allows a user to elevate to superuser-level privileges on certain Cisco devices using the enable command. Administrators of the Cisco devices will need to have configured an enable password to allow for privilege elevation.

What this means in terms of configuring Cisco Enable / Privileged Exec elevation in the Security Console, is that the Permission Elevation Password on the “Add Credentials” page must be set to the Cisco Enable password configured on the devices.

Perils of not elevating

Elevation is critical to accurately assess an asset for vulnerabilities and system configurations. There are several key pieces of information that can only be collected with root-level privileges. Improperly configuring credential elevation is one of the most common causes of inaccurate or incomplete assessment results. The following table outlines a few key operations and pieces of data that require root-level privileges. It is important to note that this is a non-exhaustive list operations and data requiring root-level privileges – an exhaustive list would quickly become outdated as new data collection techniques are constantly being added to the product.

Conclusion

When it comes to vulnerability management, retrieving accurate and comprehensive results is paramount to mitigating risks within your organization. The most accurate data is collected when the scan engine has root-level access to the systems it is scanning. However, not all organizations may be in a position to provide the root password to these systems.

In this case, a best practice is to provide the vulnerability management software with a service account that is capable of elevating its permissions to root. This allows system administrators to more easily manage who is capable of elevating to root and, if necessary, revoke access. However, there are several different ways that an account can elevate its permissions. Each method comes with subtle but important differences. Understanding those differences is critical to ensuring that elevation to the correct level of permissions occurs successfully.

Additional reading

• InsightVM Scan Engine: Understanding MAC Address Discovery
• What’s New in InsightVM and Nexpose: Q4 2021 in Review
• Distribute Reports to Email Addresses in InsightVM
• InsightVM Scan Diagnostics: Troubleshooting Credential Issues for Authenticated Scanning