Bir Linux sunucunun saldırıya açık hale gelmesi çoğu zaman sıfır gün açığından değil, varsayılan ayarlardan, unutulmuş servislerden veya gereğinden geniş yetkilerden kaynaklanır. Bu nedenle Linux sunucu güvenlik kontrol listesi, kurulumdan sonra bir kez uygulanacak statik bir belge değil; operasyonun her aşamasında tekrar edilen bir disiplin olmalıdır. E-ticaret, SaaS, ajans projeleri ve kurumsal uygulamalarda güvenlik doğrudan erişilebilirlik, müşteri güveni ve gelir sürekliliği anlamına gelir.

Linux Sunucu Güvenlik Kontrol Listesi Neden Operasyoneldir?

Sunucuda yüksek CPU gücü, NVMe depolama veya DDoS filtreleme kapasitesi tek başına yeterli değildir. Altyapı katmanı saldırı trafiğini filtreleyebilir, fakat uygulama seviyesindeki zayıf parola, açık yönetim paneli ya da güncel olmayan paketler sistemin içine davetiye çıkarabilir. Güvenliğin etkili olması için veri merkezi, ağ, işletim sistemi, uygulama ve insan süreçleri birlikte ele alınmalıdır.

Kontrol listesinin amacı her portu kapatmak ya da her kullanıcıyı kısıtlamak değildir. Hedef, sunucunun iş yükü için gerekli olan erişimi korurken gereksiz saldırı yüzeyini azaltmaktır. Örneğin sadece özel ağdan kullanılan bir veritabanı portunun internete açık olması risk yaratır; ancak dış müşterilere API hizmeti veren bir uygulamada 443 numaralı portun erişilebilir kalması iş gereğidir.

1. Root Erişimini Doğrudan Kullanmayın

Root hesabı sınırsız yetkiye sahiptir. Günlük yönetim işlerinde doğrudan root ile oturum açmak, hem yanlış komutların etkisini büyütür hem de hangi işlemi kimin yaptığını izlemeyi zorlaştırır. Her yönetici için ayrı kullanıcı oluşturun ve yalnızca gerekli komutlara `sudo` yetkisi verin.

SSH yapılandırmasında `PermitRootLogin no` ayarı, parola tahminine dayalı saldırıların en değerli hedefini kapatır. Acil müdahale senaryolarında root erişimine ihtiyaç duyuluyorsa, bunu parola yerine kontrollü konsol erişimi ve güçlü kimlik doğrulama süreçleriyle yönetin.

2. SSH Parolasını Anahtar Tabanlı Erişimle Değiştirin

SSH, Linux sunucuların en sık hedeflenen servislerinden biridir. Karmaşık bir parola faydalıdır, ancak anahtar tabanlı giriş daha güçlü ve yönetilebilir bir model sunar. Kullanıcının açık anahtarını `authorized_keys` dosyasına ekledikten sonra `PasswordAuthentication no` ayarını etkinleştirin.

Bu değişikliği yapmadan önce ikinci bir SSH oturumunda anahtarla giriş testini mutlaka tamamlayın. Aksi halde hatalı izinler veya yanlış anahtar nedeniyle kendi sunucunuza erişiminizi kesebilirsiniz. Anahtarların da bir yaşam döngüsü vardır: ekipten ayrılan personelin anahtarı gecikmeden kaldırılmalı, paylaşılan anahtar kullanımı ise mümkün olduğunca önlenmelidir.

3. SSH Erişimini Kaynak IP ile Sınırlandırın

SSH portunu değiştirmek bot taramalarını azaltabilir, fakat tek başına güvenlik kontrolü değildir. Asıl koruma, erişimi belirli ofis IP'leri, VPN ağı veya yönetim ağı ile sınırlandırmaktır. UFW, firewalld veya nftables üzerinde SSH için yalnızca ihtiyaç duyulan kaynaklara izin verin.

Dinamik IP kullanan uzaktan ekiplerde VPN üzerinden yönetim daha doğru bir tercihtir. Böylece internete açık SSH erişimini daraltır, erişim kayıtlarını merkezi biçimde tutar ve ekip büyüdükçe kuralları daha kontrollü yönetirsiniz.

4. Güncellemeleri Düzenli ve Kontrollü Uygulayın

İşletim sistemi paketleri, kernel, web sunucusu, PHP, Python bağımlılıkları ve veritabanı yazılımları ayrı ayrı risk oluşturabilir. Güvenlik güncellemelerini aylarca ertelemek, bilinen açıkların istismar edilmesi için uzun bir fırsat penceresi bırakır.

Bununla birlikte her güncellemeyi doğrudan canlı ortama geçirmek de doğru yaklaşım değildir. Kritik uygulamalarda önce staging ortamında test edin, bakım penceresi belirleyin ve geri dönüş planı hazırlayın. Otomatik güvenlik güncellemeleri düşük riskli sistemlerde yükü azaltabilir; sürücü, kernel veya uygulama bağımlılığı hassas olan üretim sunucularında ise onaylı dağıtım süreci daha güvenlidir.

5. Gereksiz Servisleri ve Açık Portları Kaldırın

Sunucuda çalışmayan her servis potansiyel bir saldırı noktasıdır. `systemctl list-unit-files --state=enabled` komutuyla açılışta çalışan servisleri inceleyin. Eski FTP hizmetleri, kullanılmayan mail daemon'ları, test panelleri veya unutulmuş geliştirme araçları genellikle gereksiz risk taşır.

Ayrıca `ss -tulpn` ile dinleyen portları kontrol edin. Beklemediğiniz bir port görüyorsanız önce hangi uygulamanın açtığını belirleyin, ardından iş gereksinimini doğrulayın. Bir servisi sadece firewall ile engellemek yerine, kullanılmıyorsa durdurmak ve devre dışı bırakmak daha temiz bir güvenlik sonucudur.

6. Firewall Politikasını Varsayılan Reddetme Mantığıyla Kurun

Firewall kuralı "her şeye izin ver, sorun olursa kapat" anlayışıyla yönetilmemelidir. Gelen trafiği varsayılan olarak reddedip yalnızca gerekli portlara izin vermek daha güvenli bir başlangıçtır. Tipik bir web sunucusunda 80 ve 443, yönetim için kısıtlı SSH erişimi yeterli olabilir.

Veritabanı, Redis, Elasticsearch ve benzeri servisler çoğu projede kamuya açık olmamalıdır. Uygulama ile aynı sunucuda çalışıyorsa yalnızca localhost'a bağlanacak şekilde yapılandırın. Ayrı sunucularda çalışıyorsa private network, güvenlik grubu veya kaynak IP bazlı kurallar kullanın. Bu detay özellikle müşteri verisi işleyen uygulamalarda kritik fark yaratır.

7. Fail2ban ve Oran Sınırlama ile Kaba Kuvveti Azaltın

Fail2ban, log dosyalarındaki başarısız giriş denemelerini takip eder ve belirlenen eşiği aşan IP adreslerini geçici olarak engeller. SSH için etkili bir ek savunmadır; ayrıca web paneli, SMTP veya uygulama giriş sayfalarının loglarına uygun filtreler eklenebilir.

Yine de Fail2ban'ı hesap güvenliğinin yerine koymayın. Saldırganlar dağıtık IP ağları kullanabilir. Uygulama katmanında login denemeleri için rate limiting, CAPTCHA gereksinimi veya çok faktörlü kimlik doğrulama gibi kontroller de devreye girmelidir.

8. Dosya İzinlerini ve Gizli Verileri Denetleyin

`.env` dosyaları, API anahtarları, SSH private key'leri, veritabanı parolaları ve yedek dosyaları yanlış izinlerle bırakıldığında en güçlü firewall bile yeterli olmaz. Uygulama kullanıcısının sadece ihtiyaç duyduğu dizinlere yazabildiğinden emin olun. Web sunucusunun tüm proje dizinine yazma yetkisi olması, dosya yükleme açığı yaşandığında zararı büyütür.

Gizli bilgileri Git deposuna koymayın ve deploy süreçlerinde loglara yazdırmayın. Anahtar sızıntısı şüphesinde yalnızca ilgili dosyayı kaldırmak yeterli değildir; anahtarı geçersiz kılıp yeni kimlik bilgisi üretmek gerekir. Düzenli secret rotasyonu, özellikle birden fazla geliştiricinin eriştiği projelerde güçlü bir alışkanlıktır.

9. Yedekleri Şifreleyin ve Geri Dönüş Testi Yapın

Yedek almak, yedeğin çalıştığını kanıtlamaz. Veritabanı dump'ı alınmış olabilir fakat dosya ekleri eksik kalmış olabilir; yedek dosyası oluşmuş olabilir fakat bozuk olabilir. Bu yüzden belirli aralıklarla izole bir ortamda geri yükleme testi yapın ve uygulamanın beklenen şekilde ayağa kalktığını doğrulayın.

Yedekleri üretim sunucusuyla aynı disk üzerinde tutmak gerçek bir felaket senaryosunda koruma sağlamaz. En az bir kopyayı ayrı depolama alanında saklayın, erişimi sınırlandırın ve hassas verileri şifreleyin. Saklama süresi, yasal yükümlülükler ve işin kabul edebileceği veri kaybı süresiyle uyumlu belirlenmelidir.

10. Logları Merkezi ve Anlamlı Biçimde İzleyin

Yetkisiz giriş denemeleri, sudo kullanımı, disk doluluğu, bellek baskısı, servis yeniden başlatmaları ve anormal ağ trafiği birbirinden kopuk loglarda kaybolmamalıdır. En azından `auth.log`, web sunucusu erişim logları, uygulama hata kayıtları ve sistem günlükleri düzenli incelenmelidir.

Alarm eşiğini doğru ayarlamak burada belirleyicidir. Her başarısız SSH denemesinde alarm üretmek ekipte alarm yorgunluğu yaratır. Buna karşılık kısa süre içinde çok sayıda başarısız giriş, yeni bir ülkeden yönetici oturumu veya aniden artan 5xx hataları doğrudan aksiyon gerektiren sinyallerdir.

11. DDoS Korumasını Uygulama Güvenliğiyle Karıştırmayın

DDoS koruması, hizmetinize ulaşmaya çalışan yoğun ve kötü niyetli trafiği filtreleyerek erişilebilirliği korur. Özellikle Türkiye lokasyonlu müşterilere hizmet veren e-ticaret ve oyun projelerinde düşük gecikme ile saldırı dayanıklılığını aynı anda sağlamak operasyonel avantajdır. Vode Host gibi Tier III veri merkezi, yedekli altyapı ve saldırı filtreleme katmanı sunan bir sağlayıcı bu savunmada güçlü bir temel oluşturur.

Ancak DDoS koruması SQL injection, zayıf yönetici parolası veya güvenlik açığı bulunan eklenti gibi uygulama sorunlarını çözmez. Ağ koruması ile sunucu sertleştirme süreçlerini ayrı ama tamamlayıcı katmanlar olarak planlayın.

12. Olay Müdahale Planını Saldırıdan Önce Yazın

Bir olay anında kimin karar vereceği, hangi erişimlerin kapatılacağı, müşteriye ne zaman bilgi verileceği ve hangi logların korunacağı önceden belirlenmelidir. İlk refleks olarak sunucuyu kapatmak bazen doğru olabilir, bazen de kanıtları ve hizmet sürekliliğini olumsuz etkileyebilir. İş yükünün kritikliğine göre izolasyon, snapshot alma, erişim anahtarlarını yenileme ve temiz yedekten dönüş adımlarını belgeleyin.

Bu planı yalnızca sistem yöneticisinin bilgisinde tutmayın. Uygulama sahibi, operasyon sorumlusu ve destek ekibi rollerini bilmeli; erişim bilgileri ise güvenli bir parola kasasında güncel kalmalıdır. Güvenlikte hız, hazırlıktan gelir.

Linux sunucunuzdaki her açık port, her yetki ve her entegrasyon için şu soruyu düzenli olarak sorun: Bu erişim hâlâ gerçekten gerekli mi? Bu soruya verilen net cevaplar, en pahalı güvenlik aracından bile daha değerli bir savunma çizgisi oluşturabilir.

Linux Sunucu Güvenlik Kontrol Listesi: 12 Adım