WordPress Veritabanı Tablo Önekini Değiştirerek Güvenliği Artırma

wp_ Öneki Neden Bilinen Bir Hedef?

WordPress kurulumlarının büyük çoğunluğu, veritabanı tablolarında varsayılan wp_ önekini hiç değiştirmeden kullanır. Bu durum, otomatik SQL-injection saldırı betikleri için işleri kolaylaştırır: bu betikler genellikle hedef sitenin gerçek tablo yapısını önce keşfetmeye çalışmaz, doğrudan wp_options, wp_users gibi tablo adlarını varsayarak sorgu üretir. Öneki rastgele bir dizeyle değiştirmek, bu tür kör ve otomatik saldırıları büyük ölçüde etkisiz hale getiren basit ama etkili bir sertleştirme adımıdır.

Bu tür betikler genellikle geniş bir IP aralığını tarayıp, karşılaştıkları her WordPress sitesine aynı sorgu kalıbını deneyen kütle (mass) saldırı araçlarıdır. Hedefli, elle yürütülen bir saldırıda önek zaten kolayca tespit edilebileceği için tablo öneki değişikliği o senaryoda tek başına yeterli değildir; asıl değeri, otomatik ve rastgele taramaların büyük çoğunluğunu daha ilk adımda başarısız kılmasıdır.

RENAME TABLE, Dışa Aktar / Ara-Değiştir / İçe Aktar Yönteminden Neden Daha Güvenli?

Önek değiştirmenin yaygın bilinen bir yöntemi, veritabanını dışa aktarıp bir arama/değiştirme aracıyla wp_ dizesini yeni önekle değiştirip tekrar içe aktarmaktır. Bu yöntem çalışır ama gereksiz risk taşır: büyük veritabanlarında serileştirilmiş (serialized) veri içindeki karakter uzunluklarının bozulma ihtimali vardır, işlem daha uzun sürer ve ara adımlarda (dışa aktarma, düzenleme, içe aktarma) hata payı yüksektir. Ayrıca bu yöntem, aktarım sırasında sitenin geçici olarak devre dışı kalmasını gerektirebilir.

MySQL'in RENAME TABLE komutunu doğrudan çalıştırmak çok daha basit ve güvenlidir. İşlem atomiktir, anlık gerçekleşir ve satır verisinde herhangi bir metin değişikliği gerektirmez — yalnızca tablonun adı değişir, içindeki veri olduğu gibi kalır. Bu da veri bozulması riskini ortadan kaldırır ve işlemi saniyeler içinde tamamlanabilir hale getirir.

RENAME TABLE `wp_posts` TO `wp_7x2k9_posts`;

Bu komut her çekirdek tablo için ayrı ayrı tekrarlanır. WordPress'in öneksiz kısımlarıyla çekirdek tabloları şunlardır:

• commentmeta
• comments
• links
• options
• postmeta
• posts
• terms
• termmeta
• term_relationships
• term_taxonomy
• usermeta
• users

Toplamda 12 çekirdek tablo bulunur ve her biri için ayrı bir RENAME TABLE satırı yazılması gerekir. Bazı eklentiler kendi tablolarını da eski önekle oluşturmuş olabilir; veritabanında başka {eskiönek}* tabloları olup olmadığını kontrol etmek bu aşamada gözden kaçmaması gereken bir ayrıntıdır, çünkü bu ek tablolar listeye dahil edilmezse ilgili eklenti kendi verisini bulamaz hale gelir.

Uçtan Uca Bir Örnek

Diyelim ki eski önek wp_, yeni önek ise rastgele üretilmiş wp_7x2k9_ olsun. Süreç sırasıyla şöyle işler: önce 12 çekirdek tablo (ve varsa eklenti tabloları) için RENAME TABLE komutları tek tek çalıştırılır — örneğin wp_options tablosu wp_7x2k9_options, wp_users tablosu wp_7x2k9_users olur. Ardından aşağıdaki bölümde anlatılan iki UPDATE komutu yeni tablo adları üzerinde çalıştırılır. Son olarak wp-config.php dosyasındaki önek satırı güncellenir ve site tarayıcıda açılarak hem ön yüzün hem de yönetim panelinin (giriş ekranı dahil) beklendiği gibi çalıştığı doğrulanır.

Kolayca Atlanan İki UPDATE Komutu

Tabloları yeniden adlandırmak işin yalnızca bir kısmıdır. WordPress çekirdeği, tablo önekini iki farklı yerde ayrıca veri olarak da saklar ve bu iki nokta RENAME TABLE ile otomatik güncellenmez.

Birincisi, wp_options tablosunda option_name değeri tam olarak {eskiönek}user_roles olan satırdır. Tablo adı değişse bile bu satırın içeriği eski öneki taşımaya devam eder ve elle güncellenmesi gerekir:

UPDATE `{yenönek}options` SET option_name = '{yenönek}user_roles' WHERE option_name = '{eskiönek}user_roles';

İkincisi, bazı usermeta anahtarlarıdır; özellikle {eskiönek}capabilities gibi kullanıcı yetkilerini tutan meta_key değerleri eski öneki içerir:

UPDATE `{yenönek}usermeta` SET meta_key = REPLACE(meta_key, '{eskiönek}', '{yenönek}') WHERE meta_key LIKE '{eskiönek}%';

wp-config.php Güncellemesi ve 500 Hata Riski

SQL komutlarını çalıştırdıktan sonra son ve zorunlu adım, wp-config.php dosyasındaki $table_prefix değişkenini yeni önekle güncellemektir:

$table_prefix = 'wp_7x2k9_';

Bu iki adımdan biri — veritabanındaki değişiklik ya da wp-config.php güncellemesi — eksik kalırsa WordPress yanlış tablo adlarını aramaya başlar ve site doğrudan 500 Internal Server Error hatası verir. Bu yüzden SQL komutlarını çalıştırma ve wp-config.php'yi güncelleme işlemleri aynı bakım penceresinde, art arda ve dikkatle yapılmalıdır. İki adım arasında site canlı bırakılırsa, o kısa süre içinde gelen istekler de hata alacaktır.

Sık Yapılan Hatalar

Tablo öneği değiştirme işlemi teknik olarak basit adımlardan oluşur, ama sırayı veya bir detayı atlamak sitenin çalışmaz hale gelmesine yol açabilir. En sık karşılaşılan hatalar şunlardır:

• İşleme başlamadan önce veritabanının tam yedeğini almamak — SQL adımlarından biri yanlış giderse geri dönüş yolu kalmaz.
• Eklentilerin oluşturduğu, eski öneki taşıyan ek tabloları atlamak — bunlar yeniden adlandırma listesine dahil edilmezse ilgili eklenti verisine erişemez.
• wp-config.php'deki $table_prefix güncellemesini unutup sitenin 500 hatasıyla karşılaşmasına şaşırmak.
• Önek değişikliğinin tek başına SQL injection saldırılarını tamamen engellediğini düşünmek — bu adım yalnızca otomatik ve kör saldırıları zorlaştırır, güncelleme ve yama disiplininin yerini almaz.
• İki UPDATE komutunu atlayıp yalnızca RENAME TABLE ile yetinmek — roller ve yetkiler sessizce bozulur.

Bu adımların tamamını elle, hatasız şekilde uygulamak zaman alır ve tek bir unutulan satır siteyi çalışmaz hale getirebilir. Süreci otomatikleştirmek hem doğruluğu garanti eder hem de zaman kazandırır.

WP Tablo Öneki SQL Oluşturucu

Eski ve yeni öneki girin; 12 çekirdek tablo için RENAME TABLE komutlarını, iki kritik UPDATE komutunu ve wp-config.php satırını eksiksiz ve doğru sırada üretir.