VPS Güvenliği: SSH, Fail2ban ve Güncellemeler

VPS Güvenlik Sertleştirme Neden Bu Kadar Önemli?

Bir VPS satın alıp ilk SSH bağlantısını yaptığınız anda aslında sadece kendi projenize değil, tüm ağa karşı da bir sorumluluk almış oluyorsunuz. Güvenlik tarafında ufak bir ihmal; spam gönderen, DDoS saldırılarına katılan ya da veritabanı sızdıran bir sunucuya dönüşmenize yol açabiliyor. Bu rehberde temel kontrolleri şu başlıklarda ele alacağız: SSH kimlik doğrulaması, doğrudan root SSH erişimi, fail2ban yapılandırması ve güvenlik güncellemeleri.

Bu yazıda, pratik bir VPS güvenlik sertleştirme kontrol listesi üzerinden ilerleyeceğiz. Odakta özellikle şu adımlar var: sshd_config sertleştirmesi, doğrudan root SSH erişimini kapatmak, fail2ban ile brute-force saldırılarını sınırlamak ve otomatik güvenlik güncellemelerini doğru kurmak. Adımların her biri tek başına basit görünebilir; fakat birlikte uygulandığında hem küçük projeler hem de yoğun trafikli uygulamalar için oldukça sağlam bir temel güvenlik katmanı sağlar. Ayrıca, DCHost üzerinde yeni açtığınız ya da mevcutta çalışan VPS/dedicated sunucularınıza bu kontrol listesini nasıl uygulayabileceğinizi de adım adım örneklendireceğiz.

VPS Güvenlik Sertleştirme Kontrol Listesi: Büyük Resim

Detay ayarlara inmeden önce, sağlam bir VPS için olması gereken temel güvenlik adımlarını netleştirelim. Aşağıdaki listeyi, hem yeni bir VPS kurarken hem de mevcut bir sunucuyu denetlerken checklist olarak kullanabilirsiniz:

• İşletim sistemini ve paketleri güncellemek (özellikle güvenlik güncellemeleri)
• sshd_config dosyasını sertleştirmek (port, kimlik doğrulama, root erişimi vb.)
• Doğrudan root girişi yerine yetkili bir kullanıcı + sudo modeli kurmak
• Parola ile SSH girişini kapatıp sadece SSH anahtarları ile bağlanmak
• fail2ban veya benzeri bir mekanizma ile brute-force saldırılarını sınırlamak
• Güvenlik duvarı (ufw, firewalld, iptables/nftables) ile sadece gereken portları açmak
• Dağıtıma uygun otomatik güvenlik güncellemelerini etkinleştirmek
• Log döngüsü ve disk takibi ile beklenmedik dolmaları engellemek
• Düzenli ve test edilmiş yedekleme stratejisi (en az 3-2-1 yaklaşımına yakın bir yapı)

Bu yazıda odak daha çok SSH, root, fail2ban ve güncellemeler üzerinde olacak. Güvenlik duvarı tarafında detay arıyorsanız, DCHost blogda yayınladığımız VPS sunucularda güvenlik duvarı yapılandırma rehberini mutlaka gözden geçirmenizi öneririz.

sshd_config ile SSH Erişimini Sertleştirmek

VPS’inize ilk dokunduğunuz yer neredeyse her zaman SSH olur. SSH, internete açık sunucularda saldırganların da hedefleyebildiği bir erişim noktasıdır. Varsayılanların dağıtıma ve sunucu imajına göre değişebileceğini dikkate alarak kimlik doğrulama yöntemlerini ve açık özellikleri gözden geçirmek gerekir. İhtiyaca göre yapılandırılmış bir sshd_config dosyası, gereksiz erişim yollarını daraltmaya yardımcı olur.

Temel sshd_config Sertleştirme Parametreleri

Örnekler Ubuntu 24.04 LTS, Debian 12 ve RHEL 9 ailesinin belgelerine dayanır; güncel dağıtım paketlerini kullanın. Sunucu komutları root yetkili Bash oturumunda, anahtar üretimi kendi bilgisayarınızda çalışır. Önce yönetici hesabı, anahtarlı yeni SSH oturumu, sudo ve bağımsız kurtarma konsolunu doğrulayın. Herhangi bir düzenlemeden önce tüm etkin SSH yapılandırmasını ve değiştireceğiniz hizmet/soket eklerini yedekleyin; ayrıntılı yedekleme ve geri dönüş adımları root erişimi bölümündedir. Aşağıdaki erişim kısıtlamalarını bunlardan önce etkinleştirmeyin. Mevcut SSH oturumunu açık tutmak tek başına kurtarma planı değildir.

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2

Bu parça tüm sshd_config dosyasının yerine geçmez. Varsayılanlar, paket yamaları, merkezi yapılandırma ve ek dosyalar korunmalıdır. Çoğu ayarda ilk okunan değer kullanılır; Include dosyaları belirtilen yerde ve joker eşleşmesinde sözcüksel sırayla okunur. Ubuntu/Debian paketleri ek dosyaları ana dosyanın başında içerebilir. AllowUsers ve AllowGroups gibi liste ayarları tekrarlanınca birikebilir. Bu nedenle “sona ekledim” veya “00 adını verdim” doğru etkin politikayı kanıtlamaz.

• Kimlik doğrulama: AuthenticationMethods publickey yalnızca açık anahtar yöntemini gerektirir; PasswordAuthentication no ve KbdInteractiveAuthentication no parola yollarını kapatır. PAM hesap/oturum kontrolleri devam eder. PAM tabanlı MFA kullanıyorsanız yalnızca anahtarla girişe izin veren bu örneği kendi politikanızın üzerine uygulamayın.
• Root: PermitRootLogin no doğrudan root SSH girişini kapatır; sudo veya konsol yetkisini kaldırmaz.
• Deneme sınırı: MaxAuthTries 3 bağlantı başınadır; yeniden bağlanmayı engelleyen IP yasağı değildir. LoginGraceTime 20 kimlik doğrulama süresidir; meşru istemcileriniz için yeterliliğini sınayın.
• Canlılık kontrolü: ClientAliveInterval/ClientAliveCountMax yanıt vermeyen istemciyi denetler; kullanıcı klavyede hareketsiz kalsa da istemci yanıt veriyorsa bağlantı sürebilir.
• Protokol/ağ: Güncel OpenSSH protokol 2 kullanır; eski Protocol 2 güvenlik sertleştirmesi değildir ve örneğe eklenmez. AddressFamily inet/ListenAddress 0.0.0.0 yalnızca IPv4 kapsamındadır; mevcut dinleme adreslerini ve IPv6 ihtiyaçlarını bilinçli yönetin.

SSH Portunu Değiştirmek: Güvenlik mi, Gürültü Azaltma mı?

Güvenlik camiasında sık tartışılan bir başlık: SSH portunu değiştirmek. Gerçekçi olmak gerekirse, sadece portu değiştirmek size tam anlamıyla ek bir güvenlik katmanı kazandırmaz; ama yalnızca varsayılan portu hedefleyen otomatik denemeleri azaltabilir. Bu da log gürültüsünü ve fail2ban yükünü azaltabilir; yeni portun taramayla bulunmasını engellemez.

Port değişimi isteğe bağlıdır. Geçiş sırasında eski ve yeni portu birlikte koruyan örnek:

Port 22
Port 2222

Port değişikliğini şu sırayla uygulayın:

• Önce sağlayıcı ve host güvenlik duvarlarında yeni portu gereken yönetim kaynaklarına IPv4/IPv6 ile açın; eski izni koruyun.
• RHEL 9’da SELinux için semanage port -l ile mevcut etiketleri inceleyin. 2222 boşsa semanage port -a -t ssh_port_t -p tcp 2222 ekleyin; araç policycoreutils-python-utils paketindedir. Başka servise ait portu körlemesine yeniden etiketlemeyin ve SELinux’u kapatmayın.
• Etkin hizmeti/soketi systemctl status ssh.service ssh.socket (Ubuntu/Debian) veya systemctl status sshd.service (RHEL) ile belirleyin. Dinleyiciyi ss -ltnp ile kontrol edin.
• Yapılandırma ve etkin kullanıcı politikasını doğrulayıp ilgili dağıtım yoluyla uygulayın; yeni porttan yeni anahtarlı SSH ve sudo oturumu başarılı olmadan eski portu/izni kaldırmayın. Fail2ban port listesini de geçişte 22,2222, sonrasında gerçek porta uyarlayın.

Ubuntu 24.04 Noble paketinin soket etkinleştirmesi kullanılıyorsa, paket README’si port/adres değişikliğinden sonra aşağıdaki yolu belirtir. Ubuntu 22.10–23.10’daki taşınmış socket drop-in dosyaları farklıdır; bu reçeteyi tüm sürümlere genellemeyin. Daemon/service modu için sonraki doğrulama bölümündeki reload dalını kullanın.

sshd -t &&
systemctl daemon-reload &&
systemctl restart ssh.socket &&
systemctl cat ssh.socket &&
ss -ltnp

AllowUsers / AllowGroups ile Erişimi Daraltmak

Erişecek mevcut kullanıcıları açıkça seçin. Aşağıdaki iki model alternatiftir: tek bir yönetilen AllowUsers listesi veya üyeliği doğrulanmış AllowGroups. Her ikisi etkinse kullanıcı iki koşulu da sağlamalıdır; mevcut deny kuralları da etkili olabilir.

AllowUsers admin

Grup modelini tercih ediyorsanız yukarıdakinin yerine:

AllowGroups sshusers

sshusers grubunu oluşturup gerçek yönetici hesaplarını ekleyin ve id admin ile üyeliği doğrulayın. Örneğin mevcut admin hesabı için:

groupadd -f sshusers
usermod -aG sshusers admin
id admin

Bu yaklaşım, yanlışlıkla şifre atanmış ancak hiç kullanılmayan sistem hesaplarının dışarıya açık bir saldırı yüzeyine dönüşmesini engeller. Ekipli çalışıyorsanız, DCHost blogda detaylarını anlattığımız SSH anahtar yönetimi ve yetki paylaşımı rehberi ile bu ayarları birleştirmenizi öneririz.

SSH Anahtarı Zorunlu Kılmak

Parola sızıntısı ve parola tekrar kullanımı SSH erişimi için risk oluşturur. Bu rehberin hedefi açık anahtar yöntemini zorunlu kılmaktır; yalnızca PasswordAuthentication no yeterli kanıt değildir. İlgili kullanıcı ve kaynak için etkin AuthenticationMethods, PubkeyAuthentication ve KbdInteractiveAuthentication değerlerini birlikte kontrol edin.

Özet adımlar:

Aşağıdaki komutlardan önce admin hesabını, sonraki kullanıcı oluşturma bölümüne göre hazırlayın veya mevcut yönetici hesabınızın gerçek adını kullanın.

1. Kendi bilgisayarınızda mevcut anahtar dosyasını ezmeden yeni anahtar oluşturun. Ed25519 uygun bir seçenektir; RHEL FIPS gibi politikalarda desteklenmeyebilir. Böyle bir ortamda desteklenen RSA/SHA-2 anahtarını/politikasını seçin, genel kripto politikasını zayıflatmayın.
2. Yalnızca açık anahtarı kullanıcıya ekleyin; mevcut authorized_keys kayıtlarını koruyun. İzin ve sahiplikleri ilgili hesabın gerçek home dizininde doğrulayın.
3. Ayrı terminalde anahtarlı giriş ve sudo yetkisini deneyin; çok anahtarlı agent için IdentitiesOnly ile doğru anahtarı seçin.
4. Önce syntax/effective-policy kontrolü, sonra doğru service/socket uygulaması ve yeniden dış bağlantı testi yapın.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C 'admin-laptop' &&
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 22 admin@SERVER_ADDRESS

SSH adresi ve portunu kendi ortamınıza göre değiştirin; sunucunun host-key parmak izini bağımsız güvenilir kanaldan doğrulayın. Anahtar dosyası varsa üzerine yazmayın. Manuel ekleme seçeneği sunucudaki root oturumunda:

install -d -m 700 -o admin -g admin /home/admin/.ssh &&
touch /home/admin/.ssh/authorized_keys &&
chown admin:admin /home/admin/.ssh/authorized_keys &&
chmod 600 /home/admin/.ssh/authorized_keys &&
# Open this file and append only the public key; preserve existing entries.
vi /home/admin/.ssh/authorized_keys

SELinux kullanılan sistemde uygun bağlamı restorecon -R /home/admin/.ssh ile geri yükleyin; gerçek home yolunu kullanın. Sadece açık anahtar taşınır, özel anahtar istemcide korunur.

OpenSSH 8.5’te PubkeyAcceptedKeyTypes adı PubkeyAcceptedAlgorithms olarak değiştirildi; eski ad bir takma addır. ssh-rsa burada RSA/SHA-1 imzasıdır, tüm RSA anahtarları değildir. OpenSSH 8.8 bu imzayı varsayılan olarak kapatır; uyumlu RSA anahtarları RSA/SHA-2 kullanabilir. Eski dar imza listesini kopyalamak yerine dağıtımın desteklenen kripto varsayılanlarını ve FIPS politikasını koruyun.

Doğrudan Root SSH Erişimini Kapatmak ve Sağlıklı Yetki Modeli Kurmak

Örnek bir risk senaryosu düşünelim: root hesabına doğrudan SSH erişimi açık, parola ile giriş aktif ve parola zayıf veya başka bir yerde de kullanılıyor. Böyle bir durumda parolanın ele geçirilmesi, saldırgana doğrudan yönetici erişimi sağlayabilir. Sağlıklı model; doğrudan root yerine, yetkili kullanıcı + sudo kullanmaktır.

Adım 1: Yetkili Bir Admin Kullanıcı Oluşturmak

Yeni yerel yönetici hesabı için yalnızca dağıtımınıza uygun dalı root oturumunda çalıştırın. Hesap zaten varsa yeniden oluşturmayın; home, shell, grup ve yetki durumunu inceleyin. Yerel parola, sudo politikasında gerekebilir; açık bir SSH parola kurtarma yolunu garanti etmez.

Ubuntu/Debian:

adduser admin &&
usermod -aG sudo admin

RHEL/AlmaLinux/Rocky 9:

useradd -m -U -s /bin/bash admin &&
passwd admin &&
usermod -aG wheel admin

Yeni anahtarlı admin oturumunda sudo -k, sudo -v, sudo id ve sudo -l ile gerçek yetkiyi sınayın. Sudo politikasına göre parola istenebilir; başarı çıktısı UID 0 olmalıdır. Grup adı tek başına yetki vermez: sudoers içinde ilgili sudo/wheel kuralının etkin olduğunu kontrol edin. Bu doğrulanmadan root SSH veya eski kimlik doğrulamayı kapatmayın.

Adım 2: sudo Yetkilerini İnce Ayar Yapmak

Birçok dağıtımda sudoers dosyası varsayılan kurallarla gelir. Yöneticiye verilen yetkinin kapsamını ve parola gereksinimini gözden geçirin:

Kuralları syntax kontrolü yapan editörle açın:

visudo

Aşağıdaki satır kabuk komutu değil, gerekliyse sudoers dosyasına yazılacak bir kural örneğidir:

admin ALL=(ALL:ALL) ALL

Bu ek kural diğer kullanıcı/grup yetkilerini kaldırmaz. Mevcut eşleşmeleri sudo -l ile değerlendirin; dosyayı visudo -c ile kontrol edin.

Her kullanıcıya tam yetki vermek yerine, görev için gereken komutlarla sınırlı yetki tanımlayın. Parola gereksinimini bu yetki kapsamından ayrı değerlendirin; NOPASSWD kullanmak tek başına daha yüksek güvenlik sağlamaz. Örneğin deployment kullanıcısının sadece belirli servisleri yönetebilmesini isteyebilirsiniz.

Adım 3: Root SSH Erişimini Kapatmak

Admin anahtarlı giriş/sudo ve konsol kurtarma doğrulanınca, global kapsamda ve etkin ilk değer olacak şekilde ayarı yönetin. Rastgele dosyanın sonuna eklemeyin; önceki bir Match bloğunun içinde kalabilir:

PermitRootLogin no

Önce tüm aktif Include dosyalarını, varsa /etc/ssh dışındaki dosyaları ve değiştireceğiniz service/socket drop-in dosyalarını değişiklik kaydına alın. Aşağıdaki özel yedek /etc/ssh ağacını korur; dış dosyaları ayrıca yedekleyin. Geri dönüşte özgün dosyaları ve bu işlemde yeni eklenen dosyaların listesini kullanın; eski dosyayı kopyalamak yeni bir override’ı ortadan kaldırmaz.

umask 077 &&
backup_dir=$(mktemp -d /root/ssh-change.XXXXXX) &&
cp -a /etc/ssh "$backup_dir/ssh" &&
printf 'Private configuration backup: %s\n' "$backup_dir"

Örnek istemci/sunucu adresleri belge adresleridir; gerçek kullanıcı, sunucunun gördüğü kaynak, hostname, yerel adres ve portla değiştirin. Her Match senaryosu, root, admin ve otomasyon hesabı için ayrı kontrol edin:

sshd -t &&
sshd -T -C user=admin,host=client.example,addr=198.51.100.10,laddr=203.0.113.10,lport=22 &&
sshd -T -C user=root,host=client.example,addr=198.51.100.10,laddr=203.0.113.10,lport=22

Global ayarları mevcut ilk Match öncesinde, Include sırası denetlenmiş yerde yönetin. sshd -t yalnızca hata kodu 0 ise başarılıdır; -T -C etkin değerleri gösterir. Anahtar dosyası, PAM, grup erişimi, firewall ve gerçek dinleyici için yeni bağlantı testi yine gerekir. Yalnızca kimlik doğrulama/politika değişikliğinde doğru dalı kullanın:

Ubuntu/Debian service:

sshd -t &&
systemctl reload ssh.service

RHEL 9 service:

sshd -t &&
systemctl reload sshd.service

Socket port/adres değişikliği için önceki Noble dalı ayrıdır. Herhangi bir doğrulama başarısızsa uygulamayı durdurun. Kurtarma konsolundan kaydedilmiş özgün dosyaları ve yalnızca bu değişiklikte eklediğiniz dosyaları geri alın; syntax kontrolünden sonra doğru birimi yeniden yükleyin.

Yeni admin bağlantısında sudo çalışırken, yeni root SSH bağlantısının reddedildiğini ve izin vermediğiniz hesap/kaynağın erişemediğini ayrıca test edin. Mevcut root oturumunun sürmesi beklenebilir; ayar yeni SSH girişlerini etkiler. Yönetim için örneğin sudo -i kullanılabilir, fakat konsol ve diğer yetki yolları kendi politikalarıyla var olmaya devam eder.

• Etkin PermitRootLogin no doğrudan root SSH girişini reddeder; başka bir yönetici hesabının ele geçirilmesini önlemez.
• Sudo komut çağrılarını kullanıcı kimliğiyle kaydedebilir. Journald, auth.log veya secure konumu dağıtıma ve log yönlendirmesine bağlıdır. Bir sudo root kabuğunun içindeki her komutun otomatik ayrı audit kaydı oluştuğunu varsaymayın.

Bu adımı, DCHost blogda anlattığımız yeni VPS’te ilk 24 saat rehberi ile birlikte uyguladığınızda, ilk günden itibaren oldukça sağlam bir temel kurmuş olursunuz.

fail2ban ile Brute-Force Saldırılarını Otomatik Bloklamak

SSH ayarlarınızı sertleştirdiniz, parola erişimini kapattınız, root girişini yasakladınız. Yine de internetten sürekli taranan bir IP adresine sahip olduğunuz için loglarınızda hâlâ başarısız giriş denemeleri göreceksiniz. İşte burada devreye fail2ban giriyor.

fail2ban Nasıl Çalışır?

Fail2ban, yapılandırılan dosya veya systemd journal kayıtlarını filtreleyip eşiğe ulaşıldığında bir action ile IP’yi geçici engelleyebilir. Başarısı doğru log kaynağı, regex ve gerçekten uygulanan firewall action’ına bağlıdır; dağıtık denemeleri veya ele geçirilmiş geçerli anahtarı tümüyle engellemez.

• Log kaynağı: journald veya gerçekten üretilen auth.log/secure dosyası.
• Filtre: dağıtımın sshd log biçimine uygun filter.d kuralı.
• Jail: kaynak, eşik ve sürelerin yerel tanımı.
• Action: kurulu nftables, firewalld veya başka desteklenen arka uca uygun yasaklama.

SSH İçin Basit Bir fail2ban Jail Örneği

Yalnızca dağıtımınıza uygun kurulum dalını kullanın. Paket kurulumu dağıtımın varsayılan jail’lerini uygulayabilir; kurulumdan sonra etkin politikayı inceleyin:

apt update &&
apt install fail2ban python3-systemd

RHEL 9 için kayıtlı sistemde CodeReady Builder erişimi gerekir:

subscription-manager repos --enable "codeready-builder-for-rhel-9-$(arch)-rpms" &&
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm &&
dnf install fail2ban python3-systemd

AlmaLinux/Rocky 9 gibi uyumlu dağıtımlarda kendi CRB deposunu ve erişimini doğrulayın:

dnf install dnf-plugins-core &&
dnf config-manager --set-enabled crb &&
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm &&
dnf install fail2ban python3-systemd

Yerel ayarları /etc/fail2ban/jail.d/sshd.local içinde yönetin; paket dosyasını bütünüyle kopyalayıp dondurmayın. Aşağıdaki örnek journald ve kurulu nftables-multiport action’ı içindir. Sisteminiz farklı firewall yöneticisi kullanıyorsa onun desteklenen action’ını seçip IPv4/IPv6 etkisini doğrulayın.

[sshd]
enabled = true
backend = systemd
port = 22
filter = sshd
banaction = nftables-multiport
maxretry = 5
findtime = 600
bantime = 3600

backend = systemd için logpath yazılmaz; journalmatch filtre ayarından gelir. Dosya logu kullanıyorsanız aynı jail’de aşağıdaki alternatifle polling seçin ve gerçek log yolunu yazın; RHEL’de /var/log/secure ancak rsyslog gerçekten oluşturuyorsa uygundur:

[sshd]
backend = polling
logpath = /var/log/auth.log
journalmatch =

Bu yapılandırma ile:

• Aynı kaynak için son 600 saniyede 5 eşleşen başarısızlık eşiği yasağı tetikleyebilir; “5’ten fazla” değildir.
• Örnek yasak süresi 3600 saniyedir. Regex/log kaynağı ve action doğru değilse bu ayarlar tek başına koruma sağlamaz.

SSH portunuzu değiştirdiyseniz port = 2222 gibi güncellemeyi unutmayın. Ayrıca güvenlik duvarınızı daha detaylı yönetmek istiyorsanız, nftables ile VPS güvenlik duvarı rehberi ile birlikte kullanmak oldukça etkilidir.

Yanlış Pozitifler ve Beyaz Liste Yönetimi

ignoreip, eşleşen kaynakları yasaklamadan muaf tutar. Yalnızca gerçek, sabit ve güvendiğiniz yönetim/VPN adreslerini ekleyin; örnek veya geniş özel ağları otomatik olarak güvenilir saymayın. İstemcinin NAT/VPN sonrasında sunucuda görünen adresini kullanın.

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1

İlk kurulumda syntax ve jail durumunu denetleyin; kaynak logdan kontrollü başarısızlık örneğini fail2ban-regex ile test edin. Konsol ve alternatif erişim hazırken kontrollü ayrı bir kaynakla gerçek yasak/unban etkisini doğrulayın; yalnızca status çıktısı yeterli değildir. Gerekirse fail2ban-client set sshd unbanip GERCEK_IP ile yanlış yasağı kaldırın. Desteklenen sürümlerde bantime.increment ve bantime.maxtime ile artan süre uygulanabilir; varsayılan olarak etkin olduğunu varsaymayın.

fail2ban-client -t &&
systemctl enable fail2ban &&
systemctl restart fail2ban &&
fail2ban-client status sshd

Otomatik Güvenlik Güncellemeleri: Yamalar Gecikmesin

Uygulanmamış güvenlik yamaları bilinen açıklara maruziyeti uzatabilir. Otomasyon, onaylı paketlerin daha düzenli uygulanmasını sağlar; test, izleme ve kurtarma hazırlığının yerini tutmaz.

Ubuntu/Debian: unattended-upgrades ile Güvenlik Güncellemeleri

Debian ve Ubuntu’da unattended-upgrades, izin verdiğiniz paket kaynaklarından güncelleme kurabilir. Ubuntu’da paket kurulumu otomatik güncellemeyi varsayılan olarak etkinleştirebilir. Kurulumdan önce dağıtımın varsayılan politikasını ve mevcut APT zamanlayıcılarını bakım planınızla birlikte inceleyin; kurulum sonrası etkin kaynak ve paket seçimini yeniden doğrulayın.

apt update &&
apt install unattended-upgrades apt-listchanges

Dağıtımın sağladığı kaynak kurallarını önce inceleyin. Ubuntu 24.04 ve Debian 12 güvenlik depoları aynı origin/label değildir; Ubuntu-Security etiketini ikisine ortak reçete olarak kopyalamayın. Gerçek APT metadata’sını ve izin verilen kaynakları kontrol edin:

apt-config dump
apt-cache policy
unattended-upgrade --dry-run --debug
systemctl list-timers 'apt-daily*'

50unattended-upgrades kaynak/paket ve bildirim politikasını, genellikle 20auto-upgrades periyodik etkinliği yönetir. Yalnızca istediğiniz kaynakların dry-run çıktısında izinli olduğunu doğrulayın; apt.conf dosyalarının birleşimi önemlidir. Aşağıdakiler APT yapılandırma içeriğidir, kabuk komutu değildir:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Unattended-Upgrade::Automatic-Reboot "false";

İnceledikten sonra paket etkinliğini etkileşimli olarak yönetebilirsiniz:

dpkg-reconfigure --priority=low unattended-upgrades

E-posta ve kullanılmayan bağımlılık temizliğini ayrıca değerlendirin. Otomatik reboot bu örnekte kapalıdır; gerekli reboot’u izleyip bakımda yapın. Bilinçli opt-in halinde Automatic-Reboot ve Automatic-Reboot-Time değerlerini, aktif kullanıcılar ve test edilmiş kurtarma planıyla birlikte ayarlayın.

Burada kritik olan; otomatik reboot gerektiren güncellemelerin hangi saat aralığında uygulanacağına bilinçli karar vermektir. Trafiğinizin düşük olduğu saatleri tercih edin ve öncesinde mutlaka yedekleme stratejinizi netleştirin. Yedek tarafını daha derin ele almak isterseniz, 3-2-1 yedekleme stratejisi rehberimize göz atabilirsiniz.

RHEL/AlmaLinux/Rocky Linux: dnf-automatic ile Güncellemeler

Aşağıdaki örnek DNF 4 kullanan RHEL/AlmaLinux/Rocky 9 içindir. Farklı ana sürüm veya DNF 5 kullanan bir sistemde paket ve timer belgelerini ayrıca izleyin:

dnf install dnf-automatic

Sonra /etc/dnf/automatic.conf dosyasını düzenleyin:

[commands]
upgrade_type = security
apply_updates = yes
random_sleep = 0

[emitters]
emit_via = stdio

Bu yapılandırmayı okuyan standart timer’ı seçin; install/download/notify türü diğer timer’lar davranışı değiştirebilir. Aynı iş için yarışan timer’ları etkinleştirmeyin:

systemctl enable --now dnf-automatic.timer &&
systemctl list-timers 'dnf-automatic*' &&
systemctl cat dnf-automatic.timer

upgrade_type=security seçimi depoların güvenlik metadata’sına bağlıdır. Timer’ın rastgele gecikmesi olabilir; random_sleep=0 kesin saat garantisi değildir. stdio raporunu journal/izleme üzerinden takip edin; e-posta isterseniz [emitters] ve [email] alanlarıyla gerçek teslimatı ayrıca test edin. Güvenlik paketi seçimi web sunucusu/veritabanı gibi servisleri kategorik olarak dışlamaz; paketler servis yeniden başlatması veya reboot gerektirebilir.

Otomatik Güncelleme Riskleri Nasıl Yönetilir?

“Her şeyi otomatiğe bağlayalım” yaklaşımı kulağa hoş gelse de, özellikle karmaşık stack’lerde beklenmedik uyumsuzluklara yol açabilir. Bu riski azaltmak için:

• İzinli paket/kaynak politikasını dry-run ve gerçek paket listesiyle doğrulayın. Güvenlik yamaları da uygulama bağımlılıklarını etkileyebilir.
• Kritik değişiklikleri staging ortamında sınayın; gerekli servis restart/reboot’u planlayın.
• HTTP durumunun yanında uygulama işlemleri, SSH erişimi, veritabanı, kuyruklar ve hata logları için sağlık kontrolü tanımlayın.
• Güncelleme sonrası kaynak ve servis değişimini VPS kaynak izleme rehberi ile takip edin; test edilmiş yedek/kurtarma yolunu hazır tutun.

Ek Kontroller: Güvenlik Duvarı, Loglar ve Yedekler

sshd_config, root erişimi, fail2ban ve otomatik güncellemeler, VPS güvenliğinin omurgasıdır. Ancak bu omurgayı destekleyecek birkaç önemli katman daha var.

Güvenlik Duvarı ile Saldırı Yüzeyini Küçültmek

Gerekli dinleyicileri ve erişecek kaynakları envanterleyin; örnek bir web VPS’i için aşağıdakiler düşünülebilir. Host, sağlayıcı firewall’u, IPv4/IPv6 ve yönlendirilen/konteyner trafiği ayrı kontrol edilmelidir:

• SSH (örn. 22 veya alternatif port)
• HTTP (80) ve HTTPS (443)
• Gerçekten ihtiyaç duyulan özel servis portları (ör. 3306 sadece iç ağa açık gibi)

Detaylı örnekler ve ufw/firewalld/iptables karşılaştırması için VPS güvenlik duvarı yapılandırma rehberini kullanabilirsiniz.

Log Yönetimi ve Disk Dolmasını Önlemek

Güvenlik önlemleri arttıkça log hacmi de artar. Bu iyi bir şeydir; ancak yönetilmezse disk dolması gibi kritik sorunlara yol açabilir. Log dosyalarınızın sağlıklı döndürülmesi ve eski logların sıkıştırılarak saklanması için logrotate yapılandırmasının düzgün olduğundan emin olun.

Bu konuda pratik bir yol haritası arıyorsanız, DCHost blogdaki VPS disk kullanımı ve logrotate ayarları rehberi size adım adım yol gösterecektir.

Yedekleme: Güvenlik Açığı Kadar Hata Payınızı da Düşürür

Yanlış yapılandırma erişimi kesebilir. Sağlayıcının desteklediği ve denediğiniz konsol/rescue erişimi, yapılandırma geri dönüşü ve bağımsız dosya/veritabanı yedekleri gerekir. Snapshot bulunması veya tek bir yedek dosyası geri yüklemenin çalışacağını kanıtlamaz; ayrı ortamda kurtarma provası yapın.

DCHost Üzerinde Bu Kontrol Listesini Nasıl Uygularsınız?

Bu kontrol listesi DCHost veya başka bir sağlayıcıda yönettiğiniz VPS/fiziksel sunucuya uyarlanabilir. Kurulum imajının sertleştirilmiş olduğunu, Fail2ban’ın etkin olduğunu veya yönetilen destek/konsol erişiminin hizmete dahil olduğunu varsaymayın; mevcut yapılandırma ve hizmet kapsamını doğrulayın.

Uygulama planında şu noktaları netleştirin:

• İmaj, dağıtım ve güvenlik güncellemesi desteği; gerçek SSH/key/sudo durumu.
• Sunucu yönetimi, konsol/rescue, yedek ve olay müdahalesinin sözleşmedeki kapsamı.
• Çok sunuculu sistemlerde kimlik, ağ ve veri katmanlarını ayrı planlayın. Veritabanı replikasyon rehberi bu genişlemenin veri katmanını ele alır; replikasyon yedek yerine geçmez.

Sağlayıcı desteğine başvururken dağıtım/sürüm, erişim yöntemi ve hata çıktısını paylaşın; parola veya özel anahtar göndermeyin. Yapılandırma desteğinin kapsamını hizmet sözleşmenizden doğrulayın.

Sonuç ve Önerilen Yol Haritası

SSH kimlik doğrulaması, doğrudan root girişinin sınırlandırılması, log tabanlı yasaklama ve yama yönetimi birbirini tamamlar. Sonuç, araç adlarından çok doğru etkin ayarlar ve gerçek erişim/kurtarma testleriyle değerlendirilir.

Pratik bir yol haritası isterseniz:

• Önce konsol ve geri dönüş yolunu, mevcut paket/politika durumunu belirleyin.
• Yönetici hesabını, kişisel anahtarı ve sudo’yu yeni bir oturumda doğrulayın.
• Include/Match kapsamını ve etkin erişim politikasını kontrol edip doğru service/socket yoluyla uygulayın; izin/ret testlerini yapın.
• Fail2ban log kaynağı, filtre ve gerçek firewall etkisini doğrulayın.
• Güncelleme kaynaklarını, bakım/reboot’u, alarmı ve yedek kurtarmayı test ederek runbook’a kaydedin.

Bu kontroller, DCHost üzerinde yönettiğiniz VPS veya dedicated sunucuda gereksiz erişim yollarını daraltmaya ve yapılandırma hatalarını fark etmeye yardımcı olur. Sonucu, yeni bağlantı, engelleme ve kurtarma testleriyle doğrulayın. İlerleyen aşamada WAF, CDN, merkezi loglama, gelişmiş izleme gibi katmanlarla güvenlik mimarinizi genişletmek isterseniz, blogumuzdaki VPS sunucu güvenliği ve diğer güvenlik odaklı yazılarımız üzerinden adım adım ilerleyebilirsiniz.

Resmî Kaynaklar

• OpenSSH: sshd_config
• OpenSSH: sshd tests
• OpenSSH 8.8 release notes
• Ubuntu OpenSSH package documentation
• RHEL 9: Securing Networks
• Fedora EPEL: Getting Started
• Fail2ban 1.1.0: jail.conf
• Ubuntu: Automatic Updates
• DNF Automatic