Nmap Proxychains
Running nmap proxychains sends network port scans through one or more relay hosts. You wrap the scanner command so outbound traffic routes through an existing tunnel. Teams often use this setup to check internal subnets from an outside laptop. Still, broad relay permissions let anyone probe every host on the private network. Once a user enters the tunnel, the network treats all scan packets alike. How the nmap proxychains workflow operates The wrapper works by hooking standard network calls i
Proxychains: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Running nmap proxychains sends network port scans through one or more relay hosts. You wrap the scanner command so outbound traffic routes through an existing tunnel. Teams often use this setup to check internal subnets from an outside laptop. Still, broad relay permissions let anyone probe every host on the private network. Once a user enters the tunnel, the network treats all scan packets alike.
How the nmap proxychains workflow operates
The wrapper works by hooking standard network calls inside the scanning tool. It intercepts outbound socket calls and redirects them to a local listening port. That local port usually belongs to an active SSH tunnel or SOCKS server. Because SOCKS tunnels handle complete TCP connections, raw packet scans will fail here. You must run full TCP connect scans so the OS completes the handshake.
Host discovery also changes when you route scans through a chain of relays. Standard ping sweeps use ICMP packets that cannot pass through a SOCKS tunnel. You must tell the scanner to skip ping checks and treat hosts as online. DNS lookups can also leak out of the local machine during a scan. Teams turn on remote DNS resolution so name lookups stay inside the tunnel.
Why teams chain relays for internal scans
Security teams and engineers need to check ports inside private cloud subnets. Opening firewall rules for every engineer laptop creates too much risk and toil. Instead, teams set up one relay host that can reach the private subnet. Engineers log in to that relay and push their scan traffic through it.
This approach keeps internal services hidden from the public internet at all times. It also lets testers check firewall rules from the view of specific hosts. If a service fails to respond, an engineer can test the port path. The wrapper makes this work with tools that lack built-in SOCKS settings.
Proxychains: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native relay setups solve and leave open
Native tunnel and relay setups solve the basic network reachability problem for teams. They let you cross network borders without giving every laptop a direct route. System owners only need to manage firewall rules for the central relay host.
Yet this setup only decides who can open the initial tunnel session. It does not check or restrict what packets flow through the open port. Once an engineer starts a tunnel, they can scan any reachable IP address. Relay logs only show an encrypted stream or basic target IP addresses. They do not link specific scan actions or database queries to team roles. Sensitive responses with emails, phone numbers, or card numbers return in plain text. Managing local config files across many engineer laptops also creates drift and errors.
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 sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses 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
Why do default stealth scans fail over a relay chain?
Default stealth scans send raw half-open TCP packets that need low-level network control. A SOCKS relay only forwards complete TCP streams managed by the operating system. You must use full TCP connect mode so the relay can pass traffic.
Why do scans run much slower through a relay chain?
Full TCP connect scans must finish a three-way handshake for every single port. Each handshake travels through every hop in your relay chain before returning. High latency or closed ports without reset replies will slow the scan down.
Can I scan UDP ports through a standard SOCKS chain?
Most wrapper tools only hook TCP socket calls and ignore UDP traffic completely. Even when a relay protocol supports UDP, the wrapper library cannot redirect it. You must run UDP checks straight from a host inside the target network.