Recently, while investigating Docker and network security on a Raspberry Pi, I started from a reasonable assumption: if UFW had its rules configured, those rules should have been protecting the services Docker published.
I didn't take that for granted.
I traced where the traffic actually went.
And that's where the problem showed up.
Traffic headed to a service Docker published wasn't following the same path as traffic headed to the system itself. Docker had its own rules for published services, and those rules were being evaluated before the UFW controls I was looking at.
That meant UFW's rules could be correctly configured and working, and still not be the thing controlling the traffic I thought they were protecting.
The question stopped being:
"What rule should I add?"
And became:
"What is actually happening with this traffic?"
That shift in the question made all the difference.
From there, the investigation turned into a series of tests: observe the actual state, trace where the traffic went, change one variable at a time, restart services, check what survived, and separate what was proven from what was still a hypothesis.
One of the pieces that showed up in that investigation was DOCKER-USER, a chain Docker builds into exactly that path, and one that turned out to matter far more for the control model than the UFW rules I'd originally been looking at.
But even there, I decided not to jump straight to a fix.
There were still questions that needed evidence: what happens to that chain during Docker's various lifecycle events, what happens when UFW is involved in creating it, and what guarantees we actually have that the control mechanism stays in place after restarts, reloads, or changes to the containers.
And that reminded me of something I've come to see as increasingly important in technology:
a configuration existing is not evidence that a mechanism works.
A rule existing doesn't prove traffic passes through it.
A service being active doesn't prove it's protected the way we think.
A solution working on one system doesn't prove it works the same way on ours.
And an AI proposing a technically plausible solution doesn't prove we should implement it either.
The fix might be correct.
But first it has to be shown to address the real problem.
This is also changing how I use AI to investigate technical problems.
Instead of asking directly:
"How do I fix this?"
the question starts to become:
"What do we need to observe to know what's happening?"
Then comes the hypothesis.
Then the test.
Then the evidence.
And only then the decision.
The result isn't always a new configuration.
Sometimes the result is discovering that our initial interpretation was wrong.
And to me, that's a valuable result too.
Because a hypothesis that doesn't survive the evidence can save us from implementing the wrong fix.
Maybe one of the most important skills when working with AI isn't getting it to give us faster answers.
Maybe it's learning not to accept too quickly an answer we haven't actually proven yet.
First we see. Then we decide.
Want to know if your infrastructure has the same kind of exposure? Schedule a technical conversation with Directsales PTY.