sudo Güvenli Yapılandırma ve sudoers Rehberi

Bir sunucuda root parolasını üç kişiyle paylaşıp herkesin doğrudan süper kullanıcı olarak oturum açtığı bir düzen kurduysanız, teknik olarak sistem çalışır ama güvenlik açısından körsünüz demektir. Gece yarısı bir yapılandırma dosyası bozulduğunda, bir servis kapatıldığında ya da bir dizin yanlışlıkla silindiğinde "bunu kim yaptı?" sorusunun cevabı yoktur; çünkü herkes aynı isimsiz root kimliğinin arkasına saklanır. İşte sudo tam da bu kör noktayı ortadan kaldırmak için vardır. Amacı yalnızca "normal kullanıcıya root yetkisi vermek" değil, her yetkili işlemin arkasına gerçek bir isim, bir zaman damgası ve bir komut kaydı koyarak kimin ne yaptığını izlenebilir kılmaktır.

Bu rehberde sudo'yu bir kolaylık aracı olmaktan çıkarıp bir güvenlik ve denetim katmanına dönüştüreceğiz. sudoers dosyasının visudo ile neden ve nasıl güvenli düzenlendiğini, kullanıcı ve grup bazlı komut kısıtlamasının pratik yazımını, herkesin refleksle eklediği NOPASSWD seçeneğinin neden sessiz bir arka kapı olabileceğini ve sudo loglarını okuyarak bir olayı nasıl geriye doğru izleyeceğinizi tek tek göreceksiniz. Her bölümü, kıdemli bir sistem yöneticisinin yeni ekip arkadaşına sunucu başında anlattığı somut örneklerle işleyeceğiz; ezber kural değil, arkasındaki mantık üzerinde duracağız.

root Oturumu Yerine sudo: İzlenebilirlik Avantajı#

Doğrudan root ile çalışmanın en büyük sorunu yetkinin fazlalığı değil, hesap verilebilirliğin sıfır olmasıdır. root isimsiz bir kimliktir; kim olduğunuzu bilmez, ne yaptığınızı ayrı ayrı işaretlemez. Aynı parolayı bilen beş kişiden hangisinin rm -rf çalıştırdığını, hangisinin güvenlik duvarı kuralını değiştirdiğini sistem üzerinden ayırt etmenin hiçbir yolu yoktur. sudo bu tabloyu tersine çevirir: her kullanıcı kendi adıyla oturum açar, yükseltilmiş yetki gerektiren komutu sudo ile çalıştırır ve sistem "hangi gerçek kullanıcı, hangi komutu, ne zaman, hangi dizinde çalıştırdı" bilgisini kaydeder.

Somut olarak farkı görelim. Aşağıdaki iki satır aynı işi yapar ama biri iz bırakmaz, diğeri kalıcı bir kayıt üretir:

# root olarak oturum açıp çalıştırmak — hiçbir kişisel iz yok
systemctl restart nginx

# kendi kullanıcınızla, sudo ile — auth.log'a "ahmet" olarak yazılır
sudo systemctl restart nginx

İkinci komut çalıştığında /var/log/auth.log (Debian/Ubuntu) veya /var/log/secure (AlmaLinux/Rocky/CentOS) dosyasına şuna benzer bir satır düşer:

sudo: ahmet : TTY=pts/0 ; PWD=/home/ahmet ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx

Bu tek satırda denetim için gereken her şey var: kim (ahmet), hangi terminalden (pts/0), hangi dizinden (/home/ahmet), kimin adına (USER=root) ve tam olarak hangi komutu. Ekip büyüdükçe bu iz paha biçilmezdir. Ayrıca sudo yetkiyi kalıcı değil geçici verir; komut biter bitmez normal kullanıcı yetkinize dönersiniz, yani tüm gün "yıkıcı" modda dolaşmazsınız. Doğrudan root shell'inde geçirilen her dakika, yanlış bir tuşla tüm sistemi silme riskini taşırken; sudo bu riski yalnızca gerçekten ihtiyaç duyulan komuta indirger. Bu yaklaşım, en az yetki prensibinin günlük operasyondaki en görünür karşılığıdır.

Bir kullanıcıya sudo yetkisi vermek için onu ilgili yönetici grubuna eklemek yeterlidir. Debian/Ubuntu'da bu grup sudo, RHEL ailesinde wheel adını taşır:

# Debian / Ubuntu
adduser ahmet
usermod -aG sudo ahmet

# AlmaLinux / Rocky / CentOS
useradd ahmet && passwd ahmet
usermod -aG wheel ahmet

Kullanıcı bir sonraki oturumunda sudo çalıştırdığında kendi parolasını girer (root parolasını değil) ve varsayılan olarak bir süre (genelde 5 dakika) boyunca tekrar sorulmadan komut çalıştırabilir.

visudo ile Güvenli Düzenleme#

sudo'nun tüm kurallarını /etc/sudoers dosyası tutar. Bu dosyaya nano ya da vim ile doğrudan dokunmak, deneyimli yöneticilerin bile kaçınacağı bir hatadır. Sebebi basit ve acımasızdır: sudoers içinde tek bir sözdizimi hatası, sudo'nun tamamen çalışmayı reddetmesine yol açar. Eğer o anda sistemde başka bir root oturumunuz açık değilse ve yetki yükseltmenin tek yolu sudo ise, kendi sunucunuzdan kilitlenmiş olursunuz. Sadece bir eksik virgül yüzünden.

İşte bu felaketi önlemek için visudo vardır. visudo, dosyayı geçici bir kopya üzerinde açar ve siz kaydedip çıkmadan önce sözdizimini denetler. Bir hata bulursa dosyayı kesinlikle uygulamaz; size hatayı gösterir ve düzeltme, yeniden deneme ya da vazgeçme seçeneği sunar. Yani bozuk bir dosya asla yürürlüğe girmez.

# Ana sudoers dosyasını güvenli düzenle
sudo visudo

# Ayrı bir kural dosyasını (önerilen yöntem) güvenli düzenle
sudo visudo -f /etc/sudoers.d/web-operator

# Değişiklik yapmadan yalnızca sözdizimini denetle
sudo visudo -c

visudo'nun varsayılan editörü sistem ayarına bağlıdır; alışkın olduğunuz editörü kullanmak için ortam değişkeni verebilirsiniz:

sudo EDITOR=nano visudo

Modern kurulumların hepsi, ana /etc/sudoers dosyasının sonunda @includedir /etc/sudoers.d satırını taşır. Bu, sudoers.d dizinindeki her dosyanın otomatik olarak yüklenmesi demektir. Ana dosyaya hiç dokunmadan, her kural setini kendi ayrı dosyasında tutmak en temiz yöntemdir; bir kullanıcının yetkisini kaldırmak istediğinizde koca dosyayı kurcalamak yerine tek bir dosyayı silersiniz. Bu dosyaların izinleri de kritiktir; sudo, güvenli olmayan izinlere sahip bir kural dosyasını görmezden gelir:

sudo chmod 0440 /etc/sudoers.d/web-operator
sudo chown root:root /etc/sudoers.d/web-operator

Bir başka pratik güvenlik ağı: sudoers düzenlerken ikinci bir SSH oturumunu her zaman açık tutun ve o oturumda zaten sudo -i ile root olun. Böylece yeni kural bir şeyi bozarsa, açık kalan bu oturumdan geri alabilirsiniz. Bu küçük alışkanlık, uzaktaki bir sunucuda kilitlenme riskini pratikte sıfıra indirir.

sudoers Kural Anatomisi#

sudoers kurallarını yazabilmek için tek bir satırın nasıl okunduğunu anlamak yeterlidir. Temel kalıp şöyledir:

kullanıcı  makineler=(hangi_kullanıcı:hangi_grup)  KOMUTLAR

Klasik "tam yetki" satırını parçalayalım:

ahmet  ALL=(ALL:ALL)  ALL

Buradaki her alanın anlamı:

% işareti bir gruba işaret eder. Örneğin Ubuntu'nun varsayılan kuralı sudo grubundaki herkese tam yetki verir:

%sudo   ALL=(ALL:ALL) ALL

Kritik ayrıntı komut alanındadır. ALL yazdığınızda kullanıcı root olarak her şeyi yapabilir. Oysa gerçek güvenlik, o ALL yerine tam komut yollarının listesini koyduğunuzda başlar. Komutları mutlaka tam yol ile (/usr/bin/systemctl, /bin/systemctl gibi) yazın; çünkü systemctl gibi çıplak bir isim, kullanıcının PATH'ine sahte bir systemctl koyup onu root olarak çalıştırmasına kapı aralayabilir. Ayrıca sudo, komuta verilen argümanları da eşleştirir; yani systemctl restart nginx izni verirken kullanıcının systemctl stop firewalld çalıştırmasını engelleyebilirsiniz.

Tekrar eden komut listelerini Cmnd_Alias, kullanıcı gruplarını User_Alias ile adlandırmak kuralları hem okunur hem yönetilebilir kılar:

# Yeniden kullanılabilir takma adlar
Cmnd_Alias WEB_SERVIS = /bin/systemctl restart nginx, /bin/systemctl reload nginx
Cmnd_Alias LOG_OKUMA  = /usr/bin/tail /var/log/nginx/*, /usr/bin/less /var/log/nginx/*
User_Alias OPERATORLER = ahmet, mehmet

# Takma adları kullanan kural
OPERATORLER  ALL=(root) WEB_SERVIS, LOG_OKUMA

Bu blok "ahmet ve mehmet, root olarak yalnızca Nginx'i yeniden başlatabilir/yükleyebilir ve Nginx loglarını okuyabilir; başka hiçbir şey yapamaz" der. Yeni bir operatör eklemek User_Alias satırına bir isim yazmak kadar kolaydır.

Kullanıcı ve Grup Bazlı Komut Kısıtlama#

sudo'nun güvenlik açısından asıl değeri burada ortaya çıkar: kişiye yalnızca işini yapacak kadar komut vermek. "Herkese ALL verelim, nasılsa güveniyoruz" yaklaşımı en az yetki prensibinin tam tersidir ve güvendiğiniz kişinin hesabı ele geçirildiğinde tüm sistemi saldırgana teslim eder. Doğru yaklaşım, rolleri çıkarıp her role dar bir komut kümesi tanımlamaktır.

Birkaç gerçekçi rol örneğine bakalım. Önce bir deploy kullanıcısı — yalnızca uygulama servisini yönetebilsin, sunucunun geri kalanına dokunamasın:

# /etc/sudoers.d/deploy
deploy  ALL=(root) /bin/systemctl restart myapp, \
                    /bin/systemctl status myapp, \
                    /bin/journalctl -u myapp *

Sonra bir yedekleme operatörü — yalnızca yedek betiğini çalıştırabilsin, ama root shell'e düşemesin:

# /etc/sudoers.d/backup
%backup-ops  ALL=(root) /usr/local/bin/nightly-backup.sh

Bir de veritabanı bakımı yapan biri — MySQL servisini yönetsin ama başka servislere karışamasın:

# /etc/sudoers.d/dba
veli  ALL=(root) /bin/systemctl restart mariadb, /usr/bin/mysqldump *

Kısıtlama yazarken sık gözden kaçan bir tehlike var: bazı komutlar içeriden başka komut çalıştırmaya (shell escape) izin verir. Örneğin vim, less, nano, find, tar gibi araçlar root olarak verildiğinde, kullanıcı bunların içinden !sh ya da -exec ile root kabuğu açabilir. Yani "sadece log okusun diye" verdiğiniz sudo less /var/log/syslog, farkında olmadan tam yetkiye dönüşebilir. Bu yüzden bir komuta izin verirken "bu araç içeriden başka komut çalıştırabilir mi?" diye sormalısınız. Aşağıdaki tablo bu ayrımı özetler:

Root olarak dosya düzenletmek gerektiğinde vim/nano vermek yerine sudoedit (veya sudo -e) kullanın. sudoedit, dosyayı kullanıcının kendi düşük yetkili editörüyle geçici bir kopyada açar, kaydedince root olarak asıl dosyanın üzerine yazar; editörün kendisi hiçbir zaman root yetkisiyle çalışmadığı için shell escape riski ortadan kalkar:

# Kullanıcı yalnızca Nginx yapılandırmasını güvenle düzenleyebilir
webadmin  ALL=(root) sudoedit /etc/nginx/nginx.conf, sudoedit /etc/nginx/conf.d/*

Bu yaklaşım, dosya düzeyinde yetkilendirmeyi de anlamlı kılar; hangi kullanıcının hangi yapılandırmaya dokunabileceğini netleştirmek, Linux dosya izinleri mantığının sudo katmanındaki tamamlayıcısıdır.

NOPASSWD Neden Riskli?#

sudo'da bir komut çalıştırırken parola sorulması can sıkıcı gelir ve çözüm gibi görünen NOPASSWD seçeneği çok hızlı yayılır. Bu seçenek, belirtilen komutların parola sorulmadan çalışmasını sağlar:

deploy  ALL=(root) NOPASSWD: /bin/systemctl restart myapp

NOPASSWD her zaman kötü değildir; hatta otomasyon için çoğu zaman zorunludur. Ancak nerede kullanıldığı hayati önem taşır. Riski anlamak için şu senaryoyu düşünün: kullanıcının SSH anahtarı bir şekilde ele geçirildi ya da bir uygulama açığıyla saldırgan o kullanıcının kabuğuna düştü. Eğer o kullanıcıda NOPASSWD: ALL varsa, saldırganın ek olarak hiçbir parola bilmesine gerek yoktur; tek bir sudo -i ile anında root olur. Parola sorulsaydı, saldırganın önünde en azından bir engel daha olurdu. NOPASSWD: ALL, bu ikinci savunma hattını tamamen kaldırır.

Bu yüzden altın kural şudur: NOPASSWD'yi asla ALL ile birlikte kullanmayın; yalnızca tek tek, dar ve zararsız komutlara verin. Aradaki farkı görün:

# TEHLİKELİ — kullanıcı ele geçirilirse tüm sistem parolasız teslim
ci-bot  ALL=(root) NOPASSWD: ALL

# GÜVENLİ — yalnızca tek bir, önceden bilinen komut parolasız
ci-bot  ALL=(root) NOPASSWD: /bin/systemctl reload nginx

NOPASSWD'yi dar tutarken bile o komutun tehlikeli olmadığından emin olun. Az önceki shell escape uyarısı burada iki kat geçerlidir: NOPASSWD: /usr/bin/vim vermek, parolasız root shell'e davetiye çıkarmaktır. İzin verdiğiniz komut argüman almıyorsa, argümanı da sabitleyin ki kullanıcı systemctl reload nginx yerine systemctl reload diyerek başka bir hedefi yeniden yükleyemesin.

Parola sormanın rahatsızlığını NOPASSWD yerine daha güvenli iki ayarla yönetebilirsiniz. Birincisi, parolanın geçerli kaldığı süreyi (timeout) uzatmak; ikincisi, parolayı terminal bazında değil sadece o oturuma özel istemek:

# /etc/sudoers.d/00-defaults
Defaults        timestamp_timeout=15      # parolayı 15 dakika hatırla (varsayılan 5)
Defaults        timestamp_type=tty        # her terminal ayrı doğrulanır
Defaults        passwd_tries=3            # yanlış parola için 3 deneme
Defaults        badpass_message="Hatalı parola. Erişim reddedildi."

Bu ayarlar günlük kullanımda parola yorgunluğunu azaltırken, NOPASSWD'nin açtığı geniş kapıyı açmadan güvenliği korur. Otomasyon (CI/CD, cron) için NOPASSWD gerçekten gerekliyse, onu insan kullanıcılarına değil, yalnızca o iş için oluşturulmuş özel bir servis hesabına ve tek bir komuta bağlayın.

sudo Loglarını Denetleme#

sudo'nun tuttuğu kayıtları hiç okumuyorsanız, izlenebilirlik avantajının yarısını kullanmıyorsunuz demektir. Her sudo çağrısı — başarılı da olsa, reddedilmiş de olsa — kimlik doğrulama loguna yazılır. Dağıtıma göre dosya değişir:

# Debian / Ubuntu
sudo tail -n 50 /var/log/auth.log
sudo grep 'sudo:' /var/log/auth.log

# AlmaLinux / Rocky / CentOS
sudo tail -n 50 /var/log/secure

# systemd tabanlı sistemlerde (dağıtımdan bağımsız)
sudo journalctl _COMM=sudo --since "today"

Reddedilen sudo denemeleri özellikle değerlidir; birisi yetkisi olmayan bir komutu çalıştırmaya çalışıyorsa bu, ya bir yanlış yapılandırmanın ya da kötü niyetli bir girişimin ilk işaretidir. Bunları hızlıca süzmek için:

# Başarısız / reddedilmiş sudo girişimlerini bul
sudo grep -E 'NOT in sudoers|command not allowed|incorrect password' /var/log/auth.log

Standart log satırı "kim, ne zaman, hangi komut" sorularını yanıtlar ama komutun ne yaptığını göstermez. Yüksek güvenlik gerektiren ortamlarda sudo'nun oturum kaydı (I/O logging) özelliğini açarak, root olarak çalıştırılan komutun ekran çıktısını dahi kaydedebilirsiniz. Bu, bir olay sonrası "tam olarak ne yazıldı, ekranda ne görüldü" analizini mümkün kılar:

# /etc/sudoers.d/00-defaults
Defaults  log_output
Defaults  log_input
Defaults  iolog_dir=/var/log/sudo-io/%{user}

Bu ayarla kaydedilen oturumları sudoreplay ile bir film gibi geri oynatabilirsiniz:

# Kaydedilmiş sudo oturumlarını listele
sudo sudoreplay -l

# Belirli bir oturumu yeniden oynat
sudo sudoreplay TSID

Logların değeri, saklandıkları yerde de saldırganın onları silememesiyle doğru orantılıdır. Bu yüzden kritik sunucularda logları merkezi bir log sunucusuna ya da harici bir sisteme (syslog forwarding) göndermek iyi bir pratiktir; yerel dosyayı silen saldırgan, merkezdeki kopyayı silemez. En azından, log dosyalarının izinlerinin sıkı olduğundan ve düzenli olarak arşivlendiğinden emin olun. logrotate gibi bir araçla eski logları döndürmek, hem disk şişmesini önler hem de belirli bir geçmiş penceresini korur.

En Az Yetki Prensibiyle Bağlantı#

Buraya kadar anlattığımız her ayar — dar komut listeleri, NOPASSWD'nin sınırlanması, sudoedit, oturum kaydı — aslında tek bir güvenlik ilkesinin sudo katmanındaki uygulamasıdır: en az yetki (least privilege). Bu ilke, her kimliğin yalnızca işini yapabilmesi için gereken en az yetkiye sahip olması gerektiğini söyler. sudo, "her şey ya da hiçbir şey" ikilisini kırıp yetkiyi komut düzeyinde dilimlemenize izin verdiği için bu ilkeyi hayata geçiren en pratik araçtır.

Pratikte bunu alışkanlığa dönüştürmek için her yeni kural yazarken birkaç soruyu kendinize sorun. Bu kullanıcı gerçekten root olmalı mı, yoksa belirli üç komut mu yetiyor? Verdiğim komut içeriden başka bir şey çalıştırabilir mi? NOPASSWD zorunlu mu, yoksa alışkanlıktan mı ekliyorum? Hesap ele geçirilse saldırganın eline en fazla ne geçer? Bu soruların cevapları, geniş bir ALL satırını çoğu zaman üç dört satırlık dar bir kurala dönüştürür. Güvenlik duvarı, SSH sertleştirmesi ve düzenli yedekle birlikte bu katmanlı savunma, bir açık istismar edilse bile hasarı tek hesabın dar yetkileriyle sınırlar.

Sıkça Sorulan Sorular#

sudo ile su arasındaki fark nedir?#

su komutu sizi tümüyle başka bir kullanıcıya (genelde root) dönüştürür ve o kullanıcının parolasını ister; ondan sonra çalıştırdığınız her komut, isimsiz bir root oturumunda ayrım gözetmeden gerçekleşir ve tek tek loglanmaz. sudo ise sizi dönüştürmez; yalnızca tek bir komutu geçici olarak yükseltilmiş yetkiyle çalıştırır, kendi parolanızı ister ve her komutu kendi adınıza kaydeder. İzlenebilirlik, dar yetkilendirme ve root parolasını paylaşmama açısından modern sunucularda sudo neredeyse her zaman su'ya tercih edilir.

sudoers dosyasını neden doğrudan nano ile açmamalıyım?#

Doğrudan düzenlediğinizde sözdizimi hatası yapma ihtimaliniz vardır ve sudoers bozuk bir söz dizimini asla affetmez; tek bir eksik virgül sudo'nun tamamen çalışmayı reddetmesine ve sisteminizden kilitlenmenize yol açabilir. visudo dosyayı geçici bir kopyada açar, kaydetmeden önce söz dizimini denetler ve hata varsa değişikliği uygulamaz. Bu güvenlik ağı sayesinde bozuk bir dosya asla yürürlüğe girmez, bu yüzden sudoers düzenlemesi her zaman visudo üzerinden yapılmalıdır.

NOPASSWD kullanmak her zaman güvenlik açığı mıdır?#

Hayır, ancak nerede ve nasıl kullanıldığına bağlıdır. NOPASSWD: ALL gerçekten tehlikelidir çünkü o hesap ele geçirilirse saldırgan tek komutla parolasız root olur. Buna karşılık, NOPASSWD'yi yalnızca tek ve zararsız bir komuta (örneğin bir servisi yeniden yüklemeye) vermek, otomasyon için makul ve yaygın bir pratiktir. Kural şudur; NOPASSWD'yi asla geniş yetkiyle birleştirmeyin, mümkünse insan hesaplarına değil özel servis hesaplarına verin ve verdiğiniz komutun içeriden başka komut çalıştıramadığından emin olun.

Bir kullanıcıya sadece belirli komutları nasıl veririm?#

sudoers kuralının komut alanına ALL yerine izin verdiğiniz komutların tam yollarını virgülle ayırarak yazarsınız; örneğin deploy ALL=(root) /bin/systemctl restart myapp satırı yalnızca o servisi yeniden başlatma yetkisi verir. Komutları mutlaka tam yol ile yazın ve gerekiyorsa argümanları da belirtin ki kullanıcı başka bir hedefi yönetemesin. Tekrar eden komut kümeleri için Cmnd_Alias tanımlayıp aynı listeyi birden çok kurala vermek, yapılandırmayı hem okunur hem yönetilebilir kılar.

sudo ile çalıştırılan komutları nereden görebilirim?#

Her sudo çağrısı, dağıtıma göre /var/log/auth.log (Debian/Ubuntu) veya /var/log/secure (AlmaLinux/Rocky) dosyasına kim, ne zaman, hangi dizinde ve hangi komutu çalıştırdığı bilgisiyle yazılır; systemd sistemlerinde journalctl _COMM=sudo ile de görebilirsiniz. Reddedilen denemeleri süzmek için loglarda NOT in sudoers veya command not allowed ifadelerini aratmak iyi bir başlangıçtır. Daha ileri denetim için log_output ve log_input seçenekleriyle oturum kaydını açıp sudoreplay ile komutun tüm ekran çıktısını sonradan geri oynatabilirsiniz.

sudo yetkimi kaybettim, kendimi kilitledim, ne yaparım?#

Eğer bozuk bir sudoers dosyası yüzünden sudo çalışmıyorsa ve hâlâ açık bir root oturumunuz varsa, o oturumdan visudo ile hatayı düzeltmeniz yeterlidir. Açık oturum yoksa; fiziksel/konsol erişimi olan sunucularda kurtarma modunda (recovery/single-user) açılıp dosyayı düzeltebilir, bulut sunucularda ise sağlayıcının konsolundan (VNC/serial console) root olarak giriş yapıp pkexec visudo ya da kurtarma diskiyle onarabilirsiniz. Bu senaryoyu tümden önlemenin en kolay yolu, sudoers düzenlerken ikinci bir root oturumunu her zaman açık tutmaktır.

Kapanış#

sudo'yu doğru yapılandırmak, bir sunucuyu "çalışıyor" durumundan "güvenli ve denetlenebilir" durumuna taşıyan en yüksek getirili adımlardan biridir. Anahtar fikirler sade: root ile doğrudan oturum açmayı bırakıp her işlemi kendi adınıza sudo ile yapın, sudoers dosyasını yalnızca visudo ile düzenleyin, herkese ALL vermek yerine role göre dar komut listeleri yazın, NOPASSWD'yi yalnızca zorunlu ve zararsız komutlarla sınırlayın ve logları düzenli okuyarak izlenebilirliğin karşılığını alın. Bu alışkanlıklar, bir gün bir şey ters gittiğinde hasarı felaketten sıradan bir olaya indirger.

Bu düzeni kurabileceğiniz, root erişiminin tümüyle sizde olduğu bir altyapı arıyorsanız Clou.TR'nin VDS sunucu ve sanal sunucu paketleri tam kontrol sunar; kurulum ve sertleştirme sürecinde yanınızda olmamızı isterseniz sunucu yönetimi hizmetimizle sudo politikalarından güvenlik duvarına kadar yapılandırmayı sizin için üstlenebiliriz. Paylaşımlı bir ortamda bu ayrıntılarla uğraşmadan güvenli bir başlangıç isteyenler ise hosting paketlerimize göz atabilir. Güvenli sunucu, doğru yapılandırılmış yetkilerle başlar.