WordPress Kurumsal Site Güvenliği: Gerçek Bir Altyapı Vakasında Uyguladığım Güvenlik Katmanları

WordPress kurumsal site güvenliği, yalnızca bir güvenlik eklentisi kurmaktan ibaret değildir. Yönettiğim kurumsal WordPress altyapısında güvenliği; sunucu, WordPress, kullanıcı erişimi, güncelleme, izleme ve yedekleme katmanlarını birlikte değerlendirerek yönetiyorum.

Bu yazıda kullandığım araçları “her WordPress sitesinde zorunlu güvenlik reçetesi” olarak değil, gerçek bir kurumsal sistemde uyguladığım güvenlik mimarisinin parçaları olarak anlatıyorum.

1. Lisanslı ve Güncel Yazılım Kullanımı

Temel prensiplerimden biri, kaynağı ve bütünlüğü doğrulanamayan nulled/korsan tema ve eklentileri üretim sistemlerinde kullanmamak.

Nulled yazılımın değiştirilmiş kod, arka kapı veya başka zararlı bileşenler içerip içermediğini güvenilir biçimde bilmek mümkün olmayabilir. Ayrıca resmi güncelleme ve destek mekanizmalarının dışında kalmak ayrı bir risk oluşturur.

Bu projede lisanslı Avada kullanıyoruz. Ancak bir temanın lisanslı olması tek başına güvenlik garantisi değildir. Tema, WordPress çekirdeği ve eklentilerin güncel tutulması ve güvenlik duyurularının takip edilmesi gerekir.

2. Sunucu Katmanındaki Güvenlik

WordPress güvenliğini yalnızca uygulama katmanında ele almıyorum. Sunucunun yapılandırması, erişim kontrolleri ve güvenlik kayıtları da sistemin genel güvenlik seviyesini doğrudan etkiler.

Bu sistemde Linux tabanlı sunucu ve Plesk kullanıyoruz.

Plesk Üzerinde Kullandığım Güvenlik Katmanları

• Fail2Ban: Belirlenen kurallara göre tekrarlanan başarısız girişler ve bazı şüpheli davranışlar için IP tabanlı engelleme uygulanmasına yardımcı oluyor.
• ModSecurity: Yapılandırılmış WAF kurallarıyla belirli zararlı HTTP isteklerini uygulamaya ulaşmadan önce tespit etmeye veya engellemeye yardımcı oluyor.
• Erişim kontrolleri: Yönetim servislerine erişimi ihtiyaç ve altyapı koşullarına göre sınırlandırıyorum.
• Log takibi: Web sunucusu, PHP ve güvenlik kayıtlarını olay incelemelerinde birlikte değerlendiriyorum.

Bu araçların hiçbiri tek başına bütün saldırıları engellemez. Güvenlik seviyeleri kullanılan kurallara, yapılandırmaya ve sistem mimarisine göre değişir.

3. WordPress Katmanında Wordfence Kullanımı

WordPress tarafında Wordfence kullanıyorum. Aynı işlevleri tekrar eden çok sayıda güvenlik eklentisini üst üste kurmak yerine mevcut güvenlik katmanlarını kontrollü biçimde yönetmeyi tercih ediyorum.

Kullandığım başlıca Wordfence özellikleri:

• Web Application Firewall: WordPress’e yönelik belirli zararlı isteklerin tespit ve engellenmesine yardımcı oluyor.
• Dosya taraması: WordPress çekirdeği, eklenti ve tema dosyalarındaki şüpheli değişikliklerin tespitinde kullanıyorum.
• Giriş güvenliği: Brute-force koruması ve giriş politikalarını yönetmek için kullanıyorum.
• Trafik ve güvenlik kayıtları: Şüpheli istekleri araştırırken ek veri kaynağı olarak değerlendiriyorum.

Wordfence’in bulunması sunucu güvenliğinin, güncelleme yönetiminin veya yedeklemenin yerini tutmaz. Ben bunu çok katmanlı yapının WordPress tarafındaki bileşenlerinden biri olarak kullanıyorum.

4. Yedekleme ve İzleme

Hiçbir güvenlik sistemi yüzde 100 koruma garantisi vermez. Bu nedenle olay sonrası kurtarma planını güvenliğin bir parçası olarak görüyorum.

• Yedekleme: Dosya ve veritabanı yedeklerini düzenli tutuyor ve mümkün olduğunda üretim sunucusundan bağımsız bir kopya bulunduruyorum.
• Geri yükleme: Yedeğin bulunması kadar gerektiğinde geri yüklenebilir olması da önemli.
• Oturum ve erişim takibi: Yönetim erişimlerini ve gereksiz açık oturumları kontrol ediyorum.
• Log incelemesi: Sunucu ve WordPress kayıtlarını özellikle güvenlik olaylarında birlikte değerlendiriyorum.

5. Sunucu ve WordPress İçin Uyguladığım Temel Önlemler

1. Yönetim erişimlerini sınırlandırmak: SSH, Plesk ve WordPress yönetim erişimlerini ihtiyaç doğrultusunda sınırlandırıyorum. SSH için güçlü kimlik doğrulama ve mümkün olduğunda anahtar tabanlı erişim, yalnızca port değiştirmekten daha önemli.
2. Dizin listelemeyi kapatmak: Sunucuda ihtiyaç olmayan dizin listeleme özelliğini devre dışı tutuyorum.
3. En az yetki prensibi: Veritabanı ve sistem kullanıcılarına yalnızca ihtiyaç duydukları yetkileri vermeye çalışıyorum.
4. XML-RPC kullanımını değerlendirmek: XML-RPC kullanılmıyorsa erişimini sınırlandırmak düşünülebilir. Ancak bazı servis ve entegrasyonlar XML-RPC’ye ihtiyaç duyabileceğinden bunu her WordPress sitesi için zorunlu bir ayar olarak görmüyorum.
5. Güçlü kimlik doğrulama: Güçlü ve benzersiz parolaların yanında mümkün olan hesaplarda iki faktörlü kimlik doğrulamayı tercih ediyorum.

Önemli not: WordPress veritabanındaki varsayılan wp_ tablo ön ekini değiştirmek, SQL injection açığını ortadan kaldırmaz. SQL injection’a karşı asıl savunma; güvenli kodlama, güncel yazılım, doğru yetkilendirme ve uygun güvenlik katmanlarıdır.

6. Gereksiz Bileşenleri Azaltmak

Kullanılmayan tema ve eklentileri üretim sisteminde tutmamaya çalışıyorum. Daha az bileşen; güncelleme, izleme ve saldırı yüzeyi yönetimini kolaylaştırabilir.

Ancak yalnızca eklenti sayısına bakarak bir WordPress sitesinin güvenli veya güvensiz olduğunu söylemek doğru değildir. Önemli olan kullanılan bileşenlerin kaynağı, güncelliği, gerekliliği ve yapılandırmasıdır.

7. HTTPS ve Güvenlik Başlıkları

HTTPS kullanımının yanında sistemin ihtiyacına göre güvenlik başlıklarını da değerlendiriyorum. Örneğin HSTS, X-Content-Type-Options ve içerik/gömme politikaları uygun yapılandırıldığında belirli tarayıcı tabanlı risklerin azaltılmasına yardımcı olabilir.

Bu başlıklar da kopyala-yapıştır yöntemiyle uygulanmamalıdır. Özellikle HSTS gibi ayarlar yanlış yapılandırıldığında erişim sorunlarına yol açabileceğinden önce mevcut altyapıyla uyumluluğu kontrol edilmelidir.

8. Bu Vakadan Çıkardığım Güvenlik Yaklaşımı

Bu sistemde kullandığım yaklaşımı üç başlıkta özetleyebilirim:

1. Saldırı yüzeyini azalt: Gereksiz yazılım, servis ve yetkileri kaldır.
2. Katmanlı savunma kullan: Sunucu, WordPress, kullanıcı erişimi ve izleme katmanlarını birlikte yönet.
3. Kurtarma planını hazır tut: Güncel ve geri yüklenebilir yedek olmadan güvenlik planını tamamlanmış sayma.

Güvenlik statik bir ayar değil, düzenli olarak gözden geçirilmesi gereken bir süreçtir. Yeni bir eklenti, sunucu değişikliği veya güvenlik güncellemesi mevcut risk profilini değiştirebilir.

Sıkça Sorulan Sorular

Sonuç

Bu vakada güvenliği tek bir eklentiye veya sunucu ayarına bağlamadım. WordPress, sunucu, erişim kontrolü, izleme ve yedekleme katmanlarını birlikte yönettim.

Benim için kurumsal WordPress güvenliğinin temel prensibi şu:

Tek bir “güvenlik ürünü” aramak yerine, birbirini tamamlayan ve düzenli olarak denetlenen savunma katmanları oluşturmak.

Tunçer ŞEN