You check the port.

It is listening.

But then comes the question:

Why is it exposed?

Tools like ss, lsof, and nmap are useful for discovering what is listening or reachable. But they don't necessarily answer the next question:

What configuration caused this service to become exposed?

That was the problem I wanted to solve.

So I built Lantern, an open-source Go CLI that traces a local service from its configuration to its network exposure and explains the root cause.

The Problem

Consider a PostgreSQL container running on port 5432.

You run:

ss -lnt

and see:

*:5432

You now know something is listening on port 5432.

But several questions remain:

• Which process owns the port?
• Is it running inside Docker?
• Which container exposed it?
• Which configuration created the binding?
• Which network interfaces can reach it?
• What should be changed to make it local-only?

Answering those questions manually means jumping between multiple tools and configuration files.

I wanted to connect those pieces.

The Idea Behind Lantern

The core idea is simple:

Configuration
      ↓
Process / Container
      ↓
Socket
      ↓
Bind / Interface
      ↓
Network Reachability
      ↓
Root Cause
      ↓
Recommended Fix

Instead of only reporting:

Port 5432 is listening

Lantern tries to explain why it is listening that way.

A Simple Docker Example

Suppose a docker-compose.yml contains:

services:
  postgres:
    image: postgres
    ports:
      - "5432:5432"

That publishing rule can result in the host exposing port 5432 beyond localhost.

The important question isn't only:

Is 5432 open?

It is:

What caused 5432 to be exposed?

The configuration itself provides an important part of that answer.

Now compare it with:

ports:
  - "127.0.0.1:5432:5432"

The second configuration explicitly binds the host side to localhost.

A developer can therefore trace the exposure back to the configuration instead of manually searching through files.

What Lantern Does

The main command is:

lantern why 5432

The intended output looks roughly like:

PostgreSQL :5432

EXPOSURE PATH

docker-compose.yml
       ↓
5432:5432
       ↓
Docker
       ↓
0.0.0.0:5432
       ↓
LAN reachable

ROOT CAUSE
docker-compose.yml:18

RECOMMENDED CHANGE
127.0.0.1:5432:5432

The goal is to turn several disconnected pieces of system information into one understandable explanation.

Lantern Isn't Another Port Scanner

Lantern is not intended to replace existing tools.

They answer different questions:

Lantern focuses on configuration causality.

That distinction is the main reason I built it.

Safe Remediation

Lantern also has a remediation workflow.

Before changing anything, you can use:

lantern fix 5432 --dry-run

This allows you to inspect the proposed change.

For supported Docker Compose bindings, the actual remediation can then be invoked with:

lantern fix 5432

The design principle is simple:

A security tool should explain what it is going to change before changing it.

What Lantern Is Not

Lantern deliberately has a narrow scope.

It is not:

• a replacement for Nmap
• a vulnerability scanner
• a generic network monitor
• a Docker security scanner
• an Internet exposure detector
• an AI wrapper around existing security tools

Its purpose is much more specific:

Explain the local configuration path that resulted in a service being exposed.

Built With Go

Lantern is written in Go and currently targets Linux and WSL2.

The project separates the investigation into several stages, including:

• listener discovery
• process attribution
• Docker correlation
• network reachability
• configuration evidence
• root-cause analysis
• remediation

The project is also tested with:

go test ./...
go test -race ./...
go vet ./...

The current release is v0.1.1.

An Important Limitation

One thing I intentionally don't want Lantern to do is pretend it knows something when it doesn't.

Docker Desktop on Windows with WSL2 introduces additional networking and forwarding layers.

In some configurations, Lantern can detect that a port is reachable but may not have enough local evidence to confidently attribute that socket back to a specific Docker container.

In those situations, the correct result is an unresolved explanation rather than a fabricated one.

For a security-oriented tool, uncertainty should be visible.

Try It Yourself

Clone the repository:

git clone [https://github.com/DhyaanKanoja11/Lantern.git](https://github.com/DhyaanKanoja11/Lantern.git)
cd Lantern

Build it:

go build ./cmd/lantern

Then:

./lantern version
./lantern doctor
./lantern scan

There is also a reproducible Docker example in the repository:

cd examples
docker compose up -d

Then:

lantern scan
lantern why 5432

You can test the remediation without changing anything:

lantern fix 5432 --dry-run

GitHub: https://github.com/DhyaanKanoja11/Lantern

Why I Built It

The original idea was straightforward.

I didn't want another tool telling me:

"Port 5432 is open."

I wanted something that could answer:

"Why is port 5432 open, and where do I change it?"

That difference becomes important in development environments, where a single configuration line can determine whether a service is available only locally or accessible from other interfaces.

Lantern is my attempt to connect those layers:

Configuration
      ↓
Container
      ↓
Process
      ↓
Socket
      ↓
Interface
      ↓
Reachability

and turn them into an explanation a developer can actually act on.

Feedback

Lantern is still early, and real-world usage is more useful than adding features based on assumptions.

If you try it, I'm particularly interested in:

• Where the explanation becomes unclear
• Cases where attribution fails
• Docker/WSL2 edge cases
• Configurations Lantern doesn't understand
• Whether the recommended fix makes sense

The goal isn't simply to detect an open port.

The goal is to explain why it is exposed.

GitHub: https://github.com/DhyaanKanoja11/Lantern