Yeni Bir VPS'te İlk Saat: Güvenlik Sıkılaştırma Checklist'im

Yeni bir VPS ayağa kalktığında, müşteri için olsun ya da kendi sunucularımdan biri olsun, aynı kısa checklist'ten geçmeden hiçbir şey deploy edilmiyor. Bir saatten az sürüyor, ve yeni bir IP internette göründükten dakikalar içinde otomatik scanner'ların ve bot'ların üzerine geldiği attack surface'ı kapatıyor. Bunların hiçbiri egzotik değil, gerçekten fark yaratan sıkıcı, temel şeyler.

1. Hemen password auth'tan kurtul

Root ile ilk giriş yaptıktan sonra ilk yaptığım şey, sudo yetkili non-root bir kullanıcı oluşturmak, SSH public key'imi oraya kopyalamak, ve başka bir şeye dokunmadan önce ikinci bir terminalde key ile login'in çalıştığını test etmek.

adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Bu login çalıştıktan sonra, /etc/ssh/sshd_config'e üç değişiklik geliyor:

PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3

systemctl restart sshd, ve bu noktadan sonra sunucuya girişin tek yolu benim ve müşterinin makinesinde bulunan bir private key, brute-force ya da phishing yapılabilecek bir password değil.

2. Default-deny firewall

UFW (ya da stack'e göre CSF) sırada: gelen trafiği varsayılan olarak engelleyecek, sunucunun gerçekten ihtiyaç duyduğu portları ise açıkça açacak şekilde ayarlıyorum:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Başka her şey, bir veritabanı portu, bir kontrol paneli, bir admin arayüzü, ancak somut bir ihtiyaç olduğunda açılıyor, ve genelde tüm dünyaya açık bırakmak yerine belirli bir kaynak IP'ye ya da bir VPN aralığına kısıtlanıyor. Daha önce yazdığım CyberPanel solucanını tam olarak bu adım durdururdu: zafiyetli admin portu her yerden erişilebilirdi, ve bunu düzeltecek firewall kuralı on saniye sürer.

3. Gürültü için Fail2ban

Sadece key ile SSH bile olsa, IP aralıklarını tarayan bot'lardan gelen login denemeleriyle log'lar doluyor. Fail2ban hedefli bir saldırıyı durdurmaz, ama gürültüyü ciddi şekilde azaltır ve birkaç başarısız denemeden sonra IP'leri banlar:

apt install fail2ban
systemctl enable --now fail2ban

Başlangıç için default sshd jail'i yeterli. Sunucuda Nginx gibi web'e açık bir servis ya da WordPress login sayfası varsa, onlar için de jail ekliyorum, aynı IP'den tekrarlanan /wp-login.php istekleri de SSH brute-force kadar hızlı banlanıyor.

4. Unattended security update'ler

Kendini patch'lemeyen bir sunucu, er ya da geç bilinen bir açığı olan bir kernel ya da OpenSSL sürümüyle çalışmaya devam eder, ve o açık orada bekler. Unattended upgrades, security patch'leri otomatik olarak hallediyor, kernel update'i reboot gerektiriyorsa düşük trafikli bir zaman dilimine planlanmış şekilde:

apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

Arada bir /var/log/unattended-upgrades/'e bakıyorum, sadece kurulu olduğunu değil, gerçekten çalıştığını doğrulamak için.

İşte temel bu

Bunların hiçbiri ileri seviye değil, ve asıl mesele de bu: herhangi bir uygulamaya özel şey kurulmadan önce her sunucunun üzerinde durması gereken taban bu. Sızıldığını gördüğüm sunucular neredeyse hiçbir zaman bir zero-day'e değil, varsayılan bir şifreye, açık bir admin portuna ya da aylardır patch'lenmemiş bir kernel'a yenildi. Burada geçirilen bir saat, ileride çok daha kötü bir günü engelliyor.