Skip to content

Portal | Level: L1: Foundations | Topics: Security Scanning | Domain: Security

Ops-Focused Security Basics - Primer

Why This Matters

Security is everyone's responsibility, but operations engineers are the last line of defense. You control SSH access, manage secrets, configure firewalls, patch vulnerabilities, and respond to incidents. A single misconfigured security group, leaked credential, or unpatched server can compromise an entire organization. You don't need to be a security engineer, but you need to think like an attacker to defend like an operator.

Core Concepts

The Principle of Least Privilege

Every user, service, and process should have the minimum permissions required to do its job. Nothing more.

Fun fact: The Principle of Least Privilege was formalized by Jerome Saltzer in 1975 in his paper "The Protection of Information in Computer Systems." It is one of the oldest security principles in computing — and still the most frequently violated. Over 80% of cloud security breaches involve overly permissive IAM roles or credentials.

Applied in practice: - Users: developers don't need root on production servers - Service accounts: a web app doesn't need S3 delete permissions if it only reads - Processes: run services as non-root users with limited filesystem access - Network: only open ports that are actively used - Time: temporary access is better than permanent access

IAM Basics

Identity and Access Management controls who can do what to which resources.

Key concepts (cloud-agnostic): - Users: individual human identities - Groups: collections of users with shared permissions - Roles: sets of permissions that can be assumed by users or services - Policies: documents that define what actions are allowed or denied

// Example AWS IAM policy: read-only S3 access
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

Best practices: - Never use root/admin accounts for daily work - Use groups for permission management, not individual user policies - Prefer roles over long-lived access keys - Enable MFA on all human accounts - Audit permissions regularly: who has access to what?

SSH Hardening

SSH is the primary way you access servers. Default configs are not secure enough for production.

Key hardening measures:

# /etc/ssh/sshd_config

# Disable password authentication (keys only)
PasswordAuthentication no
ChallengeResponseAuthentication no

# Disable root login
PermitRootLogin no

# Restrict to specific users or groups
AllowGroups ssh-users

# Use SSH protocol 2 only (should already be default)
Protocol 2

# Limit authentication attempts
MaxAuthTries 3

# Set idle timeout
ClientAliveInterval 300
ClientAliveCountMax 2

# Disable X11 forwarding (unless needed)
X11Forwarding no

# Disable TCP forwarding (unless needed)
AllowTcpForwarding no

# Use strong ciphers only
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

SSH key management: 

# Generate a strong key (Ed25519 preferred over RSA)
ssh-keygen -t ed25519 -C "user@company.com"

# Copy public key to server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# Use SSH agent (don't type passphrase every time)
eval "$(ssh-agent)"
ssh-add ~/.ssh/id_ed25519

Firewall Rules

Control network access at the host and network level.

Host-level firewall (iptables/nftables/firewalld): 

# firewalld (RHEL/CentOS)
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --permanent --remove-service=cockpit
firewall-cmd --reload

# iptables basics
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT    # SSH from internal only
iptables -A INPUT -p tcp --dport 22 -j DROP                       # Drop all other SSH
iptables -A INPUT -p tcp --dport 443 -j ACCEPT                    # HTTPS from anywhere
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT  # Allow return traffic
iptables -A INPUT -j DROP                                          # Default deny

Cloud security groups: stateful firewalls for cloud instances. Apply least privilege: only allow traffic from known sources on required ports.

Secrets Management

Secrets include: passwords, API keys, tokens, certificates, SSH keys, database credentials.

Where secrets should live: - HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager - Environment variables (for runtime injection) - Encrypted configs (Ansible Vault, SOPS)

Where secrets should NEVER live: - Git repositories (even private repos) - Dockerfiles or container images - Log files - Environment variable dumps in error pages - Plaintext config files on servers

# Check for secrets in Git history
trufflehog git file://./my-repo --only-verified
git log --all -p | grep -iE "password|secret|api_key|token" | head -20

# Use SOPS for encrypted config files
sops --encrypt --in-place config.yaml
sops --decrypt config.yaml

CVE Response

CVE (Common Vulnerabilities and Exposures) is the system for identifying known security flaws.

Response workflow: 

1. Alert: new CVE published affecting your stack
2. Assess: what's the severity? (CVSS score: 0-10)
   - Critical (9.0-10.0): patch immediately
   - High (7.0-8.9): patch within days
   - Medium (4.0-6.9): patch within weeks
   - Low (0.1-3.9): patch in normal cycle
3. Scope: which of your systems are affected?
4. Mitigate: apply workaround if patch isn't available
5. Patch: update the affected package/image/library
6. Verify: confirm the fix is applied everywhere

Vulnerability Scanning

# Scan container images
trivy image nginx:latest
trivy image --severity HIGH,CRITICAL myapp:v1.2.3

# Scan filesystem
trivy fs --security-checks vuln,config /path/to/project

# Scan running containers
trivy image $(docker ps --format '{{.Image}}')

# Scan infrastructure as code
trivy config ./terraform/
checkov -d ./terraform/

Certificate Management

TLS certificates encrypt traffic and verify identity.

# Check certificate expiration
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Check certificate chain
openssl s_client -connect example.com:443 -showcerts

# Generate a self-signed cert (testing only)
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

# Use certbot for free Let's Encrypt certs
certbot certonly --standalone -d example.com
certbot renew   # Auto-renewal

Automate certificate renewal. Expired certificates cause outages.

Remember: Key security port numbers: SSH=22, HTTPS=443, LDAP=389, LDAPS=636, Kerberos=88, SMTP=25/587, DNS=53. Mnemonic for the critical pair: "22 to get in, 443 to serve out."

Under the hood: Ed25519 keys are 256-bit elliptic curve keys that provide equivalent security to RSA-3072 but in a 68-character public key (vs 400+ for RSA). They are faster to generate, faster to verify, and resistant to several side-channel attacks. There is no reason to use RSA for new SSH keys unless you must support legacy systems that do not support Ed25519.

What Experienced People Know

  • Security is a spectrum, not a destination. Perfect security doesn't exist; the goal is making attacks more expensive than the value they'd gain.
  • The most common attack vector is leaked credentials, not sophisticated exploits. Guard your secrets.
  • Patch regularly, not reactively. A patching schedule that runs monthly is better than panic-patching after a CVE announcement.
  • Audit logs are useless if nobody reads them. Set up alerts for suspicious activity: root logins, sudo usage, failed SSH attempts.
  • Defense in depth: if one control fails, the next one catches it. Firewall + host firewall + application auth + encryption. Never rely on a single layer.
  • Automate security checks in CI/CD: image scanning, secret detection, IaC scanning. Shift security left.

Wiki Navigation

Prerequisites

Next Steps

Related Content