VDS’te Güvenlik Açığı Tespiti ve Adım Adım İhlal Müdahale Rehberi

Bir VDS (Virtual Dedicated Server) size root ya da yönetici yetkisiyle tam kontrol verir. Hangi işletim sistemini kuracağınıza, hangi portları açacağınıza, kimlerin erişebileceğine siz karar verirsiniz. Bu özgürlüğün diğer yüzü de aynı ölçüde net: Sunucunun içindeki güvenlik ayarları, güncellemeler ve erişim kontrolü büyük ölçüde sizin sorumluluğunuzdadır.

Bir gün izleme aracınız gece yarısı başarılı bir yönetici oturumu bildirebilir. İşlemci kullanımı hiçbir sebep yokken %100’e çıkabilir ya da sağlayıcınızdan sunucunuzun dışarıya şüpheli trafik gönderdiğine dair bir bildirim gelebilir. Bu anlarda yapılan en yaygın hata, panikle sunucuyu yeniden başlatmak, şüpheli dosyaları silmek ya da işletim sistemini hemen yeniden kurmaktır. Bu adımlar sorunu çözmüş gibi görünse de saldırganın sunucuya nasıl girdiğini gösteren izleri de yok eder ve aynı açık yerinde kalır.

Bu rehberde VDS üzerinde güvenlik açıklarını nasıl tespit edeceğinizi, bir ihlali hangi işaretlerle doğrulayacağınızı ve şüpheli bir durumda hangi sırayla ilerleyeceğinizi anlatıyoruz. Komutlar Ubuntu, Debian, AlmaLinux ve Windows Server için verildi. Bütün kontroller yalnızca sahibi olduğunuz ya da yazılı olarak yetkilendirildiğiniz sistemlerde yapılmalıdır.

VDS güvenlik açığı nedir?

Güvenlik açığı (zafiyet), bir saldırganın yetkisi olmadığı bir işlemi yapmasına imkân veren zayıflıktır. VDS özelinde bu zayıflık işletim sisteminde, üzerinde çalışan yazılımlarda ya da sunucunun ayarlarında olabilir. En sık karşılaşılan türler şunlardır:

• Yazılım açıkları: İşletim sistemi çekirdeğinde, web sunucusunda, veritabanında, kontrol panelinde ya da bir CMS eklentisinde bulunan ve üreticinin güncellemeyle kapattığı hatalar. Güncelleme yapılmadıkça açık sunucuda kalır.
• Yanlış yapılandırma: Varsayılan ayarlarla bırakılmış bir servis, herkese açık bırakılmış bir yönetim arayüzü, dizin listelemesi açık bir web sunucusu ya da gereğinden geniş dosya izinleri.
• Zayıf kimlik doğrulama: Tahmin edilebilir parolalar, birden fazla yerde kullanılan parolalar, parola ile root girişine izin veren SSH ya da çok faktörlü doğrulaması olmayan yönetici hesapları.
• Açıkta kalan yönetim portları: SSH (22), RDP (3389), veritabanı portları (MySQL 3306, PostgreSQL 5432, Redis 6379 gibi) ya da panel portlarının tüm internete açık olması. Bu portlar sürekli otomatik taramaların ve parola denemelerinin hedefidir.
• Güncel olmayan bileşenler: Desteği bitmiş işletim sistemi sürümleri, artık güvenlik yaması almayan PHP, Node.js ya da Python sürümleri ve bakımı bırakılmış eklentiler.

Burada önemli bir ayrımı baştan yapmak gerekiyor: Bir güvenlik açığının bulunması, sunucuya girildiği anlamına gelmez. Açık bir risktir; ihlal ise o riskin gerçekleştiğini gösteren kanıttır. Bu yüzden tespit çalışması iki ayrı soruya cevap arar. Birincisi “Sunucumda kapatılması gereken bir zayıflık var mı?”, ikincisi “Bu zayıflık kullanılmış mı?” sorusudur.

VDS üzerinde güvenlik açığı nasıl tespit edilir?

Aşağıdaki kontroller savunma amaçlıdır ve kendi sunucunuzda, yetkili kullanıcıyla çalıştırılır. Komutların çoğu yalnızca okuma yapar ve sistemde değişiklik yapmaz. Yine de bir ihlalden şüpheleniyorsanız önce “VDS ihlalinde adım adım müdahale” bölümündeki kanıt koruma adımlarını okuyun. Çünkü ele geçirilmiş bir sunucuda çalıştırdığınız her komut, sistemde iz bırakır.

İşletim sistemi ve yazılım sürümlerini belirleyin

Hangi sürümü çalıştırdığınızı bilmeden hangi açıklardan etkilendiğinizi bilemezsiniz. Linux’ta dağıtım ve çekirdek sürümünü şu komutlarla görürsünüz:

cat /etc/os-release
uname -r

Windows Server’da PowerShell ile:

Get-ComputerInfo -Property OsName, OsVersion, OsBuildNumber

İşletim sisteminin yanında web sunucusu, PHP, veritabanı, kontrol paneli ve CMS sürümlerini de bir listeye yazın. Bu liste, bir güvenlik duyurusu yayımlandığında etkilenip etkilenmediğinizi dakikalar içinde anlamanızı sağlar. Desteği bitmiş bir sürüm kullanıyorsanız (örneğin artık standart güvenlik güncellemesi almayan eski bir Ubuntu, Debian ya da Windows Server sürümü), bu tek başına kapatılması gereken bir açıktır.

Güvenlik güncellemelerini kontrol edin

Bekleyen güvenlik güncellemelerini görmek için:

# Debian / Ubuntu
sudo apt update
apt list --upgradable

# AlmaLinux
sudo dnf updateinfo list --security

Windows’ta son kurulan güncellemeleri Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 ile listeleyebilir, eksikleri Windows Update üzerinden kontrol edebilirsiniz. Hangi güncellemenin hangi açığı kapattığını öğrenmek için resmî kaynaklar Ubuntu Security Notices, Debian Security Advisories, AlmaLinux errata sayfaları ve Microsoft Security Update Guide’dır.

Açık portları ve dışarıya açık hizmetleri inceleyin

Sunucunun hangi portları dinlediğini ve bunları hangi sürecin açtığını görün:

# Linux
sudo ss -tulpn

# Windows (PowerShell)
Get-NetTCPConnection -State Listen | Sort-Object LocalPort

Çıktıda 0.0.0.0 ya da :: adresinde dinleyen her servis, güvenlik duvarı engellemiyorsa internetten erişilebilir demektir. Her satır için “Bu servise dışarıdan erişilmesi gerekiyor mu?” sorusunu sorun. Veritabanı yalnızca aynı sunucudaki uygulama tarafından kullanılıyorsa 127.0.0.1 adresinde dinlemelidir. Ardından güvenlik duvarı kurallarınızı (ufw status verbose, firewall-cmd --list-all ya da Windows Defender Güvenlik Duvarı) bu listeyle karşılaştırın.

Kullanıcı hesaplarını ve yönetici yetkilerini gözden geçirin

Saldırganlar kalıcılık sağlamak için çoğu zaman yeni bir hesap açar, mevcut bir hesaba yönetici yetkisi verir ya da SSH anahtarı ekler. Linux’ta:

# UID 0 olan (root yetkili) hesaplar; normalde yalnızca root olmalı
awk -F: '$3 == 0 {print $1}' /etc/passwd

# sudo / wheel grubundaki kullanıcılar
getent group sudo wheel

# Yetkili SSH anahtarları
sudo ls -la /root/.ssh/ /home/*/.ssh/
sudo cat /root/.ssh/authorized_keys

Windows’ta yerel kullanıcıları ve Administrators grubunu listeleyin. Grup adı Türkçe sistemlerde farklı olabileceği için sabit SID kullanmak daha güvenlidir:

Get-LocalUser | Select-Object Name, Enabled, LastLogon
Get-LocalGroupMember -SID S-1-5-32-544

Tanımadığınız her hesap ya da anahtar için kimin, ne zaman ve neden eklediğini belgeleyin. Kullanılmayan hesapları kapatmak bir önlemdir. Ancak ihlal şüphesi varsa hiçbir şeyi silmeden önce bulguyu kaydedin.

SSH ve RDP erişim kayıtlarını inceleyin

Kimin, ne zaman ve nereden bağlandığı sorusunun cevabı kimlik doğrulama kayıtlarındadır. Linux’ta:

last -F | head -30          # başarılı oturumlar
sudo lastb -F | head -30    # başarısız denemeler

# Debian / Ubuntu
sudo grep -E "Accepted|Failed" /var/log/auth.log | tail -50
# AlmaLinux
sudo grep -E "Accepted|Failed" /var/log/secure | tail -50
# Metin günlüğü yoksa (ör. Debian 12)
sudo journalctl -u ssh --since "-2 days"

Debian 12 (bookworm) ile birlikte rsyslog varsayılan olarak kurulmuyor. Bu sistemlerde /var/log/auth.log dosyası olmayabilir ve kayıtlar journald’da tutulur. AlmaLinux’ta servis adı sshd olduğu için komutu journalctl -u sshd olarak yazın.

Windows’ta Güvenlik günlüğündeki 4624 başarılı oturumu, 4625 başarısız denemeyi kaydeder. Microsoft belgelerine göre 4624’teki oturum türü (Logon Type) 10, Uzak Masaüstü ile yapılan girişi gösterir. 4625’te alt durum kodu 0xC000006A yanlış parolayı, art arda gelen 0xC0000064 kayıtları ise var olmayan kullanıcı adlarının denendiğini (kullanıcı numaralandırma) gösterebilir.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625} -MaxEvents 100 |
  Select-Object TimeCreated, Id, Message

Binlerce başarısız deneme, internete açık bir SSH ya da RDP portunda olağan bir durumdur ve tek başına ihlal anlamına gelmez. Asıl dikkat edilmesi gereken, tanımadığınız bir IP’den gelen başarılı oturumdur. Özellikle bu oturumdan hemen önce çok sayıda başarısız deneme varsa bu kaydı öncelikli olarak inceleyin.

İşlemci, bellek, disk ve ağ kullanımındaki anormallikleri araştırın

Kaynak kullanımı en kolay fark edilen ama en yanlış yorumlanan belirtidir. Önce neyin kaynak tükettiğine bakın:

# Linux
ps aux --sort=-%cpu | head -15
sudo ss -tunap state established

# Windows
Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 Name, Id, CPU, Path

Yüksek kaynak kullanımının normal sebepleri genellikle açıklanabilir ve zamanla ilişkilidir: kampanya trafiği, yedekleme ve veritabanı bakım görevleri, arama motoru botlarının taraması, oyun sunucusunda dolu bir akşam saati ya da yeni yayımlanmış bir sürüm. Şüpheli olan ise açıklaması olmayan kullanımdır. Örneğin adı sistem süreçlerine benzeyen ama /tmp, /dev/shm ya da kullanıcı klasörü gibi beklenmedik bir yerden çalışan bir süreç, gece boyunca sabit %100 CPU ya da tanımadığınız bir adrese sürekli açık giden bağlantı. Yüksek CPU tek başına bir bulgu değil, bir sorudur. Cevabı süreç adında, çalıştığı dosya yolunda ve kurduğu bağlantılarda aranır.

Web sunucusu, sistem ve kimlik doğrulama günlüklerini inceleyin

Web uygulaması çalıştıran bir VDS’te saldırıların önemli bir kısmı uygulama katmanından gelir. Nginx ya da Apache erişim günlüklerinde (/var/log/nginx/access.log, /var/log/apache2/access.log, AlmaLinux’ta /var/log/httpd/) şunlara bakın:

• Yönetim ya da giriş sayfalarına (wp-login.php, /admin, panel adresleri) tek bir IP’den gelen yoğun POST istekleri.
• Yükleme klasörlerinde bulunan ve doğrudan çağrılan .php dosyaları.
• Uygulamanızda olmayan dosya adlarına 200 yanıtı verilmesi.
• Hata günlüğünde aniden artan PHP ya da veritabanı hataları.

Sistem tarafında journalctl -p err --since "-2 days" son iki günün hata düzeyindeki kayıtlarını gösterir. Windows’ta Sistem günlüğündeki 7045 olayı yeni bir servis kurulduğunu kaydeder.

Güvenilir araçlarla yetkili kapsamda tarama yapın

Elle yapılan kontrollerin üzerine bir denetim aracı eklemek, gözden kaçan ayarları yakalar. Örneğin GPL lisanslı Lynis, Linux sunucuda kurulum gerektirmeden çalışan ve bulgularını rapor eden bir güvenlik denetim aracıdır (sudo lynis audit system). Kurulu paketlerin dosyalarının değişip değişmediğini kontrol etmek için Debian/Ubuntu’da debsums -c, AlmaLinux’ta rpm -Va kullanılabilir. Debsums belgeleri bu aracın yerel değişiklikleri bulmaya yönelik olduğunu ve güvenlik aracı olarak sınırlı kaldığını açıkça belirtiyor. Ele geçirilmiş bir sistemde araçların kendisi de değiştirilmiş olabilir.

Dışarıdan port taraması yapmak istiyorsanız bunu yalnızca kendi sunucunuzun IP adresine ve başka bir ağdan yapın. Size ait olmayan ya da yazılı izniniz olmayan sistemleri taramak, sağlayıcı sözleşmelerine ve yasalara aykırı olabilir.

Sunucunun ihlal edilmiş olabileceğini gösteren işaretler

Bir güvenlik açığı bulmak ile ihlal kanıtı bulmak farklı şeylerdir. Aşağıdaki işaretler, sunucuya yetkisiz erişim olmuş olabileceğini düşündürür:

• Bilinmeyen kullanıcı hesapları ya da UID’si 0 olan ikinci bir hesap.
• Yeni yönetici anahtarları: authorized_keys dosyasına eklenmiş tanımadığınız SSH anahtarı ya da Windows’ta Administrators grubuna yapılan bir ekleme (olay 4732).
• Olağan dışı oturumlar: Mesai dışında, alışılmadık bir ülkeden ya da daha önce hiç görülmemiş bir IP’den yapılan başarılı giriş.
• Beklenmedik süreçler: Adı tanıdık görünen ama yanlış dizinden çalışan, sürekli CPU tüketen ya da dışarıya bağlantı açan süreçler.
• Planlanmamış görevler: Sizin eklemediğiniz cron girdileri, systemd zamanlayıcıları ya da Windows zamanlanmış görevleri. Microsoft, zamanlanmış görevlerin zararlı yazılımlar tarafından yeniden başlatmadan sonra sistemde kalmak için sık kullanıldığını ve özellikle Görev Zamanlayıcı kütüphanesinin kök klasöründe oluşturulan görevlerin izlenmesini öneriyor (olay 4698).
• Değişen dosyalar: Sistem dizinlerinde, web kök dizininde ya da yapılandırma dosyalarında açıklanamayan değişiklikler.
• Alışılmadık ağ bağlantıları: Bilinmeyen adreslere giden sürekli bağlantılar ya da sağlayıcınızdan gelen “sunucunuz dışarıya saldırı trafiği gönderiyor” bildirimi.
• Günlüklerdeki boşluklar: Belirli bir zaman aralığının kayıtlarının eksik olması ya da günlüğün temizlendiğini gösteren kayıt (Windows’ta 1102).

Kalıcılık mekanizmalarını kontrol etmek için:

# Linux
sudo crontab -l
sudo ls -la /etc/cron.* /var/spool/cron/
systemctl list-timers --all
systemctl list-unit-files --state=enabled

# Windows: kök klasördeki zamanlanmış görevler ve servis yolları
Get-ScheduledTask | Where-Object TaskPath -eq '\'
Get-CimInstance Win32_Service | Select-Object Name, State, StartMode, PathName

Tek bir belirti kesin ihlal anlamına gelmez. Yeni bir hesabı bir ekip arkadaşınız açmış olabilir, yeni cron görevi bir eklentinin güncellemesiyle gelmiş olabilir, gece yarısı oturumu yurt dışındaki bir geliştiriciye ait olabilir. Karar, birden fazla bulgunun aynı zaman çizelgesinde birbirini doğrulamasıyla verilir.

İşaret	Masum açıklaması olabilir mi?	Nasıl doğrulanır?
Çok sayıda başarısız SSH/RDP denemesi	Evet, açık portlarda olağandır	Aynı kaynaktan başarılı oturum var mı, bakın
Tanımadığınız IP’den başarılı oturum	Bazen (VPN, ekip üyesi, mobil bağlantı)	Hesap sahibine sorun, oturum sonrası komut ve dosya değişikliklerine bakın
Yeni yönetici hesabı veya SSH anahtarı	Bazen (ekip, panel kurulumu)	Değişiklik kaydı ve 4720/4732 ya da dosya tarihleri
Sürekli %100 CPU	Evet (trafik, bakım işleri)	Süreç adı, dosya yolu, dış bağlantılar
Bilinmeyen zamanlanmış görev veya servis	Bazen (yazılım güncellemesi)	Görevin çalıştırdığı dosya ve oluşturulma zamanı
Silinmiş ya da boşluklu günlük	Nadiren (günlük döndürme ayarı)	Döndürme ayarlarını kontrol edin, başka kaynaklardaki kayıtlarla karşılaştırın

VDS ihlalinde adım adım müdahale

Aşağıdaki sıra, NIST SP 800-61 Rev. 3, CISA ve Five Eyes ülkelerinin ortak olay müdahalesi önerileri temel alınarak bir VDS için sadeleştirildi. Her olay farklıdır. Aktif bir veri sızıntısı varsa erişimi kısıtlamak ilk adım olabilir; yalnızca şüpheli bir kayıt varsa önce doğrulama yapılır. Bu yüzden sırayı bir kontrol listesi gibi değil, karar verirken dikkate alınacak bir çerçeve olarak kullanın. Kurumunuzun yazılı bir olay müdahale planı varsa her zaman ona göre hareket edin.

Uyarının ve bulguların doğruluğunu kontrol edin

İlk soru, gördüğünüz şeyin gerçekten bir güvenlik olayı olup olmadığıdır. İzleme aracının uyarısını, ilgili günlük kaydıyla doğrulayın. Ekibinizde o saatte sunucuya bağlanan, güncelleme yapan ya da yeni bir yazılım kuran olup olmadığını sorun. Planlı bir değişiklik bulursanız olay burada kapanabilir. Bulamazsanız, gözlemlerinizi saatleriyle birlikte not etmeye başlayın.

Etkilenen sunucu ve hizmetlerin kapsamını belirleyin

Şüpheli hesap ya da anahtar başka hangi sunucularda geçerli? Aynı parola veya SSH anahtarıyla erişilen başka bir VDS, veritabanı sunucusu ya da panel var mı? Sunucuda hangi veriler tutuluyor: müşteri bilgileri, ödeme kayıtları, uygulama kaynak kodu, API anahtarları? Kapsamı bilmeden yapılan müdahale, saldırganın erişimini başka bir sistemde açık bırakabilir.

Olayın kritik seviyesini ve iş etkisini değerlendirin

Hizmet kesintisi, veri kaybı, kişisel veri sızıntısı ve itibar etkisini birlikte düşünün. Kişisel veri işleyen bir sistemde ihlal ihtimali varsa hukuk ya da uyum sorumlusunu erkenden bilgilendirin. Kişisel Verileri Koruma Kurulu’nun 2019/10 sayılı kararı, ihlalin öğrenilmesinden itibaren en geç 72 saat içinde Kurul’a bildirim yapılmasını öngörüyor. Bu bir hukuki tavsiye değildir; yükümlülüklerinizi uzmanınızla değerlendirin.

Kurumun prosedürlerine göre erişimi kısıtlayın veya sunucuyu izole edin

Amaç, saldırganın erişimini ve olası zararı sınırlarken kanıtı korumaktır. VDS’te bunun birkaç yolu vardır:

• Güvenlik duvarında yönetim portlarını yalnızca kendi sabit IP adresinize açmak. Bu kuralı uygularken kendi bağlantınızı kesmediğinizden emin olun.
• Sağlayıcınızın panelinde sanal konsol (VNC) erişimi varsa çalışmayı ağdan bağımsız bu konsoldan sürdürmek.
• Aktif saldırı trafiği ya da veri sızıntısı varsa sağlayıcınızdan sunucunun ağ erişimini geçici olarak kesmesini istemek.

CISA’nın fidye yazılımı rehberi, ağdan ayıramadığınız cihazları kapatmanın son çare olduğunu, çünkü kapatmanın bellekteki kanıtı sildiğini vurguluyor. İzolasyon kararını iletişimle birlikte planlayın. Five Eyes ülkelerinin ortak tavsiyesi, müdahale iletişiminin olayın yaşandığı ağ üzerinden yürütülmemesini öneriyor. Saldırgan sunucudaysa e-posta ya da sohbet trafiğinizi de görebilir.

Logları ve diğer önemli kanıtları koruyun

Müdahaleye başlamadan önce kayıtların bir kopyasını sunucu dışına alın. RFC 3227, kanıtı en uçucudan en kalıcıya doğru toplamayı önerir: önce bellek, çalışan süreçler ve ağ bağlantıları, sonra disk ve günlükler. Basit bir başlangıç:

# Anlık durum (ekran çıktısı da kanıttır)
date -u; who; ps auxf > /root/surecler.txt; sudo ss -tunap > /root/baglantilar.txt

# Günlükleri arşivleyip özetini alın, ardından başka bir makineye kopyalayın
sudo tar -czf /root/kanit-$(hostname)-$(date +%F).tar.gz /var/log /root/surecler.txt /root/baglantilar.txt
sha256sum /root/kanit-*.tar.gz

Arşivi scp ya da rsync ile güvendiğiniz başka bir sisteme taşıyın ve özet değerini ayrı bir yere not edin. VDS’e özgü bir avantaj da var: Sanallaştırma altyapısına bağlı olarak sağlayıcınız diskin, bazı altyapılarda belleğin de anlık görüntüsünü (snapshot) alabilir. Böyle bir imkân olup olmadığını müdahalenin başında sorun. Adli inceleme gerekebilecek ciddi bir olayda sunucuya dokunmadan önce bir uzmandan destek almak en güvenli yoldur.

Yetkisiz erişim yollarını belirleyin

Saldırgan sunucuya nasıl girdi? En sık rastlanan yollar şunlardır: tahmin edilen ya da sızdırılmış bir parola, güncellenmemiş bir uygulama veya eklenti, internete açık bırakılmış bir yönetim arayüzü ya da başka bir sistemden çalınmış bir SSH anahtarı. İlk erişim zamanını bulmak için kimlik doğrulama günlüklerini, web erişim kayıtlarını ve dosya değişiklik tarihlerini aynı zaman çizelgesine yerleştirin. Erişim yolunu bulmadan yapılan temizlik, saldırganın aynı kapıdan tekrar girmesine izin verir. CISA ve ortaklarının tavsiyesi de bu konuda net: Belirtileri gidermek yerine kök nedeni giderin.

Güvenilir yedeklerin ve kurtarma seçeneklerinin kullanılabilirliğini kontrol edin

Hangi yedekleriniz var, ne zaman alındılar ve ihlal başlamadan önceki bir tarihe ait temiz bir kopya mevcut mu? Sunucunun içinde tutulan yedekler saldırgan tarafından değiştirilmiş ya da şifrelenmiş olabilir. Sunucu dışında, ayrı kimlik bilgileriyle erişilen yedekler daha güvenilirdir. Geri yüklemeye karar vermeden önce yedeğin gerçekten açılabildiğini ve gerekli verileri içerdiğini test edin.

Güvenlik açığını giderin ve kimlik bilgilerini güvenli bir sistemden yenileyin

Erişim yolunu kapatın: Eksik güncellemeleri uygulayın, açıkta kalan portu kapatın, zafiyetli eklentiyi kaldırın. Ardından sunucudaki ve sunucuyla ilişkili tüm kimlik bilgilerini yenileyin: root ve yönetici parolaları, SSH anahtarları, veritabanı parolaları, API anahtarları ve uygulama gizli anahtarları. Bu işlemi ele geçirilmiş sunucudan değil, temiz olduğundan emin olduğunuz bir cihazdan yapın.

Zamanlama da önemlidir. CISA ve ortakları, saldırganın erişimi henüz anlaşılmadan yapılan aceleci parola sıfırlamalarını sık yapılan hatalar arasında sayıyor. Saldırgan fark edildiğini anlayıp başka bir kalıcılık yöntemine geçebilir. Parolaları erişim yolu belirlendikten sonra ve planlı bir şekilde, mümkünse temizlenmiş ya da yeniden kurulmuş sisteme geçişle birlikte değiştirin.

Sistemi temiz ve doğrulanmış bir kaynaktan geri yükleme ihtiyacını değerlendirin

Saldırganın root ya da yönetici yetkisi kazandığına dair kanıt varsa sunucunun “temizlendiğinden” emin olmak çok zordur. Bu durumda en güvenilir yol, işletim sistemini sağlayıcının temiz kalıbından yeniden kurmak, uygulamayı doğrulanmış kaynak koddan dağıtmak ve verileri ihlal öncesine ait, kontrol edilmiş bir yedekten geri yüklemektir. Yalnızca düşük yetkili bir hesabın etkilendiği sınırlı olaylarda hedefli temizlik yeterli olabilir. Bu kararı bulgulara göre verin ve gerekçesini kaydedin.

Güncelleme, yetkilendirme ve izleme kontrollerini tamamlayın

Sunucu yeniden hizmete girmeden önce tespit bölümündeki kontrolleri tekrarlayın: bütün güncellemeler kurulu mu, yalnızca gerekli portlar açık mı, hesap listesi beklediğiniz gibi mi? Sonraki günlerde aynı IP’lerden ya da aynı yöntemle yeni deneme olup olmadığını izleyin. Saldırganların temizlik sonrası geri dönmeye çalışması nadir değildir.

Olayı belgeleyin ve tekrarını önleyecek önlemleri belirleyin

Zaman çizelgesini, bulguları, verilen kararları ve gerekçelerini yazılı hâle getirin. NIST SP 800-61 Rev. 3, olay müdahalesini tek seferlik bir iş olarak değil, risk yönetiminin sürekli bir parçası olarak ele alır. Bu yaklaşıma göre her olaydan çıkan dersler, önleme ve tespit süreçlerine geri beslenir. “Hangi kontrol olsaydı bu olayı daha erken fark ederdik?” sorusunun cevabı, bir sonraki iyileştirme listenizin ilk maddesidir.

Sık yapılan ve kanıt kaybına yol açan hatalar

Avustralya, Kanada, Yeni Zelanda, Birleşik Krallık ve ABD siber güvenlik kurumlarının ortak tavsiyesi (AA20-245A), olay müdahalesinde sık yapılan hataları şöyle sıralıyor:

• Müdahale ekibi verileri koruyup kurtarmadan önce etkilenen sistemlere müdahale etmek.
• Saldırganın altyapısına dokunmak (ping atmak, adresini sorgulamak, tarayıcıda açmak).
• Saldırganın altyapısını erkenden engellemek ve fark edildiğini belli etmek.
• Erişim anlaşılmadan aceleyle parola sıfırlamak.
• Erişimi anlamak için kritik olabilecek günlükleri korumamak ya da toplamamak.
• Müdahale iletişimini olayın yaşandığı ağ üzerinden yürütmek.
• Kök nedeni değil, yalnızca belirtileri gidermek.

VDS kullanıcıları için buna üç madde eklenebilir: plansız yeniden başlatma (bellekteki süreçler ve bağlantılar kaybolur), günlükleri silme veya döndürme (erişim yolunun izi kaybolur) ve aceleyle dosya temizleme (zararlı dosyanın yolu, tarihi ve içeriği kaybolur). İhlal şüphesi varsa önce kopyalayın, sonra müdahale edin.

VDS sağlayıcısının ve kullanıcının sorumlulukları

VDS, sanallaştırma katmanı (hypervisor) üzerinde çalışan bir sanal makinedir. Fiziksel sunucu, veri merkezi, elektrik, soğutma ve ağ altyapısı sağlayıcıya aittir. Sanal makinenin içi ise büyük ölçüde size aittir. NIST’in bulut tanımında (SP 800-145) altyapı hizmeti (IaaS) modeli bunu net bir şekilde anlatır: Kullanıcı alttaki altyapıyı yönetmez ama işletim sistemi, depolama ve kurduğu uygulamalar üzerinde kontrol sahibidir. Bazı ağ bileşenleri üzerinde de (örneğin sunucudaki güvenlik duvarı) sınırlı kontrolü vardır.

Katman	Genellikle kimin sorumluluğunda?	İhlal anında ne beklenir?
Fiziksel sunucu, disk, güç, soğutma	Sağlayıcı	Donanım kaynaklı bir sorun varsa sağlayıcı inceler
Ağ altyapısı ve DDoS koruması	Sağlayıcı	Saldırı trafiğinin ağ katmanında filtrelenmesi, gerekirse erişim kesme
Sanallaştırma katmanı (hypervisor)	Sağlayıcı	Sanal makineler arası izolasyonun korunması
İşletim sistemi ve güncellemeler	Kullanıcı	Yama, yapılandırma ve sıkılaştırma sizde
Hesaplar, parolalar, SSH/RDP erişimi	Kullanıcı	Kimlik bilgisi yenileme, erişim kısıtlama sizde
Uygulamalar, panel, CMS ve eklentiler	Kullanıcı	Güncelleme, zafiyetli bileşeni kaldırma sizde
Veriler ve yedekler	Kullanıcı (yedekleme hizmeti alındıysa ortak)	Temiz yedekten geri yükleme planı

Bu tablo genel bir çerçevedir. Sorumluluk paylaşımı sağlayıcıya, hizmet sözleşmesine ve satın alınan ek hizmetlere göre değişir. Önem Bilişim’in VDS kirala sayfasında da bu ayrım açıkça yazıyor: Donanım, elektrik ve ağ sağlayıcının sorumluluğundadır. Root/administrator yetkisiyle yönettiğiniz sunucunun bakımı, güvenliği ve güncellemeleri ise kullanıcının sorumluluğundadır. Fiziksel sunucuda bu çizgi farklı yerden geçer. Donanım katmanı da işin içine girdiğinde arıza ile saldırıyı nasıl ayırt edeceğinizi donanım arızası mı siber saldırı mı yazımızda anlattık.

Olay sırasında sağlayıcınızla iletişime geçtiğinizde şunları sormak işinizi hızlandırır:

• Ağ katmanında sunucuma yönelik ya da sunucumdan çıkan olağan dışı trafik görüyor musunuz?
• Sunucunun diskinin (ve mümkünse belleğinin) anlık görüntüsünü alabilir misiniz?
• Gerektiğinde ağ erişimini geçici olarak kesip konsol erişimini açık bırakabilir misiniz?
• Temiz işletim sistemi kalıbıyla yeniden kurulum nasıl yapılıyor, mevcut diske ne oluyor?

VDS güvenliğini artırmak için alınabilecek önlemler

İhlal müdahalesi pahalı ve yorucu bir süreçtir. Aşağıdaki önlemler hem açık sayısını azaltır hem de bir olay yaşandığında onu daha erken fark etmenizi sağlar. Yeni kurulan bir sunucuda ilk yapılması gereken ayarları adım adım uygulamak isterseniz VDS sunucu güvenliği için ilk 5 ayar rehberimize bakabilirsiniz.

• Yama yönetimi: Güvenlik güncellemelerini düzenli uygulayın. Debian/Ubuntu’da unattended-upgrades, AlmaLinux’ta dnf-automatic ile güvenlik güncellemeleri otomatikleştirilebilir. Desteği bitmiş sürümlerden zamanında çıkın.
• Çok faktörlü kimlik doğrulama: Kontrol paneli, CMS yönetim paneli ve müşteri paneli gibi web arayüzlerinde mutlaka açın. SSH’ta parola yerine anahtar kullanın.
• Minimum yetki: Günlük işler için root yerine sudo yetkili ayrı bir kullanıcı kullanın. Uygulamaları ayrı ve düşük yetkili servis hesaplarıyla çalıştırın.
• SSH/RDP erişim kısıtlaması: Yönetim portlarını yalnızca bilinen IP’lere açın ya da bir VPN arkasına alın. SSH’ta PermitRootLogin ve PasswordAuthentication ayarlarını kapatın. Fail2ban ya da Windows hesap kilitleme ilkesiyle deneme sayısını sınırlayın.
• Güvenlik duvarı: Varsayılan olarak gelen bağlantıları reddedin, yalnızca ihtiyaç duyulan portları açın. Veritabanı gibi iç servisleri internete açmayın.
• Web uygulaması koruması: Sunucuda web sitesi çalışıyorsa ağ katmanındaki DDoS korumasına ek olarak uygulama katmanında Layer 7 WAF koruması kullanmak, giriş sayfası denemeleri ve bot trafiği gibi saldırıları sunucuya ulaşmadan filtrelemeye yardımcı olur.
• Düzenli yedekleme: Yedekleri sunucunun dışında, ayrı kimlik bilgileriyle saklayın ve geri yüklemeyi düzenli olarak test edin. Önem Bilişim VDS’lerinde sepette eklenebilen ücretli Sunucu Yedekleme hizmeti günlük otomatik yedek alır. Yedekleme stratejisi kurarken VDS sunucularda otomatik yedekleme ve veri güvenliği yazımızdan yararlanabilirsiniz.
• Merkezi loglama ve izleme: Günlükleri sunucu dışındaki bir sisteme gönderin. Böylece saldırgan sunucudaki kayıtları silse bile kopyası elinizde kalır. CPU, disk, ağ ve başarılı yönetici oturumları için uyarılar tanımlayın.
• Dosya bütünlüğü izleme: AIDE gibi bir araçla sistem dosyalarının bilinen iyi durumunu kaydedin ve değişiklikleri düzenli olarak karşılaştırın.

VDS güvenlik kontrol listesi

Aşağıdaki listeyi düzenli kontrollerde ve bir olay sırasında kullanabilirsiniz. İşaretledikçe ilerleme çubuğu dolar.

Sıkça sorulan sorular

VDS güvenliği nasıl kontrol edilir?

İşletim sistemi ve yazılım sürümlerini, bekleyen güvenlik güncellemelerini, dinleyen portları, kullanıcı hesaplarını ve yönetici yetkilerini, SSH/RDP oturum kayıtlarını ve kaynak kullanımını düzenli olarak gözden geçirin. Bunlara Lynis gibi bir denetim aracıyla yapılan periyodik kontrolleri ekleyin. Bütün taramaları yalnızca yetkili olduğunuz sunucularda yapın.

Sunucunun ihlal edildiği nasıl anlaşılır?

Tanımadığınız bir IP’den yapılan başarılı oturum, bilinmeyen hesap ya da SSH anahtarı, yanlış dizinden çalışan süreçler, sizin eklemediğiniz zamanlanmış görevler ve günlüklerdeki açıklanamayan boşluklar en önemli işaretlerdir. Tek bir işaret kesin kanıt değildir. Birden fazla bulgunun aynı zaman aralığında birbirini doğrulaması gerekir.

Sunucu ne zaman izole edilmelidir?

Aktif bir veri sızıntısı, sunucudan dışarıya giden saldırı trafiği ya da yayılan bir zararlı yazılım varsa erişimi kısıtlamak öncelik kazanır. Yalnızca şüpheli bir kayıt varsa önce doğrulama yapılır. İzolasyon için mümkünse sunucuyu kapatmak yerine ağ erişimini sınırlayın. Kapatmak bellekteki kanıtı siler.

Saldırıya uğrayan VDS’i hemen yeniden kurmak doğru mu?

Çoğu zaman yeniden kurulum doğru sonuçtur ama ilk adım değildir. Önce günlüklerin ve önemli dosyaların kopyasını sunucu dışına alın, erişim yolunu belirleyin ve temiz bir yedeğin varlığını doğrulayın. Erişim yolu bilinmeden yapılan yeniden kurulum, aynı açığın yeni sunucuda da kalmasına yol açar.

Yedekten geri dönmek ihlali çözer mi?

Tek başına çözmez. Yedek ihlal başlamadan önceki bir tarihe aitse ve saldırganın kullandığı açık kapatıldıysa güvenli bir dönüş noktasıdır. Açık kapatılmadan geri yüklenen sistem aynı yoldan tekrar ele geçirilebilir. Yedeğin kendisinin de değiştirilmemiş olduğundan emin olun.

VDS’te güvenlikten sağlayıcı mı sorumludur, kullanıcı mı?

Genel olarak fiziksel donanım, veri merkezi, ağ altyapısı ve sanallaştırma katmanı sağlayıcıya, işletim sistemi, güncellemeler, hesaplar, uygulamalar ve veriler kullanıcıya aittir. Kesin paylaşım, hizmet sözleşmesine ve yönetim ya da yedekleme gibi ek hizmetlere göre değişir.

Sonuç

VDS’te güvenlik, açıkları ihlale dönüşmeden kapatmak ve bir şeyler ters gittiğinde sakin ve sıralı hareket etmektir. Bugün yapabileceğiniz ilk kontroller basittir. Bekleyen güvenlik güncellemelerini uygulayın, dinleyen portları güvenlik duvarı kurallarınızla karşılaştırın, hesap ve SSH anahtarı listesini gözden geçirin ve son başarılı oturumların hepsini tanıdığınızdan emin olun.

Bir ihlalden şüphelendiğinizde de aynı ilke geçerlidir: önce doğrulayın, kapsamı belirleyin, kanıtı koruyun, erişim yolunu bulun ve ancak ondan sonra temizleyin ya da yeniden kurun. Kişisel veri, ödeme bilgisi ya da birden fazla sistemi etkileyen bir olayla karşı karşıyaysanız olay müdahalesi ve adli inceleme konusunda deneyimli bir uzmandan destek almak hem zaman hem de kanıt kaybını önler.

Kaynaklar

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management (Nisan 2025)
• NIST SP 800-145 — The NIST Definition of Cloud Computing (Eylül 2011)
• CISA ve ortakları — AA20-245A: Technical Approaches to Uncovering and Remediating Malicious Activity
• CISA — #StopRansomware Guide (Eylül 2023)
• RFC 3227 — Guidelines for Evidence Collection and Archiving
• Microsoft — 4624(S): An account was successfully logged on
• Microsoft — 4625(F): An account failed to log on
• Microsoft — 4698(S): A scheduled task was created
• Microsoft — 4732(S): A member was added to a security-enabled local group
• Debian 12 sürüm notları — Sistem günlüğündeki değişiklikler
• DNF komut başvurusu — updateinfo ve –security
• debsums(1) kılavuz sayfası
• CISOfy — Lynis
• KVKK — Kişisel Veri İhlallerinin Bildirimi (Kurul Kararı 2019/10)