natlas is an open-source platform that orchestrates continuous nmap-based scanning across your authorized address space, centralizing results in Elasticsearch for exposure review.
| Tool | natlas/natlas — a dockerized scanning platform combining a server, distributed agents, and Elasticsearch for continuous exposure monitoring |
| Category | Attack surface management / network reconnaissance automation |
| Primary Use | Running continuous nmap scans against assets you are authorized to assess, then searching collected results for exposures like SSH password auth, open NFS/SMB/rsync shares, and weak SSL configurations |
| Safe Use | Intended for defenders and authorized security teams scanning their own or contractually authorized networks to identify and remediate unintended exposure |
| Telemetry Note | Because natlas wraps nmap, its activity is fully visible to defenders as repeated, structured port scans originating from agent hosts; monitoring for periodic scanning patterns from known agent IPs reveals its use |
natlas describes itself, with some dry humor, as attack surface management since before attack surface management was a thing. The name is a play on the idea of an atlas: you have a lot of unruly maps, so you bind them into a book. Here the maps are nmap results and the book is a web application backed by Elasticsearch. The project's stated objective is not vulnerability identification per se, but exposure identification — knowing, continuously, what your authorized address space is actually showing to the network. That framing matters, because it positions natlas as a defensive hygiene instrument rather than an exploitation framework.
Architecturally, the README lays out a clean three-component model. A minimal deployment needs one Elasticsearch node, one natlas-server, and one natlas-agent, all of which can run as containers on a single box. The required deployment order is explicit: Elasticsearch first, because the server refuses to launch without a working connection to it, then the natlas-server, and finally one or more agents. As of June 15, 2020, the project moved to a docker-only deployment model, which simplifies operations considerably and is reflected in the docker pull badges for both natlas/server and natlas/agent images on Docker Hub.
The division of labor between server and agent is worth pausing on. The natlas-server handles agent orchestration, scan configuration, and provides search and browse over the data stored in Elastic. The natlas-agent is the worker: it fetches work from the server and actually performs the scans. This is a classic pull-based work distribution pattern, which means agents can live on multiple hosts across different network vantage points while a single server coordinates what gets scanned and when. For an internal security team, that translates into placing agents inside segments where exposure looks different than from a central scanner.
The scanning engine itself is nmap, the de facto standard port scanner. The README is careful to note that because natlas uses nmap, you can leverage any of the default nmap scripting engine scripts in your scans. That is a significant capability multiplier: the NSE corpus covers service version detection, protocol misconfiguration checks, and certificate inspection, all of which feed directly into the exposure-oriented use cases the project highlights.
Those use cases are concrete and telling. The README suggests checking that nobody is running ssh with password authentication enabled, hunting for exposed nfs, smb, or rsync shares, and looking for expiring or expired SSL certificates or weak SSL ciphers. This is the daily bread of attack surface management: the unglamorous misconfigurations that turn into incidents. A platform that runs these checks continuously, rather than once a quarter during an audit, closes the window between a misconfiguration appearing and someone noticing it.
From a data perspective, the choice of Elasticsearch as the backing store is pragmatic. Continuous scanning generates high-volume, semi-structured results — exactly what Elastic ingests well and what its query layer makes searchable. The server exposing search and browse over that store means the collected history becomes an investigable dataset: you can ask what a host looked like last month, or which subnets recently grew new listening services. The README wisely points newcomers at Elastic's own instructions for a single-node docker cluster and emphasizes persisting the elastic data, an easy mistake for first-time operators.
The project's provenance is visible in the acknowledgements. natlas grew out of an initial project called nweb created by Dean Pierce (pierce403), with contributions including Elasticsearch theory from Adam Jacques and, notably, a Cyclic PRNG for target selection written by Ross Snider. That last detail is architecturally interesting: deterministic pseudorandom target ordering means scan coverage distributes evenly across the address space rather than scanning sequentially, which avoids both predictable scan patterns and accidentally hammering adjacent targets in bursts. Licensing is Apache-2.0, with copyright headers referencing 0xdade and, from 2016–2018, Intel Corporation — a hint at the project's institutional history.
For defenders, the telemetry story is straightforward. natlas does not hide; it industrializes nmap. Any organization running it will see structured, recurring port scans originating from its agent hosts, and conversely, defenders elsewhere can detect natlas-style activity the same way they detect any systematic scanning: periodic connection attempts across port ranges from fixed infrastructure. This transparency is appropriate for a tool whose purpose is authorized self-assessment, and it reinforces the point that this belongs in your own environment, pointed at ranges you own or are contracted to assess.
The repository also shows healthy engineering hygiene for an open-source project of its size — around 660 stars and written primarily in Python. There is a pre-commit integration badge, a CONTRIBUTING.md with a documented project setup path for developers, a code of conduct, and a dedicated SECURITY.md outlining reporting guidelines and security-related functionality. These are the markers of a project that expects to be deployed in sensitive environments and takes both code quality and vulnerability disclosure seriously.
Where does natlas fit in a modern toolchain? It competes conceptually with commercial attack surface management platforms, but its scope is deliberately narrower: it is about network-layer exposure from nmap data, not certificate transparency logs, external asset discovery, or dark web monitoring. For an internal team that already trusts nmap and wants continuous, searchable, historically retained scan coverage of internal ranges — lab networks, corporate segments, cloud enclaves they administer — natlas offers a self-hosted, Apache-2.0-licensed answer that keeps all data in-house. The docker-only model keeps the operational footprint small: three containers on one server gets you a working deployment, and scaling out means adding agents.
The bottom line for an authorized professional: natlas is a legitimate, well-documented platform for continuous exposure monitoring of networks you are entitled to scan. Its value is not in finding novel vulnerabilities but in systematically surfacing the misconfigurations — open shares, weak ciphers, password-authenticated SSH, stale certificates — that dominate real-world compromise precursors. Deploy it against your own ranges, persist your Elasticsearch data, and let the accumulated scan history become the atlas it promises: a bound collection of maps you can actually navigate.
natlas/natlas.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.