Infrastructure for Internet-Wide Security Scanning and Attack Surface Management

Your product scans the open internet. That’s not a side effect of what you do, it’s the product itself, and it puts you in a strange position with most infrastructure providers: your traffic looks, to an automated abuse system, almost identical to an attacker’s.

That’s a real, structural problem for attack surface management vendors, cyber-risk scoring companies, and vulnerability research platforms, not an edge case. Port scanning, banner grabbing, and service discovery across large IP ranges are exactly the behaviors most hosting providers’ abuse detection exists to catch.

Why This Is a Different Problem Than Penetration Testing

It’s worth being precise about what kind of scanning this is, because it’s a different situation than testing your own environment. We’ve written before about building a contained penetration testing lab on private cloud infrastructure, where the core problem is isolating your own security testing from your own production systems, and from a hyperscaler’s automated defenses that can’t distinguish your authorized test from a real intrusion against your own account.

Attack surface management and internet-scanning companies have a different problem entirely. The scanning isn’t contained to infrastructure you own, it’s aimed outward, at other organizations’ public IP ranges, at real scale, as the actual business. The risk isn’t that your own provider’s monitoring flags your test. It’s that the organizations you scan, who never asked to be scanned, file abuse complaints with your provider, and a provider unprepared for that pattern treats every complaint as a strike against your account regardless of whether the underlying scanning was legitimate, non-intrusive, and industry-standard.

What a Provider’s Acceptable Use Policy Actually Needs to Support

The practical question for this business model isn’t whether scanning is allowed in the abstract. It’s what happens the first time someone reports you.

OpenMetal’s Acceptable Use Policy doesn’t proactively monitor customer traffic or content. Enforcement is complaint-driven: if a report comes in, it’s investigated, and OpenMetal retains discretion over how to respond, rather than an automated system auto-suspending an account the moment a complaint lands. For a scanning company operating at genuine internet scale, that distinction matters enormously. Automated, zero-context suspension on first complaint makes this business model impossible to run at all, since large-scale non-intrusive scanning generates some volume of confused or annoyed recipients almost by definition, regardless of how responsibly it’s done. A complaint-driven process that allows for actual review is the structural difference between a provider you can build this business on and one you can’t.

That said, this isn’t a blank check, and it shouldn’t be treated as one. A legitimate scanning operation should expect to explain itself when asked, and a provider’s discretion cuts both ways: it protects reasonable, well-run scanning operations, and it doesn’t protect operations that are actually abusive or that ignore reasonable requests to stop scanning a specific target on request.

Isolating Reputation with Dedicated IP Space

Internet-wide scanning generates a specific technical need that most workloads don’t: IP reputation isolation. Scanning traffic can end up on abuse blocklists and threat-intelligence feeds maintained by third parties, regardless of intent, simply because the traffic pattern matches what those lists are built to catch. If that traffic shares IP space with unrelated customers, one company’s scanning activity can affect another customer’s mail deliverability, web reputation, or general trust score with third-party security tools, which is a real operational risk for a shared-IP environment.

Dedicated, customer-specific IP allocation avoids that cross-contamination. OpenMetal assigns dedicated public IP space per customer and supports bringing your own IP blocks (/24 or larger) for announcement through its network, which means a scanning company’s IP reputation stays its own problem to manage, not something that leaks onto or from other tenants sharing the same address space. If your scanning volume is large enough that IP allocation is a real planning question, that’s worth a direct conversation about your specific range and routing needs rather than assuming a default allocation covers it.

What Legitimate Scanning Companies Should Have Ready Regardless of Provider

A few practices are close to industry standard for this business model, and having them in place makes any conversation with a provider’s abuse team faster and more productive:

• A reverse DNS record and a scan-info page explaining who’s scanning, why, and how to opt out, reachable by anyone who looks up the source IP of an unexpected scan
• A published abuse and opt-out contact that actually gets monitored, so a target organization’s first move is emailing you rather than filing a complaint with your provider
• Documented rate limiting that keeps individual target networks from being hit hard enough to look like a denial-of-service attempt
• A clear internal record of scan scope and intent that can be produced quickly if a provider’s abuse team asks for context on a specific complaint

None of this eliminates complaints entirely. Legitimate, well-run scanning still generates some. What it does is make each complaint fast to resolve rather than a prolonged back-and-forth that puts your account at risk while it gets sorted out.

Who This Fits

• Fits well if your core product involves scanning, fingerprinting, or cataloging systems across large swaths of the public internet that you don’t own or directly manage
• Fits well if you’ve already been suspended, warned, or had service degraded by a hyperscaler or shared-hosting provider for exactly this kind of traffic pattern
• Fits well if IP reputation isolation from other tenants is a real operational requirement, not a nice-to-have
• Doesn’t fit as well if your actual need is testing your own systems or your own clients’ systems under authorization, since that’s a contained penetration-testing scenario with different infrastructure needs, covered in our pentest lab piece

Getting Started

Dedicated bare metal servers and hosted private cloud configurations are on our bare metal pricing page. Full policy details are in our Acceptable Use Policy, and if your scanning volume and IP allocation needs are substantial, that’s worth a direct conversation before you commit to a deployment size.

FAQ

Does OpenMetal allow internet-wide security scanning as a business?

OpenMetal’s Acceptable Use Policy is complaint-driven rather than based on automated, zero-context suspension. Legitimate, non-intrusive scanning for attack surface management or cyber-risk research is a different situation than actual abuse, but any provider retains discretion to act on reports. Review the full Acceptable Use Policy and discuss your specific use case directly before deploying at scale.

Why do hyperscalers suspend legitimate security scanning companies?

Most hyperscaler abuse detection is automated and can’t reliably distinguish authorized, industry-standard scanning from an actual intrusion attempt, especially when third parties who were scanned file complaints. Automated systems often act on complaint volume rather than context, which puts legitimate scanning businesses at risk regardless of how responsibly they operate.

How is this different from a penetration testing lab?

A penetration testing lab is about safely testing systems you own or have explicit authorization to test, contained on infrastructure isolated from your production environment. Internet-wide attack surface scanning targets systems outside your organization at scale as the core product, which raises different questions around IP reputation, third-party abuse complaints, and provider policy, rather than containment from your own systems.

Can I get a dedicated IP block to isolate my scanning traffic’s reputation?

OpenMetal assigns dedicated public IP space per customer and supports bringing your own IP blocks for announcement. For scanning operations at meaningful volume, discussing IP allocation and routing directly, rather than assuming default allocation, is worth doing before deployment.