ارائه راهکارهای مفید امنیتی برای مقابله با حملات علیه سرورهای لینوکس

[yebordi]

سلام

مدیران شبکه با بالا بردن اطلاعات خود در زمینه انواع حملات نقض کننده امنیت و راهکارهای مقابله با آنها، میتونن در بالا بردن ضریب امنیتی موثر باشن.
البته باید توجه داشت که در بحث امنیت، امنیت فیزیکی که رابطه مستقیم با $$$ داره، سهم بیشتری در بالا بردن ضریب امنیتی خواهد داشت ولی بروز کردن اطلاعات در زمینه راههای نفوذ و حملات ومقابله با آنها نیز میتونه بسیار مفید و موثر باشه...

هدف این تاپیک:

ارائه راهکارهای مفید امنیتی برای مقابله با حملات علیه سرورهای لینوکس:

همونطور که میدونید درهر سیستم یک سری ازپکتها اجازه عبور دارن که این مجوزها مطابق با نیاز وسیاست سازمانی خواهد بود و راهکارهای امنیتی که دراین تاپیک ارائه میشه، برفرض اینکه اختلالی درسیاست سازمانی ایجاد نمیکنن، میتونن مفید قلمداد بشن و طبیعتا در صورت ایجاد اختلال نباید استفاده شوند.
به هرحال هدف بهینه کردن امنیت هست نه تضمین کامل آن ...
(هرچند دربعضی موارد آسیب پذیربودن سیستم میتونه درنتیجه بعضی از سیاستهای سازمانی باشه ...)

[yebordi]

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 و...)

[yebordi]

تنظیمات iptables
ویرایش فایل etc/sysconfig/iptables/ :

کد:

#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های زیاد، نباید انجام داد، چون فایروال روانی میشه... [IMG]file:///I:/Security/Anti%20ddos/anto%20solaris_files/05.gif[/IMG]

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]

با سلام:

قبل از ادامه تاپیک، اشاره به چند نکته:

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]

تنظیمات 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]

تنظیمات 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]

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:

کد:

echo -e ’kern.info\t|/var/lib/psad/psadfifo’ >> /etc/syslog.conf
Restart syslog:
کد:

# /etc/init.d/sysklogd restart # /etc/init.d/klogd
ویرایش فایل vi /etc/psad/psad.conf #:
واردکردن email ID برای آگاهی شما ازتشخیص پورت اسکن وپورتهای ignore
(مثلا 53 و 5000) و تنظیمات دیگه...
(psad آپشن های زیادی داره که میتونید متناسب با نیازتون ازآنها استفاده کنید.)

کد:

EMAIL_ADDRESSES your ID@your distination; IGNORE_PORTS udp/53, udp/5000; ENABLE_AUTO_IDS Y; IPTABLES_BLOCK_METHOD Y;
کد:

# /etc/init.d/psad restart

[yebordi]

اضافه کردن این دو 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]

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 دور ریخته میشه)

کد:

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) DROP all -- 192.168.10.32 0.0.0.0/0

[yebordi]

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.
5- حفاظت در برابر ip spoofing و TCP SYN cookies، با ویرایش فایل etc/sysctl.conf/ :

کد:

net.ipv4.conf.all.rp_fil/ter = 1 net.ipv4.tcp_syncookies = 1