Natlas is a project born out of a desire for improving security, and as such, the team behind Natlas strives to take into account security considerations during the design and development of the platform. Built by hackers, Natlas is extremely receptive to constructive criticisms and research into trying to break our project. Natlas approaches security with a "secure by default" mentality.

There is currently no security@natlas email address, however vulnerabilities can be submitted directly to dade via his email dade@actualcrimes.org. For non-critical security concerns, please feel free to file a github issue.

Out of the box, the Natlas server requires authentication of both users and agents, and denies new users from registering. The only way to get access to the server initially is to have shell access to the container running the server.

Natlas uses werkzeug's generate_password_hash function in order to generate salted hashes for passwords. This uses pbkdf2:sha256 by default, and a salt length of 8.

Tokens (API, invitation, etc) used by Natlas are all generated by the secrets module that ships with python. Tokens are compared using a function provided by the secrets module that is resistant to timing attacks.

All of Natlas' routes are protected with Flask WTF's CSRF protection and a randomly generated server-side SECRET_KEY. The only routes that are not protected by CSRF protection are the /api/ routes, as they are only used by the agents. The API agent authentication is separate from user authentication, so when Natlas has Agent Authentication turned on, those routes aren't accessible without the relevant API keys.

Natlas uses the Jinja templating engine, which uses autoescaping by default. No user supplied (or agent supplied) information should ever be treated as safe input. An easy check for this is to look for safe and autoescape in natlas-server/app/templates/.

Since the server's job is to task agents with work, Natlas agents are built defensively against a potentially malicious server. They won't run nmap scripts that they don't already know about, nor will they run nmap with flags they don't already know about. This does however mean that agents don't support all nmap capabilities out of the box.

Agents also protect their local network by defaulting to NATLAS_SCAN_LOCAL=False which prevents them from scanning RFC1918 addresses. Although Natlas agents use subprocess to shell out to external security tools, the subprocess is never executed with shell=True, which prevents shell injection in script names or target names.

Since nmap's most usable output format is XML, Natlas is forced to deal with xml parsing. The Natlas project uses it's own fork of python-libnmap, natlas-libnmap, which uses the defusedxml python package to prevent billion laughs as well as numerous other XML attacks.

While Natlas itself doesn't set any security headers, the provided nginx configuration natlas-server/deployment/nginx provides a number of security related settings, including X-Frame-Options DENY, X-Content-Type-Options nosniff; and X-XSS-Protection "1; mode=block";. It also contains a number of TLS related security settings that provide some of the best TLS configurations available. More information can be found by reviewing the config file yourself.