The EazetechSecurityAudit crawler, and how to stop it.
You are here because our user agent turned up in your logs. Someone asked our free website security audit to check a page on your domain. Here is every request we sent and every way to make it stop.
Why a request arrived
Eazetech runs a free passive website security audit at /tools/website-security-audit. A person pastes a URL into it and gets back a report on the TLS configuration, response headers and redirect behaviour of that address. Somebody typed a URL on your domain. That is the whole reason we appeared. There is no list we work through and nothing about your site drew us to it.
The audit is passive in the strict sense: we read what your server already publishes to every visitor. The page that was submitted, the TLS handshake and certificate behind it, the response headers, the redirect chain, and three well-known files that exist to be fetched. Nothing we send needs a credential, and nothing we send is a guess about what you have on disk. Loading the same page once in a browser produces more traffic than a complete scan does.
Whoever ran it agreed, before the scan started, that they own the site or have permission to test it. Those rules are on the audit terms page. If you own this domain and did not authorise a scan, mail security@eazetech.co with a log excerpt and we will tell you what we hold, delete the report, and block the domain if you want it blocked.
the limits, as shipped
- Ports
- 80 and 443 only
- Targets
- Hostnames only, never IP literals
- Methods
- GET, plus a single OPTIONS preflight
- Concurrency
- Two connections at once, at most
- Redirects
- Followed to a depth of five, then we stop
- Response size
- Capped at 3 MB, then the connection closes
- Encoding
- Accept-Encoding: identity, nothing is decompressed
- Back-off
- Retry-After honoured as sent, on 429 and 503
How to recognise us
Every request carries the same user agent, unchanged, on every endpoint we touch:
That string is the only identifier we can offer you today, and you should treat it as a claim rather than as proof. Anyone can copy a user agent. Two things will fix that, and neither is in place yet.
The first is a published list of the IP ranges the scanner runs from. It will live on this page, and it will be dated, so you can pin a firewall rule to something we have committed to in writing. We are not printing a range today because the service is not live and any range we invented now would be wrong by the time you read it.
The second is reverse DNS. Once the service is live, scanner addresses will resolve under scan.eazetech.co, and the forward lookup of that name will resolve back to the same address. A forward-confirmed reverse lookup is the check that actually settles it, the same way it does for the large search crawlers. Until we say on this page that it is running, please assume it is not.
So if you see traffic naming us that does not match the shape below, it is not us. Path guessing, POST bodies, admin panel probes, hundreds of requests a minute: none of that is ours, and we would like the log lines.
Exactly what we send
A complete scan is fewer than ten requests and is finished in a few seconds. Two connections at most are open at any moment. We follow redirects to a depth of five and then give up rather than chasing a loop. Responses are read to 3 MB and the connection is closed. We send Accept-Encoding: identity so there is nothing to decompress at either end, and if you answer with a Retry-After header we wait exactly as long as you asked, on a 429 or a 503 alike.
We never test for vulnerabilities. There are no injection payloads, no traversal strings, no oversized or malformed headers, no unusual methods and no deliberately broken requests. Every single request we send is one an ordinary browser could have sent, which is the point: the report describes what your server tells the public, so it can only be built from what the public is told.
Connections go to ports 80 and 443 and nowhere else, and only to hostnames. IP literals are rejected at submission, so we never end up pointed at an address whose owner cannot be identified.
the complete request set
- A handful of GET requests to the exact address that was submitted
- GET /robots.txt
- GET /.well-known/security.txt
- GET /sitemap.xml
- One OPTIONS request with an Origin header, to read the CORS response
- One TLS handshake per host, to read the certificate and negotiated protocol
What we never do
- Guess at paths, or work through a wordlist of any kind
- Ask for config files, environment files, database dumps or backups
- Scan ports, or touch anything other than 80 and 443
- Crawl beyond the submitted page, including into your sitemap
- Store response bodies once the headers have been read
- Log in, submit a form, or send anything that changes state on your server
The last one is worth expanding, because it is the one people ask about. Response bodies are parsed in memory for the few things a report needs, such as whether a page loads a script from a third-party origin, and are then discarded. We do not keep a copy of your HTML, and we could not hand one over if someone asked.
The sitemap is fetched to check that it exists and parses, not to get a list of things to visit next. Nothing in it is queued. The audit ends where the submitted page ends.
How to stop us
Publish a TXT record
Add _eazescan-optout.<yourdomain>. IN TXT "opt-out". We look it up before every scan and honour it within 24 hours of it going live.
Write to us
Mail security@eazetech.co from an address at the domain. We add it to the block list by hand, in most cases the same working day.
Block the user agent
Refuse it at your edge or return 403. We read a block as a permanent answer, record it, and do not come back looking for a way around it.
The DNS route is the one to use if you want it settled without talking to us. The record is a normal TXT record on the _eazescan-optout subdomain of the domain you want left alone:
We check it before every scan and honour it within 24 hours of the record going live, which allows for our own DNS caching. It covers the domain and everything under it. Delete the record and scans work again on the same 24-hour clock.
Now the trade-off, because opting out is not free. The record is public, so it is not only us who can read it. Anyone who runs an audit against your domain, including you and including people you would rather did not, is told that the domain has opted out instead of receiving a report. Some readers take that as a considered decision by a competent operator. Others take it as an invitation to look more closely by hand.
The second cost is quieter and usually matters more. Findings about your own site stop reaching you. An expiring certificate, a security header that vanished in a deploy, a redirect that started serving over plain HTTP: someone on your side who runs an audit gets nothing back. If what you object to is the traffic rather than the scanning, a rate limit and a Retry-After header will do the job without any of that, and we will behave.
Related pages
The audit terms and privacy notice set out what a person agrees to before running a scan, what we keep, and for how long. The tool itself is at /tools/website-security-audit, and there is nothing stopping you running it on your own site. How Eazetech handles client code and data on a paid engagement is a separate subject, covered on the security page.
Abuse and legal contact
Anything to do with the scanner goes to security@eazetech.co: traffic that names us and does not match this page, a scan you did not authorise, a request to delete a report about your domain, or an opt-out you would rather we handled by hand. A person reads that inbox and replies. We do not treat a complaint from an operator as an adversarial act, and we would rather hear about a suspicion than read about it later.
Formal notices go to Eazetech Ltd at hello@dearhearth.com, or by phone on +1 548 391 4050. If you need us to preserve logs for an investigation, say so in the first message, because our own scan records are deleted on a 30-day cycle and we cannot recover them afterwards.
what to include in a report
- Log lines with timestamps and the time zone they are in
- The source IP addresses you saw
- The full request lines, including the user agent as received
- The hostname that was hit, and whether you own it