Güvenlik Duvarı (Firewall) Ayarları E-Pin Scriptinde Nasıl Yapılandırılır?

Bir e-pin ve dijital ürün satış sitesi, normal bir kurumsal siteden farklı bir hedef taşır: üzerinde canlı bakiye, otomatik teslim edilen kod stoğu ve tedarikçi API bağlantıları vardır. Firewall (güvenlik duvarı) yanlış yapılandırıldığında saldırgan sadece siteyi çökertmekle kalmaz; doğrudan panelinize sızıp bakiyeyi boşaltabilir veya stok tablosunu kopyalayabilir. Bu yazıda bir e-pin scriptinde sunucu seviyesinde firewall'ın hangi katmanlarda, hangi mantıkla kurulması gerektiğini adım adım anlatıyoruz.

Bir e-pin sitesi firewall olmadan neden 24 saat bile dayanamaz?

E-pin siteleri, tarayıcı uzantıları ve otomatik tarama botları tarafından sürekli hedef alınan bir kategoridir. Sebebi basit: satılan ürün doğrudan paraya çevrilebilir bir koddur. Bir saldırgan admin paneline erişim sağladığında, önce stok tablosuna, ardından sipariş/bakiye kayıtlarına ulaşır. Firewall katmanı olmayan bir sunucuda şu senaryolar dakikalar içinde gerçekleşebilir:

• MySQL portu (3306) dışarıya açık bırakılmışsa, veritabanına doğrudan bağlantı denemeleri başlar.
• Admin giriş sayfasına IP kısıtlaması yoksa, otomatik script'ler binlerce şifre denemesi yapar.
• SSH portu varsayılan (22) ve şifre girişine açıksa, botnet taramaları saatlik onlarca deneme gönderir.
• Ödeme bildirim (webhook) uç noktası herkese açıksa, sahte "ödeme başarılı" istekleriyle bakiye yükleme denenir.

Bunların hiçbiri teorik değil — barındırma panellerindeki (cPanel, DirectAdmin, düz VPS) günlük saldırı logları bu denemelerle doludur. Firewall, bu trafiğin büyük kısmını daha uygulamaya ulaşmadan eler.

Hangi portlar açık kalmalı, hangileri kesinlikle kapatılmalı?

Kural basittir: sadece gerçekten kullanılan servisler dışarıya açık olmalı, geri kalan her şey varsayılan olarak reddedilmelidir (deny-by-default). Bir e-pin scripti için tipik port haritası şöyledir:

• 80 / 443 — HTTP/HTTPS, herkese açık kalmalı (Cloudflare proxy arkasında ise sadece Cloudflare IP aralıklarına açmak daha güvenlidir).
• 22 (SSH) — açık olmalı ama yalnızca sabit ofis/ev IP'sine, tercihen anahtar (key) tabanlı girişle; şifreyle giriş kapatılmalı.
• 3306 (MySQL) — dışarıya kapatılmalı, sadece localhost'tan (127.0.0.1) erişime izin verilmeli. Uzak bağlantı gerekiyorsa SSH tüneli kullanılmalı.
• 21 (FTP) — mümkünse tamamen kapatılıp SFTP'ye geçilmeli; açık kalacaksa IP kısıtlamalı.
• 6379 (Redis), 11211 (Memcached) — bu servisler kullanılıyorsa kesinlikle dışarıya kapalı olmalı; çoğu saldırı taraması bu portları hedef alır.

Pinova gibi kendi sunucunuza kurulan bir scriptte bu port ayarı barındırma sağlayıcısının değil, sizin sorumluluğunuzdadır. CSF (ConfigServer Security & Firewall) veya ufw ile bu liste tek bir yapılandırma dosyasında tutulabilir.

Brute-force ve DDoS saldırılarına karşı kurallar nasıl yazılır?

Port kapatmak tek başına yeterli değildir; açık bırakılan servislere yapılan tekrarlı (brute-force) denemeleri de sınırlamak gerekir. Pratikte iki katman çalışır:

• Fail2ban / CSF LFD: belirli bir sürede (örneğin 5 dakika) art arda 5 başarısız giriş denemesi yapan IP'yi otomatik olarak belirli bir süre (1-24 saat) engeller. Bu, admin panel giriş sayfası ve SSH için hayati önemdedir.
• Nginx/Apache seviyesinde rate limiting: aynı IP'den saniyede belirli sayıdan fazla istek geldiğinde 429 (Too Many Requests) döndürülür. Özellikle "kod sorgula", "sipariş sorgula" gibi formlar bu koruma olmadan otomatik tarama botlarının hedefi olur.

DDoS tarafında ise sunucu seviyesindeki firewall tek başına yeterli olmayabilir; hacimli saldırılarda Cloudflare gibi bir proxy katmanı devreye girmeli, gerçek sunucu IP'si gizlenmeli ve firewall sadece Cloudflare'in bilinen IP bloklarından gelen trafiği kabul edecek şekilde daraltılmalıdır.

Tedarikçi ve ödeme sağlayıcı IP'lerini whitelist etmezseniz ne olur?

Bir e-pin scriptinde firewall'ı sıkılaştırırken en sık yapılan hata, kendi altyapınızla konuşan servisleri de yanlışlıkla engellemektir. Turkpin veya Pinabi gibi tedarikçi API'leri stok senkronizasyonu ve otomatik teslimat için sunucunuza istek gönderir ya da sizin sunucunuz onlara istek atar; PayTR, Shopier gibi ödeme sağlayıcıları ise ödeme sonucu bildirimini (webhook/callback) sizin sunucunuza POST eder. Bu noktada iki yönlü düşünmek gerekir:

• Giden bağlantılar: sunucunuzun tedarikçi API adreslerine ve ödeme sağlayıcı sunucularına erişebildiğinden emin olun; aşırı sıkı bir "outbound" (çıkış) firewall kuralı stok çekme işlemini sessizce durdurabilir.
• Gelen bağlantılar: ödeme bildirim uç noktasını genel rate-limit kurallarından muaf tutmak gerekebilir, çünkü ödeme sağlayıcı sabit IP aralıklarından gelir ve bu istekler bloklanırsa sipariş "ödendi" durumuna hiç geçmez — müşteri parayı öder ama ürünü alamaz.

Bu yüzden whitelist listesi, kısıtlama kurallarından önce test edilmelidir. Canlıya geçmeden önce bir test ödemesi ve bir test stok senkronizasyonu ile firewall'ın bu trafiği kesip kesmediği doğrulanmalıdır.

WAF (Web Application Firewall) e-pin scriptinde gerçekten şart mı?

Klasik firewall port ve IP seviyesinde çalışır; ama SQL enjeksiyonu, XSS (cross-site scripting) veya kötü niyetli dosya yükleme gibi saldırılar HTTP isteğinin içeriğinde gizlidir ve port/IP kuralıyla yakalanamaz. Bunun için bir WAF (Web Application Firewall) katmanı gerekir. Pratikte iki seçenek öne çıkar:

• Sunucu seviyesi WAF (ModSecurity + OWASP kural seti): Apache/Nginx üzerine kurulur, bilinen saldırı imzalarını (örneğin form alanına ' OR 1=1 yazılması) tanıyıp engeller.
• Cloudflare WAF: DNS proxy zaten kullanılıyorsa, ek kurulum gerektirmeden aktif edilebilir; özellikle bot skorlama ve bilinen saldırı imzası filtreleme özellikleriyle e-pin siteleri için pratik bir ilk savunma hattıdır.

Bir e-pin scriptinde form alanları (sipariş sorgulama, kupon kodu girişi, bayi başvuru formu) doğrudan veritabanı sorgularıyla ilişkili olduğu için, WAF olmadan sadece "temiz kod yazmak" yeterli güvence sağlamaz — insan hatası her zaman ihtimal dahilindedir. WAF, kod seviyesindeki küçük bir açığın büyük bir veri sızıntısına dönüşmesini engelleyen ek bir kalkandır.

Firewall loglarını kim, ne sıklıkla okumalı?

Kurallar yazıldıktan sonra iş bitmez; firewall'ın "sessiz" çalışması aslında saldırıların engellendiğinin değil, kimsenin bakmadığının işareti olabilir. Düzenli log incelemesi şu soruları cevaplamalı:

• Son 24 saatte hangi IP'ler tekrarlayan şekilde engellendi? Aynı IP aralığından gelen yoğun trafik bir hedefleme kampanyasının işareti olabilir.
• Admin panel giriş denemeleri normalin üzerinde mi? Ani bir artış, saldırıya uğradığınızın erken sinyalidir.
• Ödeme webhook uç noktasına beklenmeyen kaynaklardan istek geliyor mu? Bu, sahte ödeme bildirimi denemesi olabilir.

Küçük ölçekli bir e-pin sitesinde bile bu kontrolü haftada bir kez, büyüyen bir sitede günlük yapmak makul bir sıklıktır. CSF gibi araçlar bu özet raporu e-posta ile otomatik gönderebilir; bu ayarı açık bırakmak, elle log taramaktan çok daha sürdürülebilirdir.