Mapped

Shodan [1] is probably the best-known tool for assessing the threat situation for your organization's network. Of course, Shodan can only check your network from the outside. Various tools such as Nmap, Masscan, or ZGrab can gain similar insights into the network behind the demilitarized zone (DMZ). The open source IVRE [2] tool provides a framework containing all the components you need to obtain results in a format that is just as clear and familiar as those from Shodan.

Although IVRE lets you scan and map your IT infrastructure, it can also analyze the results collectively and display them for interaction. IVRE also imports the output of common scanning tools and merges it into its own database, which means you can integrate IVRE with your existing toolset. In this article, I discuss the feature set that IVRE provides and show you how to set up IVRE for testing and to import initial data into the framework.

Installing and Launching

IVRE has some dependencies and is not always as easy to install as the website claims. If you use Kali Linux in your environment, you can use apt to install on Kali without problems, in most cases. In my setup, I launched IVRE on Linux and used the Vagrant description provided by the developers on GitHub [3] by cloning the repository with the command:

git clone https://github.com/ivre/ivre

Next, create the directories for IVRE's work data and set the access rights accordingly:

mkdir -m 777 var_lib_mongodb ivre-share dokuwiki_data

The Vagrant description relies on a Docker back end and caused issues from time to time when I was downloading images while writing this article. If vagrant up does not work on the first attempt, you can try running the command a couple more times. As an alternative, you could also adapt the Docker definition provided in the docker-compose.yaml file and use it directly. In both cases, five Docker containers are used: one container each for the client application, for MongoDB as the back-end database, for the WSGI server for the API, for the web server as the graphical interface, and finally for DokuWiki to document the results.

If the launch procedure worked, you can now type http://localhost/ in your browser's address bar to access the IVRE web application. At this point you will not see any content because IVRE has not yet transferred the results data to the database. You now have a number of options for generating the data to import. Theoretically, you could now simply start Nmap on your system (e.g., to scan a private home network); just swap in the correct network prefix in the command:

nmap -Sv -oX localnet.xml 192.168.0.0/24

The results of the scan are stored in the localnet.xml file. The next step is to publish the file in the container for processing by IVRE downstream. In this trial environment, calling Nmap directly from inside the container with IVRE is easier. To start, run a command to discover the ID or name of the Docker container and launch an interactive shell in the container:

docker ps
docker exec -ti ivreclient /bin/bash

You can now work directly with IVRE at the command line. If you use the same environment as before, the command is:

ivre runscans --network 192.168.0.0/24 --output=XMLFork

Now you need to give IVRE some time to scan your network, unfortunately without the help of a progress bar. If you return to the prompt and do not see any serious errors in the output, you can now run the following command to transfer the results of the XML files from all accessible computers to the IVRE database:

ivre scan2db -c Admin-Magazine -s NMAP -r scans/NET-192.168.0.0-24/up

The -c switch lets you enter an arbitrary name for the entry category, which could also be a reference to network segments or the tools you used. The output from the import shows the number of results. If you check the web interface again directly after importing, you might be surprised to see nothing. The data is now in the database and can be searched by typing at the prompt,

ivre scancli --port 80

which reports the Nmap results for all endpoints that use port 80.

To make the data available in the web interface, run

ivre db2view

The output also indicates that IVRE is trying to collect additional information on the endpoints found from other sources. To use this information, run the

ivre getwebdata

command and then restart provisioning with db2view.

You have now successfully prepared the results for display with only a few minor warnings. You need to run this command regularly to make sure you have up-to-date data from these external sources at all times. If you refresh the web view again now, you should see some initial results on your dashboard.

IVRE has options for filtering and searching against the data with various criteria. For example, you could search for specific IP ranges, ports, or services to select specific endpoints and information. This filtering helps focus attention on the most important results and identify potential vulnerabilities more quickly.

You can add an mnemonic entry to the integrated DokuWiki for each endpoint the program finds. To do so, click on the small pencil icon at the edge of the results map to open DokuWiki in the right-hand window area, where you can create the documentation.

Active vs. Passive Monitoring

What you have seen so far with IVRE has all been based on manual (active) execution, but you can continue to provide data passively in the background, which IVRE then analyzes and processes. Active monitoring is about scanning individual networks and collecting data related to endpoints, open ports, running services, and other components they contain. This method is particularly effective if you are looking for an ad hoc overview of the structure and security of a network.

A typical example of an active scan is the use of Nmap, as mentioned before. By integrating the Nmap scans into IVRE, the data can be analyzed in detail and visualized. However, active monitoring is not without risks – especially in production environments where it can be conspicuous and potentially trigger alarms.

In contrast, passive monitoring (i.e., a more traditional approach in which no direct interaction occurs with the target systems) instead uses information collected from publicly accessible sources, such as network traffic monitoring, DNS queries, or data from public services. IVRE supports passive monitoring by analyzing data that can be permanently imported from various sources in the background. You could also use this passive approach to implement offline monitoring (e.g., with packet capture, PCAP, files created from network data acquisition) to obtain interesting information about the monitored network in a less invasive way.

Conclusions

IVRE is more than just a tool for reconnaissance on your private network. Its flexible framework can be integrated easily into existing IT infrastructures, supporting both active and passive network detection use cases. The ability to integrate various tools, the automation options, and the visualization tools make IVRE a great local alternative to commercial services such as Shodan. Once set up in a production environment, IVRE helps you secure your network and detect threats at an early stage.