Siber Güvenlik Tehditlerinde Artış: Gerçek Nedenler ve Sunucu Tarafında Alınacak Önlemler

Siber güvenlik tehditlerinde artış gerçekte ne anlama geliyor?

Son birkaç yılda hem müşterilerimizle yaptığımız görüşmelerde hem de kendi altyapımızdaki loglarda ortak bir tablo görüyoruz: siber güvenlik tehditlerinde gözle görülür bir artış var. Bu artış sadece sayısal değil; saldırıların karmaşıklığı, kalıcılığı ve yarattığı iş kesintisi de belirgin şekilde büyüyor. Basit bir parola deneme saldırısından, çok katmanlı fidye yazılımı operasyonlarına kadar geniş bir yelpazeden bahsediyoruz.

Bir proje planlama toplantısında kapasite hesabı yaparken artık sadece CPU, RAM ve disk IOPS konuşmuyoruz; aynı anda DDoS dayanıklılık seviyesini, yedekleme stratejisini ve olay müdahale planını da masaya koyuyoruz. Çünkü altyapı tasarımı ile güvenlik artık birbirinden ayrı düşünülebilecek kavramlar değil. Sunucu tarafında yapılacak küçük bir hata, kötü niyetli biri için büyük bir fırsata dönüşebiliyor.

Bu yazıda, DCHost ekibi olarak sahada gördüğümüz eğilimleri, siber güvenlik tehditlerinde artışın gerçek nedenlerini ve özellikle hosting / sunucu tarafında alınabilecek somut aksiyonları detaylı ama anlaşılır bir dille toparlayacağız. Hem teknik ekipler hem de işi teknik olmayan işletme sahipleri için net bir yol haritası çıkarmaya çalışacağız.

Siber tehditler neden bu kadar arttı?

“Saldırılar arttı” cümlesi tek başına pek bir şey ifade etmiyor. Asıl soru şu: Neden arttı? Cevap birkaç ana başlıkta toplanıyor.

Saldırı yüzeyi patladı: Uzaktan çalışma, bulut, SaaS, IoT

Eskiden bir şirketin saldırı yüzeyi nispeten sınırlıydı: Ofisteki birkaç sunucu, belki bir VPN, bir de web sitesi. Bugün ise tablo bambaşka:

• Uzaktan çalışma ile evlerden, kafelerden, mobil cihazlardan ağa erişim
• Çok sayıda SaaS uygulaması (CRM, dosya paylaşımı, proje yönetimi, muhasebe vb.)
• Bulutta çalışan web uygulamaları, API’ler ve mikroservisler
• IoT cihazlar: kameralar, akıllı router’lar, ofis cihazları

Her yeni sistem, her yeni entegrasyon aslında yeni bir saldırı noktası anlamına geliyor. Yönetilmeyen bu genişleme, tehditleri doğal olarak artırıyor. Bu yüzden modern mimarilerde veri yerelleştirme ve loglama gibi regülasyon odaklı pratikler sadece yasal değil, aynı zamanda güvenlik açısından da kritik hale geliyor.

Saldırılar bir ekonomi haline geldi: Ransomware-as-a-Service, phishing kitleri

Bugün siber saldırılar artık bireysel heveslerle yapılan denemeler olmaktan çıktı, profesyonel bir suç ekonomisine dönüştü. Teknik bilgisi sınırlı birinin bile hazır phishing kitleri, sızma araçları ve fidye yazılımı paketleri kiralayarak saldırı başlatması mümkün.

Bunun sonucu:

• Hedefli (spear-phishing) saldırıların sayısı artıyor
• Ortalama fidye tutarları yükseliyor
• Küçük ve orta ölçekli işletmeler de ciddi hedef haline geliyor

Yani “Benim şirketim küçük, kim uğraşsın?” dönemi bitti. Oto­matikleştirilmiş saldırı araçları için 1000 küçük işletmeye toplu saldırı başlatmak, tek bir büyük kuruma saldırmaktan daha cazip hale gelebiliyor.

Otomasyon ve yapay zeka saldırganların elinde

Savunma tarafında otomasyon ve gelişmiş analiz ne kadar yaygınlaşıyorsa, saldırı tarafında da benzer bir trend var. Örneğin:

• Otomatik tarama botlarıyla zayıf parolalara sahip SSH ve RDP portlarının dakikalar içinde bulunması
• Yazılım açıklarının yayınlanmasından kısa süre sonra bunları hedefleyen mass scan dalgaları
• Gerçeğe çok yakın yazılmış, dil bilgisi düzgün phishing e-postaları

Bu da reaktif kalmayı tehlikeli hale getiriyor. Güvenlik açıklarını “sonra bakarız” diye ertelemek artık gerçek anlamda risk demek; çünkü otomasyon sayesinde bu açıklar çok daha hızlı taranıp sömürülüyor.

En sık gördüğümüz saldırı türleri ve gerçekçi senaryolar

DCHost tarafında loglara, destek taleplerine ve güvenlik denetimlerine baktığımızda bazı saldırı türlerinin çok daha öne çıktığını görüyoruz.

Kimlik avı (phishing) ve hesap ele geçirme

İlk bakışta basit görünen phishing saldırıları, sunucu tarafındaki pek çok saldırının da başlangıç noktası. Örneğin:

• Bir çalışanınız, “fatura bildirimi” görünen sahte bir e-postadaki linke tıklıyor
• Karşısına şirket e-posta girişine çok benzeyen sahte bir sayfa çıkıyor
• Parolasını giriyor ve aslında kimlik bilgilerini saldırgana teslim ediyor

Buradan sonra neler olabilir?

• Sunucu yönetim paneline (cPanel, Plesk vb.) aynı parolayla giriş denenir
• Şirket içi VPN’e erişim sağlanır
• Çalışanın e-posta hesabı üzerinden tedarikçiler ve müşterilere yeni phishing saldırıları yapılır

Yani konu sadece “bir e-posta çalındı” değil; tüm altyapınızı zayıflatan bir ilk temas söz konusu olur. Özellikle yönetici ve finans ekiplerinin hedef alındığı saldırılar, gerçek dünyada ciddi maddi kayıplara yol açabiliyor.

Fidye yazılımları (ransomware) ve yedeklerin değeri

Fidye yazılımı saldırıları, siber güvenlik tehditlerinde artış deyince akla gelen ilk başlık. Bir sunucuda veya dosya paylaşım alanında şifrelenen veriler, işin durması demek. KOBİ’ler için bu bazen “iflas” ile eş anlamlı hale bile gelebiliyor.

Bu saldırılarda dikkat çeken iki nokta var:

• Artık sadece dosyalar şifrelenmiyor, aynı zamanda hassas veriler dışarıya sızdırılıyor (double extortion)
• Yedeklere ulaşılabiliyorsa, onlar da şifreleniyor veya siliniyor

Bu yüzden yedekleme stratejisinde klasik “günde bir yedek alıyoruz” yaklaşımı yeterli olmuyor. 3-2-1 yedekleme stratejisi, offsite yedekler ve mümkünse değiştirilemez (immutable) yedekler, fidye yazılıma karşı en kritik sigortanız haline geliyor.

DDoS ve uygulama katmanı saldırıları

Özellikle e-ticaret, oyun ve SaaS tarafında hizmet veren projelerde DDoS saldırıları belirgin şekilde artmış durumda. Burada iki tür saldırı öne çıkıyor:

• Ağ katmanı DDoS: Bant genişliğinizi ve network cihazlarınızı kilitlemeye çalışır
• Uygulama katmanı (L7) DDoS: Özellikle PHP, WordPress, Laravel gibi uygulamalara yönelik, CPU ve veritabanını kilitleyen akıllı istekler

DCHost olarak bazı projelerde şunu gözlemledik: Toplam istek sayısı o kadar da yüksek değil; ama seçilen endpoint’ler o kadar maliyetli ki, birkaç yüz istek bile sunucuyu zorlayabiliyor. Bu konuyu detaylı anlattığımız DDoS saldırılarının neden yükseldiği yazısına da mutlaka göz atmanızı öneririz.

Tedarik zinciri ve üçüncü taraf servisler

Artık bir projeyi tek bir sunucuda, dış dünyadan izole şekilde çalıştırmıyoruz. Ödeme altyapıları, kargo API’leri, CRM sistemleri, SMS ve e-posta servisleri, S3 uyumlu depolama servisleri derken çok sayıda dış bağımlılık oluşuyor.

Bu durum, iki tip riski beraberinde getiriyor:

• Üçüncü taraf servislerin maruz kaldığı saldırıların sizi dolaylı olarak etkilemesi
• Tedarik zinciri üzerinden zararlı yazılımların veya arka kapıların içeri sızması

Bu yüzden modern altyapı tasarımında, sadece kendi sunucularınızın değil, entegre olduğunuz tüm servislerin de güvenlik duruşunu dikkate almanız gerekiyor.

Sunucu ve hosting tarafında riskler neden katlandı?

Tehditler artarken, birçok işletme hızla dijitalleşti ve sunucu sayıları çoğaldı. Ama güvenlik ekipleri aynı hızda büyümedi. Bu dengesizlik, özellikle VPS ve dedicated sunucularda ciddi açıklar oluşmasına yol açıyor.

Zayıf yapılandırılmış VPS/dedicated sunucular

Yeni bir VPS veya fiziksel sunucu açmak dakikalar sürüyor. Ama doğru şekilde güvenlik sertleştirmesi yapmak çoğu zaman erteleniyor. Sahada en sık gördüklerimiz:

• SSH’nin 22. porttan, parola ile ve doğrudan root erişimine açık olması
• Sunucu üzerinde gereksiz servislerin (FTP, eski panel bileşenleri) açık bırakılması
• Varsayılan kullanıcı adları ve zayıf parolalar

Oysa temel bir VPS sunucu güvenliği kontrol listesi takip edilse, bu açıkların büyük bölümü daha ilk günden kapatılabiliyor. Sunucuyu ayağa kaldırırken güvenliği “sonraya” bırakmak, maalesef en pahalı alışkanlıklardan biri.

Yönetim panelleri, zayıf parolalar ve 2FA eksikliği

cPanel, Plesk, phpMyAdmin, WordPress admin, Laravel Horizon gibi yönetim arayüzleri, hem hayatı kolaylaştırıyor hem de saldırganlar için cazip hedefler sunuyor. En sık gördüklerimiz:

• Panel adreslerinin tahmin edilebilir ve herkese açık olması
• Admin kullanıcılarında tekrar eden veya tahmin edilebilir parolalar
• İki faktörlü kimlik doğrulamanın (2FA) devreye alınmamış olması

Bu kombinasyon, brute-force (kaba kuvvet) saldırıları için ideal bir ortam sunuyor. Sunucunun kendisine dokunmadan, sadece panel üzerinden sunucudaki tüm sitelere erişim sağlanabiliyor.

Güncellenmeyen yazılımlar, eski PHP sürümleri, zayıf konfigürasyonlar

Birçok projede, “Çalışıyorsa dokunma” yaklaşımı yüzünden yıllarca güncellenmemiş CMS’ler, eklentiler ve PHP sürümleriyle karşılaşıyoruz. Oysa her yayınlanan güvenlik güncellemesi, saldırganlara bir nevi “hedef listesi” veriyor.

Sunucu tarafında:

• Eski PHP 5.x veya güncellenmemiş 7.x sürümleri
• Güvenlik başlıkları (HSTS, CSP, X-Frame-Options vb.) eksikliği
• Zayıf TLS konfigürasyonları ve eski protokoller

Bu başlıkların her birini detaylı anlattığımız HTTP güvenlik başlıkları rehberi ve TLS 1.3 ve modern şifreler rehberi gibi yazıları pratik bir kontrol listesi olarak kullanabilirsiniz.

Artan tehditlere karşı uygulanabilir savunma stratejileri

Tehditlerin çeşitliliği göz korkutucu olabilir; ama iyi haber şu: Temel birkaç prensibi sistematik şekilde uygularsanız, riskin çok büyük bir bölümünü azaltabilirsiniz.

Güvenlik hijyeni: Parola, 2FA, yama yönetimi, en az ayrıcalık

Temelden başlayalım. Aşağıdaki dört adım, pek çok saldırının daha başlamadan bitmesini sağlar:

• Parola politikası: Her kritik hesap için uzun (en az 12-16 karakter), benzersiz ve rastgele parolalar. Parola yöneticisi kullanmak neredeyse şart.
• İki Faktörlü Kimlik Doğrulama (2FA): Özellikle panel, e-posta, VPN, SSH jump host gibi kritik erişim noktalarında zorunlu hale getirilmeli.
• Yama yönetimi: Sunucu işletim sistemi, panel, CMS ve eklentilerin düzenli olarak güncellenmesi. Otomatik güncellemeleri dikkatli kurmak, kritik yamaları hızlı geçirmek önemli.
• En az ayrıcalık: Her kullanıcıya sadece ihtiyacı olan yetkileri verin. “Hepsi admin olsun, uğraşmayalım” yaklaşımı saldırganlar için hediye niteliğinde.

Ağ ve sunucu güvenliği: Güvenlik duvarı, WAF ve sertleştirme

Sunucu tarafında iyi bir başlangıç için aşağıdaki adımları öneriyoruz:

• Güvenlik duvarı (firewall): Gerek VPS üzerinde (örn. nftables, UFW), gerekse harici bir firewall ile sadece gerçekten gerekli portları açın. Bu konuda nftables ile VPS güvenlik duvarı rehberimizi inceleyebilirsiniz.
• Sunucu sertleştirme: SSH için anahtar tabanlı giriş, root login kapatma, fail2ban/Rspamd gibi araçlarla brute-force ve spam denemelerini sınırlama.
• WAF (Web Application Firewall): Özellikle WordPress, Laravel gibi yaygın çerçevelerde, bilinen zafiyetleri filtreleyebilen bir WAF katmanı ciddi koruma sağlar.

Bu adımların birçoğunu adım adım gösterdiğimiz VPS sunucu güvenliği: pratik ve ölçeklenebilir yaklaşımlar yazısı, teknik ekipler için güzel bir kontrol listesi işlevi görebilir.

DDoS’a hazırlık: Kapasite, oran sınırlama ve mimari

DDoS saldırılarını tamamen engellemek çoğu durumda mümkün değil; ama etkisini yönetilebilir seviyeye indirmek mümkün. Önerdiğimiz yaklaşım:

• Kapasite planlama: Trafik patlamalarını kaldırabilecek, yatay ölçeklenmeye açık VPS veya dedicated mimariler kurun.
• Rate limiting: Nginx/Apache tarafında IP başına istek sınırı, belirli endpoint’ler için ek koruma.
• Ön katman: CDN/WAF çözümü ile doğrudan origin’e (kaynak sunucuya) gelen trafiği azaltmak.

Bu başlıkları daha teknik detaylarıyla ele aldığımız DDoS nedir ve web sitenizi nasıl korursunuz yazısına da mutlaka göz atmanızı öneririz.

Yedekleme, felaket kurtarma ve “fidye yazılımı sigortası” olarak 3-2-1 stratejisi

Her şeye rağmen bir gün bir şeylerin ters gitme ihtimalini kabul etmek zorundayız. Bu noktada en önemli güvenlik aracı aslında sağlam bir yedekleme ve felaket kurtarma planı.

Pratik öneriler:

• 3-2-1 stratejisi: 3 kopya, 2 farklı ortam, 1 kopya mutlaka offsite.
• Düzenli geri dönüş testleri: Yedek alıyor olmak yetmez; belirli aralıklarla test geri yükleme yapmadan bu yedekler pek bir şey ifade etmez.
• Versiyonlama: Fidye yazılımı durumunda, saldırı öncesi zamana dönmek için versiyonlanmış depolama kullanmak.

DCHost tarafında, özellikle kritik üretim sistemleri için müşterilerimize, kendi otomatik yedeklerine ek olarak RTO/RPO odaklı felaket kurtarma planı yazmalarını ve bunun parçası olarak 3-2-1 stratejisini uygulamalarını öneriyoruz.

İzleme, loglama ve erken uyarı sistemleri

Bir saldırıyı tamamen engelleyemeseniz bile, erken fark etmek zararı dramatik şekilde azaltır. Bunun için:

• Sunucu CPU, RAM, disk IO, network trafiği için temel izleme ve alarmlar
• SSH, panel giriş denemeleri, web hata logları gibi kritik logların merkezi toplanması
• Şüpheli etkinlikler için uyarı mekanizmaları (örneğin kısa sürede çok sayıda 401 hatası)

Bu konuyu derinlemesine ele aldığımız VPS izleme ve alarm kurulumu rehberini, özellikle büyüyen projeler için bir başlangıç noktası olarak düşünebilirsiniz.

KOBİ’ler ve kurumsal ekipler için pratik yol haritası

“Hepsini yapalım” dediğimizde işin içinden çıkmak zorlaşabiliyor. Bu yüzden DCHost tarafında müşterilerimize genelde 90 günlük bir eylem planı öneriyoruz.

İlk 30 gün: Envanter çıkarma ve acil delikleri kapatma

Başlangıç aşamasında hedef, mükemmel olmak değil; en kritik delikleri hızlıca kapatmak:

• Tüm alan adlarınızı, sunucularınızı, panellerinizi ve üçüncü taraf servislerinizi listeleyin
• Hangi servis nerede çalışıyor, kim erişebiliyor, hangi parolalar tekrar ediyor, görünür hale getirin
• Admin hesaplarında 2FA’yı devreye alın
• SSH’de parola ile root girişini kapatın, anahtar tabanlı girişe geçin
• İşletim sistemi ve panel güncellemelerini uygulayın

Sonraki 30 gün: Politikalar, yedekleme ve izleme

İkinci aşamada hedef, süreçleri kalıcı hale getirmek:

• Parola ve erişim politikalarını şirket içinde yazılı hale getirin
• 3-2-1 prensibine uygun bir yedekleme planı kurun ve ilk geri dönüş testini yapın
• Temel sunucu izleme ve uptime takibini devreye alın
• Kritik logları toplayan basit bir merkezi loglama çözümü planlayın

Son 30 gün: Mimarinin güçlendirilmesi ve periyodik denetimler

Üçüncü aşamada artık altyapı seviyesinde güçlendirmelere odaklanabilirsiniz:

• Uygulama katmanı için WAF çözümü devreye almak
• WordPress, Laravel gibi uygulamalar için özel sertleştirme kontrolleri uygulamak (örneğin WordPress güvenlik sertleştirme kontrol listesi gibi)
• Dönemsel (örneğin 6 ayda bir) güvenlik gözden geçirme toplantılarını takvime eklemek

DCHost üzerinde güvenlik odaklı mimari nasıl kurulur?

Tehditler artarken, altyapıyı da bu yeni gerçekliğe uygun tasarlamak gerekiyor. DCHost tarafında müşterilerle çalışırken sıklıkla önerdiğimiz bazı mimari yaklaşımlar şöyle:

• Katmanlı mimari: Uygulama (web), veritabanı ve cache katmanlarını mümkünse ayrı VPS’lerde veya dedicated sunucularda konumlandırmak. Böylece bir katmandaki ihlal, tüm sistemi ele geçirmek anlamına gelmez.
• Ayrı yönetim ağı: cPanel/Plesk, SSH ve diğer yönetim arayüzlerini doğrudan internete değil, VPN veya IP kısıtlaması olan bir yönetim ağına kapatmak.
• Merkezi yedekleme: Sunucularınızın dışında, farklı bir depolama üzerinde merkezi yedekleme kurmak. Örneğin S3 uyumlu bir depolama alanında 3-2-1 stratejisine uygun yedek tutmak.
• İzleme ve loglama: Birden fazla VPS veya dedicated sunucuyu tek panelden izleyebildiğiniz, logları tek yerde toplayabildiğiniz çözümler kurmak.

İhtiyacınıza göre paylaşımlı hosting, VPS, dedicated sunucu veya colocation tercih ediyor olun, temel prensip aynı: Güvenliği en başta mimariye gömmek, sonradan eklenecek bir katman gibi düşünmemek.

Sonuç: Artan siber tehditlere karşı panik değil, planlı aksiyon

Siber güvenlik tehditlerinde artış, istatistiksel olarak da pratikte de gerçek; ama bu, çaresiz olduğumuz anlamına gelmiyor. Tehditlerin çoğu, temel güvenlik hijyeni, doğru mimari tasarım ve düzenli bakım süreçleri ile etkisi ciddi ölçüde azaltılabilen riskler.

Bu yazıda, DCHost tarafında sahada gördüğümüz yaygın saldırı türlerini, sunucu ve hosting ortamlarında sık karşılaştığımız zafiyetleri ve bunlara karşı uygulanabilir savunma stratejilerini mümkün olduğunca somut örneklerle toparlamaya çalıştık. Buradan sonra atacağınız her küçük adım –bir panelde 2FA açmak, bir sunucuda SSH’yi sertleştirmek, bir yedek geri dönüş testini başarıyla tamamlamak– uzun vadede ciddi fark yaratacak.

Eğer “Nereden başlamalıyım?” sorusunu soruyorsanız, önce kritik sistemlerinizin envanterini çıkarın, ardından bu yazıdaki kontrol listelerini tek tek uygulamaya koyun. Detaya inmek istediğiniz konularda blogumuzdaki diğer teknik rehberlere ve özellikle siber güvenlik tehditlerindeki artışın nedenlerini derinlemesine anlattığımız yazımıza da göz atabilirsiniz. Altyapı tasarımı, VPS/dedicated seçimleri veya güvenlik mimarinizle ilgili daha spesifik sorularınız olduğunda ise, DCHost ekibi olarak her zaman yanınızdayız.