Server xavfsizlik devori o‘rnatish: DDoS va botlarga qarshi himoya qilish

Server xavfsizlik devori o‘rnatish – bu serverda faqat zarur portlarni ochiq qoldirib, barcha boshqa kirishlarni bloklash jarayonidir. DDoS, brute force va zararli bot trafikiga qarshi eng birinchi himoya qatlamini yaratadi. Amaliy maqsad: SSH kirishni cheklash, web xizmatlarini faqat kerakli IPdan ochish, shubhali so‘rovlarni limitga olish, loglarni kuzatish va iloji boricha CDN/WAF kabi yuqori qatlam himoyalar yordamida trafikni serverga yetib kelmasdan filtratsiya qilishdir.

Web serveringiz internetga ulangan zahoti, bir necha daqiqa ichida portlarni skaner qilish, SSH sinovlari, zaiflik botlari va soxta user-agentlar bilan duch kelishingiz mumkin. Ayniqsa WordPress, e-tijorat, admin panel, API yoki o‘yin serveri ishlayotgan loyihalarda xavfsizlik devori – bu faqat texnik tanlov emas, balki uzluksizlik uchun majburiy zaruratdir. Ushbu qo‘llanmada Linux serverlarda bosqichma-bosqich xavfsizlik devori arxitekturasi tuzamiz; UFW, firewalld, nftables, Fail2ban, web-app xavfsizlik devori va DDoSni kamaytirish usullarini birgalikda ko‘rib chiqamiz.

Yodda tuting: Mahalliy server xavfsizlik devori o‘ziga xos katta DDoS hujumlarni to‘liq to‘xtata olmaydi. 20 Gbps, 80 Gbps yoki undan ham yuqori hajmdagi hujum data markazga yetib kelganda, paketlar sizning OS qoidalaringizga yetmasdan tarmoqni to‘sib qo‘yadi. Shuning uchun to‘g‘ri yondashuv – qatlamli himoya: provayder darajasida DDoS himoyasi, CDN/WAF, OS xavfsizlik devori, dastur limitlari va loglarni muntazam tahlil qilish birga ishlashi kerak. Infratuzilmani tanlashda Hostragons VPS va VDS Server yechimlari sahifasi, sayt tomondagi xavfsiz hosting uchun Hostragons veb hosting paketlari sahifasiga murojaat qilishingiz mumkin.

Server xavfsizlik devori nima uchun kerak?

Server xavfsizlik devori – tarmoq trafikini manba IP, maqsad IP, port, protokol, ulanish holati va ba’zida paket xususiyatlariga ko‘ra filtrlaydigan himoya qatlamidir. Oddiy misol: saytingiz uchun 80 va 443 portlar ochiq bo‘lishi kerak, ammo 3306 port (ma’lumotlar bazasi) internetga ochiq bo‘lishi xavfli. SSH uchun 22-portni hamma uchun ochiq qilish o‘rniga, faqat sizning ofis IPdan kirishga ruxsat berish xavfsizroqdir.

Devorning asosiy maqsadi barcha hujumlarni bir zumda yo‘q qilish emas. Asosiy maqsad – hujum yuzasini qisqartirish. Yuzasi qancha kichik bo‘lsa, xaker uchun sinov variantlari shuncha kam bo‘ladi. Yangi Linux serverida SSH, admin panel, mail, database, monitoring va test xizmatlari bir vaqtning o‘zida ochiq qolishi mumkin. Har biri alohida xavf. Yaxshi devor – “standartda rad et, kerakligini ruxsat ber” tamoyili bilan ishlaydi.

DDoS va bot trafikini tushunish

DDoS hujumlari nimasi bilan boshqacha?

DDoS – ya’ni distributed denial of service – ko‘plab manbalardan keladigan kuchli trafik bilan xizmatni ishlashdan to‘xtatishga qaratilgan. Ba’zan tarmoqni to‘sadi, ba’zan serverning CPU va RAM resurslarini tugatadi, ba’zan esa dastur qatlamidagi qimmat operatsiyalarni ishga tushiradi. Masalan, sekundiga 50 000 HTTP so‘rov keladigan kichik server, tarmoq to‘lmasa ham PHP-FPM yoki Node.js, database ulanishlari sababli javob bera olmaydi.

Botlar har doim zararli emasmi?

Yo‘q. Googlebot, Bingbot va monitoring botlari foydalidir. Lekin zararli botlar admin panel qidirish, ochiq katalog izlash, spam, kontent o‘g‘irlash, XML-RPC suiste’moli, soxta ro‘yxat va login sinovlarini amalga oshiradi. Botlarni boshqarishda maqsad – barcha botlarni bloklash emas, balki ularning xatti-harakatiga qarab ajratishdir. Ko‘p xato, juda tez va ko‘p so‘rov, haqiqiy brauzerga o‘xshamagan headers va shubhali URLlar muhim signallar.

O‘rnatishdan oldin nazorat ro‘yxati

Serverda devor qoidalarini yozishda eng katta xavf – o‘zingizni serverdan uzib qo‘yish. Shuning uchun o‘zgartirishdan oldin qisqa tayyorgarlik zarur. Quyidagi ro‘yxat, ishlab chiqarish muhitida xavfsiz boshlash uchun keng qo‘llaniladi:

• Aktiv SSH sessiyani yopmang; ikkinchi terminalda test qiling.
• Server provayderingizda konsol, VNC yoki recovery kirish borligiga ishonch hosil qiling.
• Ochiq portlarni ro‘yxatga oling: ss -tulpn yoki netstat -tulpn natijalarini tekshiring.
• Web, mail, DNS, database, panel va monitoring xizmatlari qaysi portlarni ishlatishini yozib oling.
• IPv6 ishlatayotgan bo‘lsangiz, IPv6 devor qoidalarini ham rejalashtiring.
• Avval allow (ruxsat) qoidalarini, keyin deny (blok) qoidalarini qo‘llang.
• Qoidalarning doimiyligini tekshiring; server qayta ochilganda yo‘qolmasin.

Masalan, faqat web sayti joylashgan oddiy serverda ochiq bo‘lishi kerak portlar odatda 80, 443 va cheklangan SSH portidir. Agar mail server ishlamasa 25, 465, 587, 993 portlarga ehtiyoj yo‘q. Database faqat server ichidan ishlatilsa, 3306 yoki 5432 portlarni tashqariga ochiq qoldirish foydasiz va xavfli.

Qaysi devor vositasini tanlash kerak?

Linuxda bir nechta vosita bor va aksariyati bir xil kernel filtrlash bazasini turlicha interfeys bilan boshqaradi. Yangi boshlovchilar uchun UFW qulay va tez. Enterprise yoki Red Hat asosli sistemalarda firewalld keng tarqalgan. Murakkab holatlarda nftables zamonaviy va moslashuvchan. Quyidagi jadval tanlashni osonlashtiradi:

Bosqichma-bosqich server devori o‘rnatish

1. Ochiq port va xizmatlarni aniqlash

Birinchi qadam – nimaning ochiq ekanini bilish. Linuxda ss -tulpn bu xizmatlarning qaysi portlarda tinglayotganini ko‘rsatadi. Masalan nginx 0.0.0.0:80 va 0.0.0.0:443da tinglasa, web trafik barcha interfeyslardan qabul qilinadi. MariaDB 0.0.0.0:3306da tinglasa, bu xavfli – ko‘pchilik sayt uchun database 127.0.0.1da ishlashi kerak.

Praktik qoida: Internetdan kirishi shart bo‘lmagan xizmat hech qachon 0.0.0.0da tinglamasligi kerak. Avval xizmatni to‘g‘ri konfiguratsiya qilish, so‘ng devor bilan bloklash – eng to‘g‘ri yo‘l. Devor o‘chsa ham, xizmat tashqariga ochiq bo‘lmasligi lozim.

2. Standart siyosat – bloklash

Xavfsiz qoidalarga ko‘ra, kelayotgan trafik bloklanadi, chiqayotgan esa ehtiyojga ko‘ra ruxsat etiladi. Bu usul, yangi xizmatlar tasodifan internetga ochilishini oldini oladi. UFW ishlatadigan Ubuntu serverda: avval SSHga ruxsat bering, so‘ng 80 va 443ni oching, kelayotgan trafikni deny (blok) qiling va devorni yoqing.

Misol: SSH uchun admin IPga ruxsat, HTTP/HTTPSni ochish, keraksiz portlarni bloklash, so‘ng devorni yoqish. SSH ruxsatini bermasdan devorni faollashtirish – ayniqsa masofaviy serverlarda – eng keng tarqalgan xatodir.

3. SSH kirishni cheklash

SSH – xakerlar eng ko‘p hujum qiladigan servis. 22-port ochiq server kuniga yuzlab yoki minglab parol sinovlari oladi. Eng xavfsiz usul SSHni faqat muayyan IPga cheklash. Agar static IP bo‘lsa, ofis yoki VPN IPdan kirishga ruxsat beriladi. Static IP bo‘lmasa, kamida key-based autentifikatsiya va parolni o‘chirish zarur.

• Root bilan SSHni to‘g‘ridan-to‘g‘ri bloklang.
• Parol o‘rniga SSH key ishlating.
• AllowUsers/AllowGroups bilan kiruvchi foydalanuvchilarning ro‘yxatini cheklang.
• Fail2ban bilan muvaffaqiyatsiz sinovlarni avtomatik bloklang.
• Panel portlarini ham IP chekloviga oling.

Portni o‘zgartirish botlar shovqinini kamaytiradi, ammo haqiqiy himoya – IP cheklovi, kuchli autentifikatsiya va log kuzatuvi bilan ta’minlanadi.

4. Web portlarini boshqarib ochish

Ko‘pchilik web server uchun 80 va 443 portlar zarur. Hozirda 443 – HTTPS – asosiy port bo‘lishi, 80 esa faqat HTTPSga yo‘naltirish uchun ishlatilishi kerak. SSL sertifikati yo‘q saytlar foydalanuvchi ishonchini va SEO natijasini yo‘qotadi. Bu yerda Hostragons SSL sertifikatlari havolasi, HTTPSni to‘g‘ri o‘rnatish uchun yaxshi ichki linkdir.

Web portlarini ochishda real IPga e’tibor bering. Agar CDN yoki reverse proxy ishlatgan bo‘lsangiz, serveringizning 80 va 443 portlarini butun internetga ochish o‘rniga, faqat CDN IPlaridan kelgan trafikga ruxsat berish kuchli himoya beradi. Shunda xaker server IPni bilsa ham web xizmatga kira olmaydi.

5. Database va ichki xizmatlarni internetga bloklash

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB va shunga o‘xshash xizmatlarning internetga ochiq bo‘lishi katta xavf. Redisda autentifikatsiya yo‘qligi, Elasticsearchda ochiq indeks, MongoDBda ochiq admin port – ko‘plab ma’lumotlar sizib chiqishiga sabab bo‘lgan. Bu xizmatlar faqat localhost yoki private networkda tinglashi lozim.

Masalan, bir serverda WordPress ishlasa, database 127.0.0.1da yetarlidir. Agar alohida application va database server bo‘lsa, faqat application serverning private IPga ruxsat bering. 3306 yoki 5432 portlarni internetga ochiq qoldirish – botlar doim skan qiladigan xato.

6. Fail2ban bilan brute forcega qarshi himoya

Fail2ban, loglarni kuzatib, takroran muvaffaqiyatsiz kirishni aniqlaydi va tegishli IPni vaqtincha bloklaydi. SSH, nginx, Apache, Postfix, Dovecot, WordPress login va panel xizmatlari uchun jail sozlamalari qilinadi. Masalan, 10 daqiqa ichida 5 marta SSH sinov qilgan IPni 1 soat bloklash – oddiy, lekin samarali boshlanishdir.

Fail2ban sozlashda juda agressiv qoidalardan ehtiyot bo‘ling. Noto‘g‘ri log pattern haqiqiy foydalanuvchilarni ham bloklashi mumkin. Shuning uchun avval bantime qiymatini o‘rtacha tuting, loglarni kuzating, keyin bosqichma-bosqich kuchaytirib boring.

7. Rate limiting va ulanish limitlarini qo‘shish

DDoS va bot trafikiga OS darajasida limitlar yordam beradi. Masalan, bir IPdan sekundiga ko‘p ulanish bo‘lsa, limit qo‘yiladi. Web serverda nginx uchun limit_req va limit_conn modullari, Apache uchun mod_evasive ishlatiladi. Dasturda esa login, search, cart, payment, API endpointlar uchun alohida limitlar belgilash kerak.

Misol: Login page uchun bir IPga minutiga 10 sinov, search endpointda sekundiga 2-5 so‘rov yetarli. API uchun user-token limit, IP limit va xatti-harakat tahlili integratsiya qilinadi. Shunda xaker faqat IPni o‘zgartirib limitdan o‘tib ketolmaydi.

UFW bilan xavfsiz o‘rnatish misoli

Ubuntu/Debian asosli web serverda oddiy xavfsiz boshlash: avval xizmatlarni tekshiring, admin IPdan SSHga ruxsat bering, 80 va 443ni oching, kelayotgan trafikni bloklang va UFW holatini tekshiring. Agar SSHni static IPga cheklash imkoni bo‘lmasa, vaqtinchalik barcha IPdan SSHga ruxsat bering, so‘ng VPN yoki static IPga o‘ting.

Misol: 203.0.113.10 admin IP. SSH faqat shu IPdan. Web trafik 80 va 443da hamma uchun ochiq. Database, Redis, panel va test portlari internetga bloklangan. Bu tuzilma ko‘plab o‘rta va kichik korporativ saytlarga yaxshi boshlanishdir. Domain va DNS yo‘naltirish uchun Hostragons domen so'rov va ro'yxat havolasini kiritish mumkin.

firewalld va zone konsepsiyasi

AlmaLinux, Rocky Linux va RHELda firewalld keng tarqalgan. firewalld zone konsepsiyasi bilan ishlaydi. Public zone – internetga ochiq interfeyslar uchun, trusted zone – ishonchli tarmoq uchun, drop zone – keraksiz trafikni jim bloklash uchun. Eng muhim – runtime va permanent qoidalar farqi. Runtime – darhol amal qiladi, lekin rebootda yo‘qoladi; permanent – doimiy, reload talab qiladi.

Enterprise muhitida firewalldni servis-based qo‘llash oson. Masalan, http va httpsni public zoneda ochish, SSHni faqat muayyan IPdan ochish mumkin. Management, backup va user trafiklari alohida interfeyslarda bo‘lsa, zone tuzilmasi xavfsizlik va o‘qilishi yaxshilanadi.

CDN, WAF va provayder darajasida DDoS himoyasi

Mahalliy devor paketlarni serverga yetib kelgandan so‘ng tekshiradi. Katta DDoS hujumlarda esa trafik serverga yetmasdan filtrlanishi kerak. CDN, WAF va provayder-level DDoS himoyasi shu sababdan muhim. CDN statik fayllarni edge-larda taqdim etadi, WAF dastur qatlamidagi zararli so‘rovlarni filtrlaydi, provayder himoyasi – tarmoq darajasida hajmli hujumlarni “yutadi” yoki tozalaydi.

Ideal modelda DNS rekordlaringiz CDNdan o‘tadi, haqiqiy server IP yashiriladi, devor faqat CDN IPdan 80 va 443ni qabul qiladi. Management portlar esa VPN yoki static IPdan kiriladi. Bu model IPga to‘g‘ridan-to‘g‘ri hujum ehtimolini kamaytiradi va bot trafikni dasturga yetmasdan bloklaydi. Web xavfsizlik va tezlik uchun web sayti tezlashtirish va xavfsizlik qo'llanmalari havolasidan foydalaning.

Botlarga qarshi dastur qatlamida chora

Botni bloklash – faqat IP ban emas. Zamonaviy botlar proxy, mobil tarmoq, data center IP va o‘zgaruvchan user-agentlarni ishlatadi. Shuning uchun xatti-harakatga asoslangan yondashuv kerak. Bir IPdan tez-tez login sinovi, doimiy 404, wp-login.php yoki xmlrpc.php ko‘p so‘rov, oddiy userdan farqli klik pattern va shubhali headers tahlil qilinadi.

• Login va ro‘yxatdan o‘tish formalarida limitlar qo‘llang.
• Keraksiz XML-RPCni o‘chiring yoki cheklang.
• Admin panelini alohida URL, IP cheklovi va multi-factor autentifikatsiya bilan himoyalang.
• Shubhali user-agent va refererlarni WAFda filtrlang.
• Formalarda CAPTCHA yoki botni aniqlash mexanizmlarini balansli tarzda qo‘llang.
• API endpointlar uchun kalit, imzo, quota va time-stamp nazoratini qo‘shing.

Botni boshqarishda user tajribasini buzmaslik muhim. Haddan tashqari CAPTCHA, agressiv bloklash yoki noto‘g‘ri davlat bloklari haqiqiy mijozlarga zarar yetkazishi mumkin. Shuning uchun monitoring, test va bosqichma-bosqich kuchaytirish eng to‘g‘ri yo‘l.

Log monitoring va alarm qoidalari

O‘rnatish tugadi deb o‘ylash xato. Xavfsizlik devori – tirik sistemadir va doim kuzatilishi kerak. auth.log yoki secure faylida SSH sinovlari, nginx access logda g‘ayrioddiy so‘rovlar, error logda 404 va 500 ortishi, sistem metrikada CPU va ulanish soni monitoring qilinadi. Oddiy alarm ham hujum boshlanganida qimmatli daqiqalar beradi.

Boshlang‘ich uchun misol thresholdlar: 5 daqiqada bir IPdan 100dan ortiq 404, 1 daqiqada login pagega 20dan ortiq sinov, CPU 10 daqiqa davomida 90%dan yuqori, ulanish soni normaldan 3 baravar yuqori. Bu thresholdlar har sayt uchun moslashtiriladi; eng muhim – oddiy trafik profilini bilish.

Eng ko‘p uchraydigan xatolar va ularni oldini olish

• SSH ruxsatisiz devorni yoqish: Masofaviy serverdan ulanishni yo‘qotishingiz mumkin. Har doim ikkinchi sessiya bilan test qiling.
• IPv6ni unutish: IPv4 bloklangan bo‘lsa ham, IPv6 orqali xizmat ochiq bo‘lishi mumkin.
• Database portini internetga ochiq qoldirish: 3306, 5432, 6379 va 9200 portlar botlar tomonidan doim skan qilinadi.
• CDN ishlatib, real IPni ochiq qoldirish: Xaker CDNni chetlab, serverga to‘g‘ridan-to‘g‘ri hujum qilishi mumkin.
• Qoidalarni hujjatsiz o‘zgartirish: Favqulodda holatda qaysi qoida nimaga xizmat qilishini tushunish qiyinlashadi.
• Backup kirish rejasiz: Noto‘g‘ri qoidada konsol kirish bo‘lmasa, uzilish uzoq davom etadi.

Praktik devor siyosati misoli

Kichik korporativ sayt uchun amaliy siyosat: keluvchi trafik standartda bloklangan; 443 barcha tashrif buyuruvchilar uchun ochiq; 80 faqat HTTPS redirect uchun ochiq; SSH faqat VPN yoki static admin IPdan kiradi; database localhost yoki private tarmoqda; CDN ishlatilsa 80/443 faqat CDN IPlaridan; Fail2ban SSH va web loginlarni monitoring qiladi; loglar markaziy monitoringga yuboriladi.

O‘rta e-tijorat saytida: payment callback IPlar allowlist qilinadi, admin panel VPN orqali kiriladi, API user-based quota qo‘llaniladi, WAFda SQL injection va XSS qoidalari yoqiladi, davlat yoki ASN bo‘yicha vaqtinchalik filtrlar tuziladi. Bu rejaning yozma bo‘lishi muhim – hujumda oldindan tayyor chora ko‘rish uzilish vaqtini qisqartiradi.

Test qilish: qoidalar ishlayaptimi?

Devor o‘rnatgandan so‘ng albatta test qiling. Boshqa tarmoqdan port skaneri qiling, SSH faqat ruxsatli IPdan ishlayotganini tekshiring, sayt HTTPS orqali ochilishini tekshiring, database port tashqaridan yopiq ekaniga ishonch hosil qiling. CDN ishlatsa, server IPga to‘g‘ridan-to‘g‘ri HTTP so‘rov yuborib bloklanganini tekshiring.

Testda ishlab chiqarish sistemani zararli tarqatmalar bilan tekshirmang. Maqsad – xavfsiz verifikatsiya. Har o‘zgarishdan so‘ng qoidalar majmuasini eksport qiling yoki qayd eting. Shunda muammo yuz bersa, oldingi sog‘lom konfiguratsiyaga qaytish oson.

Texnik xizmat va yangilanish rejasini tuzish

Server xavfsizligi – bu bir martalik o‘rnatish emas, doimiy texnik xizmat. Yangi xizmat qo‘shilganda port ehtiyojini qayta ko‘rib chiqing, eski xizmat o‘chirsa, ruxsatlarni olib tashlang, xavfsizlik yangilanishlarini o‘z vaqtida o‘rnating va loglarni muntazam tekshiring. Har oy ochiq port audit, har uch oy firewall qoidalarini ko‘rib chiqish – yaxshi boshlanishdir.

Backup reja ham xavfsizlik strategiyasining bir qismi. DDoS kirishni uzishi mumkin, lekin ransomware yoki yetkazilmagan kirish ma’lumot yo‘qotadi. Xavfsiz hosting, SSL, domen boshqaruvi va backup birga o‘ylanishi kerak. Shu nuqtada Xavfsiz hosting tanlayotganda e'tibor berilishi kerak bo'lgan narsalar va SSL sertifikati o'rnatilishi qanday amalga oshiriladi ichki havolalari muhim.

Xulosa

Server xavfsizlik devori DDoS va botlarga qarshi serverni butunlay ko‘rinmas qilmaydi; lekin hujum yuzasini sezilarli qisqartiradi, ruxsatsiz kirish xavfini kamaytiradi va hodisalarga tezroq va boshqariladigan javob qaytarish imkonini beradi. Eng to‘g‘ri natija: provayder-level DDoS himoyasi, CDN/WAF, qat’iy port siyosati, SSH cheklovi, Fail2ban, limitlar va log monitoringni birga qo‘llash orqali olinadi.

Agar yangi loyiha ishga tushirayotgan bo‘lsangiz, devor siyosatini boshidan rejalashtiring – so‘ng tuzatishdan osonroq. Hostragonsda server, hosting, domen va SSL infratuzilmasini tanlayotganda xavfsizlik ehtiyojini ham birga o‘ylab, bardoshli web muhit yarata olasiz. Boshlash uchun qisqa nazorat ro‘yxati: ochiq portlarni bloklang, SSHni cheklang, HTTPSni majburiy qiling va loglarni monitoring qiling.

Ko‘p so‘raladigan savollar

Server devori DDoS hujumini to‘liq bloklaydi mi?

Yo‘q. Mahalliy devor kichik va ba’zi protokol darajasidagi hujumlarni kamaytiradi, lekin katta DDoSda provayder-level himoya, CDN va WAF zarur.

Web serverda qaysi portlar ochiq bo‘lishi kerak?

Oddiy web serverda 80 va 443 portlar ochiq bo‘ladi. SSH port faqat admin IPga ruxsatli. Database va ichki xizmat portlari internetga yopiq bo‘lishi kerak.

UFW yoki firewallddan qaysi biri?

Ubuntu/Debian uchun UFW oson boshlanish beradi. AlmaLinux, Rocky Linux, RHELda firewalld keng tarqalgan. Murakkab va maxsus holatlarda nftables tanlanadi.

Bot trafikni faqat IP ban bilan to‘xtata olamanmi?

Ko‘pincha yo‘q. Zamonaviy botlar ko‘plab IP va proxy ishlatadi. IP ban bilan birga limitlar, WAF qoidalari, xatti-harakat tahlili, CAPTCHA va dasturga xos quota ham kerak.

Devor o‘rnatishda eng katta xavf nima?

Eng katta xavf – noto‘g‘ri qoida sabab SSH kirishni yo‘qotish. Shuning uchun avval SSH ruxsatini belgilash, ikkinchi sessiya bilan test qilish va provayder konsol kirish tayyor bo‘lishi zarur.