Yama beklerken paylaşımlı bir Linux sunucusunu sıkılaştıran beş çekirdek ayarı

Paylaşımlı bir barındırma sunucusunda her müşteri aynı çekirdek üzerinde kod çalıştırır. Bu yüzden yerel bir yetki yükseltme hatası, ele geçirilen herhangi bir web sitesini olası bir root ele geçirmesine dönüştürür; Ekim 2026’nın sonunda da düzeltmeleri hazır olmayan birkaç çekirdek hata raporu kamuya açıldı. Asıl çözüm yamalar ve canlı yamalardır, ama bunlar günler sürer. Aradaki süre boyunca sunucuyu koruyan şey yapılandırmadır ve bunun çoğu zaten kalıcı olarak yerinde olmalıdır.

Beş ayar

Yükün çoğunu ilk ayar taşır. Son dönemdeki çekirdek yetki yükseltmelerinin birçoğu, sıradan bir kullanıcının ancak kendi oluşturduğu bir user namespace içinde elde edebildiği yetkilere ihtiyaç duyar. Sınır sıfırken bu adım başarısız olur ve hata, daha yamalanmadan bir barındırma müşterisinin ulaşamayacağı hale gelir. Diğer dört ayar, saldırganın yol boyunca öğrenebileceklerini ve dokunabileceklerini azaltır.

Yeniden başlatmadan sonra da kalıcı olsunlar

sysctl -w ile verilen bir değer yalnızca bir sonraki açılışa kadar yaşar. Ayarları, üreticinin varsayılanlarından sonra yüklenecek şekilde adlandırılmış ayrı bir dosyaya yazın. CloudLinux’ta üretici dosyası /etc/sysctl.d/90-cloudlinux.conf olduğu için 99- öneki kazanır:

# /etc/sysctl.d/99-fleet-hardening.conf
user.max_user_namespaces = 0
kernel.yama.ptrace_scope = 1
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.unprivileged_bpf_disabled = 1

Ayarları sysctl --system ile uygulayın ve her değeri sysctl user.max_user_namespaces gibi komutlarla geri okuyun. Namespace sınırını sıradan bir kullanıcı olarak doğrulamak için unshare -Ur true artık “No space left on device” hatasıyla başarısız olmalı.

Hiç kullanmadığınız çekirdek modüllerini kapatın

Yüklenebilir her modül, bir saldırganın çekirdeğe yükletmeye çalışabileceği bir koddur. Paylaşımlı bir web sunucusu çekirdek içi SMB sunucusuna ya da eski ağ protokollerine nadiren ihtiyaç duyar; bunları /etc/modprobe.d/ altında engelleyin:

# /etc/modprobe.d/99-fleet-hardening.conf
install ksmbd /bin/false
install dccp /bin/false
install sctp /bin/false
install rds /bin/false
install tipc /bin/false

Önce lsmod ile hiçbirinin yüklü ya da gerekli olmadığını kontrol edin. Sunucudaki bir şeyin bağlı olduğu modülleri engellemeyin; örneğin esp4 ve esp6 IPsec’i taşır, onları engellemek VPN tünellerini bozar.

Sunucunuz için iki dosyayı oluşturun:

Bir şeyi değiştirmeden önce sunucu nasıl kontrol edilir?

Bu ayarların her biri, kendisine bağlı bir şeyi bozabilir; bu yüzden ilk adım salt okunurdur. Mevcut değerleri beş anahtara göre süzülmüş sysctl -a çıktısıyla kaydedin ve bugün bunları tanımlayan dosyaları /etc/sysctl.conf ile /etc/sysctl.d/ üzerinde grep -r çalıştırarak bulun. Yürürlükte olan ama hiçbir dosyada görünmeyen bir değer yalnızca çalışma anında tanımlanmıştır ve bir sonraki yeniden başlatmada kaybolur.

Ardından şu anda user namespace kullanan bir şey olup olmadığına bakın. lsns -t user mevcut namespace’leri listeler; paylaşımlı bir web sunucusunda yalnızca root’a ait ilk namespace’i görmeyi beklersiniz. Bir müşteri hesabına ait bir namespace, o hesaptaki bir şeyin buna bağlı olduğu anlamına gelir ve sınır sıfıra çekilmeden önce o hesaba bakılması gerekir. Son olarak kurulu konteyner araçlarını listeleyin: kurulu ama kullanılmayan bir konteyner çalışma ortamı sorun değildir, çalışan bir tanesi ise sunucuya farklı davranmak için bir nedendir.

Her ayarın bedeli nedir?

Ne zaman kullanılmamalı

• Konteyner sunucuları. Rootless Docker, Podman, LXC ve Flatpak user namespace’lere ihtiyaç duyar. Bunları çalıştıran bir sunucuda kiracılar için sınırı başka yollarla koruyun ya da riski yalnızca o sunucuda kabul edin.
• Hata ayıklama araçları. ptrace_scope = 1, ilgisiz bir sürece hata ayıklayıcı bağlamayı engeller; root yine yapabilir.
• eBPF kullanan izleme ajanları. Yetkili çalıştıkları için çalışmaya devam ederler, ama değişiklikten sonra kontrol edin. unprivileged_bpf_disabled = 1 değerinin yeniden başlatma olmadan geri alınamayacağını unutmayın; bu seçeneği açık tutmak istiyorsanız 2 kullanın.

Bir barındırma filosundan saha notu

Herhangi bir şeyi değiştirmeden önce on dört paylaşımlı cPanel sunucusunu salt okunur olarak denetledik. Önceki bir incelemede sıkılaştırılmış olarak kaydedilmelerine rağmen dokuzunda user namespace’ler açıktı: değer yalnızca çalışma anında verilmişti ve bir yeniden başlatmada kaybolmuştu. Her sunucuda önce hiçbir müşterinin namespace kullanmadığını kontrol ettik, ilk üç ayarı, yani user.max_user_namespaces, ptrace_scope ve dmesg_restrict değerlerini 99- ile başlayan bir dosya üzerinden uyguladık ve kontrol panelini ve müşteri sitelerinden bir örneği önce ve sonra karşılaştırdık. Hiçbiri değişmedi. Filonun tamamı artık diske yazılmış aynı değerlerle çalışıyor; işaretçi ve eBPF ayarları bir sonraki adım.

Asıl düzeltmeyi takip edin

1. Canlı yamanın otomatik olduğunu doğrulayın. KernelCare’de /etc/sysconfig/kcare/kcare.conf içinde AUTO_UPDATE=True olup olmadığına bakın; komut satırındaki durum, özellik etkin olsa bile boş görünebilir.
2. “Latest patch applied” ifadesini dikkatle okuyun. Bu, çekirdeğiniz için henüz daha yeni bir yama olmadığı anlamına gelir; belirli bir hatanın düzeltildiği anlamına gelmez.
3. Canlı yamalanamayan çekirdekler için yeniden başlatma planlayın. Yeni bir çekirdek paketi kurmak, sunucu onunla açılana kadar hiçbir şey değiştirmez.
4. Yamadan sonra da ayarları koruyun. Bir web sunucusunda neredeyse hiçbir maliyetleri yok ve bir sonraki hataya karşı da koruyorlar.

Ayarların yerinde kaldığından nasıl emin olunur?

Bu bölümün var olma nedeni yukarıdaki filo notudur: tamamlandı olarak kaydedilen bir sıkılaştırma, bir yeniden başlatmada sessizce geri alınmıştı. Ayrı dosyayı yazmak anlık nedeni giderir, ama ayarlar başka yollarla da kayar: bir paket güncellemesi kendi dosyasını getirdiğinde, biri bir değeri elle ayarladığında ya da bir sunucu daha eski bir şablondan yeniden kurulduğunda.

Üç alışkanlık onları doğru tutar. Beş değeri her yeniden başlatmadan ve her çekirdek ya da CloudLinux güncellemesinden sonra kontrol edin; bunu tercihen hafızaya değil izlemeye bırakın ve beklenen değerden her sapmada uyarı üretin. Ayrı dosyayı yapılandırma yönetimi altında ya da en azından sürümlenmiş bir kopya olarak tutun ki yeniden kurulan bir sunucu aynı dosyayı alsın. Ve bu kontrolü, güvenlik duvarı ve SSH ayarlarının yanında, her dönemsel sunucu incelemesine dahil edin; çünkü kimsenin bakmadığı bir değer, değiştiğini de kimsenin fark etmeyeceği bir değerdir.

Beş anahtarı yazdırıp beklenen değerlerle karşılaştıran küçük bir betik yeterlidir. Onu cron ile çalıştırın ve çıktısını diğer uyarılarınızla aynı yere gönderin; böylece kaymış bir değer sürpriz değil, bir ticket olur.

Bir şey bozulursa nasıl geri alınır?

Geri almayı da değişikliğin kendisi kadar basit tutun. Ayrı dosyayı yazmadan önce mevcut değerleri bir çalışma dizinindeki bir dosyaya kaydedin. Sonrasında bir hizmet hata verirse, /etc/sysctl.d/99-fleet-hardening.conf içindeki satırı silin ya da yorum satırına çevirin ve eski değeri sysctl -w ile geri verin; bu ayarların çoğu hemen etkili olur ve yeniden başlatma gerektirmez. İstisna unprivileged_bpf_disabled = 1 değeridir: bir sonraki açılışa kadar yürürlükte kalır; emin olmadığınız bir sunucuda 2 değerinin daha güvenli ilk adım olmasının nedeni budur.

Aynı ayın çalışma ortamı tarafı için PHP2Shell yama günü rehberine ve tek haftada Node.js, BIND ve Java yazısına bakın.

Kısacası

Bu ayarların hiçbiri yeni değil ve hiçbiri bir çekirdek yamasının yerini tutmaz. Değiştirdikleri şey, açıklama ile düzeltme arasındaki boşluktur; paylaşımlı bir sunucuda en çok önem taşıyan dönem de budur, çünkü her müşterinin kodu aynı çekirdeği paylaşır. Onları bir kez yerine koyun, diske yazın, kaymalara karşı izleyin ve konteyner sunucusunu bilinçli tek istisna olarak ele alın. Bir dahaki sefere bir yetki yükseltme raporu düzeltmesinden önce kamuya açıldığında, soru sunucunun zaten açıkta olup olmadığı değil, yamanın ne zaman geleceği olacaktır.

SSS: paylaşımlı bir Linux sunucusu için çekirdek sıkılaştırma

user.max_user_namespaces değerini 0 yapmak cPanel ya da CloudLinux sunucularını bozar mı?

Bizim deneyimimizde hayır. On dört paylaşımlı cPanel sunucusunda kontrol paneli ve örnek müşteri siteleri değişiklikten önce ve sonra aynı yanıtları verdi. Önce lsns -t user ile hiçbir müşteri hesabının namespace kullanmadığını kontrol edin, çünkü kullanan bir hesap bundan etkilenir.

2026’da bir CloudLinux sunucusunda sysctl ek dosyası neden 99 ile başlamalı?

Çünkü /etc/sysctl.d/ içindeki dosyalar ad sırasına göre yüklenir ve sonraki dosya kazanır. CloudLinux 90-cloudlinux.conf dosyasıyla gelir; bu yüzden 99- ile başlayan bir dosya ondan sonra uygulanır ve yürürlükte kalan değerler onun değerleridir.

User namespace’lerin sıradan kullanıcılar için gerçekten kapalı olduğunu nasıl doğrularsınız?

Değeri sysctl user.max_user_namespaces ile okuyun, ardından yetkisiz bir kullanıcı olarak unshare -Ur true çalıştırın. Sınır sıfırken komut “No space left on device” hatasıyla başarısız olur; başarılı olursa ayar yürürlükte değildir.

Paylaşımlı bir barındırma sunucusunda kernel.yama.ptrace_scope 1 mi 2 mi kullanılmalı?

Pratik varsayılan 1 değeridir: bir süreç yalnızca üst süreci tarafından izlenebilir ve bu, ele geçirilen bir sürecin başka bir süreci incelemesini engeller. 2 değeri izlemeyi yalnızca yöneticilerle sınırlar; bu daha katıdır ve meşru hata ayıklamanın önüne geçebilir.

Bir web sunucusunda kernel.kptr_restrict 1 ile 2 arasındaki fark nedir?

1 değerinde çekirdek işaretçileri uygun yetkiye sahip olmayan kullanıcılardan gizlenir; 2 değerinde ise root dahil herkesten gizlenir. Bir web sunucusu nadiren çekirdek adreslerine ihtiyaç duyar, bu yüzden 2 makul bir seçimdir.

kernel.unprivileged_bpf_disabled ayarı yeniden başlatma olmadan geri alınabilir mi?

1 değeri, tasarım gereği bir sonraki açılışa kadar geri değiştirilemez. 2 değeri de yetkisiz eBPF’i engeller ama bir yönetici tarafından çalışma anında gevşetilebilir; bu yüzden sunucunun ne çalıştırdığından emin değilseniz daha güvenli ilk adım odur.

2026’da bir konteyner sunucusu user namespace’leri kapatmak yerine ne yapmalı?

Onu ayrı bir sunucu sınıfı olarak ele alın. Rootless Docker, Podman ve LXC user namespace’lere ihtiyaç duyar; bu yüzden orada açık tutun, o sunucuyu paylaşımlı barındırma havuzunun dışında tutun ve yetki yükseltme hatalarını kapatmak için hızlı çekirdek yamalarına ve canlı yamalamaya güvenin.

2026’da paylaşımlı bir web sunucusunda hangi çekirdek modüllerini engellemek güvenlidir, hangileri değildir?

Sunucunun hiç kullanmadığı özelliklere ait modüller iyi adaylardır; örneğin çekirdek içi SMB sunucusu ve nadiren kullanılan ağ protokolleri. Herhangi bir IPsec tüneli varsa esp4 ya da esp6 modülünü asla engellemeyin ve bir girdi eklemeden önce lsmod çıktısını kontrol edin.

KernelCare’deki “latest patch applied” ifadesi belirli bir çekirdek hatasının düzeltildiği anlamına mı gelir?

Hayır. Çalışan çekirdek için henüz daha yeni bir canlı yama olmadığı anlamına gelir. Belirli bir hatanın kapsanıp kapsanmadığını bilmek için KernelCare’in yama listesine ya da o soruna ait duyurularına bakın ve düzeltme yayımlandığında uygulanması için AUTO_UPDATE=True olduğunu doğrulayın.

Çekirdek yaması kurulduktan sonra sıkılaştırma ayarları yerinde kalmalı mı?

Evet. Bir web sunucusunda neredeyse hiçbir maliyetleri yoktur ve bir sonraki yetki yükseltme hatasının erişimini de, daha yaması çıkmadan azaltırlar. Onları geçici bir çözüm olarak değil, temel yapılandırma olarak görün.

Kaynaklar

• /proc/sys/user belgeleri, kernel.org
• /proc/sys/kernel belgeleri, kernel.org
• Yama, kernel.org
• Birkaç Linux çekirdek açığı herkese açık bir e-posta listesine gönderildi, Phoronix