Server Təhlükəsizlik Divarının Qurulması: Serverinizi DDoS və Bot Hücumlarından Qorumaq

Server təhlükəsizlik divarının qurulması, serverdə yalnız zəruri portların açıq saxlanılması və lazımsız bütün girişlərin bloklanması deməkdir; bu, DDoS, brute force və zərərli bot trafikinə qarşı ilkin müdafiə qatını təşkil edir. Praktikada məqsəd; SSH girişini məhdudlaşdırmaq, veb xidmətlərini nəzarətdə açmaq, şübhəli sorğuları sürət məhdudiyyətinə salmaq, logları izləmək və mümkündürsə CDN/WAF kimi yüksək səviyyəli qoruma vasitələri ilə trafikin serverə çatmadan süzülməsini təmin etməkdir.

İnternetə açılan hər hansı bir veb server dərhal port skanları, SSH girişi cəhdləri, zəiflikləri yoxlayan botlar və saxta istifadəçi agentləri ilə üzləşə bilər. Xüsusilə WordPress, e-ticarət, idarə paneli, API və ya oyun serverləri işlədən mühitlərdə təhlükəsizlik divarı yalnız texniki seçim deyil, davamlılıq üçün zəruridir. Bu bələdçi Linux serverlərdə addım-addım praktik təhlükəsizlik divarı quruluşunu təqdim edir; UFW, firewalld, nftables, Fail2ban, veb tətbiqi təhlükəsizlik divarı və DDoS azaldılması yanaşmalarını birlikdə müzakirə edəcəyik.

Vacib bir həqiqətlə başlayaq: Lokal server təhlükəsizlik divarı təkbaşına yüksək həcmli DDoS hücumlarını dayandıra bilməz. 20 Gbps, 80 Gbps və ya daha yüksək həcmli hücumlar data mərkəzinə və ya şəbəkə infrastrukturuna çatdıqda, paketlər əməliyyat sisteminizdəki qayda dəstinə gəlməzdən əvvəl genişlik tutumu dolur. Buna görə düzgün yanaşma çoxsəviyyəli təhlükəsizlikdir: provayder səviyyəsində DDoS qoruması, CDN/WAF, əməliyyat sistemi təhlükəsizlik divarı, tətbiqdə sürət məhdudiyyəti və müntəzəm log analizinin birlikdə işləməsi vacibdir. Uyğun infrastruktur seçimi üçün Hostragons VPS və VDS Server həlləri səhifəsinə, sayt tərəfi üçün təhlükəsiz hosting seçimləri üçün isə Hostragons veb hosting paketləri səhifəsinə baxa bilərsiniz.

Server Təhlükəsizlik Divarı Nə İşə Yarar?

Server təhlükəsizlik divarı, şəbəkə trafikini mənbə IP, təyinat IP, port, protokol, əlaqə vəziyyəti və bəzi hallarda paket xüsusiyyətlərinə görə filtr edən təhlükəsizlik təbəqəsidir. Sadə nümunə ilə; saytınız üçün 80 və 443 portları açıq olmalıdır, lakin verilənlər bazası portu olan 3306 internetə açıq olmamalıdır. SSH üçün 22 nömrəli portu hər kəsin sınamasına icazə verməkdənsə, yalnız ofisinizin IP ünvanından bağlantıya icazə vermək daha təhlükəsizdir.

Təhlükəsizlik divarının əsas məqsədi bütün hücumları sehrli şəkildə aradan qaldırmaq deyil. Əsas hədəf hücum səthini kiçiltməkdir. Hücum səthi nə qədər kiçikdirsə, hücum edən şəxsin sınaqdan keçirəcəyi variantlar bir o qədər az olur. Məsələn, yeni qurulmuş Linux serverdə SSH, veb panel, poçt xidməti, verilənlər bazası, monitorinq agenti və test xidmətləri eyni anda açıq qala bilər. Bunların hər biri ayrıca risk yaradır. Yaxşı konfiqurasiya edilmiş təhlükəsizlik divarı "defolt olaraq rədd et, ehtiyac olanı icazə ver" prinsipinə əsaslanır.

DDoS və Bot Trafikini Anlamaq

DDoS Hücumları Niyə Fərqlidir?

DDoS, yəni paylanmış xidmətin əlçatmaz edilməsi hücumu, çoxlu mənbələrdən gələn intensiv trafiklə hədəf xidmətin əlçatmaz olmasını təmin etməyi məqsəd qoyur. Hücum bəzən genişlik tutumunu doldurur, bəzən serverin CPU və RAM resurslarını yorar, bəzən isə tətbiq qatında bahalı əməliyyatları tetikler. Məsələn, saniyədə 50.000 HTTP sorğusu alan kiçik bir tətbiq serveri, şəbəkə xətti dolmasa belə PHP-FPM, Node.js və ya verilənlər bazası bağlantı hovuzu səbəbindən cavab verə bilməz hala gələ bilər.

Botlar Həmişə Zərərli Olurmu?

Xeyr. Googlebot, Bingbot və bəzi izləmə botları faydalıdır. Ancaq zərərli botlar idarəetmə paneli skanları, açıq kataloq axtarışları, form spamları, məzmun oğurluğu, XML-RPC istismarları, saxta qeydiyyatlar və giriş cəhdləri edir. Buna görə bot idarəsində məqsəd bütün botları bloklamaq deyil, davranışa görə fərqləndirməkdir. Yüksək səhv nisbəti, qısa müddətdə çox sayda sorğu, gerçək brauzer kimi davranmayan başlıqlar və şübhəli URL nümunələri əsas siqnallardır.

Quruluşa Başlamazdan Əvvəl Yoxlama Siyahısı

Canlı serverdə təhlükəsizlik divarı qaydaları hazırlayarkən ən böyük risk, özünüzü serverdən kənarlaşdırmaqdır. Buna görə dəyişiklik etməzdən əvvəl qısa hazırlıq etmək zəruridir. Aşağıdakı yoxlama siyahısı istehsal mühitlərində geniş istifadə olunan təhlükəsiz başlama yanaşmasıdır.

• Aktiv SSH sessiyasını bağlamayın; ikinci terminal ilə test aparın.
• Server provayderinizin konsol, VNC və ya bərpa giriş imkanı təmin etdiyindən əmin olun.
• Mövcud açıq portları siyahıya alın: ss -tulpn və ya netstat -tulpn komutlarının nəticələrini yoxlayın.
• Veb, poçt, DNS, verilənlər bazası, panel və monitorinq xidmətlərinin hansı portlarda işlədiyini qeyd edin.
• IPv6 istifadə edirsinizsə, IPv6 təhlükəsizlik divarı qaydalarını da planlaşdırın.
• Əvvəlcə allow (icazə) sonra deny (bloklama) qaydalarını tətbiq edin.
• Qayda dəstinin qalıcı olduğuna əmin olun; server yenidən başladıqda silinməməlidir.

Məsələn, yalnız vebsayt yerləşdirən tipik serverdə açıq olması lazım olan portlar adətən 80, 443 və məhdud SSH portudur. Poçt serveri işləmirsə, 25, 465, 587, 993 kimi portların açıq qalmasına ehtiyac yoxdur. Verilənlər bazası yalnız lokal serverdən istifadə olunursa, 3306 və ya 5432 portları xarici dünyaya bağlı olmamalıdır.

Hansı Təhlükəsizlik Divarı Alətini Seçməlisiniz?

Linux mühitində bir neçə alət mövcuddur və əksəriyyəti eyni nüvə filtrləmə infrastrukturunu fərqli rahatlıqla idarə edir. Yeni başlayanlar üçün UFW sadə və sürətlidir. Korporativ və ya Red Hat əsaslı sistemlərdə firewalld geniş yayılıb. Daha inkişaf etmiş ssenarilərdə nftables müasir və elastik infrastruktur təqdim edir. Aşağıdakı cədvəl seçim etməyi asanlaşdırır.

Addım-Addım Server Təhlükəsizlik Divarı Qurulması

1. Açıq Portları və Xidmətləri Müəyyənləşdirin

İlk addım nəyin açıq olduğunu görməkdir. Linux serverdə ss -tulpn əmri hansı xidmətlərin hansı portlarda dinlədiyini göstərir. Məsələn, nginx 0.0.0.0:80 və 0.0.0.0:443-də dinləyirsə, veb trafiki bütün interfeyslərdən qəbul edilir. MariaDB 0.0.0.0:3306-da dinləyirsə, bu ümumiyyətlə risklidir; əksər vebsaytlarda verilənlər bazası 127.0.0.1 üzərində işləməlidir.

Praktik qayda belədir: İnternetdən giriş tələb etməyən heç bir xidmət 0.0.0.0 üzərində dinləməməlidir. Əvvəlcə xidmət konfiqurasiyasını düzəltmək, sonra təhlükəsizlik divarı ilə bağlamaq daha düzgündür. Çünki təhlükəsizlik divarı söndürülsə belə, xidmət xarici dünyaya açıq olmamalıdır.

2. Defolt Siyasəti Bağlayın

Təhlükəsiz qayda dəstlərində defolt gələn trafik rədd edilir, gedən trafik isə ehtiyaca uyğun açılır. Bu yanaşma sonradan açılan xidmətlərin səhvən internetə açılmasının qarşısını alır. UFW istifadə edən Ubuntu serverdə məntiq belədir: əvvəlcə SSH üçün icazə verilir, sonra 80 və 443 açılır, daha sonra defolt gələn trafik deny edilir və təhlükəsizlik divarı aktivləşdirilir.

Nümunə axın: SSH üçün idarəçi IP ünvanınızı icazə verin, HTTP və HTTPS trafikini açın, lazım olmayan portları bağlayın, sonra aktivləşdirin. SSH icazəsi vermədən təhlükəsizlik divarını açmaq, uzaq serverlərdə ən çox edilən səhvlərdəndir.

3. SSH Girişini Məhdudlaşdırın

SSH, ən çox hədəflənən xidmətlərdəndir. Defolt 22 portu açıq olan server gündə yüzlərlə və ya minlərlə şifrə cəhdi görə bilər. Ən təhlükəsiz yanaşma SSH girişini müəyyən IP ünvanları ilə məhdudlaşdırmaqdır. Sabit IP varsa, yalnız ofis və ya VPN IP-nizə icazə verin. Sabit IP yoxdursa, ən azından açar əsaslı identifikasiya tətbiq edin və şifrə ilə girişləri bağlayın.

• Root ilə birbaşa SSH girişini bağlayın.
• Şifrə yerinə SSH açarından istifadə edin.
• AllowUsers və ya AllowGroups ilə istifadəçiləri məhdudlaşdırın.
• Fail2ban ilə uğursuz giriş cəhdlərini avtomatik bloklayın.
• İdarəetmə paneli varsa, onun portunu da IP məhdudiyyətinə alın.

Port dəyişdirmək təkbaşına təhlükəsizlik təmin etmir, amma avtomatik bot səs-küyünü azalda bilər. Həqiqi qoruma IP məhdudiyyəti, güclü autentifikasiya və log izləmə ilə təmin edilir.

4. Veb Portlarını Nəzarətli Açın

Sayt yayımlayan demək olar ki, bütün serverlər üçün 80 və 443 portları vacibdir. Lakin hazırda 443, yəni HTTPS əsas trafik portu olmalıdır, 80 isə yalnız HTTPS-ə yönləndirmə üçün açıq qalmalıdır. SSL sertifikatı olmayan saytlar həm istifadəçi etibarını, həm də SEO performansını mənfi təsir edir. Bu nöqtədə Hostragons SSL sertifikatları bağlantısı, oxuyucunu təhlükəsiz HTTPS qurulumuna istiqamətləndirmək üçün təbii daxili link imkanı yaradır.

Veb portlarını açarkən real IP davranışına diqqət edin. Əgər CDN və ya tərs proxy istifadə edirsinizsə, serverinizin 80 və 443 portlarını bütün internetə açmaq əvəzinə yalnız CDN IP aralıqlarından gələn trafiki qəbul etmək daha güclü qoruma təmin edir. Beləcə hücumçu real server IP-ni bilsə belə, birbaşa veb xidmətinə girişi olmayacaq.

5. Verilənlər Bazası və Lokal Xidmətləri İnternetdən Bağlayın

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB və bənzəri xidmətlərin internetə açıq olması ciddi təhlükə yaradır. Redis-də autentifikasiyanın olmaması, Elasticsearch-də icazəsiz indeksə giriş və MongoDB-də açıq idarə portu çoxlu məlumat sızmasına səbəb olmuşdur. Bu xidmətlər mümkün qədər yalnız localhost və ya xüsusi şəbəkədən dinləməlidir.

Məsələn, eyni serverdə işləyən WordPress üçün verilənlər bazasının 127.0.0.1 üzərindən işləməsi kifayətdir. Ayrı tətbiq və verilənlər bazası serveri varsa, yalnız tətbiq serverinin xüsusi IP-sinə icazə verin. Ümumi internetdən 3306 və ya 5432 portlarına giriş açıq buraxmaq, botların daimi skan etdiyi məşhur səhvdir.

6. Fail2ban ilə Brute Force Cəhdlərini Dayandırın

Fail2ban, log fayllarını izləyərək təkrar uğursuz giriş cəhdlərini aşkar edir və müvafiq IP-ni müvəqqəti şəkildə bloklayır. SSH, nginx, Apache, Postfix, Dovecot, WordPress giriş və bəzi panel xidmətləri üçün jail konfiqurasiyaları mövcuddur. Məsələn, 10 dəqiqə ərzində 5 uğursuz SSH cəhdi edən IP-ni 1 saatlıq bloklamaq sadə, amma təsirli başlanğıcdır.

Fail2ban konfiqurasiyasında çox sərt qaydalar tətbiq edərkən diqqətli olun. Yanlış log nümunəsi həqiqi istifadəçiləri də bloklaya bilər. Buna görə ilk mərhələdə bantime dəyərini məqbul tutmaq, logları izləmək və sonra tədricən sərtləşdirmək daha təhlükəsizdir.

7. Sürət Məhdudlaşdırma və Bağlantı Limitləri Əlavə Edin

DDoS və bot trafikinə qarşı əməliyyat sistemi səviyyəsində sürət məhdudlaşdırması faydalı ola bilər. Məsələn, eyni IP-dən saniyədə çox sayda yeni bağlantı gəlirsə, limit tətbiq edilə bilər. Veb server tərəfdə nginx üçün limit_req və limit_conn modulları, Apache-də mod_evasive və ya oxşar həllər istifadə oluna bilər. Tətbiq səviyyəsində isə giriş, axtarış, səbət, ödəniş və API endpointləri üçün ayrıca sürət məhdudiyyəti qoymaq lazımdır.

Konket nümunə: Giriş səhifəsində hər IP üçün dəqiqədə 10 cəhd məqbul sayıla bilər. Axtarış endpointində saniyədə 2-5 sorğu kifayət edə bilər. API təqdim edirsinizsə, istifadəçi əsaslı token limiti, IP limiti və davranış analizi birlikdə nəzərdə tutulmalıdır. Bu yolla hücumçu yalnız IP-ni dəyişməklə bütün limiti keçə bilməz.

UFW ilə Nümunə Təhlükəsiz Quruluş Ssenarisi

Ubuntu və ya Debian əsaslı veb serverdə sadə təhlükəsiz başlanğıc ssenarisi belə ola bilər: əvvəl mövcud xidmətləri yoxlayın, idarəçi IP ünvanından SSH girişinə icazə verin, 80 və 443 portlarını açın, gələn trafiki defolt olaraq rədd edin və UFW-nin vəziyyətini təsdiqləyin. Əgər SSH girişinizi sabit IP ilə məhdudlaşdıra bilmirsinizsə, müvəqqəti olaraq bütün IP-lərə icazə verib sonradan VPN və ya sabit IP həllinə keçə bilərsiniz.

Nümunə qayda dəsti belədir: 203.0.113.10 idarəçi IP-si olsun. SSH yalnız bu IP-dən gəlsin. Veb trafiki 80 və 443 portlarında hər kəs üçün açıq olsun. Verilənlər bazası, Redis, panel və test portları xaricə bağlı olsun. Bu quruluş kiçik və orta ölçülü bir çox korporativ vebsayt üçün yaxşı başlanğıcdır. Domen və DNS konfiqurasiyası üçün Hostragons domen sorğulama və qeyd səhifəsinə daxili keçid verə bilərsiniz.

firewalld ilə Zona Yanaşması

AlmaLinux, Rocky Linux və RHEL əsaslı serverlərdə firewalld geniş istifadə olunur. firewalld zona konsepti ilə işləyir. Public zona internetə açıq interfeyslər üçündür, trusted zona etibarlı xüsusi şəbəkələr üçün, drop zona isə istənməyən trafiki səssizcə rədd etmək üçün istifadə edilir. Ən vacib məqam runtime və permanent qaydaların fərqidir. Runtime qaydaları dərhal tətbiq olunur, lakin yenidən başladıqda itə bilər; permanent qaydalar isə qalıcıdır, lakin reload tələb edə bilər.

Korporativ mühitlərdə firewalld istifadə edərkən xidmət əsaslı təyinatlar işi asanlaşdırır. Məsələn, http və https xidmətlərini public zonada açar, ssh xidmətini yalnız müəyyən mənbə IP-lərdən açıq edə bilərsiniz. İdarəetmə, ehtiyat və istifadəçi trafiki fərqli interfeyslərdədirsə, zona strukturu təhlükəsizliyi və oxunaqlılığı artırır.

CDN, WAF və Provayder Səviyyəli DDoS Qoruması

Lokal təhlükəsizlik divarı paketlər serverə çatdıqdan sonra qərar verir. Böyük DDoS hücumlarında məqsəd trafiki serverə çatmadan süzməkdir. CDN, WAF və provayder səviyyəsində DDoS qoruması buna görə çox önəmlidir. CDN statik məzmunu kənar lokasiyalarda təqdim edir, WAF tətbiq qatındakı zərərli sorğuları süzür, provayder qoruması isə şəbəkə səviyyəsində böyük həcmli hücumları udur və ya təmizləyir.

İdeal modeldə DNS qeydləriniz CDN vasitəsilə keçər, real server IP-niz gizlədilir, server təhlükəsizlik divarı yalnız CDN IP aralıqlarından 80 və 443 qəbul edir. İdarəetmə portları isə VPN və ya sabit IP üzərindən əlçatan olur. Belə model birbaşa IP-yə hücum riskini azaldır və bot trafikini tətbiqə çatmadan önləyir. Veb təhlükəsizliyi və performansı birlikdə əhatə edən mövzular üçün veb saytı sürətləndirmə və təhlükəsizlik bələdçiləri bağlantısından istifadə oluna bilər.

Botlara Qarşı Tətbiq Qatı Tədbirləri

Botların bloklanması yalnız IP-nin qara siyahıya alınmasından ibarət deyil. Müasir botlar proxy, mobil şəbəkə, data mərkəzi IP-ləri və dəyişkən istifadəçi agentləri istifadə edə bilər. Buna görə davranış əsaslı yanaşma tələb olunur. Eyni IP-dən qısa müddətdə çox sayda giriş cəhdi, davamlı 404 yaradan skan, wp-login.php və xmlrpc.php intensivliyi, adi istifadəçidən fərqli klik nümunələri və şübhəli başlıqlar analiz edilməlidir.

• Giriş və qeydiyyat formalarında sürət məhdudiyyəti tətbiq edin.
• Lazımsız XML-RPC girişlərini bağlayın və ya məhdudlaşdırın.
• İdarə panelini fərqli URL, IP məhdudiyyəti və çoxfaktorlu autentifikasiya ilə qoruyun.
• Şübhəli user-agent və referer şablonlarını WAF səviyyəsində süzün.
• Formlarda CAPTCHA və görünməz bot yoxlama mexanizmlərini balanslı istifadə edin.
• API endpointləri üçün açar, imza, kvota və zaman damğası yoxlamaları əlavə edin.

Bot idarəsində istifadəçi təcrübəsini pozmamaq vacibdir. Həddindən artıq CAPTCHA, aqressiv bloklama və ya səhv ölkə blokları həqiqi müştərilərə zərər verə bilər. Buna görə ölçmə, test və tədricən sərtləşdirmə ən sağlam yanaşmadır.

Log İzləmə və Alarm Qaydaları

Quruluşun tamamlandığını düşünmək ümumi səhvdir. Təhlükəsizlik divarı canlı sistemdir və müntəzəm izlənməlidir. auth.log və ya secure faylında SSH cəhdləri, nginx access loglarında anormal sorğu sıxlığı, error loglarında 404 və 500 artımı, sistem metriklərində CPU və bağlantı sayı izlənməlidir. Sadə bir alarm belə hücum başlandıqda dəqiqələr qazandırır.

Başlanğıc üçün nümunə eşik dəyərləri: 5 dəqiqə ərzində eyni IP-dən 100-dən çox 404 sorğusu, 1 dəqiqədə giriş səhifəsinə 20-dən çox cəhd, CPU istifadəsinin 10 dəqiqə ərzində 90%-dən yuxarı qalması, bağlantı sayının normalın 3 qatına çıxması. Bu dəyərlər hər sayta görə dəyişir; əsas olan normal trafik profilini bilməkdir.

Ümumi Səhvlər və Onlardan Qaçınma Yolları

• SSH icazəsi vermədən təhlükəsizlik divarını aktivləşdirmək: Uzaq serverdə giriş itirə bilərsiniz. Həmişə ikinci sessiya ilə test edin.
• IPv6-nı unutmaq: IPv4 bağlananda IPv6 üzərindən xidmət açıq qala bilər.
• Verilənlər bazasını internetə açıq buraxmaq: 3306, 5432, 6379 və 9200 kimi portlar botlar tərəfindən davamlı skan olunur.
• CDN istifadə edib real IP-ni açıq saxlamaq: Hücumçu CDN-ni keçərək birbaşa serverə hücum edə bilər.
• Qaydaları sənədləşdirmədən dəyişdirmək: Təcili vəziyyətdə hansı qaydanın nə işə yaradığı bilinmir.
• Ehtiyat giriş planı hazırlamamaq: Yanlış qayda olduqda konsol girişi yoxdursa, kəsinti uzanır.

Praktik Təhlükəsizlik Divarı Siyasəti Nümunəsi

Kiçik korporativ vebsayt üçün mümkün ümumi siyasət belədir: gələn trafik defolt olaraq bağlıdır; 443 hamıya açıqdır; 80 yalnız HTTPS yönləndirməsi üçün açıqdır; SSH yalnız VPN və ya sabit idarəçi IP-dən əlçatandır; verilənlər bazası localhost və ya xüsusi şəbəkədədir; CDN varsa 80 və 443 yalnız CDN IP aralıqlarına icazə verilir; Fail2ban SSH və veb giriş cəhdlərini izləyir; günlük loglar mərkəzi monitorinqə göndərilir.

Orta ölçülü e-ticarət saytında əlavə olaraq ödəniş callback IP-ləri allowlist edilir, idarə paneli VPN arxasında saxlanır, API üçün istifadəçi bazlı kvota tətbiq olunur, WAF üzərində SQL injection və XSS qaydaları aktivləşdirilir, ölkə və ASN əsaslı müvəqqəti filtrləmə planlaşdırılır. Bu planın yazılı olması vacibdir; hücum zamanı qərar verməkdənsə əvvəlcədən təyin olunmuş proseduru tətbiq etmək kəsinti müddətini azaldır.

Test Etmə: Qaydalar Həqiqətən İşləyirmi?

Təhlükəsizlik divarı qurulduqdan sonra mütləq test edilməlidir. Fərqli şəbəkədən açıq port skanlaması aparın, SSH girişinin yalnız icazə verilmiş IP-dən mümkün olduğunu təsdiqləyin, saytın HTTPS üzərindən əlçatan olduğunu yoxlayın, verilənlər bazası portunun xaricdən bağlı olduğuna əmin olun. CDN istifadə edirsinizsə, real server IP-sinə birbaşa HTTP sorğusu göndərərək bloklandığını təsdiqləyin.

Test zamanı istehsal sistemlərinə zərər verə biləcək aqressiv skanlardan qaçının. Məqsəd təhlükəsiz doğrulama aparmaqdır. Həmçinin hər dəyişiklikdən sonra qayda dəstini ixrac edin və ya qeyd edin. Beləliklə problem yaranarsa, əvvəlki sağlam konfiqurasiyaya qayıtmaq asanlaşar.

Təmir və Yenilənmə Planı

Server təhlükəsizliyi təkcə bir dəfə quraşdırmaq deyil, davamlı qulluq tələb edən prosesdir. Yeni xidmət əlavə olunanda port tələbi yenidən gözdən keçirilməli, köhnə xidmət silindikdə müvafiq icazələr ləğv edilməli, təhlükəsizlik yeniləmələri vaxtında tətbiq edilməli və loglar müntəzəm yoxlanmalıdır. Ayda ən azı bir dəfə açıq port yoxlaması, üç ayda bir firewall qayda dəstinin gözdən keçirilməsi yaxşı praktikadır.

Həmçinin ehtiyat planı təhlükəsizlik strategiyasının vacib hissəsidir. DDoS hücumu xidməti kəsə bilər, amma fidyə proqramı və ya icazəsiz giriş məlumat itkisinə səbəb ola bilər. Təhlükəsiz hosting, SSL, domen idarəetməsi və ehtiyatlama birlikdə planlaşdırılmalıdır. Bu baxımdan Təhlükəsiz hosting seçərkən diqqət yetirilməsi gərəkənlər və SSL sertifikatı qurulması necə aparılır məqalələri təbii davam əlaqələridir.

Nəticə

Server təhlükəsizlik divarının qurulması DDoS və botlara qarşı serveri tamamilə görünməz etmir; lakin hücum səthini əhəmiyyətli dərəcədə kiçildir, icazəsiz giriş riskini azaldır və hadisələrə daha nəzarətli müdaxilə etməyə imkan yaradır. Ən yaxşı nəticə provayder səviyyəsində DDoS qoruması, CDN/WAF, ciddi port siyasəti, SSH məhdudiyyəti, Fail2ban, sürət məhdudiyyəti və müntəzəm log izləmə birlikdə tətbiq ediləndə əldə olunur.

Əgər yeni layihə yayımlayacaqsınızsa, təhlükəsizlik divarı siyasətini əvvəldən planlaşdırmaq sonradan düzəltməkdən daha asandır. Hostragons üzərində server, hosting, domen və SSL infrastrukturlarınızı qiymətləndirərkən təhlükəsizlik tələblərinizi də nəzərə alaraq daha davamlı veb mühiti yarada bilərsiniz. Lazım olsa, kiçik yoxlama siyahısı ilə başlayın: açıq portları bağlayın, SSH-ni məhdudlaşdırın, HTTPS-ni məcburi edin və logları izləyin.

Tez-tez Verilən Suallar

Server təhlükəsizlik divarı DDoS hücumlarını tamamilə dayandırırmı?

Xeyr. Lokal təhlükəsizlik divarı kiçik miqyaslı və protokol səviyyəsində hücumları azalda bilər, amma böyük həcmli DDoS hücumlarında provayder səviyyəsində DDoS qoruması, CDN və WAF istifadə edilməlidir.

Veb serverdə hansı portlar açıq qalmalıdır?

Tipik veb serverdə 80 və 443 portları açıq qalır. SSH portu yalnız idarəçi IP-lərinə icazəlidir. Verilənlər bazası və lokal xidmət portları internetdən bağlı saxlanmalıdır.

UFW yoxsa firewalld istifadə etməliyəm?

Ubuntu və Debian üçün UFW daha sadə başlanğıc təklif edir. AlmaLinux, Rocky Linux və RHEL əsaslı sistemlərdə firewalld geniş yayılıb. İrəliləmiş və xüsusi ssenarilər üçün nftables üstünlük verilə bilər.

Bot trafikini yalnız IP bloklama ilə dayandıra bilərəmmi?

Adətən yox. Müasir botlar müxtəlif IP və proxylərdən istifadə edir. IP bloklamanın yanında sürət məhdudiyyəti, WAF qaydaları, davranış analizi, CAPTCHA və tətbiq əsaslı kvotalar tətbiq edilməlidir.

Təhlükəsizlik divarı qurarkən ən böyük risk nədir?

Ən böyük risk səhv qayda səbəbindən öz SSH girişinizi kəsməkdir. Buna görə əvvəlcə SSH icazəsi verilməli, ikinci sessiya ilə test edilməli və provayder konsol girişi hazır olmalıdır.