Technical Requirements

Nullafi Shield requires minimal resources to deploy, although requirements increase according to the scale of the deployment. The following list is sufficient for a typical customer.

Single Server Full Stack

In the Quick Start Guide, you learn to deploy multiple services (Nullafi Shield containers, a proxy, and two databases) all on the same server. This is a perfectly reasonable way to deploy, even in production, for a relatively small number of users. As user counts grow to hundreds, thousands, or tens of thousands, it makes sense to split up the various services across multiple machines, or even multiple datacenters.

Server Requirements

  • Linux host with Docker or compatible container runtime
  • Optional: Docker Compose for ease of configuration and management
  • At least 4GB RAM and 4GB storage
    • A Shield instance serving as the Management Console or an Alert node might use even fewer resources
    • A Shield instance serving as a Scanning node (either an ICAP or an API instance) with high volume traffic might use substantially more.

Nullafi Shield is distributed as containerized software. Without getting into the complexities of the many options regarding container runtimes and host operating systems, Nullafi tests with containerd. If you’re not intimately familiar with container runtimes and the difference between OCI and CRI and a hundred other acronyms, it’s enough to know that you can use Docker and Kubernetes with Shield. If you are familiar with those terms, then you don’t need us to tell you how to make it work!

For any configuration examples going forward in this document, we’ll assume you are using Docker (in fact, we’ll use Docker Compose yaml format because it’s fairly easy to read) and leave any translation from that to other tools to you.

Network Environment

Internal Traffic

Connections between various components of the system providing the Data Protection service

  • Activity Database: an Elasticsearch database that must be accessible from all Nullafi Shield nodes (Web Management Console, ICAP enforcement nodes, API enforcement nodes, and Alert nodes). The default port is TCP 9200
  • Configuration Database: a Redis database that must be accessible from all Nullafi Shield nodes (Web Management Console, ICAP enforcement nodes, API enforcement nodes, and Alert nodes). The default port is TCP 6379.

Administrative Traffic

Connections between Nullafi Shield administrators and the Data Protection service

  • Administration Console access connectivity from administrator’s PC to Nullafi Shield via a web browser
    • HTTPS for SSL encrypted configuration management (typically 443)
    • HTTP for plain text configuration management (typically 80)

User Traffic

Traffic generated by end users, which is to be scanned by the Data Protection service

  • User traffic flowing through the proxy
    • Each proxy has it's own configuration options, so methods of getting user traffic to the proxy will differ.
    • Using Squid Proxy as an example:
      • Connectivity from client devices to the Squid Proxy (on any port; default is 3128)
      • Connectivity from the Squid Proxy to any web applications to be used (typically ports 80 and/or 443)
      • Optional: certificate signed by a trusted CA for use by the Squid Proxy, or acceptance of Squid’s self-signed certificate
  • ICAP connections from proxy to the ICAP server
    • Connectivity from the proxy to Nullafi Shield on at least one port (typically 1344) for plain text ICAP connections
    • Optional: connectivity from the proxy to Nullafi Shield on an additional port for SSL encrypted ICAP connections (typically 11344)
  • Optional: User traffic connectivity to an Identity Provider (IdP) for directory integration
    • Nullafi Shield can be configured to authenticate users via SAML redirects. In this case, the End Users' browsers need to be able to connect to the IdP (typically via HTTPS on port 443).