AppArmor ile Uygulama Sertleştirme

Bir sunucuyu güvenlik duvarıyla korumak, güçlü parolalar kullanmak ve güncellemeleri düzenli yapmak önemlidir; ancak bunların hiçbiri, çalışan bir uygulamanın ele geçirildiği anda saldırganın tüm dosya sistemine erişmesini tek başına engellemez. Bir web sunucusu, bir veritabanı ya da bir mail servisi kendi görevini yapmak için belirli dosyalara ve ağ portlarına ihtiyaç duyar. Peki bu servis bir açık yüzünden dışarıdan kontrol edilmeye başlarsa, işletim sistemi ona "yalnızca ihtiyacın olan yere dokunabilirsin" diyebilir mi? İşte AppArmor tam olarak bu soruya cevap veren bir mekanizmadır.

AppArmor, Ubuntu ve Debian tabanlı sistemlerde varsayılan olarak gelen bir Zorunlu Erişim Kontrolü (Mandatory Access Control, MAC) katmanıdır. Klasik Linux izinlerinin (kullanıcı, grup, diğer) ötesine geçerek her uygulamayı ayrı bir "profil" içine hapseder ve o profilde tanımlı olmayan hiçbir işlemi yapmasına izin vermez. Böylece bir uygulama root olarak çalışsa bile, profil dışına çıkamaz. Bu rehberde AppArmor'un profil mantığını, enforce ve complain modlarını, mevcut profilleri yönetmeyi, bir uygulama için profil düzenlemeyi ve logdan ihlalleri okumayı gerçek komutlarla anlatacağız.

AppArmor Nedir ve Neden Önemlidir#

Standart Linux izin modeli "isteğe bağlı" (discretionary) bir yapıdadır. Yani bir dosyanın sahibi, o dosyaya kimin erişebileceğine kendi karar verir ve root her şeyi yapabilir. Bu esneklik günlük kullanımda pratiktir ama güvenlik açısından zayıf noktadır. Bir Nginx sürecinde uzaktan kod çalıştırma açığı bulunan bir saldırgan, Nginx'in çalıştığı yetkiyle /etc/passwd, SSH anahtarları ya da veritabanı yedekleri gibi hassas dosyalara ulaşmayı deneyebilir.

AppArmor bu tabloyu değiştirir. Her profil, uygulamanın hangi dosyalara hangi izinlerle (okuma, yazma, çalıştırma) erişebileceğini, hangi ağ işlemlerini yapabileceğini ve hangi Linux "capability"lerini kullanabileceğini açıkça listeler. Listede olmayan her şey yasaktır. Yani AppArmor beyaz liste mantığıyla çalışır: izin verilmeyen varsayılan olarak reddedilir. Bir uygulama ele geçirilse bile, saldırgan yalnızca profilin çizdiği sınırların içinde hareket edebilir. Bu yaklaşım, hasar azaltma (damage containment) açısından modern sunucu sertleştirmesinin temel taşlarından biridir.

Önemli bir ayrıntı da AppArmor'un "yola dayalı" (path-based) çalışmasıdır. Profiller dosya yolları üzerinden tanımlanır, bu da onları okunabilir ve düzenlenebilir kılar. Sunucu güvenliğinin genel çerçevesini merak ediyorsanız sunucu güvenliği temelleri yazımız AppArmor'un oturduğu büyük resmi tamamlar.

AppArmor ile SELinux Arasındaki Fark#

Zorunlu erişim kontrolü dünyasında iki büyük isim vardır: AppArmor ve SELinux. İkisi de aynı amaca hizmet eder ama felsefeleri farklıdır. SELinux, RHEL, CentOS, Rocky Linux ve Fedora ailesinde varsayılan gelirken; AppArmor Ubuntu, Debian ve openSUSE tarafında varsayılandır. Ubuntu kullanıyorsanız neredeyse kesinlikle AppArmor ile çalışıyorsunuz demektir.

Temel fark şudur: SELinux dosyalara ve süreçlere "etiket" (label) atar ve kararlarını bu etiketler üzerinden verir. Bu güçlü ve çok ince ayarlı bir modeldir ama öğrenme eğrisi diktir. AppArmor ise dosya yollarını temel alır; profilleri okumak ve yazmak çok daha kolaydır. Bir sistem yöneticisi için pratik anlamı, AppArmor'da bir profili birkaç dakikada anlayıp düzenleyebilmenizdir.

Hangisi "daha iyi" sorusunun net bir cevabı yoktur; bulunduğunuz dağıtımın varsayılanıyla çalışmak en mantıklısıdır. Ubuntu tabanlı bir sunucuda AppArmor'u devre dışı bırakıp SELinux kurmaya çalışmak gereksiz bir uğraştır. Clou.TR üzerinde bir VDS sunucu ya da sanal sunucu kullanıyorsanız ve Ubuntu şablonu seçtiyseniz, AppArmor zaten hazır bekliyordur.

AppArmor Profil Mantığı ve Modlar#

AppArmor'un kalbi profillerdir. Her profil /etc/apparmor.d/ dizini altında düz metin bir dosya olarak durur ve genellikle koruduğu programın yoluna göre adlandırılır. Örneğin /usr/sbin/nginx için profil /etc/apparmor.d/usr.sbin.nginx dosyasında bulunur. Bir profilin çalışabileceği iki ana mod vardır ve bu ikisini bilmek AppArmor'u anlamanın anahtarıdır.

Enforce (zorlama) modu, profilin tam yetkiyle uygulandığı moddur. Profilde izin verilmeyen her işlem gerçekten engellenir ve engellenen işlem loglanır. Üretim ortamında güvenlik sağlayan mod budur.

Complain (şikayet) modu ise "öğrenme" modu olarak da bilinir. Bu modda hiçbir işlem engellenmez; ancak profil dışına çıkan her işlem loglanır. Yeni bir profil hazırlarken uygulamayı complain modunda çalıştırıp gerçek hayatta neye eriştiğini gözlemlemek, sonra o erişimleri profile eklemek yaygın bir yöntemdir. Böylece uygulamayı bozmadan doğru profili inşa edersiniz.

Bir profil ayrıca unconfined olabilir; bu, sürecin hiçbir AppArmor kısıtlaması olmadan çalıştığı anlamına gelir. Sertleştirme çalışmasının hedefi, kritik servisleri unconfined durumdan çıkarıp enforce moduna almak, ama bunu uygulamayı kırmadan yapmaktır.

aa-status ile Mevcut Durumu Görmek#

Herhangi bir değişiklik yapmadan önce sistemin mevcut AppArmor durumunu görmek gerekir. Bunun için en temel araç aa-status (ya da aynı işi gören apparmor_status) komutudur. Root yetkisiyle çalıştırılır ve size yüklü profillerin özetini verir.

sudo aa-status

Tipik bir çıktı şuna benzer:

apparmor module is loaded.
42 profiles are loaded.
38 profiles are in enforce mode.
   /usr/sbin/nginx
   /usr/sbin/mysqld
   ...
4 profiles are in complain mode.
   /usr/bin/some-app
   ...
15 processes have profiles defined.
13 processes are in enforce mode.
2 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Bu çıktı bize üç önemli bilgi verir: kaç profil yüklü, kaçı hangi modda ve o an çalışan süreçlerden kaçı bir profille korunuyor. Özellikle son satırlardaki "processes are unconfined but have a profile defined" ifadesine dikkat edin; profil tanımlı ama sürecin korunmuyor olması bir aksaklık işaretidir. AppArmor servisinin çalışıp çalışmadığını da doğrulamak isterseniz:

sudo systemctl status apparmor
sudo aa-enabled

aa-enabled komutu basitçe Yes ya da No döner. Eğer No dönüyorsa, çekirdek düzeyinde AppArmor devre dışı bırakılmış olabilir ve bunun düzeltilmesi gerekir. Paketlerin kurulu olduğundan emin olmak için sudo apt install apparmor apparmor-utils apparmor-profiles komutunu çalıştırabilirsiniz; apparmor-utils özellikle profil yönetim araçlarını içerdiği için önemlidir.

Profilleri Yönetmek#

AppArmor profillerini yönetmek için apparmor-utils paketiyle gelen üç ana komut kullanılır: aa-enforce, aa-complain ve aa-disable. Bunların her biri bir profili istediğiniz moda geçirir. Örneğin Nginx profilini şikayet moduna almak istediğinizde:

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

Aynı profili tekrar zorlama moduna almak için:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

Bir profili tamamen devre dışı bırakmak isterseniz aa-disable kullanılır; bu komut profili disable dizinine bir sembolik bağlantı ile işaretler ve çekirdekten kaldırır:

sudo aa-disable /etc/apparmor.d/usr.sbin.nginx

Program yolunu doğrudan da verebilirsiniz; örneğin sudo aa-enforce /usr/sbin/nginx de çalışır. Bir profil dosyasında elle değişiklik yaptıysanız, değişikliğin çekirdek tarafından okunması için profili yeniden yüklemeniz gerekir. Bunun için apparmor_parser kullanılır:

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

Tüm profilleri yeniden yüklemek için ise servisi yeniden başlatmak yeterlidir:

sudo systemctl reload apparmor

Pratik bir kural: bir servisi ilk kez sertleştirirken önce aa-complain ile başlayın, birkaç gün normal trafik altında gözlemleyin, logları inceleyin, profili düzeltin ve ancak yalancı ihlaller kesildiğinde aa-enforce moduna geçin. Bu sabırlı yaklaşım, enforce moda erken geçip uygulamayı üretimde kırma riskini ortadan kaldırır.

Bir Uygulama İçin Profil Düzenlemek#

Şimdi işin özüne, yani bir profilin içeriğine bakalım. AppArmor profili düz metindir ve mantığı sezgiseldir. Basitleştirilmiş bir örnek profil parçası şöyle görünür:

#include <tunables/global>

/usr/sbin/nginx {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability net_bind_service,
  capability setuid,
  capability setgid,

  network inet stream,
  network inet6 stream,

  /etc/nginx/** r,
  /var/log/nginx/*.log w,
  /var/www/** r,
  /var/run/nginx.pid rw,
  /usr/sbin/nginx mr,
}

Buradaki her satır bir izin kuralıdır. Dosya yolundan sonra gelen harfler erişim tipini belirtir: r okuma, w yazma, m bellek eşleme (memory map), x çalıştırma, k kilit (lock) anlamına gelir. Yani /var/www/** r kuralı, Nginx'in /var/www altındaki her şeyi okuyabileceğini ama yazamayacağını söyler. Bu tam olarak istediğimiz davranıştır: web sunucusu içerik dosyalarını sunabilmeli ama onları değiştirememelidir. ** iki yıldız alt dizinleri de kapsar, tek * yalnızca o dizindeki dosyaları eşler.

#include satırları hazır izin kümelerini profile katar; abstractions/base neredeyse her programın ihtiyaç duyduğu temel erişimleri içerir. capability satırları Linux capability'lerini kontrol eder; örneğin net_bind_service 1024'ün altındaki portlara bağlanma yetkisidir ki web sunucuları için gereklidir. Elle profil yazmak yerine AppArmor size yardımcı araçlar da sunar. Yeni bir uygulama için sıfırdan profil oluşturmak isterseniz aa-genprof, uygulamayı çalıştırırken davranışını izleyip interaktif olarak profil üretir:

sudo aa-genprof /usr/local/bin/uygulamam

Bu komut çalışırken başka bir terminalde uygulamayı normal şekilde kullanırsınız; aa-genprof her erişim denemesinde size "izin ver, reddet, sadece kaydet" gibi seçenekler sunar. Var olan bir complain profilinin loglarını profil kurallarına dönüştürmek içinse aa-logprof kullanılır; bu araç logdaki ihlalleri okuyup her biri için ne yapılacağını sorar. Bir web hosting ortamında çalışıyorsanız ve kendi profilinizi yönetmek yerine yönetilen bir çözüm istiyorsanız, Clou.TR web hosting ve WordPress hosting paketlerinde bu tür sertleştirmeler zaten platform tarafında yapılandırılmış gelir.

Loglardan İhlalleri Görmek ve Sorun Gidermek#

AppArmor bir işlemi engellediğinde ya da complain modunda bir ihlali kaydettiğinde bunu çekirdek loguna yazar. Bu logları okumak, hem bir uygulamanın neden çalışmadığını anlamak hem de saldırı girişimlerini fark etmek için kritiktir. En hızlı yol dmesg ya da systemd günlüğüdür:

sudo dmesg | grep -i apparmor
sudo journalctl -k | grep -i "apparmor"

Tipik bir engelleme kaydı şöyle görünür:

audit: type=1400 apparmor="DENIED" operation="open" profile="/usr/sbin/nginx" name="/etc/shadow" pid=1234 comm="nginx" requested_mask="r" denied_mask="r"

Bu satır çok şey anlatır. apparmor="DENIED" işlemin engellendiğini, profile hangi profilin devrede olduğunu, name erişilmeye çalışılan dosyayı, requested_mask istenen izni gösterir. Yukarıdaki örnekte Nginx /etc/shadow dosyasını okumaya çalışmış ve engellenmiş; bu ya bir yanlış yapılandırma ya da ciddi bir saldırı işaretidir. complain modunda aynı satır apparmor="ALLOWED" olarak görünür, yani işlem geçmiştir ama kaydedilmiştir.

Eğer bir uygulama profil yüzünden beklenmedik şekilde çalışmıyorsa, teşhis yöntemi nettir: logu açın, hangi dosya ya da yeteneğin reddedildiğini bulun, bu erişim meşruysa profile ekleyin, profili yeniden yükleyin ve tekrar deneyin. Bu döngüyü kolaylaştıran araç yine aa-logprof'tur:

sudo aa-logprof

Bu komut son logları tarar ve reddedilen her işlem için size profile ekleme seçeneği sunar; onayladıklarınızı otomatik olarak profil dosyasına yazar. Sürekli izleme için AppArmor loglarını merkezi log altyapınıza dahil etmek iyi bir fikirdir. Kayıtların kaybolmaması ve olay incelemesinde işinize yaraması için düzenli yedekleme politikanızın log dosyalarını da kapsadığından emin olun.

AppArmor'u Sunucu Sertleştirme Stratejisine Oturtmak#

AppArmor tek başına bir sihirli değnek değildir; katmanlı güvenlik (defense in depth) yaklaşımının bir parçasıdır. En verimli sonucu, onu diğer önlemlerle birlikte kullandığınızda alırsınız. Sağlıklı bir sertleştirme sırası genellikle şöyle işler: önce sistemi güncel tutun, ardından ağ katmanını UFW güvenlik duvarı ile kapatın, SSH erişimini anahtar tabanlı hale getirin ve en sonda çalışan servisleri AppArmor profilleriyle hapsedin. Bu sıralama, bir katman aşılsa bile diğerlerinin devrede kalmasını sağlar.

Pratikte hangi servisleri öncelikli olarak sertleştirmelisiniz? İnternete açık ve saldırı yüzeyi geniş olan her şey listenin başında olmalı: web sunucusu (Nginx/Apache), veritabanı (MySQL/PostgreSQL), mail servisleri ve dışarıya iş yapan uygulama süreçleri. Ubuntu'nun kendi paket depolarından kurulan birçok popüler servis, apparmor-profiles paketiyle birlikte hazır bir profil ile gelir; sizin işiniz bu profilleri complain'den enforce'a doğru olgunlaştırmaktır.

Şu birkaç ilkeyi akılda tutun: profilleri en az ayrıcalık ilkesine göre daraltın, yani uygulamaya yalnızca gerçekten ihtiyaç duyduğu erişimi verin; profil değişikliklerini enforce'a almadan önce mutlaka complain modunda test edin; ve logları düzenli izleyin çünkü bir DENIED satırı bazen bir saldırının ilk işareti olabilir. Uygulama sertleştirmenin yanında ağ katmanında bir WAF ve DDoS koruma çözümü kullanmak, girişi engellenmiş bir saldırganın AppArmor'a hiç ulaşamamasını sağlar. Sunucularınızı kendiniz yönetmek istemiyorsanız, Clou.TR sunucu yönetimi hizmeti bu sertleştirmelerin tümünü sizin adınıza uygular.

Sıkça Sorulan Sorular#

AppArmor'u devre dışı bırakmalı mıyım eğer bir uygulama çalışmıyorsa?#

Hayır, ilk çözüm asla AppArmor'u kapatmak olmamalıdır. Uygulama bir profil yüzünden çalışmıyorsa doğru yaklaşım, ilgili profili önce complain moduna almak, logdan hangi erişimin reddedildiğini bulmak ve o erişim meşruysa profile eklemektir. AppArmor'u tamamen kapatmak, tüm sistem için önemli bir güvenlik katmanını feda etmek anlamına gelir; oysa sorun genellikle tek bir eksik izin kuralından ibarettir ve birkaç dakikada çözülebilir.

Complain ve enforce modu arasındaki fark tam olarak nedir?#

Enforce modunda AppArmor profilde izin verilmeyen işlemleri gerçekten engeller ve loglar; bu, üretimde koruma sağlayan moddur. Complain modunda ise hiçbir işlem engellenmez, yalnızca profil dışına çıkan her erişim loglanır. Complain modu esasen bir öğrenme ve test aşamasıdır; yeni bir profili canlı ortamı bozmadan geliştirmek için uygulamayı bu modda çalıştırıp gerçek davranışını gözlemler, sonra profili olgunlaştırıp enforce moduna geçersiniz.

AppArmor mı SELinux mi kullanmalıyım?#

Bu tercih büyük ölçüde dağıtımınızın varsayılanına bağlıdır. Ubuntu, Debian ve openSUSE kullanıyorsanız AppArmor zaten kuruludur ve onunla çalışmak en pratik yoldur; RHEL, Rocky ya da Fedora ailesindeyseniz SELinux varsayılan gelir. İkisi de aynı amaca hizmet eder ama AppArmor yola dayalı ve okunması kolay profillerle daha yumuşak bir öğrenme eğrisi sunarken, SELinux etiket tabanlı ve daha ince ayarlıdır. Varsayılanı değiştirmeye çalışmak genellikle gereksiz zorluk yaratır.

Yeni yüklediğim bir uygulama için sıfırdan profil nasıl oluştururum?#

Bunun için apparmor-utils paketindeki aa-genprof aracı tasarlanmıştır. Komutu uygulamanın yolu ile çalıştırır, ardından başka bir terminalde uygulamayı normal şekilde kullanırsınız; araç her erişim denemesinde size izin verme, reddetme ya da kaydetme seçenekleri sunar ve sonunda bir başlangıç profili üretir. Alternatif olarak uygulamayı bir süre complain modunda çalıştırıp topladığınız logları aa-logprof ile profile dönüştürebilirsiniz. Her iki yolda da profili enforce'a almadan önce yeterince test etmek gerekir.

AppArmor performansı olumsuz etkiler mi?#

Pratikte AppArmor'un performans etkisi ihmal edilebilir düzeydedir. Erişim kontrolü çekirdek seviyesinde ve son derece verimli çalışır; her dosya işleminde profilin kontrol edilmesi mikrosaniyeler mertebesinde bir maliyet getirir ve bu, tipik bir web ya da veritabanı iş yükünde ölçülebilir bir yavaşlamaya yol açmaz. Kazandığınız güvenlik faydası, bu son derece küçük ek yükün çok üzerindedir; dolayısıyla performans kaygısıyla AppArmor'dan vazgeçmek için pratik bir gerekçe yoktur.

Kapanış#

AppArmor, Ubuntu ve Debian sunucularınızda hazır bekleyen ama çoğu zaman hakkı verilmeyen güçlü bir güvenlik katmanıdır. Profillerin beyaz liste mantığını kavradığınızda, enforce ve complain modları arasındaki farkı öğrendiğinizde ve logları okuyup profilleri düzeltebildiğinizde, çalışan uygulamalarınızı en az ayrıcalık ilkesiyle hapsedip olası bir ihlalin etkisini dramatik biçimde sınırlayabilirsiniz. Bunu güvenlik duvarı, güncel sistem ve sağlam erişim politikalarıyla birleştirdiğinizde, katmanlı ve dirençli bir sunucu elde edersiniz.

Bu sertleştirmeleri kendi sunucunuzda uygulamaya hazırsanız, Clou.TR'nin VDS ve sanal sunucu çözümleriyle tam kök erişimine sahip Ubuntu ortamınızı bugün kurabilirsiniz. Yapılandırmayı bizim üstlenmemizi tercih ederseniz sunucu yönetimi hizmetimizle AppArmor profillerinden güvenlik duvarına kadar tüm sertleştirmeyi sizin adınıza yaparız. Güvenli, hızlı ve profesyonelce yönetilen altyapı için barındırma paketlerimizi incelemeniz yeterli.