DEV Community: Billy

How to Check SPF, DKIM, and DMARC Records in Python

Billy — Fri, 24 Jul 2026 21:42:16 +0000

If your app sends email — transactional or marketing — three DNS records decide whether it lands in the inbox or the spam folder: SPF, DKIM, and DMARC. Here's how to look them up and sanity-check them in Python, no third-party API required.

Install the one dependency:

pip install dnspython

SPF: who is allowed to send

SPF lives in a TXT record on the domain itself and starts with v=spf1.

import dns.resolver

def get_spf(domain):
    for rec in dns.resolver.resolve(domain, "TXT"):
        txt = b"".join(rec.strings).decode()
        if txt.startswith("v=spf1"):
            return txt
    return None

print(get_spf("github.com"))
# v=spf1 ip4:... include:_spf.google.com ~all

A quick gotcha worth checking: SPF allows at most 10 DNS-querying mechanisms (include, a, mx, ptr, exists, redirect). Go over and receivers return permerror, which quietly breaks authentication:

def spf_lookup_count(spf):
    return sum(spf.count(m) for m in ("include:", "a:", "mx:", "ptr", "exists:", "redirect="))

spf = get_spf("example.com")
if spf and spf_lookup_count(spf) > 10:
    print("⚠️ SPF exceeds the 10-lookup limit")

DMARC: the policy that ties it together

DMARC is a TXT record on the _dmarc. subdomain and starts with v=DMARC1.

def get_dmarc(domain):
    try:
        for rec in dns.resolver.resolve(f"_dmarc.{domain}", "TXT"):
            txt = b"".join(rec.strings).decode()
            if txt.startswith("v=DMARC1"):
                return dict(
                    kv.strip().split("=", 1)
                    for kv in txt.split(";") if "=" in kv
                )
    except dns.resolver.NXDOMAIN:
        return None

print(get_dmarc("github.com"))
# {'v': 'DMARC1', 'p': 'reject', 'rua': 'mailto:...'}

The key field is p: none (monitor only), quarantine (spam folder), or reject (bounce). If a domain sends real mail but has p=none, it's not protected against spoofing yet.

DKIM: the signature key

DKIM is trickier because you need the selector — a label chosen by the sender that lives at SELECTOR._domainkey.DOMAIN. There's no way to enumerate selectors from DNS, so you try common ones:

COMMON_SELECTORS = ["google", "default", "s1", "s2", "k1", "selector1", "selector2", "dkim"]

def find_dkim(domain):
    found = {}
    for sel in COMMON_SELECTORS:
        try:
            for rec in dns.resolver.resolve(f"{sel}._domainkey.{domain}", "TXT"):
                txt = b"".join(rec.strings).decode()
                if "v=DKIM1" in txt or "p=" in txt:
                    found[sel] = txt
        except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer):
            continue
    return found

print(find_dkim("github.com").keys())

If none of the common selectors resolve, the domain may use a custom one — you'll need to read it from an actual signed message's DKIM-Signature: header (s= tag).

Putting it together

def audit(domain):
    spf = get_spf(domain)
    dmarc = get_dmarc(domain)
    dkim = find_dkim(domain)
    print(f"{domain}")
    print(f"  SPF   : {'✓' if spf else '✗ missing'}")
    print(f"  DMARC : {dmarc.get('p') if dmarc else '✗ missing'}")
    print(f"  DKIM  : {', '.join(dkim) if dkim else '✗ none of the common selectors'}")

audit("your-domain.com")

Run that against your sending domain before you ship a campaign. Missing DKIM or a p=none DMARC are the two most common reasons legitimate mail gets filtered after Gmail and Yahoo tightened bulk-sender rules in 2024.

When you need this at scale

The snippets above are perfect for one domain in a script. If you're validating whole lists, warming a new sending domain, or want the checks plus blacklist and deliverability scoring in one pass, I built these into Bulko's free email tools — same logic, no code to run. But for a quick programmatic check, dnspython is all you need.

Rotating Residential Proxies in Python: requests, Scrapy & Sticky Sessions

Billy — Fri, 24 Jul 2026 21:42:06 +0000

When you scrape at any real volume, the bottleneck is rarely your code — it's the target site's rate limiting and IP bans. Rotating residential proxies solve this by routing each request through a different real-user IP. Here's how to wire them into requests and Scrapy in Python, including the sticky-session trick most tutorials skip.

The proxy URL format

A residential proxy is just an authenticated HTTP/SOCKS endpoint. With a pool gateway, you target a country and control session behavior through the username, not separate endpoints:

http://USERNAME_country-us_session-a1b2c3_lifetime-30:PASSWORD@proxy.gproxy.net:1000

country-us — exit country (ISO code)
session-a1b2c3 — a sticky-session id; reuse it to keep the same IP, change it to rotate
lifetime-30 — how many minutes that session's IP stays fixed

Basic request through a rotating proxy

import requests

USER = "USERNAME"
PWD = "PASSWORD"

def proxy(country="us", session=None, lifetime=30):
    tag = f"_country-{country}"
    if session:
        tag += f"_session-{session}_lifetime-{lifetime}"
    url = f"http://{USER}{tag}:{PWD}@proxy.gproxy.net:1000"
    return {"http": url, "https": url}

# New IP on every call (no session id):
r = requests.get("https://api.ipify.org?format=json", proxies=proxy(), timeout=30)
print(r.json()["ip"])

Run it in a loop and you'll see a different IP each time — the gateway rotates automatically when no session id is present.

Sticky sessions: keep one IP across requests

Some flows (login, multi-step checkouts, paginated results behind a cookie) break if your IP changes mid-session. Pin the IP by passing a stable session id:

import uuid

sess = uuid.uuid4().hex[:8]        # one id for the whole flow
p = proxy(country="de", session=sess, lifetime=30)

s = requests.Session()
s.proxies.update(p)
s.get("https://example.com/login")
s.post("https://example.com/login", data={...})   # same exit IP

When you want a fresh IP, generate a new session id.

Scrapy integration

Scrapy reads the proxy off each request's meta. A tiny middleware rotates a fresh session per request:

# middlewares.py
import uuid

class ResidentialProxyMiddleware:
    USER = "USERNAME"
    PWD = "PASSWORD"

    def process_request(self, request, spider):
        sess = uuid.uuid4().hex[:8]
        cc = request.meta.get("country", "us")
        request.meta["proxy"] = (
            f"http://{self.USER}_country-{cc}_session-{sess}_lifetime-10:"
            f"{self.PWD}@proxy.gproxy.net:1000"
        )

# settings.py
DOWNLOADER_MIDDLEWARES = {
    "myproject.middlewares.ResidentialProxyMiddleware": 350,
}

Set request.meta["country"] = "gb" in a spider to geo-target specific requests.

A few practical notes

Retry on proxy errors. Residential IPs occasionally drop; wrap requests with retries (urllib3 Retry, or Scrapy's RETRY_ENABLED) so a bad exit doesn't kill a job.
Respect the target. Rotating IPs is for spreading legitimate load and geo-testing — not for hammering a site past its terms. Add delays and honor robots.txt.
SOCKS5 works the same way on port 1002 if you need it (socks5://...).

Getting credentials

You need a residential pool that supports country targeting and sticky sessions. I use GProxy — the username-based targeting above is exactly its format, and it's usage-based ($0.90/GB) rather than a fixed monthly seat, which suits burst scraping jobs. Grab a key from the dashboard, drop it into USER/PWD, and the snippets above run as-is.

Happy (responsible) scraping.

Finding Network Device Info Programmatically: A Python Guide with ScanSearch

Billy — Mon, 20 Jul 2026 04:00:16 +0000

Ever needed to quickly check the exposure of a specific type of network device, or verify if a known vulnerability is present across your external-facing infrastructure? Manually probing IPs can be a tedious and time-consuming process. What if you could query the entire internet for devices, services, and even known vulnerabilities, all from a simple API call?

This article will walk you through using Python to programmatically query ScanSearch, an internet-wide search engine for network devices, services, and vulnerabilities. We'll focus on practical examples that demonstrate how to find specific device types, filter results, and extract useful information.

The Problem: Manual Network Reconnaissance is Slow

Imagine you're a security analyst, and a new vulnerability (CVE-2023-XXXX) has just been announced, affecting a specific version of a network-attached storage (NAS) device. Your immediate thought is: Are any of our external-facing devices vulnerable? And what about other organizations I'm responsible for monitoring?

Traditionally, you'd start with IP ranges, port scans, and banner grabbing – a process that's not only slow but also might miss devices outside your known ranges. This is where a tool like ScanSearch comes in handy, providing a fast way to query pre-indexed internet data.

Getting Started with ScanSearch

ScanSearch (https://scansearch.net) offers an API that allows you to perform these queries programmatically. While the specifics of API key acquisition aren't covered here, assume you have an API key ready for the following examples.

We'll use Python's requests library to interact with the ScanSearch API. First, let's set up our basic request structure.

import requests
import json

API_KEY = 'YOUR_SCANSEARCH_API_KEY' # Replace with your actual API key
BASE_URL = 'https://api.scansearch.net/v1/search'

def query_scansearch(query_string, page=1, limit=10):
    headers = {
        'Authorization': f'Bearer {API_KEY}',
        'Content-Type': 'application/json'
    }
    params = {
        'q': query_string,
        'page': page,
        'limit': limit
    }
    try:
        response = requests.get(BASE_URL, headers=headers, params=params)
        response.raise_for_status()  # Raise an exception for HTTP errors
        return response.json()
    except requests.exceptions.HTTPError as err:
        print(f"HTTP error occurred: {err}")
        print(f"Response body: {response.text}")
    except Exception as err:
        print(f"An error occurred: {err}")
    return None

This query_scansearch function takes a query_string, page, and limit and handles the API call, including basic error checking.

Example 1: Finding Specific Device Types

Let's say we want to find all publicly exposed instances of nginx web servers. The query_string for ScanSearch is quite powerful and supports various filters. A simple query for nginx will return services identified as such.

print("\n--- Searching for Nginx Servers ---")
nginx_results = query_scansearch('nginx')

if nginx_results and 'results' in nginx_results:
    print(f"Found {len(nginx_results['results'])} Nginx instances (first {len(nginx_results['results'])} results shown):")
    for i, result in enumerate(nginx_results['results'][:5]): # Print first 5 for brevity
        print(f"  {i+1}. IP: {result.get('ip')}, Port: {result.get('port')}, Banners: {result.get('banners', [])[0] if result.get('banners') else 'N/A'}")
        # You can inspect the full result object for more details
        # print(json.dumps(result, indent=2))
else:
    print("No Nginx results found or an error occurred.")

This code snippet sends a query for nginx and then iterates through the results, printing out the IP, port, and the first banner string found. ScanSearch's data includes a lot more, so feel free to inspect the result object more deeply.

Example 2: Filtering by Port and Service

What if you're interested in SSH services running on non-standard ports, say port 2222? ScanSearch allows combining search terms.

print("\n--- Searching for SSH on Port 2222 ---")
ssh_port_results = query_scansearch('service:ssh port:2222')

if ssh_port_results and 'results' in ssh_port_results:
    print(f"Found {len(ssh_port_results['results'])} SSH services on port 2222:")
    for i, result in enumerate(ssh_port_results['results'][:5]):
        print(f"  {i+1}. IP: {result.get('ip')}, Port: {result.get('port')}, Country: {result.get('location', {}).get('country_name')}")
else:
    print("No SSH on port 2222 results found or an error occurred.")

Here, service:ssh specifically targets services identified as SSH, and port:2222 narrows it down to that specific port. The results also contain geographical information under location.

Example 3: Searching for Vulnerabilities (CVEs)

ScanSearch also indexes known vulnerabilities. This is incredibly powerful for security auditing. Let's look for devices exposed to a hypothetical (or real, if you substitute a current one) CVE.

print("\n--- Searching for Devices with CVE-2021-44228 (Log4Shell) ---")
# Note: ScanSearch indexes vulnerabilities; results will show devices associated with them.
log4shell_results = query_scansearch('cve:CVE-2021-44228')

if log4shell_results and 'results' in log4shell_results:
    print(f"Found {len(log4shell_results['results'])} devices potentially affected by CVE-2021-44228:")
    for i, result in enumerate(log4shell_results['results'][:5]):
        print(f"  {i+1}. IP: {result.get('ip')}, Port: {result.get('port')}, Service: {result.get('service')}")
        # For vulnerability queries, you might want to inspect the 'vulnerabilities' key in the full result.
        # print(json.dumps(result.get('vulnerabilities', []), indent=2))
else:
    print("No CVE-2021-44228 results found or an error occurred.")

This example demonstrates how to query for a specific CVE ID. ScanSearch's data includes an association between identified services/devices and known vulnerabilities, which can be invaluable for threat hunting and patch validation.

Considerations and Best Practices

API Key Security: Never hardcode your API key directly into public repositories. Use environment variables or a secure configuration management system.
Rate Limiting: Be mindful of API rate limits. Implement delays or back-off strategies if you're making a large number of requests.
Result Paging: The page and limit parameters are crucial for fetching all results when your query returns more than the default limit. Implement a loop to fetch subsequent pages.
Data Structure: The exact structure of the results can vary slightly depending on the query. Always inspect the JSON response to understand the available fields.
Query Syntax: Familiarize yourself with ScanSearch's query syntax for more precise searches. This often includes field-specific searches (e.g., product:apache, os:linux).

Conclusion

Programmatically querying an internet-wide search engine like ScanSearch significantly speeds up network reconnaissance, security auditing, and threat intelligence gathering. By leveraging its API with a few lines of Python, developers and security professionals can quickly gain insights into internet-facing infrastructure, identify specific device types, services, and even potential vulnerabilities without resorting to slow, active scanning.

Explore the ScanSearch website (https://scansearch.net) to learn more about its capabilities and detailed query options.

Finding Exposed Services & Vulnerabilities: A Developer's Quick Guide with ScanSearch

Billy — Sun, 12 Jul 2026 04:00:14 +0000

Ever been in a situation where you need to quickly identify what services are exposed on a particular network range, or even across the internet? Maybe you're auditing your own infrastructure, or perhaps performing some ethical hacking. Traditional methods can involve port scanning specific IPs, which is fine for small scopes but quickly becomes impractical for broader reconnaissance.

This article will walk you through a practical approach to quickly discover network devices, their services, and even potential vulnerabilities using a powerful internet-wide search engine called ScanSearch. We'll focus on common developer use cases, showing you how to formulate queries to get actionable insights without running a single nmap command yourself.

The Problem: Blind Spots and Manual Scanning

Imagine you're responsible for securing a fleet of IoT devices. You've configured them, but how do you verify they aren't accidentally exposing a web interface or an SSH port to the public internet? Or perhaps you're developing a new service and want to see what similar services are exposing. Manually scanning vast IP ranges is time-consuming and often requires dedicated infrastructure.

This is where an internet-wide search engine comes in. Instead of actively scanning, it aggregates data from continuous scans, allowing you to query this massive dataset instantly.

Introducing ScanSearch: A Practical Tool

ScanSearch is essentially Google for network devices. It continuously scans the internet and indexes information about network devices, the services they run, and known vulnerabilities. This allows you to search for specific criteria, like devices running a particular version of Apache, or devices with an open RDP port.

Let's dive into some practical examples.

Use Case 1: Discovering Exposed Web Servers

Let's say you want to find all devices on the internet running an Apache web server on port 80. ScanSearch's query language is fairly intuitive.

You'd use a query like this:

service.name:apache AND port:80

This query tells ScanSearch to look for devices where the service name contains "apache" and the port is 80. The results would show you IP addresses, along with other details about the discovered service. This is incredibly useful for understanding the landscape of publicly accessible web servers.

Use Case 2: Identifying Devices with Specific Vulnerabilities

One of the most powerful features for developers and security professionals is the ability to search for devices with known vulnerabilities. ScanSearch indexes information about vulnerabilities associated with discovered services.

Let's say you're concerned about devices running services known to be vulnerable to a specific CVE (Common Vulnerabilities and Exposures) ID, for example, CVE-2021-44228 (Log4Shell).

While ScanSearch doesn't let you query by CVE ID directly in the current iteration, you can achieve similar results by searching for specific service versions or patterns often associated with that vulnerability. For instance, if Log4Shell primarily affected specific versions of Java applications exposing certain services, you could try to narrow it down.

For a more general approach to finding vulnerable services, you might search for a service known to have many common vulnerabilities, like certain versions of an older database or web server.

Let's try to find devices running an older, potentially vulnerable version of nginx.

service.name:nginx AND service.version:"1.14.0"

(Note: Always check the specific version information against public CVE databases like NVD to determine actual vulnerability status.)

This query helps you quickly pinpoint instances that might need immediate patching or further investigation. It's a great first step in a vulnerability management workflow.

Use Case 3: Finding Open RDP Ports for Auditing

Remote Desktop Protocol (RDP) is a common target for attackers, and accidentally exposing it to the internet is a significant security risk. You can quickly check for publicly exposed RDP services.

port:3389 AND protocol:rdp

This simple query will list all devices with an open RDP port (3389). If you manage a large network, running this query periodically can act as a quick check against misconfigurations.

Tips for Effective Querying

Be Specific: The more specific your query, the more relevant your results will be. Use AND and OR operators to combine terms.
Explore Fields: ScanSearch offers various fields you can query, such as ip, port, service.name, service.version, protocol, etc. Experiment with these to narrow down your searches.
Regular Checks: For ongoing security, integrate ScanSearch queries into your regular audit routine. It's a fantastic way to passively monitor your public-facing assets.

Beyond the Basics

While we've only scratched the surface, ScanSearch's capabilities extend to discovering a wide array of network services, like databases (MongoDB, MySQL), industrial control systems (SCADA), and various IoT devices. The key is to understand what you're looking for and formulate your query accordingly.

For more detailed query syntax and available fields, I recommend checking out the ScanSearch website directly.

Conclusion

ScanSearch offers a powerful and efficient way for developers, system administrators, and security professionals to gain insights into the internet's observable attack surface. By leveraging its internet-wide scanning data, you can quickly identify exposed services, pinpoint potential vulnerabilities, and audit your own infrastructure without the need for active scanning. It's a valuable tool in any developer's security toolkit for proactive defense and reconnaissance.

Catch expiring TLS certs and weak security headers in CI — with one small CLI

Billy — Wed, 08 Jul 2026 22:29:05 +0000

Your CI proves the app builds, the tests pass, and maybe that there are no known-vulnerable dependencies. Then it ships — behind a TLS certificate that will quietly expire in three weeks, serving responses with a security-headers grade of F.

Nobody notices until a browser does.

These two failure modes — an expiring certificate and weak HTTP security headers — are cheap to check and easy to forget. Here's a small, dependency-light CLI that checks them (plus DNS posture and subdomains) from your terminal, and a one-line GitHub Action that fails the build before your users find out.

Install

pip install "secably[dns]"

The core checks have zero dependencies; the optional [dns] extra pulls in dnspython for SPF/DMARC/DNSSEC. Everything runs locally — nothing about your domain is sent to a third party.

Check a TLS certificate

secably ssl example.com

TLS — github.com:443
--------------------
  Subject          github.com
  Issuer           Sectigo Public Server Authentication CA DV E36
  Valid until      2026-09-30T23:59:59+00:00  (84 days left)
  Protocol         TLSv1.3
  Cipher           TLS_AES_128_GCM_SHA256
  Trusted          yes
  SAN              github.com, www.github.com

It completes the handshake, reads the leaf certificate, and reports the issuer, validity window, days remaining and negotiated protocol. It also flags the things you actually care about: an expired or not-yet-valid certificate, a chain that doesn't verify, or a server still negotiating an obsolete protocol like TLS 1.0.

One implementation detail worth knowing if you build something similar: ssl.getpeercert() returns an empty dict unless the certificate verifies, so you can't use it to inspect an already-expired or self-signed cert — exactly the case you want to catch. The trick is to pull the certificate in DER form with getpeercert(binary_form=True) and decode that instead, then run verification separately just to set a "trusted" flag.

The CI-friendly part is the exit code:

secably ssl example.com --fail-if-expires 21

Exits non-zero if the certificate expires within 21 days. Drop it in a scheduled job and you get weeks of warning instead of an incident.

Grade your security headers

secably headers https://example.com

Security headers — https://example.com
--------------------------------------
  Grade: A  (90/100, HTTP 200)
  Present:
  • strict-transport-security
  • content-security-policy
  • x-frame-options
  • x-content-type-options
  • referrer-policy
  Missing:
  ✗ permissions-policy — Set a Permissions-Policy to restrict powerful browser features.
  Info leaks:
  ! server: nginx

It scores the response A–F across the six headers that matter most — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy — and calls out headers that leak your stack, like a verbose Server or X-Powered-By.

Same CI story:

secably headers https://example.com --fail-below B

Fails the build if the grade drops below B.

Bonus: DNS posture and subdomains

Two more checks that are handy for recon and hygiene:

secably dns example.com          # A/AAAA/MX/NS/TXT + SPF / DMARC / DNSSEC
secably subdomains example.com   # passive discovery via Certificate Transparency

dns tells you whether your domain can be spoofed (no SPF, no DMARC, no DNSSEC — the CLI warns on each). subdomains queries public Certificate Transparency logs — every name a CA has ever issued a certificate for — so there's no brute force and no traffic to the target. Add --resolve to get IPs, and --json to any command for a machine-readable object you can pipe into jq.

Put it in CI

You can wire the CLI into any pipeline, but on GitHub there's a ready-made action so you don't have to script the exit-code handling yourself:

name: Security check
on:
  schedule:
    - cron: '0 6 * * *'   # every morning
  workflow_dispatch:

jobs:
  secably:
    runs-on: ubuntu-latest
    steps:
      - uses: Secably/secably-security-check@v1
        with:
          url: your-domain.com
          fail-if-expires: 21
          headers-min-grade: B

That's the whole thing. The job runs entirely inside your runner, prints a job summary, and turns red — with a GitHub error annotation — the moment the certificate is close to expiry or the headers slip below your bar. Running it on a daily cron (not just on push) is the point: certificates expire on the calendar, not on your commits.

Where it runs

To be upfront about it: ssl, headers, dns and subdomains all run on your machine with no account and no rate limit. There's also a secably scan command for a deeper server-side website/port scan, which uses a free API key — but the four checks above need nothing.

A CI run is a snapshot at deploy time, though. Certificates still expire, new subdomains still appear, and ports still open up between deploys. If you want these same checks running continuously with alerts, that's what the hosted side at Secably does — but the CLI and the Action are open source and stand on their own.

CLI: github.com/Secably/secably-cli
Action: github.com/Secably/secably-security-check

If you add it to a pipeline, I'd genuinely like to hear which check caught something first — mine was an expiring cert on a staging box nobody was watching.

The Cheapest Dedicated Servers in 2026: A Price-Checked Shortlist

Billy — Mon, 06 Jul 2026 11:28:16 +0000

If you have ever tried to price a bare-metal server, you know the game: a big "from $X/mo" on the landing page, then the actually-orderable configs cost two or three times that, half of them are out of stock, and the cheap one ships "in 3–5 business days." This is a price-checked shortlist of where to rent a genuinely cheap dedicated server in 2026 — who each provider is for, roughly where pricing starts, and the catch.

I pulled the numbers for the last entry from a live, daily-refreshed dataset (linked at the bottom) so you can verify them instead of trusting a screenshot.

What "cheap" should actually mean

Before the list, four things that separate a real deal from bait:

The price you see is the price you pay. Watch for setup/install fees and "from" pricing that no in-stock config matches.
In stock now, not "provisioning in 5 days." A $16 box you can't deploy today isn't a $16 box.
Bandwidth and traffic caps. Unmetered 1 Gbps and a 30 TB cap are very different economics.
Location. A server two continents from your users is cheap and useless.

The shortlist

1. Kimsufi (OVH budget brand) — legacy boxes, rock-bottom

OVH's budget label recycles older Atom/Xeon hardware at the lowest headline prices in the market. Great for a cheap always-on box, a seedbox, or a lab. Catch: stock is famously thin, hardware is old, and support is minimal.

2. Scaleway Dedibox — cheap French metal

Long-running budget bare-metal out of Paris/Amsterdam, entry configs among the cheapest in the EU. Good if you specifically want France/NL and Scaleway's ecosystem. Catch: entry SKUs sell out and the cheapest tiers use aging CPUs.

3. Hetzner (server auction) — best price/performance in the EU

Not the lowest sticker, but the auction floor gets you modern Ryzen/EPYC with lots of RAM for what budget hosts charge for an Atom. The default answer for "cheap and fast" in Germany/Finland. Catch: auction inventory rotates, and it's EU-only locations.

4. Contabo — cheap high-spec, oversubscribed

Known for a lot of cores/RAM/disk per dollar. Fine for storage or batch workloads where you don't need guaranteed peak performance. Catch: reputation for oversubscription and variable I/O; read recent reviews for your region.

5. Leaseweb / enterprise carriers — not cheap, but predictable

When uptime SLAs and DDoS protection matter more than the invoice, the enterprise carriers start higher but deliver consistency. Catch: you'll pay for it, and it's overkill for a hobby box.

6. Valebyte — cheap and in-stock across 20 countries

Aggregates in-stock bare-metal across a wide provider network, so the differentiator is breadth + honesty: ~800 servers deployable now across 20 countries, prices are final (no "from $X" bait), and the whole catalog is published as a machine-readable dataset. Entry is $16/mo (Atom-class in France/NL), with modern Ryzen from ~$72 and EPYC from ~$160. Catch: it's an aggregator, so the cheapest tiers are still older CPUs — same as everyone else at $16.

Cheapest by region (live figures)

Where the boxes actually are and what the cheapest one costs, at the time of writing:

Region	In stock	Cheapest
France	241	$16/mo
Netherlands	120	$16/mo
Germany	87	$59/mo
United States	80	$41/mo
Poland	63	$54/mo
Singapore	29	$42/mo
Canada	28	$40/mo
Australia	18	$40/mo

France and the Netherlands are where the floor is; if you don't need a specific country, that's where the cheapest usable metal lives in 2026.

How to actually verify prices

The single most useful habit: check a machine-readable price list instead of marketing pages. The regional numbers above come from an open dataset that refreshes daily — dedicated-server-prices on GitHub — with CSV/JSON of specs, location, monthly price and order URL for every in-stock server. Clone it, sort by price, done. No "from $X," no stale screenshots.

Bottom line

Lowest sticker, don't care about hardware age → Kimsufi / Scaleway Dedibox.
Cheap and fast in the EU → Hetzner auction.
Lots of cores/RAM per dollar → Contabo.
SLA and DDoS matter more than price → Leaseweb.
Cheap, in-stock now, specific country → Valebyte.

Whatever you pick, sort by in-stock final price in your region — not the number on the hero banner.

Bypassing Telegram Blocks: How MTProto FakeTLS Proxies Actually Work

Billy — Sat, 04 Jul 2026 12:48:41 +0000

When an ISP or national firewall throttles or blocks Telegram, the usual advice is "use a VPN." But there's a lighter, Telegram-specific tool that is often more resilient and far simpler for end users: the MTProto proxy with FakeTLS.

DPI vs. Telegram

Deep Packet Inspection classifies traffic by its protocol fingerprint. A plain MTProto stream or a naive proxy is easy to spot and drop. The trick is to make the connection look like something completely ordinary.

How FakeTLS works

MTProto is Telegram's own transport protocol. FakeTLS wraps it so the wire looks like a normal TLS 1.3 handshake to a real website:

The client sends a TLS ClientHello with the SNI of a popular domain (e.g. www.microsoft.com).
Authentication is a per-user secret verified via an HMAC computed over the ClientHello (with the 32-byte random field acting as the digest).
If the HMAC is invalid (a censor's active probe), the proxy transparently proxies the prober to the real fronting domain — so an attacker who pokes the port just gets Microsoft's real certificate back.

To a censor, a real client's flow is indistinguishable from an HTTPS visit to that domain. That's what keeps it working where generic proxies are already blocked.

A failure mode nobody documents: clock skew

Here's a real-world gotcha we hit in production. FakeTLS embeds a timestamp for anti-replay. If the proxy host's clock drifts more than a couple of minutes, every legitimate client handshake is rejected:

invalid faketls client hello: incorrect timestamp. got=..., now=..., diff=2m54s

The nasty part: the proxy still accepts TCP, still answers TLS, still passes an openssl s_client masquerade check — it looks perfectly alive. It just silently falls back to domain-fronting instead of relaying, so every user on that host is broken at once. The fix is boring but essential: run NTP (chrony) on every proxy host. We shipped a box without it and spent an afternoon chasing "the proxy is down" tickets that were really a 3-minute clock drift.

MTProto proxy vs VPN

	MTProto proxy	VPN
Scope	Telegram only	whole device
Setup	one tap on a link	install + configure
Detectability	masked as TLS	often fingerprinted
Battery/speed	negligible / fast	heavier

For unblocking Telegram specifically, MTProto is usually the better tool.

Try it

Notes + setup (open): https://github.com/blureshot/free-telegram-proxy
A free, working MTProto proxy (24h, no signup, one-tap): https://t.me/NotifyGproxyBot?start=devto

Full disclosure: that bot is the free tier of a proxy service I work on (GProxy). But the mechanics above are protocol-level and vendor-neutral — any FakeTLS MTProto proxy (mtg, mtprotoproxy) works the same way, and the clock-skew lesson applies to all of them.

Need production-grade rotating & residential proxies with real uptime? Try *gproxy.net*.

A free proxy list that's actually checked (HTTP/SOCKS4/SOCKS5, updated every 30 min)

Billy — Sat, 04 Jul 2026 10:38:33 +0000

Every "free proxy list" you find is the same story: a giant wall of ip:port lines, 90% of them already dead, no idea which are HTTP or SOCKS, no idea where they exit. You paste 500 into your scraper and three of them work.

So I put up a small one that's actually checked: gproxynet/free-proxy-list. A checker validates each proxy, tags it with protocol, country and latency, and the repo is regenerated every 30 minutes. It's a rotating sample, not a 50k dump — the point is that what's in it was alive minutes ago, not last month.

Grab it

Plain text, one ip:port per line, split by protocol:

curl -s https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/all.txt
curl -s https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/socks5.txt

Or the structured version with protocol, country and latency:

curl -s https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/proxies.json

[
  {"proxy":"103.156.224.66:8080","protocol":"http","country":"ID","latency_ms":4225,"checked_at":"2026-07-04T09:34:16Z"},
  {"proxy":"185.26.180.180:80","protocol":"http","country":"NL","latency_ms":340,"checked_at":"2026-07-04T09:41:02Z"}
]

Use it in Python

Filter to the protocol and speed you want:

import requests

proxies = requests.get(
    "https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/proxies.json"
).json()

fast_socks5 = [
    p["proxy"] for p in proxies
    if p["protocol"] == "socks5" and (p["latency_ms"] or 9999) < 2000
]
print(len(fast_socks5), "fast SOCKS5 proxies")

If you're rotating them across a scraper, feed the list straight into a pool. I use proxyspin (a small rotating pool with health tracking + ban detection), which can load a URL directly:

from proxyspin import ProxyPool
from proxyspin.requests_adapter import RotatingSession

pool = ProxyPool.from_url("https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/all.txt")
session = RotatingSession(pool)          # dead ones get benched automatically
print(session.get("https://httpbin.org/ip").json())

The honest part

These are public proxies. They're shared by strangers, they're slow, they die within minutes to hours, and you should never send anything sensitive through them. A checked list saves you the "which of these 500 is alive" step — it does not make public proxies reliable. They're great for testing, learning, one-off checks and throwaway requests.

The moment you need proxies that stay up — real scraping, account work, ad verification — you'll want dedicated ones (residential, mobile or datacenter) instead of public ones. But if a free, checked, auto-updating list is what you need today, it's there:

➡️ github.com/gproxynet/free-proxy-list

Bookmark the raw URL, poll it every so often, and you've always got a fresh handful to work with.

Need production-grade rotating & residential proxies with real uptime? Try *gproxy.net*.

Rotating proxies for Scrapy, Playwright and requests — one small library

Billy — Sat, 04 Jul 2026 10:28:29 +0000

If you scrape anything at scale, you know the drill: proxies die, sites start returning 403/429, and your run grinds to a halt. The classic Scrapy answer, scrapy-rotating-proxies, hasn't seen a real update in years — and it's Scrapy-only, so the moment you reach for Playwright or plain requests, you're rebuilding rotation from scratch.

I wanted one small proxy pool I could share across all three. So I wrote proxyspin: a rotating pool with health tracking, ban detection and sticky sessions, and thin adapters for Scrapy, Playwright and requests. Zero required dependencies, pure standard library.

pip install proxyspin

The pool

Everything is built around one object. Load proxies from a list, a file, or a URL:

from proxyspin import ProxyPool

pool = ProxyPool.from_file("proxies.txt", strategy="round_robin")
# or inline / from your provider's export endpoint:
pool = ProxyPool(["http://user:pass@gate1.example.com:8000", "10.0.0.2:8000"])
pool = ProxyPool.from_url("https://example.com/api/my-list.txt")

proxy = pool.get()        # -> Proxy; proxy.url is ready to use
pool.mark_failed(proxy)   # bench it after repeated failures
pool.mark_ok(proxy)       # reset its failure streak

It parses every common list format — host:port, host:port:user:pass, user:pass@host:port, scheme://user:pass@host:port — for HTTP, HTTPS, SOCKS4 and SOCKS5.

Rotation strategies

round_robin — cycle through healthy proxies in order (default)
random — pick one at random
sticky — keep returning the same proxy for a given key (a target domain, an account id, a worker name) until it goes unhealthy

The health model

Every proxy starts healthy. mark_failed bumps its failure streak; when the streak hits max_failures (default 2) the proxy is benched with exponential backoff (cooldown * 2**overshoot, base 60s, capped at 1h), then automatically rejoins rotation. mark_ok resets the streak. So dead proxies quietly drop out and recover on their own — you never manually prune the list.

Scrapy

Enable the middleware and point it at your proxies. Ban detection and retry-through-the-next-proxy are automatic:

# settings.py
DOWNLOADER_MIDDLEWARES = {
    "proxyspin.scrapy_middleware.ProxySpinMiddleware": 610,
}
PROXYSPIN_FILE = "proxies.txt"
PROXYSPIN_STRATEGY = "sticky"       # one proxy per target host
PROXYSPIN_BAN_CODES = [403, 429]    # these responses rotate the proxy
PROXYSPIN_MAX_RETRIES = 3

Any 403/429 (configurable) marks the proxy as failed and retries the request through the next healthy one. No spider code changes.

Playwright

Playwright takes a proxy per browser context, which is the natural rotation unit — great for one-IP-per-account flows:

from playwright.sync_api import sync_playwright
from proxyspin import ProxyPool
from proxyspin.playwright_helper import proxy_settings

pool = ProxyPool.from_file("proxies.txt", strategy="sticky")

with sync_playwright() as p:
    browser = p.chromium.launch()
    for account in accounts:
        context = browser.new_context(proxy=proxy_settings(pool, key=account.id))
        # each account keeps its own IP for the whole session

requests

A drop-in Session that rotates on every call and retries failures through another proxy:

from proxyspin import ProxyPool
from proxyspin.requests_adapter import RotatingSession

session = RotatingSession(ProxyPool.from_file("proxies.txt"))
print(session.get("https://httpbin.org/ip").json())   # new IP per call

Check a list first

Bad proxies waste run time. The bundled CLI tests a whole list concurrently and writes out the survivors:

proxyspin check proxies.txt --workers 100 --alive-out alive.txt

OK   45.155.10.4:8000        612 ms  HTTP 200
DEAD 91.10.77.2:3128                 TimeoutError
...
118/200 alive
wrote 118 proxies to alive.txt

Getting proxies to test with

Want to try it right now without your own proxies? Bootstrap straight from a live public list:

pool = ProxyPool.from_url("https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/all.txt")

Fair warning: public proxies are unreliable by nature — they're shared, slow, and die within minutes. They're fine for kicking the tires, not for a real crawl. For production you'll want dedicated proxies (residential/mobile/datacenter); a pool of one gateway entry per endpoint is all proxyspin needs since rotation happens server-side.

Wrapping up

One pool, the same health model everywhere, and you stop babysitting dead proxies. The code is MIT-licensed and on GitHub — issues and PRs welcome. If you've been limping along on an unmaintained rotation middleware, give it a spin.

Need production-grade rotating & residential proxies with real uptime? Try *gproxy.net*.

Finding Exposed Services (and Fixing Them) with ScanSearch and Python

Billy — Sat, 04 Jul 2026 04:00:19 +0000

Ever wondered what parts of your infrastructure are inadvertently exposed to the internet? Or maybe you're trying to debug a network service that just isn't behaving as expected, and you suspect a firewall issue or misconfiguration somewhere upstream. Manually scanning IP ranges can be tedious and slow, especially if you're dealing with a dynamic environment.

This article will walk you through a practical approach to quickly identify internet-facing services and potential vulnerabilities using ScanSearch, an internet-wide search engine for network devices and services, combined with a bit of Python to automate and interpret the results. The goal isn't to hack anything, but to gain insight into your own network's perimeter and improve its security posture.

The Problem: What's Visible?

It's surprisingly easy to accidentally expose services that shouldn't be public. A developer might spin up a test database, forget to configure its firewall rules, and suddenly it's reachable from anywhere. Or a misconfigured router might forward ports intended for internal use. These oversights create attack vectors that bad actors actively scan for.

Instead of waiting for a security incident, let's proactively find what's visible.

Introducing ScanSearch

ScanSearch is a powerful tool for discovering network devices, services, and even vulnerabilities across the internet. Think of it like Google, but for network ports and banners. You can query it for specific port numbers, service banners, protocols, and more.

For instance, if you want to find all devices exposing port 22 (SSH), you can simply search for port:22 on their website. The real power, however, comes from combining these queries and using their API for programmatic access.

Scenario: Finding Unexpected SSH Exposure

Let's say you manage a set of servers and want to ensure that only specific, hardened SSH servers are exposed to the public internet. You want to quickly check if any other devices within your known IP ranges are also inadvertently exposing SSH.

We'll use ScanSearch to query for devices running SSH on port 22, filtered by a specific IP range (e.g., your organization's public IP block). For this example, let's assume your organization uses the fictional IP range 192.0.2.0/24.

Step 1: Manual Query (for exploration)

Before diving into code, it's often helpful to test your query directly on the ScanSearch website. Go to the site and try searching for:

port:22 ip:192.0.2.0/24

This query tells ScanSearch to look for devices with port 22 open and that fall within the 192.0.2.0/24 IP range. You'll get a list of results, each showing the IP, port, and often a service banner (e.g., SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3).

Step 2: Automating with Python

Manually checking results is fine for a one-off, but for regular auditing or more complex analysis, an API is essential. ScanSearch offers an API that allows you to programmatically submit queries and retrieve results. (Note: You'll typically need an API key for programmatic access beyond basic public queries. Refer to the ScanSearch documentation for details on API usage and authentication).

Here's a simple Python script to query ScanSearch for exposed SSH services within our example IP range and print the results.

import requests
import json

# Replace with your actual ScanSearch API endpoint and API key
# For simplicity, we'll use a placeholder URL here. 
# Check ScanSearch documentation for the correct API endpoint and authentication.
SCANSEARCH_API_URL = "https://api.scansearch.net/v1/search" 
# SCANSEARCH_API_KEY = "YOUR_API_KEY_HERE" # Uncomment and set if required by API

def search_scansearch(query, ip_range):
    full_query = f"port:22 {query} ip:{ip_range}"
    print(f"Executing ScanSearch query: {full_query}")

    headers = {
        "Content-Type": "application/json",
        # "Authorization": f"Bearer {SCANSEARCH_API_KEY}" # Uncomment if using API key
    }

    payload = {
        "query": full_query,
        "limit": 100 # Adjust limit as needed, check API docs for max
    }

    try:
        response = requests.post(SCANSEARCH_API_URL, headers=headers, data=json.dumps(payload))
        response.raise_for_status() # Raise an exception for HTTP errors

        results = response.json()
        return results
    except requests.exceptions.RequestException as e:
        print(f"Error querying ScanSearch API: {e}")
        return None

if __name__ == "__main__":
    target_ip_range = "192.0.2.0/24" # Replace with your actual public IP range

    # We're specifically looking for SSH on port 22, so the initial query is simple.
    # You could expand this to include specific SSH versions, e.g., 'ssh-2.0-openssh'
    query_string = ""

    search_results = search_scansearch(query_string, target_ip_range)

    if search_results and search_results.get("data"):
        print(f"\nFound {len(search_results['data'])} potential SSH exposures in {target_ip_range}:\n")
        for result in search_results['data']:
            ip = result.get("ip")
            port = result.get("port")
            service_banner = result.get("banner", "N/A")

            print(f"  IP: {ip}, Port: {port}, Banner: {service_banner}")

        # Further analysis: Check if these IPs are expected or unexpected
        # For example, maintain a whitelist of allowed SSH servers.
        expected_ssh_servers = ["192.0.2.10", "192.0.2.20"]
        print("\n--- Analysis ---")
        for result in search_results['data']:
            ip = result.get("ip")
            if ip not in expected_ssh_servers:
                print(f"  WARNING: Unexpected SSH exposure on {ip} (Port: {result.get('port')}, Banner: {result.get('banner', 'N/A')})")
            else:
                print(f"  INFO: Expected SSH server on {ip}")
    elif search_results:
        print(f"No SSH services found in {target_ip_range}.")
    else:
        print("Failed to retrieve ScanSearch results.")

Important Notes:

API Key: The example above shows placeholders. You will need to refer to the ScanSearch API documentation for the correct API endpoint, authentication methods (likely involving an API key), and usage limits. Set SCANSEARCH_API_KEY and uncomment the Authorization header if required.
IP Range: Replace 192.0.2.0/24 with your actual public IP address range or a specific IP address you want to monitor.
Error Handling: The script includes basic error handling for API requests. In a production scenario, you'd want more robust logging and error management.
Rate Limiting: Be mindful of API rate limits. The limit parameter helps control the number of results per query.

Interpreting Results and Taking Action

Once you run the script, you'll get a list of IPs within your specified range that have port 22 open. Your next steps depend on what you find:

Expected Services: If an IP shows up and you know it's a legitimate, hardened SSH server, that's great. Document it as part of your known infrastructure.
Unexpected Services: If an IP appears that you don't expect to have SSH exposed, this is a critical finding. Investigate immediately:
- Identify the machine: What server or device owns that IP? Who is responsible for it?
- Determine the cause: Is it a misconfigured firewall? An old test server that was never decommissioned? A rogue service?
- Remediate: Close the port, restrict access to specific trusted IPs, or remove the service if it's not needed. Ensure proper security configurations are in place (e.g., key-based authentication, disabled root login, up-to-date SSH daemon).

Beyond SSH: Finding Other Vulnerabilities

The power of ScanSearch isn't limited to just SSH. You can adapt the query_string to find a multitude of other potentially risky exposures:

Databases: port:3306 (MySQL), port:5432 (PostgreSQL), port:27017 (MongoDB) – often found with default credentials or no authentication.
Web Servers: port:80 (HTTP), port:443 (HTTPS) – look for unexpected admin panels or outdated server versions (server:nginx/1.10.3).
Remote Desktops: port:3389 (RDP) – a common target for brute-force attacks.
IoT Devices: Look for default credentials or known vulnerable device types.
Unsecured Storage: port:445 (SMB) or port:21 (FTP) with anonymous access.

By regularly scanning your external footprint with ScanSearch, you can proactively identify and mitigate risks before they become security incidents. It's a fundamental step in maintaining a robust security posture for any internet-connected infrastructure.

Stop Guessing What’s Public: Automating Attack Surface Discovery

Billy — Wed, 24 Jun 2026 04:00:19 +0000

The "Forgotten Server" Problem

Every developer has been there. You spin up a temporary staging instance to test a deployment script, or you launch a quick Redis container to debug a caching issue. You intend to tear it down in an hour, but then a Slack notification hits, a meeting starts, and that instance stays live.

Six months later, that "temporary" server is an unpatched entry point into your infrastructure.

You can't secure what you don't know exists. While internal asset trackers are great, they often miss what the outside world can actually see. This is where internet-wide search engines come in.

In this guide, we’ll look at how to use ScanSearch to programmatically audit your public-facing infrastructure and identify services you might have forgotten were exposed.

What is ScanSearch?

ScanSearch is an internet-wide search engine designed to index network devices, services, and vulnerabilities across the entire IPv4 space. Think of it as a specialized crawler that doesn't look for web content, but for open ports, SSL certificates, service banners, and misconfigurations.

For a developer or DevOps engineer, it’s a tool for External Attack Surface Management (EASM). Instead of manually running nmap against your IP ranges (which is slow and can be blocked), you query a pre-indexed database of the entire internet.

The Goal: Finding Exposed Databases

Let’s build a practical Python script. We want to find any instances associated with a specific organization or IP range that are running services they shouldn't be—specifically, we'll look for exposed database ports (like MongoDB on 27017 or Redis on 6379) that might be leaking data.

Prerequisites

To follow along, you'll need:

Python 3.x installed.
The requests library.
Access to the ScanSearch platform to retrieve your API credentials.

Writing the Audit Script

We’ll write a script that queries the ScanSearch API for a specific network range and flags any service that isn't on our "allowlist" (like 80 or 443).

import requests
import json

# Configuration
API_KEY = "YOUR_SCANSEARCH_API_KEY"
BASE_URL = "https://scansearch.net/api/v1" # Hypothetical API endpoint
TARGET_NET = "192.168.1.0/24"  # Replace with your actual public CIDR
ALLOWED_PORTS = [80, 443]

def fetch_exposed_services(net_range):
    """
    Queries ScanSearch for all indexed services in a specific CIDR.
    """
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    }

    # We search for the net range using the 'net' filter
    query = f"net:{net_range}"

    try:
        response = requests.get(
            f"{BASE_URL}/search",
            params={"q": query},
            headers=headers
        )
        response.raise_for_status()
        return response.json().get('results', [])
    except Exception as e:
        print(f"Error fetching data: {e}")
        return []

def audit_infrastructure():
    print(f"--- Starting Audit for {TARGET_NET} ---")
    results = fetch_exposed_services(TARGET_NET)

    flagged_count = 0

    for entry in results:
        ip = entry.get('ip')
        port = entry.get('port')
        service = entry.get('service', 'Unknown')

        if port not in ALLOWED_PORTS:
            print(f"[!] ALERT: Unexpected service found!")
            print(f"    IP: {ip}")
            print(f"    Port: {port}")
            print(f"    Service: {service}")
            print(f"    Banner: {entry.get('banner', 'N/A')[:50]}...")
            flagged_count += 1

    if flagged_count == 0:
        print("No unexpected services found. Infrastructure looks clean.")
    else:
        print(f"Audit complete. {flagged_count} issues found.")

if __name__ == "__main__":
    audit_infrastructure()

Why This Matters

When you run the script above, ScanSearch doesn't just tell you a port is open; it gives you the banner data. If you have an Nginx server running, it will tell you the version. If you have an expired SSL certificate, it will flag it.

Common things to look for in your results:

Old Headers: Are you still running X-Powered-By: PHP/5.4? That’s a signal to attackers.
Dev Endpoints: Finding /swagger-ui.html or /_ast (Airflow) exposed to the public internet is a major risk.
Vulnerabilities: ScanSearch indexes known vulnerabilities associated with specific service versions. You can refine your search to net:1.2.3.4/24 has_vulnerability:true to prioritize your patching schedule.

Beyond Simple Port Scanning

One of the most powerful ways to use ScanSearch is to find "shadow" assets that aren't even in your known IP range. You can search by organization name or SSL certificate common names.

For example, searching for ssl.cert.subject.cn:"*.yourcompany.com" might reveal a marketing microsite hosted on a random VPS that your security team never knew existed. These are often the weakest links because they fall outside your standard patch management cycle.

Integrating into your Workflow

Security shouldn't be a one-time event. You can take the script above and:

Run it as a Cron Job: Get a weekly report of any new ports that appeared on your infrastructure.
CI/CD Integration: Add a step in your deployment pipeline to verify that a newly deployed service is visible (or invisible) as expected.
Slack Alerts: Instead of printing to the console, send a webhook to your team's security channel whenever a high-risk port (like 3389 for RDP or 22 for SSH) is detected on a production IP.

Conclusion

Visibility is the foundation of security. Tools like ScanSearch provide a "hacker's eye view" of your infrastructure, allowing you to find and fix holes before someone else does. By automating these checks, you move from reactive firefighting to a proactive security posture.

Next time you spin up a "temporary" instance, you'll know exactly when you've forgotten to turn it off.

On-demand internet scanning in Python: scan any IP, CIDR, or country with ScanSearch

Billy — Tue, 16 Jun 2026 08:05:30 +0000

Search engines like Shodan and Censys are great, but they show you an index — data collected on their schedule, which can be hours, days, or weeks old. Sometimes you don't want the last snapshot. You want to know what's open right now.

That's the gap ScanSearch fills: instead of querying a pre-built index, you trigger a real SYN + service-detection scan of a target through a REST API and get current results back in seconds. Here's how to drive it from Python.

Install

The SDK is open source (MIT). Until the PyPI release it installs straight from GitHub:

pip install git+https://github.com/ScanSearch/scansearch-python.git

Grab an API key from your dashboard at https://scansearch.net/dashboard/api-keys/ and export it — the client picks it up automatically:

export SCANSEARCH_API_KEY="your-key"

The free tier scans at 2 kpps, which is plenty to follow along.

Scan a CIDR and wait for the result

from scansearch import Client

api = Client()  # reads SCANSEARCH_API_KEY from the environment

job = api.scan(
    targets=["192.0.2.0/24"],
    ports="80,443,8080,8443",
    modules=["ports", "services"],
)

result = api.scan_wait(job["task_id"])
print(f"open ports: {result['open_ports_found']}")
print(f"services:   {result['services_found']}")

modules=["ports", "services"] means you get open ports plus service identification — banners, product/version, TLS certificate details, and JARM/JA3S fingerprints — per host/port.

Fire-and-forget for big targets

A /24 finishes fast. A whole country does not, so don't block on it — kick it off, store the task_id, and poll when you're ready:

job = api.scan(targets=["country:DE"], ports="9200")
print("task_id:", job["task_id"])

# ...later, from anywhere
print(api.scan_status(job["task_id"]))

Targets can be a single IP, a CIDR, a list of CIDRs, a domain list, or a country:<CC> code.

Turn up the speed

Scan rate is set per call (capped by your plan). Higher speed = the same job finishes sooner:

job = api.scan(
    targets=["10.0.0.0/16", "192.168.0.0/16"],
    ports="1-1024",
    modules=["ports", "services"],
    speed=1000,  # kpps
)
api.scan_wait(job["task_id"], poll_interval=10)

# changed your mind?
api.scan_stop(job["task_id"])

Handle the errors you'll actually hit

from scansearch import Client, AuthError, RateLimitError, NotFoundError, APIError

try:
    api.scan_status(99999)
except NotFoundError:
    ...                       # no such task
except RateLimitError:
    ...                       # daily quota or per-minute limit
except AuthError:
    ...                       # bad / revoked key
except APIError as e:
    print(e.status, e.body)

Prefer the shell?

Everything above has a CLI equivalent:

scansearch scan 192.0.2.0/24 --ports 80,443,8080 --modules ports,services --wait
scansearch scan country:DE --ports 9200 --speed 1000 --wait
scansearch status 1234
scansearch stop 1234

Where on-demand scanning beats an index

Bug-bounty recon — scan your in-scope CIDRs fresh and grab current open ports + banners, not last month's.
Asset discovery / shadow IT — point it at your own AS or netblocks and find what's exposed that shouldn't be.
Continuous monitoring — scan your ranges daily, diff the results, alert on new open ports.
Vulnerability triage — combine services enrichment with CVE matching to find newly exposed ssh, rdp, elasticsearch, etc.