Yeni bir Linux sunucuda ilk 30 dakika: güvenlik kontrol listesi

VPS’i aldın, root şifresi e-postana geldi, heyecanlısın. Kötü haber: sunucun internete çıktığı andan itibaren dünyanın dört bir yanındaki botlar SSH kapısını yoklamaya başlıyor. İnanmıyorsan birkaç saat sonra journalctl -u ssh çıktısına bak; root kullanıcısıyla giriş denemeleri tek tek değil, sayfa sayfa akıyor.

İyi haber: bu botların neredeyse hepsi kolay lokma arıyor. İlk yarım saatte birkaç kapıyı kapatırsan listelerinden düşersin. Bu yazıdaki komutlar Ubuntu ve Debian için; başka bir dağıtım kullanıyorsan mantık aynı, paket yöneticisi farklı.

Kısa cevap: sistemi güncelle, kendi kullanıcını aç, SSH’a yalnızca anahtarla gir, root ve şifreli girişi kapat, güvenlik duvarında yalnızca gereken portları aç, otomatik güvenlik güncellemelerini aç ve ilk yedeği al. Gerisi ayrıntı.

1. Önce güncelle

Kalıp imajlar genellikle haftalar hatta aylar öncesinden kalmadır. İlk iş:

apt update && apt full-upgrade -y

Çekirdek güncellendiyse /var/run/reboot-required dosyası oluşur. Varsa sunucuyu şimdi yeniden başlat; içinde henüz hiçbir şey çalışmıyorken yeniden başlatmanın bedeli sıfır.

2. Root ile yaşama, kendi kullanıcını aç

Root her şeyi yapabilir, yanlışlıkla yapılanlar dahil. Günlük iş için sudo yetkili bir kullanıcı aç:

adduser semih
usermod -aG sudo semih

3. SSH anahtarı: şifreden vazgeç

Kendi bilgisayarında bir anahtar çifti üret ve genel anahtarı sunucuya kopyala:

ssh-keygen -t ed25519 -C "laptop"
ssh-copy-id semih@SUNUCU_IP

Şimdi en önemli kural: açık olan oturumu kapatmadan, yeni bir terminalde ssh semih@SUNUCU_IP ile girmeyi dene. Anahtarla girebildiğini ve sudo çalıştığını görmeden bir sonraki adıma geçme. Kendini sunucunun dışında kilitlemek, bu listenin en klasik kazasıdır.

4. SSH güvenliğini artır

Ana ayar dosyasını düzenlemek yerine ayrı bir dosya açmak daha temiz. Burada küçük ama sinsi bir tuzak var: OpenSSH aynı ayarı birden fazla yerde görürse ilk okuduğu değeri kullanır ve sshd_config.d klasöründeki dosyaları alfabetik sırayla okur. Bazı bulut imajları 50-cloud-init.conf içinde şifreli girişi açık bırakır. Dosyanın adını 00- ile başlatırsan senin ayarın önce okunur:

# /etc/ssh/sshd_config.d/00-guvenlik.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Ayarı uygulamadan önce sözdizimini kontrol et, sonra servisi yeniden başlat ve gerçekte ne uygulandığına bak:

sudo sshd -t && sudo systemctl restart ssh
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"

SSH portunu 22’den başka bir sayıya taşımak loglardaki kalabalık görüntüyü azaltır ama güvenlik önlemi sayılmaz. Asıl koruma, şifreyle girişin kapalı olması.

5. Güvenlik duvarı: yalnızca gerekeni aç

Ubuntu’da ufw hazır gelir, Debian’da apt install ufw ile kurulur. Sıralama önemli, SSH iznini güvenlik duvarını açmadan önce ver:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

Docker kullanıyorsan bir uyarı: Docker’ın dışarı açtığı portlar ufw kurallarını atlayabilir. -p 3306:3306 yazdığın bir veritabanı konteyneri, ufw’da kapalı görünse bile internete açık olabilir. Yalnızca sunucu içinden erişilecek servisleri -p 127.0.0.1:3306:3306 biçiminde bağla.

6. fail2ban: kapıyı zorlayanları beklet

Şifreli girişi kapattıysan botlar zaten içeri giremez; fail2ban burada daha çok loglardaki kalabalığı ve boşa harcanan kaynağı azaltır. Yine de kurması bir dakika:

sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 5
bantime = 1h

Debian 12 gibi auth.log dosyası tutmayan sistemlerde aynı bölüme backend = systemd satırını ekle. Durumu sudo fail2ban-client status sshd ile görebilirsin.

7. Güvenlik güncellemeleri kendiliğinden gelsin

Her sabah sunucuya girip güncelleme kontrol etmeyeceksin, kimse etmiyor. Bırak işi sistem yapsın:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Bu yalnızca güvenlik güncellemelerini otomatik kurar. PHP’nin ya da veritabanının büyük sürüm geçişleri hâlâ senin kontrolünde kalır, kalmalı da.

8. Saat dilimi ve saat

Loglardaki saat ile senin saatin tutmuyorsa, gece 03.00’teki bir hatayı ararken yanlış yere bakarsın:

sudo timedatectl set-timezone Europe/Istanbul
timedatectl

Çıktıda System clock synchronized: yes görmelisin. SSL sertifikaları ve iki adımlı doğrulama kodları doğru saate bağlıdır.

9. Küçük sunucuya küçük bir swap

1 veya 2 GB RAM’li bir sunucuda bir composer install ya da büyük bir yedek alma işlemi belleği bitirebilir. Linux bu durumda bir süreci öldürür ve genellikle öldürdüğü şey veritabanıdır. Küçük bir swap dosyası bu ani çöküşü yavaşlamaya çevirir:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Swap, RAM’in yerini tutmaz. Sunucu sürekli swap kullanıyorsa bu bir ayar sorunu değil, büyütme sinyalidir.

10. İlk yedek, ilk gün

Yedek konusunu “site yayına girince hallederim” diye ertelemek en pahalı ertelemedir. Kuralı basit tut: veritabanı dökümü ve yüklenen dosyalar her gün, sunucunun dışında bir yere gitsin. Sağlayıcının anlık görüntü (snapshot) özelliği güzel ama sağlayıcı hesabına bir şey olursa yedek de onunla gider.

Bir de şu cümleyi bir yere yaz: denenmemiş yedek, yedek değil umuttur. Ayda bir kez yedeği boş bir makineye geri yükleyip gerçekten çalıştığını gör.

Kontrol listesi

Adım	Komut ya da dosya	Neden
Güncelleme	apt full-upgrade	Bilinen açıkları kapatır
Kullanıcı	adduser, usermod -aG sudo	Root ile günlük iş yapılmaz
SSH anahtarı	ssh-copy-id	Şifre tahminini anlamsız kılar
SSH ayarı	00-guvenlik.conf	Root ve şifreli girişi kapatır
Güvenlik duvarı	ufw	Yalnızca 22, 80, 443 açık kalır
fail2ban	jail.local	Deneme yapanları bekletir
Otomatik güncelleme	unattended-upgrades	Güvenlik yamaları beklemez
Saat	timedatectl	Loglar ve sertifikalar doğru saati görür
Swap	/swapfile	Bellek dolunca ani çöküşü önler
Yedek	Sunucu dışında, günlük	Kötü günün sigortası

Hepsi bu. Yarım saat sonra elinde, bot listelerinin “uğraşmaya değmez” kısmına düşmüş bir sunucu var. Sunucun bir gün yavaşlarsa nereye bakacağın da ayrı bir yazının konusu.

Sunucu kurulumunu ya da taşımasını birine devretmek istersen teklif formundan yazabilirsin.