مدیران شبکه با بالا بردن اطلاعات خود در زمینه انواع حملات نقض کننده امنیت و راهکارهای مقابله با آنها، میتونن در بالا بردن ضریب امنیتی موثر باشن.
البته باید توجه داشت که در بحث امنیت، امنیت فیزیکی که رابطه مستقیم با $$$ داره، سهم بیشتری در بالا بردن ضریب امنیتی خواهد داشت ولی بروز کردن اطلاعات در زمینه راههای نفوذ و حملات ومقابله با آنها نیز میتونه بسیار مفید و موثر باشه...
هدف این تاپیک:
ارائه راهکارهای مفید امنیتی برای مقابله با حملات علیه سرورهای لینوکس:
همونطور که میدونید درهر سیستم یک سری ازپکتها اجازه عبور دارن که این مجوزها مطابق با نیاز وسیاست سازمانی خواهد بود و راهکارهای امنیتی که دراین تاپیک ارائه میشه، برفرض اینکه اختلالی درسیاست سازمانی ایجاد نمیکنن، میتونن مفید قلمداد بشن و طبیعتا در صورت ایجاد اختلال نباید استفاده شوند.
به هرحال هدف بهینه کردن امنیت هست نه تضمین کامل آن ...
(هرچند دربعضی موارد آسیب پذیربودن سیستم میتونه درنتیجه بعضی از سیاستهای سازمانی باشه ...)
yebordi
December 17th, 2012, 23:02
1- DNS
مهمترین نوع حملات DNS ، حملات Cache Poisoning هست که مهاجم میتونه به علت اشکال اساسی که در ساختار DNS سرورها وجود داره، رکوردهای جعلی در Cache یک DNS سرور تزریق کنه که باعث میشه وقتی کلاینت، درخواستی برای رکورد مورد نظر به سمت DNS سرورارسال میکنه، به سمت رکورد جعلی که در Cache، جایگزین رکورد اصلی شده، تغییر مسیر پیدا کنه...
یک black hat باهوش میتونه با آلوده کردن رکوردهای DNS به بهترین شکل ممکن سوءاستفاده کنه، مثلا:
1-مهاجم میتونه یک رکورد DNS رو به یک Domain name اختصاص بده که توسط Google AdSense به عنوان یک آگهی تبلیغاتی در وب سایتها نشون داده میشه. اگر مهاجم این Domain name رو به یک Banking Trojan آلوده کرده باشه، ویزیتورهای وب سایتهایی که اون Domain name از طریق google ads در آنها بارگذاری میشه، بطور ناخواسته آلوده به Banking Trojan میشن و...
2- همینطور میتونه رکورد DNS رو به Domain name آلوده کنه که این Domain name میتونه یک نسخه کپی شده باشه از یک وب سایت بانکی یا موسسات مالی که در وب سایتشون امکان تراکنش اینترنتی دارن. (Malicious Banking Web page)
ویزیتورهای از همه جا بی خبر، با تغییر مسیر به سمت نسخه کپی شده وب سایت بانکی، با وارد کردن اطلاعات حساب بانکی خود ...
اگر مهاجم، DNS سرور یک ISP بزرگ رو از این طریق آلوده کنه، طبیعتا قربانیان زیادتری خواهد داشت.
راهکارهای امنیتی مفید:
(CentOS v5.x- RHEL v5.x)
1- تنظیمات iptables
2- تنظیمات iptables برای ممانعت از cache poisoning
3- تنظیمات BIND DNS Server (پیکربندی TSIG و...)
#vi etc/sysconfig/iptables/
اضافه کردن خطوط زیر قبل از خطهای LOG و DROP:
کد:
-A RH-Firewall-1-INPUT -m state --state NEW -p udp --dport 53 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT
سپس:
کد:
# service iptables restart
تنظیمات iptables برای ممانعت از cache poisoning(برای یک یا تعداد کمی از Domain ها)
(تست شده روی CentOS سرور، با اینکار از درخواستهای DNS تکراری توسط مهاجم جلوگیری میشه)
تنظیمات زیر رو برای Domainهای زیاد، نباید انجام داد، چون فایروال روانی میشه... file:///I:/Security/Anti%20ddos/anto%20solaris_files/05.gif
rule1 و rule2:
کد:
-A RH-Firewall-1-INPUT -p udp -m udp -m recent -i eth0 --dport 53\ --update --seconds 660 --hitcount 7 --name DNSTHROTTLE --rsource -j DROP -A RH-Firewall-1-INPUT -p udp -m udp -m recent -i eth0 --dport 53\ -j ACCEPT --set --name DNSTHROTTLE --rsource
ترکیب rule اول و دوم، باعث میشه میزان DNS query دراین حملات محدود بشه،rule اول به تنهایی تاثیری نداره ولی ترکیب اون با rule دوم، باعث میشه درخواستهای DNS query برای
یک ip آدرس (entry) با استفاده ازنتایج ان در مموری فایل proc/net/ipt_recent/DNSTHROTTLE/ محدود شود.
yebordi
December 17th, 2012, 23:19
با سلام:
قبل از ادامه تاپیک، اشاره به چند نکته:
1- درباره قوانینی که برای فایروال به جهت جلوگیری از حملات Cache Poisoning، درپست قبلی گفته شد، باید به این موضوع اشاره کرد که چون دراین حملات، مهاجم معمولا چندین درخواست query رو درمدت زمان کوتاهی ارسال میکنه (مثلا 10 درخواست در مدت 10 دقیقه یا حتی کمتر ازیک دقیقه) به کاربردن این قوانین باعث میشه فایروال، بسته ها با IP آدرس یکسان که
7 درخواست درمدت 660 ثانیه (11دقیقه) داشته باشن وبا بررسی درخواستهای اون IP آدرس درمموری فایل DNSTHROTTLE ، بهشون اجازه عبور نده و این بسته ها دور ریخته میشن (drop) وعملا حمله مهاجم، ناموفق خواهد بود و برای بسته سالم با استفاده از cache، با حداقل اجازه جستجو برای اون domain، به درخواست کاربر پاسخ داده میشه.
2- برای Domainهای زیاد، نمیشه ازراهکار قبلی استفاده کرد. چون درخواستهای سالم برای Domainهای زیاد، طبیعتا بیشترهستش و کاربرد این قوانین باعث میشه فایروال توانایی تشخیص بسته های سالم رو از بسته های ناسالم نداشته باشه.
در این حالت میشه از SNAT در iptables کمک گرفت:
چون درحملات آلوده کردن cache، پیش بینی پورت مبدا توسط مهاجم بعنوان شرط لازم برای تدارک دیدن این حملات محسوب میشه، پس اگربا iptables بتونیم پورت مبدا که توسط BIND استفاده میشه رو به پورت مبدا دیگه بصورت random تغییر بدیم، عملا کارمهاجم رو برای پیش بینی پورت مبدا، مشکل کردیم.
iptables میتونه اینکار رو با SNAT وبا استفاده از آپشن random-- براحتی انجام بده:
(SNAT توانایی تغییردادن پورتهای مبدا رو برای هم tcp وهم udp داره...)
کد:
# iptables -t nat -I POSTROUTING 1 -p udp -s "your DNS server IP" --dport 53 -j SNAT --to "your DNS server IP" --random
ولی مهاجم میتونه با استفاده از nmap، پورت مبدا تصادفی رو که SNAT برای درخواستهای یک domain اختصاص داده رو بدست بیاره، مثلا با این دستور:
کد:
# nmap --source-port 6666 -P0 -p 53 -sU "domain IP1" "domain IP2"
برای حل این مشکل میشه با تنظیم تایمرها (مثلا 30 ثانیه) در nf_ct_udp_timeout و
nf_ct_udp_timeout_stream در فایل net/netfilter/nf_conntrack_proto_udp.c/ باعث شد تا
SNAT پورت مبدا تصادفی برای درخواستهای یک domain خاص رو هر 30 ثانیه یکبار تغییر بده .
yebordi
December 17th, 2012, 23:45
تنظیمات BIND DNS Server:
--------------------------------------------
DNS سرورها در لینوکس و یونیکس، اغلب از پکیج های نرم افزاری BIND استفاده میکنن. نسخه های قدیمی BIND دارای باگهای متعددی هستن ونسخه 9 امنیت بیشتری نسبت به سایر نسخه های BIND داره.
BIND: Berkeley Internet Name Domain
درBIND برای امنیت پیام های DNS وایمنی ارتباط سرورهای DNS با هم، بهتره که ازمکانیزم TSIG
استفاده بشه. TSIG: Transaction SIGnature
(مکانیزم TSIG برای نسخه های BIND v8.2 و بالاترمناسبه)
TSIG ازطریق کلید اختصاصی رمزنگاری اشتراکی بین سرورها، امنیت پیامهای DNS رو تامین میکنه و از یک تابع یکطرفه hash، برای تایید اعتبار پیام های DNS استفاده میکنه که این خودش باعث ممانعت از حملات man in the middle میشه و مهاجم نمیتونه خودش رو بجای DNS جا بزنه. علاوه بر این، TSIG توانایی حفاظت از دیتای مبادله شده بین 2 سرورDNS رو داره، مثل درخواستهای query برگشتی ویا zone transfer و ...
برای پیکربندی TSIG باید با استفاده از برنامه dnssec-keygen، واجرای دستور زیر برروی
master server، کلیدهای عمومی واختصاصی (public key- private key) رو بسازیم:
کد:
#dnssec-keygen -a HMAC-MD5 -b 128 -n HOST rndc-key
دردستوربالا در آپشن n- بجای HOST، بسته به تغییراتی که درفایل var/named/chroot/etc/named.conf/ درزمان نصب BIND برای پیکربندی سرورهای master-slave ایجاد میشه، میتوان از نامهای zone,entity, user استفاده کرد. برنامه dnssec-keygen برای ساختن کلیدها از الگوریتم رمزنگاری متقارن مانند hmac-md5 استفاده میکنه که با آپشن a- مشخص میشه و آپشن b- سایز کلید رو تعیین میکنه...
خروجی این دستور بصورت دو فایل هستش که فایل key. شامل کلید عمومی وفایل private. شامل کلید اختصاصی هست، مثال:
کد:
Krndc-key.+124+48236.key Krndc-key.+124+48236.private
تنظیمات TSIG برای master server:
برای اینکار باید private key رو درفایل tsig.key معرفی کنیم وبرای آگاهی ازاین کلید، کافیست محتویات فایل private. رو ببینیم:
کد:
# cat Krndc-key.+124+48236.private
خروجی یک کلید 24 رقمی هست که باید در کد زیر وارد بشه وبرای اینکار باید
فایل var/named/chroot/etc/tsig.key/ ویرایش کنیم:
(بدیهی است که در کد زیردرصورت داشتن سرورهای Slave بیشتر، ipها رو مثل سرور1 باید وارد کنیم.)
کد:
key "TRANSFER" { algorithm hmac-md5; secret " your private key "; }; # Slave server IP # 1 server your slave server ip { keys { TRANSFER; };
خط زیر در فایل var/named/chroot/etc/named.conf/ اضافه و ذخیره می کنیم:
کد:
include "/etc/tsig.key";
کد:
# service named restart
yebordi
December 18th, 2012, 00:06
تنظیمات TSIG برای slave server:
مثل تنظیمات master server هستش با این تفاوت که برای ساختن فایل tsig.key باید ip آدرس
master server را در کد زیر وارد کنیم:
کد:
key "TRANSFER" { algorithm hmac-md5; secret " your private key "; }; # Master server IP server your master server ip { keys { TRANSFER; }; };
و برای مشاهده لاگ فایلهای master BIND DNS server:
کد:
# grep 'theos.in/IN' /var/log/syslog
یا:
کد:
# tail -f /var/log/syslog
yebordi
December 18th, 2012, 00:08
2- Port Scan
Port Scan Attack Detector: PSAD
همونطور که میدونید ناقضان امنیتی بویژه Crackers، فبل از شروع نفوذ، با اسکن
کردن شبکه برای آگاهی ازپورتهای بازو سایر اطلاعات مفید دیگه ازnmap استفاده
میکنند.با مشاهده لاگهای var/log/message/ میتونید الگوهای اسکن شبکه رو ببینید
ولی ابزارPSAD با آنالیزلاگهای iptables میتونه حملات پورت اسکن و DDOS و
ترافیکهای مشکوک رو تشخیص، اعلان هشدار وبلوک کنه.
psad برای تشخیص از الگوهای تعریف شده tcp,udp,icmp برای snort IDS،
استفاده میکنه وبه هنگام اسکن پورتهای tcp، با آنالیزflagها وتطابق با آپشن های
nmap، نوع اسکن رو تعیین میکنه. (مثلا: syn, fin, xmas)
پیکربندی psad:
---------------------------
ویرایش فایل: vi /etc/syslog.conf # و اضافه کردن این خط:
کد:
kern.info |/var/lib/psad/psadfifo
استفاده از این دستور برای آپدیت کردن فایل syslog.conf:
# /etc/init.d/sysklogd restart # /etc/init.d/klogd
ویرایش فایل vi /etc/psad/psad.conf #:
واردکردن email ID برای آگاهی شما ازتشخیص پورت اسکن وپورتهای ignore
(مثلا 53 و 5000) و تنظیمات دیگه...
(psad آپشن های زیادی داره که میتونید متناسب با نیازتون ازآنها استفاده کنید.)
اضافه کردن این دو rule درiptables برای لاگ کردن هرچیزی توسط psad:
کد:
iptables -A INPUT -j LOG iptables -A FORWARD -j LOG
برای دیدن گزارش پورت اسکن با psad:
کد:
# psad -S
برای حذف کردن ipهای بلوک شده:
کد:
# psad -F
مشاهده لاگ هر ip آدرس:
(var/log/psad/ip.address/ directory/)
کد:
# cd /var/log/psad/82.11.194.60 # ls -l
yebordi
December 18th, 2012, 00:11
3- Brute Force
همونطور که میدونید حملات ورود به زور (dictionary - brute force) روش هایی هستن که مهاجم با تست کردن stringها بصورت تصادفی، به مقدار مساوی با مقدار پسورد دسترسی پیدا میکنه...
با مشاهده خطاهای زیر در بررسی لاگها مثلا در var/log/apache2/ مشخص میشه که سرور با حمله ورود به زور مواجه بوده:
کد:
client sent HTTP/1.1 request without hostname (see RFC 2616 section 14.23): /...... Invalid URL in request p-Alive: 300 request failed: error reading the headers
ابزار fail2ban با اسکن لاگ فایلهای var/log/pwdfail/ یا var/log/apache/error_log/ میتونه
IP آدرسهایی که در این لاگها با تست پسوردها، موفق به لاگین نشدن رو ban کنه.
fail2ban برای اکثر توزیع های لینوکس مناسبه و تنظیمات اون بطور پیش فرض برای مقابله با
حملات SSH brute force هست و میشه بعضی از پارامترهای مهم رو در فایل پیکربندی
etc/fail2ban.conf/ برحسب شرایط ونیاز تغییر داد:
ignoreip
بطور پیش فرض ip آدرسی در این لیست وجود نداره و میشه لیستی از ipها رو قرار داد که توسط fail2ban نادیده گرفته بشه و ban نشن.
ignoreip = 192.168.10.25
maxfailures
تعداد دفعاتی که هر ip میتونه پسورد رو برای لاگین شدن تست کنه وبطور پیش فرض 5 بار هست و بهتره که به 3 بار کاهش پیدا کنه.
maxfailures= 3
bantime
مدت زمانی که ip بن میشه بطور پیش فرض 600 ثانیه هستش وبا تنظیم این پارامتر بصورت 1- باعث میشه ipها برای همیشه بن بشن.
bantime= -1
تمام کارهای fail2ban در این مسیرvar/log/fail2ban.log/ لاگ میشه و با مشاهده این لاگها، ipهایی که پورت ssh برای اونا بلوک شده قابل مشاهده هست:
کد:
2010-01-02 04:28:39,261 INFO: SSH: 192.168.10.32 has 3 login failure(s). Banned. 2010-01-02 04:28:39,287 WARNING: SSH: Ban (permanent) 192.168.10.32
در fail2ban میشه sectionهای دیگه که بطور پیش فرض غیرفعال هستند رو مثلا:
VSFTPD, PROFTPD, Apache, SALS, ApacheAttacks فعال کرد، برای اینکار درتعاریف
iptables میشه در (fail2ban-(name_of_section، نام section دلخواه رو وارد کنیم، مثال:
fail2ban-PROFTPD یا fail2ban-SSH و...
کد:
fwchain = INPUT fwstart = iptables -N fail2ban-(name_of_section) iptables -A fail2ban-(name_of_section) -j RETURN iptables -I (fwchain)s -p %(protocol)s --dport (port)s -j fail2ban-(name_of_section) fwend = iptables -D (fwchain)s -p (protocol)s --dport (port)s -j fail2ban-(name_of_section) iptables -F fail2ban-(name_of_section) iptables -X fail2ban-(name_of_section) fwcheck = iptables -L (fwchain)s | grep -q fail2ban-(name_of_section) fwban = iptables -I fail2ban-(name_of_section) 1 -s -j DROP fwunban = iptables -D fail2ban-(name_of_section) -s -j DROP
با این کار، fwstart برای هر section که فعال کرده باشیم یک iptables chain متفاوت میسازه مثلا
برای fail2ban-SSH، زنجیره زیر رو میسازه و یعنی تمام ترافیک SSH بدون تغییر به این زنجیره
منتقل میشه.
کد:
iptables -L -n Chain INPUT (policy ACCEPT) fail2ban-SSH tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 Chain fail2ban-SSH (1 references) RETURN all -- 0.0.0.0/0 0.0.0.0/0
حالا میشه با استفاده از rule جدیدی که برای ip مهاجم در این زنجیره تعریف میکنیم، ترافیک SSH
رو کنترل کنیم. با مشاهده لاگها var/log/fail2ban.log/ ومشخص شدن ipهای مهاجم،
هاست های مهاجم رو میشه بلوک کرد. مثلا:
(تمام ترافیک SSH از این هاست 192.168.10.32 دور ریخته میشه)
4- DDOS- DOS
مهاجم دراین نوع حملات، سایتها یا سرویس های میزبانی شده توسط وب سرور وحتی سرورهای DNS رو هدف قرار میده، اجرای بسیار کند برنامه ها، از کار افتادن سرویسها (HTTP)، درخواستهای بسیار زیاد ازکانکشن های شبکه های مختلف، در دسترس نبودن سایتهای روی سرور و بار زیاد اعمال شده روی CPU از نشانه های قرار گرفتن درمعرض این حملات است.
انواع حملات DDOS:
Trinoo- TFN/TFN2K- Stacheldraht- Shaft- mstream
انواع حملات DOS:
Smurf/Fraggle- Ping of Death- SSPing- Land- SYN Flood
CPU Hog- RPC Locator- Jolt2- Bubonic- Targa
بطورکلی روشهای مقابله با این نوع حملات، متفاوته چون پکتهای SYN جزء ترافیک نرمال محسوب میشن و مهاجم میتونه از fake IPs استفاده کنه و مدت زمان حملات میتونه طولانی باشه و...
افزایش تعداد سرورها وافزایش سایز table کانکشن ها و گسترش فایروالها وبکارگیری اونا برای مقابله با syn flood و... میتونه راهکارهای مفید برای مقابله با این حملات باشه.
با راهکارهای منطقی هم میشه با این حملات مقابله کرد، ازجمله:
1- تشکیل تیم DSE (برای شرکت هایی که همیشه در دسترس بودن برای اونا امری ضروری هست.)
(Dedicated Security Expert Team)
2- استفاده ازچک لیست عمومی. مثلا:
آپدیت کردن سیستم ها به منظور کاهش آسیب پذیری کرنل ونرم افزارها
چک کردن سیستم ها به منظور آلوده بودن به rootkits
چک کردن لاگها به منظور port sniffing
چک کردن پردازش های مخفی با استفاده از مقایسه خروجی های ps و lsof
اسکن سیستم ها با استفاده از Nessus یا SARA یا SAINT
چک کردن کارائی CPU و Memory سیستم به منظوردرحد میانگین ونرمال بودن
3- اضافه کردن ماژول Mod_dosevasive به apache به منظور مقابله با DDOS و ورود به زور
4- نصب ماژول mod_security (http://http/www.modsecurity.org/documentation/Securing_Web_Services_with_ModSecurity_2.0.pdf) برای آنالیز درخواستها قبل از انتقال اونا
به وب سرور وکنترل ترافیک HTTP.
5- حفاظت در برابر ip spoofing و TCP SYN cookies، با ویرایش فایل etc/sysctl.conf/ :
مقابله با dDoS با استفاده از DROP list:
DROP list شامل لیست ipهای zombie و ip هایی است که مهاجمین از اونا برای dDoS استفاده
میکنن و یا اکثر اسپمرهای شناخته شده مثل ARIN, LACNIC, APNIC, RIPE از این لیست برای اسپم و اسکن و...استفاده میکنند. با این روش، میشه بسیاری از ترافیک های مضر رو بلوک کرد.
برای بکاربردن DROP list میشه از این شل اسکریپت برای firewall /router /dedicated Linux web-mail server استفاده کرد:
کد:
#!/bin/bash FILE="/tmp/drop.lasso" URL="http://www.spamhaus.org/drop/drop.lasso" echo "" echo -n "Applying DROP list to existing firewall..." [ -f $FILE ] && /bin/rm -f $FILE || : cd /tmp wget $URL blocks=$(cat $FILE | egrep -v '^;' | awk '{ print $1}') iptables -N droplist for ipblock in $blocks do iptables -A droplist -s $ipblock -j LOG --log-prefix "DROP List Block" iptables -A droplist -s $ipblock -j DROP done iptables -I INPUT -j droplist iptables -I OUTPUT -j droplist iptables -I FORWARD -j droplist echo "...Done" /bin/rm -f $FILE
با استفاده از این اسکریپت، لیست ipهای بلوک، هر24 ساعت یکبار آپدیت میشه و با هر بار
اجرا، بلوک لیست ازاین لینک http://www.spamhaus.org/drop/drop.lasso دانلود میشه و
تغییرات ipها در لیست اعمال میشه.
yebordi
December 18th, 2012, 00:42
مقابله با slowloris dDoS attack با استفاده از ماژول mod_qos:
(تست شده روی Apache2/Debian)
ماژول quality of service برای وب سرورهای Apache، مکانیزمی برای اولویت بندی و کنترل
درخواستهای http هست.
slowloris توسط RSnake و به زبان perl نوشته شده و میتونه درحمله dDoS بر روی وب سرور
apache و سرور squid caching pro/xy استفاده بشه.
البته سرورهای IBM http و IBM webSphere edge caching pro/xy هم نسبت به slowloris
آسیب پذیرن.
slowloris بطورمداوم صدها درخواست معتبر http رو به سمت سرور ارسال میکنه وبا تولید کمترین ترافیک tcp برای این درخواستها، این کانکشن ها رو باز نگه داره تا سرور ازپا دربیاد ودیگه سرورنمیتونه به ترافیک سالم http پاسخ بده...
حتی شبکه هایی که از سخت افزارهای load balancer هم استفاده میکنن، وب سرورشون به slowloris dos آسیب پذیر هست.
mod-qos میتونه با محدود کردن تعداد کانکشن های tcp وغیرفعال کردن keep-alive برای کانکشن tcp (مثلا هنگامیکه کانکشن های tcp به بیش از 70% برسه) و برای جلوگیری از بازبودن کانکشن های slowloris که هیچ درخواستی ندارن با درنظر گرفتن حداقل میزان data rate برای این درخواستها وپاسخ دادن به اونا با slowloris مقابله کنه.
ماژول mod-qos ازلینک mod_qos | Free software downloads at SourceForge.net (http://sourceforge.net/projects/mod-qos) قابل دریافت هست.
فعال سازی و پیکربندی mod-qos:
ویراش فایل vi qos.load# :
کد:
LoadModule qos_module /usr/lib/apache2/modules/mod_qos.so
ویراش فایل vi qos.conf# :
کد:
## QoS Settings <IfModule mod_qos.c> # handles connections from up to 100000 different IPs: QS_ClientEntries 100000 # will allow only 50 connections per IP: QS_SrvMaxConnPerIP 50 # maximum number of active TCP connections is limited to 256: MaxClients 256 # disables keep-alive: QS_SrvMaxConnClose 180 # minimum request/response speed (slowloris keeping connections open without requesting anything): QS_SrvMinDataRate 150 1200 # and limit request header and body: # LimitRequestFields 30 # QS_LimitRequestBody 102400 </IfModule>
فعال کردن ماژول و راه اندازی مجدد apache:
کد:
a2enmod qos /etc/init.d/apache2 restart
yebordi
December 18th, 2012, 00:43
مقابله با SYN-flood DOS Attack:
SYN flood یکی از انواع حملات dos هست که مهاجم درخواستهای پیاپی SYN
رو به سمت سرور ارسال میکنه و این نوع حمله dos بر روی شبکه های مدرن
تاثیری نداره و درواقع اگه سرور بیاد قبل از اینکه ACK رو دریافت کنه،
resourceها رو به درخواست های SYN اختصاص بده، میشه گفت که این سرور
به این نوع ازdos آسیب پذیرهست.
برای مقابله میتونیم تمام کانکشن های ورودی tcp رو مجاز تلقی کنیم به شرطی که
تابع محدودیت تعریف شده درiptables باشن.
برای تعریف این محدودیت، میتونیم ماکزیمم تعداد پکتهای syn که پشت سرهم ارسال
میشن (limit-burst) رو برابربا 3 قراربدیم (بطور پیش فرض 5 پکت هست) و
limit-rate هم برابر1/s قرار بدیم تا کانکشن هایtcp درهرثانیه پذیرفته بشن ونهایتا
پکتهای syn ناسالم، drop بشن.برای اینکار دراسکریپت iptables، میتونیم این
ruleها رو اضافه کنیم:
کد:
# SYN-flood protection: iptables -N syn_flood iptables -A INPUT -p tcp --syn -j syn_flood iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN iptables -A syn_flood -j DROP
-----------------
مثال دیگه:
هم چنین میتونیم با استفاده ازlimit-rate و limit-burst کانکشنهای ورودی icmp رو
محدود کنیم، با تعریف این ruleها در iptables:
rule اول، کانکشن های ping رو درهرثانیه با1پکت (1=brust) قبول میکنه و rule
دوم درفایل var/log/message/ برای پکت متخلف (ping-drop) لاگ میسازه و
rule سوم پکت متخلف رو drop میکنه و rule چهارم اجازه میده به درخواست ping
که ازطرف کانکشن حاضر(سالم) ارسال شده، پاسخ داده بشه.
کد:
# Limiting the incoming icmp ping: iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j ACCEPT iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j LOG --log-prefix PING-DROP: iptables -A INPUT -p icmp -j DROP iptables -A OUTPUT -p icmp -j ACCEPT
(شما میتونید limit-rate و limit-burst رو بر اساس ترافیک شبکه خودتون وبا
توجه به نیازوشرایط خودتون تنظیم کنید.)