Someone from 22 Security scanned you

Confirming it was us

Source addresses

Forward and reverse DNS agree on both:

dig +short -x 100.62.233.236                 # lagavulin.22security-scanner.com
dig +short lagavulin.22security-scanner.com  # 100.62.233.236

dig +short -x 52.2.108.65                    # talisker.22security-scanner.com
dig +short talisker.22security-scanner.com   # 52.2.108.65

The requests carry a User-Agent that says the same thing:

Mozilla/5.0 (compatible; 22security-scanner/1.0; +https://22security.com/scanning)

Traffic that claims to be us and fails those checks is not us, and we would like to hear about it.

Web checks

Headers, certificates, and server versions

For the hostnames under your domain that resolve, we request the homepage the same way a browser would and read what the server sends back. This is the bulk of the traffic you will see from us.

• What we read. The response headers, including the security headers a browser is told to honor, the server and platform version strings the server volunteers about itself, the TLS certificate and the protocol versions the listener accepts, and whether a content-management login is exposed to the internet. Where a version is disclosed we compare it against the vendor's own support lifecycle.
• One page, plus a few well-known paths. We fetch the homepage and a small number of standard, documented paths. We do not crawl, we do not follow links into the site, we do not submit forms, and we do not send anything a browser would not send on its first request. Every request carries the User-Agent above.
• Where it comes from. The automated pass originates from lagavulin.22security-scanner.com (100.62.233.236). When we validate a result by hand before contacting anyone, that comes from talisker.22security-scanner.com (52.2.108.65).

Service reachability

SSH, FTP, and other service ports

Alongside the web-layer checks above, we also check whether a small, fixed set of well-known service ports, like port 22 (SSH), port 21 (FTP), and port 990 (FTPS), is reachable from the open internet.

For each host and port we open one TCP connection to read the identification banner that the service sends on connect.

• Named ports, never a scan. We connect only to the specific service ports listed above, one connection each. We do not enumerate what else may be listening.
• We do not authenticate and we do not send credentials. We stop at the point where a credential would be the next thing on the wire. These services announce themselves the moment a connection opens: an SSH server sends its identification string (e.g. SSH-2.0-OpenSSH_8.9p1) before key exchange, and an FTP server sends its 220 greeting before any login. We read that line, understand what protocols and algorithms are used, and then disconnect.
• We identify ourselves where the protocol allows it. On SSH for example, our client announces itself as SSH-2.0-22security_scanner_1.0 +https://22security.com/scanning, so this page shows up in your logs. FTP has no client-identification banner, so there we send nothing at all. The connection simply originates from the address below.
• Why. A remote-access service like SSH that is open to the entire internet is an exposure normally kept behind a VPN or restricted to known source addresses. We note it the same way we note any other misconfiguration and do not test it for weaknesses.

This is the current set; if we add another well-known service port, it will be listed here. These checks originate from talisker.22security-scanner.com (52.2.108.65).

Mail authentication

SPF, DMARC, DKIM, and mail transport

We read the public DNS records that tell the world's mail servers who is allowed to send email as your domain, and whether mail to it travels encrypted. A domain that gets this wrong can be impersonated in phishing aimed at its own customers, and these records are published precisely so that they can be read.

• What we read. SPF, DMARC, and DKIM records, the MX records and whether they resolve, whether the zone is DNSSEC-signed, and the MTA-STS, TLS-RPT, and BIMI records if they exist. We check that each is present, well formed, and consistent with the others.
• It is DNS, not SMTP. The lookups go through the public resolvers run by Google and Cloudflare, so your nameservers see those resolvers rather than our addresses. We never connect to your mail servers: no SMTP session, no port 25, and no message sent or received.
• The one direct request. If your domain publishes an MTA-STS record, we fetch the policy file it advertises with a single HTTPS GET to https://mta-sts.<domain>/.well-known/mta-sts.txt, carrying the User-Agent above and originating from lagavulin.22security-scanner.com (100.62.233.236). That is the only mail check that reaches your infrastructure directly.

A record we could not read is reported as not assessed, never as passed.

How we conduct ourselves

Deliberately conservative compared to the industry

• Minimum necessary. Every check on this page was designed to be more conservative than the routine internet-wide measurement you already receive from services like Censys and Shodan and from academic research institutions. Some of those services publish specific results publicly. We do not: when we find something worth raising, we tell you directly, with the potential compliance implications of what we found and actionable recommendations.
• So much depends on reputation. We proactively monitor both source addresses on AbuseIPDB and other threat-intelligence and reputation services. We are fully transparent with these services about our processes and care deeply about being good security practitioners.
• Results stay with us. What we observe about your specific infrastructure is shared only with you and never sold to third-party services.
• Leaving is one email. If you would still rather not be included, email abuse@22security.com and we will remove your company from our scanning list and confirm the change within 2 business days. The removal covers every hostname under your domain and both source addresses.