Defense against ATTACKS in Linux Server

[neda_atishpare]

Defense against ATTACKS on Linux Server
ِ
با سلام:

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

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

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

::Attention::

!!No warranty that described rules can really protect your system!!

[neda_atishpare]

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 میشن و...
:cool: :cool:

2- همینطور میتونه رکورد DNS رو به Domain name آلوده کنه که این Domain name میتونه یک نسخه کپی شده باشه از یک وب سایت بانکی یا موسسات مالی که در وب سایتشون امکان تراکنش اینترنتی دارن. (Malicious Banking Web page)
ویزیتورهای از همه جا بی خبر، با تغییر مسیر به سمت نسخه کپی شده وب سایت بانکی، با وارد کردن اطلاعات حساب بانکی خود ... :cool: :ii: :ii
اگر مهاجم، DNS سرور یک ISP بزرگ رو از این طریق آلوده کنه، طبیعتا قربانیان زیادتری خواهد داشت.

راهکارهای امنیتی مفید:
(CentOS v5.x- RHEL v5.x)
1- تنظیمات iptables
2- تنظیمات iptables برای ممانعت از cache poisoning
3- تنظیمات BIND DNS Server (پیکربندی TSIG و...)

[neda_atishpare]

تنظیمات 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های زیاد، نباید انجام داد، چون فایروال روانی میشه... :cool:

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/ محدود شود.

[neda_atishpare]

با سلام:

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

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 ثانیه یکبار تغییر بده .

[neda_atishpare]

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

[neda_atishpare]

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

[neda_atishpare]

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

[neda_atishpare]

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

[neda_atishpare]

3- Brute Force
همونطور که میدونید حملات ورود به زور (dictionary - brute force) روش هایی هستن که مهاجم با تست کردن stringها بصورت تصادفی، به مقدار مساوی با مقدار پسورد دسترسی پیدا میکنه...
با مشاهده خطاهای زیر در بررسی لاگها مثلا در var/log/apache2/ مشخص میشه که سرور با حمله ورود به زور مواجه بوده:

client sent [Only registered and activated users can see links] 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
RETURN all -- 0.0.0.0/0 0.0.0.0/0

[neda_atishpare]

4- Root SSH Login
برای ایمن سازی ssh:

TNX to Dear eychenz
[Only registered and activated users can see links]

5- 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 ([Only registered and activated users can see links]) برای آنالیز درخواستها قبل از انتقال اونا
به وب سرور وکنترل ترافیک [Only registered and activated users can see links]
5- حفاظت در برابر ip spoofing و TCP SYN cookies، با ویرایش فایل etc/sysctl.conf/ :

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

[neda_atishpare]

بلوک کردن شبکه های مهاجم:
برای اینکار وبن کردن ipها با کانکشن های زیاد، میشه از اسکریپت ها استفاده کرد:

TNX to Dear Virangar
[Only registered and activated users can see links]

هم چنین میشه با استفاده از w یا uptime، میانگین بار روی CPU رو مشاهده کرد:

Neda@workstation >w
10:42:23 up 1 day, 16:39, 7 users, load average: 0.80, 0.80, 0.59

و برای مشاهده تعداد پردازش های [Only registered and activated users can see links]

root@Neda root# ps -aux|grep -i HTTP|wc -l
32

بطور متوسط اگر از یک IP آدرس، بیشتر از 30 کانکشن داشته باشین، شما در معرض attack هستین.
چون درحالت نرمال این تعداد کانکشن از یک ip آدرس، بندرت اتفاق می افته. برای دیدن ip آدرس
کانکشن های ثابت، میشه از این دستور استفاده کرد:

# netstat -lpn|grep :80|awk '{print $5}'|sort

اگر بیشتر از 5 تا Hosts/IPs ازشبکه یکسان کانکت شده باشن، کاملا واضح هست که ddos شدین و برای تشخیص این شبکه ها میشه از دستور whois استفاده کرد و سپس شبکه های مهاجم رو با تعریف این rule در iptables بلوک کرد:

iptables -A INPUT -s <Attacker IP> -j DROP

[neda_atishpare]

مقابله با 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="[Only registered and activated users can see links]"
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 ساعت یکبار آپدیت میشه و با هر بار
اجرا، بلوک لیست ازاین لینک [Only registered and activated users can see links] دانلود میشه و
تغییرات ipها در لیست اعمال میشه.
اگر از روترهای Cisco استفاده میکنید، میشه ازاسکریپت ضمیمه شده در فایلهای پیوست استفاده کرد.

[neda_atishpare]

مثال: بلوک لیست به تاریخ امروز: 2010/10/2

; Spamhaus DROP List 2/10/10 - (c) 2010 The Spamhaus Project
109.94.212.0/22 ; SBL84898
110.44.0.0/20 ; SBL74731
116.199.128.0/19 ; SBL56563
119.42.144.0/21 ; SBL70035
121.46.64.0/18 ; SBL72673
128.168.0.0/16 ; SBL51908
128.199.0.0/16 ; SBL62478
132.232.0.0/16 ; SBL9176
132.240.0.0/16 ; SBL68517
134.33.0.0/16 ; SBL7097
138.252.0.0/16 ; SBL9702
138.43.0.0/16 ; SBL69354
139.167.0.0/16 ; SBL64740
140.170.0.0/16 ; SBL79701
143.135.0.0/16 ; SBL84946
143.49.0.0/16 ; SBL7182
148.178.0.0/16 ; SBL79700
148.248.0.0/16 ; SBL84763
150.141.0.0/16 ; SBL79702
150.230.0.0/16 ; SBL78129
152.147.0.0/16 ; SBL8847
167.28.0.0/16 ; SBL75680
167.97.0.0/16 ; SBL12947
168.151.0.0/16 ; SBL73292
170.25.0.0/16 ; SBL84900
170.67.0.0/16 ; SBL8148
187.16.192.0/19 ; SBL76362
188.130.250.0/23 ; SBL83604
190.112.0.0/19 ; SBL76260
192.160.44.0/24 ; SBL9493
192.223.64.0/18 ; SBL85852
192.26.25.0/24 ; SBL84941
192.31.212.0/23 ; SBL84945
192.43.153.0/24 ; SBL69615
192.43.154.0/23 ; SBL69616
192.43.156.0/22 ; SBL69617
192.43.160.0/24 ; SBL69618
192.43.175.0/24 ; SBL84942
192.43.176.0/21 ; SBL84943
192.43.184.0/24 ; SBL84944
192.67.16.0/24 ; SBL6648
192.86.85.0/24 ; SBL69619
193.104.106.0/24 ; SBL83510
193.104.110.0/24 ; SBL82582
193.104.12.0/24 ; SBL83599
193.104.153.0/24 ; SBL84254
193.104.22.0/24 ; SBL83509
193.104.27.0/24 ; SBL81900
193.104.41.0/24 ; SBL82374
193.104.94.0/24 ; SBL85667
193.110.136.0/24 ; SBL3399
193.138.172.0/22 ; SBL72612
193.142.244.0/24 ; SBL57948
193.16.100.0/24 ; SBL61945
193.169.250.0/23 ; SBL82277
193.238.36.0/22 ; SBL40543
193.27.246.0/23 ; SBL70826
194.110.160.0/22 ; SBL60306
194.116.146.0/23 ; SBL50590
194.126.193.0/24 ; SBL58152
194.143.130.0/23 ; SBL78840
194.146.204.0/22 ; SBL51152
194.165.4.0/23 ; SBL74236
194.8.74.0/23 ; SBL76200
195.114.8.0/23 ; SBL48773
195.225.176.0/22 ; SBL47622
195.234.159.0/24 ; SBL57950
195.238.242.0/24 ; SBL57947
195.5.168.0/24 ; SBL81786
195.74.88.0/23 ; SBL53174
195.78.122.0/23 ; SBL82373
195.88.190.0/23 ; SBL79119
195.88.32.0/23 ; SBL75285
195.93.184.0/23 ; SBL83327
195.93.208.0/23 ; SBL80356
195.95.151.0/24 ; SBL80032
195.95.155.0/24 ; SBL84230
195.95.161.0/24 ; SBL42935
196.1.176.0/20 ; SBL73088
196.32.216.0/21 ; SBL66614
198.151.152.0/22 ; SBL23969
198.186.16.0/20 ; SBL75933
198.186.25.0/24 ; SBL23976
198.204.0.0/21 ; SBL8179
199.120.163.0/24 ; SBL6658
199.166.200.0/22 ; SBL6026
199.245.138.0/24 ; SBL9923
199.60.102.0/24 ; SBL9159
200.106.128.0/20 ; SBL85870
200.115.96.0/20 ; SBL85853
200.123.224.0/20 ; SBL85855
200.124.160.0/21 ; SBL85854
200.22.0.0/16 ; SBL84896
200.50.192.0/19 ; SBL77554
201.71.0.0/20 ; SBL38197
203.19.101.0/24 ; SBL6619
203.31.88.0/23 ; SBL8083
203.34.205.0/24 ; SBL7330
203.34.70.0/23 ; SBL9682
203.34.71.0/24 ; SBL7244
204.13.32.0/21 ; SBL37362
204.236.0.0/19 ; SBL46767
204.52.255.0/24 ; SBL13483
204.89.224.0/24 ; SBL11667
205.210.137.0/24 ; SBL25844
205.235.64.0/20 ; SBL8558
205.236.189.0/24 ; SBL9442
206.197.175.0/24 ; SBL14246
206.197.176.0/24 ; SBL14250
206.197.177.0/24 ; SBL14248
206.197.28.0/24 ; SBL14253
206.197.29.0/24 ; SBL14251
208.77.224.0/21 ; SBL62629
208.81.136.0/21 ; SBL61909
208.82.136.0/21 ; SBL59310
208.84.96.0/21 ; SBL72825
208.87.152.0/21 ; SBL64180
208.90.0.0/21 ; SBL83016
209.165.224.0/20 ; SBL163
209.213.48.0/20 ; SBL57862
213.109.208.0/20 ; SBL81091
213.109.96.0/22 ; SBL80829
216.243.240.0/20 ; SBL55229
41.221.112.0/20 ; SBL73618
58.83.12.0/22 ; SBL53280
58.83.8.0/22 ; SBL67465
62.122.32.0/21 ; SBL73243
62.182.152.0/21 ; SBL83337
64.15.0.0/20 ; SBL84899
64.28.176.0/20 ; SBL36453
66.206.32.0/22 ; SBL67916
67.210.0.0/20 ; SBL58520
67.211.208.0/20 ; SBL74177
67.213.128.0/20 ; SBL72074
67.218.208.0/20 ; SBL79149
69.8.176.0/20 ; SBL15315
72.13.16.0/20 ; SBL83151
72.2.176.0/20 ; SBL65287
72.50.192.0/19 ; SBL69515
78.155.220.0/23 ; SBL71758
78.157.128.0/19 ; SBL68777
78.31.184.0/21 ; SBL83336
79.110.16.0/20 ; SBL83334
79.110.160.0/20 ; SBL67820
79.110.176.0/20 ; SBL79067
79.110.48.0/20 ; SBL81903
85.202.192.0/20 ; SBL83332
85.255.112.0/20 ; SBL36702
86.105.230.0/24 ; SBL50622
88.135.64.0/21 ; SBL84897
88.214.211.0/24 ; SBL67516
89.35.0.0/23 ; SBL47082
91.196.232.0/22 ; SBL60122
91.199.112.0/24 ; SBL64756
91.200.164.0/22 ; SBL83164
91.200.248.0/22 ; SBL83326
91.201.124.0/22 ; SBL82375
91.203.92.0/22 ; SBL65512
91.205.40.0/22 ; SBL80808
91.206.200.0/23 ; SBL76648
91.207.116.0/23 ; SBL72150
91.208.0.0/24 ; SBL66769
91.208.162.0/24 ; SBL68740
91.208.228.0/24 ; SBL85021
91.209.14.0/24 ; SBL69636
91.209.183.0/24 ; SBL80244
91.209.184.0/24 ; SBL71669
91.209.186.0/24 ; SBL73228
91.209.48.0/24 ; SBL74708
91.209.58.0/24 ; SBL73115
91.210.172.0/22 ; SBL71956
91.211.224.0/22 ; SBL81784
91.211.64.0/22 ; SBL70438
91.211.88.0/22 ; SBL71163
91.212.107.0/24 ; SBL82098
91.212.123.0/24 ; SBL78564
91.212.163.0/24 ; SBL76770
91.212.201.0/24 ; SBL76662
91.212.45.0/24 ; SBL73397
91.212.65.0/24 ; SBL73329
91.213.121.0/24 ; SBL80042
91.213.126.0/24 ; SBL77763
91.213.174.0/24 ; SBL83028
91.213.29.0/24 ; SBL80031
91.213.33.0/24 ; SBL77856
91.213.72.0/24 ; SBL78805
91.213.75.0/24 ; SBL84610
91.213.93.0/24 ; SBL78807
91.213.94.0/24 ; SBL78806
93.113.27.0/24 ; SBL79865
93.118.128.0/18 ; SBL77516
93.119.240.0/20 ; SBL82122
93.175.240.0/20 ; SBL83333
93.188.160.0/21 ; SBL66854
94.130.0.0/15 ; SBL83315
94.154.0.0/18 ; SBL83335
94.154.128.0/18 ; SBL67819
94.158.240.0/20 ; SBL81904
94.232.248.0/21 ; SBL73242
95.129.144.0/23 ; SBL75264
95.129.146.0/24 ; SBL75437
95.215.192.0/22 ; SBL79623
95.216.0.0/15 ; SBL83308

[neda_atishpare]

مقابله با 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 ازلینک [Only registered and activated users can see links] قابل دریافت هست.
فعال سازی و پیکربندی 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

[neda_atishpare]

مقابله با 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 رو بر اساس ترافیک شبکه خودتون وبا
توجه به نیازوشرایط خودتون تنظیم کنید.)

[neda_atishpare]

6- Spoofing

IP Spoofing:
درspoofing مهاجم با استفاده از آدرس های IP/network که بعنوان Bad Address
شناخته میشن، سعی درفریب دادن سرور میکنه که پکتهای ارسالی از طرف آدرس های محلی
یا شبکه هستش تا سرور به اونا پاسخ بده ...
آدرس های IP/network شناخته شده که برای spoofing استفاده میشن:
0.0.0.0/8
127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
192.168.0.0/16
224.0.0.0/3
یا محدوده ip آدرس سروریا شبکه داخلی شما...

با استفاده ازاین شل اسکریپت که این ip آدرس ها در اون معرفی میشن، میتوان با این متد مقابله کرد تا به این پکتها پاسخی داده نشه:

#!/bin/bash
INT_IF="connected to internet Example: eth1"
SERVER_IP="Your Server IP Address"
LAN_RANGE="your LAN IP range"
# Add your BAD IP Address/ranges
SPOOF_IPS="0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 224.0.0.0/3"
IPT="/sbin/iptables"
# default action, can be DROP or REJECT
ACTION="DROP"
# Drop packet that claiming from your server
$IPT -A INPUT -i $INT_IF -s $SERVER_IP -j $ACTION
$IPT -A OUTPUT -o $INT_IF -s $SERVER_IP -j $ACTION
# Drop packet that claiming from your internal LAN
$IPT -A INPUT -i $INT_IF -s $LAN_RANGE -j $ACTION
$IPT -A OUTPUT -o $INT_IF -s $LAN_RANGE -j $ACTION
for ip in $SPOOF_IPS
do
$IPT -A INPUT -i $INT_IF -s $ip -j $ACTION
$IPT -A OUTPUT -o $INT_IF -s $ip -j $ACTION
done

واضافه کردن این خط با ویرایش فایل etc/sysctl.conf/ تا سورس آدرسها در کرنل وارسی بشن:

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

[neda_atishpare]

ARP Spoofing
شبکه های طراحی شده برپایه استاندارد 802.11b و شبکه های محلی (LANs)
وسوییچ ها درلایه 2 به حملات arp spoofing آسیب پذیرن.
با arp spoofing/poisoning مهاجم میتونه حملاتی از جمله dos- hijacking- sniffing
رو تدارک ببینه و با ارسال پیامهای arp روی شبکه وبا جایگزینی MAC
آدرس قربانی با MAC خودش، ترافیک ارسالی به سمت قربانی رو sniff کنه
که میتونه شامل اطلاعات مهمی باشه:

[root@Neda] arpredirect -t 10.0.3.35 10.0.3.210
intercepting traffic from 10.0.3.35 to 10.0.3.210

[root@Neda] linsniff
Linux Sniffer Beta v.99
Log opened.
———[SYN] (slot 1)
10.0.3.210 => 192.168.2.57 [21]
USER Victim
PASS ***********
PORT 10,1,1,18,8,35
NLST
QUIT

ابزارarpwatch میتونه با استفاده ازpcap وبررسی پکتهای arp، تغییرکردن MAC
هرip آدرس رو لاگ کنه(var/log/syslog/) هم چنین میشه با ویرایش فایل پیکربندی
etc/arpwatch.conf/ ازطریق ایمیل ازاین تغییرات مطلع شد:

eth0 -a -n "your LAN IP/ranges" -m [Only registered and activated users can see links]

مثالی از arp spoofingبامشاهده لاگها:
Feb 08 11:33:08 arpwatch: new station 192.168.2.57
0:14:bf:a:7f:66 eth0

Feb 08 11:33:08 arpwatch: changed station 192.168.2.57
0:14:8c:b:59:b6

[neda_atishpare]

برای مقابله با arp spoofing وفیلترینگ پکتهای arp، میشه ازابزارمدیریتی
arptables استفاده کرد.
هم چنین میشه ازv/p/n استفاده کرد تا ترافیک توسط مهاجم قابل sniff نباشه وبرای
سوییچ هم میشه از NAC ([Only registered and activated users can see links]) استفاده کرد.
NAC: Network Access Control

برای مثالی که درپست قبلی عنوان شد، با دیدن جداول arp داریم:
Attacker: 192.168.2.57 at 0:14:bf:a:7f:66
Victim: 192.168.2.102 at 0:14:8c:b:59:b6
با استفاده از ماژول mangle درarptables، میشه MAC آدرس پکتهای مهاجم
رو که ازMAC قربانی استفاده میکنه به MAC آدرس اصلی مهاجم تغییربدیم تا نتوته
ترافیک قربانی رو sniff کنه:

arptables -A OUT -s 192.168.2.57 -d 192.168.2.102 -j mangle --mangle-hw-s 0:14:bf:a:7f:66

یا میتونیم درخواستهای arp ارسالی ازقربانی به مقصد مهاجم رو drop کنیم:
(مهاجم میتونه ازماشین قربانی برای dos یا hijacking ویا pro/xing استفاده کنه...)

arptables -A IN ! -s 192.168.2.102 -d 192.168.2.57 -j DROP

[neda_atishpare]

7- Sniffing
شنود یا sniffing تکنیکی هست که مهاجم بوسیله ابزارهایی مثل tcpdump- Wireshark-
sniffit- Ethereal- Hunt- Dsniff و... میتونه به دیتای مبادله شده روی سیم دسترسی پیدا
کنه. حملات sniffing با آنالیز پروتکل، ترافیک شبکه رو کپچر میکنن تا نفوذگر به اطلاعات
مهم مثل پسوردها دسترسی پیدا کنه:

log=admin&pwd=*************XX-submit=Log+In&redirect_to=[Only registered and activated users can see links]
log: admin
pwd:*************
XX-submit: Log In
redirect_to: [Only registered and activated users can see links]
testcookie: 1

روشهای sniffing بر پایه ip یا mac یا arp صورت میگیره که arp sniff در شبکه های
مبتنی برswitch استفاده میشه و ip sniff درشبکه های non-switch استفاده میشه
و mac sniff علاوه بر switch، بر روی رابط شبکه (NIC) نیز صورت میگیره جایی که
داده ها به LAN ارسال و دریافت میشن ازطریق پورتهای AUI و RJ-45 و BNC ...

برای تشخیص packet sniffer میشه از ابزارهایی مثل Sentinel یا Promisc.c و... استفاده کرد.
برای مقابله با sniffing میشه ازسرویس های ایمن، مثلا [Only registered and activated users can see links] و sftp و imaps و یا ازSSH
و V/P/N و SSL و IP Sec و... استفاده کرد.

بطورکلی استفاده از رمزنگاری برای تبادل دیتای ارسالی ودریافتی بهترین راه برای حفاظت
دربرابر sniffing هست وروشهای رمزنگاری که روی اینترنت استفاده میشن ssl و tls هستن.
SSL:Secure Sockets Layer
TLS:Transport Layer Security

برای پیکربندی apache سرور به منظور استفاده ازssl (مثلا برای [Only registered and activated users can see links] روی پورت 443 برای
اینکه کانکشن بین سرور و کلاینت رمزنگاری بشه) میتونیم در دایرکتوری
etc/apache2/sites-available/ فایل yoursite.yourdomain بصورت زیر بسازیم:
(برای راحتی کار فایل certificate.pem شامل محتویات دو فایل privkey.pem و signed.pem
هستش که اولی شامل کلید ssl و دومی شامل گواهی معتبرCSR هست.)

NameVirtualHost *:443
<VirtualHost *:443>
ServerName "yoursite.yourdomain"
DocumentRoot /var/[Only registered and activated users can see links]
SSLEngine On
SSLCertificateFile /path/to/certificate.pem
</VirtualHost>


سپس باید ماژول ssl و سایت مورد نظر رو فعال کنیم و راه اندازی مجدد apache:

a2enmod ssl
a2ensite "yoursite.yourdomain"
/etc/init.d/apache2 restart

با استفاده از[Only registered and activated users can see links] و sftp و... نباید توقع تضمین امنیت رو دربرابرsniffing داشت چون:
مثلا با استفاده از V/P/N درسته که دیتا بصورت رمزشده منتقل میشه ولی باید به این نکته توجه
داشت که مهاجم برای دور زدن V/P/N میتون هاست ها روی شبکه رو به یک RAT آلوده کنن و
این تروجان با استفاده از پلاگین های sniffing میتونه دیتا رو قبل از اینکه به حافظه stack در
V/P/N برای رمزنگاری منتقل بشه شنود کنه و برای مهاجم ارسال کنه.
RAT: Remote Access Trojan
یا درحملات IKE علیه پروتکل ipsec، مهاجم میتونه به کلید اشترکی بین سرور و کلاینت ودرنتیجه
به دیتای مبادله شده بین اونا دسترسی پیدا کنه.
IKE: Internet Key Exchange
یا ترافیک [Only registered and activated users can see links] رو شنود کرد. مثلا با استفاده ازابزارلینوکسی sslstrip که به زبان python
نوشته شده و درکنفرانس black hatها (2009) بعنوان دشمن نیرومند علیه ssl معرفی وثابت شد...

[neda_atishpare]

8- Sneaks Rootkits
RootKit بدافزاری شبيه Trojan و Backdoor هست با اين تفاوت كه خودش رو طوری
پنهان میکنه که شناسایی اون بسيارسختره. چون RootKit علاوه بر اين كه به عنوان يک
application مثل Netcat و یا یکbackdoor اجرا میشه، میتونه جايگزين برنامه های
اجرايی سيستم عامل وحتی جايگزين هسته كرنل بشه و به هكر اجازه میده تا از طريق
backdoor و پنهان شدن درعمق سيستم عامل با نصب Sniffer و... اطلاعاتی رو كه نياز
داره بدست بیاره.

مهمترین نوع که RootKit سطح هسته گفته میشه بسیارحرفه ای عمل میکنه وشناسايی اون
بسيارسخته. ولی RootKit معمولی جايگزين برنامه های سيستمی مثل برنامه های ifconfig و
ls و... ميشه. با RootKit سطح هسته، هکرمیتونه فايل ها، دستورها وپردازشها رو به نفع
خودش اجرا کنه. مثلا هکر كه با حساب Root به سرور وصل شده تنها با تایپ
insmod adore-ng-2.6.ko ماژول adore-ng رو نصب میکنه که یکی از RootKitهای هسته لینوکس هستش و دستورات بعدی مهاجم، توسط rootkit اجرا میشه:

root@Neda# ps
PID TTY TIME CMD
2209 pts/0 00:00:00 su
2210 pts/0 00:00:00 bash
2278 pts/0 00:00:00 ps
root@Neda# insmod adore-ng-2.6.ko
root@Neda# ./ava 1 2210
Checking for adore 0.12 or higher ...
Adore 1.56 installed. Good luck.
Made PID 2210 invisible.
...

برای شناسایی rootkitها میشه از ابزار chkrootkit و rkhunter استفاده کرد.
Chkrootkit شامل اسکریپت هایی هست که وقتی rootkit قصد تغییردراستاندارهای باینری
رو داره با اون مقابله میکنه و چون به طورمعمول rootkitها برای پنهان سازی ازتروجان های
LKM استفاده میکنن و chkrootkit میتونه تروجانهای LKM رو شناسایی کنه...

لیست برخی از rootkitها و wormهای شناخته شده که توسط chkrootkit شناسایی میشن:

01. lrk3, lrk4, lrk5, lrk6 (and variants);
02. Solaris rootkit;
03. FreeBSD rootkit;
04. t0rn (and variants);
05. Ambient's Rootkit (ARK);
06. Ramen Worm;
07. rh[67]-shaper;
08. RSHA;
09. Romanian rootkit;
10. RK17;
11. Lion Worm;
12. Adore Worm;
13. LPD Worm;
14. kenny-rk;
15. Adore LKM;
16. ShitC Worm;
17. Omega Worm;
18. Wormkit Worm;
19. Maniac-RK;
20. dsc-rootkit;
21. Ducoci rootkit;
22. x.c Worm;
23. RST.b trojan;
24. duarawkz;
25. knark LKM;
26. Monkit;
27. Hidrootkit;
28. Bobkit;
29. Pizdakit;
30. t0rn v8.0;
31. Showtee;
32. Optickit;
33. T.R.K;
34. MithRa's Rootkit;
35. George;
36. SucKIT;
37. Scalper;
38. Slapper A, B, C and D;
39. OpenBSD rk v1;
40. Illogic rootkit;
41. SK rootkit.
42. sebek LKM;
43. Romanian rootkit;
44. LOC rootkit;
45. shv4 rootkit;
46. Aquatica rootkit;
47. ZK rootkit;
48. 55808.A Worm;
49. TC2 Worm;
50. Volc rootkit;
51. Gold2 rootkit;
52. Anonoying rootkit;
53. Shkit rootkit;
54. AjaKit rootkit;
55. zaRwT rootkit;
56. Madalin rootkit;
57. Fu rootkit;
58. Kenga3 rootkit;
59. ESRK rootkit;
60. rootedoor rootkit;
61. Enye LKM;
62. Lupper.Worm;
63. shv5;
64. OSX.RSPlug.A;
...

[neda_atishpare]

JavaScript Rootkit

سرورهای لینوکس، تارگت JS Rootkit هستن برای این توزیع ها:
RedHat Enterprise- Centos v4.x/v5.x- Fedora v5/v6
هنوز جزییات ناشناخته زیادی درمورد این روت کیت وجود داره و این روت کیت با سطح دسترسی
super user هم نصب میشه وسپس سرور Reboot میشه و اسکریپت ها، پکیج های باینری
رو آلوده میکنن ازجمله پکیج های:

sbin/ifconfig/
sbin/fsck/
sbin/route/
bin/basename/
bin/cat/
bin/mount/
bin/touch/

بعد از آلوده کردن پکیج های باینری، اونا رو Rename میکنه به این صورت که
کارآکترهای تصادفی به اسم فایل اضافه میکنه و بصورت مخفی درفایل سیستمی قرارمیگیرن.
مثال:

/sbin/routevQmx6rKJ5ase2ccDe8zi
/sbin/routeAcdhxa594zbiNVH3961x2
/sbin/routeTLV3efG8RHiBBown66sp

وپس ازاجرا، فایلهای مخفی، پکیج های باینری ناقص و اجرای تصادفی کدهای جاوا اسکریپت
برای ویزیتورهای وب سرور ازنتایج آلوده شدن به JS Rootkit هست و تزریق کدهای JS به
درخواستهای وب ویزیتورها در هیچکدام از لاگهای apache قابل مشاهده نیست وکدهای JS
بصورت اکسپلویت هایی برای آسیب پذیری های ویندوز- یاهو مسنجر و Quick Time بر
روی PCهای ویزیتورها عمل میکنن که درصد کمی از درخواستهای وب به این طریق و بطور
تصادفی پاسخ داده میشن.

اما چطور تشخیص بدیم که سرور به JS Rootkit آلوده هست یا نه؟
برای این کار میشه یک دایرکتوری بسازیم با نامی که در اون از اعداد استفاده شده باشه.
اگه این پیغام رو دریافت کردیم، میشه گفت سروربه JS Rootkit آلوده هست:
(البته این روش همیشه جواب نمیده.)

root@Neda# mkdir 1234test
mkdir: cannot create directory `1234test': No such file or directory

و برای مطمئن شدن میشه با استفاده از tcpdump برای 3 تا 5 دقیقه پکتها رو sniff کرد با این دستور:

tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'"

و اگه سرور آلوده باشه، سیستم این پیغام رو میده:

root@Neda# tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'"
tcpdump: verbose output suppressed, use -v or -vv for full protocol

decode
listening on eth0, capture size 2306 bytes

1264 packets captured
2592 packets received by ******
0 packets dropped by kernel

برای remove کردن این Rootkit، باید پکیج های باینری اصلی رو با پکیج های باینری اولیه
جایگزین کرد. مثلا پکیج باینری اصلی که آلوده شده: sbin/routeAcdhxa594zbiNVH3961x2
برای اینکار میشه فایل رو براساس سایز جستجو کرد که یکی سایز 0 بایت داره و دیگری به سایز
اصلی هستش وبهتره این پکیج ها از یک سرورمطمئن و clean کپی بشن.
میتونیم با دیتا سنتر یا NOC یا یک کارشناس تماس بگیریم تا سیستم بصورت full چک بشه وباید
تمام پسوردهای root رو که قبلا استفاده میشده عوض کنیم و سرویس ها و applicationهای سرور آپدیت بشن و پچ های امنیتی و hardening سرورهم فراموش نشه وبا دقت هرفعالیت مشکوکی نظارت بشه.

[neda_atishpare]

RKhunter:

اگه برای مقابله با Rootkits از rkhunter استفاده کرده باشین، ممکنه با این هشدار از طرف rkhunter مواجه شده باشین:

The command '/usr/bin/ldd' has been replaced by a script

اگه سرور ایمن و clean باشه این آلارم اشتباه هست و بعنوان مثال درCentos این هشداربرای :
usr/bin/ldd/
usr/bin/whatis/
usr/bin/fgrep/
usr/bin/egrep/ نمایش داده میشه.

چون شل اسکریپت های plain text دراکثر توزیع ها میتونن مفید باشن، برای اطمینان بیشتر میشه این اسکریپت ها رو با استفاده از ادیتورهای vi یا pico یا nano مشاهده کرد ومحتویات اونا رو از نظر سلامت وایمنی بررسی کرد واین مغایرت داره با اینکه rootkit خودش رو بصورت visible و
قابل مشاهده نصب کنه ...
بنابراین اگه سرور ایمن و clean داشته باشیم میشه این اسکریپت ها رو در فایل پیکربندی
etc/rkhunter.conf/ در لیست سفید معرفی کنیم. مثلا:

# Allow the specified commands to be scripts.
SCRIPTWHITELIST=/sbin/ldd
SCRIPTWHITELIST=/sbin/whatis

rkhunter با استفاده از md5 hash فایلهای باینری رو مقایسه میکنه و با rootkit که سعی کنه
اونا رو تغییر بده مقابله میکنه، بنابراین برای مطمئن شدن از اینکه فایلها تعویض شدن یا نه با دستورزیر میشه فایلها رو با MD5های اسکریپت های یک سیستم مطمئن و ایمن مقایسه کرد
و اگه باینری ها تغییر کرده بودن باید سرور توسط یک کارشناس بصورت full چک بشه و
برای مقایسه:

/usr/bin/md5sum /usr/bin/"your replace file"

نکته دیگه در رابطه با rkhunter این هست که اگه با این خطاها مواجه شدیم:

The file of known backdoor ports (backdoorports.dat) is missing or empty.
If it has been deleted, then you will need to run 'rkhunter --update'.
The file of unsecure application versions (programs_bad.dat) is missing or empty.

بهتره که دیتابیس rkhunter رو آپدیت کنیم و ابتدا مطمئن بشیم که فایلهای موردنظر وجود دارن و اگه نبود، فایلها رو بصورت دستی بسازیم و مجوز و حق مالکیت اون فایلها رو تنظیم کنیم و
برای آپدیت کردن دیتابیس:

/usr/local/bin/rkhunter --update

[neda_atishpare]

جلوگیری ازآپلود فایلهای آلوده روی سرور:

برای اسکن وجلوگیری ازآپلود کردن فایلهای آلوده روی سرور، باید clamav ([Only registered and activated users can see links]) و pureftpd ([Only registered and activated users can see links])
رو فعال کنیم تا فایلهایی که میخوان آپلود بشن توسط Clamav اسکن شده و درصورت آلوده بودن
delete بشن. برای این کار باید این تنظیمات و انجام بدیم:
باید clamav روی سرور نصب شده باشه و آپدیت هم باشه و با استفاده از ادیتور Vi
فایل پیکربندی etc/pure-ftpd.conf/ ویرایش کنیم و برای این کار، ورودی
CallUploadScript yes# رو بصورت زیر تغییر بدیم:

CallUploadScript yes

بعد ازذخیره کردن باید فایل etc/init.d/pure-ftpd/ ویرایش کنیم واین خط و پیدا کنیم:

$DAEMONIZE $fullpath /etc/pure-ftpd.conf -O clf:/var/log/xferlog $OPTIONS --daemonize

و اضافه کردن این خط، درزیرخط فوق:

$DAEMONIZE /usr/sbin/pure-uploadscript -B -r /var/run/pure-ftpd/clamscan.sh

سپس پیدا کردن این خط:

kill $(cat /var/run/pure-ftpd.pid)

واضافه کردن این خط:

kill $(cat /var/run/pure-ftpd/pure-uploadscript.pid)

وبعد از ذخیره کردن تغییرات به دایرکتوری /var/run/pure-ftpd/ رفته واین اسکریپت
رو درclamscan.sh وارد می کنیم:

#!/bin/sh

if [ "$1" = "" ]; then
echo 'Variable is blank';
exit;
fi
if [ ! -f "$1" ]; then
echo "$1 file not found"
exit;
fi


date=`date '+%d-%m-%y %H:%M'`;
scan=`/usr/bin/clamdscan --remove --no-summary "$1"`;
echo "$date ClamAV $scan" >> /var/log/messages

وبعد ازذخیره کردن فایل clamscan.sh، برای راه اندازی مجدد سرویس pure-ftpd:

chmod 755 /var/run/pure-ftpd/clamscan.sh
/sbin/service pure-ftpd restart

دراسکریپت فوق، دردستور clamdscan که ازسوئیچ remove-- استفاده شده، فایلهای
آلوده delete میشن ولی اگه مایل باشین بجای حذف کردن، فایلها به یک دایرکتوری انتقال
داده بشن باید دراسکریپت فوق بجای این خط :

scan=`/usr/bin/clamdscan --remove --no-summary "$1"`;

خط زیرو جایگزین کنیم تا با استفاده از سوئیچ move-- در مسیر تعیین شده منتقل بشن:

scan=`/usr/bin/clamdscan --move=/"your path" --no-summary "$1"`;

[neda_atishpare]

9- ...XSS- SQL/SQL Blind Injection- PHP & ASP injection- Rfi- Trojans & Backdoors

ModSecurity CRS

این ماژول ( ModSecurity Core Rule Set) که بر روی ModSecurity 2.5 و بالاتر
کار میکنه، برای وب سرورapache بصورت یک فایروال عمل میکنه و یک لایه امنیتی قابل
توجهی رو برای سرور فراهم میکنه.

برخلاف سیستم های حفاظتی وتشخیص نفوذ که بر اساس آسیب پذیریها و حملات مشخص و
شناخته شده کار میکنن، CRS براساس قواعد کلی بر روی شناسایی payload حملات تمرکز
میکنه و این میتونه در مورد حملات و آسیب پذیریهای zero day و ناشناخته که اغلب در
web application پیدا میشن، موثر باشه.

CRS میتونه درخواستهای برنامه هایی ازقبیل crawlerها و اسکنرهای امنیتی و robotها که
آسیب پذیریها رو جستجو میکنن یا کسب اطلاعات اولیه ومصرف پهنای بند و... رو شناسایی کنه.
هم چنین میتونه حملات application رو شناسایی کنه از جمله:
SQL و Blind SQL و XSS و شناسایی دستورهای remote ودستورهای OS و
E-mail Injection و PHP Injection وASP Injection و Rfi و...

CRS میتونه trojans و backdoors که قصد نصب شدن روی سیستم رو دارن
شناسایی کنه و این میتونه در مواردی مفید باشه که بعضی از backdoorها با حق دسترسی مجاز میخوان آپلود بشن وازآپلود جلوگیری میشه.

علاوه بر این، CRS میتونه مانع استفاده مهاجم از error messages و کدهای کوچک بشه چون
مهاجم به کمک اونا میتونه اطلاعاتی درباره سرور کسب کنه و CRS کار مهاجم رو سخت تر میکنه.

این ماژول ازاین لینک ([Only registered and activated users can see links]) قابل دریافت هست و برای
استفاده ازاین ماژول باید خطوط زیرو در [Only registered and activated users can see links] اضافه کنیم و راه اندازی مجدد وب سرور:
(با این فرض که فایلهای rule در /conf/modsecurity_crs قرار گرفتن)

<IfModule security2_module>
Include conf/modsecurity_crs/*.conf
Include conf/modsecurity_crs/base_rules/*.conf
</IfModule>

[neda_atishpare]

10- Peer to Peer (P2P) File Sharing Attack

اشتراک گذاشتن فایل ها باعث میشه با خطرات امنیتی مهمی روبرو شد ازجمله نصب کدهای
مخرب توسط مهاجم مثل ویروس، تروجان، worm وspyware ویا به خطر افتادن اطلاعات
مهم در صورت دسترسی به دایرکتوریها وهم چنین از کارافتادن سرویس های نصب شده روی
سرور وقتی که دریافت فایل ها حجم ترافیک و پردازش های مرتبط رو افزایش میده و یا استفاده
از برنامه های P2P باعث میشه که این برنامه ها از فایروال درخواست کنن تا پورت خاصی
رو باز کنه تا بتونه فایل رو ارسال کنه که ايجاد يک روزنه درسيستم حفاظتی ايجاد شده توسط
فايروال، میتونه مستعد آسیب پذیری به حملات دیگه بشه...
مثلا slapper worm که تارگت اون وب سرورهای آپاچی برای توزیع های Red Hat و
Suse و Debian و Mandrake و Slackware و Gentoo بود که با استفاده از
اکسپلویت مربوط به آسیب پذیری ماژول OpenSSL سرورو آلوده می کرد وبا امکاناتی
که برای P2P داشت، ازطریق ارتباط با کلاینت ها، از اونا درحملات DDoS استفاده میکرد...

در P2P ازپروتکل های Fasttrack, eDonkey, Direct Connect, Gnutella
kazaa, OpenFT, BitTorrent و...استفاده میشه.
ipp2p ماژولی برای iptables هست که میتونه این پروتکل ها رو شناسایی کنه وترافیک
مرتبط با اونا رو محدود یا بلوک کنه، که ازاین لینک قابل دریافت هست:
[Only registered and activated users can see links]

تنظیمات iptables برای ماژول ipp2p وکنترل ترافیک پروتکل های مختلف P2P:

#all p2p traffic
echo -n "all P2P "
iptables -t mangle -A PREROUTING -m ipp2p --ipp2p -j LOG --log-level 6 --log-prefix "ipp2p: p2p-traffic "
iptables -t mangle -A PREROUTING -m ipp2p --ipp2p -j DROP

#edk p2p traffic
echo -n "eDonkey,eMule,aMule,Kamdelia,"
iptables -t mangle -A PREROUTING -m ipp2p --edk -j LOG --log-level 6 --log-prefix "ipp2p: donkey's-traffic "
iptables -t mangle -A PREROUTING -m ipp2p --edk -j DROP

#kazaa p2p traffic
echo -n "kaZaA,FastTrack,"
iptables -t mangle -A PREROUTING -m ipp2p --kazaa -j LOG --log-level 6 --log-prefix "ipp2p: kazaa-traffic "
iptables -t mangle -A PREROUTING -m ipp2p --kazaa -j DROP

#gnu p2p traffic
echo -n "Gnutella,Limeware,Azureus,"
iptables -t mangle -A PREROUTING -m ipp2p --gnu -j LOG --log-level 6 --log-prefix "ipp2p: gnutella-traffic "
iptables -t mangle -A PREROUTING -m ipp2p --gnu -j DROP

#dc p2p traffic
echo -n "DirectConnect,"
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --dc -j LOG --log-level 6 --log-prefix "ipp2p: dc-traffic "
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --dc -j DROP

#bit p2p traffic
echo -n "BitTorrent,extendedBT,"
iptables -t mangle -A PREROUTING -m ipp2p --bit -j LOG --log-level 6 --log-prefix "ipp2p: bit-traffic "
iptables -t mangle -A PREROUTING -m ipp2p --bit -j DROP

#apple p2p traffic
echo -n "appleJuice,"
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --apple -j LOG --log-level 6 --log-prefix "ipp2p: apple-traffic "
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --apple -j DROP

#winmx p2p traffic
echo -n "WinMX,"
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --winmx -j LOG --log-level 6 --log-prefix "ipp2p: winmx-traffic "
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --winmx -j DROP

#soul p2p traffic
echo -n ",SoulSeek,PySoulSeek,"
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --soul -j LOG --log-level 6 --log-prefix "ipp2p: soul-traffic "
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --soul -j DROP

#ares p2p traffic
echo -n "Ares,AresLite"
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ares -j LOG --log-level 6 --log-prefix "ipp2p: ares-traffic "
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ares -j DROP

[neda_atishpare]

مقابله با P2P Gnutella با استفاده از ماژول rope و iptables:

اغلب کلاینت های P2P ازقبیل LimeWire, Acquisitionx, Poisoned, Mutella
Gnucleus, Gtk-Gnutella, Gnotella, XNap, CocoGnut, BearShare,
Shareaza, Phex و... از پروتکل Gnutella استفاده میکنن.
برای بلوک کردن کلاینتهای P2P علاوه برipp2p میشه ازماژول rope استفاده کرد (برای نصب ماژول rope) ([Only registered and activated users can see links])
و بعد از نصب ماژول باید اسکریپت gnutella.rope رو کمپایل کرد واسکریپت کمپایل شده
رو در فولدرetc/rope.d/scripts/ قرارداد وبرای استفاده از اون دریک زنجیره iptables
بصورت زیرعمل کنیم تا پکتهای Gnutella شناسایی و drop بشن:

iptables -A FORWARD -p tcp -m rope --rope-script gnutella -j DROP

اسکریپت gnutella.rope:
این اسکریپت با بررسی دیتا در پیلود بسته ها، پکتهای Gnutella رو با استفاده ازاین
ترکیب: " GNUTELLA CONNECT/digit(s).digit(s)\r\n " شناسایی میکنه:

# gnutella.rope - ROPE script to block GnuTella transfers using
# IpTables and Netfilter.
# By : Chris Lowth
# License : GPL ([Only registered and activated users can see links])
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#

expect_str( "GNUTELLA CONNECT/" )
expect_while( {isdigit} )
expect_str( "." )
expect_while( {isdigit} )
expect_str( chr(13) chr(10) )
yes

وبرای کمپایل کردن این اسکریپت:
با دسترسی root، سورس کد با استفاده از دستورropec و آپشن i-
فایل کمپایل شده (مثلا mytest) در دایرکتوری etc/rope.d/scripts/ ایجاد میشه:

ropec -i mytest.rope

[neda_atishpare]

Malicious url
معمولا ruleهای تعریف شده در ماژول ModSecurity میتونن بسیاری از urlهای مخرب
که قصد حمله به پورتهای http یا [Only registered and activated users can see links] سرورو دارن، فیلتر کنه. اما برای مقابله با مهاجمی که
از الگوی یک url آسیب پذیراستفاده میکنه و بخواد درurl، پورت رو تغییر بده مثلا:

[Only registered and activated users can see links]

میشه با استفاده از string match و پارامترalgo، با تعریف rule زیر در iptables با
جستجو دربسته های tcp، هرurl رو که شامل این استرینگ “download?file=%2e%2e”
باشه، روی هر پورتی از سرور بلوک کرد:

iptables -I INPUT -p tcp -s 0.0.0.0/0 -m string --string “download?file=%2e%2e” --algo bm -j DROP

وبرای بررسی عملکرد این rule:

root@Neda # iptables -L -v | grep STR
71 36607 DROP tcp -- any any anywhere anywhere
STRING match “download?file=%2e%2e” ALGO name bm TO 65535

محدود کردن نشست های همزمان
برای محدود کردن نشست های همزمان درP2P برای ip آدرس هایی که میخوان تعداد
زیادی نشست های همزمان داشته باشن، میشه از ruleهای زیر در iptables به منظور
محدود کردن کانکشن های موازی tcp استفاده کرد.(مثلا 5کانکشن برای هر ip)
البته باید کرنل رو با ipset ([Only registered and activated users can see links]) و connlimit ([Only registered and activated users can see links]) کمپایل کرد.

iptables -t mangle -A PREROUTING -p tcp -i eth0 --dport 1024: -m \
connlimit --connlimit-above 5 -j SET --add-set p2p src

iptables -t mangle -A FORWARD -o eth0 -p tcp -m multiport --sport \
1024:65535 -m set --set p2p dst -j MARK --set-mark 60

iptables -t mangle -A FORWARD -i eth0 -p tcp -m multiport --dport \
1024:65535 -m set --set p2p src -j MARK --set-mark 60

[mohsentanha]

با سلام و تشکر
میشه در مورد برنامه Snort هم آموزش بدین ؟

[Unf0rgiven2]

ممنون از آموزش خوبتون قست اسپم ندارم ولی اگه وقت کنین آموزش تصویرشم درست کنید واقعا لطف می کنید
با تشکر

[sarzamineajayeb]

با سلام.
همه مراحل انجام شده منتها فایلهای rule در /conf/modsecurity_crs را پیدا نمی کنم.
هر چقدر هم با locate جستجو می کنم چیزی پیدا نمی کنم.
ممنون میشم راهنمایی بفرمایید.
متشکرم.

9- ...XSS- SQL/SQL Blind Injection- PHP & ASP injection- Rfi- Trojans & Backdoors

ModSecurity CRS

این ماژول ( ModSecurity Core Rule Set) که بر روی ModSecurity 2.5 و بالاتر
کار میکنه، برای وب سرورapache بصورت یک فایروال عمل میکنه و یک لایه امنیتی قابل
توجهی رو برای سرور فراهم میکنه.

برخلاف سیستم های حفاظتی وتشخیص نفوذ که بر اساس آسیب پذیریها و حملات مشخص و
شناخته شده کار میکنن، CRS براساس قواعد کلی بر روی شناسایی payload حملات تمرکز
میکنه و این میتونه در مورد حملات و آسیب پذیریهای zero day و ناشناخته که اغلب در
web application پیدا میشن، موثر باشه.

CRS میتونه درخواستهای برنامه هایی ازقبیل crawlerها و اسکنرهای امنیتی و robotها که
آسیب پذیریها رو جستجو میکنن یا کسب اطلاعات اولیه ومصرف پهنای بند و... رو شناسایی کنه.
هم چنین میتونه حملات application رو شناسایی کنه از جمله:
SQL و Blind SQL و XSS و شناسایی دستورهای remote ودستورهای OS و
E-mail Injection و PHP Injection وASP Injection و Rfi و...

CRS میتونه trojans و backdoors که قصد نصب شدن روی سیستم رو دارن
شناسایی کنه و این میتونه در مواردی مفید باشه که بعضی از backdoorها با حق دسترسی مجاز میخوان آپلود بشن وازآپلود جلوگیری میشه.

علاوه بر این، CRS میتونه مانع استفاده مهاجم از error messages و کدهای کوچک بشه چون
مهاجم به کمک اونا میتونه اطلاعاتی درباره سرور کسب کنه و CRS کار مهاجم رو سخت تر میکنه.

این ماژول ازاین لینک ([Only registered and activated users can see links]) قابل دریافت هست و برای
استفاده ازاین ماژول باید خطوط زیرو در [Only registered and activated users can see links] اضافه کنیم و راه اندازی مجدد وب سرور:
(با این فرض که فایلهای rule در /conf/modsecurity_crs قرار گرفتن)

<IfModule security2_module>
Include conf/modsecurity_crs/*.conf
Include conf/modsecurity_crs/base_rules/*.conf
</IfModule>

[yaser_rap2]

من چیز زیادی نفهمیدم فقط چطوری میتونم آی پی اصلی مهاجم رو پیدا کنم تا بفهمم کجاست اگه یارو با یه سرور خارجی وارد بشه مثل استفاده از سرورهای س ا ک س الان این که سرور منو هک کرده با س ا ک س وارد شده و ای پی که داره از یک سرور خارجی هست چطوری میتونم ورودی ای پی های اون سرور رو در اون ساعت تاریخ که بهم حمله کرده رو بگیرم و ای پی مرود نظر که بهم حمله کرده رو بردارم