PHP betiklerinin analiz ve değişiklikten korunması. Çerez gizli anahtarlarınızı değiştirmeyi unutmayın

PHP betiklerini korumaya yönelik tüm yazılım ürünleri iki kategoriye ayrılır: sunucuya ek modüllerin yüklenmesini gerektirenler ve web sunucularının olağan yapılandırmasıyla çalışanlar. İlki, PHP betiklerini metin biçiminden özel bir ikili koda çevirdikleri, ancak sunucuya yönetici haklarıyla erişim gerektirdiği için güvenlik açısından daha güvenilirdir. İkincisi, ücretsiz olanlar da dahil olmak üzere PHP destekli neredeyse tüm barındırmalarda çalışabilir, ancak hacklenmesi çok zor değildir. Şifreleme veya sıkıştırma kullanmayan kaynak kodu ayrı bir alt gruba ayrılabilir.

Sunucu düzeyinde korumalar:

Zend Encoder / Zend SafeGuard Suite en popüler ticari korumadır, Zend desteği için modüller genellikle tüm ücretli barındırmalara kurulur. Zend, etki alanı ve ip komut dosyası oluşturma, deneme komut dosyası zamanlaması ve güçlü gizleme sağlar. Tüm işletim sistemleri desteklenmektedir. Kamusal alanda Zend kaldırma yardımcı programları için çeşitli seçenekler vardır, bunların tümü değiştirilmiş PHP sürüm 4 ve 5'tir. Zend'in eski sürümleri sorunsuz bir şekilde kaldırılır, ikincisinde kaynak kodunun karartılmasından kaynaklanan zorluklar vardır.

Yeni, aktif olarak gelişen ticari koruma. Kendi API'leri düzeyinde korumalı komut dosyaları ile etkileşim sağlar; Windows ve Linux işletim sistemleri desteklenir. Düşük yaygınlığı nedeniyle, sıradan sanal barındırmaya kurulmaz, ancak kullanıcılar tarafından özel sunuculara kurulabilir. Genel kod çözücüler yoktur.

Ticari koruma pratikte bulunmaz, sanal barındırmaya kurulmaz. Harici zaman sunucularındaki tarihi kontrol etmek, korumalı komut dosyalarını sunuculara, ip adresini, ağ kartının MAC adresini bağlamak için komut dosyaları için bir deneme süresi belirlemenizi sağlar ve bu veriler şifre çözme için kullanılır. Tüm işletim sistemleri desteklenmektedir. Genel kod çözücüler yoktur.

phpSHIELD. PHP prototipi için SourceGuardian. İki geliştiricinin birleşmesinden sonra bağımsız bir ürün olarak gelişmeyi bıraktı. Ana işlevsellik aynıdır, genel kod çözücü yoktur.

ionCube PHP Kodlayıcı. Komut dosyalarını korumak için ikinci en popüler ticari ürün. Zend için genel kod çözücülerin ortaya çıkmasından sonra, giderek daha fazla kullanılır ve paylaşılan barındırmada kurulur. Yalnızca komut dosyalarını değil, şablonları, xml belgelerini, görüntüleri, ikili dosyaları da şifrelemenize olanak tanır. Korumalı dosyaları sunuculara bağlar, güçlü bir obfuscator vardır, tüm işletim sistemleri desteklenir. Genel kod çözücü yoktur, ancak bazı durumlarda deZender tarafından kaldırılabilir.

PHTML Kodlayıcı. Bu tür ürünler için olağan işlevselliği sağlayan nadir bir ticari güvenlik sistemi, tüm işletim sistemlerinde çalışır. Ayrı bir ücret karşılığında orijinal güvenlik kodlarını satın alabilir ve ihtiyaçlarınıza göre değiştirebilirsiniz. Genel kod çözücüler yoktur.

DWebEncoder. CD'lerde komut dosyasıyla hazırlanmış sunumlar ve kataloglar oluşturmak için tasarlanmış Windows için egzotik koruma. Kurulu formda, kodlanmış php komut dosyalarının yürütüldüğü bağımsız bir web sunucusu gibi bir şeydir. Genel kod çözücüler yoktur.

PHP Kompakt. Savunma pratikten çok teoriktir. Yerli forumlardan birinde geliştirildi, ancak yazarın yayınlarının ötesine geçmemiş gibi görünüyor. Korumalı komut dosyalarının yanı sıra kod çözücü yoktur.

Eski php hızlandırıcıları Turck MMCache ve eAccelerator'a açık kaynaklı bir eklenti. Yürütme hızlarını artırmak için komut dosyalarını bayt koduna dönüştürür. Windows ve Linux için modüllerin sürümleri vardır. Halka açık kod çözücüler yoktur, ancak belki de projenin açık kaynak kodu bir şekilde çalışmada yardımcı olacaktır.

Kaynak düzeyinde korumalar:

PHP LockIt! ... Popüler ticari koruma, özellikle yabancı geliştiricilerin komut dosyalarında çok yaygındır. Komut dosyalarının çalışması için bir deneme süresi belirlemenizi sağlar, etki alanlarına ve ip adreslerine bağlanır, standart php araçlarını (gzinflate) kullanarak komut dosyalarını sıkıştırır. Tek zor kısım iyi bir obfuscator. Farklı koruma versiyonları, yalnızca paket açma modülünün modifikasyonunda farklılık gösterir. Hem manuel hem de otomatik modlarda kolayca çıkarılabilir. Bir obfuscator olmadan, bir obfuscator ile tam olarak kaynak koduna kaldırılır, ek işlem gerektirir.

CNC kripto. Kamusal alanda bir demo sürümü bile yok, analiz korumalı komut dosyaları kullanılarak yapıldı. Menteşeli modülü paketinden çıkarmak zor değildir, koruma yalnızca kaynak kodunun iyi bir şekilde gizlenmesine dayanır.

PHPŞifre. Koruma çevrimiçi bir hizmettir. Komut dosyalarınızı içeren bir arşiv siteye yüklenir ve zaten korunan arşiv geri indirilir. Ücretli bir lisans, verilerinizle korumalı komut dosyaları imzalamanıza ve bunları ticari amaçlarla kullanmanıza olanak tanır. Ücretsiz lisans yalnızca kişisel kullanıma izin verir. Korumanın kendisi, korumalı betiklere bağlanan Zend tarafından korunan bir php modülüdür.DeZend'den sonra koruma modülü ve ondan gerekli tüm sabitlerin alınması tamamen kaynak koduna kaldırılır. Obfuscator işlevi yoktur.

PHP için ByteRun Koruyucu. Ticari bir ürün, lisans türüne bağlı olarak, komut dosyalarını hem sunucu düzeyinde hem de kaynak kodu düzeyinde korumanıza olanak tanır. Standart özelliklere sahip sunucu koruması, özel bir şey değil. Komut dosyası düzeyinde koruma, otomatik ve manuel olarak çok kolay bir şekilde kaldırılabilir. Sunucu sürümü için genel kod çözücü yoktur.

Koruma, yerli geliştiriciler arasında çok popüler. İçerme yoluyla korumalı komut dosyalarına bağlanan, boş kodla yoğun bir şekilde dolu bir koruma modülüdür. Kod çözme algoritması çok basittir, manuel ve otomatik kaldırmada herhangi bir zorluğa neden olmaz. Her durumda, kaynak koduna tamamen kaldırılır, obfuscator işlevi yoktur. Özel kod çözme durumları için küçük özellikler vardır, ancak bunlar burada açıklanmayacaktır.

Kod Kilidi. Bir başka popüler savunma, okuma yazma bilmeyen programlamanın harika bir örneği. Javascript kullanarak hem scriptlerin kendilerini hem de çalışmalarının sonucunu tarayıcıda kodlamanıza izin veren bir php uygulamasıdır. Komut dosyaları bir parola ile korunabilir, ancak vasat uygulama nedeniyle, menteşeli korumayı kaldırmadan bile parolayı bulmak kolaydır. Koruma modülü, korumalı komut dosyalarına bağlanan boş kodla dolu bir php komut dosyasıdır. Koruma algoritması çok basittir, tamamen kaynak koduna kaldırılır. Gizleme işlevi yoktur.

TrueBug PHP Encoder, daha yakın zamanda TrueBug PHP Obfuscator & Encoder. Keşfetmek için çok ilginç bir yürüyüş. 1.0.2 sürümünden önce, gzip sıkıştırması için standart php araçları kullanılıyordu, 1.0.3 sürümünden bu yana yazarlar kendi sıkıştırma algoritmalarını geliştirdiler. Yeni ürün TrueBug PHP Obfuscator & Encoder, kaynak kodunun şaşırtma ve optimizasyonu işlevini ekler. Korumanın tek zayıf noktası, değişmez komut dosyası kod çözme algoritmasıdır, ancak algoritmanın kendisi, korumanın her sürümü için değişir. Ayrıştırmadan sonra, obfuscator kullanılmamış olması koşuluyla, koruma tam olarak kaynak koduna kolayca kaldırılır.

Zorex PHP CryptZ. Koruma, CodeLock gibi bir php uygulamasıdır, çalışması için bir MySQL veritabanı gerektirir. Koruma modülü, birkaç katmanda şifrelenmiş bir eklenti php betiğidir. Analizden sonra algoritma çok kolay bir şekilde tam olarak kaynak koduna kaldırılır. Obfuscator işlevi yoktur.

Ücretsiz PHP Kodlayıcı. PHP komut dosyalarını kodlamak için ücretsiz çevrimiçi hizmet. Koruma modülü, siteden indirilmesi gereken Zend kapsamındaki bir eklenti php-script'tir.Zend kaldırıldıktan ve algoritma ayrıştırıldıktan sonra koruma tamamen kaynak koduna kolayca kaldırılabilir. Koruma algoritması değişmez, obfuscator işlevi yoktur.

Php betiği, ilkel kodlama, standart base64. Daha fazla ilgiyi hak etmiyor ve pratik bir ilgiye sahip değil.

Standart wp-signup.php yerine multisite için kendi kayıt sayfamızı oluşturuyoruz.

Tipik bir WordPress kurulumunda, kayıt (oturum açma, parola sıfırlama) sayfası wp-login.php dosyasını görüntüler.

  • /wp-login.php - yetkilendirme
  • /wp-login.php?action=register - kayıt
  • /wp-login.php?action=lostpassword - şifreyi sıfırla

wp-login.php'de multisite için ayrı koşullar vardır. Bu nedenle, bir çoklu sitede /wp-login.php?action=register bağlantısını tıkladığınızda, WordPress /wp-signup.php sayfasına yönlendirilecektir. Birçok temada sayfa çok çekici görünmüyor, bu yüzden kendimizinkini yapacağız.

Ağın ana sitesi

WordPress varsayılan olarak ağın ana etki alanında (site) bir kayıt sayfası (wp-signup.php) açar. Ancak, farklı temalara sahip olsalar bile ağdaki her site için ayrı bir kayıt sayfası oluşturabilirsiniz. Ağdaki tüm sitelerin kendi kayıt sayfasına sahip olduğu, ancak aynı temanın kullanıldığı ve sitelerin yalnızca dilde farklılık gösterdiği durumu ele alacağız. Farklı temalar kullanıyorsanız, daha fazla kod yazmanız gerekecektir.

fonksiyonlar.php?

Numara. Bu dosyanın adı her WordPress makalesinde geçiyor gibi görünüyor. Bizim durumumuzda, kayıt işlevselliği birkaç site için tasarlandığından, herhangi bir siteyi açtığınızda yüklenen MU eklentilerine taşımak mantıklıdır.

lirik arasöz

MU eklentilerinin normal eklentilerden daha erken ve WordPress çekirdeği tamamen yüklenmeden önce yüklendiğini belirtmekte fayda var, bu nedenle bazı işlevlerin çağrılması PHP'de ölümcül hatalara neden olabilir. Bu "erken" yüklemenin de avantajları vardır. Örneğin, herhangi bir temanın içinde, function.php dosyası temadan yüklenmeden önce tetiklenen bazı eylemlere tutunamazsınız. Buna bir örnek, Jetpack'teki modüllerin etkinliğini izlemenin mümkün olduğu jetpack_module_loaded_ Related-posts (ilgili gönderiler - modülün adı) biçimindeki Jetpack eklentisindeki eylemlerdir. Tema dosyasından bu eyleme "yapışmak" imkansızdır, çünkü eylem tema yüklenmeden önce zaten tetiklenmiştir - eklentiler temalardan önce yüklenir. Codex'teki Eylem Referans sayfasındaki WordPress yükleme sırasının genel bir resmine göz atabilirsiniz.

Dosya sırası

MU eklentileri, herhangi bir sayıda dosya ve size mantıklı görünen herhangi bir yapı içerebilir. Bu hiyerarşi gibi bir şeye bağlıyım:

| -mu-eklentiler | - | -load.php | - | - | -selena-network | - | - | - | -kayıt | - | - | - | - | -plugin.php | - | - | - | - | -... | - | - | - | -jetpack | - | - | - | - | -plugin.php

Ağımız için gerekli tüm "eklentiler" load.php dosyasına bağlanır:

// Tüm eklentiler için Çevirileri Yükle load_muplugin_textdomain ("selena_network", "/ selena-network / diller /"); // Ağ Kaydı WPMU_PLUGIN_DIR gerektirir. "/selena-network/signup/plugin.php"; // Başka eklentiler // WPMU_PLUGIN_DIR gerektirir ...

Eklenti klasörleri selena-network klasörünün içinde saklanır, her birinin load.php'ye dahil ettiğimiz kendi plugin.php'si vardır. Bu size esneklik ve işleri hızlı bir şekilde kapatıp açma yeteneği verir.

Kayıt sayfası adresi

Kayıt sayfasının adresini belirtmek için wp_signup_location filtresi kullanılır. wp-login.php dosyasının içinde bulunabilir ve wp-signup.php'ye yönlendirmeden sorumludur.

Durum "kayıt": if (is_multisite ()) (wp_redirect (apply_filters ("wp_signup_location", network_site_url ("wp-signup.php"))); çıkış;

Mevcut sitedeki kayıt sayfasının adresini döndürecek olan mu-plugins / selena-network / signup / plugin.php dosyasına fonksiyonumuzu ekleyelim:

fonksiyon selena_network_signup_page ($ url) (home_url'ye dön (). "/ Signup /";) add_filter ("wp_signup_location", "selena_network_signup_page", 99);

selena_network, çarpışmaları önlemek için sitemdeki MU eklentilerinin içindeki tüm işlevlerin adlarında kullandığım önek, kendi benzersiz önekimle değiştirilmelidir. Filtrenin önceliği 99'dur çünkü bbPress ve BuddyPress gibi bazı eklentiler bu URL'nin üzerine kendi URL'lerini yazabilir (MU eklentileri normal eklentilerden daha erken yüklenir, yukarıya bakın). Ziyaretçiyi aynı etki alanında tutmak için network_site_url () yerine home_url () kullanıldığını unutmayın. Adres olarak herhangi bir URL kullanılabilir.

Sayfa yarat

Şimdi normal arayüz üzerinden site.com/signup/ adresiyle bir sayfa oluşturalım ve alt tema klasöründe yeni sayfamızın şablonu page-signup.php'dir. "Kayıt" kelimesi yerine benzersiz bir kimlik kullanılabilir.

Yeni şablonun içinde, kayıt formunu gösterecek olan selena_network_signup_main() işlevini çağırmanız gerekir.

Şablonlarla yapılan tüm sürecin gerekli olmadığı ve bunun yerine kendi kısa kodunuzu oluşturabileceğiniz ve bunun da selena_network_signup_main () işlevini çağıracağı unutulmamalıdır.

wp-signup.php ve wp-activate.php

Şimdi kayıt formunu gösterecek bir fonksiyon oluşturmaya başlayalım. Bunu yapmak için wp-signup.php ve wp-activate.php dosyalarını WordPress kökünden mu-plugings / selena-network / signup / klasörüne kopyalayın (ve bunları mu-plugins / selena-network içine bağlamayı unutmayın) / kayıt / plugin.php) ... Dosyalarla yapılacak diğer manipülasyonları açıklamak son derece zor ve zaman alıcıdır, bu nedenle bunları kendiniz yapmanız gerekecektir. Tam olarak ne yapılması gerektiğini anlatacağım ve projemin kaynak dosyalarını yayınlayacağım:

  1. Dosyanın başında, tüm gerekli, işlev çağrılarını ve işlevlerin dışındaki diğer kodları kaldırın.
  2. Adlara benzersiz önekler ekleyerek tüm işlevleri yeniden adlandırın.
  3. wp-signup.php kodunun alt kısmını selena_network_signup_main işlevine sarın ve en başına global $ active_signup yazın; ...
  4. Düzeni doğru yerlerde kendi düzeninizle değiştirin.

wp-activate.php içinde, yaklaşık olarak aynısını yapmanız gerekir:

  1. Fonksiyonların dışındaki tüm kodları kaldırın, düzeni ayrı bir fonksiyona sarın.
  2. Gerektiğinde düzeni değiştirin.

wp-activate.php dosyası hesap aktivasyon sayfasından sorumludur. Kayıt sayfasında olduğu gibi, bunun için de wp-activate.php dosyasından işlevi çağırdığınız ayrı bir şablon oluşturmanız gerekir.

Aktivasyon mektupları gönderiyoruz

Kayıt sayfası, ziyaretçiye hesabını etkinleştirmesi için bir bağlantı içeren bir e-posta gönderir. Varsayılan olarak, bu, ms-functions.php dosyasındaki wpmu_signup_user_notification () işlevi tarafından yapılır. İşlevselliği, işleviniz için ödünç alınabilir. Bu özelliği kullanmayı bırakmanın nedeni, wp-activate.php adresinden hesap aktivasyon bağlantısını göndermesidir. Bu işlevi wpmu_signup_user_notification filtresini kullanarak false vererek "devre dışı bırakabilirsiniz" (bunu yapmazsanız aktivasyon mektubu iki kez gönderilecektir, tamam, aslında iki farklı harf).

Armyofselenagomez_wpmu_signup_user_notification işlevi ($ user, $ user_email, $ key, $ meta = array()) (// ... // wpmu_signup_user_notification () işlevinden kod wp_mail ($ user_email, wp_specialchars_decode ($ message_headers), $ mesaj), $ ; false döndür;) add_filter ("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);

Sonuç olarak, Selena temasındaki kayıt sayfası çok daha temiz ve daha doğru görünüyor.

Çözüm

Aynı şeyi İnternette yapmanın pek doğru olmayan başka yolları da var - Apache yönlendirmeleri, Java Script olmadan çalışmayacak AJAX formları, vb. kendi web sitesi.

Dosyaları dikkatli bir şekilde düzenlemeniz ve orijinalinden fazla sapmamaya çalışmanız gerektiğini unutmayın, böylece gelecekte WordPress wp-signup.php ve wp-activate.php dosyalarını değiştirirse, onları karşılaştırmanız daha kolay olacaktır. değişir.

Kodun içinde neler olduğunu ve nasıl olduğunu tam olarak anlamak için yukarıda açıklanan tüm işlevlerin kaynak koduna bakmayı unutmayın.

Bonus. Spam gönderici koruması

En küçük WordPress siteleri bile sık sık spam kayıtlarına maruz kalır. Botları filtrelemek için, genellikle daha çok yapay zeka oluşturmaya çalışmak gibi sonsuz koşullar yazabilirsiniz 🙂 Çoklu site durumunda, Apache'deki olağan yönlendirme bana çok yardımcı oldu, bununla birlikte /wp-signup.php ve /wp-'yi açarken acitvate.php, 404 istedim (Apache konfigürasyonu konusunda uzman değilim, bu yüzden kurallarım çok doğru olmayabilir).

RewriteBase'de RewriteEngine / RewriteRule ^ wp-signup \ .php - RewriteRule ^ wp-activate \ .php - # BEGIN WordPress # Varsayılan olarak WordPress kurallarına dokunmayın :) # ... # WordPress'i Bitir

P. S. Bazı üçüncü şahıslara ait şeyleri olabildiğince ayrıntılı bir şekilde açıklamaya çalışıyorum çünkü başladığımda bazen birçok şeyi soracak ve açıklayacak kimse yoktu. Ayrıca, diğer materyallerle ilgili bu kadar küçük ipuçlarının, birini yeni bir şeyler öğrenmeye ve bilgi alanlarını genişletmeye iteceğine inanıyorum. RewriteRule girişlerinde normal ifadeler kullanılır, bunlar hiç karmaşık değildir, örneğin, ^ karakteri bir satırın başlangıcı anlamına gelir.

“Banka sitelerini para için, Pentagon'u casusluk için kırıyorlar ve kimsenin projeme ihtiyacı yok”, ne yazık ki kişisel blogların, İnternet kartvizitlerinin, küçük şirketlerin sanal ofislerinin çoğu sahibinin düşündüğü şey bu. Sadece birkaç kişi siteyi nasıl koruyacağını düşünüyor, ama boşuna. Modern gerçekliklerde, türü veya popülerliği ne olursa olsun, kesinlikle herhangi bir platform, bilgisayar korsanlarının gözünde ilgi çekicidir. Kaynağınıza kim ihtiyaç duyabilir ve neden? Anlayalım:
1. scriptkiddis şakaları. Jargon, "karanlık tarafa" ilk adımlarını atan, gelecek vadeden bilgisayar korsanlarını ifade eder. Birkaç araç edindikten veya kendi programlarından birkaçını yazdıktan sonra, karşılaştıkları ilk kurban üzerinde performanslarını test etmeye ve kural olarak en kolay (zayıf korumalı ve güncellenmemiş CMS) hedefleri seçmeye isteklidirler.
2. Siyah SEO. Dürüst olmayan optimize edicilerin hizmetleri hala kullanılmaktadır - 10'dan fazla TCI'ye sahip projelerin koduna gizli bağlantılar yerleştirmek hala uygulanmaktadır. Ve her şeyden önce, açık kaynak motorlarındaki (Joomla, Drupal, OpenCart vb.) kaynaklar saldırıya uğrar.
3. Bir botnet oluşturmak. WordPress'i htaccess ve eklentilerle korumak da önemlidir, çünkü DDoS saldırılarında, spam göndermede vb. kullanılan bir zombi ağı oluşturmak için kesinlikle herhangi bir kaynak kullanılabilir.
4. Teminat hasarı. Son olarak, saldırıya uğramayabilirsiniz - asıl amaç barındırma olacak ve site yalnızca sağlayıcının BT altyapısının büyük bir güvenlik açığı olarak hizmet edecek. Tabii ki, bilgisayar korsanları kaderini umursamayacak.

Bilgisayar korsanlığının sonuçları en tatsız olabilir: içerik veya bir bütün olarak kaynak kaybı, arama motoru sonuçlarında karamsarlık, “Site bir bilgisayarın veya mobil cihazın güvenliğini tehdit edebilir” yazısı nedeniyle izleyici kaybı ve Web kaynağınız temelinde yasa dışı eylemler gerçekleştirildiği takdirde bir ceza davasına dahil olma riski bile.

Bu nedenle, güvenlik sorunlarının kesinlikle her web yöneticisini etkilediğini güvenle söyleyebiliriz. Ve onları ihmal ederseniz, arama motorunu (ve bu para ve değerli zaman) tanıtmak için tüm çabalar bir gecede boşa gidebilir. Sorun çok acil, bu yüzden ağ tehditlerine ve bunlarla başa çıkma yöntemlerine ayrılmış bir dizi makale başlatmaya karar verdim. Popüler CMS sistemi - Wordpress üç konuda ele alınacaktır.

Bir WordPress sitesini güvence altına alma yöntemleri

En ilkel hack yöntemlerinden biri kaba kuvvettir. Kelimenin tam anlamıyla terim "kaba kuvvet" olarak çevrilir ve olası seçeneklerin kaba kuvvetle numaralandırılmasıyla bir çift oturum açma / şifre alma anlamına gelir. Çoğu zaman, kaba kuvvetçiler motor ve sunucu ayarlarındaki hatalardan yararlanarak hayatlarını kolaylaştırmaya çalışırlar - bu, örneğin kombinasyon sayısını önemli ölçüde azaltan hesap adını bulmalarına yardımcı olur. Bu zafiyetlerin ortadan kaldırılması ve yetkisiz erişim girişimleriyle mücadele yöntemleri tartışılacaktır.

1. Benzersiz bir yönetici girişi kullanın

Varsayılan olarak, sistem admin adında bir kullanıcı oluşturmayı önerir. Bununla birlikte, WordPress sitenizi korumak için, bir dizi rastgele harf ve rakamdan oluşan bir giriş kullanmak en iyisidir. Canlı bir kaynakta, yöneticinin adı iki yöntemden biri kullanılarak sorunsuz bir şekilde değiştirilebilir:

Yönetici paneli aracılığıyla. "Kullanıcılar" bölümüne gidin, "Yeni Ekle" düğmesini tıklayın ve bir hesap oluşturun. “Rol” alanında “Yönetici”yi seçin ve işlemi onaylayın. Ardından yeni oluşturulan hesap adına yeniden giriş yapın, "Kullanıcılar" bölümüne dönün, "admin"i seçin ve "Sil" e tıklayın. Açılan pencerede radyo düğmesini "Tüm içeriği bağla" konumuna getirin ve açılır listeden yeni bir yönetici seçin ve ardından "Silme işlemini onayla"ya tıklayın.
... phpMyAdmin'i kullanma. Aynı işlemi veritabanı kontrol panelinden yapmak çok daha kolay. Gerekli veritabanını seçin, wp_users tablosunu bulun, “admin” (ID = 1) satırını bulun, “Değiştir”e tıklayın ve istediğiniz ismi girin.

2. Özel bir yayıncılık hesabı oluşturun

Yönetici "dışlanırsa", bu ek koruma sağlayacaktır. Makaleleri göndermek için ayrı bir hesap oluşturun ve daha önce yayınlanmış tüm materyalleri paragraf 1'de açıklanan şekilde buna bağlayın. Ardından, bilgi ekleyin ve okuyucularla yalnızca yeni bir hesaptan iletişim kurun.

3. Güçlü bir parola girin

Genel olarak kabul edilen önerileri izleyin: şifre en az 10 karakter uzunluğunda olmalı, benzersiz olmalı ve rastgele bir büyük ve küçük harf, sayı ve özel karakter dizisinden oluşmalıdır.
Hiçbir durumda yapmamalısınız:
... anlamlı ifadelerden bir şifre oluşturun
... herhangi bir gerçek veriyi kullanın (doğum tarihi, kızlık soyadı, banka hesap numarası, cari yıl ...)
Bu, sözlük kullanarak parola arama riskini ortadan kaldıracak ve ayrıca kaba kuvvet için gereken süreyi önemli ölçüde artıracaktır. Bu nedenle, yalnızca küçük harf ve sayılardan oluşan (hki458p1fa) 10 karakterlik bir diziyi kırmak, bir PC için 10 gün bilgisayar süresi alacaktır, ancak büyük harfler ve ek karakterler (Nv6 $ 3PZ ~ w1) eklerseniz, bu süre 526 yıla kadar artacak ve neredeyse mutlak WordPress korumasını garanti edecek. Özellikle birkaç projeden sorumluysanız, bu şifreleri bulmak ve hatırlamak oldukça zordur. Bu nedenle, bunları oluşturmak ve depolamak için, ücretsiz olarak dağıtılan KeePassX gibi özel yöneticiler veya normal bir test belgesi kullanmak daha iyidir (bir şifre ile bir arşive paketlenmesi daha iyidir).

4. Veritabanının parolasını değiştirin

Yukarıdaki kurallar MySQL erişim kodunun güvenliği için de geçerlidir. Sonuçta, tüm içeriği ve ayrıca yöneticinin gizli ifadesinin karmasını içeren oradadır. Zaten zayıf bir şifre kullanıyorsanız, değiştirmek için uğraşmaya değer. Bu şu şekilde yapılır:

1. phpMyAdmin kontrol panelinize gidin
2. "Kullanıcılar" sekmesini açın ve veritabanının sahibini seçin
3. “Ayrıcalıkları Düzenle”ye tıklayın
4. "Şifreyi değiştir" sütununu bulun ve uygun alanlara yeni gizli diziyi girin
5. "Tamam"a tıklayarak değişiklikleri kaydedin

Artık geriye sadece wp-config.php dosyasını düzenlemek kalıyor, aksi takdirde WordPress veritabanına bağlanamayacaktır. define satırını bulun ('DB_PASSWORD', 'şifre'); ve parola kelimesi yerine yeni parolayı girin. SQL komutlarını sınırlamak için (') karakteri kullanıldığından, bir parolanın parçası olarak kullanılmaması gerektiğini unutmayın.

5. Şifreleri düzenli olarak güncelleyin

En az altı ayda bir değiştirilmeleri gerekir. Olağanüstü bir kod ifadesi değişikliği HER ZAMAN aşağıdakilerden sonra yapılmalıdır:

Kimlik doğrulama için verilerin üçüncü taraflara aktarılması (programcılar, sistem yöneticileri, optimize ediciler ve diğer uzmanlar, barındırma şirketinin personeli üzerinde çalışsalar bile)
... başka birinin bilgisayarından bir web kaynağına giriş yapmak (bir partide, bir internet kafede)
... güvenliği ihlal edilmiş olabilecek ekipmandan yetkilendirme (virüs bulaşmış bir makine)

6. Çerezler için gizli anahtarları değiştirmeyi unutmayın

wp-config.php dosyasında bulunurlar. 8 tane var:

define ("AUTH_KEY", "benzersiz anahtar"); define ("SECURE_AUTH_KEY", "benzersiz anahtar"); define ("LOGGED_IN_KEY", "benzersiz anahtar"); define ("NONCE_KEY", "benzersiz anahtar"); define ("AUTH_SALT", "benzersiz anahtar"); define ("SECURE_AUTH_SALT", "benzersiz anahtar"); define ("LOGGED_IN_SALT", "benzersiz anahtar"); define ("NONCE_SALT", "benzersiz anahtar");

define ("AUTH_KEY", "benzersiz anahtar"); define ("SECURE_AUTH_KEY", "benzersiz anahtar"); define ("LOGGED_IN_KEY", "benzersiz anahtar"); define ("NONCE_KEY", "benzersiz anahtar"); define ("AUTH_SALT", "benzersiz anahtar"); define ("SECURE_AUTH_SALT", "benzersiz anahtar"); define ("LOGGED_IN_SALT", "benzersiz anahtar"); define ("NONCE_SALT", "benzersiz anahtar");

Değişkenlerin isimlerinden de tahmin edebileceğiniz gibi, siteyi yapmak için kullanılan çerezlerin (bilinen argo: cookie - cookie, salt - salt, hackerları tuzlu cookielerle besliyoruz) şifrelenmesinden anahtarlar sorumludur. yetkilendirmeden sonra bilgisayarınızı "hatırlayın". Sonuç olarak, saldırgan yönetici şifresinin karmasını eline geçirse bile, siteye erişmek için gerekli çerezleri listelenen gizli ifadeler olmadan oluşturamaz.

Güvenliği artırmak için, CMS dağıtıldıktan hemen sonra varsayılan karakter dizileri benzersiz olanlarla değiştirilmelidir. Kolaylık sağlamak için geliştiriciler www.api.wordpress.org/secret-key/1.1/salt/ adresinde bulunan bir web oluşturucu oluşturmuşlardır - girdiğinizde tuşları göreceksiniz ve sayfayı yenilerseniz kombinasyonlar güncellenir .

7. Yönetici alanı için çift yetkilendirme

Htaccess, sunucu düzeyinde kimlik doğrulama ekleyerek WordPress sitenizi daha da güvenli hale getirmenize olanak tanır. Kod şöyle görünecek:

< Files wp- login. php> # Temel kimlik doğrulama türünü belirledik - bu, denediğinizde# belirtilen dizine veya dosyaya erişim için bir şifre istenecektir: AuthType temel # Formun başlığında görüntülenecek metni girin: AuthName "Kendinizi tanımlayın" # Parolayı içeren dosyanın yolunu belirtin: AuthUserFile "/home/site/.htpasswd" # wp-login.php dosyasına erişirken şifreyi girmeniz gerektiğini belirtiyoruz: Geçerli kullanıcı gerektir # .htpasswd dosyasına üçüncü şahısların erişimini engelleyin:< Files . htpasswd>izin ver, reddet hepsini reddet

# Yetkilendirme komut dosyasını seçin: # Temel kimlik doğrulama türünü ayarlayın - bu, belirtilen dizine veya dosyaya # erişmeye çalıştığınızda bir parola isteneceği anlamına gelir: AuthType basic # Form başlığında görüntülenecek metni girin: AuthName "Kendinizi tanımlayın" # Parolayı içeren dosyanın yolunu belirtin: AuthUserFile "/home/site/.htpasswd" # wp-login.php dosyasına erişirken bir parola girmeniz gerektiğini belirtiyoruz: Geçerli kullanıcı iste# .htpasswd dosyasına üçüncü şahısların erişimini engelleyin: izin ver, reddet hepsini reddet

Aynı zamanda, htaccess'in kendisinin güvenliğine dikkat etmek güzel olurdu. Açıkçası, böyle bir yönerge ana barındırma ayarlarında belirtilmelidir, ancak bazı sağlayıcıların dikkatsizliği göz önüne alındığında, güvenli oynamalısınız:

"Giriş" yerine istediğiniz adı değiştirin. Geriye parolayı kendisi oluşturmak ve şifrelemek kalıyor, çünkü bu tür verileri açık metin olarak saklamak kabul edilemez bir lüks. Bunun için birçok hizmet var, ancak gerekli betiği kendiniz yazmanız daha iyi. Bu şu şekilde yapılır:

1) Not defterinde bir .php dosyası oluşturun, örneğin crypt.php
2) "Şifre" kelimesi yerine şifrenizi değiştirerek kodu buraya girin:

3) Dosyayı kaydedin ve kök dizine yükleyin
4) site_name.ru / crypt.php bağlantısını takip edin - ekranda şifre karması görünecektir
5) Bu değeri .htpasswd dosyasına kaydedin ve kök dizine yükleyin ve crypt.php silin

Son dokunuş, web kaynak dizininin içeriğinin görüntülenmesinin yasaklanmasıdır. htaccess'e tek bir satır eklemek yeterlidir:

Seçenekler Tümü - Dizinler

Seçenekler Tümü - Dizinler

Bu, bilgisayar korsanlarının proje dizinlerinde hangi dosyaların olduğunu bulamamaları için yapılır. Birçok hosting sitesinde bu yönerge zaten sunucu ayarlarında yer almaktadır ancak bu nokta gözden kaçırılırsa kendiniz kayıt ettirmelisiniz.

8. Captcha'yı yükleyin

Captcha kullanmak, hepsini olmasa da en azından kaba kuvvet botlarının çoğunu ve aynı zamanda kesmenize izin verecektir. WordPress site koruma eklentisi dizini birçok seçenek sunar. Google'ın tescilli bir çözümünü bağlamanın yanı sıra, BestWebSoft'un matematiksel işlemlere dayalı karma (grafik ve metin) türündeki Captcha'sı da büyük ilgi görüyor. Hizmet bağımsızlığı, netlik ve kabul edilebilir karmaşıklık düzeyi, modülü en iyilerden biri yapar.

Özelleştirme büyük bir sorun değil. "Temel" sekmesi, captcha'nın nerede görüntüleneceğini seçmenize ve gerekli alanları işaretlemek için bir başlık ve bir sembol belirlemenize olanak tanır.

"Gelişmiş" bölümü, botlar için hayatı daha da zorlaştırmak için ek görüntü paketlerini etkinleştirmenin yanı sıra kendi hata mesajlarınızı oluşturma yeteneği sağlar.

Bir başka kullanışlı özellik de, captcha'nın görüntülenmediği yerleşik IP adresleri beyaz listesidir.

Eklentiyi kurmanın ve etkinleştirmenin sonucu, yetkilendirme sayfasında bir formun görünümü olacaktır:

9. Yönetici adresini değiştirin

Bir WordPress sitesinin nasıl korunacağı hakkında konuşurken, daha radikal ama aynı zamanda daha karmaşık bir yoldan bahsetmeye değer - giriş sayfası URL'sini komut dosyası düzeyinde değiştirmek. Prosedür birkaç aşamada gerçekleştirilir:

1. wp-login.php dosyasını yeniden adlandırın. Rastgele bir küçük Latin harf, sayı ve tire dizisi kullanın. Örneğin: abc-123.php
2. Sonuç dosyasında wp-login.php ile ilgili tüm referansları bulun ve bunları yeni adla değiştirin.
3. Sitenin doğru çalışması için, değiştirmenin ayrıca şurada yapılması gerekir: wp-activate.php, general-template.php, post-template.php, functions.php, class-wp-customize-manager.php, general -template.php, link-template.php, admin-bar.php, post.php, pluggable.php, ms-functions.php, canonical.php, functions.wp-scripts.php, wp-signup.php, benim -sites.php, schema.php, ru_RU.po

Bu manipülasyonlardan sonra admin paneli /abc-123.php sitesinde yer alacaktır. Yeni dosyaya erişim, yukarıda açıklandığı gibi sınırlandırılmalı ve parola korumalı olmalıdır. Sahte bir wp-login.php dosyası oluşturarak ve ona bir şifre belirleyerek potansiyel bilgisayar korsanlarını yanıltmak da mümkündür.

Daha da basit bir seçenek, "wp-login.php'yi yeniden adlandır" eklentisini kullanmaktır. Siteyi korumak için eklentiyi kurduktan sonra, "Ayarlar" -> "Kalıcı Bağlantılar" menüsünde yeni bir alan görünecektir:

10. Yöneticinin IP'sini belirtin

Statik bir IP adresiniz varsa ek güvenlik sağlanabilir. Kendi bilgisayarınız dışında herhangi bir bilgisayardan wp-login.php'ye erişimi reddetmek, bilgisayar korsanları için hayatı çok daha zor hale getirecektir:

< Files wp- login. php>sipariş reddet, reddet hepsinden izin ver 127.0.0.1, 127.0.02'den izin ver # IP adreslerinizi virgülle ayırın

sipariş reddet, reddet hepsinden izin ver 127.0.0.1'den izin ver, 127.0.02 # IP adreslerini virgülle ayır

11. Yetkilendirme hatalarını devre dışı bırakın

Parolaları kaba zorlarken, bir saldırgan, girilen verilerin yanlış olduğunu bilmeyi çok faydalı bulacaktır. Bu tür mesajlar her başarısız oturum açma girişiminde görüntülenir ve WordPress ayrıca yanlış girilenleri, kullanıcı adını veya şifreyi bildirir. Onlardan kurtulmak için, function.php'ye sadece bir satır eklemeniz yeterlidir:

add_filter ("login_errors", create_function ("$ a", "boş dönüş;"));

add_filter ("login_errors", create_function ("$ a", "boş dönüş;"));

Bunu yapmak için yönetici panelinde "Görünüm" -> "Düzenleyici" -> "Tema İşlevleri"ni seçin. Kodu açılış etiketinden sonra yazmak gerekiyor

12. Güvenli bir bağlantı kullanın.

Kullanıcının bilgisayarı ile web sunucusu arasındaki trafiği şifrelemek için, kullanımı önemli verileri, bizim durumumuzda tanımlama verilerini ele geçirme olasılığını dışlayan bir https protokolü vardır. Etkinleştirmek için önce iki işlevi aynı anda gerçekleştiren bir SSL sertifikası satın almanız gerekir: bir web kaynağının doğrulanması ve iletilen bilgilerin şifrelenmesi. Özel merkezlerde veya bir dizi alan adı kayıt şirketinden alabilirsiniz. Ticari olmayan amaçlar için ücretsiz bir giriş seviyesi sertifikası almak yeterlidir (bu, www.startssl.com şirketi tarafından sunulmaktadır). Kurulum işlemine gelince, kural olarak, barındırma sağlayıcısının yardım bölümünde ayrıntılı olarak açıklanmaktadır.

Bir SSL sertifikası aldıktan sonra, web kaynağının yönetim bölümünün güvenli bir bağlantıya yeniden yönlendirilmesini yapılandırmanız gerekir. WordPress durumunda, bu, aşağıdaki yapı kullanılarak yapılır:

< IfModule mod_rewrite. c>Seçenekler + FollowSymlinks RewriteEngine Açık RewriteCond% (HTTPS) = kapalı RewriteCond% (REQUEST_URI) = / wp- oturum açma. php RewriteRule (. *) https:

Seçenekler + FollowSymlinks RewriteEngine Açık RewriteCond% (HTTPS) = kapalı RewriteCond% (REQUEST_URI) = / wp-login.php RewriteRule (. *) Https: //% (HTTP_HOST)% (REQUEST_URI)

Ayrıca, SSL sertifikalarının kullanımını motor düzeyinde de zorlayabilirsiniz. Bunu yapmak için wp-config.php dosyasını açın ve sonra ekleyin

define ("FORCE_SSL_ADMIN", true);

define ("FORCE_SSL_ADMIN", true);

Ayrıca, http'den https'ye genel bir yönlendirme ayarlayabilirsiniz. Google'ın güvenli projeleri teşvik ettiği ve onlara arama sonuçlarında bir miktar öncelik verdiği göz önüne alındığında, yeni siteler için bu yaklaşım en uygunudur:

< IfModule mod_rewrite. c>Seçenekler + FollowSymlinks RewriteEngine on RewriteCond% (HTTPS) = kapalı RewriteRule ^ (. *) $ Https: //% (HTTP_HOST)% (REQUEST_URI)

Seçenekler + FollowSymlinks RewriteEngine on RewriteCond% (HTTPS) = kapalı RewriteRule ^ (. *) $ Https: //% (HTTP_HOST)% (REQUEST_URI)

13. Davetsiz misafirleri engelle

Belirli IP'lerden şüpheli etkinlik tespit edilirse, siteye erişimlerini engellemeye değer. Bu, önceki yöntemle benzetilerek yapılır. Aradaki fark, direktifler bir bütün olarak proje için yazılmış ve yasaklamak istediğimiz kişilerin adreslerini listeledik:

İzin Ver, Reddet Tümünden İzin Ver 127.0.0.1'den Reddet, 127.0.02 # İstenmeyen IP'yi belirtin

Yöntem güvenilir ancak etkisizdir. İlk olarak, kaba kuvvet hizmetlerinin taleplerini bir şekilde kaydetmek ve onları saygın ziyaretçilerden ayırmak gerekir. İkincisi, büyük bir saldırı ile, bilgisayar korsanlarının ve botların IP'sini manuel olarak izleyemez ve kullanamazsınız. Bu yöntem, yalnızca yöneticinin güvenilir bir kara liste adresleri varsa iyidir.

Aksi takdirde, WP Cerber adlı bir WordPress site güvenlik eklentisi kullanabilirsiniz. Bu çözüm tamamen ücretsizdir ve CMS korsanlığını önlemek için tasarlanmış çok etkileyici bir araç seti sunar. Doğrudan yönetici panelinden yükleyebilirsiniz.

Varsayılan olarak, oldukça mantıklı parametreler sunulur. Ancak yanlış anlaşılmalara mahal vermemek için deneme sayısı 5'e çıkarılmalıdır.

Yönetici adresini daha önce açıklanan şekilde değiştirirseniz, "Herhangi bir wp-login.php isteği için IP'yi engelle"nin karşısındaki onay kutusu işaretlenmelidir.

Bu amaçlar için WP Cerber'in kendi aracını da kullanabilirsiniz:

Citadel sitesini korumaya yönelik eklenti modu ayrıca ek yapılandırmaya ihtiyaç duymaz. Devasa bir kaba kuvvet saldırısı sırasında projeyi "güve savurmak" için tasarlandı. “Dosyada oturum açma denemelerini kaydet” seçeneğinin yanındaki kutunun işaretini kaldırmak daha iyidir - bu, sunucudaki ek yükün ortadan kaldırılmasına yardımcı olacaktır.

“Erişim Listeleri” sekmesi, “siyah” ve “beyaz” bir IP listesi oluşturmak için kullanılır (statik bir adresiniz varsa, onu güvenilirler listesine eklediğinizden emin olun) ve “Araçlar” bölümü size izin verir. önceden yapılmış ayarları içe ve dışa aktarın. Ancak, bu olasılıklar ayrı bir değerlendirme gerektirmez.

14. Yapılandırma dosyasını taşıyın

Yukarıda öğrendiğimiz gibi, wp-config.php, MySQL'e erişim için giriş ve şifre gibi kritik verileri ve ayrıca API anahtarlarını depolar. Bir sonraki adım açık görünüyor - dosyaya erişimi kısıtlayarak WordPress'i htaccess aracılığıyla korumak:

< Files wp- config. php>İzin ver, reddet Tümünden reddet

İzin ver, reddet Tümünden reddet

Ancak, daha güvenilir bir yöntem de var. WordPress, çok az kişinin bildiği çok ilginç bir özelliğe sahiptir. Motor, yapılandırma dosyasının kök dizinin bir seviye üstüne yerleştirilmesine izin verir. php, site dizinine taşınabilir. Bu durumda, dosya İnternet üzerinden tamamen erişilemez hale gelirken, içerdiği bilgiler CMS tarafından okunmaya devam edecektir.

15. YÖNLENDİRİCİ kontrolü ekleyin

WordPress'i istenmeyen e-postalardan korumak için kanıtlanmış bir yöntem, kaba kuvvet saldırılarına karşı da yardımcı olacaktır. Sonuçta, parolaların kaba kuvvetle kullanılması hiçbir şekilde manuel bir iş değildir: bu amaçlar için özel programlar kullanılır. Bu, gelen isteklerde üstbilgi kontrolünü etkinleştirerek, hiçbir yerden gelmeyen botları boş bir HTTP REFERER ile kesebileceğiniz anlamına gelir:

< IfModule mod_rewrite. c>RewriteEngine On RewriteCond% (REQUEST_METHOD) POST RewriteCond% (REQUEST_URI). (wp- yorumlar- gönderi | wp- login) \. php * RewriteCond% (HTTP_REFERER)!. * tekseo. su. * [VEYA] RewriteCond% (HTTP_USER_AGENT) ^ $ RewriteRule (. *) http: //% (REMOTE_ADDR) / $ 1

RewriteCond% (REQUEST_METHOD) POST RewriteCond% (REQUEST_URI).(Wp-yorum-post | wp-login) \. Php * RewriteCond% (HTTP_REFERER)!. * Site. * RewriteCond% (HTTP_USER_AGENT) ($ RewriteCond% ( HTTP_USER_AGENT) ($ RewriteCond) ^ $ RewriteCond *) http: //% (REMOTE_ADDR) / $ 1

16. XML-RPC'yi koruyun

3.5 sürümünden bu yana, XML-RPC uzaktan yordam çağrı protokolünü devre dışı bırakma özelliği WordPress'te kayboldu. Temel olarak, mobil uygulamalarla etkileşime geçmek gerekiyor, ancak herkesin böyle bir işlevselliğe ihtiyacı yok. Aynı zamanda, xmlrpc.php, tüm projenin Aşil topuğu olan DDoS saldırılarını gerçekleştirmek için aktif olarak kullanılır.

Ayrıca, bilgisayar korsanları kaba kuvvet için XML-RPC kullanmayı düşünmüşlerdir. wp.getUsersBlogs yöntemini kullanmak, kimlik bilgilerini yönetici formunu kullanmaktan çok daha hızlı yinelemenize olanak tanır. Birçok XML-RPC çağrısı yetkilendirme gerektirdiğinden, şuna benzer bir istek:

< methodCall> < methodName>wp. getUsersBlog'lar < params>< param>< value>< string>yönetici < param>< value>< string> 12345

wp.getKullanıcılarBloglar yönetici 12345

geçen kombinasyonun doğru olup olmadığını motorun size söylemesine neden olur. Bu beladan kurtulmak için protokolü tamamen devre dışı bırakmalısınız. Bu birkaç yolla yapılabilir:

1) xmlrpc.php dosyasına htaccess üzerinden erişimi engelleyerek

require_once (ABSPATH. "wp-settings.php");

kayıt olmak gerekiyor

işlev remove_x_pingback ($ üstbilgileri) (unset ($ üstbilgileri ["X-Pingback"]); dönüş $ üstbilgilerini;) add_filter ("wp_headers", "remove_x_pingback");

4) Kontrol XML-RPC yayınlama eklentisini kullanarak Ayarlar -> Yazma'da uygun seçeneği döndürün:

Lütfen unutmayın: eklenti, etkinleştirmeden hemen sonra protokolü devre dışı bırakır ve ayarlarda ilgili onay kutusunu işaretleyerek etkinleştirebilirsiniz.

17. Kaba kuvvet saldırılarını izleyin

Son olarak, bilgisayar korsanlığı girişimlerini günlüğe kaydetmek için ilginç bir eklentiden bahsetmeye değer - Kimlik doğrulama ve xmlrpc günlük yazarı. Aynı WP Cerber yerleşik izleme araçlarına sahip olsa da, bu modül özellikle yukarıda açıklanan protokolün özelliklerine ihtiyaç duyanlar için hala faydalı olacaktır. AX LogWriter, xmlrpc.php aracılığıyla kaba kuvveti izleyebilir, böylece tehdit derecesini ve yeteneklerini kullanmayı tamamen reddetmenin tavsiye edilebilirliğini değerlendirebilirsiniz. Son olarak, projelerinin güvenliğiyle hiç ilgilenmemiş olanlar için siteyi korumaya yönelik eklenti, listelenen faaliyetlerin önemine gözlerini açacaktır.

AX LogWriter'ı kullanmak basittir. Kurulumdan sonra, gerekli tüm değişiklikleri yapabileceğiniz yönetici menüsünde ilgili bölüm görünecektir:

“Hata Türü” alanında kaydetme yöntemini seçin. Sistem günlüğüne, Apache sunucu günlüğüne yazmayı ve ayrıca özel bir dosya oluşturma yeteneğini destekler. İkinci durumda, Özel Hata Günlüğü Adı ve Özel Hata Günlüğü Yolu ile de yapılandırılabilir. Bu, sistem yöneticisi için geniş olanaklar açar - örneğin, çözüm fail2ban ile birlikte kullanılabilir. Ayrıca, Saat Dilimi sütununda uygun saat dilimini seçmeyi unutmayın.

Özel günlük, doğrudan Özel Günlük Görüntüleyici sayfasındaki yönetici panelinden görüntülenebilir:

Özetleyelim:

Listelenen yöntemler, kaynağınızın güvenliğini önemli ölçüde artırmaya ve onu botların kaba zorlamasından, ağ holiganlarından ve scriptkiddis pratiğinden korumaya yardımcı olacaktır. Ancak, yukarıda açıklanan her şey buzdağının sadece görünen kısmıdır. Saldırganların cephanelerinde çok daha karmaşık yöntemler var. Ve bir sonraki makalede, motor ve sunucu yazılımının çeşitli güvenlik açıklarını kullanarak kendinizi gerçek bilgisayar korsanlarından nasıl koruyacağınız hakkında konuşacağız. Bu materyalde olduğu gibi, genel "hijyen kuralları"na ek olarak, temel CMS ayarları, kodu değiştirme yolları ve en alakalı eklentiler dikkate alınacaktır.


Uygulama güvenliği söz konusu olduğunda, yalnızca donanım ve işletim sistemine değil, aynı zamanda güvenli komut dosyaları yazmaya da dikkat etmek önemlidir. Bu makalede, uygulamanızı nasıl güvenli ve daha az savunmasız tutacağınızı öğreneceksiniz. Aşağıda, uygulamanızı her türlü saldırıdan korumanıza yardımcı olacak önlemlerin bir listesi bulunmaktadır:

  1. Gelen veri doğrulama
  2. XSS saldırılarına karşı koruma
  3. CSRF saldırılarına karşı koruma
  4. SQL Enjeksiyonunu Önleme
  5. Dosya sistemi koruması
  6. Oturum veri koruması
  7. Hata işleme
  8. Dahil Edilen Dosyaları Koruma

Gelen veri doğrulama

Uygulamanızı tasarlarken, onu gelen "kötü" verilerden korumaya çalışmanız gerekir. İzlenecek kural şuna benzer: "Kullanıcının girdiğine asla inanmayın." Çoğu kullanıcı bir tehdit olmasa da, birisinin formlar veya adres çubuğu aracılığıyla girilen "kötü" verileri kullanarak sitenizi hacklemek isteme olasılığı her zaman vardır. Gelen verileri her zaman doğrular ve filtrelerseniz, güvenli bir uygulama yazma şansınız yüksektir.

Verilerinizi her zaman PHP komut dosyalarında kontrol edin. Verileri doğrulamak için JavaScript kullanırsanız, saldırgan istediği zaman tarayıcısında bunu devre dışı bırakabilir. Bu durumda uygulamanız risk altındadır. Hiç kimse JavaScript doğrulamasına karşı değildir, ancak iyi bir koruma için PHP komut dosyalarındaki verileri iki kez kontrol etmeniz gerekir.

XSS saldırılarına karşı koruma

Siteler arası komut dosyası çalıştırma veya XSS saldırısı, potansiyel olarak savunmasız sayfalara kod enjekte etmeye dayalı bir saldırıdır. Tehlike, kötü amaçlı kodun formlar aracılığıyla girilebilmesi ve ardından tarayıcıda görüntülenebilmesidir.

Sitenizin, ekledikten hemen sonra görüntülenen yorum girmek için bir formu olduğunu varsayalım. Saldırgan, JavaScript kodunu içeren bir yorum girebilir. Formu gönderdikten sonra veriler sunucuya gönderilir ve veritabanına girilir. Bundan sonra, veriler veritabanından alınır ve yeni yorum, gömülü JavaScript kodu da dahil olmak üzere HTML sayfasında görüntülenir. Kullanıcıyı bazı kötü niyetli sayfalara veya kimlik avı sitelerine yönlendirebilir.

Uygulamalarınızı korumak için, gelen verileri, mevcut etiketleri kaldıracak olan strip_tags () işlevi aracılığıyla çalıştırın. Verileri bir tarayıcıda görüntülerken htmlentities () işlevini kullanın.

CSRF saldırılarına karşı koruma

Bakacağımız sonraki saldırı türü, bir CSRF saldırısı veya siteler arası istek sahtekarlığıdır. Saldırgan, gizli bilgileri elde etmek veya kurbanın bilgisi olmadan bir anlaşma yapmak için çeşitli hileler kullanır. Bu, esas olarak, iş mantığının GET isteklerinin çalışmasına dayandığı kötü korunan sitelerde olur.

Genel olarak konuşursak, GET istekleri önemsizdir. Idempotency, bu bağlamda, bir ve aynı sayfaya herhangi bir dış müdahale olmaksızın herhangi bir sayıda erişilebilmesi anlamına gelir. Bu nedenle GET istekleri yalnızca bilgiye erişim sağlamak için kullanılmalı, hiçbir durumda çeşitli türde işlemleri gerçekleştirmek için kullanılmamalıdır.

Aşağıdaki basit örnek, güvenli olmayan bir sitenin nasıl CSRF saldırısına maruz kalabileceğini gösterir:

Bob'un Alice'e bir CSRF saldırısı yapmak istediğini varsayalım. Özel bir url adresi oluşturdu ve e-posta ile Alice'e gönderdi:

Web sitemi ziyaret edin!

Alice example.com web sitesinde yetkilendirilmişse ve bu bağlantıyı takip ederse, hesabından Bob'un hesabına 1000 $ aktarılacaktır. Alternatif olarak, Bob bir resim de gönderebilir ve src özelliğindeki "kötü" URL'yi doldurabilir.

Tarayıcı mevcut olmadığı için bu görüntüyü gösteremez, ancak istek Alice'in bilgisi ve katılımı olmadan yapılacaktır.

Bu tür saldırıları önlemek için, veritabanındaki bilgileri değiştirmek için tasarlanmış işlemlere yalnızca POST isteklerini kullanın. $ _REQUEST kullanmayın. GET parametrelerini işlemek için $ _GET ve POST parametrelerini almak için $ _POST kullanın.

Ek bir önlem olarak, benzersiz bir belirteç oluşturabilir ve bunu her POST isteğine ekleyebilirsiniz. Bir kullanıcı sisteme giriş yaptığında, rastgele bir jeton üretebilir ve bunu oturuma yazabilirsiniz. Tüm formlar kullanıcıya görüntülendiği için bu jetonun gizli bir alana yazılması gerekir. Uygulamanın iş mantığı, formlardan belirteci ve oturumda depolanan belirteci kontrol edecek işlevsellik sağlamalıdır.

SQL Enjeksiyonunu Önleme

Veritabanına karşı sorguları çalıştırmak için PDO kullanmalısınız. Parametreli sorgular ve hazırlanmış ifadeler ile SQL enjeksiyon tehdidini azaltabilirsiniz.

Aşağıdaki örneğe bir göz atalım:

Yukarıdaki kodda, adı verilen parametreler:: name ve: age dahil olmak üzere hazırlama () yöntemine bir istek gönderiyoruz. Böylece, sorgu daha fazla veri ikamesi için önceden derlenir. Yürütme () yöntemi çağrıldığında, istek tam olarak oluşturulur ve yürütülür. Bu tekniği kullanırsanız, bir saldırganın SQL enjeksiyonu gerçekleştirmeye yönelik tüm girişimleri geçersiz sayılacaktır.

Dosya sistemi koruması

Sorumlu bir geliştirici olarak, her zaman dosya sisteminizden ödün vermeyen kod yazmalısınız. Kullanıcı tarafından gönderilen verilere bağlı olarak bir dosyayı indirmeye gönderen koda bakalım.

Bu komut dosyası çok tehlikelidir, çünkü komut dosyasıyla dosyadan erişilebilen herhangi bir dizine erişmeyi mümkün kılar: oturumların bulunduğu dizin, sistem klasörleri ve çok daha fazlası.

Oturum veri koruması

Varsayılan olarak, tüm oturum bilgileri geçici dizine yazılır. Paylaşımlı barındırma kullanıyorsanız, sizden başka biri bir komut dosyası yazabilir ve oturum verilerini okuyabilir. Bu nedenle oturumlarda parola veya kredi kartı numarası saklamamaya dikkat edin.

Yine de bu tür verileri bir oturumda saklamanız gerekiyorsa, şifreleme en iyi önlemdir. Bu, sorunu tamamen çözmez, çünkü şifrelenmiş veriler %100 güvenli değildir, ancak saklanan bilgiler okunamaz olacaktır. Ayrıca, oturum verilerinin veritabanı gibi başka bir yerde saklanabileceğini de göz önünde bulundurmalısınız. PHP, oturum verilerini kendi yönteminizle saklamanıza izin veren özel bir session_set_save_handler() yöntemine sahiptir.

PHP 5.4'ten beri, SessionHandlerInterface türünde bir nesneyi session_set_save_handler() öğesine iletebilirsiniz.

Hata işleme

Bir uygulamanın geliştirilmesi sırasında ortaya çıkabilecek her türlü hataya dikkat etmekte fayda var, ancak bunların son kullanıcılardan gizlenmesi gerekiyor. Kullanıcılara hatalar gösteriliyorsa, bu sitenizi savunmasız hale getirir. Bu nedenle, en iyi çözüm, hedef sunucu ve geliştirme sunucusu için farklı yapılandırma olacaktır.

Genel sunucuda, display_errors ve display_start_up_errors gibi seçenekleri devre dışı bırakmanız gerekir, ancak error_reporting ve log_errors gibi seçeneklerin aktif olması gerekir, böylece kullanıcılar tarafından karşılaşılan tüm hatalar günlüğe kaydedilir.

Kendi hata işleyicinizi tanımlamak için set_error_handler'ı da kullanabilirsiniz. Ancak, yerel işleyici yerel PHP mekanizmasından daha düşük olduğu için sınırlamalar olabilir. E_CORE_ERROR, E_STRICT veya E_COMPILER_ERROR hataları, belirli bir işleyiciyle aynı dosyada yakalanamaz. Ayrıca işleyicinin kendisinde oluşabilecek hatalar da yakalanamaz.

İstisnaları yakalamanın daha zarif bir yolu için, bir try/catch bloğuna potansiyel olarak tehlikeli kod yerleştirilmelidir. Tüm yerel istisnalar, sınıfların nesneleri veya İstisna'nın alt sınıfları olmalıdır. İstisnalar atıldıysa, try/catch bloğunda işlenebilirler.

Dahil Edilen Dosyaları Koruma

Genellikle, veritabanına bağlanma ve diğerleri gibi diğer dosyalar PHP betiklerine yüklenir. Bazı geliştiriciler bu dosyalara .inc uzantısı verir. PHP bu tür dosyaları varsayılan olarak ayrıştırmaz. Bunları doğrudan adreslerseniz, kullanıcı bu dosyanın metnini görebilir. Bilgisayar korsanı, veritabanına veri bağlantısını depolayan dosyaya erişmeyi başarırsa, daha sonra uygulamanızın tüm verilerine erişebilir. Bu nedenle, yüklenen dosyalar için her zaman .php uzantısını kullanın ve bunları doğrudan kullanıcı erişiminin olmadığı bir yerde saklayın.

Sonuç

Listelenen 8 kuralı izlerseniz, bu, uygulamanızın çeşitli saldırılara karşı direncini büyük ölçüde artıracaktır. Kullanıcıların girdiği verilere güvenmeyin, dosyalarınızı ve veritabanınızı koruyun.

Bir hackerın kim olduğunu düşünelim mi? Hacker, kraker değildir! İnsanlar genellikle bu kavramları karıştırır. Bir bilgisayar korsanı, her şeyden önce, kullanıma hazır düşünceye sahip bir kişidir ve tabiri caizse bu onun gücüdür.

Bir bilgisayar korsanına başarılı bir şekilde direnmek için kalıpların dışında düşünmeyi de öğrenmeniz gerekir. Dedikleri gibi, bir kama bir kama tarafından nakavt edilir.

Bugün size kendinizi php dahil gibi saldırılardan korumanın çok sıra dışı bir yolunu sunacağım. Tabii ki, herkese uygun değil. Ve dürüst olmak gerekirse, saldırının kendisinden değil, tespitinden korur. İlginizi çekti mi?

Dahil nasıl bulunur ...

Önce bir saldırganın bir güvenlik açığını nasıl bulmaya çalıştığını tam olarak anlayalım.

Şuna benziyor. Saldırgan, bu parametrelerin verilerinin include işlevine girdiğini varsayarak, gelen tüm parametreleri tek tek değiştirir. Ya da basit bir şekilde dosyaları "eklemeye" çalışırsa. Ve bir zafiyet olup olmadığını tespit etmek için, hedef sistemde bir dosya eklemesi gerekir (eğer biliyorsa - zafiyet var, hayır - zafiyet yok).

Doğal olarak, bir saldırgan dışarıdan hareket ederse, dizinlerin ve dosyaların konumunun yapısını bilmez ve yolunu bilmediği için herhangi bir dosya ekleyemez. Ancak sistemde her zaman var olan ve her zaman okuma izinlerinin bulunduğu dosyalar vardır. Linux için bu / etc / passwd'dir ve Windows için C: \ boot.ini olsun. Ancak bu arada, Windows bizi pek ilgilendirmiyor, bu yüzden daha sonra passwd hakkında konuşacağız.

/ vb / şifre

Muhtemelen günlüklerinizde formun daha fazla kaydına rastlamışsınızdır:

Eylem = .. / etc / passwd% 00
?eylem = .. / .. / etc / passwd% 00
?eylem = .. / .. / .. / etc / passwd% 00
?eylem = .. / .. / .. / .. / etc / passwd% 00
?eylem = .. / .. / .. / .. / .. / etc / passwd% 00
? do = .. / etc / passwd% 00
? do = .. / .. / etc / passwd% 00
? do = .. / .. / .. / etc / passwd% 00
? do = .. / .. / .. / .. / etc / passwd% 00
? do = .. / .. / .. / .. / .. / etc / passwd% 00
id = .. / etc / passwd% 00
id = .. / .. / etc / passwd% 00
id = .. / .. / .. / etc / passwd% 00
id = .. / .. / .. / .. / etc / passwd% 00
id = .. / .. / .. / .. / .. / etc / passwd% 00

Evet ise, o zaman php include'ı bulmaya çalıştığınızı bilmelisiniz (peki, ya da rastgele dosyaları okuma yeteneği, ama şimdi bununla ilgilenmiyoruz). Bu nedenle, parametrelerinizden biri doğru şekilde işlenmez ve bir işlevle sonuçlanırsa Dahil etmek (), sonra / etc / passwd dosyası eklenecek, içeriği bir php betiği olarak yorumlanacak ve php kod etiketleri içermediğinden tarayıcıda değişmeden görüntülenecektir. Bu, saldırganın bir güvenlik açığına sahip olması için bir "işaret" görevi görür.

Bunu neden yazıyorum, içerme ararken, saldırgan kesinlikle (vakaların% 90'ında garanti ederim) dosyayı eklemeye çalışacaktır. / vb / şifre.

Kendinizi koruyun efendim!

Belki de şimdi düşünüyorsunuz: "İçlerinde / etc / passwd bulunmasıyla normal bir WAF ve filtre paketleri sunmak istiyor mu?" Numara. Bu standart yol. Bu, sıradan bir insanın nasıl düşündüğünün bir örneğidir.

Biraz yaratıcı olalım. Neden passwd dosyasının içeriğine biraz php kodu eklemiyoruz? Ve eğer aniden saldırgan onu bağlamayı başarırsa, bizim php kodumuz çalıştırılacaktır. (Saçmalık mı buluyorsunuz? - sonuca bakın)

Bu dosyayı ekleyecek tek kişinin bir cracker olduğunu bildiğimiz için, php kodumuz onu yasaklamalı ve sistemimizin daha fazla saldırıya uğramasını önlemek için savunmasız dosyayı engellemeli ve yöneticiye bildirilmesi arzu edilir. olay hakkında.

Ancak, sözdizimi sıkı bir şekilde düzenlendiğinden / etc / passwd'ye php kodunu nasıl eklersiniz? Her kullanıcının bir "yorum" alanı vardır - kullanıcının açıklaması, oraya istediğiniz her şeyi girebilirsiniz (elbette iki nokta üst üste hariç). Bu nedenle ihtiyacımız olan yorum ile bir kullanıcıyı alıp sisteme ekliyoruz. Bundan sonra / etc / passwd aşağıdaki satırı içerecektir

kök: x: 0: 0: Süper kullanıcı: /:
arka plan programı: *: 1: 5 :: /: / sbin / sh
bin: *: 2: 2 :: / usr / bin: / sbin / sh
sistem: *: 3: 3: :: /:
adm: *: 4: 4 :: / var / adm: / sbin / sh
güvenlik kullanıcısı: *: 1001: 1001::/:

Eklenti komut dosyasında, ihtiyacınız olan eylemleri zaten gerçekleştiriyoruz - kullanıcıyı yasaklayın, isteği engelleyin, yöneticiye bildirin.

Sonuç olarak, sitenizi bilgisayar korsanlığından koruyabilecek bir tür tuzağımız var.

Çözüm

Evet, yukarıda yazılanların tamamen saçmalık gibi göründüğünün farkındayım. Ve kimsenin bunu pratikte kullanmayacağını çok iyi anlıyorum. Ama bunun için yazmadım. Koruma alanında standart dışı bir yaklaşım örneği göstermek için yazdım.

ilginiz için teşekkürler =)