How It Works: Core Architecture

The Sensor

The sensor is a lightweight point of presence on the internet, nothing more. It requires:

• Ubuntu/Debian server with a public IP address
• Minimal resources: ~0.5GB RAM, single CPU (a $3/month cloud instance or Raspberry Pi works)

Deploying a sensor is done via a single one-line SSH command. The sensor’s only job is to receive inbound internet traffic and forward it to the GreyNoise cloud, it does not process, emulate, or run any profiles locally.

The WireGuard Tunnel

All traffic is received by the sensor is routed to GreyNoise’s cloud infrastructure via a WireGuard tunnel. When a packet hits your sensor, it is forwarded over the WireGuard tunnel into the GreyNoise cloud and routed to the profile mapped to your sensor.

The Profile (runs in GreyNoise Cloud)

Profiles are emulations or real software used to provide services on your sensor for deception and attracting attackers. They run in GreyNoise’s cloud, not on your sensor. The GreyNoise control plane routes traffic from the sensor to the appropriate profile instance based on the sensor-to-profile mapping.

Sensor ↔ Profile Relationship

• 1 sensor = 1 profile at a time, to maintain a realistic device appearance
• Profile switching requires no sensor redeployment. It's done via the UI in seconds, and the remapping completes in ~5 minutes
• Each sensor requires a unique public IPv4 address for believable deception
• IPv6 not currently supported but is on the roadmap

Security Isolation

Because all emulation runs in GreyNoise’s cloud:

• Zero lateral movement risk to the network where you deployed the sensor
• If a vulnerable profile gets exploited, the compromise lands in GreyNoise’s cloud environment, not the network where you deployed the sensor
• Outbound traffic is restricted by default to manage reputational risk, in the future the user will be able to configure whether outbound traffic is allowed.
• Only SSH (on an ephemeral port or one of your choosing) remains exposed for sensor management