After mastering how systems communicate in Networking (Day 7) ,I learned that communication without protection is like sending postcards without envelopes - anyone can read them.
So, my next mission was clear: learn how to protect the network.
This part of my journey was where DevOps met Security - the phase where "moving fast" had to evolve into "moving fast securely."
Network Security Attacks - The Reality Every Engineer Faces
My first encounter with security wasn't in a textbook - it was on an EC2 instance.
One morning, I opened /var/log/auth.log and saw dozens of failed SSH login attempts from random IPs.
That's when I realized: even your test servers are visible to the entire internet.
Let's break down a few common network security attacks I studied (and later simulated safely in my sandbox):
| Attack | What happens | How to mitigate |
|---|---|---|
| DDoS (Distributed Denial of Service) | Servers flooded with fake requests | Use CDN, WAF, rate limiting |
| Man-in-the-Middle (MITM) | Attacker intercepts communication | Enforce HTTPS/TLS, VPNs |
| DNS Spoofing | Fake DNS responses redirect users | Use DNSSEC & trusted resolvers |
| Port Scanning | Attackers find open services | Restrict ports via firewalls |
| Brute Force | Repeated login attempts | Enable fail2ban, SSH keys only |
Real-World Learning
When I faced that SSH attack, I realized my biggest mistake - I had allowed inbound SSH from 0.0.0.0/0.
Within hours, my logs were filled with brute-force attempts.
I fixed it by:
- Allowing SSH only from my IP range
- Switching to key-based authentication
- Installing fail2ban
Lesson: Security breaches don't wait for production - they start with small misconfigurations.
Firewall and ACL Configurations - The Digital Security Guard
A firewall isn't just software; it's the first layer of trust your system builds.
It decides who can knock on your door and who can't.
Example: Linux Firewall with iptables
sudo iptables -A INPUT -p tcp --dport 22 -s 192.168.1.10 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j DROP
This means:
- Only 192.168.1.10 can access SSH.
- Everyone else gets blocked.
AWS Security Group Example
| Rule type | Port | Source | Purpose |
|---|---|---|---|
| Inbound | 22 | My IP only | SSH access |
| Inbound | 80 | 0.0.0.0/0 | HTTP traffic |
| Outbound | All | 0.0.0.0/0 | Internet access |
In one of my sandbox deployments, my web app failed to load because I forgot to allow HTTP in inbound rules - a simple oversight that taught me how much firewalls influence availability.
Lesson: Firewalls don't just block; they define your system's exposure.
TLS, IPsec and Encryption Protocols - The Science of Safe Communication
Encryption is what turns a public network into a private channel.
As I explored it, I realized - security doesn't always mean adding tools; sometimes, it's about using the right protocol.
| Protocol | Purpose | Example use |
|---|---|---|
| TLS (Transport Layer Security) | Encrypts data in transit | HTTPS, email |
| IPsec (Internet Protocol Security) | Encrypts IP packets | VPNs, VPC tunnels |
| SSH (Secure Shell) | Secure remote login | Admin access |
| DNSSEC | Validates DNS responses | Prevents DNS spoofing |
To check if a site supports TLS:
Lesson: Encryption doesn't make systems slower - it makes trust faster.
DevSecOps - Automating Security, Not Just Deployments
Once I got comfortable securing systems manually, I realized - manual security doesn't scale.
That's where DevSecOps comes in: security integrated into DevOps pipelines.
Instead of "deploy first, scan later," DevSecOps shifts everything left - security testing starts during development.
Here are some tools I began experimenting with:
| Tool | Purpose |
|---|---|
| Trivy | Scans Docker images for vulnerabilities |
| Falco | Monitors runtime threats |
| HashiCorp Vault | Manages and encrypts secrets |
| OWASP ZAP | Scans web apps for security issues |
| SonarQube | Detects code vulnerabilities and bugs |
Example: Trivy in Action
trivy image myapp:latest
It listed all the CVEs present in my Docker image - outdated packages, unpatched libraries.
I fixed those and pushed a cleaner, more secure image.
Lesson: Security isn't about fear - it's about visibility before failure.
My Turning Point - The "Allow All" Mistake
In one of my early deployments, I opened up inbound rules for all ports - just to test multiple services.
Within a day, my system logs showed multiple scans and failed access attempts.
That one careless configuration taught me what no textbook could:
"Convenience is the enemy of security."
Now, every environment I build - from testing to production - follows zero-trust principles and least privilege access.
Key Takeaways
- Every open port is an invitation - protect it.
- Security starts with small steps: IP restriction, SSH keys, encryption.
- Firewalls and ACLs define who your system talks to.
- DevSecOps = embedding security into every build, commit, and deployment.
- Prevention always costs less than recovery.
What's Next (Day 9 - Cloud Foundations and IAM Essentials)
Now that I've learned how to protect systems and secure communication, the next logical step is to explore where those systems live - the cloud.
In Day 9, I'll be exploring:
- What is Cloud Computing?
- Identity & Access Management (IAM)
- Introduction to AWS
That's where this journey moves from protecting connections to building secure infrastructure.
Top comments (1)
👍