Posts

WordPress Security Tips

It is very important to take security measures for WordPress. If you do not take your security measures, your site may be hacked or you may suffer data loss.

Security Tips During WordPress Installation

1) Create a strong user password database. It must contain uppercase letters, lowercase letters, numbers, and special characters.

2) Don’t make the database’s name and username simple and guessable names, ie database, db, admin, database.

3) WordPress asks for a prefix on the installation screen. By default, wp_ is the prefix. This is the most common of the tables in the database. Use a different prefix from the default.

4) In the user name and password selection, select a different name from admin, administrator. These are tried first because they are defaults. Likewise, create the password with upper case, lower case, number and special character so it will be strong.

Security Tips After WordPress Installation

1) Add the following codes to your .htaccess file.

# Prevent access to .htaccess file
<files .htaccess>
order allow,deny
deny from all
</files>
# remove server signing
ServerSignature Off
# limit file upload size to 10MB
LimitRequestBody 10240000
# Prevent access to wp config.php file
<files wp-config.php>
order allow,deny
deny from all
</files>
# Prevent access to wp-load.php file
<files wp-load.php>
order allow,deny
deny from all
</files>
# disable directory listing
Options All -Indexes

2) The wp-config.php file has a place called unique keys. If you have never touched it, you will see something like this.

define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');

This is very important. It encrypts cookies and password records with them. When you visit http://api.wordpress.org/secret-key/1.1/salt, WordPress will give you the necessary codes to add there. Copying and pasting are enough.

3) Use plugins as little as possible. They will slow down your site and increase their vulnerability to attack.

4) Get the themes and plugins as much as possible from reliable sources such as WordPress or code them yourself. Never use warez themes or plugins.

Most importantly, always update your WordPress.

HTTP Dersleri – Ders 5 – Güvenlik

HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

HTTP serisini takip ettiyseniz, artık HTTP güvenliği yolculuğuna çıkmaya hazırsınız demektir. Güzel bir yolculuk olacak, söz veriyorum.

Birçok şirket güvenlik ihlallerine maruz kalmıştır. Sadece birkaç önemli özelliği belirtmek için: Dropbox, Linkedin, MySpace, Adobe, Sony, Forbes ve daha birçokları kötü niyetli saldırıların son noktalarında. Birçok hesap ele geçirildi ve en azından birisinde hesabınız vardır.

Aslında şuradan kontrol edebilirsiniz, Have I Been Pwned.

E-posta adresim, güvenlik ihlalinin kurbanı olan 4 farklı web sitesinde bulundu.

Web uygulaması güvenliğinin pek çok özelliği vardır, bir makalede ele alınacak çok şey var, ancak en başından başlayalım. Önce HTTP iletişimimizi nasıl güvenli yapacağımızı öğrenelim.

Bu makalede, hakkında daha fazla bilgi edineceksiniz:

  • Gerçekten HTTPS’ye ihtiyacınız var mı?
  • HTTPS’nin temel kavramları
  • SSL-TLS
  • TLS el sıkışma
  • Sertifika ve Sertifika Yetkilileri
  • Sertifika zincirleri
  • HTTPS zayıf yönleri

Üzerinden geçilecek çok şey var, o yüzden hemen başlayalım.

Gerçekten HTTPS’ye ihtiyacınız var mı?

Düşünüyor olabilirsiniz: “Elbette bütün web sitelerinin korunması gerekmez”. Bir web sitesi hassas verilere hizmet etmiyorsa veya herhangi bir form gönderiminde bulunmuyorsa, yalnızca “Güvenli” yazan URL çubuğunda küçük yeşil işareti almak için sertifikalar satın almak ve web sitesini yavaşlatmak aşırı olacaktır.

Bir web siteniz varsa, mümkün olduğunca hızlı yüklenmesi çok önemlidir, dolayısıyla gereksiz şeyler yüklememeye çalışın.

İlk etapta korunması gerekmeyen web sitesinizi güvence altına almak için neden acımasızca HTTPS’ye taşıma sürecine girdiniz? Üstelik bunun parasını ödemeniz de gerekiyor.

Buna gerçekten değer mi bakalım.

HTTPS iletilerinizi şifreler ve MITM sorununu çözer

HTTP serisinin önceki bölümünde farklı HTTP kimlik doğrulama mekanizmaları ve güvenlik kusurları hakkında konuştuk. Hem temel hem de Digest kimlik doğrulamasının çözemediği sorun man-in-the-middle (ortadaki adam) saldırısıdır. Ortadaki adam, sizinle iletişim kurduğunuz web sitesi arasına kendisini yerleştiren kötü amaçlı bir programı temsil eder. Amacı orijinal mesajları her iki yönden de çevirmek ve değiştirilen mesajları tekrar iletmek suretiyle kendisini gizlemektir.

İletişimin orijinal katılımcıları, mesajlarının dinlendiğinden haberdar olmayabilir.

HTTPS, iletişimi şifreleyerek MITM saldırı sorununu çözer. Şimdi, bu, trafiğinizin artık dinlenemeyeceği anlamına gelmiyor. Bu, iletilerinizi dinleyen ve kesen herkesin içeriğini göremeyeceği anlamına gelir. Mesajın şifresini çözmek için anahtara ihtiyacı vardır. Bunun nasıl olduğunu tam olarak biraz sonra öğreneceğiz.

Hadi devam edelim.

Sıralama sinyali olarak HTTPS

Yakın zamanda Google, HTTPS’yi bir sıralama sinyali yaptı.

Bu ne anlama geliyor?

Bu, bir web yöneticisiyseniz ve Google sıralamanızı önemsiyorsanız, HTTPS’yi web sitenizde kesinlikle uygulamalısınız. Bazılarının kalite içeriği ve geri dönüş gibi işaretleri kadar güçlü olmasa da, kesinlikle önemlidir.

Bunu yaparak, Google, web yöneticilerine mümkün olan en kısa sürede HTTPS’ye geçme ve internetin genel güvenliğini artırma konusunda teşvik sağlar.

Tamamen ücretsizdir

Bir web sitesi için HTTPS’yi (SSL / TLS) etkinleştirmek için bir Sertifika Otoritesi tarafından verilen bir sertifikaya ihtiyacınız vardır. Yakın geçmişe kadar sertifikalar pahalıydı ve her yıl yenilenirdi.

Let’s Encrypt geliştiricilerine teşekkürler ki sertifikayı ücretsiz alabilmekteyiz. Cidden, onlar tamamen ücretsizdir.

Şifreleme sertifikalarının kolayca yüklenip, büyük bir şirket desteğinin verildiği harika bir topluluktur. Ana sponsorlarına bir göz atın ve onlara destek veren şirketlerin listesine göz atın. Birkaç tanesini tanıyabilirsiniz.

Let’s Encrypt, DV (Domain Doğrulama) ile çalışır. Her sertifikanın ömrü 90 gündür ve otomatik olarak yenilenir.

Her harika teknoloji gibi, kötü tarafı da var. Sertifika artık kolaylıkla bulunabildiğinden, Kimlik Avı web siteleri tarafından istismar ediliyor.

Her Şey Hızla İlgilidir

HTTPS kullanan siteler çok daha hızlı çalışmaktadır. httpvshttps.com‘ye bir göz atın.

Peki orada ne oldu? Neden HTTPS çok daha hızlıdır? Bu nasıl mümkün olabilir?

HTTPS, HTTP 2.0 protokolünü kullanmak için şarttır.

Ağ sekmesine bakarsak, HTTPS durumunda görüntülerin h2 protokolü üzerinden yüklendiğini göreceğiz. Ve akış çok farklı görünüyor.

HTTP 2.0 şu anda yaygın olan HTTP / 1.1’in halefidir.

HTTP / 1.1’e göre pek çok avantajı vardır:

  • Metinsel değil, ikili.
  • Tek bir TCP bağlantısı üzerinden birden fazla isteği paralel olarak gönderebileceği anlamına gelen tam çoğullama
  • HPACK sıkıştırmasını kullanarak yükü azaltır
  • Daha hızlı şifrelenmiş bağlantılar sağlayan yeni ALPN uzantısını kullanır
  • Ek gidiş dönüş sürelerini (RTT) azaltır, böylece web siteniz daha hızlı yüklenir

ve daha bir çoğu.

Şimdilik ikna olmadıysanız, muhtemelen bazı tarayıcıların şifrelenmemiş içeriğe karşı savaş başlattığını bilmelisiniz. Google, Chrome’un güvensiz web sitelerine nasıl davranacağını net bir şekilde açıklayan bir blog yayınladı.

Chrome sürüm 56’dan önce ve sonra nasıl göründüğü aşağıda belirtilmiştir.

Şimdi ise bu şekilde gözükmektedir;

Halen ikna olmadınız mı?

HTTPS’ye Geçmek Karmaşıktır

Bu aynı zamanda geçmiş zamanların kalıntılarıdır. HTTPS’ye geçmek, HTTP üzerinden yüklenen kaynakların yoğunluğu nedeniyle uzun süredir var olan web siteleri için daha zor olabiliyor olsa da, barındırma sağlayıcıları genellikle bu işlemi daha kolay hale getirmeye çalışmaktadır.

Birçok barındırma sağlayıcıları, HTTPS’ye otomatik geçiş sunar. Seçenekler panelinde bir düğmeyi tıklamak kadar kolay olabilir.

Web sitenizi HTTPS üzerinden kurmayı planlıyorsanız, barındırma sağlayıcısının önce HTTPS geçişi sunup sunmadığını kontrol edin. Veya kabuk erişimine sahipse, şifrelemek ve biraz sunucu yapılandırması ile kolayca kendiniz yapabilirsiniz.

Bu nedenle, HTTPS’ye geçmek için sebepler bunlar. Herhangi bir sebep yok mu?

Umarım, şimdiye kadar sizi HTTPS değerinden ikna etmiştimdir.

HTTPS’nin temel kavramları

HTTPS, Köprü Metni Aktarım Protokolü Güvenli (Hypertext Transfer Protocol Secure) anlamına gelir. Etkili bir şekilde istemci ve sunucu HTTP üzerinden ancak güvenli SSL / TLS bağlantısı üzerinden iletişim kurar.

Serinin önceki bölümlerinde, HTTP iletişiminin nasıl çalıştığını öğrendik, ancak SSL / TLS bölümü neydi ve hem SSL hem de TLS’yi neden kullanıyoruz?

Onunla başlayalım.

SSL-TLS

SSL (Güvenli Yuva Katmanı) ve TLS (Aktarım Katmanı Güvenliği) terimleri birbirlerinin yerine kullanılılabilirdi, ancak aslında, bugün birileri SSL sözü ettiğinde muhtemelen TLS demek istiyordur. TLS daha yeni bir teknolojidir.

SSL aslında Netscape tarafından geliştirildi, ancak sürüm 1.0 bugünün ışığını hiç görmedi. Sürüm 2.0 1995’te, 1996’da da 3.0 sürümünde tanıtıldı ve daha sonradan ne kadar uzun süre kullanıldılarsa da, halef TLS zaten yol almaya başlamıştı. Bu durum 2014’e kadar devam etti. TLS’den SSL’ye düşüş, sunucular tarafından desteklendi ve POODLE saldırısının bu kadar başarılı olmasının başlıca nedeni oldu.

Bundan sonra, SSL’ye geçiş tamamen devre dışı bırakıldı.

Sizinkini veya Qualys SSL Labs aracıyla başka bir web sitesini kontrol ederseniz, muhtemelen böyle bir şey göreceksiniz:

Gördüğünüz gibi, SSL 2 ve 3 hiç desteklenmiyor ve TLS 1.3 hala kapalı değil.

Ancak, SSL çok uzun süredir bu kadar yaygın olduğundan, çoğu insanın aşina olduğu ve şimdi hemen hemen her şey için kullanılan bir terim haline geldi. Dolayısıyla, TLS yerine SSL kullanan birisini duyduğunuzda, yalnızca tarihsel nedenlerden ötürü, SSL olduklarından değil.

Şimdi bunu bir kenara bıraktık, artık daha uygun olduğundan TLS’i kullanacağım.

Peki, istemci ve sunucu nasıl güvenli bir bağlantı kuruyor?

TLS El Sıkışması

İstemci ve sunucu arasındaki gerçek şifreli iletişim başlamadan önce, “TLS el sıkışması” adlı işlemi gerçekleştirirler.

Aşağıdaki gibi işler (çok basitleştirilmiştir, ek bilgiler için bağlantılar aşağıdadır).

Bağlantı kurulduktan sonra şifreli iletişim başlar.

Gerçek mekanizma bundan çok daha karmaşıktır, ancak HTTPS’yi uygulamak için el sıkışma uygulamasının tüm gerçek ayrıntılarını bilmeniz gerekmez.

Bilmeniz gereken şey, istemci ile sunucu arasında anahtarlar ve sertifikalar değiştiren ilk bir el sıkışması olmasıdır. Bu el sıkışma sonrasında, şifrelenmiş iletişim başlamaya hazırdır.

Tam olarak nasıl çalıştığını bilmek isterseniz, RFC 2246‘a bakabilirsiniz.

TLS el sıkışma görüntüsünde sertifikalar gönderiliyor, bu nedenle bir sertifikanın neyi temsil ettiğini ve nasıl verildiğini görelim.

Sertifika ve Sertifika Yetkilileri (CA’lar)

Sertifikalar, HTTPS üzerinden güvenli iletişimin çok önemli bir parçasıdır. Bunlar, güvenilir Sertifika Yetkililerinden biri tarafından verilir.

Dijital sertifika, bir web sitesini kullanırken web sitesinin kullanıcılarının güvenli bir şekilde iletişim kurmalarını sağlar.

Örneğin, blogumda gezinirken kullandığınız sertifika şöyle görünür:

Örneğin, Chrome kullanıyorsanız, Sertifikaları kendiniz incelemek için Geliştirici Araçları’ndaki (F12) Güvenlik sekmesine gidin.

İki şeyi işaret etmek istiyorum. İlki kırmızı kutuda, sertifikanın gerçek amacının ne olduğunu görebilirsiniz. Sadece doğru web sitesiyle konuştuğunuzdan emin olabilirsiniz. Birisi, örneğin iletişim kurduğunuzu düşündüğünüz web sitesini kimliğine bürünmüşse, kesinlikle tarayıcınız tarafından bilgilendirilirsiniz.

Meşru bir sertifika ile meşru bir siteye girmişseniz, kimlik bilgileriniz çalınmayacağı anlamına gelmez. Yani dikkatli olmalısınız. Sol üstteki Yeşil “Güvenli”, doğru web sitesi ile iletişim kurduğunuz anlamına gelir. Bu web sitesinin sahibinin dürüstlüğü konusunda hiçbir şey söylemez.

Genişletilmiş doğrulama sertifikaları, tüzel kişinin web sitesini denetlediğini kanıtlamaktadır. EV (Extended Validation) sertifikaların, internetin tipik kullanıcısı için faydalı olup olmadığı konusunda devam etmekte olan bir tartışma var. Bunları, URL çubuğunuzun sol tarafındaki özel metin ile tanıyabilirsiniz. Örneğin, twitter.com’a göz attığınızda şunları görebilirsiniz:

Bu, şirketlerinin web sitelerinin arkasındaki olduğunu kanıtlamak için EV (Extended Validation) sertifikası kullandıkları anlamına geliyor.

Sertifika zincirleri

Öyleyse neden tarayıcınız sunucunun geri gönderdiği sertifikaya güvenmeli? Herhangi bir sunucu bir parça dijital dokümantasyon gönderebilir ve bunun ne olmasını istediğinizi iddia edebilir.

Burada kök sertifikalar gelir. Genellikle sertifikalar zincirlenir ve kök sertifika makinenizin örtük olarak güvendiği belgedir.

Code-maze.com için şu şekildedir:

En düşük olan alan sertifika, üstündeki sertifika tarafından imzalanmış ve benzeri … Kök sertifikaya ulaşılıncaya kadar.

Ama kök sertifikayı kim imzalar?

Şey, kendisi imzalar.

Yayınlanan: AddTrust External CA Root, Yayınlayan: AddTrust External CA Root.

Makineniz ve tarayıcılarınız, göz attığınız alanın güvenilir olduğuna güvenmek için güvenilen kök sertifikaların bir listesine sahiptir. Sertifika zinciri herhangi bir nedenden dolayı kırılmışsa, siteniz bazı makinelerde güvensiz olarak görüntülenir.

Windows’ta güvenilen kök sertifikaların listesini kontrol etmek için windows ® düğmesini + R tuşlarına basarak ve certmgr.msc yazarak sertifika yöneticisini çalıştırın. Daha sonra güvenilen sertifikaları Güvenilen Kök Sertifika Yetkilileri bölümünde bulabilirsiniz. Bu liste Windows, IE ve Chrome tarafından kullanılır. Öte yandan Firefox, kendi listesini yönetiyor.

Sertifika değişimi yaparak, istemci ve sunucu, doğru tarafla konuştıklarını bildiklerini ve şifreli mesaj aktarmaya başlamasını isteyebilir.

HTTPS’in Zayıf Yönleri

HTTPS, site arkasında düzgün bir şekilde uygulanmadığında yanlış bir güvenlik hissi sağlayabilir. Müşteri bilgilerini ayıklamak için birçok farklı yol var ve birçok site HTTPS kullanıyor olsa bile veri sızdırıyor olabilir. Web sitesinden hassas bilgi almak için MITM dışında birçok başka mekanizma bulunmaktadır.

Web sitelerinin HTTPS üzerinden çalışmasına rağmen HTTP bağlantılarına sahip olabilmesi bir başka potansiyel sorunu. Bu MITM saldırısı için bir şans olabilir. Web sitelerini HTTPS’ye taşırken bu fark edilmeyebilir.

Ve bir de bonus olarak bir tane daha var: Güvensiz bir sayfadan erişilen oturum açma formları, güvenli bir sayfaya yüklenmiş olsalar bile potansiyel olarak tehlikeye girebilirler. Bu nedenle, bir websiteyi önlemek için tüm web sitesini güvende tutmak en iyisidir.

Referanslar;

Orijinali: https://www.code-maze.com/http-series-part-5/

WordPress Güvenlik Önlemleri

WordPress Kurulum Esnasındaki Güvenlik Önlemleri

1) Veritabanı kullanıcı şifresini güçlü oluşturun. Büyük harf, küçük harf, sayı ve özel karakter içermeli.

2) Veritabanı ismi ve kullanıcı ismi basit ve tahmin edilebilecek isimler yani database, db, admin, veritabanı gibi isimler olmasın.

3) WordPress, kurulum ekranında bir ön eki sormaktadır. Varsayılan olarak wp_ ön eki vardır. Bu veritabanındaki tabloların en ekidir. Varsayılandan farklı bir ön eki kullanın.

4) Kullanıcı adı ve şifre seçiminde admin, administrator’den farklı bir isim seçin. Bunlar varsayılan olduğu için ilk olarak denenmektedir. Aynı şekilde şifreyi de büyük harf, küçük harf, sayı ve özel karakter içerek şekilde oluşturun ki güçlü olsun. Mail adresi admin@siteadi.com gibi admin içeren bir mail olmasın.

WordPress Kurulumdan Sonraki Güvenlik Önlemleri

1) .htaccess dosyanıza aşağıdaki kodları ekleyin.

# .htaccess dosyasına erişimi engelle
<files .htaccess>
order allow,deny
deny from all
</files>
# sunucu imzasını kaldır
ServerSignature Off
# dosya yükleme boyutunu 10mb ile sınırlandır
LimitRequestBody 10240000
# wpconfig.php dosyasına erişimi engelle
<files wp-config.php>
order allow,deny
deny from all
</files>
# wp-load.php dosyasına erişimi engelle
<files wp-load.php>
order allow,deny
deny from all
</files>
# dizin listelemeyi iptal et
Options All -Indexes

2) wp-config.php dosyasında eşsiz anahtarlar kısmı denen bir yer vardır. Eğer oraya hiç dokunmadıysanız aşağıdaki gibi bir görünümle karşılaşacaksınız.

define('AUTH_KEY', 'eşsiz karakter kümenizi buraya yerleştirin');
define('SECURE_AUTH_KEY', 'eşsiz karakter kümenizi buraya yerleştirin');
define('LOGGED_IN_KEY', 'eşsiz karakter kümenizi buraya yerleştirin');
define('NONCE_KEY', 'eşsiz karakter kümenizi buraya yerleştirin');
define('AUTH_SALT', 'eşsiz karakter kümenizi buraya yerleştirin');
define('SECURE_AUTH_SALT', 'eşsiz karakter kümenizi buraya yerleştirin');
define('LOGGED_IN_SALT', 'eşsiz karakter kümenizi buraya yerleştirin');
define('NONCE_SALT', 'eşsiz karakter kümenizi buraya yerleştirin');

Burası çok önemlidir. Cookie ve parola kayıtlarını bunlarla şifrelemektedir. Buraya ekleyeceğiniz kodlar için http://api.wordpress.org/secret-key/1.1/salt adresini ziyaret ettiğinizde WordPress size gerekli kodları verecektir. Kopyalayıp yapıştırmanız yeterlidir.

3) Eklentileri mümkün olduğunca az kullanın. Hem sitenizi yavaşlatacaklardır hem de saldırıya açık olma durumlarını artıracaklardır.

4) Tema ve eklentileri mümkün olduğunca WordPress gibi güvenilir kaynaklardan edinin ya da siz yazın. Warez tema ya da eklentileri kesinlikle kullanmayın.

5) Bu yazımdaki güvenlik açığını kapatın.

En önemlisi ise WordPress‘inizi devamlı güncelleyin.

WordPress Xmlrpc Açığı Ve Çözümü

WordPress‘de mevcut olan bir açık vardır. Xmlrpc.php dosyası üzerinden saldırılar gerçekleşebiliyor. Normalde sadece POST ile gönderilen veriler varsa çalışan bu dosya kötü amaçlı kullanılabiliyor. DDoS saldırıları yapılabiliyor.

Açık olup olmadığını anlamak için sitenizde şöyle bir url’ye gidin “www.siteniz.com/xmlrpc.php”. Eğer aşağıdaki resimdeki gibi bir sonuç alıyorsanız sizde de bu açık mevcut demektir.

xmlrpc-securityBu açığı kapatmak için ise .htaccess dosyanıza aşağıdaki kodları eklemeniz yeterlidir.

# Begin Protect xmlrpc
RedirectMatch 403 /xmlrpc.php
# End Protect xmlrpc.php