Removing the Logs Was the Easy Part
Once I'd identified the logs, I assumed the difficult part of the investigation was over.
I was wrong.
From a technical perspective, the changes themselves were surprisingly simple.
- Configuration files were edited.
- Services were restarted.
- Log settings were modified.
- In one case, the solution involved changing only a few lines in a configuration file.
The actual remediation took minutes.
But then another question appeared.
How could I be certain that I'd changed the right thing?
Deleting a log file proves very little.
Disabling a logging mechanism is only the first step.
Verification is the second step.
I didn't want to assume that a configuration change had worked.
I wanted evidence.
That meant performing real-world tests.
Files were transferred between computers.
Services were restarted.
The virtual server itself was rebooted.
The logs were examined again.
The file transfers still worked.
The logs didn't reappear.
Only then did I feel comfortable saying that the changes had been successful.
But there was another lesson hidden in the investigation.
Absolute statements can be surprisingly difficult to defend.
For example, what does "no logs" actually mean?
- No application logs?
- No operating system logs?
- No web server logs?
- No activity logs?
Those are very different things.
I discovered that precise language matters just as much as precise engineering.
That realisation eventually led me back to the SecurityNet website itself.
Some of the wording needed to be reconsidered.
Some claims needed to be refined.
Not because they were wrong, but because they could be interpreted in different ways.
In the end, the investigation changed more than the server configuration.
It changed the way I thought about privacy claims.
And that's probably the most valuable lesson of all.
In the next episode, I'll explain why privacy shouldn't depend entirely on trust.
Evidence may not answer every question, but it's a much better place to start.
