unattended-upgrades ile Otomatik Güvenlik Güncellemeleri

Bir sunucuyu kurup çalıştırmaya başladıktan sonra en sık ihmal edilen iş, güvenlik güncellemelerini düzenli uygulamaktır. Sistem sorunsuz çalıştığı sürece kimse apt upgrade komutunu hatırlamak istemez; oysa açık kalan bir OpenSSL ya da sudo açığı, yayınlandığı günden itibaren otomatik tarayan botların hedefidir. Gerçek dünyada sunucuların büyük kısmı sıfır-gün açıklarıyla değil, aylar önce yaması çıkmış ama kimsenin uygulamadığı bilinen açıklarla ele geçirilir. İşte bu boşluğu kapatan araç, Debian ve Ubuntu ailesinde unattended-upgrades paketidir.

unattended-upgrades, arka planda çalışıp yalnızca belirlediğiniz depolardan (tipik olarak güvenlik deposundan) gelen paketleri sizin müdahaleniz olmadan kuran bir mekanizmadır. Doğru yapılandırıldığında sunucunuz her gün otomatik olarak güvenlik yamalarını çeker, ister e-posta ile ister log dosyalarıyla sizi bilgilendirir ve gerekiyorsa çekirdek güncellemesi sonrası önceden tanımladığınız bir bakım penceresinde kendini yeniden başlatır. Bu rehberde paketin kurulumundan hangi depoların açılacağına, otomatik reboot penceresinden bildirimlere ve olası kırılmaları yönetmeye kadar üretim ortamında kullanabileceğiniz sağlam bir yapılandırmayı adım adım kuracağız.

unattended-upgrades Nedir ve Nasıl Çalışır#

unattended-upgrades, APT'nin periyodik görev altyapısı üzerine oturan bir Python aracıdır. Sistemde iki ayrı parça birlikte çalışır: apt-daily ve apt-daily-upgrade adlı systemd timer'ları paket listesini indirip güncellemeleri hazırlar, unattended-upgrade betiği ise politikanıza uyan paketleri gerçekten kurar. Yani bir cron satırı yazmanıza gerek yoktur; modern Ubuntu ve Debian sürümlerinde zamanlamayı systemd timer'ları üstlenir.

Aracın kalbi, hangi paketlerin otomatik kurulacağına karar veren "origin" (köken) eşleştirmesidir. Her APT deposunun bir kimliği vardır (Ubuntu:noble-security, Debian:bookworm-security gibi) ve siz yapılandırmada yalnızca güvenilir kökenleri açarsanız, araç sadece o kaynaklardan gelen paketleri kurar. Bu tasarım sayesinde "sadece güvenlik yamalarını otomatik uygula, geri kalan her şeyi ben elle yöneteyim" gibi muhafazakâr ve güvenli bir politika kurmak mümkündür. Üretim sunucularında önerdiğimiz varsayılan yaklaşım tam olarak budur.

Kurulum ve Etkinleştirme#

Çoğu Ubuntu Server kurulumunda paket zaten yüklü gelir, ancak minimal imajlarda veya Debian'da elle kurmanız gerekebilir. Önce sistemi güncel bir tabana getirin, ardından paketi kurun:

sudo apt update
sudo apt install -y unattended-upgrades apt-listchanges

apt-listchanges zorunlu değildir ama e-posta bildirimlerinde hangi paketin neyi değiştirdiğini özetlediği için birlikte kurmanızı öneririz. Kurulum bittikten sonra otomatik güncellemeleri etkinleştiren en pratik yol interaktif yapılandırma aracıdır:

sudo dpkg-reconfigure -plow unattended-upgrades

Bu komut size "otomatik güncellemeler etkinleştirilsin mi?" diye sorar; "Evet" dediğinizde /etc/apt/apt.conf.d/20auto-upgrades dosyası oluşturulur. Aynı sonucu bu dosyayı elle yazarak da alabilirsiniz. İçeriği şu şekilde olmalıdır:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";

Buradaki her satırın anlamı önemlidir. Update-Package-Lists "1" her gün paket listesini yeniler; Unattended-Upgrade "1" her gün güvenlik güncellemelerini uygular; AutocleanInterval "7" ise haftada bir indirilmiş eski .deb dosyalarını temizleyerek disk şişmesini önler. Değerler gün cinsindendir; "0" ilgili görevi kapatır. Bu dört satır, otomatik güncelleme mekanizmasının açık/kapalı anahtarıdır; asıl politika ise bir sonraki bölümdeki 50unattended-upgrades dosyasında tanımlanır.

Hangi Depolar Otomatik Güncellensin#

Politikanın kalbi /etc/apt/apt.conf.d/50unattended-upgrades dosyasıdır. Bu dosyayı bir editörle açın:

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

En kritik blok Allowed-Origins (Ubuntu'da Origins-Pattern) listesidir. Üretim sunucusu için önerimiz nettir: sadece güvenlik deposunu açık bırakın, genel updates deposunu ise yorum satırı olarak pasif tutun. Ubuntu için tipik bir yapılandırma şöyledir:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
//  "${distro_id}:${distro_codename}-updates";
//  "${distro_id}:${distro_codename}-proposed";
//  "${distro_id}:${distro_codename}-backports";
};

Buradaki -security satırları güvenlik yamalarını, ESM satırları ise Ubuntu Pro aboneliğiniz varsa uzatılmış güvenlik desteği paketlerini kapsar. -updates satırının başındaki // yorum işaretini kaldırırsanız, güvenlik dışı sürüm güncellemeleri de otomatik uygulanır; bu, çalışan servislerin davranışını değiştirebileceği için üretimde genellikle önerilmez. Aşağıdaki tablo, hangi depoyu açmanın ne anlama geldiğini özetler:

Belirli paketlerin otomatik güncellenmesini hiç istemiyorsanız (örneğin veritabanı ya da özel derlediğiniz bir servis), Package-Blacklist bloğuyla onları hariç tutabilirsiniz:

Unattended-Upgrade::Package-Blacklist {
    "mysql-server";
    "mariadb-server";
    "docker-ce";
};

Bu kara liste, "yamayı ben elle, planlı bir bakım penceresinde uygulayacağım" dediğiniz kritik bileşenler için idealdir. Güvenlik yamalarını otomatikleştirmek genel bir savunma katmanıdır; bunu daha geniş bir sertleştirme stratejisiyle birlikte ele almak isterseniz sunucu güvenliği temelleri rehberimiz iyi bir tamamlayıcıdır.

Otomatik Yeniden Başlatma Penceresi#

Çekirdek (kernel), glibc veya systemd gibi çekirdek bileşenler güncellendiğinde yamanın gerçekten etkin olması için çoğu zaman yeniden başlatma gerekir. unattended-upgrades bunu sizin belirlediğiniz saatte otomatik yapabilir. İlgili ayarlar yine 50unattended-upgrades dosyasındadır:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

Automatic-Reboot "true" yalnızca gerçekten gerekiyorsa (sistemde /var/run/reboot-required dosyası oluştuğunda) yeniden başlatmayı devreye alır; her güncellemede değil. Automatic-Reboot-Time "04:30", trafiğin en düşük olduğu gece yarısı sonrası bir bakım penceresi tanımlar; bu değeri işinize göre seçin. Automatic-Reboot-WithUsers "false" ise sunucuda aktif oturum açmış bir kullanıcı varsa reboot'u ertelemenizi sağlar, böylece birinin ortasında çalıştığı bir işi kesmezsiniz.

Otomatik reboot güçlü ama riskli bir özelliktir. Tek başına çalışan, kümede yedeği olmayan kritik bir üretim sunucusunda gece 04:30'da beklenmedik bir açılış sorunu (örneğin fsck takılması veya bir servisin açılışta başlamaması) sabaha kadar kesinti yaratabilir. Bu yüzden pratik önerimiz şudur: gerçekten 7/24 izlenen ve yedekli bir mimariniz yoksa Automatic-Reboot değerini "false" bırakın, reboot gerektiğini e-posta ile öğrenin ve yeniden başlatmayı planlı biçimde siz yapın. Kesinti toleransı düşük servislerde yedekli mimari ve düzenli yedekleme kritik önemdedir; bu konuda yedekleme ve sunucu yönetimi hizmetlerimiz devreye girer.

E-posta ve Bildirim Ayarları#

Otomatik güncellemenin "otomatik" olması, onu gözden kaçırmanız gerektiği anlamına gelmez. Aracın ne yaptığını bilmek için e-posta bildirimlerini açmanızı şiddetle öneririz. Aynı dosyada şu satırları düzenleyin:

Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "on-change";

MailReport için üç değer vardır: always her çalıştırmada rapor gönderir, on-change yalnızca gerçekten bir paket kurulduğunda ya da bir sorun çıktığında gönderir, only-on-error ise sadece hata durumunda uyarır. Günlük gürültüyü azaltmak için üretimde on-change dengeli bir seçimdir. E-postanın gerçekten gidebilmesi için sunucuda çalışan bir posta aracına (MTA) ihtiyacınız vardır. En hafif çözüm msmtp ya da postfix'i "satellite" modda kurup harici bir SMTP sunucusuna yönlendirmektir:

sudo apt install -y msmtp msmtp-mta bsd-mailx

Kurulum sonrası basit bir test ile zincirin çalıştığını doğrulayın:

echo "unattended-upgrades test" | mail -s "Sunucu bildirim testi" [email protected]

Bu e-posta kutunuza düşüyorsa, bildirim altyapısı hazır demektir. E-posta yerine ya da e-postaya ek olarak bir izleme sistemine (Prometheus, Zabbix, ya da basit bir webhook) sinyal göndermek isterseniz, /etc/apt/apt.conf.d/50unattended-upgrades içindeki bir dpkg::Post-Invoke kancasıyla kendi betiğinizi tetikleyebilirsiniz; ancak çoğu ekip için e-posta yeterlidir.

Kırılma Riskini Yönetmek ve Test Etmek#

Otomatik güncellemelerin en büyük korkusu, bir yamanın çalışan bir servisi bozmasıdır. Bu risk gerçektir ama yönetilebilir. İlk savunma hattı, güncellemeleri gerçekten uygulamadan önce kuru bir çalıştırma (dry-run) ile ne olacağını görmektir:

sudo unattended-upgrade --dry-run --debug

Bu komut hiçbir şeyi kurmaz; sadece hangi paketlerin uygun olduğunu, hangi kökenlerin eşleştiğini ve neyin atlanacağını ayrıntılı biçimde listeler. Politikanızı ilk kurduğunuzda mutlaka bu çıktıyı inceleyin; beklediğinizden fazla paket listeleniyorsa Allowed-Origins bloğunuz çok geniştir. İkinci savunma hattı, kritik ortamlarda yamaları önce bir hazırlık (staging) sunucusunda denemektir; birebir aynı imajı taşıyan test sunucusunda sorun çıkmayan bir yama, üretimde de büyük olasılıkla sorunsuz geçer.

Riski düşürmenin diğer yolları şunlardır. Unattended-Upgrade::MinimalSteps "true"; ayarı güncellemeyi tek dev işlem yerine küçük adımlara böler, böylece süreç ortasında kesilirse sistem tutarsız kalmaz. Otomatik güncellemeyi güvenlik deposuyla sınırlamak (önceki bölümde yaptığımız gibi) zaten kırılma yüzeyini büyük ölçüde daraltır, çünkü güvenlik yamaları geriye dönük uyumluluğu bozmamak üzere tasarlanır. Yine de yamalanan güvenlik açıkları bazen saldırının bir parçasıdır; bir sunucu ele geçirilmişse yalnızca yama yetmez, saldırıyı da durdurmanız gerekir. Bu noktada fail2ban kurulumu rehberimizle brute-force saldırılarını engellemek, otomatik yamalarla iyi bir ikili oluşturur. Uygulama katmanındaki saldırılar için ise WAF ve DDoS koruma çözümlerimiz devrededir.

İzleme, Loglar ve Doğrulama#

Yapılandırma tamamlandıktan sonra sistemin gerçekten çalıştığını doğrulamak önemlidir. unattended-upgrades, tüm işlemlerini ayrı bir log dizinine yazar; en son ne olduğunu görmek için:

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log
sudo cat /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

Birinci dosya politikanın hangi paketleri seçtiğini ve kurduğunu, ikincisi ise dpkg'nin ham çıktısını (herhangi bir yapılandırma çakışması burada görünür) tutar. Zamanlamanın aktif olduğunu systemd timer'larından teyit edebilirsiniz:

systemctl list-timers apt-daily apt-daily-upgrade
systemctl status unattended-upgrades.service

Reboot gerekip gerekmediğini elle kontrol etmek için /var/run/reboot-required dosyasının varlığına bakabilir, hangi paketlerin reboot istediğini de yanındaki dosyadan görebilirsiniz:

[ -f /var/run/reboot-required ] && echo "Yeniden baslatma gerekiyor" || echo "Gerek yok"
cat /var/run/reboot-required.pkgs 2>/dev/null

Bu birkaç komutu bir izleme betiğine ya da haftalık kontrol rutininize eklerseniz, otomatik güncelleme mekanizmasının sessizce çalışmayı bırakmadığından emin olursunuz. Unutmayın: kurup unuttuğunuz bir otomasyon, ilk kurulduğunda çalışsa bile aylar sonra bir posta aracı arızası ya da disk dolması yüzünden durmuş olabilir; düzenli doğrulama bu yüzden şarttır.

Farklı Sunucu Rolleri İçin Öneriler#

Her sunucu aynı politikayı kaldırmaz. Basit bir statik site ya da tek başına çalışan bir WordPress sunucusunda güvenlik yamalarını ve hatta gece reboot'unu tam otomatik bırakmak mantıklıdır; kesinti maliyeti düşüktür ve güncel kalmanın faydası riskin önüne geçer. Böyle ortamlar için WordPress'e özel bakım paketlerimiz de vardır; içeriği WordPress bakım ve WordPress hosting sayfalarımızda bulabilirsiniz. Paylaşımlı ya da yönetilen web hosting planlarımızda güncellemeleri zaten biz üstlendiğimiz için bu yapılandırmayla uğraşmanıza gerek kalmaz.

Veritabanı sunucusu, ödeme altyapısı ya da kümedeki bir düğüm gibi kritik roller içinse muhafazakâr yaklaşın: güvenlik yamalarını otomatik indirip hazırlayın ama kurulum ve reboot'u planlı bakım pencerelerinde elle tetikleyin, kritik paketleri kara listeye alın. VDS ve sanal sunucu hizmetlerimizde bu tür ince ayarlı politikaları uygulamak tamamen sizin kontrolünüzdedir; tam yönetim isterseniz sunucu yönetimi ekibimiz devreye girer. İster tek sunucu ister sunucu filosu yönetin, temel prensip aynıdır: güvenlik yamasını asla geciktirmeyin, ama davranış değiştiren güncellemeleri kontrollü uygulayın.

Sıkça Sorulan Sorular#

unattended-upgrades sunucumu her güncellemede yeniden başlatır mı?#

Hayır, yalnızca gerçekten gerektiğinde ve siz izin verdiyseniz yeniden başlatır. Reboot yalnızca çekirdek ya da temel bir kütüphane güncellendiğinde ve sistemde /var/run/reboot-required dosyası oluştuğunda gündeme gelir. Üstelik Automatic-Reboot "false" bıraktığınızda hiç yeniden başlatmaz; size yalnızca reboot gerektiğini bildirir ve siz uygun bir zamanda elle yaparsınız. Otomatik reboot açıksa bile bunu yalnızca tanımladığınız saatte (Automatic-Reboot-Time) yapar.

Sadece güvenlik güncellemelerini mi yoksa tüm paketleri mi otomatik kurmalıyım?#

Üretim sunucuları için önerimiz yalnızca güvenlik deposunu (-security origin'i) otomatikleştirmenizdir. Güvenlik yamaları geriye dönük uyumluluğu korumak üzere hazırlandığı için servislerinizi bozma olasılığı düşüktür, buna karşılık güvenlik faydası çok yüksektir. Genel -updates deposu ise davranış değiştiren sürüm yükseltmeleri getirebilir; bunları elle, planlı bakım pencerelerinde uygulamak daha güvenlidir. Bu ayrım, 50unattended-upgrades dosyasındaki Allowed-Origins bloğunda hangi satırların açık kaldığıyla belirlenir.

Otomatik bir güncelleme servisimi bozarsa ne yapmalıyım?#

Öncelikle log dosyalarına bakarak hangi paketin ne zaman kurulduğunu tespit edin; /var/log/unattended-upgrades/ ve /var/log/dpkg.log bu bilgiyi verir. Sorunlu paketi bilinen çalışan sürümüne geri almak için apt install paket=eski-surum komutunu kullanabilir, ardından o paketi Package-Blacklist listesine ekleyerek tekrar otomatik güncellenmesini engelleyebilirsiniz. Bu tür durumlara karşı en iyi sigortanız düzenli yedeklerdir; sistem imajınızın ya da veritabanınızın güncel bir yedeği varsa geri dönüş dakikalar sürer.

E-posta bildirimi gelmiyor, sorun nerede olabilir?#

En sık neden, sunucuda çalışan bir posta aracının (MTA) bulunmamasıdır. unattended-upgrades e-postayı sistemin mail komutu üzerinden gönderir; msmtp veya postfix gibi bir araç kurulu ve doğru yapılandırılmış değilse bildirim hiçbir yere ulaşmaz. Önce echo test | mail -s test [email protected] komutuyla posta zincirini bağımsız olarak test edin. Ayrıca MailReport değerinin only-on-error olmadığından ve Mail satırında doğru adresin yazılı olduğundan emin olun; on-change ayarı yalnızca bir değişiklik olduğunda posta gönderir, hiç güncelleme yoksa sessiz kalması normaldir.

unattended-upgrades'in çalıştığını nasıl doğrularım?#

En pratik yol log dosyalarını ve systemd timer'larını kontrol etmektir. systemctl list-timers apt-daily-upgrade komutu bir sonraki çalışma zamanını gösterir; cat /var/log/unattended-upgrades/unattended-upgrades.log ise en son hangi paketlerin işlendiğini listeler. Politikanızın beklendiği gibi davrandığını görmek isterseniz sudo unattended-upgrade --dry-run --debug komutunu çalıştırın; bu, hiçbir şeyi kurmadan hangi paketlerin uygun olduğunu ve hangi kökenlerin eşleştiğini ayrıntılı biçimde gösterir. Bu iki kontrolü periyodik olarak yapmak, otomasyonun sessizce durmadığından emin olmanızı sağlar.

Debian ile Ubuntu'da yapılandırma farklı mı?#

Temel mantık ve dosya konumları aynıdır; her ikisinde de /etc/apt/apt.conf.d/50unattended-upgrades ve 20auto-upgrades dosyalarını kullanırsınız. Fark, Allowed-Origins içindeki köken kimliklerindedir: Ubuntu'da ${distro_id}:${distro_codename}-security (ve varsa ESM satırları) kullanılırken Debian'da genellikle origin=Debian,codename=${distro_codename}-security,label=Debian-Security biçiminde bir Origins-Pattern görürsünüz. Kurulum sırasında gelen varsayılan dosya zaten dağıtımınıza uygun örnekleri içerir; siz sadece hangi satırların yorumdan çıkacağına karar verirsiniz.

Kapanış#

unattended-upgrades, birkaç dakikalık yapılandırmayla sunucunuza yıllarca değer katan sessiz bir savunma katmanıdır. Doğru kurgu basittir: yalnızca güvenlik deposunu açın, kritik paketleri kara listeye alın, reboot'u ihtiyaç ve mimarinize göre elle ya da bir bakım penceresinde otomatik yapın, ve her şeyi e-posta bildirimleriyle izleyin. Bu politika, bilinen açıkların yamasız kalıp sizi hedef haline getirmesini büyük ölçüde engeller; geri kalan riski de düzenli yedekleme ve saldırı engelleme araçlarıyla kapatırsınız.

Sunucularınızı bu tür otomasyonlarla tek tek uğraşmadan güncel ve güvenli tutmak isterseniz, Clou.TR'nin yönetilen çözümleri işinizi kolaylaştırır. Güvenlik güncellemelerini, yedeklemeyi ve izlemeyi bizim üstlendiğimiz sunucu yönetimi hizmetimize, esnek VDS ve sanal sunucu planlarımıza ya da tüm güncelleme derdini bizim çözdüğümüz yönetilen hosting paketlerimize göz atın. Uygulamalarınızı hızlıca ayağa kaldırmak için App Center, altyapınızı sertleştirmek için WAF ve SSL çözümlerimiz de yanınızda.