Skip to content

Latest commit

 

History

History
163 lines (113 loc) · 10.4 KB

README.md

File metadata and controls

163 lines (113 loc) · 10.4 KB
Raw

Deepfence Logo

GitHub license GitHub stars GitHub issues GitHub wiki Demo Docker pulls Slack Twitter

CVE-2021-44228 Log4J Vulnerability can be detected at runtime and attack paths can be visualized by ThreatMapper.

  • Live demo of Log4J Vulnerability here
  • More details here

ThreatMapper - Runtime Vulnerability Management and Attack Path Enumeration for Cloud Native

Deepfence ThreatMapper hunts for vulnerabilities in your production platforms, and ranks these vulnerabilities based on their risk-of-exploit. You can then prioritize the issues that present the greatest risk to the security of your applications - read more.



Learn the Topology

Identify Vulner­abilities

Discover Attack Paths

See ThreatMapper running with a live demo.

Getting Started with ThreatMapper

ThreatMapper.mp4

Planning your Deployment

The ThreatMapper console can be deployed on a single docker host or in a Kubernetes cluster.

ThreatMapper then monitors your development or production workloads using Sensor Agents. The sensors can be deployed on a wide range of platforms - Kubernetes, Docker, Fargate, Bare-Metal and Virtual Machines. Check the prerequisites before you proceed.

Install the Management Console

Installing the management console on a Docker host (4 cores, 16Gb) is as straightforward as:

wget https://github.com/deepfence/ThreatMapper/raw/master/deployment-scripts/docker-compose.yml
docker-compose -f docker-compose.yml up --detach

Once docker-compose has detached, allow 30 seconds or so for the console to complete its startup. Note that the console uses an untrusted self-signed TLS key by default (how to fix).

Installation on Kubernetes is performed with a Helm Chart:

# Install OpenEBS, and wait for it to start up
kubectl create ns openebs
helm install openebs --namespace openebs --repo "https://openebs.github.io/charts" openebs --set analytics.enabled=false
kubectl get pods -o wide --namespace openebs -w

# Install the Kubernetes metrics service (if not already installed)
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.5.0/components.yaml

# Configure the Deepfence ThreatMapper Helm Chart
helm repo add deepfence https://deepfence-helm-charts.s3.amazonaws.com/threatmapper

# Install the ThreatMapper console and wait for the pods to start up
helm install deepfence-console deepfence/deepfence-console
kubectl get pods -o wide -w

# Optionally, install the Deepfence Router service and wait for the platform to deploy a load balancer
helm install deepfence-router deepfence/deepfence-router
kubectl get --namespace default svc -w deepfence-router

More details are in the ThreatMapper documentation.

Initial Configuration

Once the Management Console is up and running, you can register an admin account and obtain an API key.

When the console first starts up, it will begin to acquire the Threat Intel feed data; this usually takes a few minutes, but can take up to an hour. You can install sensors and browse the topology of your applications, but you will not be able to perform vulnerability scans until the threat feeds have been fully acquired.

Install the ThreatMapper Sensor Agents

Install the Sensor Agents on your production or development platforms. The Sensor Agents report to the Management Console; they tell it what services they discover, provide telemetry and generate manifests of software dependencies.

The following production platforms are supported by ThreatMapper sensors:

  • Amazon ECS: ThreatMapper sensors are deployed as a daemon service using a task definition.
  • AWS Fargate: ThreatMapper sensors are deployed as a sidecar container, using a task definition.
  • Google Kubernetes Engine: ThreatMapper sensors are deployed as a daemonset in the GKE cluster.
  • Azure Kubernetes Service: ThreatMapper sensors are deployed as a daemonset in the AKS cluster.
  • Kubernetes: ThreatMapper sensors are deployed as a daemonset in the Kubernetes cluster, using a helm chart.
  • Docker: ThreatMapper sensors are deployed as a lightweight container.
  • Bare-Metal or Virtual Machines: ThreatMapper sensors are deployed within a lightweight Docker runtime.

For example, run the following command to start the Deepfence Sensor on the Docker host:

docker run -dit --cpus=".2" --name=deepfence-agent --restart on-failure --pid=host --net=host \
  --privileged=true -v /sys/kernel/debug:/sys/kernel/debug:rw -v /var/log/fenced \
  -v /var/run/docker.sock:/var/run/docker.sock -v /:/fenced/mnt/host/:ro \
  -e USER_DEFINED_TAGS="" -e MGMT_CONSOLE_URL="---CONSOLE-IP---" -e MGMT_CONSOLE_PORT="443" \
  -e DEEPFENCE_KEY="---DEEPFENCE-API-KEY---" \
  deepfenceio/deepfence_agent_ce:latest

On a Kubernetes platform, the sensors are installed using a Helm chart:

helm repo add deepfence https://deepfence-helm-charts.s3.amazonaws.com/threatmapper

# helm v2
helm install deepfence/deepfence-agent \
    --name=deepfence-agent \
    --set managementConsoleUrl=---CONSOLE-IP--- \
    --set deepfenceKey=---DEEPFENCE-API-KEY---

# helm v3
helm install deepfence-agent deepfence/deepfence-agent \
    --set managementConsoleUrl=---CONSOLE-IP--- \
    --set deepfenceKey=---DEEPFENCE-API-KEY---

Next Steps

Once the sensor agents have been installed, you can begin to explore the topology of your infrastructure and applications.

Subsequently, when the threat feeds have been acquired, you'll see a message on Settings -> Diagnosis. You can begin with your first Production Vulnerability Scan.

Check out the Deepfence ThreatMapper wiki for how to get started with using Deepfence ThreatMapper.

Get in touch

Security and Support

For any security-related issues in the ThreatMapper project, contact productsecurity at deepfence dot io.

Please file GitHub issues as needed, and join the Deepfence Community Slack channel.

License

The Deepfence ThreatMapper project (this repository) is offered under the Apache2 license.

Contributions to Deepfence ThreatMapper project are similarly accepted under the Apache2 license, as per GitHub's inbound=outbound policy.