Internal Network Scanner
To run an internal network scanner, place a local agent inside your private subnet. Then grant that agent read roles to check hosts, ports, and local databases. Most teams set up these tools with broad admin keys for fast results. Yet wide permissions create huge risks if an attacker steals the scanner keys. How an internal network scanner works in private subnets An outside tool can only see public web ports on your border firewall. It misses the servers, databases, and apps running deep ins
Internal Developer Platforms (IDP): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run an internal network scanner, place a local agent inside your private subnet. Then grant that agent read roles to check hosts, ports, and local databases. Most teams set up these tools with broad admin keys for fast results. Yet wide permissions create huge risks if an attacker steals the scanner keys.
How an internal network scanner works in private subnets
An outside tool can only see public web ports on your border firewall. It misses the servers, databases, and apps running deep inside your private zones. You must place a local engine inside each private zone to see everything. This engine sends packets to nearby hosts to find open ports and services.
Port checks alone do not show the full security picture of a host. The tool also needs to log in to servers and databases to check patches. Teams set up dedicated service accounts on targets for these deep checks. For Linux hosts, the engine uses an SSH key to read package lists. For Windows servers, it uses a domain account to read local registry states. Database checks require a user role that can read system tables and views.
How to scope credentials for deep host checks
Many teams take a dangerous shortcut when they set up target accounts. They give the scanner a full root or database admin role everywhere. This makes setup fast, because the tool hits no permission walls during runs. Still, that single account now holds the keys to your entire kingdom.
A safer setup uses a strict read-only role for every target type. On servers, create a local user that cannot run privileged commands. Grant this user permission to read only version files and software lists. In databases, create a role that reads only system catalogs and settings. Never let the check account read raw customer tables with emails or phone numbers. Store the account keys in a central secret store and rotate them often. Also, restrict the source IP so the account works only from the scanner host.
Internal Developer Platforms (IDP): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native scanner permissions solve and what they leave open
Scoped service accounts and firewall rules solve the first layer of risk. They decide which host can log in and which base role it gets. If someone steals a read-only database key, they cannot drop production tables. Network rules also stop the engine from reaching zones it should not touch.
Yet static roles and network rules leave a major operational gap open. Native controls only check who logs in at the start of a session. They do not inspect what individual commands or queries do in flight. A compromised scanner or an engineer using its key can still run heavy queries. They can pull sensitive schemas or run commands that slow down a live host. Static keys also sit on the scanner disk between scheduled check windows. Teams lack a clear log of every single command the tool ran on targets. Also, if a query hits a table with card numbers or national IDs, native roles do not rewrite matched fields in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between an external and an internal network scanner?
An external tool checks your public IP addresses from outside your firewall. An internal tool runs inside your private network to check local hosts and databases.
Does an internal scan need admin rights on target hosts?
No, you should never grant full admin rights for routine security checks. Create a scoped read-only user that can only read package lists and system settings.
How often should teams run internal network checks?
Most teams schedule automated checks to run once a week during low traffic. You should also trigger a check after major server updates or network changes.