WordPress’te Kurumsal Site Güvenliği Savunması: Bir Dil Okulu Zincirinin Web Sitesini Nasıl Zırhladık?

Günümüzde WordPress kurumsal site güvenliği sağlamak, sadece bir eklenti kurmaktan çok daha fazlasını gerektiriyor. Bu yazıda, 15 yıllık IT tecrübemle bir dil okulu zincirinin web sitesini sunucu seviyesinden itibaren nasıl koruduğumuzu adım adım anlatacağım.

1. WordPress Kurumsal Site Güvenliğinde Temel Felsefe: “Nulled” Yazılıma Sıfır Tolerans

Güvenlik, kodun temizliğiyle başlar. Birçok webmasterın yaptığı en büyük hata, “deneme” amaçlı da olsa illegal (lisanssız/nulled) eklenti veya tema kullanmaktır.

  • Neden Önemli? Nulled yazılımlar, içine gizlenmiş “backdoor” (arka kapı) ile gelir. Siz kapıyı kilitlediğinizi sanırken, hackerlar verdiğiniz anahtarla içeri girer.
  • Bizim Tercihimiz: Her zaman lisanslı, güncel ve globalde kendini kanıtlamış Avada temasını kullandık. Gereksiz kod yığınından kaçınarak sitenin hem hızlı hem de güvenli kalmasını sağladık.

2. Sunucu Seviyesinde Güvenlik (Kaleyi İnşa Etmek)

Bir web sitesi, üzerinde çalıştığı sunucu kadar güvenlidir. Biz bu süreçte paylaşımlı (shared) hosting yerine, kontrolü tamamen bizde olan Linux tabanlı özel bir sunucu tercih ettik.

Plesk Panel ile Güvenlik Yapılandırması

Plesk Panel sadece bir yönetim arayüzü değil, doğru kullanıldığında bir kalkan setidir. Uyguladığımız kritik ayarlar:

  • Fail2Ban (IP Address Banning): Şüpheli giriş denemelerini (Brute Force) anında tespit edip, saldırganın IP adresini sunucu seviyesinde yasakladık.
  • ModSecurity (WAF): Web Uygulama Güvenlik Duvarı ile SQL Injection ve Cross-Site Scripting (XSS) gibi karmaşık saldırıları daha siteye ulaşmadan engelledik.
  • Özel IP Atamaları: Web sitemiz için ayrı, mail trafiğimiz için ayrı IP adresleri kullanarak “IP itibarımızı” (IP Reputation) koruma altına aldık. Bu, maillerin spam’e düşmemesi için de kritik bir hamleydi.

💡
WordPress Kurumsal Site Güvenliği İçin Neden Sunucu Katmanı Şart?

3. WordPress Kurumsal Site Güvenliği Seviyesinde Akıllı Savunma: Neden Sadece Wordfence?

Birçok webmaster, güvenliği sağlamak için onlarca eklentiyi üst üste kurarak siteyi hantallaştırır. 15 yıllık tecrübemle şunu söyleyebilirim: Doğru yapılandırılmış tek bir dev, onlarca küçük eklentiden daha etkilidir. Biz bu projede, WordPress’in iç güvenliğini tamamen Wordfence’e emanet ettik. Peki neden ikinci bir eklentiye ihtiyaç duymadık?

WordPress kurumsal site güvenliği vaka analizi ve Plesk ayarları

Engellenen Saldırı Toplamı: Wordfence Ağı

  • Uç Nokta Güvenlik Duvarı (Endpoint WAF): Wordfence, bulut tabanlı değil, doğrudan WordPress çekirdeğiyle bütünleşik çalışır. Bu sayede, şifrelenmiş (encrypted) saldırıları bile sunucu seviyesinde yakalamadan önce WordPress içinde teşhis edebiliriz.
  • Dosya Bütünlüğü ve Zararlı Kod Taraması: Wordfence’in en güçlü yanı, WordPress çekirdek dosyalarını, temaları ve eklentileri orijinal halleriyle anlık olarak karşılaştırmasıdır. En ufak bir kod enjeksiyonunda veya yetkisiz dosya değişikliğinde sistem anında alarm vererek müdahale etmemizi sağlıyor.
  • Giriş Güvenliği (Login Security): Sucuri gibi ek araçlara ihtiyaç duymadan; brute force saldırılarını engellemek, XML-RPC açıklarını kapatmak ve yönetici girişlerini izlemek için Wordfence’in gelişmiş login korumasını kullandık.
  • Gerçek Zamanlı Trafik İzleme (Live Traffic): Sitemize gelen bot trafiğini ve şüpheli kullanıcı davranışlarını anlık olarak izleyerek, sunucu tarafındaki Fail2Ban kurallarımızı bu verilere göre optimize ettik.

Kritik Not: Wordfence’in üzerine ek bir güvenlik eklentisi kurmamamızın bir diğer sebebi de, sunucu katmanında kullandığımız Plesk ModSecurity ve Fail2Ban ikilisidir. WordPress katmanına ulaşmadan önce saldırıların %90’ını zaten sunucu seviyesinde durdurduğumuz için, WordPress’i yormayacak kadar hafif ama derinlemesine bir savunma hattı oluşturmuş olduk.

4. Unutulan Kahraman: Yedekleme ve İzleme

Güvenlik %100 garanti edilemez; bu yüzden en kötü senaryoya her zaman hazırlıklıyız.

  • Yedekleme Stratejisi: 3-2-1 yedekleme kuralına göre hem sunucu içi hem de off-site (sunucu dışı) yedekleme ile veri bütünlüğünü garanti altına aldık.
  • Session Management: Aktif Plesk ve FTP oturumlarını sürekli izleyerek, boşta kalan oturumların (Session Idle Time) otomatik sonlandırılmasını sağladık.
  • Plesk Tarafındaki “Gizli Kahramanlar”: ModSecurity’nin sadece açık olması yetmez. OWASP kurallarını aktif ederek SQL Injection denemelerini uygulama katmanına ulaşmadan kestik.
  • IP Kısıtlaması (Management): Sadece şubelerin IP adreslerine veya belirli VPN çıkışlarına admin paneli izni verdi.
    WordPress kurumsal site güvenliği vaka analizi ve Plesk ayarları

    WordPress kurumsal site güvenliği vaka analizi ve Plesk ayarları

Plesk Güvenlik

Plesk Panel Üzerinde WordPress Kurumsal Site Güvenliği İçin Uyguladığımız 5 Kritik Güvenlik Adımı

  1. SSH Portunu Değiştirmek: Standart 22 portu yerine yüksek bir port numarası kullanarak kaba kuvvet saldırılarını %90 azalttık.
  2. Dizin Listelemeyi Kapatmak: Options -Indexes komutu ile sunucu dosyalarının dışarıdan taranmasını engelledik.
  3. Veritabanı Prefix Değişimi: Varsayılan wp_ yerine özel bir ön ek kullanarak SQL injection riskini minimize ettik.
  4. XML-RPC Devre Dışı Bırakmak: WordPress’in bu eski özelliğini kapatarak gereksiz bot yükünden kurtulduk.
  5. Güçlü Parola Politikası: Sadece adminler için değil, tüm sistem kullanıcıları için 16 haneli karmaşık şifreleme zorunluluğu getirdik.

 

Kurumsal Güvenlikte 3 Altın Kural: Eklentilerin Ötesi

  1. Gereksiz Kodlardan Arınma: Sitemizde sadece aktif olarak kullandığımız eklentileri barındırıyoruz. Kullanılmayan her eklenti, potansiyel bir saldırı yüzeyidir. Avada temasının sunduğu esnekliği, gereksiz “builder” eklentileriyle kirletmiyoruz.
  2. SSL ve Header Güvenliği: Sadece SSL sertifikası kurmakla yetinmeyip; HSTS, X-Frame-Options ve X-Content-Type-Options gibi güvenlik başlıklarını (Security Headers) Plesk üzerinden yapılandırarak tarayıcı seviyesinde koruma sağlıyoruz.
  3. Veritabanı İzole Etme: Varsayılan tablo ön eklerini değiştirerek ve veritabanı kullanıcısına sadece gerekli yetkileri (minimum privilege) tanımlayarak, olası bir sızıntının etkisini sınırlandırıyoruz.

Sıkça Sorulan Sorular (FAQ)

1. Ücretsiz güvenlik eklentileri yeterli mi?

Kurumsal yapılar için sadece ücretsiz eklentiler yeterli değildir. Sunucu tarafında Fail2Ban ve WAF gibi katmanların olması şarttır.

2. Avada teması güvenlik için bir risk oluşturur mu?

Hayır, lisanslı ve güncel tutulan Avada teması oldukça güvenlidir. Ancak nulled (korsan) sürümlerden kesinlikle uzak durulmalıdır.

3. WordPress güvenliğinde en büyük açık nedir?

Genellikle güncellenmeyen eklentiler ve zayıf yönetici parolalarıdır. 15 yıllık tecrübemizde saldırıların çoğunun bu iki noktadan geldiğini gözlemledik.

Bir Uzman Görüşü (Eleştirel Yaklaşım)

Peki, tüm bunlar yeterli mi? Hayır. Güvenlik statik bir durum değil, bir süreçtir. Makalemi okuyan dostlarıma bir tavsiyem var: Teknik araçlara güvenin ama onları denetlemeyi asla bırakmayın. IP kısıtlamaları (IP Access Restriction) ve yasaklı alan adları (Prohibited Domain Names) listelerinizi düzenli olarak güncelleyin.

Sonuç: American LIFE gibi büyük bir markanın dijital itibarını korumak, sunucu çekirdeğinden son kullanıcı arayüzüne kadar her noktaya hakim olmayı gerektirir. Bizim sistemimizdeki en güçlü halka, kullandığımız araçların çokluğu değil, bu araçların birbiriyle uyumlu çalışmasıdır.

Neden bu işi bir ajans yerine 15 yıllık bir IT yöneticisi yapmalı? Ben bu sistemi sadece kurmadım, 15 yıldır her gün bu sistemin nabzını tutuyorum. Ben Tunçer ŞEN, Peki siz WordPress web sitenizin güvenliğini artırmak için neler yaptığınızım merak ediyorum? Yorumlarda paylaşın!

Kategoriler:

Güvenlik,