Linux Sunucu Güvenliği: Yeni VPS'te İlk 24 Saatte Yapılacaklar

Linux sunucu güvenliği için yeni bir VPS'te yapılacaklar kısa bir sıraya sığar: önce sistemi güncelleyin ve sudo yetkili ayrı bir kullanıcı açın, sonra SSH anahtarı ekleyip root girişini ve parolayla girişi kapatın. Ardından güvenlik duvarında (UFW veya firewalld) yalnız gereken portları açık bırakın, Fail2ban ile tekrarlayan giriş denemelerini engelleyin, otomatik güvenlik güncellemelerini açın ve sunucu dışına alınan bir yedekle izlemeyi kurun. Sıra önemli: yanlış sırada yapılan tek bir adım sizi kendi sunucunuzun dışında bırakabilir.

Neden ilk gün? Sunucuya henüz site koymamış olmanız, kimsenin onu bilmediği anlamına gelmiyor. IPv4 adresleri tükendiği için size verilen adres çoğu zaman daha önce başka bir müşterinin elindeydi. Shodan, Censys gibi tarama motorlarının kayıtlarında ve botların hedef listelerinde zaten duruyor. Bu botlar alan adı sormaz; IP aralıklarını sırayla dolaşır, 22 numaralı portta SSH bulduğunda elindeki kullanıcı adı ve parola sözlüğünü denemeye başlar. Test için açtığım boş sunucularda başarısız giriş kayıtları, ben daha ilk sertleştirme komutunu yazmadan dolmaya başlıyor.

Sızma testlerinde saldırgan rolünü ben üstleniyorum. Yeni kurulmuş bir sunucuda ilk baktığım yerler pek değişmez: root kullanıcısında zayıf parola, sağlayıcının e-postayla gönderdiği ilk parolanın hâlâ geçerli olup olmadığı, internete açık unutulmuş bir veritabanı ya da yönetim paneli. Bunların hiçbiri gelişmiş bir saldırı sayılmaz. Otomatik tarayıcılar da aynısını yapıyor, yalnız aynı anda binlerce sunucuda.

Başarılı bir girişten sonrası çoğu zaman tahmin edilebilir. Sunucuya kripto para madencisi kurulur, CPU tavan yapar ve ilk işaret faturadaki kaynak artışı ya da sağlayıcının kötüye kullanım (abuse) uyarısı olur. Sunucu başka sistemlere saldırmak veya spam göndermek için kullanılırsa IP adresiniz Spamhaus gibi kara listelere girer; birçok sağlayıcı da abuse bildirimi gelen sunucuyu ağdan ayırır. Güvenlik firmalarının tehdit raporlarında SSH kaba kuvvet (brute-force) saldırıları ve ardından gelen madenci kurulumları yıllardır tekrar eden bir başlık.

Bu yazıdaki her adım, bu zincirin bir halkasını kırmak için var.

Saldırgan gözünden yeni bir VPS

1. 1Port taraması22, 80, 443, 3306, 5432, 6379 gibi bilinen portlar yoklanır; cevap veren her servis bir sonraki adımın listesine girer.
2. 2Sözlük saldırısıroot, admin, ubuntu, test, deploy gibi yaygın kullanıcı adlarıyla sızdırılmış parola listeleri denenir.
3. 3Açık servis avıParolasız Redis, internete açık MySQL, varsayılan parolalı yönetim paneli aranır. Bunlar SSH'tan bile kolaydır.
4. 4KalıcılıkGiriş başarılıysa yeni bir SSH anahtarı ve cron görevi eklenir. Bu noktadan sonra parolayı değiştirmek tek başına yetmez.

İlk SSH bağlantısından önce işletim sistemi kararını verin: üretim için uzun süreli destek (LTS) alan bir sürüm seçin. Ubuntu tarafında 24.04 LTS ve Nisan 2026'da yayımlanan 26.04 LTS, Debian tarafında 12 (bookworm) ve 13 (trixie), RHEL ailesinde Rocky Linux veya AlmaLinux 9 en sık gördüğümüz seçenekler. Ubuntu'nun ara sürümleri (ör. 25.10) yalnız dokuz ay civarı destek alır; sunucuda kullanmayın.

Kurtarma yolunu da sorun çıkmadan öğrenin. Sağlayıcı panelinde web tabanlı konsol (VNC, noVNC veya seri konsol) nerede, nasıl açılıyor, klavye düzeni Türkçe Q mu İngilizce mi? Konsolda | ya da ~ karakterini yazamadığınızı kötü bir günde fark etmek istemezsiniz. SSH'ı yanlış yapılandırdığınızda sizi kurtaracak kapı bu konsol, çünkü ağ üzerinden değil, sanal makinenin ekranına doğrudan bağlanır ve güvenlik duvarı kurallarınızdan etkilenmez.

Konsolda giriş yapabilmek için bir parolanız olmalı. SSH'ta parolayı kapatmak, yerel konsolda parolalı girişi kapatmaz; bu yüzden sudo kullanıcınıza uzun ve benzersiz bir parola verin, bir parola yöneticisinde saklayın. Anahtarla girdiğiniz için o parolayı her gün yazmayacaksınız ama kötü bir günde ona ihtiyacınız olacak.

Son hazırlık sıfır noktası. Temiz kurulumdan hemen sonra, hiçbir şeye dokunmadan bir snapshot (diskin o anki görüntüsü) alın. Sertleştirme sırasında bir şey ters giderse sunucuyu birkaç dakikada başa döndürürsünüz. W3'ün bulut sunucu panelinde yeniden başlatma, konsol açma ve snapshot alma aynı ekrandan yapılıyor; başka bir sağlayıcı kullanıyorsanız bu üç düğmenin yerini önceden bulun.

Dağıtımlar arasında sizi etkileyecek farklar

İlk girişte root olarak bağlanırsınız; bazı sağlayıcılar ubuntu, debian veya rocky gibi hazır bir kullanıcı verir. İlk iş paket listesini yenileyip bekleyen tüm güncellemeleri kurmak. Sağlayıcı imajları haftalar, bazen aylar önce hazırlanmış olabilir ve aradaki güvenlik yamaları sizi bekliyor.

Çekirdek (kernel) ya da OpenSSH, systemd, glibc gibi temel paketler güncellendiyse yeniden başlatın. Ubuntu ve Debian'da /var/run/reboot-required dosyasının varlığı, RHEL ailesinde dnf needs-restarting -r komutu bunu söyler. Yeniden başlatmayı şimdi yapmak, sonradan canlı sitede yapmaktan çok daha ucuz.

Sonra günlük iş için ayrı bir kullanıcı açın. Root ile çalışmanın sorunu yetkinin kendisi değil, her komutun sınırsız yetkiyle ve kimin çalıştırdığı belli olmadan çalışması. sudo, tek bir komutu yönetici yetkisiyle çalıştırmanızı sağlayan araç; kimin hangi komutu yükseltilmiş yetkiyle çalıştırdığını da kayda geçirir. Yanlışlıkla yazılmış bir rm -rf de en azından bir parola sorusuyla yavaşlar.

apt update && apt full-upgrade -y
timedatectl set-timezone Europe/Istanbul      # loglardaki saat sizin saatiniz olsun
adduser deploy                                # güçlü, benzersiz bir parola verin
usermod -aG sudo deploy
[ -f /var/run/reboot-required ] && reboot

dnf upgrade -y
timedatectl set-timezone Europe/Istanbul
useradd -m -G wheel deploy
passwd deploy
dnf needs-restarting -r || reboot

Kullanıcı adını tahmin edilmesi zor seçmek gerçek bir koruma sayılmaz; parola girişi kapandıktan sonra adın gizli olması pek bir şey değiştirmiyor. Yine de admin, test, user gibi sözlüklerin ilk satırındaki adlardan kaçının.

SSH anahtarı birbirine bağlı iki dosyadan oluşur: bilgisayarınızda kalan özel anahtar ve sunucuya kopyaladığınız açık anahtar. Bağlanırken sunucu, açık anahtarınızla doğrulanabilecek bir imza ister; bu imzayı yalnız özel anahtar üretebilir. Ağ üzerinden parola gitmez, sözlükle tahmin edilecek bir şey de kalmaz.

Anahtar türü olarak ed25519 kullanın. Kısa, hızlı ve güncel OpenSSH sürümlerinin tamamında destekleniyor; Windows 10 ve 11'deki yerleşik OpenSSH istemcisi de PuTTYgen de bu türü üretebiliyor. Eski bir sistem yüzünden RSA kullanmak zorundaysanız en az 3072 bit seçin.

Anahtarı oluştururken bir anahtar parolası (passphrase) verin. Bu, sunucudaki kullanıcı parolasıyla karıştırılmasın; yalnız özel anahtar dosyasını şifreler. Dizüstü bilgisayarınız çalınırsa ya da yedeği bir yere sızarsa parolasız bir özel anahtar, doğrudan sunucularınızın anahtarıdır. ssh-agent sayesinde parolayı oturum başına bir kez yazarsınız.

# Kendi bilgisayarınızda
ssh-keygen -t ed25519 -C "ad.soyad@sirket-dizustu"

# Linux / macOS
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@SUNUCU_IP

# Windows PowerShell (ssh-copy-id yoksa)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@SUNUCU_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

ssh-copy-id, açık anahtarı sunucudaki ~/.ssh/authorized_keys dosyasına ekler ve izinleri ayarlar. Elle ekliyorsanız izinlere dikkat edin: .ssh dizini 700, authorized_keys 600 olmalı ve ikisi de kullanıcının kendisine ait olmalı. OpenSSH, başkalarının yazabildiği bir anahtar dosyasına güvenmez ve onu yok sayar. “Anahtarı ekledim ama hâlâ parola soruyor” şikâyetinin en sık nedeni bu. Hangi anahtarın denendiğini görmek için ssh -v ile bağlanın.

Anahtarla girişin çalıştığını ikinci terminalde doğruladıktan sonra iki kapıyı kapatıyoruz: root kullanıcısının doğrudan SSH girişi ve parolayla giriş. Root'u kapatmak, saldırganın hedefini herkesin bildiği bir kullanıcı adından tahmin edilmesi gereken bir ada çevirir. Parolayı kapatmak ise sözlük saldırısını tamamen anlamsız hale getirir.

Ayarları ana dosya /etc/ssh/sshd_config yerine /etc/ssh/sshd_config.d/ altına ayrı bir dosya olarak yazın. Güncel Ubuntu, Debian ve RHEL 9 sürümlerinde ana dosyanın başında bu dizini içeri alan bir Include satırı bulunur. Böylece bir paket güncellemesi ana dosyayı yenilemek istediğinde sizin ayarlarınız çakışma sorusuna takılmaz.

Çoğu rehberin atladığı ayrıntı şu: OpenSSH bir ayar için ilk bulduğu değeri kullanır. Bulut imajlarında cloud-init (sanal makine ilk açıldığında kullanıcı, anahtar ve ağ ayarlarını yazan araç) 50-cloud-init.conf adlı bir dosya bırakabilir ve içinde PasswordAuthentication yes olabilir. RHEL 9 ailesinde kurulum sırasında root için parolalı SSH'a izin verildiyse benzer bir 01-permitrootlogin.conf görürsünüz. Sizin dosyanızın adı alfabetik olarak bunlardan sonra geliyorsa (ör. 99-guvenlik.conf), yazdığınız no hiç uygulanmaz.

Bu yüzden dosyanızı 00- ile başlatın ve etkin değeri her zaman sshd -T ile kontrol edin. “Parola girişini kapattık” denen bir sunucuda parolanın hâlâ açık çıkması testlerde sık karşılaştığımız bir durum; sebebi çoğu zaman bu dosya sırası.

cat > /etc/ssh/sshd_config.d/00-sertlestirme.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers deploy
EOF

sshd -t && sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|allowusers) '
systemctl restart ssh        # RHEL ailesinde: systemctl restart sshd

Önce sshd -t ile sözdizimini sınayın; hatalı bir yapılandırmayla servis yeniden başlatıldığında açılmayabilir. Açık SSH oturumunuz yeniden başlatma sırasında kopmaz, yeni ayarlar yalnız yeni bağlantılara uygulanır. Bu yüzden testi daima yeni bir terminalden yapın ve eski oturumu ancak test başarılı olunca kapatın. Parola girişinin gerçekten kapandığını görmek için ssh -o PubkeyAuthentication=no deploy@SUNUCU_IP deneyin; cevap Permission denied (publickey) olmalı.

SSH portunu değiştirmek ne kazandırır?

Otomatik tarayıcıların log gürültüsü

Belirgin şekilde azalır; çoğu bot yalnız 22'yi dener.

Hedefli bir saldırgan

Etkisiz. Tam port taraması yeni portu kısa sürede bulur.

Sözlük saldırısına karşı koruma

Parola girişi kapalıysa zaten anlamsız; port ek koruma sağlamaz.

Operasyon maliyeti

Her istemcide, CI/CD'de, yedek betiğinde -p ayarı; ssh.socket ve SELinux tuzakları.

Port değiştirmek kilit değil, kapının yerini değiştirmek. Logları temiz tutmak istiyorsanız yapın; asıl koruma anahtar tabanlı giriş.

Aşağıdaki araç bu yazıdaki adımları sizin seçimlerinize göre komutlara çeviriyor. Dağıtımı, kullanıcı adını, SSH portunu, açılacak servisleri, veritabanını, Docker ve panel kullanımını seçtiğinizde sırası değiştirilemeyen komut blokları ve her bloğun altında bir kontrol noktası çıkıyor. Kilitlenme riski taşıyan adımlar ayrıca işaretleniyor.

İndirdiğiniz .sh dosyası her adımdan sonra durup onay ister; baştan sona körü körüne çalışmaz. Önerimiz, betiği ilk kez bir test sunucusunda (birkaç saatliğine açıp sileceğiniz küçük bir VPS yeterli) denemeniz.

• 1.SSH izni güvenlik duvarı açılmadan önce eklenir; port değişiyorsa yeni port önceden açılır, eski port ancak test sonrası kapanır.
• 2.Veritabanı portları hiçbir koşulda tüm internete (0.0.0.0/0) açılmaz; özel ağ girilmezse kural üretilmez.
• 3.Panel seçildiyse UFW/firewalld ve Fail2ban yerine panelin kendi modülleri önerilir; iki kural setinin çakışması engellenir.
• 4.Ubuntu'da port değişikliği ssh.socket komutlarıyla, Rocky ve AlmaLinux'ta SELinux port tanımıyla birlikte üretilir.

Araç tamamen tarayıcınızda çalışır; girdiğiniz IP, kullanıcı adı veya açık anahtar hiçbir yere gönderilmez. Üretilen komutlar yaygın kurulumlar için hazırlanmış örneklerdir. Sağlayıcı imajınız farklı varsayılanlarla gelebilir; kendi ortamınızda test edin.

UFW (Uncomplicated Firewall), Linux çekirdeğindeki paket filtresini daha okunur komutlarla yönetmenizi sağlayan bir ön yüz. Mantık basit: gelen her bağlantıyı varsayılan olarak reddet, giden bağlantılara izin ver, sonra yalnız ihtiyacın olan portları tek tek aç. RHEL ailesinde aynı işi firewalld yapar ve kurulumla birlikte açık gelir.

Sıra burada da belirleyici. ufw enable komutunu SSH izni eklemeden çalıştırırsanız mevcut oturumunuz kopabilir, yeni bağlantılar ise kesinlikle reddedilir. Kural daima şu: önce ufw allow ile SSH, sonra ufw enable. Tüm dünyaya açık bir SSH portunda ufw allow yerine ufw limit kullanın: UFW'nin belgelerine göre bu kural, son 30 saniyede 6 veya daha fazla bağlantı deneyen IP'yi geri çevirir. Basit ama bedava bir hız sınırı.

Bulut sağlayıcıların çoğu panelde ayrıca bir ağ güvenlik duvarı (security group) sunar; W3 bulut sunucularında bu katman ayrı bir Firewall eklentisi olarak seçiliyor. İki katman birbirinin yerine geçmez. Sağlayıcı katmanı trafiği sunucuya ulaşmadan keser, yanlış bir kuralda sunucuya konsol dışında hiç ulaşamazsınız. Sunucu üzerindeki UFW ise sağlayıcı değişse de sizinle gelir. Biz ikisine aynı kural listesini yazmayı öneriyoruz.

ufw default deny incoming
ufw default allow outgoing
ufw limit 22/tcp comment 'SSH'          # yönetici IP'si varsa: ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Hangi port kime açık olmalı?

Tabloya bakınca bir desen görünüyor: internete açık olması gereken şey çok az. Tipik bir web sunucusunda dışarıdan görünen yalnız SSH, 80 ve 443 olmalı. Veritabanı uygulamayla aynı sunucudaysa 127.0.0.1 üzerinden konuşur; ayrı sunucudaysa sağlayıcının özel ağı (private network, VLAN) üzerinden ve yalnız uygulama sunucusunun IP'sine açılır.

Plesk veya cPanel kullanıyorsanız durum değişir. Bu paneller kendi güvenlik duvarı ve giriş engelleme modülleriyle gelir (Plesk'te Firewall ve Fail2Ban bileşenleri, cPanel'de cPHulk). Panelin yönettiği bir sunucuda elle UFW kuralı yazmak, iki kural setinin birbirini ezmesine yol açar. Güvenlik duvarını panelden yönetin ve panelin giriş portunu mümkünse yalnız ofis IP'nize açın. Panelin kendisi de bir saldırı yüzeyi: güncellemelerini takip edin, kullanmadığınız eklentileri kaldırın. Panel lisansı için lisans satış sayfamıza bakabilirsiniz. Tek bir kurumsal site için ise sunucu yönetimiyle hiç uğraşmadan web hosting çoğu zaman daha mantıklı bir seçim.

Fail2ban, log kayıtlarını izleyip belirli bir sürede çok sayıda başarısız giriş deneyen IP adreslerini güvenlik duvarı kuralıyla geçici olarak engelleyen bir araç. İzlenen her servis için bir “hapishane” (jail) tanımlanır: hangi log, hangi hata kalıbı, kaç deneme, ne kadar süre.

Parola girişini kapattıysanız Fail2ban'a yine ihtiyaç var mı? Evet, ama beklentiniz doğru olsun. Anahtar tabanlı girişte sözlük saldırısı zaten başarısız olur. Fail2ban'ın katkısı logları okunur tutmak, sunucunun boşa harcadığı bağlantı yükünü azaltmak ve aynı mantığı Nginx, Postfix ya da panel girişi gibi parolanın hâlâ var olduğu servislere taşımak.

Saldırgan tarafından bakınca sınırı da görmek lazım. Büyük botnetler denemeleri çok sayıda farklı IP'ye dağıtır; her IP birkaç deneme yapıp çekilir. Tek IP'yi banlayan bir mekanizma bunu yakalayamaz. Bu yüzden Fail2ban bir ek katman, asıl korumanın yerine geçmez.

Yapılandırmayı jail.conf dosyasına yazmayın; paket güncellemesinde üzerine yazılabilir. Ayarlarınızı jail.local veya jail.d/ altında bir dosyaya koyun. Fail2ban'ın varsayılan değerleri 10 dakika içinde 5 başarısız denemede 10 dakikalık engel. Aşağıdaki örnekte engel süresini uzatıp tekrar edenlere artan süre uyguluyoruz.

apt install -y fail2ban          # Rocky/Alma: dnf install -y epel-release && dnf install -y fail2ban fail2ban-systemd

cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
bantime.increment = true
ignoreip = 127.0.0.1/8 ::1 203.0.113.10

[sshd]
enabled = true
port    = 22
# Debian ve Rocky/Alma'da: backend = systemd
EOF

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

bantime1h

Engelin süresi. Varsayılan 10 dakika; örnek değer olarak bir saat.

findtime10m

Denemelerin sayıldığı zaman penceresi.

maxretry5

Pencere içinde izin verilen başarısız deneme sayısı.

bantime.incrementtrue

Aynı IP tekrar engellenirse süre her seferinde uzar.

ignoreipkendi IP'niz

Asla engellenmeyecek adresler. Kendinizi banlamamak için ilk satır.

Kendi IP'nizi ignoreip satırına eklemeyi unutmayın; aksi halde yanlış anahtar dosyasıyla birkaç kez denediğinizde kendinizi engellersiniz. Engellenen adresleri fail2ban-client status sshd ile görür, yanlışlıkla engellenen birini fail2ban-client set sshd unbanip 203.0.113.10 ile serbest bırakırsınız. UFW ile birlikte sorunsuz çalışır; isterseniz banaction = ufw ile engelleri UFW üzerinden de ekletebilirsiniz.

Kısa cevap: güvenlik güncellemeleri için evet, tüm paketler için hayır. Ubuntu'da unattended-upgrades sunucu kurulumlarında genellikle kurulu ve açık gelir, varsayılanı yalnız güvenlik deposudur. Debian'da kurulu olup olmadığı imaja göre değişir; varsayılan ayar güvenlik yamalarının yanında kararlı sürümün ara güncellemelerini (point release) de alır, bunlar da ana sürüm değiştirmez. RHEL ailesinde dnf-automatic'i siz kurar ve upgrade_type = security ile güvenlik yamalarına sınırlarsınız.

Teklif görüşmelerinde en sık duyduğum endişe “gece güncelleme siteyi bozar mı?” sorusu. Dağıtımların güvenlik depoları sürüm atlatmadan yalnız yamayı içeren paketler yayımlar; PHP'nin veya veritabanının ana sürümü kendiliğinden değişmez. Yine de üretimde iki şeyi kontrol altında tutun: yeniden başlatma zamanı ve üçüncü taraf depolar.

Çekirdek güncellemesi yeniden başlatma olmadan devreye girmez. unattended-upgrades'e otomatik yeniden başlatma için bir saat verebilirsiniz (trafiğin en düşük olduğu, genellikle gece 03:00–05:00 arası) ya da bunu kapatıp haftalık bakım penceresinde elle yaparsınız. Ubuntu'da Livepatch hizmeti bazı çekirdek yamalarını yeniden başlatmadan uygular; Ubuntu Pro ile gelir, kişisel kullanımda sınırlı sayıda makine için ücretsizdir, ticari kullanım koşullarını Canonical'ın sitesinden kontrol edin.

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades     # "Yes"

cat > /etc/apt/apt.conf.d/52sertlestirme <<'EOF'
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
EOF

unattended-upgrade --dry-run --debug 2>&1 | tail -n 15

Docker'ın, Nginx'in ya da bir veritabanının resmi deposunu eklediyseniz, bu depolardan gelen paketler varsayılan yapılandırmada otomatik güncellenmez. Bu bir eksik değil, bilinçli bir tercih olmalı: bu servisleri sürüm notunu okuyup bakım penceresinde güncelleyin.

Hangi durumda nasıl ayarlamalı?

• Tek sunucu, kısa kesinti kabul edilebilir (kurumsal site, blog)→ Güvenlik güncellemeleri otomatik, yeniden başlatma gece otomatik.
• Tek sunucu, kesinti pahalı (e-ticaret, rezervasyon)→ Güvenlik güncellemeleri otomatik, yeniden başlatma haftalık bakım penceresinde elle.
• Yük dengeleyici arkasında birden fazla sunucu→ Sunucuları farklı saatlerde sırayla yeniden başlatın; hepsi aynı anda inmesin.
• Değişiklik yönetimi veya denetim gereksinimi var→ Önce test ortamı, sonra kayıtlı onayla üretim; otomatik kurulum yalnız kritik yamalarda.

Bir sunucunun saldırı yüzeyi, dışarıdan bağlantı kabul eden her programın toplamıdır. Sertleştirmeden sonra ss -tulpn çıktısına bakın: hangi program, hangi adreste, hangi portu dinliyor. 0.0.0.0 veya [::] tüm ağ arayüzleri demek; 127.0.0.1 yalnız sunucunun kendisi.

Sağlayıcı imajları bazen beklemediğiniz şeylerle gelir: bazı Rocky ve AlmaLinux kurulumlarında 9090 portunda Cockpit yönetim arayüzü, bazı imajlarda postfix, rpcbind ya da önceden kurulmuş bir panel. Kullanmadığınız servisi systemctl disable --now <servis> ile kapatın; hiç kullanmayacaksanız paketini kaldırın.

Kullanıcı listesine de bakın. Giriş kabuğu atanmış hesaplar ve sudo grubundaki üyeler sizin tanıdığınız kişiler olmalı. Sağlayıcının destek için eklediği bir kullanıcı ya da anahtar varsa ne işe yaradığını sorun.

Bu bölümün performansla da ilgisi var ama ayrıntısına girmiyoruz. Swap ayarı, gereksiz servislerin RAM tüketimi ve darboğaz teşhisi için sunucu yavaşladığında CPU, RAM ve disk darboğazını bulma yazımıza bakabilirsiniz.

Hayır, geçmez. Snapshot, diskin belirli bir andaki görüntüsüdür ve genellikle aynı sağlayıcıda, çoğu zaman aynı depolama altyapısında durur. Yanlış bir güncellemeden sonra geri dönmek için çok iyi bir araç. Ama sağlayıcı hesabınız ele geçirilirse, ödeme aksadığı için hesap kapanırsa ya da veri merkezinde bir depolama sorunu yaşanırsa snapshot'larınız da sunucuyla birlikte gider.

Fidye yazılımı senaryosunu düşünün. Saldırgan sunucuda root yetkisi aldıysa, sunucudan erişilebilen her yedeği de şifreler veya siler. Sunucuya bağlı ikinci bir diskteki yedek, aynı sunucudaki bir klasör kadar savunmasız. Gerçek yedek sunucunun dışında, sunucunun silme yetkisi olmadığı bir yerde durur.

Pratik bir ilk gün düzeni şöyle: veritabanı her gece dump olarak alınır (mysqldump --single-transaction veya pg_dump), dosyalarla birlikte şifrelenip S3 uyumlu bir nesne depolamaya gönderilir. Yedek hesabının anahtarı yalnız yazma yetkisine sahiptir, silemez; depolama tarafında sürüm tutma veya silme kilidi (object lock) açıktır. restic ya da borg gibi araçlar şifrelemeyi ve tekilleştirmeyi kendisi yapar.

Yedeğin hangi ülkede durduğunu da baştan düşünün. Kişisel veri içeren bir veritabanı yedeğini yurt dışındaki bir depolamaya göndermek, 6698 sayılı KVKK'nın yurt dışına aktarım hükümlerine takılabilir. Bunun hukuki değerlendirmesini hukuk ekibinize bırakın; teknik tarafta yapılacak iş, yedek hedefinin lokasyonunu bilinçli seçmek ve kayda geçirmek.

Kaç kopya, nerede ve ne kadar süre sorularını, yani 3-2-1 kuralını web hosting, VPS, bulut ve dedicated farkını anlattığımız yazıda ele aldık. Burada tek bir şeyin altını çizelim: geri yüklemesi hiç denenmemiş bir yedeğin işe yarayıp yaramadığını bilmiyorsunuz. İlk hafta içinde boş bir sunucuya geri yükleme yapın ve ne kadar sürdüğünü not edin; kesinti planınız o süreye göre şekillenir.

İlk hafta yedek takvimi (örnek)

1. Gün 0Sıfır noktası ve sertleştirme sonrası snapshot.
2. Gün 1Gece veritabanı dump'ı ve dosya yedeği, sunucu dışına.
3. Gün 3Yedekten boş bir sunucuya geri yükleme denemesi; süreyi not edin.
4. Gün 7Saklama kuralı (ör. 7 günlük, 4 haftalık, 6 aylık) ve başarısız yedek için uyarı.

İzleme kurmadan geçen her gün, sorunu müşterinizden öğrenme ihtimalinizi artırır. İlk gün için büyük bir izleme yığını gerekmez; dışarıdan bir erişilebilirlik (uptime) kontrolü, disk doluluğu uyarısı ve SSL sertifikasının bitiş tarihi takibi iyi bir başlangıç.

Araç seçiminde ölçek belirleyici. Tek sunucu için Netdata veya Uptime Kuma kurulumu yarım saatlik iş; birden fazla sunucuda Prometheus, node_exporter ve Grafana üçlüsü ya da sağlayıcının kendi metrik ekranı daha mantıklı. Uptime kontrolünü izlenen sunucunun üstünde çalıştırmayın: sunucu düştüğünde uyarıyı gönderecek olan da onunla birlikte düşer.

İlk gün izleme listesi (örnek eşikler)

Güvenlik tarafında “kim girdi, kim denedi” sorusunun cevabı zaten sunucuda. last başarılı girişleri, lastb başarısız denemeleri, journalctl -u ssh (RHEL ailesinde -u sshd) SSH günlüğünü gösterir. Debian 13 gibi yeni sürümlerde giriş kayıt altyapısı değiştiği için lastb bulunmayabilir; journalctl her üç ailede çalışır. Beklemediğiniz bir IP'den başarılı giriş görürseniz bu artık izleme konusu değil, olay müdahalesi konusudur.

Uyarı yorgunluğu konusunda dürüst olalım: her şeye uyarı kurarsanız bir hafta sonra hiçbirine bakmazsınız. Uyarıyı birinin kalkıp bir şey yapması gereken durumlara ayırın, geri kalanını haftalık bir özete bırakın.

HTTPS için Let's Encrypt ve certbot (ya da sertifikayı kendisi alan Caddy) ilk gün kurulur. Yenileme otomatiktir ama çalıştığını certbot renew --dry-run ile bir kez doğrulayın; Let's Encrypt sertifikaları kısa ömürlü olduğundan yenileme bozulursa birkaç hafta içinde tarayıcı uyarısı başlar. Alan adını sunucuya henüz yönlendirmediyseniz önce nameserver ve DNS ayarlarını yapın; sertifika doğrulaması buna bağlı. Sertifika türleri arasındaki farkı (DV, OV, EV, wildcard) SSL sertifikası rehberimizde anlattık.

Çoğu durumda evet. Ekipte Linux komut satırına alışkın biri varsa bu yazı, komut üretici ve aşağıdaki skor bir sunucuyu sağlam bir temele oturtmaya yeter. Bunun için bir hizmet satın almanız gerekmiyor.

Kurulum bir günlük iş; zor olan, o sunucuyu yıllarca aynı disiplinle tutmak. Destek almayı düşünmeniz gereken durumlar belli:

• Sunucuyu güncel tutacak, uyarılara bakacak kimse yokKurulum bir kere yapılır, bakım hiç bitmez.
• Kart, sağlık ya da çok sayıda kişisel veri işleniyorKVKK ve sektör denetimleri belgelenmiş tedbir ister.
• E-ticaret veya 7/24 erişilebilir olması gereken bir sistemGece 03:00'te gelen uyarıya kimin bakacağı belli olmalı.
• Sunucunun daha önce ele geçirilmiş olabileceğinden şüpheleniyorsunuzSertleştirme değil, olay müdahalesi gerekir.
• Birden fazla sunucu, Docker veya ayrı veritabanı sunucusu varKural setleri elle yönetilmeyecek kadar büyür.

Bu durumlarda üç yol var: kurulumunu ve bakım düzenini baştan birlikte planladığımız bir bulut sunucu, mevcut altyapınızın bağımsız bir gözle incelendiği bir altyapı değerlendirmesi ya da sertleştirmenin gerçekten işe yarayıp yaramadığını saldırgan gözüyle sınayan bir sızma testi. Testin nasıl yürüdüğünü ve raporun nasıl okunduğunu pentest rehberimizde anlattık.

Sanal sunucu yetmeyecek kadar büyüdüyseniz ya da donanım düzeyinde izolasyon gerekiyorsa dedicated sunucu seçeneğine bakın; aylık faturanın hangi kalemlerden oluştuğunu bulut sunucu fiyatları yazımızda ayrıştırdık. Ürününü bulut üzerinde kuran ekipler için altyapıyı yazılımla birlikte tasarlama yaklaşımımızı SaaS girişimleri için web yazılım sayfasında anlattık.

Sunucunuz zaten ele geçirildiyse bu listeyi uygulamak yetmez; saldırgan kendi anahtarını, cron görevini ya da servisini bırakmış olabilir. İlk saatlerde neyin yapılacağını web sitesi hacklendiğinde izlenecek müdahale planı yazısında adım adım anlatıyoruz.

Sertleştirme Skoru: sunucunuz nerede duruyor?

Aşağıdaki öz değerlendirme 16 maddede sunucunuzun nerede durduğunu gösteriyor. Ağırlıklar ekibimizin önerdiği örnek bir önceliklendirme. Ağırlığı en yüksek maddelerden biri (root veya parola girişi, açık veritabanı portu, sunucu dışı yedek) yapılmadıysa skor 60'ın üstüne çıkmaz.