Web siteniz nasıl güvenli ve hızlı barındırılır?

Bir web sitesi farklı ülkelerde hızlı açılabilir, kullanıcı hesaplarını koruyabilir ve yoğun saatlerde işlem almaya devam edebilir. Bunun için her işin nerede yapılacağı baştan belirlenir. Ortak içerikler kullanıcıya yakın bir noktadan sunulur. Oturum, bakiye ve ödeme işlemleri ise yetkiyi ve kayıtları doğrulayan uygulama üzerinden yürür.

Barındırmayı, tarayıcıdan çıkan bir isteğin izlediği yol üzerinden ele alıyoruz. Önce içeriğin kullanıcıya nasıl ulaştığına, ardından uygulamanın isteği nasıl denetlediğine bakıyoruz. Son bölümlerde sunucu erişimi, Fail2Ban ve yedekten dönüş var.

Plesk ile başlayan barındırma düzeni

Bir topluluk sitesi, mağaza ve destek paneli; uygulama dosyaları, veritabanı ve bu ikisini çalıştıran hizmetlerle birlikte barındırılır. Biz bu düzenin yönetiminde Plesk kullanıyoruz. Alan adının siteye bağlanması, sertifika yönetimi, web sunucusu ve uygulamanın çalışma ayarları aynı yönetim katmanında ele alınır. Kullanıcının gördüğü mağaza bu düzenin dışarıya açılan yüzüdür.

Bir kullanıcı sayfayı açtığında herkese açık görseller ve stil dosyaları web sunucusundan sunulabilir. Oturum, bakiye veya destek talebi gibi kişisel işlemler uygulamada değerlendirilir, gerekli kayıtlar veritabanından alınır. Bu görevleri doğru yerde yürütmek, her ziyaret için aynı işi tekrar yapmayı azaltır. Örneğin ortak bir haber görseli önbellekten gelirken kullanıcının özel destek eki erişim denetiminden geçer.

Plesk üzerinden uygulamanın kullandığı PHP sürümü ve çalışma havuzları yönetilebilir. Veritabanı bağlantılarının, dosya izinlerinin ve yedeklerin de hizmetin ihtiyacına göre düzenlenmesi gerekir. Bir mağazanın düzgün barındırılması, yalnızca ana sayfanın açılmasını kapsamaz. Ödeme bildirimi geldiğinde siparişin kaydedilmesi, oyun sunucusuna teslimatın yürütülmesi ve kullanıcının destek kaydına ulaşabilmesi de aynı hizmetin parçalarıdır.

Web siteniz farklı ülkelerde nasıl hızlı açılır?

Ortak içerik farklı bölgelerden sunulurken oturumlu işlemler uygulamada yürütülür.

Trafiği, isteğin geldiği konuma uygun noktadan karşılayarak siteyi farklı ülkelerdeki kullanıcılara ulaştırıyoruz. Logo, stil dosyası ve herkese açık görseller gibi ortak içerikler kullanıcıya yakın bir noktadan sunulabilir. Böylece her görsel için ana sunucuya kadar gidip gelmek gerekmez. Bir ülkedeki kullanıcı için hızlı olan rota başka bir ülkede aynı sonucu vermeyebileceğinden ilk yanıt süresini farklı bölgelerden ölçmek gerekir.

Oturumlu panel, bakiye ve ödeme işlemleri yetkili uygulama üzerinden yürür. Örneğin aynı ürün görseli birden fazla ülkede önbellekten sunulabilir. Kullanıcı kredi yüklediğinde ise işlem ana sipariş kaydına işlenir ve yeni bakiye yalnızca kendi oturumunda gösterilir. Bölgesel trafik dağıtımı ile kullanıcıya özel verinin erişim sınırları böylece birlikte korunur.

Web istekleri sunucuya ulaşırken

ModSecurity kuralı nasıl okunur?

Plesk’te web uygulaması güvenlik duvarı için kullanılan ModSecurity, HTTP isteklerini yapılandırılmış kurallarla denetler. Kural seti, hangi alana bakılacağını, neyin eşleşme sayılacağını ve eşleşince hangi işlemin yapılacağını tarif eder. Bir kural yalnız istek yolunu ve yöntemini inceleyebilir. Başka bir kural form alanlarını, ayrıştırılmış JSON değerlerini veya yüklemenin yapısını denetleyebilir. İstek başlıkları erken aşamada okunur; gövde denetimi ise içerik ayrıştırıldıktan sonra yapılır. JSON veya dosya yüklemesi kullanan bir uç nokta için uygun ayrıştırıcının çalıştığını doğrulamak gerekir.

Örneğin herkese açık bir arama sayfası metin kabul ederken dosya yükleme adresi yalnız belirli türde bir POST isteği bekler. Arama kutusunda betik çalıştırmaya yönelik kalıplar denetlenir. Dosya yükleme adresinde ise yöntem, gövde boyutu ve dosya sayısı sınırlanır. Bir ModSecurity kuralının kimliği, eşleşen alanı ve seçilen eylem günlükte izlenebilmelidir. Yanıt tarafı denetleniyorsa hangi içerik türlerinin taranacağı da belirlenmelidir. Uygulamanın hata ekranında dışarı sızan bir yığın izi veya veritabanı hata ayrıntısı buna örnektir. Uygulama kendi hata yanıtlarını sade tutmalı, teşhis ayrıntılarını özel kayda yazmalıdır.

Tek kelimeye göre engellemek yerine isteği bağlamıyla değerlendirin

Bir destek mesajında “script” veya “select” kelimesinin geçmesi olağandır. Örneğin bir kullanıcı teknik hata metnini olduğu gibi gönderebilir. Denetim, kelimenin hangi alanda ve hangi yapının içinde bulunduğuna bakmalıdır. Bir düz metin alanına gelen betik etiketiyle bir destek mesajında metin olarak gösterilen kod örneği aynı sonucu doğurmaz. Kodlanmış girdilerin nasıl çözüldüğü de önemlidir. Güvenlik duvarı ile uygulama, aynı isteği birbirinden farklı yorumlarsa denetimden geçen değer uygulamada farklı bir anlama gelebilir.

OWASP Core Rule Set (CRS), anomali puanlama kullanılan kurulumlarda eşleşmeleri puana dönüştürür. Örneğin şüpheli bir başlıkla gövdedeki saldırı kalıbı aynı istekte birlikte puan toplayabilir. Toplam puan yapılandırılan eşiğe ulaştığında istek engellenir. Kural kimlikleri, puanın hangi eşleşmelerden geldiğini gösterir. Güvenlik duvarının önünde başka bir ağ katmanı bulunuyorsa her dinamik isteğin gerçekten denetlenen yoldan geçtiğini de test etmek gerekir.

Geçerli bir istek engellenirse hangi kural değişir?

Yeni kurallar, önce tespit modunda veya bir test ortamında gerçek iş akışlarıyla sınanmalıdır. Ürün kaydetme, destek mesajı, görsel yükleme ve imzalı ödeme bildirimi ayrı ayrı denenir. Bir form yanlışlıkla engellenirse saat, istek yolu ve kural kimliği üzerinden eşleşen alan bulunur. Örneğin yetkili bir tasarım düzenleyicisinin tek alanında gerçekten HTML bekleniyorsa istisna yalnız o yol, alan ve ilgili kural için tanımlanır. Böyle bir istisnada uygulamanın kendi yetki ve içerik denetimi sürmelidir.

Engelleme etkinleştirildiğinde geçerli işlem, bozuk istek ve yüksek trafikli senaryo yeniden denenmelidir. Günlüklerde kararın nedeni görülebilmeli, parola, ödeme verisi ve bağlantı anahtarları maskelenmelidir. İzlenecek sonuçlar arasında gerçek kullanıcıların aldığı hata oranı, engelleme sayısı ve yoğun saatlerde yanıt süresi bulunur. Bir kural seti saldırıyı durdururken ödeme bildirimini, destek mesajını ve dosya yüklemeyi de doğru biçimde tamamlatmalıdır.

Plesk ModSecurity rehberi · OWASP CRS anomali puanlama · OWASP CRS yanlış eşleşmeler ve kural istisnaları

Yönetilen doğrulamayı doğru yere koyun

WAF, bilinen saldırı kalıplarını isteğin yolu, gövdesi ve diğer sinyalleriyle birlikte değerlendirir. Şüpheli tarayıcı trafiği için süreli hız sınırı, Managed Challenge ve gerektiğinde engelleme adımları içeren iyi tanımlanmış bir kural seti bulunmalıdır. Aynı IP okul ağındaki onlarca kullanıcıya ait de olabilir. Önce yol, zaman aralığı ve başarısız işlem oranına bakın. Oyun eklentisinin teslimat adresine veya ödeme bildirimine tarayıcı doğrulaması koyarsanız otomasyon cevap veremez. Bu uçlarda imza, zaman damgası ve işleme özel hız sınırı kullanın.

Bir cuma akşamı tek bir IP’nin bir dakikada yüzlerce istek yaptığını varsayalım. İstekler herkese açık görsellere gidiyor, çoğu önbellekten karşılanıyor ve hatalı giriş sayısı artmıyorsa IP’yi hemen engellemek kullanıcıları oyundan soğutabilir. Aynı IP kısa aralıklarla yüzlerce farklı hesapta parola deniyorsa giriş yolu için hız sınırı anlamlıdır. Önce gözlem modunda hangi isteklerin eşleştiğini okuyun, sonra belirli süre için doğrulama veya engelleme uygulayın. Kuralın bitiş zamanı ve geri alma yolu belli olsun.

Uygulamada istek, oturum ve yetki denetimi

Kullanıcının tarayıcısından gelen form, bir oyun eklentisinin bağlantı isteği ve bir dosya yüklemesi sistemin girişinde karşılanır. Merkezi denetleyicide, istek ilgili işlemi başlatmadan önce kontrol katmanlarından geçer. İlk katman, aynı kaynağın kısa sürede sistemi meşgul edecek kadar istek göndermesini sınırlar. Genel trafikle veri değiştiren istekler için ayrı sınırlar uygulanabilir. Sınır dolduğunda istek beklemesi gerektiğini bildiren bir yanıtla durdurulur. Böylece sıradan bir sayfa görüntüleme ile sürekli destek talebi açma aynı bütçeyi paylaşmak zorunda kalmaz. Herkese açık sayfa, oturumlu panel ve ödeme bildirimi farklı kontrollerden geçer.

POST girişleri ve verinin sayfaya yansıtılması için kural seti

Merkezi denetleyici, form alanlarını iç içe diziler dâhil tarar. İlgili JSON uçlarında gövdeyi ayrıştırarak değerleri de denetler. Tarama öncesi normalleştirme, farklı biçimlerde kodlanmış aynı girdinin aynı kurallarla değerlendirilmesini sağlar. Gövde ve alan uzunluğu sınırları da kontrol edilir. Hız sınırı, bir kaynağın ne sıklıkta istek yapabileceğini belirler. İçerik denetimi ise tek bir isteğin içindeki veriye bakar. Güvenlik kuralları, istek girişinden verinin kullanıcıya gösterilmesine kadar bütün akışı kapsamalıdır. Her uç noktanın kabul ettiği istek yöntemi, alanlar, veri türleri, uzunluklar ve gövde boyutu belirlenmelidir. Beklenmeyen alanlar işleme alınmamalı, geçersiz istekler ilgili işlemi başlatmadan reddedilmelidir. Aynı kaynaktan tekrarlanan denemeler için işlem türüne uygun hız sınırları tanımlanmalıdır.

Bir POST isteğinin kontrol edilmesi tek başına yeterli değildir. İstek yetkili bir kullanıcıdan gelse bile başka bir kullanıcının kaydını değiştirmemelidir. Tarayıcı oturumuyla yürütülen veri değiştirme işlemlerinde CSRF denetimi uygulanmalıdır. Gelen değerler sorguya parametre olarak bağlanmalı, sayfaya yazılırken kullanıldığı bağlama göre kodlanmalıdır. İzin verilen zengin metin içeriği ise açık bir etiket ve öznitelik listesiyle doğrulanmalıdır. Böylece girişte saklanan bir değer, daha sonra görüntülendiği başka bir ekranda betik çalıştıran içeriğe dönüşmez.

Güven sınırını formdaki kutular belirlemez

Bir moderatör, destek talebi 471’e ekran görüntüsü ekliyor. Sunucu yalnız oturumun açık olduğuna bakarsa kullanıcı istek içindeki 471’i 472 yaparak başka bir kullanıcının talebine dosya ekleyebilir. Burada dosya kusursuz bir PNG bile olsa işlem yetkisizdir. Önce giriş yapan kişinin o talebe erişim hakkını, ardından ekleme yetkisini doğrulayın. Son olarak dosyanın kendisini inceleyin. Kimlik, işlem izni ve dosya türü üç ayrı kontroldür.

Kullanıcının yazdığı metni kayıt ederken amaç her özel karakteri silmek değildir. Bir destek mesajında 5 < 10 ifadesi olduğu gibi saklanabilmeli ve sayfada okunabilmelidir. Aynı değer HTML içinde gösterilirken metin olarak kodlanır, veritabanı sorgusuna parametre olarak girer. JSON yanıtına da JSON kodlayıcısıyla yazılır. Tek bir “temizle” fonksiyonuyla bütün bu bağlamları çözmeye çalışmak, hem gerçek mesajları bozar hem bazı ekranları açık bırakır.

Oturum çerezi başka bir IP’den kullanılırsa ne olur?

Web hesabı doğrulanırken sunucu oturum belirtecini, oturum açılışında kaydedilen IP adresini ve son geçerlilik zamanını birlikte kontrol eder. Birisi belirteci kopyalayıp farklı bir IP’den gönderirse oturum kaydı eşleşmez ve istek o hesapla yetkilendirilmez. Aynı kural, kullanıcının mobil veriden Wi-Fi’a geçişinde IP değişirse yeniden giriş gerektirebilir.

PHP oturum çerezinde HttpOnly kullanılır. HTTPS kullanıldığında Secure de etkinleştirilir. HttpOnly tarayıcıdaki JavaScript’in çerezi doğrudan okumasını sınırlar. Secure çerezin HTTPS üzerinden gönderilmesini sağlar. IP eşleştirmesi ise ele geçirilmiş bir belirtecin farklı bir adresten tekrar kullanılmasını sınırlar. Çerez ayarları, MVC çıktı kodlaması ve sunucudaki oturum doğrulaması bu yüzden birlikte çalışır.

Dosya yükleme ve güvenli depolama

Bir resmin gerçekten resim olduğunu nasıl anlarsınız?

Tarayıcının gönderdiği MIME başlığı değiştirilebilir. Yükleme hattında boyut sınırı koyun, izin verilen uzantıyı kontrol edin, dosya içeriğinden türü belirleyin ve görseli bir resim kütüphanesiyle açın. Piksel sayısını da sınırlayın. Küçük bir sıkıştırılmış dosya açıldığında çok fazla bellek tüketebilir. Yüklenen resmi yeniden kodlayıp sunucunun ürettiği adla saklayın. Yükleme dizininde PHP çalıştırılmamalı, özel dosyaların indirilmesinde sahiplik kontrolü yapılmalıdır.

Çift uzantı ve sistemin ürettiği dosya adı

Bir dosyanın adı resim.php.png olabilir. Sonunda PNG yazması içerideki verinin resim olduğunu kanıtlamaz. Yükleme sırasında dosya türünün ve görsel yapısının doğrulanması bu yüzden önemlidir. Gerçek bir PNG doğrulamayı geçerse desteklenen görsel kayıt akışlarında özgün dosya adı yerine sistemin ürettiği kimlik kullanılır. Örneğin saklanan dosya 8d7c42f1.png biçiminde tek bir görsel uzantısıyla adlandırılır. Kullanıcının dosya adına eklediği parçalar sunucudaki dosyanın adını belirlemez.

Adın değiştirilmesi, içeriği doğrulama ve yükleme alanında çalıştırmayı engelleme kontrolleriyle birlikte anlam kazanır. Yalnızca dosyanın adını kısaltmak, resim gibi gösterilen çalıştırılabilir bir içeriği güvenli hâle getirmez. Doğrulanan görselin yeniden kodlanması ve yalnızca beklenen türde sunulması da yükleme hattının bir parçasıdır.

Yükleme bileşeni, PHP ve PHTML gibi yorumlanabilir uzantıların yanında CGI, shell betiği, JavaScript ve PHAR gibi türleri de çalıştırılabilir içerik olarak ele alır. Genel dosya işleyicisindeki betik koruması, bu türleri düz metin olarak ele alıp dosya adına .txt ekleyebilir. Görsel yükleme alanı ise kendi izinli MIME listesine uymayan dosyayı reddeder. Böylece genel dosya işleyicisinin bir metin dosyasını saklayabilmesi, aynı dosyanın görsel olarak kabul edileceği anlamına gelmez.

SVG içine saklanan betikler nasıl ele alınır?

SVG, çizimi metin tabanlı bir yapıyla tarif eder. Bu yapı içine betik, olay tetikleyen öznitelik veya tehlikeli bir bağlantı eklenebilir. Dosya ekranda küçük bir logo gibi görünürken içinde sayfa davranışını değiştirecek içerik taşıyabilir. Bu nedenle sistem, SVG’nin içeriğini de inceler. Betik etiketleri, olay işleyicileri, tehlikeli bağlantı şemaları ve gömülü etkin içerikler kontrol edilen örneklerdir. Uygun olmayan yükleme işleme alınmadan engellenir.

Yükleme alanının görevi de önemlidir. Sıradan kullanıcı görseli alanıyla, yetkili kişinin tasarım varlığı eklediği alan aynı dosya politikasına sahip olmak zorunda değildir. İncelenen koruma akışında genel yükleme kısıtları ve belirli tasarım alanlarına özgü kontroller birlikte bulunur. Bu, her SVG’nin kabul edildiği anlamına gelmez; izin verilen alanda bile dosyanın içeriği denetlenir.

Yükleme tamamlandığında dosyaya kim ulaşabilecek?

Herkese açık bir görsel kamuya açık olabilir, destek talebindeki ekran görüntüsü ise kullanıcının e-posta adresini içerebilir. Her ikisi de resim olsa bile depolama ve sunma kuralları aynı olmamalıdır. Destek ekini web kökünün dışında tutun, indirme isteğinde kullanıcının hâlâ ilgili talebe erişimi olduğunu denetleyin. Tahmin edilmesi zor bir dosya adını tek başına erişim kontrolü olarak kullanmayın. Herkese açık görseli ise yeniden kodlanmış, çalıştırılamayan bir görsel olarak sunabilirsiniz.

Önizleme üretimi sırasında bir hata olursa kısmen yazılmış dosyanın herkese açılmaması gerekir. Geçici alana kaydedip doğrulamadan geçen çıktıyı son adına taşıyın. Boyut limitini hem web sunucusunda hem PHP tarafında ayarlayın. Örneğin uygulama 4 MB sınırı koyarken önündeki sunucu çok daha büyük gövdeleri kabul ediyorsa, reddedilecek dosya bile bant genişliğini ve geçici depolamayı tüketir. Limiti aşan istekte kullanıcıya anlaşılır bir mesaj verin ki aynı dosyayı tekrar tekrar denemesin.

MVC şablonları ve SFTP değişiklikleri

MVC ile şablon ve uygulama kodu nasıl ayrılır?

Şablonlarımızda MVC kullanıyoruz. Bir mağaza sayfası açıldığında denetleyici isteği karşılar ve hangi kayıtlara erişilebileceğini belirler. Veri katmanı ürünleri ve fiyatları getirir. Görünüm ise kendisine verilen ürün adı, fiyat ve stok bilgisiyle sayfayı üretir. Bu ayrım sayesinde bir temanın ürün kartını veya liste düzenini değiştirmek için ödeme akışını ya da veritabanı sorgusunu değiştirmek gerekmez.

Düzenlenebilir tema ve panel dosyaları sunum katmanına aittir. Şablon denetleyicisi yürütülebilir PHP etiketlerini, betik yorumlayıcısı başlıklarını ve görünüm içine eklenmiş doğrudan SQL kalıplarını engeller. Dosya adı .php ile bitse bile içerik bu kurallara tabidir. Şablon motoru, doğrulanmış şablonu kendi çalışma biçimine derler. Dinamik veriyi sunum tarafına yetkili arka uç bileşeni verir. Ham çıktı direktifi kısıtlanır, varlık yolları da göreli ve izinli dizinlerle sınırlanır.

Bir tema destek talebinin başlığını gösterebilir. Başlığın hangi kullanıcıya gösterileceğine ve veritabanından hangi kayıtların çekileceğine arka uç karar verir. Tema dosyasına doğrudan sorgu, sunucudan dosya okuma veya dışarıya ağ bağlantısı açma yetkisi verilirse bir tasarım değişikliğinin etkisi mağazanın verilerine kadar uzanır.

MVC, kullanıcı girdisi sayfaya yansıdığında ne yapar?

Bir kullanıcı arama kutusuna yazdığı değeri sonuç sayfasında tekrar görebilir. Girdi aynı yanıtta gösteriliyorsa yansıyan XSS riski vardır. Bir destek mesajı kaydedilip daha sonra başka bir ekranda gösterildiğinde ise saklanan XSS riski doğar. Her iki durumda da tarayıcının veriyi nasıl yorumlayacağını, çıktının üretildiği MVC görünümü belirler.

Şablon derleyicisi standart değerleri HTML çıktısı için işler, özel karakterleri ve tırnakları kodlar. Örneğin bir girdideki <script>, HTML metin alanına yazıldığında kullanıcıya metin olarak görünür. Şablonun ham değer direktifi de kaynak denetiminde engellenir. Zengin HTML gereken alanlarda açıkça yetkilendirilmiş arka uç blokları kullanılır. Bir değer URL olarak kullanılacaksa izinli bağlantı şeması, JavaScript’e veri olarak aktarılacaksa güvenli JSON kodlaması ayrıca uygulanmalıdır.

SFTP ile düzenlenen şablon nasıl devreye alınır?

SFTP eşitlemesinde dosya önce tema için ayrılmış çalışma kopyasına gelir. Eşitleme katmanı dosyanın ilgili temaya ait olduğunu ve düzenlenebilir bir yolda bulunduğunu kontrol eder. Yol çözümlemesi, çalışma alanının dışına çıkan dizin geçişlerini ve hedefi dışarıda kalan bağlantıları engeller. Daha eski bir SFTP kopyasının panelde yapılmış yeni kaydı ezmemesi için dosya güncelliği de karşılaştırılır.

Çalışma kopyası etkin şablona alınmadan önce içeriği yeniden taranır. Shell çağrısı, dosya okuma veya dizin listeleme, ortam değişkenlerine erişim, cURL ve soket işlemleri bu katmanda kontrol edilen örneklerdir. Engellenen değişiklik etkin şablona yazılmaz. SFTP ile geçerli bir oturum açılması dosya aktarımına izin verir. Sitede o dosyanın devreye alınmasına ise şablon denetimi karar verir.

Bir eklentiye hangi çalışma yetkileri verilmeli?

Sunucu tarafında çalışan bir eklentinin yetkisi yaptığı işle sınırlı olmalıdır. Bir eklenti ürün listesini biçimlendiriyorsa dosya izinlerini değiştirmeye veya dışarıya bağlantı açmaya ihtiyacı yoktur. Kısıtlar belirlenirken aynı yetkiye ulaşan farklı yollar birlikte ele alınmalıdır. Bir HTTP istemcisi sunucunun erişebildiği bir adrese istek gönderebilir. Bir süreç başlatma yetkisi ise işletim sistemine komut iletir. Bu yetkiler ayrı ayrı sınırlandırılmalıdır. Kod incelemesine ek olarak süreç izinleri, dosya erişimi ve ağ çıkışı da eklentinin göreviyle sınırlı tutulmalıdır.

Sunucu erişimi ve bağlantı bilgileri

Veritabanı parolası nerede kullanılır?

Uygulama, veritabanına bağlanabilmek için geçerli bir parolaya ihtiyaç duyar. İncelediğimiz bağlantı akışında parola sunucuda şifreli olarak saklanır ve bağlantıyı kuran uygulama süreci tarafından çözülür. Böylece bir yapılandırma kaydını görmek, tek başına veritabanı parolasını okumaya yetmez.

Yönetim ve destek ekranları, bağlantının çalışıp çalışmadığı gibi işlem için gerekli bilgileri göstermeli. Parolanın açık değeri bu ekranlarda veya hata yanıtlarında yer almamalı. Çözme anahtarı ile şifreli kayıt ayrı tutulmalı ve anahtara erişim bağlantıyı kuran süreçle sınırlandırılmalı. Bu erişim ayrımı, günlük destek işlemlerinde parolayı görme ihtiyacını ortadan kaldırır.

Plesk’te Fail2Ban ve erişim korumaları

Linux üzerinde Plesk’te etkinleştirilebilen Fail2Ban, seçili hizmetlerin günlüklerini izler. Her hizmet için tanımlanan kural hangi kayıtların sayılacağını, kaç denemenin hangi süre içinde eşiği dolduracağını ve engelin ne kadar süreceğini belirler. Örneğin SSH’ye aynı IP’den kısa aralıklarla başarısız girişler gelirse, ilgili kural o IP’nin erişimini güvenlik duvarında geçici olarak kesebilir. Plesk paneli, SSH ve posta gibi hizmetler farklı günlükler ve kurallarla izlenebilir.

Plesk’in yerleşik giriş koruması panel ve API’de art arda gelen başarısız girişleri sınırlar. Yönetici erişimi ayrıca belirli IP adreslerine veya ağlara açılabilir. Veritabanında ise uzaktan bağlantı gerekmeyen hesaplar yerel erişimle sınırlandırılabilir. Ayrı bir uygulama sunucusu bağlanacaksa ilgili veritabanı hesabına yalnız gerekli kaynaktan erişim verilir.

ModSecurity, bir HTTP isteğini içeriğine göre değerlendirir. Fail2Ban ise hizmet günlüklerinde görülen olaylara göre IP düzeyinde işlem yapar. Aynı IP’yi birden çok kişi paylaşabileceği için eşik ve engel süresi hizmete göre ayarlanmalı, engeller günlüklerden izlenmelidir.

Plesk Fail2Ban ve giriş koruması · Yönetici erişim kısıtları · Veritabanı erişim kuralları

Yoğunluk, yedek ve geri dönüş

Plesk, Docker ve gerçekten hızlı açılan sayfa

Plesk üzerinden siteler için ayrı PHP-FPM havuzları ve bellek sınırları yönetilebilir. Docker kullanılan bir kurulumda işlemci ve bellek limitleri, salt okunur uygulama dosyaları ve ayrı hizmet kimlikleri bir işin etkisini sınırlar. Ana sayfanın hızını ise somut işler belirler: görsel boyutları, veritabanı sorguları ve ilk yanıtı bekleten işlemler. Genel sayfaları önbelleğe alın, kullanıcının özel panelini ortak önbelleğin dışında tutun. Yük testinde ortalama yanında en yavaş yüzde beşlik yanıtları ve kuyrukta bekleyen PHP isteklerini izleyin.

Bir konteyner daha açmadan önce neyi ölçmeli?

Zonely’de hedefimiz her isteğin mümkün olduğunca az kaynak kullanarak tamamlanması. İşlemci süresini, RAM kullanımını, disk ve ağ erişimini ve takas alanına yazılan veriyi birlikte izliyoruz. Aynı sorguyu gereksiz yere çalıştırmamak işlemciyi ve diski rahatlatır. Önbelleği sınırlı tutmak RAM tüketimini dengeler. Bir isteği daha az bellekle tamamlamak için sürekli takas alanına başvurmak ise yanıtı uzatabilir. Bir değişikliğin işe yarayıp yaramadığını kaynak tüketimiyle birlikte yoğunluktaki yanıt süresi ve hata oranı gösterir.

Kullanıcılar “site dondu” dediğinde ilk ayrım yanıtın nerede beklediğidir. Herkese açık sonuç sayfası hızlı, giriş yapmış kullanıcının paneli yavaşsa kıyaslamaya aynı anda çalışan SQL sorgularından başlayın. Statik resim de yavaşsa ağ, disk veya sunucu kapasitesi ayrıca incelenmelidir. PHP havuzundaki bütün çalışanlar yavaş bir dış servisten yanıt bekliyorsa CPU kullanımı düşük görünse bile yeni istekler sırada kalır. Çalışan sayısını artırmak veritabanına daha fazla eşzamanlı sorgu göndererek darboğazı büyütebilir.

Örneğin sonuç tablosunu her kullanıcı için yeniden hesaplamak yerine turnuva turu bittiğinde bir kez hesaplayıp kısa süreyle ortak sunabilirsiniz. Buna karşılık “hesabım” sayfası ve sepet kullanıcıya özeldir. Önbellek kuralını değiştirdikten sonra iki farklı test hesabıyla aynı adresi açın. İkinci kullanıcı ilk kullanıcının adını, bakiyesini veya sepetini görüyorsa performans uğruna veri açığa çıkmıştır. Testi sadece sayfanın açılış süresine bakarak tamamlamayın.

Yedek geri geldiğinde mağaza hangi saatte kalır?

Sabah 03.00 yedeğine dönüp öğlen yapılan ödemeleri kaybettiğinizi düşünün. Sağlayıcı parayı almış ve oyuna birkaç ödül teslim edilmiş olabilir. Eski veritabanındaki kuyruğu hemen çalıştırmak bazı ödülleri ikinci kez dağıtabilir. Geri yüklenen mağazayı önce izole ortamda açın. Yedekten sonraki ödeme ve teslimat kimliklerini karşılaştırıp eksik siparişleri belirleyin, sonra kuyruğu yeniden başlatın. Bir topluluk sitesi için kurtarma provası tam da bu nedenle yalnız “dosya geri geldi” kontrolünden daha değerlidir.

Son prova basittir: yanlış türde dosya gönderin, geçerli küçük bir fotoğraf yükleyin ve bu sırada normal bir kullanıcının sonuç tablosunu açın. Ardından yedeği ayrı bir ortama geri yükleyin. Bu dört işlem, bir koruma kuralının kullanıcıyı engelleyip engellemediğini ve gerçek bir olaydan sonra neyi kurtarabileceğinizi gösterir.

OWASP dosya yükleme rehberi · Cloudflare doğrulama sayfaları