Ele Geçirilen VPS Nasıl Kurtarılır?

Ele geçirilmiş bir VPS'i temizlemeyin

VPS'iniz ele geçirildiğinde, vereceğiniz en önemli karar herhangi bir komut çalıştırmadan önce gelir. Makineyi temizlemeye çalışmayın. Sağlayıcı üzerinden izole edin, kanıt olarak diskin anlık görüntüsünü (snapshot) alın, üzerinde tutulan tüm kimlik bilgilerini değiştirin ve ardından güvendiğiniz kaynaklardan temiz bir sunucu üzerinde yeniden kurulum yapın.

Bir rootkit'in temizlendiğini kanıtlayamazsınız, çünkü bunu kanıtlayacak araçlar saldırganın kontrolündeki araçlardır.

Tüm argüman bundan ibarettir. Bunun arkasındaki mekanizma şöyledir: root yetkisine ulaşan bir saldırgan, bir işlem kimliğinin (PID) çıktıda asla görünmemesi için ps dosyasını değiştirebilir. /etc/ld.so.preload içindeki tek bir satır, saldırganın kodunu kutudaki her dinamik bağlantılı programa yükleyebilir; böylece ls, ss ve find araçlarının tümü aynı tutarlı yalanı söyler. Yüklenebilir bir çekirdek modülü (LKM), dosyaları sistem çağrısının altında gizleyebilir; bu sayede yeni indirilmiş bir ikili dosya bile diski temiz görür. Madenciyi silersiniz, CPU grafiği düşer ve sunucu sessizleşir. Sessizlik, çalışan bir arka kapının da görüntüsüdür.

Yeniden kurulum, hissettirdiğinden daha az maliyetlidir. Tipik bir VPS; bir avuç paket, bir yapılandırma dizini ve bir veri kümesinden oluşur; bu nedenle yeniden kurulum, sonu belli olan sınırlı bir iştir. Saldırganın yaptığı her değişikliği aramak ise ucu açık bir süreçtir ve asla kesin bir sonuca ulaşmaz.

Sunucunun gerçekten ele geçirildiğini doğrulayın

Hacker saldırısına uğradığı bildirilen sunucuların çoğu aslında saldırıya uğramamıştır. Günde binlerce başarısız SSH girişi denemesi internetin arka plan gürültüsüdür; çünkü her genel IPv4 adresi sürekli taranır. lastb çıktısının root ve admin denemeleriyle dolu olması, tarayıcıların portunuzu bulduğu anlamına gelir. Bu, birinin içeri girdiği anlamına gelmez.

Şu sinyaller ise bir şeylerin ters gittiğine işaret eder:

• Accepted password for root from 203.0.113.7 gibi, sizin yapmadığınız başarılı bir giriş.
• authorized_keys içerisinde sizin eklemediğiniz bir anahtar.
• Sunucunuzdan dışarıya giden trafikle ilgili servis sağlayıcınızdan gelen bir kötüye kullanım bildirimi.
• Bir çekirdek iş parçacığının (kernel thread) adını kopyalayan ve %100 CPU kullanan bir süreç. Açık Redis ve Docker soketleri üzerinden bırakılan madenciler, genellikle kdevtmpfsi ve kinsing gibi isimlerle rapor edilir.
• Servislerinizin hiçbirinin kullanmadığı adreslere yapılan giden bağlantılar.

Çekirdek iş parçacığı kılığına girme durumunu test etmenin hızlı bir yolu vardır. Gerçek çekirdek iş parçacıkları köşeli parantez içinde yazdırılır ve arkalarında çalıştırılabilir bir dosya bulunmaz; bu nedenle sudo ls -l /proc/<pid>/exe komutu bunlar için No such file or directory hatası verir. Eğer [kworker/0:2] olarak listelenen bir sürecin exe bağlantısı /tmp altında bir yeri işaret ediyorsa, bu çekirdek ismi kullanan sıradan bir kullanıcı programıdır.

Bu kontrolleri, sunucunun sizi yanıltabileceğini bilerek çalıştırın. Bu kontroller bir şeylerin yanlış olduğuna karar vermek için yeterlidir. Ancak hiçbir sorun olmadığına karar vermek için yeterli değildir.

Ağı sunucu içinden değil, sağlayıcı panelinden kesin

İzolasyon ilk adımdır; bir başkası hâlâ kabuk (shell) erişimine sahipken atılan her adım boşa gider. Canlı bir saldırgan izlerken günlükleri okumak, anahtarları yenilemek ve verileri geri yüklemek anlamsızdır.

Bunu, işletim sisteminizin dışında çalışan ağ güvenlik duvarı üzerinden, sağlayıcı kontrol panelinizde yapın. Gelen ve giden trafiği engelleyin ve erişim yolu olarak yalnızca web konsolunu kullanın. Orada uygulanan kurallar, disk üzerinde gerçekleşen hiçbir şeyden etkilenmez.

Bunu sunucu içinden yapmamanızın iki nedeni vardır. Ele geçirilmiş bir çekirdek içinde yapılandırdığınız güvenlik duvarı yine o çekirdek tarafından uygulanır; root kullanıcısı, sizin yazdığınız kadar kolay bir şekilde nftables kurallarını silebilir. Ayrıca SSH üzerinden sudo ip link set enp1s0 down komutu önce kendi oturumunuzu keser ve inceleme yaptığınız makineden dışarı atılmanıza neden olur.

Gelen trafiğin yanı sıra giden trafiği de engelleyin. Ters kabuk (reverse shell), sunucunuzdan saldırgana doğru dışarıya bağlantı kurar; bu nedenle yalnızca gelen trafiği engellemek, kurulmuş bir bağlantının sorunsuz çalışmaya devam etmesine neden olur. Eğer sağlayıcınız yalnızca gelen trafik kurallarına izin veriyorsa, geriye kalan seçenekler ağ arayüzünü ayırmak veya örneği (instance) kapatmaktır.

Henüz yeniden başlatma yapmayın. Önce /var/log/journal dizininin var olup olmadığını kontrol edin. Eğer bu dizin yoksa, journald kayıtları bellekte tutulan /run/log/journal konumuna yazıyordur; bu durumda yeniden başlatma, saldırıya dair tüm kayıtları siler. Çalışan süreçler de yeniden başlatma ile kaybolur; oysa bu süreçlerin komut satırı çıktıları, elde edebileceğiniz en net kanıtlardır.

Herhangi bir işleme başlamadan önce diskin anlık görüntüsünü (snapshot) alın

Anlık görüntü (snapshot) ve yedekleme, bu bağlamda farklı işlevlere sahiptir. Şu an alacağınız anlık görüntü, güvenliği ihlal edilmiş bir diskin kopyasıdır; bu sizin kanıtınızdır ve yanlışlıkla bir şeylerin üzerine yazdığınızda geri dönüş yapmanızı sağlayan tek yoldur. Eski yedekleriniz ise kurtarma yoludur. Eğer servis sağlayıcınızın paneli bu iki terimi birbirinin yerine kullanıyorsa, önce VPS anlık görüntüleri ile gerçek yedeklemeler arasındaki farklar konusunu okuyun; çünkü saklama kuralları ve geri yükleme davranışları aynı değildir.

Sunucuya tekrar giriş yapmadan önce anlık görüntüyü sağlayıcı panelinden alın. Canlı bir anlık görüntü "crash consistent" (çökme tutarlı) yapıdadır; diski tıpkı fişin çekildiği o anki haliyle yakalar. Bu durum kanıt toplamak için yeterlidir. Anlık görüntüye, kimsenin yanlışlıkla geri yüklemeyeceği bir isim verin. COMPROMISED-do-not-restore-2026-08-12 kadar net bir isimlendirme, gereken ciddiyeti yansıtacaktır. Bu görüntüyü, incelemeniz tamamlanana ve barındırma sağlayıcınızla olan tüm kötüye kullanım (abuse) bildirimleri kapanana kadar saklayın.

SSH erişimi kaybolduğunda sisteme nasıl girilir

İki yöntem mevcuttur ve her ikisi de sağlayıcı panelinde yer alır. Web konsolu (VNC veya seri bağlantı), makineye fiziksel bir klavye takmışsınız gibi doğrudan erişim sağlar. Bu yöntem, sshd servisi çalışmadığında, güvenlik duvarı yanlış yapılandırıldığında veya saldırgan SSH portunu değiştirdiğinde işe yarar. Konsol yerel parola ile kimlik doğrulaması yapar; bu nedenle yalnızca SSH anahtarı ile erişilen sunucularda, konsolu kullanabilmek için önce root parolasının sıfırlanması gerekebilir.

Kurtarma modu (rescue mode) daha iyi bir seçenektir. Bu mod, diskinizi bağlı ancak çalışır durumda olmayan küçük bir canlı sistem ile başlatır. Bu sayede komutlarınız güvenilirdir; çünkü ele geçirilmiş çekirdek ve ikili dosyalar çalıştırılmaz. Diski salt okunur (read-only) olarak bağlayın.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

Eğer lsblk komutu düz bir bölüm yerine LVM (logical volume manager) birimleri gösteriyorsa, bunları önce sudo vgchange -ay ile etkinleştirin, ardından /dev/mapper/ altında görünen aygıtı bağlayın.

İçeride neler olup bittiğine bakmak için bağlı diske chroot yapmayın. Bir chroot işlemi, saldırganın ikili dosyalarını sizin yetkilerinizle çalıştırır; bu da kurtarma modunda başlatma amacınızı tamamen boşa çıkarır.

Hala güvenilir olan kanıtları toplayın

Bunları, diskin salt okunur olarak /mnt/victim konumuna bağlandığı kurtarma modunda çalıştırın. Giriş kayıtlarıyla başlayın; çünkü bunlar ihlalin zamanını belirler ve bir zaman aralığına sahip olduğunuzda diğer her şey daha kolaylaşır.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

Eksik bir /var/log/auth.log tek başına şüpheli değildir. Bazı güncel Ubuntu imajları rsyslog olmadan gelir, bu nedenle sshd kayıtları yalnızca journal içine yazılır; journalctl -D satırı da bunu okur. Dikkat edilmesi gereken şey, aksi takdirde sürekli olan kayıtlardaki bir boşluk veya sıfır bayta düşürülmüş bir kayıt dosyasıdır. Kayıt silme işlemi yaygındır ve genellikle acemice yapılır.

Sırada hesaplar ve anahtarlar var.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

awk satırı, kullanıcı kimliği 0 olan her hesabı yazdırır. Bu çıktıda root dışında herhangi bir şey olması, ikinci bir root hesabı olduğu anlamına gelir. find deseni, authorized_keys2 dosyasını da kasten eşleştirir; çünkü OpenSSH varsayılan olarak her iki dosya adını da okur ve ikincisini gözden kaçırmak kolaydır. Eğer lsattr öznitelik listesinde bir i yazdırırsa, dosya değiştirilemez durumdadır: bir saldırgan bu bayrağı ayarlar, böylece anahtarlarını silme girişiminiz Operation not permitted hatasıyla başarısız olur ve yorgun bir yönetici düzenlemenin başarılı olduğunu varsayar.

Kalıcılık az sayıda yerde gizlenir, bu yüzden hepsini kontrol edin.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

/etc/ld.so.preload normal bir Ubuntu veya Debian sisteminde bulunmaz, bu nedenle No such file or directory sağlıklı sonuçtur ve herhangi bir içerik dikkatinizi hak eder. base64 -d çıktısını bir shell'e yönlendiren bir giriş dosyası da aynı durumdadır: meşru yapılandırmalar kendi metnini gizleme ihtiyacı duymaz.

Zaman çizelgesini değişiklik zamanına (ctime) göre oluşturun, değiştirme zamanına (mtime) göre değil.

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch, değiştirme zamanını saldırganın istediği herhangi bir değere ayarlar, bu yüzden mtime kolayca yalan söyler. Değişiklik zamanı (ctime), inode üzerindeki herhangi bir değişiklikte güncellenir ve touch bunu geriye doğru hareket ettiremez, bu nedenle -newerct yakın zamanda yazılanların daha dürüst bir listesini verir. Bu yine de kesin kanıt değildir, çünkü root sistem saatini değiştirebilir veya doğrudan blok aygıtına yazabilir.

Paket bütünlüğü bir komut ve bir uyarıyı hak eder. Canlı bir sistemde sudo dpkg --verify, sağlama toplamı artık eşleşmeyen her paketlenmiş dosya için sağlama toplamı sütununda bir 5 ile bir satır yazdırır; sudo debsums -ac ise debsums paketi yüklendiğinde yapılandırma dosyaları dahil aynı işi yapar. Sonucu yalnızca tek bir yönde okuyun. Değiştirilmiş bir /usr/sbin/sshd gerçek kanıttır. Temiz bir rapor hiçbir şeyi kanıtlamaz, çünkü ikili dosyayı değiştiren aynı root hesabı, /var/lib/dpkg/info/ altındaki sağlama toplamı listelerini de yeniden yazabilir. rkhunter ve chkrootkit gibi rootkit tarayıcıları aynı kuralı izler: bir bulgu bilgidir, temiz bir tarama ise bir aklanma değildir.

Yıkıcı bir işlem yapmadan önce topladıklarınızı makineden dışarı kopyalayın.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

Bu hash değerini sunucunun dışında bir yere not edin. Eğer bu durum bir sigorta talebine veya polis raporuna dönüşürse, arşivin toplandığı andan itibaren değişmediğini gösterebilmek, kanıt ile bir dosya klasörü arasındaki farkı yaratır. Soruşturma sırasında yanlışlıkla bir şeyleri silmek normaldir; snapshot ve bu arşiv, durumu kurtarılabilir kılan şeydir. Daha sonra hatalı bir rm işlemini geri almak, insanların beklediğinden çok daha zordur; rm -rf ile silinen dosyaları kurtarma bölümünde açıklandığı gibi.

Giriş kapısını bulma

Giriş yolunu kapatmayan bir yeniden kurulum, sunucunun günler içinde tekrar ele geçirilmesine neden olur; çünkü sizi ilk kez bulan tarama işlemleri durmaksızın devam eder. Tek sunuculu sistemlerdeki ihlallerin çoğu dört ana kapıdan kaynaklanır.

SSH parola ile giriş. Tanımadığınız bir adresten gelen Accepted password for root satırı, sorunun tek başına yanıtıdır. /etc/ssh/sshd_config içindeki ve /etc/ssh/sshd_config.d/ altındaki her dosyada PasswordAuthentication ayarını kontrol edin. sshd, bir anahtar kelime için elde ettiği ilk değeri kullanır; Ubuntu'da Include satırı ana dosyanın en üstünde yer aldığından, sonradan eklenen bir yapılandırma dosyası, dosyanın alt kısımlarında değiştirdiğiniz ayarı sessizce geçersiz kılar.

Kimlik doğrulaması olmayan bir servis. 6379 portunda Redis, 2375 portunda Docker API veya 127.0.0.1 yerine 0.0.0.0 adresine bağlı bir veritabanı. Docker, yaygın bir sürpriz kaynağıdır. Bir container portunu dışarı açmak, ufw zincirlerinden önce değerlendirilen DNAT (hedef ağ adresi çevirisi) kurallarını sisteme ekler. Bu nedenle ufw status, bir portu kapalı olarak raporlasa bile, arkasındaki container tüm internete yanıt veriyor olabilir. Yeniden kurulumdan önce bunu anladığınızdan emin olun: Docker published ports bypass ufw belgesi, kural sıralamasını ve çözüm yolunu açıklamaktadır.

Yamalanmamış bir web uygulaması. Web sunucusu erişim loglarında, şüpheli etkinliklerin başladığı ilk zaman damarı civarında bir yükleme (upload) veya yönetici (admin) yoluna yapılan POST isteklerini arayın. Ardından web kök dizini altında, bu zaman damarıyla eşleşen değişiklik saatine sahip dosyaları inceleyin. Yükleme dizinlerinde bulunan yabancı bir PHP dosyası, klasik bir sonuçtur.

Sızdırılmış kimlik bilgileri. Bir depoya (repository) işlenmiş bir anahtar, sohbet ortamına yapıştırılmış bir token veya yanlış yapılandırılmış bir web sunucusu tarafından statik dosya olarak sunulan bir .env dosyası. Otomasyon süreçleri bu hataların kazara yapılmasını kolaylaştırır; bu durum keeping secrets out of AI agents and their config files konusunun temel argümanıdır.

Tüm bu incelemelerden sonra giriş kapısını tespit edemiyorsanız, kimlik bilgilerinin sızdırıldığını varsayın ve makinede tutulan her türlü gizli veriyi kamuya açık kabul edin.

Makinenin erişebildiği tüm kimlik bilgilerini yenileyin

Yenileme işlemini ağ bağlantısını kestikten sonra yapın, öncesinde asla yapmayın. Saldırganın bağlantısı devam ederken yenileme yapmak, yeni gizli bilgileri doğrudan saldırgana teslim etmek anlamına gelir.

• Sunucuda depolanan her SSH özel anahtarı ve eşleşen genel anahtara güvenen diğer tüm hesaplar.
• ssh -A ile makineye yönlendirdiğiniz tüm anahtarlar. Agent forwarding, /tmp altında bir soket bırakır; o makinedeki root yetkisine sahip bir kullanıcı, oturumunuz açık kaldığı sürece anahtarınızın kabul edildiği her yerde sizin adınıza kimlik doğrulaması yapabilir.
• .env dosyalarındaki, systemd Environment= satırlarındaki, CI yapılandırmalarındaki ve sağlayıcı kimlik bilgilerindeki API belirteçleri.
• Veritabanı parolaları ve bunları kullanan uygulama hesapları.
• Sunucunun tuttuğu TLS (transport layer security) özel anahtarları. Sertifikayı yeniden oluşturun ve eskisini iptal edin.
• İki faktörlü kimlik doğrulaması etkinleştirilmiş şekilde, hosting hesabı parolanız. Bu panel, sahip olduğunuz her sunucuyu yeniden oluşturabilir, anlık görüntüsünü alabilir ve konsol üzerinden erişebilir; bu nedenle gerçek çevre güvenliği burasıdır.
• İhlal edildiği sırada bu ana makinede bir kabuk oturumuna yazılan her parola; çünkü root yetkisine sahip bir kullanıcı, terminal oturumunu gerçekleştiği anda kaydedebilir.

Eğer makinedeki bir parola başka herhangi bir yerde kullanılıyorsa, o yerdeki parolayı da değiştirin. Parola tekrarı, tek bir ihlal edilmiş VPS'in ihlal edilmiş bir e-posta hesabına dönüşme yoludur.

Yeniden oluşturma kontrol listesi

1. Yeni bir sunucuyu temiz bir dağıtım imajından oluşturun. Compromised (ele geçirilmiş) sunucunun snapshot'ını veya tüm root dosya sistemini içeren bir yedeği kullanmayın.
2. Paketleri dağıtımın kendi depolarından kurun. Eski diskten hiçbir binary dosyasını kopyalamayın.
3. Yalnızca verileri, zaman çizelgenizdeki en eski kanıttan daha eski bir yedekten geri yükleyin. Veritabanı dökümleri, yüklenen dosyalar ve uygulama durumu buna dahildir. /etc, /usr ve eski unit dosyalarını geride bırakın.
4. Yenilenen gizli anahtarları (secrets) manuel olarak girin. Eski .env dosyasını kopyalamayın.
5. Geri yüklenen web içeriğini, tekrar yayına almadan önce saldırı aralığında eklenmiş dosyalar için inceleyin.
6. İnternete açmadan önce güvenliği sıkılaştırın: yalnızca anahtar tabanlı SSH, root olmayan bir kullanıcı hesabı, varsayılan olarak gelen trafiği reddeden bir güvenlik duvarı kullanın ve hiçbir servisi gereğinden fazla dış dünyaya açmayın. Yeni bir VPS üzerinde ilk on dakika adımlarını uygulayın, ardından SSH güvenliğini doğru şekilde yapılandırın ve giriş denemelerini azaltmak için Ubuntu 24.04 üzerinde fail2ban kurulumunu yapın. Her servise kendi en düşük yetkili hesabını atayın; böylece bir sonraki sızma girişimi root yetkisiyle sonuçlanmaz.
7. Eski sunucuyu kapatın ve soruşturma ile olası kötüye kullanım bildirimleri sonuçlanana kadar snapshot'ını saklayın.
8. Yedekleme sisteminizi düzeltin. Eğer 3. adımda tahmin yürütmek zorunda kaldıysanız, asıl ders yedekleme geçmişinizin saldırı öncesine ulaşacak kadar uzun olmamasıdır. Uzun süreli saklama politikasına sahip, sunucu dışı ve sürümlenmiş yedekler bir sonraki seferde temiz bir geri yükleme noktası sağlar: VPS üzerinde restic yedekleri size her ikisini de sunar.

Saldırı tarihini belirleyemiyorsanız, güvenli bir yedek seçemezsiniz. Bu durumda yalnızca gözle inceleyebileceğiniz verileri geri yükleyin: okuyabildiğiniz bir SQL dökümü veya listeleyebildiğiniz bir görsel dizini gibi. Çalıştırılabilir her dosyayı şüpheli kabul edin ve bunları depolardan yeniden kurun.

Sunucu sağlayıcınızdan gelen kötüye kullanım bildiriminin anlamı

Çoğu kullanıcı, sunucusunun ele geçirildiğini kendi izleme araçlarından değil, hizmet sağlayıcısından öğrenir. Sağlayıcılar dışa giden trafiği görür: diğer ağlara yönelik SSH kaba kuvvet saldırıları, 25 numaralı port üzerinden gönderilen spam veya bir yansıtma saldırısındaki paylaşımlar. Destek talebi genellikle zaman damgalarını, portları ve akış örneklerini, saatlerle ölçülen bir son teslim tarihiyle birlikte içerir.

Cevabınız sadece sunucunun izole edildiği ve yeniden kurulduğu olsa bile mutlaka yanıt verin. Destek talebi yanıtsız kaldığında sağlayıcılar sunucuyu null-route işlemine tabi tutar veya askıya alır; bu da olayı bir kesintiye dönüştürür. Ardından raporun temelini oluşturan ham günlük kayıtlarını talep edin. Bu zaman damgaları makinenizin dışında kaydedildiği için saldırganın değiştiremediği tek zaman çizelgesi parçasıdır ve genellikle saldırı tarihini diskteki herhangi bir veriden daha doğru gösterir.

Ele geçirilmiş bir müşteri sunucusu, bir sağlayıcı için rutin bir iştir ve bu durumu iyi yönetmeniz aleyhinize bir durum oluşturmaz. VPS barındırmanın güvenli olup olmadığı konusundaki daha geniş kapsamlı soru, büyük ölçüde müşterinin yaptığı yapılandırmaya bağlıdır; bu da tam olarak sıfırdan tekrar yapacağınız kısımdır.

Ne zaman profesyonel destek alınmalı

• Sunucu, başka kişilere ait kişisel veriler barındırıyorsa. GDPR (Genel Veri Koruma Tüzüğü) kapsamında, bir kişisel veri ihlali durumunda denetleyici makama gecikmeksizin ve mümkünse ihlalin öğrenilmesinden itibaren 72 saat içinde bildirimde bulunulmalıdır. Bu sürenin başlayıp başlamadığını değerlendirmek sistem yöneticisinin değil, hukuk biriminin görevidir.
• Ödeme kartı verileri kapsam dahilindeyse. Kart kuruluşları onaylı bir adli bilişim uzmanı talep eder; sizin yapacağınız müdahaleler kanıt bütünlüğüne zarar verebilir.
• Bir şantaj talebi varsa veya verileriniz şifrelenmişse.
• Makine diğer sistemlere erişebiliyorsa: bir iç ağ, bir hipervizör veya üretim kimlik bilgilerini tutan bir CI çalıştırıcısı gibi. Bir gruptaki tek bir sunucunun güvenliğinin ihlal edilmesi, aksi kanıtlanana kadar tüm grubun ihlal edildiği anlamına gelir.
• Kanıtların sigorta veya kolluk kuvvetleri nezdinde geçerli olması gerekiyorsa. Snapshot aşamasında durun, tam bir disk imajı alın ve kimin, ne zaman müdahale ettiğini kayıt altına alın.

Kendi servislerinizi çalıştırdığınız ve başka kimsenin verisinin bulunmadığı tek bir VPS için yukarıdaki yönergeler tüm süreci kapsar. Sağlayıcı üzerinden izolasyonu sağlayın. Kanıt için snapshot alın. Hâlâ güvenilir olan verileri toplayın. Her şeyi yenileyin. Temiz bir kurulum yapın.

FAQ

Ele geçirilmiş bir VPS'i yeniden kurmak yerine temizleyebilir miyim?

Güvenilir bir şekilde hayır, çünkü ele geçirilmiş bir sistemden kendi durumunu raporlamasını istiyor olursunuz. Değiştirilmiş bir ps bir süreci gizleyebilir, /etc/ld.so.preload içindeki bir satır çalıştırdığınız her dinamik bağlantılı araca kod enjekte edebilir ve bir kernel modülü dosyaları tüm programlardan aynı anda saklayabilir. Bir şeyleri bulduğunuzda bu bir kanıttır. Ancak yokluğu kanıtlayamazsınız, bu yüzden temiz bir sonuç güvenilir değildir. Temizleme işlemi yalnızca sunucuda sizin için önemli hiçbir şey yoksa ve tekrar ele geçirilebileceğini kabul ediyorsanız savunulabilir.

Ele geçirilmiş bir sunucuyu kapatmalı mıyım yoksa çalışır durumda mı bırakmalıyım?

Önce servis sağlayıcı üzerinden ağ bağlantısını kesin, ardından bir snapshot almak ve çalışan süreçleri incelemek için yeterli süre çalışır durumda bırakın. Kapatmak süreç listesini yok eder ve /var/log/journal mevcut değilse, journald verileri /run altında belleğe yazdığı için günlük kayıtlarını tamamen siler. Eğer sunucu aktif olarak başka ağlara saldırıyorsa ve giden trafiğini engelleme imkanınız yoksa, her şeye rağmen kapatın. Zararı durdurmak, kanıtları korumaktan daha önceliklidir.

Saldırganın sisteme ne zaman girdiğini nasıl anlarım?

/var/log/auth.log içinde veya günlük kayıtlarında açıklayamadığınız en eski Accepted password veya Accepted publickey satırını bulun. Bunu, ctime'ın mtime'dan daha zor değiştirilebilir olması nedeniyle find / -xdev -newerct 'YYYY-MM-DD' -type f kullanarak bir değişiklik zamanı listesi ile çapraz kontrol edin. Ardından her ikisini de sunucu dışında kaydedildiği için değiştirilmesi mümkün olmayan, servis sağlayıcınızın gönderdiği kötüye kullanım bildirimindeki zaman damgalarıyla karşılaştırın. Bu üç tarihten en eskisinden daha eski bir yedekleme seçin. Eğer hiçbir şey eşleşmiyorsa, ele geçirilme tarihinin yedekleme geçmişinizden daha eski olduğunu varsayın ve yalnızca inceleyebileceğiniz verileri geri yükleyin.

Ele geçirilme sonrasında yedeklerimi geri yüklemek güvenli midir?

İnceleme yapıldığı sürece veriler genellikle güvenlidir. Sistem dosyaları ise güvenli değildir. İzinsiz girişten sonra alınan bir yedekleme arka kapıyı da içerir, bu nedenle tüm root dosya sistemini geri yüklemek saldırganı da geri yükler. Yedekleme deposunun kendisini de kontrol edin: Eğer yedekleme kimlik bilgileri ele geçirilmiş sunucuda saklanıyorsa, geçmiş silinmiş veya değiştirilmiş olabilir; bu durum, salt yazılır (append-only) veya çekme tabanlı (pull-based) yedekleme hedeflerinin kullanılmasını gerektirir. Uygulama verilerini geri yükleyin, ardından yazılımı dağıtım depolarından yeniden kurun.

VPS'imin ele geçirildiğini birilerine bildirmeli miyim?

Servis sağlayıcınızın kötüye kullanım bildirimine mutlaka yanıt verin. Bunun ötesinde, sunucuda kimin verilerinin bulunduğu önemlidir. Başkalarına ait kişisel veriler, GDPR'nin denetleyici makama 72 saat içinde bildirimde bulunma zorunluluğu gibi yasal yükümlülükleri tetikleyebilir. Eğer sunucuda kullanıcı kimlik bilgileri saklanıyorsa, bu kullanıcılara bildirimde bulunun ki başka yerlerdeki şifrelerini değiştirebilsinler. Eğer sunucudaki anahtarlar kod barındırma platformu veya bulut hesabı gibi üçüncü taraf sistemlere erişim yetkisi veriyorsa, bu sağlayıcılara bildirimde bulunun ki kötüye kullanım olup olmadığını kontrol edebilsinler. Başkasına ait veri barındırmayan tamamen kişisel bir sunucu için, kötüye kullanım bildirimi dışında bir yükümlülük bulunmamaktadır.