Abuse policy and reporting — SuperDMZ

Last updated: 28 September 2026

SuperDMZ publishes reverse tunnels: a customer runs a small client inside their own network and we give that service a public hostname under dmzgate.com. The service at the far end belongs to the customer — we operate the road, not the destination. This page states what we forbid, how to report a tunnel that breaks those rules, and exactly what we do when a report checks out.

Reporting abuse
[email protected]

1. Reporting abuse

Write to [email protected]. The mailbox is monitored by the people who operate the service, not by a ticket robot.

We acknowledge within one business day and, on a report we can confirm, we act within 24 hours. Please include whatever you have:

  • the full hostname (something.dmzgate.com), or the node IP and port;
  • timestamps with time zone — UTC preferred;
  • what you observed, in one or two sentences;
  • evidence: log excerpts, URLs, file hashes, packet captures, screenshots.

You do not need an account, and you do not need to encrypt the message. If you want to be told the outcome, say so and we will write back when the case is closed.

2. What is not allowed

A tunnel may not be used to run or assist any of the following, whether the traffic targets our network or someone else’s:

  • Botnet command-and-control — panels, beacons, check-in endpoints, RAT controllers.
  • Malware — hosting, staging or distributing it, including loaders and droppers.
  • Phishing and any page that impersonates another organisation to harvest credentials or payment data.
  • Spam or bulk unsolicited messaging, and infrastructure that supports it.
  • Attacks on third parties — port scanning, brute force, credential stuffing, exploitation attempts, denial of service.
  • Child sexual abuse material. Reports of CSAM are acted on immediately and reported to the authorities.
  • Anything else unlawful under Brazilian law, where the service is operated.

Security research and penetration testing are welcome against systems you are authorised to test. If that is what you are doing, a note to [email protected] beforehand saves everyone a takedown.

3. What happens after a confirmed report

The order matters, and it is always this one:

  1. Evidence is preserved first. Deleting a tunnel cascades its connection records away, so a snapshot is written to cold storage before anything is touched.
  2. The tunnel token is revoked on the node, so the customer’s client cannot reconnect — this, not DNS, is what actually closes the door.
  3. The account is blocked and flagged, with the reason and the evidence recorded against it.
  4. The DNS record is removed, so the hostname stops resolving to our node.
  5. The source addresses are banned on the panel and on the firewall of every node.

We do not send the operator of a confirmed abuse case our usual “your tunnel was deleted” notice, and a repeat of the same abuse is blocked on sight without a fresh investigation.

4. What we can and cannot see

This decides how quickly we can confirm a report, so it is worth being plain about it.

HTTP and HTTPS tunnels terminate TLS on our node. When we are investigating a report we can look at what is being served, and we do.

TCP tunnels (SSH, RDP, database ports, game servers) carry raw bytes end to end. We cannot read them, and we do not try. For those we work from connection metadata — source addresses, how many connections, how long they lasted, how many bytes moved. A botnet beacon has a distinctive shape in that metadata even when the payload is opaque: many short connections, almost all moving no bytes at all, from a concentrated set of sources.

The Security & Technical Transparency page describes the traffic path in full.

5. For blocklist and CERT operators

dmzgate.com is shared infrastructure. Every hostname under it is a different customer’s service, the way it works for any tunnelling or dynamic-DNS provider. One abusive hostname does not make the domain dedicated to abuse, and a listing at the apex takes down thousands of unrelated services.

If you have identified a specific hostname, tell us which one and we will take it down and tell you what we found. We would rather remove the tunnel than argue about the domain.

Contact: [email protected]. No PGP, no forms, no account needed.

6. Law enforcement and preservation requests

Requests from competent authorities go to [email protected] and are answered by the operator of the service. SuperDMZ is run by DestinoLivre Tecnologia Ltda, in Brazil, and is subject to Brazilian law.

We hold account records and connection metadata — source address, timestamps, duration and byte counts per connection. We do not hold the contents of TCP tunnels, because they never exist in a readable form on our side. A documented preservation request freezes what exists at the moment it arrives; the sooner it reaches us, the more there is to freeze.