Overload/README.md

I can kill your server by overloading your disk

You dont have a firewall

You dont have a VPN for your internal services

You dont have a DMZ

You are mixing your production deployment and your test deployment

PLEASE Set up firewall so at least DRONE CI API isnt exposed

Server & Deployment Security Hardening Guide

Threat model (what we’re defending against)

• Disk exhaustion / resource exhaustion
• Direct access to internal services
• Lateral movement after compromise
• Accidental exposure of test systems
• No network segmentation or trust boundaries

---

1. Network Segmentation (Non-Negotiable)

Environments

NEVER mix these on the same host or network segment:

• Production
• Staging
• Test / Dev

Minimum setup

• Separate VMs or nodes
• Separate subnets/VPCs
• Separate credentials
• Separate databases

Zones

• Public zone: Load balancer / reverse proxy only
• DMZ: Web servers
• Internal zone: Databases, queues, caches
• Management zone: SSH, monitoring, CI/CD

---

2. VPN for Internal Services

Internal services must not be publicly routable.

Options:

• WireGuard (recommended)
• OpenVPN
• Cloud-native private networking (AWS VPC, GCP VPC, etc.)

Rules

• Databases listen on private IPs only
• Redis, Kafka, internal APIs → VPN or private subnet
• No public IPs for internal services

---

3. Firewall Policy (IPtables)

Firewall Philosophy

• Default deny
• Explicit allow
• Log drops (rate-limited)
• Stateful filtering

---

4. IPtables Baseline Configuration

Flush existing rules

iptables -F
iptables -X
iptables -t nat -F
iptables -t mangle -F

---

Default policies

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

---

Allow loopback

iptables -A INPUT -i lo -j ACCEPT

---

Allow established connections

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

---

SSH (restricted)

iptables -A INPUT -p tcp --dport 22 -s <YOUR_VPN_SUBNET>/24 -m conntrack --ctstate NEW -j ACCEPT

Never expose SSH to the world.

---

HTTP / HTTPS

iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT

---

Rate-limit connections (DDoS / abuse mitigation)

iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 50 -j DROP
iptables -A INPUT -p tcp --syn --dport 80  -m connlimit --connlimit-above 50 -j DROP

---

Protect against SYN floods

iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP

---

ICMP (limited)

iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 5 -j ACCEPT

---

Log and drop everything else

iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPTABLES DROP: "
iptables -A INPUT -j DROP

---

Persist rules

iptables-save > /etc/iptables/rules.v4

---

5. Disk Exhaustion Protection

Enable disk quotas

mount -o remount,usrquota,grpquota /
quotacheck -cum /
quotaon /

Log rotation

apt install logrotate

Tmpfs for temp files

tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0

---

6. Application-Level Protections

Reverse proxy (mandatory)

• Nginx / HAProxy / Envoy
• Rate limiting
• Request body size limits

Example (Nginx):

client_max_body_size 10M;
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

---

7. Deployment Security Best Practices

CI/CD

• No SSH deploys
• Use short-lived credentials
• One-way artifact promotion (build once → promote)

Secrets

• Never in Git
• Use Vault / SSM / Secrets Manager
• Rotate regularly

---

8. OS Hardening

• Disable password SSH auth
• Use SSH keys only
• Fail2ban
• Automatic security updates
• Remove unused packages
• Run services as non-root

---

9. Monitoring & Alerting

You don’t have security if you don’t have visibility.

Monitor:

• Disk usage
• Connection counts
• Failed auth attempts
• Firewall drops
• CPU / memory saturation

---

10. Final Reality Check

If:

• You don’t have a firewall
• You don’t have segmentation
• You don’t have a VPN
• You mix prod and test

Then you don’t have security — you have hope.