A college student's journey from mindless config checking to actually solving something real
The coffee's gone cold. It's 2:47 AM and I'm in my room staring at VirtualBox. My network security professor assigned us to audit 20 virtual machines for our lab assignment—check SSH configs, firewall rules, password policies, the works.
I'm on VM number eight.
My fingers move on autopilot: start VM, wait for boot, ssh admin@192.168.1.108, password, cat /etc/ssh/sshd_config, scroll, look for PermitRootLogin, check if it says "no", screenshot for submission, shutdown VM. Next one.
This is what I thought cybersecurity would be? Really? Somewhere around VM twelve, a thought cuts through the caffeine haze: I'm literally doing what a for-loop does. Why am I the for-loop?
That's when AuditFlow started. Not as some grand vision. Just as a desperate attempt to stop being a human script.
The Thing They Don't Tell You in Class
Our professors love showing us the flashy stuff. Penetration testing. Ethical hacking. Catching sophisticated exploits. Breaking into systems like it's a movie.
Here's what actually happens in the real world: most companies get breached because someone forgot to close port 23. Or left default credentials. Or disabled the firewall "just for a minute" six months ago.
Last summer during my vacation, I watched a senior engineer almost cry when we discovered a breach. "I audited that server," he kept saying. "I know I did."
He had. Six weeks earlier. But someone made a "quick change" and forgot to document it. The system drifted. The security went with it.
Manual audits are snapshots of a movie that never stops. You check server health on Monday. By Friday, twenty things have changed. By next month, you've forgotten which twenty things.
According to Verizon's 2023 breach report, 82% of hacks involve misconfiguration or human error. Not zero-days. Not sophisticated attacks. Just... someone forgot something.
It's like training for months in martial arts and getting knocked out because you left your door unlocked.
When the Pattern-Matching Breaks
Here's what was happening in my brain at 2 AM:
Server 1: Check if PermitRootLogin = no ✓
Server 2: Check if PermitRootLogin = no ✓
Server 3: Check if PermitRootLogin = no ✓
...
Server 8: Check if PermitRootLogin = no ✓
Server 9: Check if PermitRoot... wait, what was I checking?
I wasn't thinking anymore. I was pattern-matching. My brain had switched to energy-saving mode, just looking for anything that seemed different from the previous seven files.
That's when dangerous stuff slips through. Not because you're bad at your job. Because human brains aren't designed for perfect repetition. We're designed for creativity, problem-solving, recognizing new patterns—not being biological bash scripts.
My data structures professor always said: "If you're doing something repetitive, you're doing it wrong."
So, I stopped. Opened a new terminal. Started writing Python.
Building Something That Actually Helps
The first version was embarrassingly simple. A script that SSH'd into a server, read the SSH config, and checked five things. It was ugly code. It probably violated every best practice. My friend who loves Rust said it made his eyes hurt.
But it worked. And it didn't get tired. It didn't lose focus. It checked server 50 with the same attention as server 1.
That's when I realized: I wasn't building a replacement for security engineers. I was building a tool that handles the boring stuff so engineers can focus on actual security work—like investigating why someone's trying to brute-force port 22, not whether port 22 has good password policies.
The hard part wasn't the code though. The hard part was understanding what "secure" actually means.
Quick test: Is PermitRootLogin prohibit-password secure?
I thought yes. Two of my classmates thought yes. We were all wrong.
That setting blocks password-based root login but still allows key-based root login. If someone steals your SSH key—which happens—they're in. The actually secure option is PermitRootLogin no, period.
These tiny distinctions are everywhere in the CIS Benchmarks (this massive document of security rules that companies follow). They're the kind of detail you miss when you're on autopilot checking server 23 at 3 AM.
The Moment It Clicked
I finally got the scanner working on my test server—a deliberately misconfigured Docker container I'd set up. Hit enter. Watched the scan run.
The report came back:
CRITICAL: SSH Root Login Enabled
CRITICAL: Firewall Disabled
HIGH: Password Policy Too Weak
HIGH: Dangerous Ports Open
Compliance Score: 23/100
Risk Level: CRITICAL
I spent an hour fixing everything. Re-ran the scan: 94/100.
That score jumping from 23 to 94? That's when it hit me. This wasn't just automating checks. This was making security visible. Measurable. Real.
Before, security was vague: "I think we're okay?" After: "We were 23/100 last week, we're 94/100 now, here's what we fixed." Progress you can actually see and prove.
Why It Matters (The Practical Part)
Let's say a hospital gets breached through an SSH misconfiguration. Attackers got in because root login was enabled—violating CIS Benchmark 5.2.10.
The investigation reveals it. The hospital gets fined. HIPAA violations can hit millions of dollars. Cyber insurance might not cover it because they didn't follow basic security practices.
But if they'd been running daily automated scans? If they could show documented efforts to maintain compliance? That's due diligence. Fines get reduced. Insurance covers more. It's the difference between "we were negligent" and "we were trying but got unlucky."
This isn't paranoid security theatre. It's covering your ass when things inevitably go wrong.
The Messy Reality
Building this hasn't been smooth. Ubuntu and CentOS store configs in different places. Some use ufw, others use iptables. My "universal" scanner worked perfectly on my laptop and crashed on every other system.
Early versions flagged everything as CRITICAL. Custom SSH port? CRITICAL! Non-standard firewall rules? CRITICAL! Security teams started ignoring the alerts. I'd created the boy-who-cried-wolf problem.
I've spent full days debugging why the scanner worked on 49 servers but died on number 50. (Turned out that server had a slightly different Linux distribution that formatted command outputs differently. Took eight hours to figure that out.)
Real engineering is messier than textbooks make it seem.
What I'm Actually Building
Current features that work:
• Scans ports and running services
• Checks SSH configurations against CIS Benchmarks
• Verifies firewall status
• Validates password policies
• Generates HTML reports with actual remediation steps
What's coming next:
• Web interface (because CLI-only is limiting)
• REST API (so other tools can integrate)
• Scheduled automatic scans
• Better visualization (graphs, trends, executive-friendly summaries)
What I need help with:
• Windows Server (I don't know Windows Server)
• More security checks (CIS has hundreds of benchmarks)
• Testing on different Linux distributions
• Making it not break in weird edge cases
Why I'm Open-Sourcing This
I could keep it private. Use it as my portfolio piece. Demo it only in interviews.
But that 82% misconfiguration problem affects everyone. Small companies. Hospitals. Probably my own college's servers.
If this helps even one person catch one misconfiguration before it becomes a breach headline, it's worth sharing.
Plus, I need help. I'm a student who learned most of this three months ago. I don't have all the answers. But I built something that works, and maybe together we can make it actually good.
What This Means for You
If you're still in college: this is what professors mean when they say "apply what you learned." Find something repetitive and annoying in your internship or lab work. Build a tool to fix it.
If you're already working: you probably do something manually that could be automated. What's your 2 AM config-checking equivalent?
If you're hiring: I solve problems I've personally experienced. I build things that work. I'm graduating in February. My email's below.
Try It Yourself
Code's on GitHub: https://github.com/phillippauljames-code/auditflow
It's not perfect. It probably has bugs. But it solves a real problem and it's free.
Clone it. Test it. Break it. Tell me what's wrong. Or just star it so I feel productive.
The bottom line: We're not supposed to be human bash scripts. We're supposed to build the bash scripts and focus on actual interesting problems.
So stop being the for-loop. Build the for-loop instead.
Coming next: Docker, chaos, and why breaking things on purpose matters
Find me:
GitHub: @phillippauljames-code
LinkedIn: Philip Paul James
Email: phillippauljames@gmail.com
Philip Paul James
Aspiring Cybersecurity Professional
Top comments (0)