Scaling Security Insights: how we achieved a 10x increase in global scanning capacity
Security Insights provides actionable security recommendations for every Cloudflare account. To find these insights, we perform regular scans for all accounts, zones, and DNS records, looking for potential security risks and misconfigurations.
However, two key issues emerged. First, our scans were too infrequent. Scans were only being performed every week or two, and therefore newly introduced security risks could remain undetected for up to two weeks. Second, automatic scanning was opt-in for many free plan accounts – meaning lots of accounts weren’t being scanned at all.
The risks of infrequent or nonexistent scans are rising: as automated attacks accelerate, the window for detecting security misconfigurations is shrinking. Making sure that we’re finding these issues for all of our customers is crucial to our aim of building a better Internet for everyone.
We calculated that to increase our scanning frequencies and enable automatic scanning for all accounts, we would need to increase our scanning throughput by around 10x on average – from 10 scans per second to 100 per second. But our system was already struggling with its load: millions of events were filling up our backlog waiting to be processed; our API was frequently timing out; our processes were crashing. Continue reading
Hedge 308: Hidden Competence
We all talk about how engineers deal with imposter syndrome–but we don’t often talk about the experience of making things work “in the background.” What is competence, and what do we do when competence isn’t recognized? Justin Wilson (j2sw) joins Russ and Tom to discuss.
download
Cisco Live 2026 – Requiem For A Corner
Cisco Live US 2026 was an interesting ride this year. There was a lot of talk about AI. There was a big discussion about security and how we are protecting our software from the AI models on the horizon that are ready to uncover every bug ever conceived. And there was even more discussion about whether Cisco was ahead of the game or behind the curve on their support for everything from eBPF to the latest Mythos reports. I say there was a lot of discussion, but I’m not sure where exactly it was happening.
Social Desert
One of the biggest things I heard from my friends at the event was how light everything felt. Fewer people was a common theme. The reported number was around 22,000 but it felt closer to 20,000 to me. The World of Solutions felt very spread out this year, with most of the back side being Cisco booth space.
The other thing was the Social Hub. It had shrunk from last year. At least the couches were facing each other this year. And there were some cool stickers and some interesting puzzles to work on. But there were far too few tables for people Continue reading
CCDE Practical Exam — Tips and Tricks for Exam Day
I recently passed the CCDE practical exam at Cisco Live. I am now CCDE #2026::37. During my preparation, I gathered insights from fellow candidates, seasoned CCDEs, and instructors, including Zig…
The post CCDE Practical Exam — Tips and Tricks for Exam Day appeared first on JTnetwork.io.
Installing Dnsmasq in My Homelab
Dnsmasq is an application which has features like DNS caching, DHCP server, and so on. It’s useful as a DNS server in a homelab as it can reply to DNS queries for what’s in its database, and forward everything else to an authoritative server or recursive resolver. This is useful in my lab as I want to resolve for example gitlab.lostintransit.se locally, but lostintransit.se (my web server) or any other domains via recursive resolvers. Most DNS servers are authoritative for a zone or parts of a zone, but dnsmasq responds only to what it knows and forwards everything else, which is perfect for my needs.
First I’ll configure a static IP on the host by modifying the file in /etc/netplan:
sudo vi 50-cloud-init.yaml
The contents are now:
sudo cat 50-cloud-init.yaml
network:
version: 2
ethernets:
ens160:
dhcp4: no
addresses:
- 192.168.128.53/24
routes:
- to: default
via: 192.168.128.1
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
I’m using recursive resolvers for now but will update it later.
Then apply the configuration:
sudo netplan apply
The IP has been updated:
ip addr show ens160 2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> Continue reading
Using netlab to Configure Live Devices
Leo Fleskes sent me an interesting question after reading my Generate Partial Device Configurations with netlab blog post:
What is stopping us from eventually, given enough usage and coverage, using netlab to configure devices in the live network?
In theory, nothing. In practice, you might hit a few hurdles:
Five Principles of an Accountable AI Agent Network: How to Evaluate Any Governance Platform
The first post in this series argued that AI agent governance hasn’t kept pace with deployment. The second laid out the five pillars of accountability, and what is required. The third walked through why network policies, API gateways, MCP/A2A protocols, DIY security patterns, and Role-based Access Control (RBAC) each leave critical accountability gaps.
So what does good look like?
The five pillars define what AI agent accountability requires. The principles below define how a governance platform should deliver it. These are the architectural principles your team should evaluate any AI agent governance solution against, whether you build it, buy it, or assemble it from open-source components.
If a vendor pitches you a governance platform that fails any of these five, walk away.
What are the five principles of an accountable AI agent network?
Kubernetes Network Policies are essential for securing any cluster. They restrict which pods can communicate with which other pods at the network level, and they should absolutely be part of your security posture.
- Default-deny: No agent communicates unless a policy explicitly permits it.
- Attribute-based policy: Policies reference agent attributes, not agent names.
- Zero-trust identity: Every request authenticated, every identity verified.
- Audit by design: Every interaction produces a Continue reading
A field guide to the agents in your cluster
You know every service in your cluster by name. You know which team owns each one, what it talks to, how it scales, where its logs go. The agents are a different story.
That’s not a criticism, it’s an observation, and it’s one we keep running into. Every company we talk to is shipping agents of some kind, from scales of 10s to 1000s. Customer service bots that field tier-one tickets. Internal copilots that draft emails and summarise meetings and write the boring half of every PR. SREs that handle their own incidents at 2am while the team sleeps. What used to be a few experimental builds in a dev cluster is now dozens in some shops and hundreds in the biggest, growing faster than most teams are tracking.
That growth curve is the interesting part. Services tend to come into existence through a fairly heavyweight process. There’s a ticket, a design review, an owner, a runbook. Agents tend to arrive the way side projects do:
- Somebody had an idea on a Tuesday.
- By Friday it was in staging.
- At some point nobody can quite remember when it became part of the actual business.
Who said it could do that?
Route public traffic to private applications with Cloudflare
For most of the Internet’s history, public and private infrastructure operated as separate worlds. Public applications lived behind content delivery networks (CDNs) and web application firewalls (WAFs). Private applications lived behind virtual private networks (VPNs), firewalls, and separate operational stacks. We think that distinction is becoming obsolete.
Many of the applications organizations care about are not public websites. They are internal APIs, AI agent backends, MCP servers, operational tools, and services that were never designed to be exposed to the public Internet. Yet these applications still need modern security, performance, and programmability services. Security should be a property of the traffic reaching an application, not an accident of where the application happens to sit.
Until now, applying those services to private applications often required public IPs, firewall exceptions, connector software, or complex networking. As a result, many private applications missed out on capabilities such as WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers, despite needing the same protections and controls as public-facing applications.
Today, we're launching Application Services for Private Origins in closed beta for eligible Enterprise customers. Customers can now securely route traffic to private origins without exposing those origins to the public Internet. This allows Continue reading
Pinging Hosts Sequentially vs Concurrently in Python
I’m reorganizing some things in my homelab and wanted to check how many hosts are alive in a /24. The simple check, while not perfect, is to ping all the hosts and see who responds. I used Claude to generate some Python for me and noticed it used some tools I had not used before, to run code concurrently, which really speeds up things like scanning a /24 for alive hosts. In this post I’ll compare running sequentially vs concurrently and break down the code.
Running something sequentially means that every job, such as checking if an IP is alive, must run to completion before the next job starts. This is highly inefficient, of course, mainly for two reasons:
- Work can’t be performed in parallel
- Most of the time is spent waiting, rather than working
Especially when the job involves something like ping, we must give hosts a reasonable time to respond, so we’ll wait up to a second. We also can’t one-shot the ping because what if we have no ARP entry for the host we are pinging (assuming same subnet)? Then, a host that is alive could be reported as dead due to the missing ARP entry.
I’ll Continue reading
Goodbye, Leaf-and-Spine Networks?
A friend of mine sent me links to a new paper published by AWS engineers, and an associated LinkedIn post which claims:
We got lean, resilient, massive aggregation fabrics that provide 33% better throughput with 69% fewer routers, savings 27% of costs, cutting power usage by 40%, and reducing CO2 emissions.
The obvious question one should ask after reading the hyperventilated Radical Network Redesign blog post is thus: is this the end of leaf-and-spine networks? Of course not. Let’s go into the details.
Overcoming the trade-offs in data sovereignty
What does data sovereignty actually mean for your network, which trade-offs are unavoidable? Learn more.Blogging with an LLM assistant
AI slop is invading the web. A recent story about disallowing LLM-generated submissions on Lobsters triggered a lot of debate. My personal worst offenders are LinkedIn articles with AI-generated images and uninspired articles filled with emojis from people trying to masquerade as experts on a subject they don’t care enough to write themselves. While I am unhappy about this situation, I rely on LLMs for grammar, copyediting, and translation. I don’t see this as a contradiction.
I am a native French speaker, but I blog in both English and French. When I started writing this blog in 2011, I was composing in French and translating to English, but I found it was better to work in the reverse order to avoid unnatural and non-idiomatic constructions. One of my goals is to write “good” English but I never felt it was my strong point.1 For example, verb tenses are often an issue, even if I mostly stick with the present tense. I learn the rules and forget them right away. I also don’t feel like hiring an editor for something I see as an hobby.
As an example, I have kept the history of the Continue reading