Bir sabah sunucuma girdim ve garip processler gördüm. “İmpossible” diye düşündüm — SSH key kullanıyorum, fail2ban kurulu, firewall aktif. Nasıl girdiler? Cevap: UFW firewall kurmuş ama 3 portu gereksiz açık bırakmıştı, Redis şifresiz çalışıyordu ve SSH banner’ından sunucu bilgisi sızdırılıyordu. Benim hatamın aynısını binlerce kişi yapıyor. İşte sunucu güvenliğinde en çok atlanan ayarlar ve benim yaşadığım tecrübe.
Konu İçeriği
Ne Oldu? Olayın Hikayesi
Cuma gecesi sunucumdaki CPU kullanımı %98’e fırladı. Normalde %15 civarı. Hemen htop ile baktım ve tanımadığım bir process gördüm: kworkerds. Adı kernel worker gibi görünüyordu ama sahteydi — cryptominer’dı. Birisi sunucuma sızıp crypto madenciliği kurmuştu.
Hemen interneti kestim ve soruşturmaya başladım. Sophos’un 2026 raporuna göre, Linux sunucu ihlallerinin %63’ü yanlış yapılandırma nedeniyle oluyor — yani sıfır-day exploit değil, admin’in unuttuğu bir ayar yüzünden (Sophos, “Linux Server Security Report”, 2026).
Unutulan Ayar #1: Redis Şifresiz Erişim
Benim sunucumda Redis varsayılan ayarlarla çalışıyordu — yani şifresiz ve sadece localhost’tan erişime açık…diye düşünüyordum. Ama Redis bind 0.0.0.0 ile çalışıyordu ve dışarıdan erişilebilirdi.
Saldırgan Redis’e bağlanıp, kendi SSH key’ini Redis’in içine yazmış ve oradan authorized_keys dosyasına kopyalamış. Bu, 2018’den beri bilinen bir saldırı vektörü ama hâlâ çalışıyor çünkü insanlar Redis’i şifrelemeyi unutuyor.
Çözüm:
# /etc/redis/redis.conf dosyasında: bind 127.0.0.1 requirepass GüçlüŞifreBuraya123! rename-command FLUSHDB "" rename-command FLUSHALL "" rename-command CONFIG ""
Redis’i sadece localhost’a bağlayın, şifre belirleyin ve tehlikeli komutları devre dışı bırakın. Ben bu ayarı yaptıktan sonra Redis portunu dışarıdan kapattım da — ekstra güvenlik.
Unutulan Ayar #2: Gereksiz Açık Portlar
Ben UFW firewall kurduğumu hatırlıyordum ama tam kontrol etmemiştim. ufw status çalıştırdığımda gördüm:
Status: active To Action From -- ------ ---- 22/tcp ALLOW Anywhere 80/tcp ALLOW Anywhere 443/tcp ALLOW Anywhere 6379/tcp ALLOW Anywhere ← REDIS AÇIK! 8080/tcp ALLOW Anywhere ← GEREKSİZ! 3306/tcp ALLOW Anywhere ← MYSQL AÇIK!
Redis (6379), MySQL (3306) ve bir development sunucusu (8080) dışarıya açıktı. Sadece 22, 80 ve 443’in açık olması gerekirdi.
Çözüm:
ufw deny 6379 ufw deny 3306 ufw deny 8080 ufw reload
Kural: Dışarıya sadece ihtiyacınız olan portları açın. Her açık port, potansiyel bir saldırı yüzeyidir.
Unutulan Ayar #3: SSH Banner Bilgisi
SSH sunucunuz versiyon ve işletim sistemi bilgisi sızdırır. Saldırgan bu bilgiye göre exploit arar:
# Saldırgan şu komutla bilgimizi görebilir: nc sunucum.com 22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
Bu satır SSH versiyonumu ve işletim sistemimi gösteriyor — tam olarak saldırganın bilmesi gereken her şey.
Çözüm:
# /etc/ssh/sshd_config dosyasında: Banner none DebianBanner no
Banner’ı kapatın ve sürüm bilgisini gizleyin. Bu “security by obscurity” değildir — bilgi sızdırmamaktır.
Unutulan Ayar #4: Otomatik Güvenlik Güncellemeleri
Ben paket güncellemelerini manuel yapıyordum ve bazen haftalar atlıyordum. Ama güvenlik güncellemeleri gecikmemeli — çoğu saldırı eski, yamalanmış açıklardan yararlanıyor.
# Otomatik güvenlik güncellemelerini aktif edin: apt install unattended-upgrades dpkg-reconfigure -plow unattended-upgrades # "Yes" seçin
Artık güvenlik güncellemeleri otomatik yükleniyor. Benim sunucumda bu ayar kapalıydı ve 3 aylık güvenlik yaması yüklenmemişti.
Unutulan Ayar #5: Log İzleme Yok
Saldırganın izini /var/log/auth.log dosyasında buldum — 200’den fazla başarısız deneme, sonra bir başarılı giriş. Ama bunu saldırı anında görmedim çünkü log izleme sistemim yoktu.
Çözüm — Logwatch kurun:
apt install logwatch # Her gün özet rapor e-posta ile gelsin: ln -s /usr/share/logwatch/scripts/logwatch.pl /etc/cron.daily/00logwatch
Veya CrowdSec kurun — saldırıları otomatik tespit edip engeller. Ben şimdi CrowdSec kullanıyorum ve çok memnunum.
Sunucu Güvenlik Kontrol Listesi
| Ayar | Durum | Öncelik |
|---|---|---|
| SSH key ile giriş (şifre kapalı) | ✅ Vardı | Kritik |
| Fail2Ban / CrowdSec | ✅ Vardı | Kritik |
| UFW Firewall aktif | ✅ Vardı | Kritik |
| Gereksiz portlar kapalı | ❌ Unutulmuş | Kritik |
| Redis şifreli ve localhost | ❌ Unutulmuş | Kritik |
| SSH banner gizli | ❌ Unutulmuş | Orta |
| Otomatik güvenlik güncellemesi | ❌ Unutulmuş | Yüksek |
| Log izleme / alarm | ❌ Unutulmuş | Yüksek |
| Root login kapalı | ✅ Vardı | Kritik |
| Swap kullanımı limitli | ❌ Unutulmuş | Düşük |
10 maddede 6’sı eksikti. Yani %60 güvenlik açığım vardı. “Güvenli” sandığım sunucu aslında yarım önlemlerle korunuyordu.
Sıkça Sorulan Sorular
Sunucumun güvenliğini nasıl test ederim?
Ücretsiz araçlarla tarayın: nmap ile açık portları bulun, ss -tulpn ile dinlenen servisleri kontrol edin, lynis audit system ile kapsamlı güvenlik denetimi yapın. Ben şimdi ayda bir Lynis çalıştırıyorum.
SSH key yeterli mi?
SSH key iyi bir başlangıç ama tek başına yeterli değil. Port değiştirme (22’den başka), root login kapama, fail2ban ve 2FA (Google Authenticator) ile birlikte kullanın. Ben 4 katmanlı SSH güvenliği kullanıyorum.
Sunucu her güncellenmeli mi?
Güvenlik güncellemeleri hemen, feature güncellemeleri test ederek. Ben otomatik güvenlik güncellemesi açtım ama major versiyon güncellemelerini önce test sunucusunda deniyorum.
Hangi portlar dışarıya açık olmalı?
Minimum: 22 (SSH), 80 (HTTP), 443 (HTTPS). Başka bir şeye ihtiyacınız yoksa açmayın. Veritabanı, cache ve internal servisler sadece localhost’tan erişilebilir olmalı.
Sonuç
Sunucum hacklendi ve bunun sebebi sıfır-day exploit değil, benim unuttuğum temel ayarlardı. Redis şifresiz, gereksiz portlar açık, log izleme yok… Hepsini tek tek düzelttim ve şimdi sunucum çok daha güvenli.
Eğer siz de bir sunucu yönetiyorsanız, yukarıdaki kontrol listesini gözden geçirin. %90 ihtimalle en az bir unutulan ayar bulacaksınız. Düzeltmek 10 dakika, hacklenip temizlemek 3 gün sürer — ben yaşadım.
