SELinux ve AppArmor Nedir? Zorunlu Erişim Kontrolü

Klasik Linux izin modeli, bir dosyaya kimin okuma, yazma ve çalıştırma hakkı olduğunu dosyanın sahibine göre belirler. Yani www-data kullanıcısıyla çalışan Nginx, o kullanıcının erişebildiği her dosyaya erişebilir; işletim sistemi bu erişimin "makul" olup olmadığını hiç sorgulamaz. Bu yaklaşıma isteğe bağlı erişim kontrolü (Discretionary Access Control, DAC) denir çünkü kararı büyük ölçüde dosyanın sahibi verir. DAC pratik ve anlaşılırdır, ama tek başına düşünüldüğünde tehlikeli bir varsayıma dayanır: her sürecin, üzerinde çalıştığı kullanıcının tüm yetkilerini hak ettiğine güvenir.

Gerçek dünyada bu varsayım çöker. Bir web uygulamasındaki güvenlik açığı sömürülüp saldırgan Nginx'in ele geçirilmesini sağladığında, saldırgan artık www-data kimliğiyle iş yapabilir ve DAC'a göre bu kimliğin gidebildiği her yere gidebilir: SSH anahtarlarını okumaya, /etc/passwd içeriğini sızdırmaya, hatta başka servislerin veritabanı yedeklerine ulaşmaya çalışır. İşte tam bu noktada zorunlu erişim kontrolü (Mandatory Access Control, MAC) devreye girer. SELinux ve AppArmor, çekirdek düzeyinde çalışan iki MAC sistemidir ve amaçları aynıdır: bir süreç ele geçirilse bile ne yapabileceğini önceden yazılmış bir politikayla katı biçimde sınırlamak. Bu yazıda ikisinin nasıl çalıştığını, birbirlerinden neyle ayrıldıklarını ve engellenen bir erişimi loglardan nasıl çözeceğinizi anlatıyorum.

DAC Yeterli Değil: MAC Neden Var?#

Zorunlu erişim kontrolünü anlamanın en kolay yolu, onu bir kat üste yerleştirmektir. Bir süreç bir dosyaya erişmek istediğinde önce klasik izinler (DAC) kontrol edilir; DAC izin veriyorsa iş bitmez, ardından MAC politikası sorgulanır. Erişimin gerçekleşebilmesi için her iki katmanın da onay vermesi gerekir. MAC sadece daraltabilir; asla DAC'ın reddettiği bir erişimi açamaz. Yani en kötü senaryoda bile MAC sizi mevcut durumdan daha güvensiz yapmaz, sadece güvenli tarafa doğru kısıtlar.

Aradaki en kritik fark "zorunlu" kelimesinde saklıdır. DAC'ta bir dosyanın sahibi, iznini istediği gibi gevşetebilir; örneğin chmod 777 diyerek dosyayı herkese açabilir. MAC'ta ise politikayı süreç veya dosya sahibi değil, sistemi yöneten güvenlik politikası belirler ve sıradan bir süreç bu politikayı kendi lehine değiştiremez. Bir Nginx süreci, politika izin vermiyorsa /home altındaki kullanıcı dosyalarını okuyamaz; www-data bu dosyalara DAC açısından erişebilecek olsa bile. Bu, saldırı yüzeyini daraltmanın en güçlü yollarından biridir ve neden sunucu güvenliği temelleri rehberimizde katmanlı savunmanın vazgeçilmez bir parçası olarak anlattığımızın da cevabıdır.

MAC'ın felsefesi en az yetki prensibiyle birebir örtüşür: her servise, işini görebilmesi için gereken minimum erişimi ver, gerisini kapat. Bir posta sunucusunun /var/mail dizinine erişmesi doğaldır; ama aynı sürecin /root/.ssh/id_rsa dosyasını okumaya çalışması hiçbir normal senaryoda gerekli değildir. MAC işte bu "gereksiz ama teknik olarak mümkün" erişimleri kesip atar.

Zorunlu Erişim Kontrolü Nasıl Çalışır?#

MAC sistemleri, çekirdek içindeki Linux Security Modules (LSM) çerçevesine bağlanarak çalışır. LSM, çekirdeğin kritik noktalarına yerleştirilmiş kancalardır (hook): bir dosya açılmadan, bir soket dinlenmeye başlamadan, bir süreç başka bir sürece sinyal göndermeden hemen önce çekirdek "bu işleme izin var mı?" diye MAC modülüne danışır. Modül politikaya bakar, izin verir ya da reddeder. Bu sorgulama kullanıcı için tamamen şeffaftır; uygulama koduna hiçbir değişiklik gerekmez.

Politikanın kalbinde, her sürecin ve her nesnenin (dosya, dizin, port, soket) bir bağlama/güvenlik etiketine sahip olması yatar. Modül, "şu etiketteki süreç, şu etiketteki nesneye şu işlemi yapabilir mi?" sorusunun cevabını önceden tanımlanmış kurallarda arar. İşte SELinux ile AppArmor'un yollarının ayrıldığı temel nokta da budur: ikisi de MAC uygular ama nesneleri farklı biçimde tanımlar. SELinux her şeyi etiketlerken, AppArmor dosya yollarıyla çalışır. Bu ayrımı sonraki bölümlerde ayrı ayrı ele alacağız.

Bir sürecin çekirdek gözünde hangi izinlere sahip olduğu, o sürecin etki alanı (domain) ya da profili tarafından belirlenir. Süreç başlarken belirli bir etki alanına girer; o andan itibaren yapabildiği her şey o alanın kurallarıyla çerçevelenir. Klasik izinlerin sürecin çalıştığı kullanıcıya odaklanmasının aksine, MAC sürecin ne olduğuna ve ne yapmaya çalıştığına odaklanır. Bu ince fark, ele geçirilmiş bir servisi zapt etmenin tüm sırrıdır. İzin mantığının temellerine hâkim değilseniz Linux dosya izinleri yazısı, MAC'ın üzerine oturduğu DAC katmanını iyi bir zemine oturtacaktır.

SELinux: Etiket Tabanlı Politika#

SELinux (Security-Enhanced Linux), RHEL ailesinin (AlmaLinux, Rocky Linux, CentOS Stream, Fedora) varsayılan MAC sistemidir. Yaklaşımı etiket tabanlıdır: sistemdeki her dosya, dizin, süreç ve ağ portu bir güvenlik bağlamıyla (context) etiketlenir. Bu bağlam dört alandan oluşur ve genellikle user:role:type:level biçiminde yazılır. Günlük pratikte en çok işinize yarayacak alan üçüncüsü, yani tip (type) alanıdır; SELinux kararlarının büyük çoğunluğu tipler arasındaki kurallara dayanır ve buna "type enforcement" denir.

Etiketleri -Z bayrağıyla görebilirsiniz. Dosyalar için ls -Z, süreçler için ps -Z kullanılır:

# Web kök dizinindeki dosyaların bağlamı
ls -Z /var/www/html
# -rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:0 index.html

# Çalışan Nginx sürecinin bağlamı
ps -eZ | grep nginx
# system_u:system_r:httpd_t:0  1234 ?  00:00:00 nginx

Buradaki mantık şudur: httpd_t tipindeki bir süreç (web sunucusu), httpd_sys_content_t tipiyle etiketlenmiş dosyaları okuyabilir. Ama aynı süreç, örneğin /home altındaki kullanıcı dosyalarının taşıdığı user_home_t tipine kural bulunmadığı için erişemez. Nginx ele geçirilse bile SELinux, httpd_t alanının çizdiği duvarların dışına çıkmasına izin vermez. Servisin sadece kendi içeriğini görmesi, gerisini görememesi tam olarak istediğimiz izolasyondur.

SELinux'un durumunu ve kipini görmek için:

sestatus
# SELinux status:   enabled
# Current mode:     enforcing
# Loaded policy name: targeted

getenforce
# Enforcing

SELinux'la çalışırken en sık karşılaşacağınız görevler, bir dizine doğru etiketi atamak ve bir davranışı açıp kapatmaktır. Örneğin web kök dizinini standart dışı bir yola (/srv/web) taşıdıysanız, o yola web içerik tipini kalıcı olarak tanımlamanız gerekir:

# Yeni yol için kalıcı etiket kuralı ekle
semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"

# Kuralı diske uygula (dosyaları yeniden etiketle)
restorecon -Rv /srv/web

SELinux ayrıca boolean adı verilen açık/kapalı anahtarlar sunar; bunlar politikayı yeniden yazmadan yaygın davranışları esnetmenizi sağlar. Mesela web uygulamanızın dışarıya ağ bağlantısı kurması (bir API'ye istek atması) varsayılan olarak kapalıdır:

# Mevcut boolean'ları listele
getsebool -a | grep httpd

# Web sunucusunun ağ bağlantısı kurmasına kalıcı izin ver
setsebool -P httpd_can_network_connect on

Bu ince ayarlı yapı SELinux'u son derece güçlü ama başlangıçta öğrenmesi dik bir yokuş yapar. "SELinux sorun çıkarıyor, kapatayım" refleksi çok yaygındır; oysa doğru çözüm neredeyse her zaman bir etiket düzeltmek ya da bir boolean açmaktır.

AppArmor: Yol Tabanlı Profiller#

AppArmor, Ubuntu ve Debian ailesinin varsayılan MAC sistemidir ve SELinux'a kıyasla çok daha yalın bir zihinsel model sunar. Etiketlerle değil, dosya yollarıyla çalışır. Her uygulama için bir profil yazılır; profil, "bu program hangi dosya yollarına, hangi izinlerle erişebilir; hangi yeteneklere (capability) sahiptir; hangi ağ işlemlerini yapabilir" sorularını doğrudan yol ifadeleriyle yanıtlar. Bir dosyaya özel bir etiket iliştirmek gerekmez; kural doğrudan yolun kendisine yazılır.

Profiller /etc/apparmor.d/ altında düz metin dosyaları olarak durur ve okuması oldukça sezgiseldir:

# /etc/apparmor.d/usr.sbin.nginx (basitleştirilmiş)
/usr/sbin/nginx {
  #include <abstractions/base>

  capability net_bind_service,

  /var/www/**            r,     # web içeriğini oku
  /var/log/nginx/*.log   w,     # log yaz
  /etc/nginx/**          r,     # yapılandırmayı oku
  /run/nginx.pid         rw,

  # Başka her şey örtük olarak reddedilir
}

Bu profil sayesinde Nginx sadece /var/www altını okuyabilir, /var/log/nginx altına yazabilir; profilde geçmeyen /home ya da /root gibi yollara erişmeye çalışırsa çekirdek reddeder. Yol tabanlı olmasının pratik bir avantajı vardır: profili okuyarak bir uygulamanın "neye dokunabildiğini" bir bakışta görürsünüz, çünkü izinler doğrudan gerçek yollar olarak yazılıdır.

AppArmor'un durumunu ve yüklü profilleri görmek için:

sudo aa-status
# apparmor module is loaded.
# 32 profiles are loaded.
# 30 profiles are in enforce mode.
#    /usr/sbin/nginx
#    /usr/sbin/mysqld
# 2 profiles are in complain mode.

Yeni bir uygulama için profil oluşturmanın en pratik yolu, uygulamayı önce "öğrenme" kipinde çalıştırıp gerçekte hangi kaynaklara eriştiğini gözlemlemek, sonra bu gözlemleri profile dökmektir:

# Bir program için taslak profil üret ve etkileşimli olarak öğren
sudo aa-genprof /usr/sbin/nginx

# Sonradan loglardan çıkan yeni erişimleri profile işle
sudo aa-logprof

AppArmor genellikle "başlaması kolay, ileri düzeyde SELinux kadar granüler değil" diye özetlenir. Küçük ve orta ölçekli sunucularda, tek tek servisleri hızlıca hapsetmek istediğinizde AppArmor pratik bir tercihtir.

SELinux ve AppArmor Karşılaştırması#

İki sistem de aynı hedefe (MAC ile süreç izolasyonu) koşar ama tasarım felsefeleri farklıdır. Aşağıdaki tablo, bir sunucu yöneticisinin karar verirken bakacağı temel farkları özetliyor:

Pratik tavsiye basittir: dağıtımınızın varsayılan MAC sistemiyle çalışın. RHEL tabanlı bir sunucuda SELinux'u kapatıp AppArmor kurmaya çalışmak zaman kaybıdır; SELinux o ekosistemde çok daha olgun paket desteğine sahiptir. Aynı şekilde Ubuntu'da varsayılan gelen AppArmor'u devre dışı bırakıp SELinux'a geçmek nadiren mantıklıdır. İkisi de aynı LSM çerçevesini kullandığı için tipik olarak aynı anda yalnızca biri etkin olur. Hangi dağıtımın hangi MAC'la geldiğini bilmek, sunucunuz için işletim sistemi seçerken de dikkate almanız gereken bir ayrıntıdır.

Enforcing ve Permissive Kip#

Her iki sistemde de en kritik kavram kip (mode) ayrımıdır ve yeni yöneticilerin en çok kafasının karıştığı yer burasıdır. İki temel kip vardır:

• Enforcing (zorlayıcı): Politika hem kararı verir hem de uygular. Bir erişim politikaya aykırıysa gerçekten engellenir ve loglanır. Üretim ortamında olmanız gereken kip budur.
• Permissive (izin verici): Politika kararı verir ve ihlalleri loglar ama engellemez. Yani her erişim geçer, sadece "bu enforcing olsaydı reddedilirdi" notu düşülür. Bu kip, yeni bir politikayı devreye almadan önce hangi erişimlerin patlayacağını görmek için altın değerindedir.

SELinux'ta kipi geçici (yeniden başlatana kadar) değiştirmek için:

# Anlık olarak permissive'e geç (test için)
sudo setenforce 0

# Geri enforcing'e dön
sudo setenforce 1

Kalıcı ayar /etc/selinux/config dosyasında yapılır. Buradaki kritik uyarı şudur: SELinux'u üretimde tamamen kapatmayın (disabled). Kapalıysa dosyalar etiketlenmemeye başlar; sonradan tekrar açmak istediğinizde tüm dosya sistemini yeniden etiketlemek gerekir ki bu uzun ve zahmetli bir işlemdir. Bir şey çalışmıyorsa disabled yerine geçici olarak permissive kullanın, sorunu çözün, enforcing'e dönün:

# /etc/selinux/config
SELINUX=enforcing
# Seçenekler: enforcing, permissive, disabled
SELINUXTYPE=targeted

AppArmor'da kip her profil için ayrı ayrı yönetilir. Bir profili öğrenme/izleme için complain (SELinux'taki permissive'in karşılığı), üretim için enforce kipine alırsınız:

# Bir profili complain (yalnızca logla) kipine al
sudo aa-complain /usr/sbin/nginx

# Sorun kalmadığında enforce (zorla) kipine geç
sudo aa-enforce /usr/sbin/nginx

Doğru iş akışı hep aynıdır: yeni bir servisi önce permissive/complain kipinde bir süre çalıştır, üreteceği ihlalleri topla, politikayı bu ihlaslara göre düzelt, sonra enforcing/enforce'a geç. Bu sayede bir gecede tüm servisleri kırma riskine girmeden MAC'ı devreye alırsınız.

Engellenen Erişimi Loglardan Çözmek#

MAC ile çalışırken kaçınılmaz olarak bir servis "sebepsiz yere" çalışmayı bırakacaktır: Nginx 403 döndürür, PHP dosya yazamaz, bir servis porta bağlanamaz. İlk refleksiniz dosya izinlerini (DAC) kontrol etmek olur, her şey doğru görünür ama servis yine de çalışmaz. İşte bu tablo klasik bir MAC engellemesi belirtisidir. İyi haber şu: MAC sessizce reddetmez, her reddi loglar. İş, o logları okumaya kalır.

SELinux'ta reddedilen erişimler AVC denied (Access Vector Cache) kayıtları olarak denetim günlüğüne düşer. Bunları ausearch ile süzebilirsiniz:

# Son reddedilen SELinux erişimlerini listele
sudo ausearch -m AVC -ts recent

# Örnek satır:
# avc: denied { read } for pid=1234 comm="nginx"
#   name="config.php" dev="vda1" ino=99
#   scontext=system_u:system_r:httpd_t:0
#   tcontext=unconfined_u:object_r:default_t:0 tclass=file

Bu satır her şeyi anlatır: httpd_t alanındaki Nginx, default_t tipiyle etiketlenmiş bir dosyayı okumaya çalışmış ve reddedilmiş. Sorun açıktır: dosya yanlış etiketli. Çözüm de bellidir, doğru tipi atayıp restorecon çalıştırmak. Karmaşık durumlarda audit2allow aracı, log kayıtlarına bakıp size gereken kuralı (hatta hazır bir politika modülü) önerebilir:

# Reddedilen kayıtlara bakıp önerilen kuralı üret
sudo ausearch -m AVC -ts recent | audit2allow -m mypolicy

# Bir modül derleyip yükle (gerçekten gerekliyse)
sudo ausearch -m AVC -ts recent | audit2allow -M mypolicy
sudo semodule -i mypolicy.pp

Burada bir uyarı şart: audit2allow çıktısını körü körüne uygulamayın. Bazen çıkan öneri, gerçekten gereken bir kuraldır; bazense saldırının kendisine kapı açar. Önce reddin neden oluştuğunu anlayın; genelde doğru çözüm yeni bir kural eklemek değil, yanlış etiketi düzeltmek veya bir boolean açmaktır.

AppArmor tarafında reddedilen erişimler çekirdek loglarına ve genelde journalctl/dmesg çıktısına düşer:

# AppArmor reddi kayıtlarını gör
sudo journalctl -k | grep -i apparmor
sudo dmesg | grep DENIED

# Örnek:
# apparmor="DENIED" operation="open" profile="/usr/sbin/nginx"
#   name="/home/user/data.txt" requested_mask="r"

Bu kayıt, Nginx profilinin /home/user/data.txt yolunu okumasına izin vermediğini söyler. aa-logprof aracını çalıştırdığınızda AppArmor bu reddi size gösterir ve "bu erişime izin ver / reddet / yoksay" diye interaktif olarak sorar; verdiğiniz cevaba göre profili otomatik günceller. Bu, AppArmor'un yol tabanlı olmasının en keyifli yanıdır: log okuma ve profil düzenleme neredeyse konuşma gibi ilerler.

Gerçek Senaryo: Ele Geçirilen Servisi Sınırlamak#

Tüm bu teoriyi tek bir somut senaryoda toplayalım. Diyelim ki sunucunuzda bir PHP uygulaması çalışıyor ve bir açık yüzünden saldırgan, web sürecine komut çalıştırma yeteneği kazandı. DAC dünyasında bu felakettir: saldırgan www-data kimliğiyle /etc/passwd içeriğini okur, varsa okunabilir yedek dosyalarını sızdırır, /tmp altına araç indirir ve yanal harekete (lateral movement) geçmeye çalışır.

Aynı sunucuda enforcing kipinde SELinux (ya da enforce kipinde AppArmor) etkinse tablo tamamen değişir. Web süreci httpd_t alanında hapsedildiği için politikada tanımlı olmayan hiçbir şeye dokunamaz. Saldırgan /etc/shadow okumaya kalkar, reddedilir ve loglanır. /tmp altına indirdiği bir ikili dosyayı çalıştırmayı dener, httpd_t alanında execmem/çalıştırma izni tanımlı olmadığı için engellenir. Başka bir servise bağlanmaya çalışır, boolean kapalıysa ağ çıkışı reddedilir. Saldırgan hâlâ web uygulamasını bozabilir ama makinenin geri kalanına sıçrayamaz. İşte MAC'ın vaadi tam olarak budur: ihlali önlemek her zaman mümkün olmasa da, ihlalin yayılma alanını (blast radius) küçük bir kutuya hapsetmek.

Bu yüzden MAC, tek başına bir güvenlik çözümü değil, katmanlı savunmanın en içteki halkasıdır. Güvenlik duvarı (WAF ve DDoS koruması) dış kapıyı tutar, güncel yazılım açıkları kapatır, güçlü kimlik doğrulama girişi zorlaştırır; MAC ise "her şeye rağmen içeri sızıldıysa ne olacak?" sorusunun cevabıdır. Bu katmanları tek tek kurmak yerine yönetimini profesyonel bir ekibe bırakmak isterseniz sunucu yönetimi hizmetimiz, sertleştirme ve MAC yapılandırmasını sizin adınıza üstlenir.

Sıkça Sorulan Sorular#

SELinux mü AppArmor mu daha güvenli?#

İkisi de olgun ve güçlü MAC sistemleridir; "daha güvenli" olan büyük ölçüde onu ne kadar doğru yapılandırdığınıza bağlıdır. SELinux daha granülerdir ve sistemdeki her nesneyi kapsar, bu yüzden çok sıkı politikalar yazmaya elverişlidir; AppArmor ise öğrenmesi ve doğru profilleri tutması daha kolaydır. En doğru seçim, kullandığınız dağıtımın varsayılan sistemiyle çalışmaktır çünkü paket desteği ve topluluk bilgisi o yönde çok daha zengindir.

SELinux sürekli sorun çıkarıyor, kapatsam olur mu?#

Kapatmak neredeyse her zaman yanlış çözümdür; bir servisi çalıştırmak için güvenliğin tamamını feda etmiş olursunuz. Karşılaştığınız engelleme genellikle yanlış bir dosya etiketinden ya da kapalı bir boolean'dan kaynaklanır ve ausearch ile logu okuyup restorecon veya setsebool çalıştırarak dakikalar içinde düzeltilebilir. Gerçekten sıkıştıysanız disabled yerine geçici olarak permissive kipine geçin, sorunu çözün ve tekrar enforcinge dönün.

Enforcing ile permissive kip arasındaki fark nedir?#

Enforcing kipinde politika ihlalleri hem loglanır hem de gerçekten engellenir, yani üretimde olmak istediğiniz kip budur. Permissive kipinde ise ihlaller yalnızca loglanır ama engellenmez; her erişim geçer. Permissive, yeni bir politikayı devreye almadan önce hangi erişimlerin reddedileceğini güvenli biçimde görmek ve profili buna göre düzeltmek için kullanılır.

AppArmor bir profili nasıl uyguluyor, dosyaları etiketlemeden nasıl çalışıyor?#

AppArmor etiket yerine dosya yollarıyla çalışır; her uygulama için /etc/apparmor.d/ altında bir profil vardır ve bu profil, uygulamanın hangi yollara hangi izinlerle erişebileceğini doğrudan yol ifadeleriyle listeler. Çekirdek, uygulama bir dosyaya erişmeye çalıştığında yolu profildeki kurallarla eşleştirir ve profilde geçmeyen her şeyi örtük olarak reddeder. Bu yüzden bir dosyaya özel bir etiket iliştirmeye gerek kalmaz, kural yolun kendisine yazılır.

Paylaşımlı hosting kullanıyorum, MAC yapılandırmasıyla uğraşmam gerekir mi?#

Hayır; paylaşımlı hosting ortamında sunucunun güvenlik sertleştirmesi, MAC dâhil, tamamen barındırma sağlayıcısının sorumluluğundadır ve sizin bu katmana erişiminiz olmaz. SELinux, AppArmor, boolean'lar ve profillerle uğraşmak, kök (root) erişiminiz olan sanal sunucu, VDS veya kendi yönetimindeki fiziksel sunucularda gündeme gelir. Yani MAC yönetimi, altyapının kontrolünü tümüyle elinize aldığınız senaryolarda konu olur.

Bir servis çalışmıyor, sorunun MAC kaynaklı olup olmadığını nasıl anlarım?#

En hızlı yöntem, dosya izinlerinin (DAC) doğru olduğundan eminken servisin hâlâ çalışmaması durumunda MAC loglarına bakmaktır. SELinux'ta sudo ausearch -m AVC -ts recent ile son reddedilen erişimleri, AppArmor'da sudo dmesg | grep DENIED ile engellenen işlemleri görürsünüz. Eğer bu komutlar servisiniz çökerken beliren denied satırları döndürüyorsa sorun büyük olasılıkla MAC kaynaklıdır ve çözümünü de yine o log satırındaki tip veya yol bilgisi gösterir.

Kapanış#

SELinux ve AppArmor, klasik izinlerin bıraktığı en tehlikeli boşluğu kapatır: "ele geçirilmiş bir servisin sınırsız yetkiyle dolaşması" senaryosunu. İkisi de aynı hedefe koşar, sadece farklı yollardan; SELinux etiketlerle her nesneyi kapsar, AppArmor yol tabanlı profillerle her uygulamayı hapseder. Doğru iş akışı her ikisinde de aynıdır: önce permissive/complain kipinde gözlemleyin, ihlalleri loglardan okuyup politikayı düzeltin, ardından enforcing/enforce'a geçip servisinizi güvenli bir kutuya kapatın. Bir şey çalışmadığında MAC'ı kapatmak yerine logu okumayı alışkanlık haline getirin; çözüm neredeyse her zaman bir etiket ya da bir satır uzağınızdadır.

Bu kontrolü sonuna kadar elinize almak ve MAC dâhil tüm güvenlik katmanlarını kendiniz yapılandırmak isterseniz kök erişimli VDS veya sanal sunucu seçeneklerimize göz atabilir; yapılandırmayı bize bırakmak isterseniz sunucu yönetimi hizmetimizle sertleştirmeyi uzman ekibimize devredebilirsiniz. Güvenlik yolculuğunuza temelden başlamak için sunucu güvenliği temelleri rehberimiz de iyi bir sonraki durak olacaktır.