Sunucu Güvenlik Duvarı Kurulumu: Sunucuyu DDoS ve Botlara Karşı Kapatma

Sunucu güvenlik duvarı kurulumu, sunucuda yalnızca gerekli portları açık bırakıp gereksiz tüm erişimleri engelleme işlemidir; DDoS, brute force ve zararlı bot trafiğine karşı ilk savunma katmanını oluşturur. Pratikte hedef; SSH erişimini sınırlandırmak, web servislerini kontrollü açmak, şüpheli istekleri oran sınırlamasına almak, logları izlemek ve mümkünse CDN/WAF gibi üst katman korumalarla trafiği sunucuya ulaşmadan filtrelemektir.

Bir web sunucusunu internete açtığınız anda dakikalar içinde port taramaları, SSH denemeleri, zafiyet botları ve sahte kullanıcı ajanlarıyla karşılaşabilirsiniz. Özellikle WordPress, e-ticaret, panel, API veya oyun sunucusu çalıştıran yapılarda güvenlik duvarı yalnızca teknik bir tercih değil, süreklilik için zorunluluktur. Bu rehberde Linux sunucularda uygulanabilir, adım adım bir güvenlik duvarı mimarisi kuracağız; UFW, firewalld, nftables, Fail2ban, web uygulama güvenlik duvarı ve DDoS azaltma yaklaşımını birlikte ele alacağız.

Önemli bir gerçek ile başlayalım: Yerel sunucu güvenlik duvarı tek başına büyük hacimli DDoS saldırılarını durduramaz. 20 Gbps, 80 Gbps veya daha yüksek hacimli bir saldırı veri merkezine ya da ağ omurgasına ulaştığında, paketler sizin işletim sisteminizdeki kural setine gelmeden bant genişliğini doldurabilir. Bu nedenle doğru yaklaşım katmanlı güvenliktir: sağlayıcı seviyesinde DDoS koruması, CDN/WAF, işletim sistemi güvenlik duvarı, uygulama oran sınırlaması ve düzenli log analizi birlikte çalışmalıdır. Uygun altyapı seçimi için Hostragons VPS ve VDS sunucu çözümleri sayfasına, web sitesi tarafındaki güvenli barındırma seçenekleri için Hostragons web hosting paketleri sayfasına bağlantı verilebilir.

Sunucu Güvenlik Duvarı Ne İşe Yarar?

Sunucu güvenlik duvarı, ağ trafiğini kaynak IP, hedef IP, port, protokol, bağlantı durumu ve bazı durumlarda paket özelliklerine göre filtreleyen güvenlik katmanıdır. Basit bir örnekle; web siteniz için 80 ve 443 portları açık olmalı, fakat veritabanı portu olan 3306 internete açık olmamalıdır. SSH için 22 numaralı portu herkesin denemesine izin vermek yerine sadece sizin ofis IP adresinizden bağlantıya izin vermek daha güvenlidir.

Güvenlik duvarının temel amacı tüm saldırıları sihirli biçimde yok etmek değildir. Asıl hedef saldırı yüzeyini küçültmektir. Saldırı yüzeyi ne kadar küçükse, saldırganın deneyeceği seçenek o kadar az olur. Örneğin yeni kurulmuş bir Linux sunucuda SSH, web paneli, posta servisi, veritabanı, monitoring agent ve test servisleri aynı anda açık kalabilir. Bunların her biri ayrı bir risk üretir. İyi yapılandırılmış bir güvenlik duvarı, “varsayılan olarak reddet, ihtiyaç olanı izin ver” prensibiyle çalışır.

DDoS ve Bot Trafiğini Anlamak

DDoS Saldırıları Neden Farklıdır?

DDoS, yani dağıtık hizmet engelleme saldırısı, çok sayıda kaynaktan gelen yoğun trafikle hedef hizmeti erişilemez hale getirmeyi amaçlar. Saldırı bazen bant genişliğini doldurur, bazen sunucunun CPU ve RAM kaynaklarını tüketir, bazen de uygulama katmanındaki pahalı işlemleri tetikler. Örneğin saniyede 50.000 HTTP isteği alan küçük bir uygulama sunucusu, ağ hattı dolmasa bile PHP-FPM, Node.js veya veritabanı bağlantı havuzu nedeniyle yanıt veremez hale gelebilir.

Botlar Her Zaman Kötü müdür?

Hayır. Googlebot, Bingbot ve bazı izleme botları faydalıdır. Ancak zararlı botlar yönetim paneli taraması, açık dizin arama, form spam, içerik kopyalama, XML-RPC kötüye kullanımı, sahte kayıt oluşturma ve login denemeleri yapar. Bu nedenle bot yönetiminde amaç tüm botları engellemek değil, davranışa göre ayrım yapmaktır. Yüksek hata oranı, çok kısa sürede çok fazla istek, gerçek tarayıcı gibi davranmayan başlıklar ve şüpheli URL kalıpları önemli sinyallerdir.

Kuruluma Başlamadan Önce Kontrol Listesi

Canlı bir sunucuda güvenlik duvarı kuralı yazarken en büyük risk, kendinizi sunucudan kilitlemektir. Bu yüzden değişiklik yapmadan önce kısa bir hazırlık yapmak gerekir. Aşağıdaki kontrol listesi, üretim ortamlarında sık kullanılan güvenli bir başlangıç yaklaşımıdır.

• Aktif SSH oturumunu kapatmayın; ikinci bir terminal ile test yapın.
• Sunucu sağlayıcınızın konsol, VNC veya kurtarma erişimi sunduğundan emin olun.
• Mevcut açık portları listeleyin: ss -tulpn veya netstat -tulpn çıktısını inceleyin.
• Web, mail, DNS, veritabanı, panel ve izleme servislerinin hangi portları kullandığını not alın.
• IPv6 kullanıyorsanız IPv6 güvenlik duvarı kurallarını da planlayın.
• Önce allow yani izin kurallarını, sonra deny yani engelleme kurallarını uygulayın.
• Kural setinin kalıcı olduğundan emin olun; sunucu yeniden başlayınca kaybolmamalıdır.

Örneğin yalnızca web sitesi barındıran tipik bir sunucuda dışarıya açık olması gereken portlar çoğu zaman 80, 443 ve sınırlı SSH portudur. Eğer mail sunucusu çalışmıyorsa 25, 465, 587, 993 gibi portların açık olması gerekmez. Eğer veritabanı yalnızca aynı sunucu içinden kullanılıyorsa 3306 veya 5432 portları dış dünyaya kapalı kalmalıdır.

Hangi Güvenlik Duvarı Aracını Seçmelisiniz?

Linux dünyasında birden fazla araç vardır ve çoğu aynı çekirdek filtreleme altyapısını farklı kullanım kolaylıklarıyla yönetir. Yeni başlayanlar için UFW sade ve hızlıdır. Kurumsal ya da Red Hat tabanlı sistemlerde firewalld yaygındır. Daha ileri senaryolarda nftables modern ve esnek bir yapı sunar. Aşağıdaki tablo seçim yapmayı kolaylaştırır.

Adım Adım Sunucu Güvenlik Duvarı Kurulumu

1. Açık Portları ve Servisleri Belirleyin

İlk adım neyin açık olduğunu görmektir. Linux sunucuda ss -tulpn komutu hangi servislerin hangi portlarda dinlediğini gösterir. Örneğin nginx 0.0.0.0:80 ve 0.0.0.0:443 üzerinde dinliyorsa web trafiği tüm arayüzlerden kabul ediliyor demektir. MariaDB 0.0.0.0:3306 üzerinde dinliyorsa bu genellikle risklidir; çoğu web sitesinde veritabanı 127.0.0.1 üzerinde çalışmalıdır.

Burada pratik kural şudur: İnternetten erişilmesi gerekmeyen hiçbir servis 0.0.0.0 üzerinde dinlememelidir. Önce servis yapılandırmasını düzeltmek, sonra güvenlik duvarı ile kapatmak daha sağlıklı olur. Çünkü güvenlik duvarı devre dışı kalsa bile servis dış dünyaya açık olmamalıdır.

2. Varsayılan Politikayı Kapalı Hale Getirin

Güvenli kural setlerinde varsayılan gelen trafik reddedilir, giden trafik ise ihtiyaca göre serbest bırakılır. Bu yaklaşım, sonradan kurulan servislerin yanlışlıkla internete açılmasını önler. UFW kullanan bir Ubuntu sunucuda mantık şu şekildedir: önce SSH için izin verilir, sonra 80 ve 443 açılır, ardından varsayılan gelen politika deny yapılır ve güvenlik duvarı etkinleştirilir.

Örnek akış: SSH için yönetici IP adresinize izin verin, HTTP ve HTTPS trafiğini açın, gereksiz portları kapatın, sonra etkinleştirin. SSH iznini vermeden güvenlik duvarını açmak, özellikle uzak sunucularda en sık yapılan hatalardan biridir.

3. SSH Erişimini Sınırlandırın

SSH, saldırganların en çok hedeflediği servislerden biridir. Varsayılan 22 portu açık olan bir sunucu günde yüzlerce veya binlerce parola denemesi görebilir. En güvenli yaklaşım SSH erişimini belirli IP adresleriyle sınırlandırmaktır. Sabit IP kullanıyorsanız yalnızca ofis veya VPN IP adresinize izin verin. Sabit IP yoksa, en azından anahtar tabanlı kimlik doğrulama kullanın ve parola girişini kapatın.

• Root ile doğrudan SSH girişini kapatın.
• Parola yerine SSH key kullanın.
• AllowUsers veya AllowGroups ile kullanıcıları sınırlandırın.
• Fail2ban ile başarısız denemeleri otomatik engelleyin.
• Yönetim paneli kullanıyorsanız panel portunu da IP kısıtlamasına alın.

Port değiştirmek tek başına güvenlik sağlamaz, ancak otomatik bot gürültüsünü azaltabilir. Yine de gerçek koruma IP kısıtlaması, güçlü kimlik doğrulama ve log izleme ile sağlanır.

4. Web Portlarını Kontrollü Açın

Web sitesi yayınlayan çoğu sunucu için 80 ve 443 portları gereklidir. Ancak günümüzde 443 yani HTTPS ana trafik portu olmalı, 80 ise yalnızca HTTPS yönlendirmesi için kullanılmalıdır. SSL sertifikası olmayan siteler hem kullanıcı güvenini hem de SEO performansını olumsuz etkiler. Bu noktada Hostragons SSL sertifikaları bağlantısı, okuyucuyu güvenli HTTPS kurulumuna yönlendirmek için doğal bir iç link fırsatıdır.

Web portlarını açarken gerçek IP davranışına dikkat edin. Eğer CDN veya ters proxy kullanıyorsanız, sunucunuzun 80 ve 443 portlarını doğrudan tüm internete açmak yerine sadece CDN IP aralıklarından gelen trafiğe izin vermek daha güçlü bir koruma sağlar. Böylece saldırgan gerçek sunucu IP adresini bilse bile doğrudan web servisine erişemez.

5. Veritabanı ve Dahili Servisleri İnternete Kapatın

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB ve benzeri servislerin internete açık olması ciddi risk üretir. Redis için kimlik doğrulama eksikliği, Elasticsearch için yetkisiz indeks erişimi veya MongoDB için açık yönetim portu geçmişte çok sayıda veri sızıntısına yol açmıştır. Bu servisler mümkünse yalnızca localhost veya özel ağ üzerinden dinlemelidir.

Örneğin aynı sunucuda çalışan WordPress sitesi için veritabanının 127.0.0.1 üzerinden çalışması yeterlidir. Ayrı bir uygulama ve veritabanı sunucusu kullanıyorsanız sadece uygulama sunucusunun özel IP adresine izin verin. Genel internetten 3306 veya 5432 erişimi bırakmak, botların sürekli taradığı bilinen bir hatadır.

6. Fail2ban ile Brute Force Denemelerini Engelleyin

Fail2ban, log dosyalarını izleyerek tekrar eden başarısız giriş denemelerini tespit eder ve ilgili IP adresini geçici olarak engeller. SSH, nginx, Apache, Postfix, Dovecot, WordPress login ve bazı panel servisleri için jail tanımları yapılabilir. Örneğin 10 dakika içinde 5 başarısız SSH denemesi yapan IP adresini 1 saat engellemek basit ama etkili bir başlangıçtır.

Fail2ban yapılandırmasında aşırı agresif kurallar kullanırken dikkatli olun. Yanlış log kalıbı gerçek kullanıcıları da engelleyebilir. Bu nedenle ilk aşamada bantime değerini makul tutmak, logları izlemek ve daha sonra kademeli sertleştirme yapmak daha güvenlidir.

7. Rate Limiting ve Bağlantı Sınırları Ekleyin

DDoS ve bot trafiğine karşı işletim sistemi seviyesinde oran sınırlama yardımcı olabilir. Örneğin aynı IP adresinden saniyede aşırı sayıda yeni bağlantı geliyorsa sınır uygulanabilir. Web sunucusu tarafında nginx için limit_req ve limit_conn modülleri, Apache için mod_evasive veya benzeri çözümler kullanılabilir. Uygulama tarafında ise login, arama, sepet, ödeme ve API endpointleri için ayrıca oran sınırı koymak gerekir.

Somut bir örnek: Bir giriş sayfasında tek IP adresi için dakikada 10 deneme makul olabilir. Bir arama endpointinde saniyede 2-5 istek yeterli olabilir. API sunuyorsanız kullanıcı bazlı token limiti, IP limiti ve davranış analizi birlikte tasarlanmalıdır. Böylece saldırgan yalnızca IP değiştirerek tüm limiti aşamaz.

UFW ile Örnek Güvenli Kurulum Senaryosu

Ubuntu veya Debian tabanlı bir web sunucuda basit bir güvenli başlangıç senaryosu şu mantıkla kurulabilir: önce mevcut servisleri kontrol edin, yönetici IP adresinizden SSH erişimine izin verin, 80 ve 443 portlarını açın, gelen trafiği varsayılan olarak reddedin ve UFW durumunu doğrulayın. Eğer SSH erişiminiz sabit IP ile sınırlandırılamıyorsa, geçici olarak tüm IPlerden SSH izni verip daha sonra VPN veya sabit IP çözümüne geçebilirsiniz.

Örnek karar seti şöyledir: 203.0.113.10 yönetici IP adresi olsun. SSH yalnızca bu IPden gelsin. Web trafiği 80 ve 443 üzerinden herkes için açık kalsın. Veritabanı, Redis, panel ve test portları dışarıya kapalı olsun. Bu yapı küçük ve orta ölçekli birçok kurumsal web sitesi için iyi bir başlangıçtır. Domain ve DNS tarafında doğru yönlendirme yapmak için Hostragons domain sorgulama ve kayıt sayfasına iç bağlantı verilebilir.

firewalld ile Zone Mantığı

AlmaLinux, Rocky Linux ve RHEL tabanlı sunucularda firewalld yaygın kullanılır. firewalld zone kavramı ile çalışır. Public zone internete açık arayüzler için, trusted zone güvenilir özel ağlar için, drop zone ise istenmeyen trafiği sessizce düşürmek için kullanılabilir. En önemli nokta runtime ve permanent kuralların farkıdır. Runtime kural anında uygulanır ancak yeniden başlatmada kaybolabilir; permanent kural kalıcıdır ancak reload gerekebilir.

Kurumsal ortamlarda firewalld kullanırken servis tabanlı tanımlar işleri kolaylaştırır. Örneğin http ve https servislerini public zone üzerinde açabilir, ssh servisinin yalnızca belirli kaynak IP adreslerinden erişilebilir olmasını sağlayabilirsiniz. Yönetim ağı, yedekleme ağı ve kullanıcı trafiği ayrı arayüzlerdeyse zone yapısı güvenliği ve okunabilirliği artırır.

CDN, WAF ve Sağlayıcı Seviyesi DDoS Koruması

Yerel güvenlik duvarı paketleri sunucuya ulaştıktan sonra karar verir. Büyük DDoS saldırılarında ise amaç trafiği sunucuya gelmeden filtrelemektir. CDN, WAF ve sağlayıcı seviyesindeki DDoS koruması bu nedenle kritiktir. CDN statik içerikleri kenar lokasyonlarda sunar, WAF uygulama katmanındaki zararlı istekleri filtreler, sağlayıcı koruması ise ağ seviyesindeki hacimli saldırıları emer veya temizler.

İdeal modelde DNS kayıtlarınız CDN üzerinden geçer, gerçek sunucu IP adresiniz gizlenir, sunucu güvenlik duvarınız yalnızca CDN IP aralıklarından 80 ve 443 kabul eder. Yönetim portları ise VPN veya sabit IP üzerinden erişilebilir olur. Böyle bir model, doğrudan IPye saldırı ihtimalini azaltır ve bot trafiğini uygulamaya ulaşmadan önce elemenizi sağlar. Web güvenliği ve performans konularını birlikte ele alan içerikler için web sitesi hızlandırma ve güvenlik rehberleri bağlantısı kullanılabilir.

Botlara Karşı Uygulama Katmanı Önlemleri

Bot engelleme yalnızca IP ban listesinden ibaret değildir. Modern botlar proxy, mobil ağ, veri merkezi IPleri ve değişken kullanıcı ajanları kullanabilir. Bu nedenle davranış odaklı yaklaşım gerekir. Aynı IPden kısa sürede çok sayıda login denemesi, sürekli 404 üreten tarama, wp-login.php veya xmlrpc.php yoğunluğu, normal kullanıcıdan farklı tıklama paterni ve şüpheli başlıklar analiz edilmelidir.

• Login ve kayıt formlarında oran sınırlama kullanın.
• Gereksiz XML-RPC erişimini kapatın veya sınırlandırın.
• Yönetim panelini farklı URL, IP kısıtlaması ve çok faktörlü doğrulama ile koruyun.
• Şüpheli user-agent ve referer kalıplarını WAF seviyesinde filtreleyin.
• Formlarda CAPTCHA veya görünmez bot doğrulama mekanizmalarını dengeli kullanın.
• API endpointleri için anahtar, imza, kota ve zaman damgası kontrolleri ekleyin.

Bot yönetiminde kullanıcı deneyimini bozmamak önemlidir. Aşırı CAPTCHA, agresif engelleme veya hatalı ülke blokları gerçek müşterilerinize zarar verebilir. Bu nedenle ölçüm, test ve kademeli sıkılaştırma en sağlıklı yöntemdir.

Log İzleme ve Alarm Kuralları

Kurulumun bittiğini düşünmek yaygın bir hatadır. Güvenlik duvarı canlı bir sistemdir ve düzenli izlenmelidir. auth.log veya secure dosyasında SSH denemeleri, nginx access loglarında anormal istek yoğunluğu, error loglarında 404 ve 500 artışı, sistem metriklerinde CPU ve bağlantı sayısı takibi yapılmalıdır. Basit bir alarm bile saldırı başladığında dakikalar kazandırır.

Örnek eşik değerleri başlangıç için şöyle olabilir: 5 dakika içinde aynı IPden 100den fazla 404 isteği, 1 dakika içinde login sayfasına 20den fazla deneme, CPU kullanımının 10 dakika boyunca yüzde 90 üzerinde kalması, bağlantı sayısının normalin 3 katına çıkması. Bu eşikler her siteye göre değişir; önemli olan normal trafik profilinizi bilmektir.

Yaygın Hatalar ve Kaçınma Yolları

• SSH izni vermeden güvenlik duvarını etkinleştirmek: Uzak sunucuda erişimi kaybetmenize neden olabilir. Her zaman ikinci oturumla test edin.
• IPv6yı unutmak: IPv4 tarafı kapalıyken IPv6 üzerinden servis açık kalabilir.
• Veritabanını internete açık bırakmak: 3306, 5432, 6379 ve 9200 gibi portlar botlar tarafından sürekli taranır.
• CDN kullanıp gerçek IPyi açık bırakmak: Saldırgan CDNyi atlayarak doğrudan sunucuya saldırabilir.
• Kuralları belgelemeden değiştirmek: Acil durumda hangi kuralın ne işe yaradığını anlamak zorlaşır.
• Yedek erişim planı oluşturmamak: Yanlış kuralda konsol erişimi yoksa kesinti uzar.

Pratik Güvenlik Duvarı Politikası Örneği

Küçük bir kurumsal web sitesi için uygulanabilir özet politika şu şekilde olabilir: gelen trafik varsayılan olarak kapalıdır; 443 tüm ziyaretçilere açıktır; 80 yalnızca HTTPS yönlendirmesi için açıktır; SSH yalnızca VPN veya sabit yönetici IP adresinden erişilebilir; veritabanı localhost veya özel ağdadır; CDN kullanılıyorsa 80 ve 443 yalnızca CDN IP aralıklarına izinlidir; Fail2ban SSH ve web login denemelerini izler; günlük loglar merkezi bir izleme aracına gönderilir.

Orta ölçekli bir e-ticaret sitesinde buna ek olarak ödeme callback IPleri allowlist yapılır, yönetim paneli VPN arkasına alınır, API için kullanıcı bazlı kota uygulanır, WAF üzerinde SQL injection ve XSS kuralları etkinleştirilir, ülke veya ASN bazlı geçici filtreleme planı hazırlanır. Bu planın yazılı olması önemlidir; saldırı anında karar vermek yerine önceden belirlenmiş prosedürü uygulamak kesinti süresini azaltır.

Test Etme: Kurallar Gerçekten Çalışıyor mu?

Güvenlik duvarı kurulumundan sonra mutlaka test yapılmalıdır. Farklı bir ağdan açık port taraması yapın, SSH erişiminin yalnızca izin verilen IPden çalıştığını doğrulayın, web sitesinin HTTPS üzerinden erişilebilir olduğunu kontrol edin, veritabanı portunun dışarıdan kapalı olduğundan emin olun. CDN kullanıyorsanız gerçek sunucu IPsine doğrudan HTTP isteği göndererek engellendiğini doğrulayın.

Test sürecinde üretim sistemlerine zarar verebilecek agresif taramalar yapmayın. Amaç güvenli doğrulama yapmaktır. Ayrıca her değişiklikten sonra kural setini dışa aktarın veya not alın. Böylece bir problem yaşandığında önceki sağlıklı yapılandırmaya dönmek kolaylaşır.

Bakım ve Güncelleme Planı

Sunucu güvenliği tek seferlik bir kurulum değil, düzenli bakım sürecidir. Yeni servis eklendiğinde port ihtiyacı gözden geçirilmeli, eski servis kaldırıldığında ilgili izinler silinmeli, güvenlik güncellemeleri zamanında uygulanmalı ve loglar periyodik kontrol edilmelidir. Ayda en az bir kez açık port denetimi yapmak, üç ayda bir firewall kural setini gözden geçirmek iyi bir pratik başlangıçtır.

Ayrıca yedekleme planı güvenlik stratejisinin parçasıdır. DDoS saldırısı erişimi kesebilir, fakat fidye yazılımı veya yetkisiz erişim veri kaybına neden olabilir. Güvenli hosting, SSL, alan adı yönetimi ve yedekleme birlikte düşünülmelidir. Bu bağlamda güvenli hosting seçerken dikkat edilmesi gerekenler ve SSL sertifikası kurulumu nasıl yapılır içerikleri doğal devam bağlantılarıdır.

Sonuç

Sunucu güvenlik duvarı kurulumu, DDoS ve botlara karşı sunucuyu tamamen görünmez yapmaz; fakat saldırı yüzeyini ciddi biçimde azaltır, yetkisiz erişim riskini düşürür ve olaylara daha kontrollü müdahale etmenizi sağlar. En doğru sonuç; sağlayıcı seviyesinde DDoS koruması, CDN/WAF, sıkı port politikası, SSH kısıtlaması, Fail2ban, oran sınırlama ve düzenli log izlemenin birlikte uygulanmasıyla elde edilir.

Eğer yeni bir proje yayına alıyorsanız, güvenlik duvarı politikasını en başta planlamak sonradan düzeltmekten daha kolaydır. Hostragons üzerinde sunucu, hosting, domain ve SSL altyapınızı değerlendirirken güvenlik ihtiyaçlarınızı da birlikte düşünerek daha dayanıklı bir web ortamı oluşturabilirsiniz. İhtiyacınız varsa küçük bir kontrol listesiyle başlayın: açık portları kapatın, SSHyi sınırlandırın, HTTPSyi zorunlu yapın ve logları izleyin.

Sıkça Sorulan Sorular

Sunucu güvenlik duvarı DDoS saldırısını tamamen engeller mi?

Hayır. Yerel güvenlik duvarı küçük ölçekli ve bazı protokol düzeyindeki saldırıları azaltabilir, ancak büyük hacimli DDoS saldırılarında sağlayıcı seviyesinde DDoS koruması, CDN ve WAF kullanmak gerekir.

Web sunucusunda hangi portlar açık kalmalı?

Tipik bir web sunucusunda 80 ve 443 portları açık kalır. SSH portu yalnızca yönetici IP adreslerine izinli olmalıdır. Veritabanı ve dahili servis portları internete kapalı tutulmalıdır.

UFW mi firewalld mi kullanmalıyım?

Ubuntu ve Debian için UFW daha kolay bir başlangıç sunar. AlmaLinux, Rocky Linux ve RHEL tabanlı sistemlerde firewalld yaygındır. İleri seviye ve özel senaryolarda nftables tercih edilebilir.

Bot trafiğini sadece IP engelleyerek durdurabilir miyim?

Genellikle hayır. Modern botlar farklı IPler ve proxyler kullanır. IP engellemenin yanında oran sınırlama, WAF kuralları, davranış analizi, CAPTCHA ve uygulama bazlı kotalar kullanılmalıdır.

Güvenlik duvarı kurarken en büyük risk nedir?

En büyük risk yanlış kural nedeniyle kendi SSH erişiminizi kesmektir. Bu nedenle önce SSH izni tanımlanmalı, ikinci oturumla test yapılmalı ve sağlayıcı konsol erişimi hazır bulundurulmalıdır.