Ubuntu Server: LTS, Sıkılaştırma ve Dağıtım Seçimi

Bir kurumun araç filosunu yöneten kişiye hangi otomobilin en iyisi olduğunu sorarsanız, size en hızlısını ya da en gösterişlisini söylemez. Onun sorusu bambaşkadır: hangi aracı, elimdeki ekiple, beş yıl boyunca yolda tutabilirim? Bu soruyu sorduğu anda karar motor gücünden çıkar, yedek parça bulunabilirliğine, tamircinin o motoru tanıyıp tanımadığına ve arızanın ertesi gün mü yoksa üç hafta sonra mı çözüleceğine bağlanır. Filo yöneticisi araç satın almaz; beş yıllık bir bakım taahhüdü satın alır.

Kurumsal Linux dünyasında Ubuntu Server tam olarak bu filo aracının yerinde durur. En kararlı dağıtım değildir, en derin kurumsal destek sözleşmelerini sunmaz, en ince yapılandırma esnekliğini vermez. Ancak yedek parçası her yerde bulunur, her tamirci motorunu tanır ve arıza çıktığında aynı arızayı sizden önce yaşamış on kişi cevabı bir foruma bırakmıştır. Kurumsal tercihi belirleyen şey heyecan değil, operasyonel kararlılıktır.

Bu rehber iki soruyu birlikte cevaplıyor. Önce neyi imzaladığınızı: dağıtım ailelerinin birbirinden nerede ayrıldığını, LTS destek takviminin kaç yıl sürdüğünü, Ubuntu Pro’nun neyi genişlettiğini ve yükseltme penceresinin nasıl planlandığını. Ardından onu kurumsal disiplin altında nasıl tutacağınızı: paket ve depo yönetimini, servis kontrolünü, erişim disiplinini, sıkılaştırma katmanlarını ve Active Directory entegrasyonunu. Hangi dağıtımı seçeceğinize karar vermek için geldiyseniz doğrudan dağıtım karşılaştırmasına geçebilirsiniz.

Ubuntu Server Nedir, Masaüstü Ubuntu’dan Farkı Ne?

Ubuntu Server, Canonical’ın sunucular için ürettiği Ubuntu sürümüdür. Masaüstü Ubuntu’dan ayrıldığı yer sürüm numarası veya çekirdek değil, grafik arayüzün hiç kurulmamış olması ve kurulum medyasının sunucu rollerine göre paketlenmesidir. Aynı çekirdek, aynı paket deposu, farklı gövde: binek otomobil ile panelvanın aynı motoru paylaşması gibi.

Bu farkın pratik karşılığı üç yerde ortaya çıkar:

• Bellek ve işlemci, grafik arayüzü çizmek yerine servise gider.
• Saldırı yüzeyi küçülür, çünkü kurulu olmayan bir masaüstü bileşeninin açığı sizi ilgilendirmez.
• Yama yükü azalır, çünkü her kurulu paket güncellenmesi gereken bir kalemdir.

Üçüncü madde soyut kalmasın. Lab’daki ntp01 sunucusu sade bir zaman sunucusudur, üzerinde chrony dışında kayda değer bir şey çalışmaz. GLPI ajanının bu makineden topladığı envanter 785 yazılım paketi gösteriyor. Yani hiçbir şey yapmayan bir sunucuda bile 785 ayrı güncelleme kalemi var. Masaüstü ortamı eklediğinizde bu sayı katlanır ve her yeni kalem, bir gün bir güvenlik bülteninde adı geçebilecek bir satırdır.

Ne zaman gerekmez: masanızın altında duran, tek kişinin kullandığı ve dışarıya hiçbir servis vermeyen bir makine için masaüstü Ubuntu gayet yeterlidir. Sunucu sürümüne geçmeyi tetikleyen şey donanım değil, o makineye başkalarının bağımlı hale gelmesidir.

Linux, Dağıtım ve Aile: Karşılaştırmadan Önce Üç Kelime

Bir sonraki bölümde üç dağıtım ailesini karşılaştıracağız. O karşılaştırmanın işe yaraması için üç kelimenin yerine oturması gerekiyor, çünkü bu üç kelime Linux tarafında Windows’takinden başka türlü çalışır.

Linux aslında yalnızca çekirdektir. Çekirdek, donanımla doğrudan konuşan katmandır: belleği paylaştırır, süreçleri sıraya koyar, diske ve ağ kartına erişimi yönetir. Yaptığı iş bundan ibarettir ve tek başına kullanılamaz. Üstüne kabuk, paket yöneticisi, servis yöneticisi ve yüzlerce araç giydirilmeden ortada açıp kullanabileceğiniz bir sistem yoktur.

Dağıtım, o giydirme işinin adıdır. Bir dağıtım; çekirdeği, sistem araçlarını, paket deposunu ve bunları bir arada tutan kurulum düzenini tek ürün olarak paketler. Ubuntu bir dağıtımdır, Debian bir dağıtımdır, Rocky Linux bir dağıtımdır. Pratik sonucu şudur: “Linux kurdum” cümlesi tek başına eksiktir. Her zaman bir dağıtım kurulur ve hangisini kurduğunuz, sonraki beş yılın komutlarını ve destek takvimini belirler.

Aile ise dağıtımların soyudur. Dağıtımlar sıfırdan yazılmaz, çoğu var olan bir dağıtımdan türer: Ubuntu Debian’dan, Rocky Linux ve AlmaLinux ise Red Hat Enterprise Linux’tan (RHEL) türemiştir. Soy dekoratif bir bilgi değil, günlük işin kendisidir. Paket biçimini (.deb mi .rpm mi), paket komutunu (apt mı dnf mü) ve yapılandırma dosyalarının nerede duracağını belirleyen şey ailedir. İnternette bulduğunuz bir çözüm aynı aileden bir dağıtım için yazılmışsa çalışır, değilse komutlar tanınmaz.

Filo benzetmesini sürdürürsek: çekirdek motordur, dağıtım o motorun etrafına kurulmuş tam araçtır, aile ise aynı platformu paylaşan model ailesidir. Windows’tan gelen bir yöneticinin zihnindeki model tek üretici, tek ürün, sürümler şeklindedir; Linux’ta model tek çekirdek, çok üretici, aileler şeklinde çalışır. Bir sonraki bölümdeki karşılaştırmanın “hangisi daha hızlı” değil “hangi ekosisteme giriyorsunuz” sorusu etrafında dönmesinin sebebi budur.

Neden Ubuntu Server? Debian ve RHEL Ailesiyle Karşılaştırma

Kurumsal Linux tercihi pratikte üç aile arasında yapılır: Ubuntu, Debian ve RHEL soyundan gelen Rocky Linux ile AlmaLinux. Aralarındaki fark hız, güvenlik veya kararlılık değil; arkalarındaki tedarik zinciri ve usta havuzudur. Filo benzetmesini sürdürelim: üç aracın da motoru sağlamdır, ayrıldıkları yer yedek parçanın hangi şehirde bulunduğu ve o motoru kaç tamircinin tanıdığıdır.

Ubuntu Server: Ekosistem Genişliği

Ubuntu’nun kurumsal tercihte öne çıkmasının sebebi teknik üstünlük değil, ekosistem genişliğidir. Docker dokümantasyonu Ubuntu üstünde örneklenir, Kubernetes kurulum kılavuzları Ubuntu referansı verir, Zabbix, GLPI, Nginx ve PostgreSQL paketlemeleri Ubuntu depolarında güncel tutulur.

Bunun sahadaki karşılığı gece üçte belli olur. Bir servis beklenmedik bir hata verdiğinde ihtiyacınız olan şey en zarif çözüm değil, aynı hatayı sizden önce yaşamış birinin bıraktığı nottur. Ubuntu’da o not neredeyse her zaman vardır. Bu bir mühendislik iddiası değil, bir lojistik iddiasıdır ve kurumsal kararı belirleyen şey çoğu zaman tam olarak budur.

Serçe Bilişim olarak KOBİ ve orta ölçekli kurumlarda varsayılan Linux tercihimiz Ubuntu Server’dır. Lab ortamımızdaki zaman sunucusu, LDAP sunucusu, RADIUS sunucusu ve GLPI sunucusunun tamamı Ubuntu 24.04 LTS üzerinde çalışıyor.

Debian: Daha Yavaş Dönen, Daha Az Değişken

Debian, Ubuntu’nun üzerine kurulduğu üst kaynaktır ve tercih edilme sebebi değişkenliğinin düşük olmasıdır. Canonical, Debian’ın geliştirme dalından paketleri alır, sabitler, kendi paketlemesini ve destek taahhüdünü ekler; Ubuntu bu işlemin çıktısıdır. Yani Debian seçmek, aradaki bu katmandan vazgeçmek demektir.

Filo karşılığı şudur: Debian, on yıl elinizde tutmayı planladığınız araçtır. Sürüm döngüsü daha yavaştır, paketler daha eskidir ve tam olarak bu yüzden daha az sürpriz üretir. “Kurulsun ve yıllarca uğraşmayayım” diyen bir sistemci için doğru tercihtir.

Ne zaman Debian’a geçilir: paketlerin en güncel sürümüne ihtiyacınız yoksa, ortamı yılda birkaç kez elden geçirecek vaktiniz yoksa ve Canonical’ın destek sözleşmesiyle işiniz olmayacaksa. Bu üç madde birden tutuyorsa Debian, Ubuntu’dan daha rahat bir hayat sunar.

Rocky Linux ve AlmaLinux: CentOS Sonrası RHEL Ailesi

Rocky Linux ve AlmaLinux, CentOS’un 2021’de yön değiştirmesiyle doğan boşluğu dolduran topluluk dağıtımlarıdır. Olan şuydu: CentOS, Red Hat Enterprise Linux’un ücretsiz ve birebir kopyası olmaktan çıkıp CentOS Stream’e dönüştü, yani RHEL’in aşağısında değil yukarısında, test sahası konumuna geçti. Kurumsal kullanıcı için bu, altındaki zeminin kayması anlamına geldi.

Bu ailede kalmanın tek bir ciddi gerekçesi vardır ve o gerekçe sizin tercihiniz değildir: yazılım sağlayıcınızın sertifikasyonu. Kurumsal bir ERP, yedekleme ürünü veya veritabanı yalnız RHEL üstünde destekleniyorsa dağıtım kararınız zaten verilmiştir. O durumda Ubuntu’da çalıştırmak teknik olarak mümkün olsa bile, arıza anında sağlayıcı desteği kapıda durur.

Hangi Dağıtım Hangi Senaryoda?

Destek Yaşam Döngüsü: LTS, ESM ve Ubuntu Pro

Aileyi seçtiniz, diyelim ki Ubuntu. Sıradaki karar aynı ailenin hangi sürümünü kuracağınız ve bu, göründüğünden büyük bir karardır. Ubuntu’da bir sürüm seçmek, o sürüm için kaç yıl güvenlik yaması alacağınızı seçmek demektir. Filo yöneticisinin “bu modelin yedek parçası kaç yıl daha bulunur” sorusunun birebir karşılığıdır ve altyapı planlamasının zeminidir.

LTS Sürümler Ne Kadar Destekleniyor?

LTS (Long Term Support) sürümleri iki yılda bir, çift sayılı yılların nisan ayında çıkar ve beş yıl standart güvenlik desteği alır. Sürüm numarası tarihin kendisidir: 24.04, 2024 yılının nisan ayı demektir. Aralardaki ara sürümler yalnız dokuz ay desteklenir ve üretim sunucusunda işleri yoktur.

Desteğin bitmesi neyi değiştirir? Bu soruyu somutlaştırmak önemli, çünkü sezgi burada yanıltıyor. Sunucu kapanmaz, bir uyarı ekranı çıkmaz, hiçbir servis durmaz. Değişen tek şey şudur: o tarihten sonra yayınlanan açıklar için sizin sürümünüze yama üretilmez. Yamanın gecikmesi değil, hiç var olmaması söz konusudur. Destek bitiminin ertesi günü yayınlanan bir güvenlik açığı, o makinede ömür boyu açık kalır ve size bunu kimse söylemez.

Ubuntu Pro ve Genişletilmiş Güvenlik Bakımı

Ubuntu Pro, beş yıllık standart desteği on yıla çıkaran abonelik programıdır; uzatılan kısma ESM (Expanded Security Maintenance) adı verilir. Kişisel kullanımda beş makineye kadar ücretsizdir, ticari kullanımda ücretlidir.

Ama Pro’nun asıl önemli tarafı süre uzatması değil, çoğu kurumun hiç fark etmediği bir boşluğu kapatmasıdır. Ubuntu depoları ikiye ayrılır:

• main: Canonical’ın kendi taahhüdü altındaki paketler. Beş yıllık standart destek yalnız burayı kapsar.
• universe: topluluk tarafından bakılan, çok daha kalabalık depo. Standart destek buraya söz vermez.

Buradaki tuzak şudur: kurumsal yığınların büyük kısmı universe deposundaki paketlere dayanır. Yani “beş yıl desteğim var” diyen bir kurumun gerçek destek penceresi sandığından dar olabilir. Ubuntu Pro, ESM kapsamını universe’e de genişleterek bu boşluğu kapatır.

Ne zaman gerekmez: sunucularınızı zaten üç yılda bir yeniden kuruyorsanız, on yıllık destek size satın almadığınız bir şey satar. Pro’nun değeri, donanımı ve kurulumu uzun süre yerinde tutan kurumlar için ortaya çıkar.

Sürüm Yükseltme Penceresini Planlamak

Yükseltmeyi destek bitişine göre değil, bir sonraki LTS’in olgunlaşmasına göre planlayın. Filo mantığı burada da aynıdır: kimse tüm filoyu aynı hafta değiştirmez, araçlar sırayla ve planlı çıkar.

Pratik kural şudur: yeni bir LTS çıktığında ilk sürümüne değil, ilk ara sürümüne geçin. Bu, 24.04 yerine 24.04.1 beklemek demektir; ilk aylarda çıkan kurulum ve sürücü sorunları o ara sürümde toplanır. Lab ortamımızdaki bütün Ubuntu sunucuları bu yüzden 24.04.4 üstünde çalışıyor.

LTS’ten LTS’e yükseltme şu komutla yapılır:

sudo do-release-upgrade

Yükseltmeden önce iki şey zorunludur: sunucunun tam yedeği ve yükseltmenin konsoldan veya kalıcı bir oturumdan çalıştırılması. SSH oturumu yükseltmenin ortasında düşerse yarım kalmış bir paket ağacıyla baş başa kalırsınız.

Ubuntu Server Kurulumu ve İlk Yapılandırma

Buraya kadarki kararların hepsi kurulum daha başlamadan verildi: hangi aile, hangi sürüm, kaç yıllık destek. Şimdi sıfırıncı güne dönüyoruz.

Ubuntu Server kurulumu yarım saatlik bir iştir, ama içindeki iki karar yıllarca sizinle kalır: diski nasıl böldüğünüz ve ağı nasıl yapılandırdığınız. Diski LVM olmadan kurarsanız kapasiteyi büyütmek çoğu zaman sistemi yeniden kurmak demektir; ağı DHCP’de bırakırsanız sunucunun adresi bir sabah değişir ve ona bağlı ne varsa kırılır. Geri kalan ekranlar (dil, klavye, mirror, snap listesi) birkaç saniyede geçilir.

Kurulum sırasında atlanmaması gereken tek kutucuk OpenSSH sunucusudur; işaretlenmezse sunucuya uzaktan bağlanamaz, konsola inmek zorunda kalırsınız.

Ağ tarafında Ubuntu’nun kurumsal ortamda en çok can yakan davranışı burada saklıdır ve bunu geçen hafta bizzat yaşadım. Lab’daki ntp01 sunucusunu DHCP’den statik 192.168.1.15 adresine taşırken netplan yapılandırmasını yazdım, uyguladım, adres oturdu. Sunucuyu yeniden başlattığımda adres DHCP’ye geri dönmüştü.

Sebebi şu: Ubuntu’nun sunucu kurulumu netplan’ı doğrudan yönetmez, cloud-init üzerinden yönetir. Siz /etc/netplan/50-cloud-init.yaml dosyasını elle düzenlediğinizde değişiklik o an geçerli olur; ancak açılışta cloud-init aynı dosyayı kendi kaynağından yeniden üretir ve sizin yazdığınızın üstüne yazar. Dosya adındaki 50-cloud-init kısmı zaten bunu söylüyor, ama ilk kez karşılaşan biri için görünmez bir tuzaktır.

Çözüm, cloud-init’in ağ yönetimini devre dışı bırakmaktır:

# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
network: {config: disabled}

Bu dosya oluşturulduktan sonra netplan yapılandırması kalıcı olur:

network:
  version: 2
  ethernets:
    ens33:
      dhcp4: false
      addresses:
        - 192.168.1.15/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [192.168.1.1]

Kurulum medyasının başlatılmasından disk düzenine, statik IP tanımından kurulum sonrası ilk kontrollere kadar bütün adımlar ekran görüntüleriyle Ubuntu Server kurulumu rehberinde anlatılıyor.

Ubuntu’da Paket ve Depo Yönetimi

Sunucu ayakta ve ağda. Bundan sonra üstüne koyacağınız her şey tek bir kapıdan geçecek: paket yöneticisi.

Ubuntu’da yazılım kurmak, filoya yedek parça takmaya benzer: parçanın kendisi kadar nereden geldiği de önemlidir. Orijinal parça, yan sanayi ve internetten gelen kutu aynı vidayı tutuyor olabilir; ama arıza çıktığında sorumluluğu kimin üstlendiği farklıdır.

APT: Paket Kurmak ile Depo Yönetmek Aynı Şey Değil

apt install komutu paketi sihirli bir yerden indirmez; sunucunuzda tanımlı depolardan indirir. Yani asıl karar paketi kurarken değil, depoyu eklerken verilir.

Ubuntu’nun kendi depoları dört bileşene ayrılır:

• main: Canonical’ın desteklediği, açık kaynaklı çekirdek paketler.
• universe: topluluk tarafından bakılan açık kaynaklı paketler.
• restricted: açık kaynak olmayan sürücüler.
• multiverse: lisansı kısıtlı yazılımlar.

Üçüncü taraf depolar (PPA’lar) bu listenin dışındadır ve eklerken farkında olunması gereken bir şey vardır: bir paket kurulurken kendi betiklerini root yetkisiyle çalıştırır. Yani bir depo eklemek, o deponun sahibine sunucunuzda root düzeyinde güven vermek demektir. Bu, imza doğrulamasının atlanabildiği bir açık değil, paket sisteminin tasarımıdır. Sorulacak soru “bu paket güvenli mi” değil, “bu depoyu kim yönetiyor ve yarın da yönetecek mi” olmalıdır.

Kurulu paket sayısı bu yüzden bir bakım göstergesidir. Az önce verdiğim rakamı hatırlayın: sade bir zaman sunucusunda 785 paket. Her biri bir gün bir güvenlik bülteninde geçebilir.

Güvenlik Yamalarını Otomatikleştirmek

Güvenlik yamalarını elle takip etmek ölçek büyüdükçe imkansızlaşır; Ubuntu bunu unattended-upgrades paketiyle otomatikleştirir:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Sahada tavsiyem yalnız güvenlik yamalarını otomatiğe almaktır, tüm güncellemeleri değil. Güvenlik yaması geriye dönük uyumluluğu korumaya çalışır; sürüm yükselten bir güncelleme ise gece yarısı bir servisin yapılandırma dosyasını değiştirebilir.

Bir de herkesin atladığı ikinci yarısı var. Yamalanmış bir çekirdek, sunucu yeniden başlatılana kadar sizi korumaz. Yeni çekirdek diske yazılır ama çalışan sistem hala eskisidir. Ubuntu bunu bir dosyayla bildirir:

ls /var/run/reboot-required

/var/run/reboot-required

Bu dosya varsa bekleyen bir yeniden başlatma var demektir. Yeniden başlatma penceresi olmayan sistemler için Ubuntu Pro kapsamındaki Livepatch, çekirdek yamalarını sunucuyu kapatmadan uygular; kritik çalışma saatleri olan kurumlarda Pro’nun en somut karşılığı budur.

Servis Yönetimi: systemd

Bir önceki bölüm yeniden başlatmayla bitti: çekirdek yaması ancak sunucu kapanıp açılınca devreye giriyordu. Peki sunucu yeniden açıldığında üstündeki servisler geri gelecek mi? Bu sorunun cevabı systemd’dedir ve göründüğü kadar kesin değildir.

systemd, modern Linux dağıtımlarında sistemin ilk başlayan süreci (PID 1) ve bütün servislerin yöneticisidir. Servisleri başlatır, durdurur, bağımlılık sırasını çözer ve çöktüklerinde yeniden ayağa kaldırır.

Mekanizmasını anlamak, komutları ezberlemekten daha faydalı. systemd’nin merkezinde unit dosyası vardır ve bu dosya üç şeyi bildirir: ne çalıştırılacak, önce neyin hazır olması gerekiyor, ve süreç öldüğünde ne yapılacak. Asıl değer ilk maddede değil, ikincisindedir: systemd servisleri sırayla değil, bağımlılık grafiğine göre paralel başlatır. Veritabanına ihtiyaç duyan bir uygulama, veritabanı hazır olmadan başlatılmaz; ama birbirinden bağımsız on servis aynı anda ayağa kalkar.

Filo karşılığı sabah çıkışıdır. Kötü işleyen bir depo araçları teker teker, sırayla yola çıkarır: en öndeki gecikirse arkadaki on araç bekler. systemd böyle çalışmaz. Bütün araçlar aynı anda çıkar; yalnız yükünü bekleyen araç bekler, ve yalnız kendi yükünü bekler, başkasınınkini değil.

Günlük kullanımda dört komut işinizi görür:

systemctl status chrony      # servis çalışıyor mu, son ne oldu
sudo systemctl restart chrony # yeniden başlat
sudo systemctl enable chrony  # açılışta otomatik başlasın
journalctl -u chrony -n 50    # bu servisin son 50 log satırı

Sahada en sık gördüğüm hata start ile enable arasındaki farkın atlanmasıdır. systemctl start servisi şimdi başlatır, systemctl enable ise açılışta başlamasını sağlar. Yalnız start yapılmış bir servis o gün sorunsuz çalışır; sunucu haftalar sonra bir elektrik kesintisinde yeniden başladığında ise geri gelmez. Arıza, kurulumdan aylar sonra ve kurulumla hiç ilişkilendirilmeyecek bir anda ortaya çıkar.

Ubuntu’da Kullanıcı, Yetki ve SSH Erişimi

Servisleri ayakta tutmayı çözdük; sıra o servislerin durduğu makineye kimin girebileceğinde. Buradan itibaren üç bölüm aynı işi katman katman kuruyor: önce kim girer, sonra girince ne yapabilir, en sonda kimliği nereden alır.

İlki hepsinden önce gelir. Filo dilinde: aracı kimin kullandığını bilmiyorsanız, arkasına taktığınız kamera bir işe yaramaz.

sudo Disiplini ve Servis Hesapları

Doğru disiplin, normal kullanıcı hesabıyla oturum açıp yalnız gerekli komutlar için sudo kullanmaktır. Gerekçesi konfor değil, izlenebilirliktir.

Kırılma noktasını somutlaştıralım. Üç kişilik bir sistem ekibi düşünün; üçü de doğrudan root kabuğunda çalışıyor. Bir sabah kritik bir yapılandırma dosyasının değiştiğini fark ediyorsunuz. Denetim kaydına bakıyorsunuz ve orada tek bir isim var: root. Üç kişiden hangisinin, hangi saatte, hangi niyetle yaptığını öğrenmenin hiçbir yolu yok. Aynı ekip kendi hesaplarıyla girip sudo kullansaydı, her komut /var/log/auth.log içinde kimlikli olarak duruyor olacaktı.

Servis hesapları ayrı bir disiplindir: bir uygulamanın çalıştığı hesabın oturum açması gerekmez. Bu hesaplara kabuk olarak /usr/sbin/nologin verilir, ev dizini açılmaz ve etkileşimli girişleri kapatılır. Böylece o hesap ele geçirilse bile saldırgana bir kabuk açılmaz.

SSH Anahtar Tabanlı Kimlik Doğrulama

Sunucuya uzaktan erişimin tek kapısı genellikle SSH’dir ve bu kapının sıkılaştırılması her şeyden önce gelir. Yapılacaklar /etc/ssh/sshd_config dosyasında toplanır:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
MaxAuthTries 3

Buradaki asıl kazanç PasswordAuthentication no satırıdır ve neden kazanç olduğunu görmek için mekanizmaya bakmak gerekir. Şifreyle girişte şifreniz sunucuya gider; sunucu ele geçirilmişse şifreniz de gitmiştir. Anahtarla girişte ise özel anahtarınız makinenizden hiç çıkmaz. Sunucu size rastgele bir veri gönderir, istemciniz onu özel anahtarla imzalar, sunucu daha önce kaydettiğiniz açık anahtarla imzayı doğrular. Sunucu hiçbir aşamada özel anahtarı görmez, dolayısıyla ele geçirilmiş bir sunucu bile onu öğrenemez.

Peki şifre girişi kapalıyken anahtarınızı kaybederseniz ne olur? Bu gerçek bir risktir ve cevabı “kaybetmeyin” değildir: sunucuya ikinci bir açık anahtar tanımlayın (ikinci bir yöneticinin veya güvenli saklanan bir kurtarma anahtarının) ve sanal makinelerde konsol erişimini açık tutun. Tek anahtarla çalışan bir sunucu, anahtar kaybolduğunda yeniden kurulur.

Ubuntu Sunucu Sıkılaştırma: Katmanlı Savunma

Kapıyı sağlamlaştırdık. Zincirin ikinci halkası, içeri girmeyi başaran birinin ne yapabileceğini sınırlamak.

Sıkılaştırma tek bir ayar değil, birbirini tamamlayan katmanlardır. Filo karşılığı TÜVTÜRK muayenesidir: araçta fren, lastik, far ve emisyon ayrı ayrı kontrol edilir, çünkü hiçbiri tek başına aracı yolda güvenli kılmaz ve kontrol yılda bir tekrarlanır.

Bu bölüm Ubuntu’ya özgü mekaniği anlatır. İşletim sisteminden bağımsız sıkılaştırma disiplini (denetim ritmi, kıyas ölçütleri, Windows ile ortak olan taraf) ayrı bir konudur ve kendi rehberini hak eder.

Güvenlik Duvarı: UFW ve nftables

UFW (Uncomplicated Firewall), Ubuntu’da iptables-nft uyumluluk katmanı üzerinden çalışan basitleştirilmiş bir güvenlik duvarı arayüzüdür. Varsayılan politika gelen trafiği kapatmak, giden trafiğe izin vermek üzerine kurulur:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

Sıralamaya dikkat edin, çünkü buradaki hata pahalıdır: ufw enable komutundan önce SSH’a izin vermezseniz uzak sunucuyla bağlantınız o saniye kopar ve konsola fiziksel erişiminiz yoksa geri dönüş yoktur. Sanal makinelerde konsol elinizin altındadır, bulut sunucusunda çoğu zaman değildir.

fail2ban ve Erişim Sınırlama

fail2ban, kimlik doğrulama kayıtlarını izler ve belirlenen eşiği aşan IP adreslerini geçici olarak engeller. Kaba kuvvet denemelerine karşı standart cevaptır.

Ama dürüst olalım: şifreyle girişi zaten kapattıysanız fail2ban’in koruma değeri ciddi biçimde düşer. Anahtar tabanlı bir sunucuda kaba kuvvet denemesi zaten başarısız olur. O noktada fail2ban’in asıl faydası güvenlik değil, log gürültüsünü azaltmasıdır. Kurulsun, ama onu birincil savunma sanmayın; birincil savunma bir önceki bölümdeydi.

AppArmor: Zorunlu Erişim Kontrolü

AppArmor, Ubuntu’da varsayılan olarak etkin gelen zorunlu erişim kontrolü (Mandatory Access Control) katmanıdır. Bir profil, sürecin hangi dosyalara ve yeteneklere erişebileceğini tanımlar.

Farkı kavramak için iki sorunun ayrıldığı yeri görmek gerekir. Klasik Unix izinleri “sen kimsin” diye sorar: bu kullanıcı bu dosyayı okuyabilir mi? AppArmor ise “sen hangi programsın” diye sorar: bu program, kendisini çalıştıran kullanıcının yetkisi ne olursa olsun, bu dosyaya dokunabilir mi? Bu yüzden ele geçirilmiş bir web sunucusu süreci, root yetkisine ulaşsa bile profilinin dışına çıkamaz.

Durumu görmek için:

sudo aa-status

Ubuntu Server ve Active Directory: Domain’e Katılım ve Kimlik

Zincirin son halkası kimliğin kendisi. Buraya kadar anlatılan her şey tek bir sunucuda geçerlidir: hesaplar orada açılır, anahtarlar oraya konur, kurallar orada tanımlanır. Ama aynı işi on sunucuda on kez yaparsanız elinizde disiplin değil, on ayrı hesap listesi olur ve işten ayrılan birini hepsinden tek tek silmeniz gerekir. Çözüm kimliği sunucunun dışına taşımaktır.

Ubuntu sunucular bir Active Directory domainine katılabilir ve kullanıcılar sunucuya kendi domain hesaplarıyla oturum açabilir. Katılım Active Directory şemasına dokunmaz; sunucu, domainde sıradan bir bilgisayar nesnesi olarak görünür.

Modern yöntem SSSD (System Security Services Daemon) ile realmd ve adcli araçlarıdır; daha eski kurulumlarda winbind görülür. Mekanizma şöyle işler: katılım sırasında domainde bir bilgisayar hesabı oluşturulur ve sunucuya bir keytab dosyası yazılır. Bu dosya, sunucunun domaine karşı kendini kanıtlamasını sağlayan gizli anahtarı taşır. Sonraki her oturum açma işlemi Kerberos üzerinden yürür; bilet alışverişinin nasıl çalıştığını Kerberos nedir rehberinde, dizin yapısının kendisini ise LDAP nedir makalesinde ele alıyoruz.

Sahada bu entegrasyonun en sık kırıldığı yer yapılandırma değil, saattir. Kerberos, istemci ile sunucu arasındaki zaman farkına yaklaşık beş dakika tolerans tanır; bu aşıldığında bilet doğrulaması reddedilir. Sorunun can sıkıcı tarafı, hata mesajlarının zamandan başka her şeyi işaret etmesidir: kimlik bilgisi, DNS, ağ. Ubuntu sunucuyu domaine katmadan önce saatini domain denetleyicisiyle aynı kaynağa bağlayın; iç zaman sunucusu kurulumunu Linux NTP sunucusu kurulumu rehberinde adım adım anlatıyoruz.

Domain tarafındaki yapının tamamı için Active Directory rehberimize göz atabilirsiniz.

Ubuntu Üzerinde Çalışan Kurumsal Araçlar

Kurulan, yamalanan, sıkılaştırılan ve kimliğe bağlanan bu sunucu sonuçta bir iş yapacak. Sırası geldi.

Kurumsal ağda Ubuntu sunucuların üstlendiği roller genellikle görünmez ama vazgeçilmezdir; filoda kimsenin fotoğrafını çekmediği, ancak durduğu gün her şeyin aksadığı servis araçları gibi.

En sık karşılaşılanlar şunlardır:

• Envanter ve helpdesk: Bu kategorideki açık kaynak araçların neredeyse tamamı, Linux çekirdeği üzerine kurulmuş bir yığını varsayarak yazılır: web sunucusu, veritabanı ve PHP. Alanın en yaygın açık kaynak ürünü olan GLPI de böyledir; kurulum dokümantasyonu, hazır paketleri ve topluluk cevapları Linux’u temel alır. Başka bir işletim sisteminde çalıştırmak teknik olarak mümkündür ama sizi, kimsenin yazmadığı sorunları tek başına çözen kişi yapar. Aracın kendisini GLPI nedir makalemizde ele alıyoruz.
• Zaman dağıtımı: Ağdaki her cihazın aynı saati göstermesi gerekir ve bu cihazların çoğu domain üyesi değildir: switch’ler, yazıcılar, kameralar, sanallaştırma sunucuları. chrony bu işin Linux tarafındaki standart uygulamasıdır, her dağıtımın temel deposunda gelir ve küçük bir sunucu bütün ağı tek kaynaktan besleyecek kadar yeterlidir. Kurulum ve doğrulama adımları Linux NTP sunucusu kurulumu rehberinde.
• Ağ erişim doğrulaması: Kablosuz ve switch erişimini merkezi hesaplara bağlayan RADIUS servisinin açık kaynak tarafındaki referans uygulaması FreeRADIUS’tur ve Linux üzerinde paketlenir. Aynı işin Windows tarafındaki karşılığı NPS’tir; seçim ürün kalitesinden çok hangi ekosistemde çalıştığınıza bağlıdır. Kurulumu Linux RADIUS sunucusu kurulumu rehberinde ele alıyoruz.
• Kimlik ve domain denetleyicisi: Ubuntu yalnızca bir domaine katılmakla kalmaz, domainin kendisini de barındırabilir. Samba’nın AD DC rolü dizini, Kerberos’u, DNS’i ve grup ilkesi dağıtımını tek kurulumda getirir; Windows istemciler bu domaine, karşılarında bir Windows sunucu varmış gibi katılır. Kurulum kararlarını ve provizyon sonrası doğrulamayı Samba AD DC kurulumu rehberinde ele alıyoruz.
• İzleme ve görselleştirme: Bu rol iki ayrı iştir ve karıştırıldığında yanlış ürün seçilir: ölçüm çekip eşik aşıldığında uyarmak, ve o ölçümleri tek panoda okunur kılmak. Açık kaynakta iki işi çoğu zaman iki ayrı ürün üstlenir; kategori kalabalıktır, Zabbix ile Grafana bizim tercih ettiğimiz çifttir. Ortak noktaları sunucu tarafının Linux’ta paketlenmesidir: ajanlar Windows dahil her platformu izler, izleyen sunucu Linux’ta durur. Bu ikiliyi pahalı bir ürünün yerine nasıl kurduğumuzu merkezi izleme vakamızda anlatıyoruz. SNMP tabanlı bant genişliği trendini ayrı tutan klasik araç Cacti’nin Ubuntu üzerine kurulumunu ise adım adım bir rehberde gösterdik.
• Merkezi log toplama: İzlemenin diğer ayağı, ve karıştırılmaması gerekiyor: izleme sayı çeker, log ise cihazın kendi cümlesini toplar. Ağdaki switch, firewall ve sunucular olay ürettikçe metin satırı gönderir; bu satırları merkezî bir yerde toplayan servis Linux’ta rsyslog’tur ve Ubuntu’da kutudan kurulu gelir, yapılması gereken iş paketi kurmak değil ağı dinlemesini açmaktır. Kurulumu, gönderen başına ayırmayı ve disk planını syslog sunucusu kurulum rehberinde anlatıyoruz.

Bu araçlarla ilgili sahada gördüğüm en sık hata, hepsini kurup sahip ve alarm politikası olmadan bırakmaktır. Zabbix bildirimi kurulur, herkes alır, kimse bakmaz; bir yıl içinde alarmlar gürültüye dönüşür ve kritik olay geldiğinde kimse fark etmez. Her aracın net bir sahibi olmalı ve yalnız kritik seviye alarmlar aktif bildirim kanalına düşmelidir.

Sonuç: Linux Ucuz Değil, Maliyeti Başka Yerdedir

“Her aracın net bir sahibi olmalı” dedik. O cümle aslında bütün rehberin özeti ve faturanın nereye kesildiğini de söylüyor.

Ubuntu Server’ın lisans satırı gerçekten sıfırdır ve bu, kurumsal bütçede görünen tek rakam olduğu için karar çoğu zaman burada verilir. Oysa filo yöneticisinin bildiği şeyi BT yöneticisi de bilmek zorundadır: aracın etiket fiyatı, o aracı beş yıl yolda tutmanın maliyeti değildir.

Linux’ta ödenmeyen lisans faturası yok olmaz, ekibe taşınır. Sunucuyu kuracak, yamalayacak, sürüm yükseltmesini planlayacak ve gece üçte açacak yetkinliğin bir karşılığı vardır; bu karşılık ya maaş bordrosunda ya da bir bakım sözleşmesinde görünür. Sahada gördüğüm en pahalı senaryo, bu iki kalemin de bütçelenmediği durumdur: sunucu kurulur, iki yıl sorunsuz çalışır, üçüncü yılda güncellemesi geçmiş ve kimsenin dokunmaya cesaret edemediği bir kutuya dönüşür. O noktada tasarruf edilen lisans bedeli, yeniden kurulum ve veri taşıma maliyetinin yanında küçük kalır.

Doğru soru “hangi işletim sistemi daha ucuz” değildir. Platform karşılaştırmasını Windows Server rehberimizde ayrıca ele alıyoruz, ama karar noktasında sorulacak soru her iki tarafta da aynıdır ve tek cümledir:

Bu sunucuya önümüzdeki beş yıl boyunca kim bakacak?

Bu sorunun net bir cevabı varsa Ubuntu Server, kurumsal altyapının en kararlı ve en ekonomik zeminlerinden biridir. Cevabı yoksa, işletim sistemi seçimi zaten sorunun kendisi değildir.

Sunucu altyapınızın kurulumu, sıkılaştırılması ve sürdürülebilir bakımı için BT Sistem Yönetimi hizmetimize göz atabilirsiniz.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.