60 saniyede Linux sertleştirme
Bir Linux sertleştirme (hardening) denetimi sıklıkla iç rahatlatıcı bir sayı ile sonuçlanır: Paket listesi kısalmış, birkaç kernel parametresi güncellenmiş ve hardening index skoru yükselmiştir. Bu sayı yapılan emeği izleyebilir; ancak dışarıya açık bir servisin hâlâ root haklarıyla çalışıp çalışmadığını, tek bir yönetici hesabının tüm sunucu havuzunda (fleet) yeniden kullanılıp kullanılamayacağını, ele geçirilmiş bir sürecin bir kimlik bilgisine erişip erişemeyeceğini ya da sistemin bir sonraki yeniden başlatmadan (reboot) sağ çıkıp çıkamayacağını gösteremez.
Bu fark, bu metodolojinin ana konusudur. Lynis aracını geniş kapsamlı yerel bir sensör olarak; The Practical Linux Hardening Guide rehberini ise mantıksal gerekçeler, politika aileleri ve sorular kataloğu olarak kullanıyorum. Bu kaynakların hiçbiri otomatik bir düzeltme motoruna dönüşmez. Nihai karar sunucunun rolünden, mevcut platformdan, dışa açılan yetkiden, operasyonel bağımlılıklardan ve orijinal güvenlik iddiasının yeniden test edilmesinden gelir.
Temel kural basittir:
Bir sertleştirme değişikliği, ancak hedeflenen iş yükü hâlâ sorunsuz çalışırken ve bu değişikliğe neden olan tehlikeli davranış artık engellendiğinde tamamlanmış sayılır.
Bu not kaynakları gözden geçirilmiş bir metodolojidir; gizli bir kıyaslama sonucu değildir. Öncesi ve sonrası şeklinde bir Lynis skoru yayımlamaz veya aşağıdaki üç durumlu deneyin önceden çalıştırıldığını iddia etmez. Protokol, gelecekteki bir laboratuvar kaydının uydurma kanıtlar etrafında sonucu yeniden yazmadan bu ölçümleri ekleyebileceği şekilde tasarlanmıştır.
Puan bir gözlemdir, nihai sonuç değil
Lynis, tam da birçok alt sisteme aynı anda baktığı için değerlidir: önyükleme yapılandırması, kernel ayarları, kimlik doğrulama, kabuklar (shells), dosya sistemleri, depolama, ağ, paket durumu, günlük kaydı (logging), zamanlayıcılar, servis yapılandırması ve sertleştirme özellikleri. Her teste kararlı bir tanımlayıcı atar, teknik detayları /var/log/lynis.log dosyasına kaydeder ve makine tarafından okunabilir bulguları /var/log/lynis-report.dat dosyasına yazar.
Aracın kendi dokümantasyonu bu önemli sınırı net bir şekilde çizer: Bir OK sonucu hedefin güvenli olduğunu kanıtlamaz; bir WARNING sonucu da otomatik olarak bir güvenlik açığı değildir. Öneriler yalnızca potansiyel iyileştirme alanlarını ifade eder. Uygulanabilirlik ve etki değerlendirmesi denetçinin sorumluluğundadır.
Hardening index de aynı sınıra sahiptir. Lynis’in test ettiği kontrolleri ve mevcut profilin bunları nasıl puanladığını özetler. Ancak sunucunun eksiksiz iş rolünü, uygulamanın taşıdığı güven düzeyini, bir yönetim arayüzünün erişilebilirliğini, sisteme bağlı bir sırrın hassasiyetini veya sunucuyu çevreleyen kurtarma (recovery) sürecini bilemez.
Bu nedenle iki sistem benzer skorlara sahip olup tamamen farklı risk profilleri taşıyabilir:
- Dar bir servis yetkisine ve test edilmiş bir yeniden derleme (rebuild) yoluna sahip, dışa açık bir reverse proxy;
- Yeniden kullanılabilir bir deployment anahtarına, geniş sudo erişimine ve sunucu havuzu genelinde ayrıcalıklı kurtarma işlemleri çalıştırabilen bir yedekleme ajanına sahip bir dahili yönetim sunucusu.
İkinci sunucu daha az port dinliyor olabilir; ancak çok daha fazla yetki taşır.
Tarayıcıyla değil, sunucu rolüyle başlayın
İlk taramadan önce bir sayfalık bir “sunucu sözleşmesi” (host contract) oluşturun. Bu sözleşme tamamlanamıyorsa sertleştirme incelemesi henüz neyi koruduğunu bilmiyor demektir.
| Soru | Kaydedilecek kanıt |
|---|---|
| Sunucu ne iş yapar? | Servis sahibi, iş yükü, veri sınıfı, erişilebilirlik hedefi |
| Sunucuya kimler erişebilir? | Beklenen kaynak ağlar, kamuya açıklık, yönetim rotası |
| Sunucu hangi kimliklere güvenir? | İnsan yöneticiler, servis kullanıcıları, iş yükü kimlikleri, SSH süjeleri |
| İş yükü neleri kontrol edebilir? | Dosyalar, soketler, veritabanları, bulut API’leri, orkestrasyon veya yedekleme sistemleri |
| Sunucu nasıl yeniden kurulur? | İmaj veya yapılandırma kaynağı, paket kaynağı, geri yükleme bağımlılıkları |
| Hangi olay asla gerçekleşmemelidir? | Tanımlanmış yetkisiz işlem, kimlik bilgisi erişimi, ayrıcalık geçişi veya veri sızıntı rotası |
Bu sözleşme, genel bir Lynis önerisini bilinçli bir karara dönüştürür. Tek kullanımlık bir derleme sunucusundaki (build worker) bir derleyicinin (compiler) anlamı ile değişmez (immutable) bir prodüksiyon cihazındaki derleyicinin anlamı tamamen farklıdır. İkinci bir DNS sunucusu kritik bir sunucu için zorunlu olabilirken, izole tek amaçlı bir laboratuvar makinesi için anlamsız kalabilir. Meşru olarak ağ ve cihaz erişimine ihtiyaç duyan bir servis, yalnızca maruz kalma puanını düşürmek uğruna genel bir sandbox profiline zorlanmamalıdır.
Aynı kural harici baseline’lar için de geçerlidir. CIS Benchmarks, belirli ürünler ve sürümler için uzlaşıya dayalı yapılandırma önerileridir. OpenSCAP açık SCAP içeriklerini ve profillerini değerlendirir. trimstray rehberi faydalı açıklamalar ve operasyonel uyarılar sunar; ancak kendi README dosyasında bunun kapsamlı bir standarttan ziyade bir kontrol listesi olduğunu ve örneklerinin RHEL 7 ile CentOS 7 etrafında inşa edildiğini açıkça belirtir.
Mantığı ve muhakemeyi benimseyin. Kullanılan platform sürümüne tam uyan güncel içerikleri seçin. Sırf kulağa güvenli geliyor diye eski bir kontrolü modern bir sunucuya asla kopyalamayın.
Tekrarlanabilir bir baseline saklayın
İlk çalıştırma sıkıcı, salt okunur ve kaynakları doğrulanabilir olmalıdır. Prodüksiyon ortamını değiştirmeden önce tek kullanımlık bir laboratuvar klonu veya onaylanmış bir test sunucusu kullanın. Tam dağıtım sürümünü, kernel’ı, Lynis sürümünü, aktif profili, sanallaştırma bağlamını, çalışan servisleri, dinleyen soketleri, bağlama noktalarını (mounts) ve paket kaynaklarını kaydedin.
Aşağıdaki komutlar yapılandırmayı değiştirmeden yerel bir baseline toplar:
uname -a
cat /etc/os-release
systemd-detect-virt
lynis show version
lynis show profiles
lynis show settings
ss -lntup
systemctl --type=service --state=running --no-pager
findmnt -rn -o TARGET,SOURCE,FSTYPE,OPTIONSDenetimi güvenilir bir paketten veya incelenmiş bir repodan çalıştırın. Standart sistem denetimi şöyledir:
sudo lynis audit system --quick --nocolors --auditor "controlled-hardening-baseline"Lynis detaylı logunu bir sonraki taramada temizler. Kanıtları denetlenen sunucuda, kısıtlı bir çalışma dizininde derhal koruma altına alın:
case_dir="/var/tmp/linux-hardening-case-001/baseline"
sudo install -d -m 0700 "$case_dir"
sudo cp --preserve=timestamps /var/log/lynis.log "$case_dir/"
sudo cp --preserve=timestamps /var/log/lynis-report.dat "$case_dir/"
sudo sha256sum "$case_dir/lynis.log" "$case_dir/lynis-report.dat" |
sudo tee "$case_dir/SHA256SUMS" >/dev/nullBu dosyalar hostname’leri, paket envanterini, servisleri, dosya sistemi yollarını ve politika durumlarını ifşa edebilir. Orijinal dosyaları test kanıt sınırları içinde tutun. Asla bir müşteri veya prodüksiyon sunucusunun ham raporunu olduğu gibi yayımlamayın; yalnızca sansürlenmiş (redacted) türevlerini paylaşın.
Her öneriyi bir hipoteze dönüştürün
İş listesini yalnızca uyarı ve öneri ayrımına veya hardening index puanına göre sıralamayın. Eksik olan operasyonel alanları ekleyin:
- Gözlem: Test gerçekte ne gördü?
- Uygulanabilirlik: Beklenen durum bu platform ve rol için geçerli mi?
- Yetki: Bu durum nedeniyle hangi ek eylem mümkün hale geliyor?
- Erişilebilirlik: Bu eylem hangi gerçekçi kaynaktan denenebilir?
- Bileşim: Saldırı yolunu hangi kimlik bilgisi, servis, mount, soket veya yönetim düzlemi tamamlıyor?
- Değişiklik riski: Yapılacak düzeltme hangi meşru işlevi bozabilir?
- Güvenlik testi: Sonrasında tam olarak hangi eylem başarısız olmalıdır?
- Pozitif kontrol: Hangi iş yükü eylemi başarıyla çalışmaya devam etmelidir?
- Geri alma (Rollback): Pozitif kontrol başarısız olursa ekip sistemi nasıl eski haline getirecek?
Bu yaklaşım tek bir uzun liste yerine dört ayrı kuyruk oluşturur:
- Saldırı yolunu kesen kontroller: Erişilebilir ayrıcalığı, dışa açılan yetkiyi veya kimlik bilgisi erişimini ortadan kaldırır;
- Dayanıklılık (Resilience) kontrolleri: Tespiti, bütünlüğü, kurtarmayı ve güvenli çalışmayı geliştirir;
- Baseline yükümlülükleri: Doğrudan saldırı yolu etkisi sınırlı olsa bile güvenlik politikası gereği zorunludur;
- Kabul edilmiş istisnalar: Tanımlanmış bir gerekçeye, sahibe, telafi edici kontrole ve son kullanma tarihine sahiptir.
Bir istisna sessizce göz ardı etmek değildir. Kanıtın resmi bir parçasıdır.
Yetkiyi değiştiren kontrollere öncelik verin
Kesin sıralama sunucu sözleşmesine bağlıdır; ancak aşağıdaki iş sırası genellikle biçimsel bulgularla başlamaktan çok daha sağlıklı kararlar üretir:
1. Erişilebilir yüzeyi daraltın
Dinleyen soketleri ve her birinin arkasındaki süreci, namespace’i, arayüzü ve güvenlik duvarı yolunu envanterleyin. Gereksiz servisleri kaldırın veya yerel arayüze bağlayın (bind). Değişikliği hem onaylanmış harici bir kaynaktan hem de yerel soket tablosundan doğrulayın. Kapatılmış yerel bir süreç ile filtrelenmiş bir ağ yolu farklı kontrollerdir; hangisinin değiştiğini açıkça kaydedin.
2. Yönetimsel kimliği daraltın
Kimlerin kimlik doğrulayabildiğini, kimlerin sudo kullanabildiğini, hangi komutlara izin verildiğini, SSH anahtarlarının nerede yetkilendirildiğini ve otomasyonun insanlarla aynı kimliği paylaşıp paylaşmadığını listeleyin. İsimlendirilmiş süjeleri, dar komut yetkilendirmesini, kısa ömürlü kimlik bilgilerini ve bağımsız olarak test edilmiş bir acil durum (break-glass) rotasını tercih edin. Kanıt paketine asla özel anahtarları, parola hash’lerini veya gizli değerleri yazdırmayın.
3. Yalnızca kullanıcı hesabını değil, servisi de sınırlandırın
Root olmayan bir Unix kullanıcısı kullanmak iyi bir sınırdır; ancak servis hâlâ geniş dosya sistemi, aygıt, ağ, Linux yetenekleri (capabilities) ve IPC erişimini devralıyor olabilir. systemd servisleri için systemd-analyze security komutu eksik sandbox direktiflerini tespit edebilir ve bir maruz kalma puanı üretebilir. Kılavuzunda, servisin IPC üzerinden başka süreçlerden işlem talep edebildiği durumlarda bu analizin eksik kalacağı açıkça belirtilir. Bu sonucu da bir muhafaza kanıtı değil, başka bir aday olarak değerlendirin.
Servisin gerçek ihtiyaçlarıyla başlayın: yazılabilir yollar, adres aileleri, aygıtlar, capability’ler, sistem çağrıları (syscalls), geçici depolama, home dizinleri ve kernel arayüzleri. Bir laboratuvar veya canary ortamında her seferinde tek bir kısıtlama ekleyin, servisi yeniden başlatın, pozitif kontrolü çalıştırın ve logları inceleyin.
4. Kimlik bilgilerini ve süreç sınırlarını koruyun
Hangi dosyaların, ortam değişkenlerinin (environment variables), ajanların, soketlerin, core dump’ların ve aynı kullanıcı süreçlerinin kimlik bilgilerini ifşa edebileceğini sorgulayın. Linux Yama LSM dokümantasyonu, kısıtlanmamış aynı UID’li ptrace çağrısının, ele geçirilmiş bir uygulamanın başka bir süreci denetlemesine ve SSH oturumlarına veya kimlik bilgisi ajanlarına sıçramasına nasıl izin verebileceğini açıklar. Daha katı bir ptrace_scope ayarının uygun olup olmadığı hata ayıklama, gözlemlenebilirlik (observability), kilitlenme işleme ve platformun mevcut politikasına bağlıdır.
Bir sysctl ayarının pozitif bir kontrol olmadan bir listeden asla kopyalanmaması gerektiğinin nedeni budur. Olay müdahale uzmanını, profilleyiciyi (profiler) veya crash toplayıcıyı engelleyen bir değişiklik, bir rolde güvenliyken başka bir rolde operasyonel olarak yıkıcı olabilir.
5. Tespit ve kurtarmayı sertleştirme durumunun bir parçası yapın
Paket kaynağı güvenilirliği, zaman senkronizasyonu, denetim (audit) kapsamı, log yönlendirme, dosya bütünlüğü, yapılandırma geçmişi ve test edilmiş yeniden derleme talimatları gelecekteki bir ihlalin sınırlandırılıp sınırlandırılamayacağını belirler. Hiçbir gereksiz servisi olmayan ancak güvenilir bir yeniden inşa kaynağı bulunmayan bir sistem tamamlanmış sayılmaz.
NIST’in sunucu güvenliği kılavuzu sertleştirmeyi bir yaşam döngüsünün parçası olarak tanımlar: planla, yapılandır, sürdür, izle ve müdahale etme kabiliyetini koru. Bu nedenle operasyonel birim tek bir andaki tek bir sunucu değildir. Sunucunun kendisi, yönetim düzlemi, kanıtları ve kurtarma yoludur.
Üç durumlu deneyi çalıştırın
Desteklenen bir Linux sürümünün tek kullanımlık bir klonunu kullanın ve ona gerçekçi bir iş yükü verin — örneğin OpenSSH ve systemd tarafından yönetilen küçük bir HTTP servisi. Değişikliklerden önce snapshot alın. Ağı onaylanmış laboratuvarda izole tutun ve ayrılmış kimlikler ile test verileri kullanın.
Durum A — Baseline
Sunucu sözleşmesini, yerel envanteri, Lynis çıktısını, servis sağlığını, erişilebilir soketleri, mevcut yönetim yolunu ve yeniden derleme süresini kaydedin. Sınırlandırılmış tek bir güvenlik iddiası tanımlayın:
İDDİA Web servisi, onaylanmış durum dizini dışına yazma işlemi yapamaz
KAYNAK Onaylı laboratuvar arayüzü üzerinden kontrollü bir istek
SÜJE Laboratuvar için oluşturulmuş servis hesabı
KORUNAN VARLIK Yazılabilir yolun dışındaki root sahipliğindeki bir canary dosyası
POZİTİF KONTROL Servis beklenen uygulama durumunu başarıyla yazar
NEGATİF KONTROL Servis korunan canary dosyasını değiştiremezBir güvenlik açığını istismar etmeyin veya gerçek bir servisi hedef almayın. Negatif kontrol, bu deney için oluşturulmuş bir canary dosyasına yönelik zararsız bir izin veya erişilebilirlik testi olmalıdır.
Durum B — Puan odaklı
İndeks puanını artırabilecek ancak tanımlanmış saldırı yolunu değiştirmesi beklenmeyen, uygulanabilir ve geri alınabilir birkaç bulgu seçin. Bunları platformun desteklenen yapılandırma mekanizması üzerinden uygulayın. Gerektiğinde yeniden başlatın, iş yükü testini tekrarlayın, Lynis’i yeniden çalıştırın ve negatif kontrolü yineleyin.
Buradaki amaç kontrollerle alay etmek değildir. Bunlar değerli baseline veya dayanıklılık çalışmaları olabilir. Soru çok daha nettir: Tanımlanmış yol açık kalırken puan değişti mi? Başarısız bir hipotez de dahil olmak üzere yanıtı kaydedin.
Durum C — Tehdit odaklı
Tanımlanmış yoldaki en erken kalıcı kenarı (edge) değiştirin: servis kimliği, yazılabilir yol, Linux capability’si, soket erişilebilirliği, sudo kuralı, kimlik bilgisi okuyucusu veya yönetim düzlemi izni. Aynı kaynak bağlamından aynı pozitif ve negatif kontrolleri tekrarlayın. Lynis’i yeniden çalıştırın; ancak indeks farkının büyük olmasını beklemeyin. Asıl güvenlik sonucu, engellenen saldırı yolu ve sağlıklı çalışan iş yüküdür.
Karşılaştırma kaydı sıfatlar değil, gözlemler içermelidir:
| Ölçüm | Durum A | Durum B | Durum C |
|---|---|---|---|
| Lynis sürümü ve profili | Kaydet | Aynı | Aynı |
| Hardening index | Ölç | Ölç | Ölç |
| Uyarılar ve öneriler | Koru | Fark (Diff) | Fark (Diff) |
| Dinleyen yüzey | Ölç | Yeniden kontrol | Yeniden kontrol |
| Tanımlanmış yetki yolu | Test et | Test et | Test et |
| Pozitif iş yükü kontrolü | Geçti/Kaldı | Geçti/Kaldı | Geçti/Kaldı |
| Negatif güvenlik kontrolü | Geçti/Kaldı | Geçti/Kaldı | Geçti/Kaldı |
| Yeniden başlatma ve kurtarma | Süre | Süre | Süre |
Bu hücreler somut kanıtlarla dolana kadar makale sayısal bir nihai hüküm yayımlamamalıdır.
Neler bozulabilir?
Sertleştirme bir prodüksiyon değişikliğidir ve prodüksiyon değişiklikleri erişilebilirliği en az bir saldırgan kadar etkili bir şekilde yok edebilir. Her önerinin yanına bağımlılık keşfini ve geri alma (rollback) planını koyun.
| Değişiklik ailesi | Olası bağımlılık | Pozitif kontrol | Negatif kontrol |
|---|---|---|---|
| SSH kimlik doğrulama kısıtlaması | Otomasyon, acil durum erişimi, bastion sunucular | Onaylı yönetici hedeflenen rotadan bağlanabilir | Kaldırılan kimlik veya rota reddedilir |
| systemd dosya sistemi izolasyonu | Yükleme yolları, önbellekler, sertifikalar, Unix soketleri | Normal istek yalnızca gerekli durumu okuyup yazabilir | Korunan canary dosyası değişmeden kalır |
| Capability azaltma | Düşük portlar, saat/zaman, ağ yönetimi, izleme (tracing) | Servis başlar ve sağlık kontrolünü tamamlar | Kaldırılan ayrıcalıklı işlem başarısız olur |
| Güvenlik duvarı veya bind değişikliği | İzleme sistemleri, yük dengeleyiciler, küme üyeleri | Beklenen kaynak servise erişir | Onaysız kaynak servise erişemez |
| Kernel veya ptrace politikası | Hata ayıklayıcılar, profiler’lar, crash analizi, EDR | Onaylı arıza teşhis iş akışı başarıyla çalışır | Aynı kullanıcının ilgisiz süreci canary sürecini denetleyemez |
| Mount sertleştirme | Paket betikleri, geçici çalıştırma, konteynerler | Onaylı güncelleme ve iş yükü akışı başarıyla çalışır | İzin verilmeyen çalıştırma veya yazma yolu başarısız olur |
| Audit ve log değişiklikleri | Disk kapasitesi, gizlilik, SIEM ayrıştırması | Beklenen olay doğru zaman ve kimlikle ulaşır | Kontrollü bir politika ihlali sessiz kalmaz |
Değişiklikleri bir canary ortamında uygulayın; konsol veya kurtarma erişimini üzerinde değişiklik yapılan yolun dışında tutun; önceki yapılandırmayı saklayın ve geri alma tetikleyicisini bakım penceresinden önce tanımlayın. Bir kesintiden sonra sessizce geri alınan bir ayar, bir sertleştirme başarısı değildir.
Kanıt matrisi
| Sertleştirme iddiası | Gereken kanıt | Negatif kontrol | Neler yeterli değildir |
|---|---|---|---|
| Gereksiz ağ açıklığı kaldırıldı | Süreç, soket, arayüz, güvenlik duvarı ve onaylı harici erişilebilirlik öncesi ve sonrası | Önceden erişilebilen onaysız kaynaktan bağlanın ve başarısız olmasını bekleyin | Yalnızca ss komut çıktısı |
| Yönetimsel erişim daraltıldı | İsimlendirilmiş süjeler, SSH politikası, sudo kapsamı, başarılı onaylı giriş ve engellenen kaldırılmış rota | Kaldırılan kimliği veya kaynak rotayı kullanın ve reddedildiğini gösterin | Yalnızca değiştirilmiş bir yapılandırma dosyası |
| Servis sınırlandırıldı (containment) | Çalışma zamanı kimliği, efektif capability’ler, yazılabilir yollar, aygıtlar, adres aileleri, IPC bağımlılıkları ve iş yükü sağlığı | Beyan edilen yetkinin dışındaki sınırlandırılmış canary işlemini deneyin | İyi bir systemd-analyze security skoru |
| Kernel kontrolleri role uygundur | Çalışan değer, kalıcı kaynak, desteklenen platform dokümantasyonu, bağımlılık testi ve yeniden başlatma doğrulaması | Ayarın kısıtlaması hedeflenen zararsız işlemi tekrarlayın | Başka bir dağıtımdan sysctl listesi kopyalamak |
| Lynis bulguları giderildi | Saklanan baseline raporu, uygulanabilir kontrol ID’si, kök neden değişikliği, tarama sonrası diff, sorumlu ve yeniden test | Orijinal güvenlik testini orijinal kaynaktan tekrarlayın | Daha az uyarı veya daha yüksek bir indeks |
| Loglama işlevseldir | Kontrollü olay, güvenilir zaman damgası, kaynak kimliği, iletim, depolama, uyarı veya sorgu sonucu ve saklama sorumlusu | Canary olayını üretin ve uçtan uca göründüğünü doğrulayın | Sadece auditd kurulu olması veya SIEM ajanının çalışması |
| Kurtarma uygulanabilirdir | Güvenilir kaynak, yapılandırma geçmişi, izole kimlik bilgileri, süresi ölçülmüş yeniden kurulum, geri yüklenen iş yükü ve bütünlük doğrulaması | Kurtarılan sunucuya veya kimlik düzlemine bağımlı olmadan yeniden kurun | Bir sanal makine snapshot’ı veya başarılı bir yedekleme görevi |
Nihai raporda neler yer almalıdır?
Sistem sahibine bir terminal ekran görüntüsü ve bir yüzde skoru teslim etmeyin. Kabul edilen her kontrol için şunları kaydedin:
- Sunucu rolü, sahibi, ortamı, dağıtımı, kernel sürümü ve iş yükü sürümü;
- Lynis sürümü, aktif profili, test tanımlayıcısı, orijinal gözlem ve kanıt hash’leri;
- Platforma özel baseline ve kullanılan tam sürüm;
- Uygulanabilirlik kararı ve kabul edilen istisnalar;
- Erişilebilir kaynak, efektif süje, korunan varlık ve mevcut durumun ürettiği yetki;
- Yapılandırma değişikliği, dağıtım mekanizması, değişiklik sahibi ve geri alma tetikleyicisi;
- Pozitif iş yükü kontrolü ve negatif güvenlik kontrolü;
- Yeniden başlatma, failover, izleme ve kurtarma sonuçları;
- Kalan risk, telafi edici kontroller, yeniden test tarihi ve kanıt konumu.
Bu yapı iki yaygın hatayı önler: Birincisi, bir tarayıcı önerisi doğrudan bir bulguya dönüştürülmez. İkincisi, değiştirilmiş bir ayar doğrudan kapatılmış bir bulgu sayılmaz.
Önerilen iş sırası
Denetim için bir haftanız varsa şu sıralamayı kullanın:
- Sunucu rolünü, korunan yetkiyi ve kurtarma sınırını tanımlayın.
- Güvenilir bir yerel baseline ve Lynis kanıtlarını koruma altına alın.
- Erişilebilir servisleri ve yönetimsel kimlik yollarını doğrulayın.
- En erken kalıcı kenarları ortadan kaldıran az sayıdaki kontrolü seçin.
- Her seferinde bir değişiklik ailesini geri alma yolu hazır olacak şekilde uygulayın.
- Gerektiğinde yeniden başlatın ve hedeflenen iş yükünü test edin.
- Orijinal negatif güvenlik kontrolünü birebir tekrarlayın.
- Lynis’i yeniden çalıştırın ve puanı nihai sonuç saymadan diff çıktısını kaydedin.
- Log görünürlüğünü test edin ve tek kullanımlık sunucuyu yeniden kurun veya geri yükleyin.
- Kalan önerileri sahipli işlere, politika yükümlülüklerine veya süreli istisnalara dönüştürün.
Sonuç, genel bir kontrol listesinden daha küçük ve çok daha güçlüdür. Her kontrolü bir sistem rolüne, erişilebilir bir eyleme, korunan bir varlığa, operasyonel bir bağımlılığa ve başka bir mühendisin tekrarlayabileceği somut bir sonuca bağlar.
Sonuç
The Practical Linux Hardening Guide değerlidir; çünkü kontrollerin neden var olduğunu açıklar ve bunları köklü politika aileleriyle ilişkilendirir. Lynis değerlidir; çünkü canlı bir Unix benzeri sistemi hızlı bir şekilde geniş ve doğrulanabilir bir gözlem kümesine dönüştürür. Bunların en iyi kullanımı birliktedir — ancak otomatik bir tara, kopyala, yapıştır ve kutla zinciri şeklinde değil.
Sunucunun ne yapması için yetkilendirildiğiyle başlayın. Güncel platform içeriklerini kullanın. Her araç sonucunu bir aday olarak görün. Erişilebilir en erken yetki kenarını kaldırın. Servisi çalışır durumda tutun. Ardından orijinal eylemi tekrarlayın ve engellendiğini kanıtlayın.
Daha yüksek bir puan bu sonuca eşlik edebilir. Ancak onu gerçek bir sertleştirme (hardening) kılan şey kanıttır.
MITRE ATT&CK eşleştirmesi
| Taktik | Teknik ID | Teknik Adı | Savunucu doğrulama sinyali |
|---|---|---|---|
| Execution | T1059.004 | Command and Scripting Interpreter: Unix Shell | Etkileşimli oturumlardaki komut çalıştırmalarını auditd ile denetleyin |
| Privilege Escalation | T1548.001 | Abuse Elevation Control: Setuid and Setgid | find / -perm -4000 -type f denetimlerini baseline envanteri ile karşılaştırın |
| Persistence | T1543.002 | Create or Modify System Process: systemd Service | systemd-analyze security <unit> ile sandbox duruşunu denetleyin |
| Credential Access | T1003.008 | OS Credential Dumping: /etc/passwd and /etc/shadow | /etc/shadow üzerindeki katı 000 / 640 dosya izinlerini Lynis ile doğrulayın |
| Defense Evasion | T1070.002 | Indicator Removal on Host: Clear Linux Logs | Uzak syslog iletimi + değişmez (immutable) audit log dizini |
Savunucu eylem kontrol listesi
Değerlendirme sonrası iyileştirme aşamasında bu uygulanabilir kontrol listesini kullanın:
- Yama ptrace kısıtlamalarını zorunlu kılın:
/etc/sysctl.d/99-security.confdosyasınakernel.yama.ptrace_scope = 2yazın vesysctl -pile uygulayın. - Dışa açık systemd servislerini sertleştirin: Servis drop-in dosyalarına
ProtectSystem=strict,ProtectHome=yesveNoNewPrivileges=yesekleyin. - Ayrıcalıklı geçişleri denetleyin:
/etc/audit/rules.d/audit.rulesdosyasına-w /etc/sudoers -p wa -k identity_changesekleyin. - İş yükü dayanıklılığını doğrulayın: Sertleştirme baseline’ını onaylamadan önce hedef servise karşı test paketini çalıştırın.
İncelenen kaynaklar
- trimstray: The Practical Linux Hardening Guide
- CISOfy: Lynis source repository
- CISOfy: Lynis installation and usage
- CISOfy: Lynis report and logging guide
- Center for Internet Security: CIS Benchmarks
- OpenSCAP 1.4.1 user manual
- NIST SP 800-123: Guide to General Server Security
- systemd-analyze manual
- Linux kernel documentation: Yama
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.