Bu rehber neyi çözer?
Linux güvenliği tek bir script değildir; patch, kimlik, ağ, servis azaltma, MAC politikaları, loglama ve backup katmanlı uygulanmalıdır.
Patch ve paketler
Güvenlik güncellemeleri düzenli uygulanmalı, gereksiz paket ve repository sayısı azaltılmalıdır.
Otomatik update varsa reboot ve bakım penceresi politikası ayrıca yönetilmelidir.
SSH ve ayrıcalık
Doğrudan root login yerine kişisel hesap + sudo ve mümkünse SSH key/certificate tercih edilmelidir.
MFA, bastion ve kaynak IP kısıtı risk profiline göre eklenebilir.
Firewall ve servis yüzeyi
Yalnız gerekli portlar açılmalı ve kullanılmayan servisler kapatılmalıdır.
Host firewall ağ firewall’unun yerine değil ek katman olarak kullanılmalıdır.
AppArmor / SELinux
Mandatory Access Control uygulama ele geçirilse bile erişim alanını sınırlayabilir.
Sorunlarda kapatmak yerine audit log ile policy düzeltmek daha güvenlidir.
Loglama
Auth, sudo, servis ve kritik değişiklik logları merkezi sisteme aktarılmalıdır.
Saat senkronizasyonu ve retention incident response için önemlidir.
Sık Sorulan Sorular
Linux antivirüssüz güvenli midir?
Hayır. İhtiyaç workload ve dosya akışına bağlıdır; bazı sunucularda malware taraması gerekli olabilir.
SSH portunu değiştirmek yeterli mi?
Hayır. Tarama gürültüsünü azaltabilir ama güçlü kimlik, firewall ve patch yerine geçmez.
SELinux/AppArmor kapatılmalı mı?
Genellikle hayır. Policy/log analiziyle sorun çözmek daha güvenlidir.
Kaynaklar ve teknik referanslar
Linux Sunucu Projenizi Değerlendirelim
Mevcut Windows/Linux rollerinizi, uygulama bağımlılıklarını ve geçiş hedeflerinizi birlikte değerlendirebiliriz.
Mimari ve çalışma modeli
Hardening servis azaltma, kimlik, patch, ağ, dosya izinleri ve MAC politikalarını birleştirir. Bir benchmark kontrolünü anlamadan bütün sunuculara aynı şekilde uygulamak uygulamayı bozabilir. SSH yönetimi, acil erişim ve log görünürlüğü korunmalıdır. SELinux veya AppArmor uyarısının çözümü kontrolü kalıcı kapatmak değil dar kapsamlı politika incelemesidir.
- 1Envanter ve baseline
- 2Kimlik/servis/ağ daraltma
- 3MAC ve loglama
- 4Reboot ve iş testi
Tasarım parametreleri
- Saldırı yüzeyi
- Dinleyen servis, yönetim portu ve gereksiz paketleri rol ihtiyacına göre azaltın; servis listesini başlangıç kaydı yapın.
- Yetki ve zorunlu kontrol
- Sudo, SSH anahtarı ve SELinux/AppArmor kapsamını ayrı test edin; hatayı genel root yetkisiyle gizlemeyin.
- Servis ve kullanıcı
- Gerçek servis kullanıcısını, grup üyeliğini, çalışma dizinini ve gerekli yetkileri listeleyin. Root ile başarılı test sınırlı hesapla çalışmayı kanıtlamaz.
- Depolama ve kalıcılık
- Mount, dosya sistemi, inode ve kalıcı veriyi birlikte kontrol edin. Yeniden başlatma ve yeniden oluşturma aynı test değildir.
- Ağ ve güvenlik katmanı
- Dinlenen arayüz, firewall, TLS ve SELinux/AppArmor politikalarını ayırın. Bir katmandaki engel başka katmanın ayarıyla çözülmez.
- Paket ve işletim yöntemi
- Sürüm, depo, güncelleme yöntemi ve servis bağımlılıklarını belgeleyin. Bakım sonrası reboot ve uygulama doğrulamasını planlayın.
Hesap ve uygulama örneği
Örnek pilotta yalnız gerekli servisler dinlesin; yönetim ağı dışından SSH reddedilsin. Uygulama servis kullanıcısıyla yazabilsin fakat başka dizinleri okuyamasın. Bir değişiklikten sonra reboot ve uygulama testi yapın. Acil erişim yolunu doğrulamadan uzaktan yönetimi kapatmayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Hardening sonrası servis başlamıyor | Dosya erişimi, capability veya güvenlik politikası engeli olabilir. | Journal ve denetim kaydını servis kimliğiyle inceleyip dar kapsamlı düzeltin. |
| Servis aktif ama yanıt vermiyor | Process sağlığı, port dinleme ve uygulama sağlığı farklı kontrollerdir. | Yerel sağlık kontrolünü uzak istemci isteğiyle karşılaştırın; log ve bağımlılık durumunu inceleyin. |
| Dosya yazılamıyor | İzin, ACL, read-only mount, inode veya disk doluluğu etkili olabilir. | Servis kimliğiyle dizin zincirini ve mount durumunu doğrulayın; izinleri topluca açmayın. |
| Reboot sonrası yapılandırma kayboldu | Geçici mount, runtime ayarı veya yanlış yapılandırma kaynağı kullanılmış olabilir. | Kalıcı ayarı ve açılış sırasını kontrol edin; temiz reboot testini tekrarlayın. |
Kabul ve doğrulama kontrolleri
- Sertleştirme sonrası uygulama, log ve acil erişimin birlikte çalıştığını doğrulayın.
- Servisi tanımlanan sınırlı kimlikle çalıştırıp temel iş akışını test edin.
- Reboot sonrasında mount, ağ, zaman ve uygulama durumunu doğrulayın.
- Yapılandırma, veri ve anahtarları ayrı kurtarma kalemleri olarak kaydedin.
- Güncellemeden önce ve sonra aynı sağlık testini çalıştırın.
- Ayrı hedefe geri yükleyerek platform bağımlılıklarını doğrulayın.
İlgili kavramlar
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.