دفاع علیه حملات Smurf یا Fraggle

دفاع علیه حملات Smurf یا Fraggle

اگر در معرض حمله Smurf قرار گرفته باشید، کار چندانی از شما ساخته نیست. هرچند که این امکان وجود دارد که بسته های مهاجم را در روتر خارجی مسدود کنید، اما پهنای باند منشاء آن روتر مسدود خواهد شد. برای اینکه فراهم کننده شبکه بالاسری شما، حملات را در مبداء حمله مسدود کند، به هماهنگی نیاز است.

بمنظور جلوگیری از آغاز حمله از سایت خودتان، روتر خارجی را طوری پیکربندی کنید که تمام بسته های خارج شونده را که آدرس مبداء متناقض با زیرشبکه شما دارند، مسدود کند. اگر بسته جعل شده نتواند خارج شود، نمی تواند آسیب چندانی برساند.

برای جلوگیری از قرار گرفتن بعنوان یک واسطه و شرکت در حمله DoS شخص دیگر، روتر خود را طوری پیکربندی کنید که بسته هایی را که مقصدشان تمام آدرس های شبکه شماست، مسدود کند. یعنی، به بسته های ICMP منتشر شده به شبکه خود، اجازه عبور از روتر ندهید. این عمل به شما اجازه می دهد که توانایی انجام ping به تمام سیستم های موجود در شبکه خود را حفظ کنید، در حالیکه اجازه این عمل را از یک سیستم بیرونی بگیرید. اگر واقعاً نگران هستید، می توانید سیستم های میزبان خود را طوری پیکربندی کنید که از انتشارهای ICMP  کاملاً جلوگیری کنند.

دفاع علیه حملات طغیان SYN

بلاک های کوچک

بجای تخصیص یک شیء از نوع ارتباط کامل (که باعث اشغال فضای زیاد و نهایتاً اشکال در حافظه می شود)، یک رکورد کوچک (micro-record) تخصیص دهید. پیاده سازی های جدیدتر برای SYN های ورودی ، تنها ۱۶ بایت تخصیص می دهد.

کوکی های SYN

یک دفاع جدید علیه طغیان SYN «کوکی های SYN» است. در کوکی های SYN، هر طرف ارتباط، شماره توالی (Sequence Number) خودش را دارد. در پاسخ به یک SYN، سیستم مورد حمله واقع شده، یک شماره توالی مخصوص از ارتباط ایجاد می کند که یک «کوکی» است و سپس همه چیز را فراموش می کند یا بعبارتی از حافظه خارج می کند (کوکی بعنوان مشخص کننده یکتای یک تبادل یا مذاکره استفاده می شود). کوکی در مورد ارتباط اطلاعات لازم را در بردارد، بنابراین بعداً می تواند هنگامی که بسته ها از یک ارتباط سالم می آیند، مجدداً اطلاعات فراموش شده در مورد ارتباط را ایجاد کند.

کوکی های RST

جایگزینی برای کوکی های SYN است، اما ممکن است با سیستم عامل های ویندوز 95  که پشت فایروال قرار دارند، مشکل ایجاد کند. روش مذکور به این ترتیب است که سرور یک ACK/SYN اشتباه به کلاینت ارسال می کند. کلاینت باید یک بسته RST تولید کند تا به سرور بگوید که چیزی اشتباه است. در این هنگام، سرور می فهمد که کلاینت معتبر است و ارتباط ورودی از آن کلاینت را بطور طبیعی خواهد پذیرفت.

پشته های (stack) های TCP  بمنظور کاستن از تأثیر طغیان های SYN می توانند دستکاری شوند. معمول ترین مثال کاستن زمان انقضاء (timeout) قبل از این است که پشته، فضای تخصیص داده شده به یک ارتباط را آزاد کند. تکنیک دیگر قطع بعضی از ارتباطات بصورت انتخابی است.

 

دفاع علیه حملات DNS

دفاع از سرور اصلی (root server)

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

دفاع از سازمان تان

اگر سازمان شما یک اینترانت دارد، باید دسترسی  های جداگانه ای از DNS برای کاربران داخلی و مشتریان خارجی خود فراهم کنید. این عمل DNS داخلی را از حملات خارجی در امان نگاه می دارد. ناحیه اصلی را کپی کنید تا سازمان خود را از حملات DDoS آتی روی قسمت های اصلی محفوظ نگه دارید. همچنین به کپی کردن نواحی DNS از شرکای تجاری خود که در خارج از شبکه شما قرار دارند، توجه کنید. هنگامی که بروز رسان های DNS به روی اینترنت می روند، می توانند در هنگام انتقال مورد ربایش و دستکاری قرار گیرند. از TSIGها (transaction signature)  یا امضاهای معاملاتی برای امضای آن ها یا ارسال بروز رسان ها روی VPN (شبکه های خصوصی مجازی) یا سایر کانال ها استفاده کنید.

مقابله با حملات DDoS

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

 

سیاه چاله

این روش تمام ترافیک را مسدود می کند و به سمت سیاه چاله! یعنی جایی که بسته ها دور ریخته می شود هدایت می کند. اشکال در این است که تمام ترافیک – چه خوب و چه بد- دور ریخته می شود و در حقیقت شبکه مورد نظر بصورت یک سیستم off-line  قابل استفاده خواهد بود. در روش های اینچنین حتی اجازه دسترسی به کاربران قانونی نیز داده نمی شود.

مسیریاب ها و فایروال ها

روتر ها می توانند طوری پیکربندی شوند که از حملات ساده ping با فیلترکردن پروتکل های غیرضروری جلوگیری کنند و می توانند آدرس های IP نامعتبر را نیز متوقف کنند. بهرحال، روترها معمولاً در مقابل حمله جعل شده پیچیده تر و حملات در سطح Application با استفاده از آدرس های IP معتبر، بی تأثیر هستند.

سیستم های کشف نفوذ

روش های سیستم های کشف نفوذ (intrusion detection systems) توانایی هایی ایجاد می کند که باعث تشخیص استفاده از پروتکل های معتبر بعنوان ابزار حمله می شود. این سیستمها می توانند بهمراه فایروال ها بکار روند تا بتوانند بصورت خودکار در مواقع لزوم ترافیک را مسدود کنند. در بعضی مواقع سیستم تشخیص نفوذ نیاز به تنظیم توسط افراد خبره امنیتی دارد و البته گاهی در تشخیص نفوذ دچار اشتباه می شود.

 

سرورها

پیکربندی مناسب applicationهای سرویس دهنده در به حداقل رساندن تأثیر حمله  DDoS تأثیر بسیار مهمی دارند. یک سرپرست شبکه می تواند بوضوح مشخص کند که یک application از چه منابعی می تواند استفاده کند و چگونه به تقاضاهای کلاینت ها پاسخ دهد. سرورهای بهینه سازی شده، در ترکیب با ابزار تخفیف دهنده، می توانند هنوز شانس ادامه ارائه سرویس را در هنگامی که مورد حمله DDoS قرار می گیرند، داشته باشند.

ابزار تخفیف DDoS

چندین شرکت ابزارهایی تولید می کنند که برای ضدعفونی ! کردن ترافیک یا تخفیف حملات DDoS استفاده می شوند که این ابزار قبلاً بیشتر برای متعادل کردن بار شبکه یا فایروالینگ استفاده می شد. این ابزارها سطوح مختلفی از میزان تأثیر دارند. هیچکدام کامل نیستند. بعضی ترافیک قانونی را نیز متوقف می کنند و بعضی ترافیک غیرقانونی نیز اجازه ورود به سرور پیدا می کنند. زیرساخت سرور هنوز باید مقاوم تر شود تا در تشخیص ترافیک درست از نادرست بهتر عمل کند.

پهنای باند زیاد

خرید یا تهیه پهنای باند زیاد یا شبکه های افزونه برای سروکار داشتن با مواقعی که ترافیک شدت می یابد، می تواند برای مقابله با DDoS مؤثر باشد.

عموماً، شرکت ها از قبل نمی دانند که یک حمله DDoS بوقوع خواهد پیوست. طبیعت یک حمله گاهی در میان کار تغییر می کند و به این نیاز دارد که شرکت بسرعت و بطور پیوسته در طی چند ساعت یا روز، واکنش نشان دهد. از آنجا که تأثیر اولیه بیشتر حملات، مصرف کردن پهنای باند شبکه شماست، یک ارائه کننده سرویس های میزبان روی اینترنت که بدرستی مدیریت و تجهیز شده باشد، هم پهنای باند مناسب و هم ابزار لازم را در اختیار دارد تا بتواند تأثیرات یک حمله را تخفیف دهد.

عدم پذیرش سرویس (۱)

عدم پذیرش سرویس (۱)

قصد داریم تا طی چند مقاله با نوعی از حمله به نام DoS آشنا شویم که مخفف عبارتDenial-of-Service  یا عدم پذیرش سرویس است. همانطور که در روش های معمول حمله به کامپیوترها اشاره مختصری شد، این نوع حمله باعث از کارافتادن یا مشغول شدن بیش از اندازه کامپیوتر می شود تا حدی که غیرقابل استفاده می شود. در بیشتر موارد، حفره های امنیتی محل انجام این حملات است و لذا نصب آخرین وصله های امنیتی از حمله جلوگیری خواهند کرد. شایان گفتن است که علاوه بر اینکه کامپیوتر شما هدف یک حمله DoS قرار می گیرد، ممکن است که در حمله DoS علیه یک سیستم دیگر نیز شرکت داده شود. نفوذگران با ایجاد ترافیک بی مورد و بی استفاده باعث می شوند که حجم زیادی از منابع سرویس دهنده و پهنای باند شبکه مصرف یا به نوعی درگیر رسیدگی به این تقاضاهای بی مورد شود و این تقاضا تا جایی که دستگاه سرویس دهنده را به زانو در آورد ادامه پیدا می کند. نیت اولیه و تأثیر حملات DoS جلوگیری از استفاده صحیح از منابع کامپیوتری و شبکه ای و از بین بردن این منابع است.

علیرغم تلاش و منابعی که برای ایمن سازی علیه نفوذ و خرابکاری مصروف گشته است، سیستم های متصل به اینترنت با تهدیدی واقعی و مداوم به نام حملات DoS مواجه هستند. این امر بدلیل دو مشخصه اساسی اینترنت است:

·   منابع تشکیل دهنده اینترنت به نوعی محدود و مصرف شدنی هستند.

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

·   امنیت اینترنت تا حد زیادی وابسته به تمام عوامل است.

حملات DoS معمولاً از یک یا چند نقطه که از دید سیستم یا شبکه قربانی عامل بیرونی هستند، صورت می گیرند. در بسیاری موارد، نقطه آغاز حمله شامل یک یا چند سیستم است که از طریق سوءاستفاده های امنیتی در اختیار یک نفوذگر قرار گرفته اند و لذا حملات از سیستم یا سیستم های خود نفوذگر صورت نمی گیرد. بنابراین، دفاع برعلیه نفوذ نه تنها به حفاظت از اموال مرتبط با اینترنت کمک می کند، بلکه به جلوگیری از استفاده از این اموال برای حمله به سایر شبکه ها و سیستم ها نیز کمک می کند. پس بدون توجه به اینکه سیستم هایتان به چه میزان محافظت می شوند، قرار گرفتن در معرض بسیاری از انواع حمله و مشخصاً DoS ، به وضعیت امنیتی در سایر قسمت های اینترنت بستگی زیادی دارد.

 

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

تکنولوژی حملات DoS اولیه شامل ابزار ساده ای بود که بسته ها را تولید و از «یک منبع به یک مقصد» ارسال می کرد. با گذشت زمان، ابزارها تا حد اجرای حملات از «یک منبع به چندین هدف»، «از چندین منبع به هدف های تنها» و «چندین منبع به چندین هدف»، پیشرفت کرده اند.

امروزه بیشترین حملات گزارش شده به CERT/CC مبنی بر ارسال تعداد بسیار زیادی بسته به یک مقصد است که باعث ایجاد نقاط انتهایی بسیار زیاد و مصرف پهنای باند شبکه می شود. از چنین حملاتی معمولاً به عنوان حملات طغیان بسته (Packet flooding) یاد می شود. اما در مورد «حمله به چندین هدف» گزارش کمتری دریافت شده است.

 

انواع بسته ها (Packets) مورد استفاده برای حملات طغیان بسته ، در طول زمان تغییر کرده است، اما چندین نوع بسته معمول وجود دارند که هنوز توسط ابزار حمله DoS استفاده می شوند.

·   طغیان های TCP: رشته ای از بسته های TCP با پرچم های ( flag ) متفاوت به آدرس IP قربانی فرستاده می شوند. پرچم های SYN، ACK و RST بیشتر استفاده می شوند.

·   طغیان های تقاضا\پاسخ ICMP (مانند طغیان های ping): رشته ای از بسته های ICMP به آدرس IP قربانی فرستاده می شود.

·   طغیان های UDP: رشته ای از بسته های UDP به آدرس IP قربانی ارسال می شوند.

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

گزارش همایش بررسی پیش نویس سند ملی امنیت فضای تبادل اطلاعات کشور (افتا)

روز چهارشنبه، نهم دیماه، به طور کاملاً اتفاقی سایت شورای عالی امنیت فضای تبادل اطلاعات کشور (افتا) را دیدم و در صفحه اول سایت، پوستر همایش ارائه، بررسی و نقد سند راهبرد ملی امنیت فضای تبادل اطلاعات کشور را مشاهده کردم! برایم جالب بود که تا به حال خبری از آماده سازی سند منتشر نشده و حتی درباره همایش فوق الذکر نیز اطلاع رسانی مناسبی انجام نشده بود. جهت حضور در همایش تماسی با دبیرخانه شورا گرفته شد که در پاسخ ما را به مرکز امنیت شبکه شریف ـ مجری همایش ـ راهنمایی کردند. طی تماس تلفنی با مرکز امنیت شبکه شریف گله کردم که چرا هیچ گونه خبر و اطلاعاتی درباره سند و همایش منتشر نشده است.  پاسخ شنیدم که برای متخصصان، کارشناسان و فعالان در این زمینه دعوتنامه ارسال شده است. از ما هم خواسته شد فاکس بفرستیم و لیست اسامی کسانی را که می خواهند در همایش حضور بیابند اعلام کنیم. این کار در همان روز انجام شده و قرار شد که روز شنبه ۱0/۱2 پاسخ را دریافت کنیم. شنبه بعدازظهر طی تماسی که با مرکز داشتیم به ما گفته شد که به دلیل کمبود جا و ثبت نام بیش از حد ظرفیت، از پذیرش افراد جدید معذورند. با چند تلفن متوجه شدیم که بسیاری از رسانه های فعال در زمینه IT نه تنها دعوت نشده اند که حتی از این موضوع خبر نیز ندارند. در همین حین و حدود ساعت 15:10 فاکس جالبی به دفتر بعضی مجلات ارسال شد . در این فاکس از خبرنگاران آن مجموعه جهت شرکت در مصاحبه ای با آقای مهندس جعفری – دبیر محترم شورای عالی افتا – دعوت شده بود. تا اینجا مشکلی نبود ولی با دیدن ساعت برگزاری مصاحبه که 16 بود، تعجب ما بیشتر شد که چطور توقع می رود که بدون هیچ اطلاع قبلی خبرنگاران بتوانند ظرف مدت 50 دقیقه از گوشه و کنار تهران خود را به مجموعه ریاست جمهوری برسانند.

به هرحال با همکاری جناب آقای دکتر جلیلی – دبیر محترم همایش و رئیس مرکز امنیت شبکه شریف – بالاخره توانستیم در همایش حضور یابیم و آنچه در ذیل می خوانید، گزارشی کوتاه از این همایش است. نکته ای که تذکر آن ضروری به نظر می رسد این است که همایش فضای تبادل اطلاعات و سند راهبردی آن گرچه مرتبط با “امنیت” است اما یک موضوع محرمانه امنیتی نیست که نتوان در باره آن اطلاع رسانی کرد. ضمنا پیش نویس سند در حال حاضر از سایت شورا قابل دریافت است.

 

مطابق با برنامه اعلام شده روز دوشنبه 14دیماه در دانشگاه صنعتی شریف، سالن جابربن حیان حضور یافتیم. قرار بود از ساعت 8 تا ۸:۳۰ ثبت نام انجام شود و در ساعت ۸:۴۰ پس از تلاوت قرآن مجید، اهداف همایش توسط دکتر جلیلی تبیین شود. ما هم پس از ثبت نام حدود ۸:۴۰ وارد سالن شدیم اما با کمال تعجب متوجه شدیم که ظاهراً برنامه زودتر شروع شده است، لذا صحبت های دکتر جلیلی را نشنیدیم و به اواسط صحبت های مهندس جعفری درباره ارائه کلیات سند رسیدیم. وی با اشاره به زحماتی که برای تهیه سند از حدود 10 ماه پیش کشیده شده متذکر شد که حدود 18000 نفرساعت کار کارشناسی بر روی سند انجام گرفته و در نتیجه حدود 1790 صفحه سند تولید شده است. وی خاطرنشان کرد که تهیه سند افتا براساس بند ج ماده ۴۴ برنامه چهارم توسعه به دولت تکلیف شده و امروز پیش نویس این سند تهیه شده و آماده نقد و ارائه نظر عمومی است.

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

 

 وی همچنین به تاریخچه این شورا اشاره کرد و پیشنهاد انجمن رمز در آبان سال گذشته را پایه تشکیل شورای عالی افتا در اسفند ۸۲ معرفی کرد. وی با اظهار امیدواری به اجرای سند گفت: “ تفاوت ما با کشورهای توسعه یافته این است که آنها سند را می نویسند که اجرا کنند اما ما می نویسیم که نوشته باشیم!”

قابل به ذکر است که طی سخنرانی معاون اول رئیس جمهور، دوبار برق سالن به مدت چند ثانیه رفت و سالن همایش در تاریکی مطلق فرو رفت که ظاهراً علّت آن قطعی برق سراسری و بازه زمانی مورد نیاز جهت وارد مدار شدن برق اضطراری دانشگاه بود.

با پایان سخنان دکتر عارف، مراسم افتتاحیه همایش پایان یافت و پس از پذیرایی و در ساعت ۱۰:۳۰ بخش دوم همایش با موضوع معرفی سند آغاز شد. در این بخش ابتدا دکتر برنجکوب به رویکرد دیگر کشورها به سند راهبردی ملی امنیت پرداخت و به مقایسه نگرش دو کشور آمریکا و فنلاند به شیوه تدوین سند و دلایل آن پرداخت. نکته جالب آن بود که آمریکا به تازگی و بعد از حادثه ۱۱ سپتامبر و با هدف جلوگیری از حملات علیه زیرساختهای حیاتی کشور به فکر تدوین این سند افتاده است. اما فنلاند از تدوین این سند افزایش رفاه اجتماعی مردم خود را مدنظر دارد. پس از دکتر برنجکوب، دکتر غریبی به مدل برنامه ریزی راهبردی برای سند راهبردی ملی امنیت پرداخت و دکتر جلیلی به معرفی سند راهبرد ملی افتا پرداخت. رئیس مرکز امنیت شبکه شریف در ابتدا به دلایل و شیوه تدوین سند پرداخت. وی با اشاره به مدل مورد استفاده جهت تدوین سند (swot) راهبردهای اولیه  و نهایی را با توجه به قوتها، فرصتها، تهدیدها و ضعفها معرفی کرد. در پایان دکتر جلیلی پیش نویس تهیه شده را مرور کرد و بخش های مختلف آن را معرفی نمود. بخش دوم همایش با سخنرانی مهندس خالقی با موضوع زیرساختهای فنی افتا پایان یافت.

نشست های بعدازظهر که با حدود یک ربع تأخیر و در ساعت 13:45 آغاز شد به نقد سند اختصاص داشت. در نشست اول با موضوع نقد تخصصی سند راهبرد ملی افتا به ترتیب آقایان دکتر ولوی و مهندس پورآذین سخنرانی کردند و سپس حاضران به بیان نظرات و انتقادات خود پرداختند. از جمله مهمترین موارد مطرح شده در این نشست می توان به موارد زیر اشاره کرد:

-     ظاهراً به جز دولت سایر بخش های حکومت در این سند دیده نشده اند. برای مثال در اقدام ۸-۲ ،  ایجاد نظام مقابله با جرایم فتا شامل ایجاد دادگاه ها و آموزش قضاوت و ... به عهده وزارت کشور گذارده شده است در حالی که این کار وظیفه قوه قضائیه است.

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

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

-     یکی از کارشناسان و متخصصان سازمان مدیریت نیز با انتقاد از روند کاری ریاست جمهوری پرسید : “چرا ریاست جمهوری خود به کارهای اجرایی روی می آورد؟ پس وزارت ارتباطات و فناوری اطلاعات چه کاره است؟ اضافه شدن یک شورایعالی به شوارهای عالی چه فایده دارد، در حالیکه این شورا نیز مسیر شورایعالی اطلاع رسانی را می پیماید؟”

-          مهندس پورآذین نیز با واردآوردن انتقاداتی جدی به سند آن را منطبق با تکنولوژی جدید ندانست.

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

دکتر دژپسند، رئیس کمیته اقتصادی -  تجاری شورا و معاون وزیر بازرگانی، یکی از افراد حاضر در این میزگرد بود که به معرفی فعالیت های کمیته خود پرداخت. وی این کمیته را متشکل از نمایندگان بانک مرکزی و وزارتخانه های اقتصاد و دارایی، بازرگانی، صنایع و معادن و راه وترابری معرفی کرد که به مباحث افتا در موضوعات اقتصادی و تجاری می پردازند. وی با اشاره به کار انجام شده جهت تهیه سند، قرار گرفتن نام وزارت کشور به عنوان مسؤول تشکیل دادگاه ها را اشکال تایپی دانست. دکتر دژپسند پس از مدت کوتاهی به دلیل گرفتاری های کاری مجبور به ترک میزگرد شد و نقد با حضور سه نفر یعنی آقایان مهندس جعفری، دکتر جلیلی و دکتر سمیعی ادامه یافت.

دکتر سمیعی، رئیس کمیته امور فرهنگی - اجتماعی، نیز با معرفی کمیته خود به شرح فعالیت های انجام شده پرداخت. به گفته وی سازمان صدا و سیما و وزارتخانه های دادگستری، آموزش و پرورش، علوم، تحقیقات و فناوری و فرهنگ و ارشاد اسلامی تشکیل دهنده این کمیته هستند.

به گفته مهندس جعفری کمیته امور دفاعی - امنیتی که متشکل از وزارتخانه های دفاع، امور خارجه، کشور و اطلاعات است زیر نظر مهندس فیروز آبادی به فعالیت می پردازد و کمیته امور زیربنایی نیز که با هدف استمرار خدمات زیربنایی کشور و با ریاست دکتر کرمانشاه فعالیت می کند، از وزارتخانه های راه و ترابری، بهداشت، نیرو و نفت تشکیل شده است.

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

-          سند ایستاست و پویایی ندارد.

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

-          ایجاد ساز و کار قانونی سلامت محتوا که در بند ۴-۳ به آن اشاره شده است، متولی دیگری دارد و به عهده این شورا نیست.

-          دستگاه های مجری و همکار در اقدامات و راهبردهای ارائه شده به درستی انتخاب نشده اند.

-          الزامات قانونی تصویب سند مشخص نشده است.

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

عدم پذیرش سرویس (۲) : انواع حملات

عدم پذیرش سرویس (۲) : انواع حملات

در مقاله پیش با حمله DoS آشنا شدیم. از آنجا که حملات طغیان بسته های دیتا معمولاً تلاش می کنند منابع پهنای باند و پردازش را خلع سلاح کنند، میزان بسته ها و حجم دیتای متناظر با رشته بسته ها عوامل مهمی در تعیین درجه موفقیت حمله هستند. بعضی از ابزارهای حمله خواص بسته ها را در رشته بسته ها بدلایلی تغییر می دهند:

·   آدرس IP منبع – در بعضی موارد، یک آدرس IP منبع ناصحیح، (روشی که جعل IP نامیده می شود) برای پنهان کردن منبع واقعی یک رشته بسته استفاده می شود. در موارد دیگر، جعل IP هنگامی استفاده می شود که رشته های بسته به یک یا تعداد بیشتری از سایت های واسطه فرستاده می شوند تا باعث شود که پاسخ ها به سمت قربانی ارسال شود. مثال بعدی در مورد حملات افزایش بسته است (مانند smurf و fraggle)

·   پورتهای منبع\مقصد-  ابزار حمله طغیان بسته بر اساس TCP و UDP ، گاهی اوقات پورت منبع و یا مقصد را تغییر می دهند تا واکنش توسط فیلتر کردن بسته را مشکل تر کنند.

·   مقادیر IP Header دیگر -  در نهایت در ابزار حمله DoS مشاهده کرده ایم که برای مقداردهی تصادفی، مقادیر Header هر بسته در رشته بسته ها طراحی شده اند که تنها آدرس IP مقصد است که بین بسته ها ثابت می ماند.

بسته ها با خواص ساختگی بسادگی در طول شبکه تولید و ارسال می شوند. پروتکل TCP/IP به آسانی مکانیزم هایی برای تضمین پیوستگی خواص بسته ها در هنگام تولید و یا ارسال نقطه به نقطه بسته ها ارائه نمی کند. معمولاً، یک نفوذگر فقط به داشتن اختیار کافی روی یک سیستم برای بکارگیری ابزار و حملاتی که قادر به تولید و ارسال بسته های با خواص تغییریافته باشند، نیاز دارد.

ژوئن ۱۹۹۹، آغاز بکارگیری ابزار DoS با چندین منبع یا DDos (Distributed DoS) بود.

روش های حمله DoS

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

Smurf یا Fraggle

حملات smurf یک از مخرب ترین حملات DoS هستند. (شکل زیر)

 

در حمله Smurf (حمله براساس ازدیاد بسته های ICMP)، نفوذگر یک تقاضای اکوی ICMP (ping) به یک آدرس ناحیه می فرستد. آدرس منبع تقاضای اکو، آدرس IP قربانی است. (از آدرس IP قربانی بعنوان آدرس برگشت استفاده می شود). بعد از دریافت تقاضای اکو، تمام ماشین های ناحیه پاسخ های اکو را به آدرس IP قربانی می فرستند. در این حالت قربانی هنگام دریافت طغیان بسته های با اندازه بزرگ از تعداد زیادی ماشین، از کار خواهد افتاد.

 

حمله Smurf برای ازکار انداختن منابع شبکه سیستم قربانی از روش مصرف پهنای باند استفاده می کند. این حمله این عمل را با استفاده از تقویت پهنای باند نفوذگران انجام می دهد. اگر شبکه تقویت کننده ۱۰۰ ماشین دارد، سیگنال می تواند ۱۰۰ برابر شود، و بنابراین حمله کننده با پهنای باند پایین (مانند مودم ۵۶ کیلوبیتی) می تواند سیستم قربانی را با پهنای باند بیشتری (مانند اتصال T1) از کار بیندازد.

حمله Fraggle (تقویت بسته  UDP) در حقیقت شباهت هایی به حمله Smurf دارد. حمله Fraggle از بسته های اکوی UDP بر طبق همان روش بسته های اکوی ICMP در حمله Smurf استفاده می کند. Fraggle معمولاً به ضریب تقویت کمتری نسبت به Smurf می رسد، و در بیشتر شبکه ها اکوی UDP سرویسی با اهمیت کمتر نسبت به اکوی ICMP است، بنابراین Fraggle عمومیت Smurf را ندارد.

SYN Flood

حمله طغیان SYN قبل از کشف حمله Smurf بعنوان مخرب ترین شیوه حمله DoS بشمار می رفت. این روش برای ایجاد حمله DoS بر اساس قحطی منابع عمل می کند.

در طول برقراری یک ارتباط معمولی TCP، سرویس گیرنده یک تقاضای SYN به سرویس دهنده می فرستد، سپس سرور با یک ACK/SYN به کلاینت پاسخ می دهد، در نهایت کلاینت یک ACK نهایی را به سرور ارسال می کند و به این ترتیب ارتباط برقرار می شود.

اما در حمله طغیان SYN، حمله کننده چند تقاضای SYN به سرور قربانی با آدرس های منبع جعلی بعنوان آدرس برگشت، می فرستد. آدرس های جعلی روی شبکه وجود ندارند. سرور قربانی سپس با ACK/SYN به آدرس های ناموجود پاسخ می دهد. از آنجا که هیچ آدرسی این ACK/SYN را دریافت نمی کند، سرور قربانی منتظر ACK از طرف کلاینت می ماند. ACK هرگز نمی رسد، و زمان انتظار سرور قربانی پس از مدتی به پایان می رسد. اگر حمله کننده به اندازه کافی و مرتب تقاضاهای SYN بفرستد، منابع موجود سرور قربانی برای برقراری یک اتصال و انتظار برای این ACKهای در حقیقت تقلبی مصرف خواهد شد. این منابع معمولاً از نظر تعداد زیاد نیستند، بنابراین تقاضاهای SYN جعلی حتی با تعداد نسبتاً کم می توانند باعث وقوع یک حمله DoS شوند.

حملات DNS

در نسخه های اولیه BIND (Berkely Internet Name Domain)، حمله کنندگان می توانستند بطور مؤثری حافظه نهان یک سرور DNS را که در حال استفاده از عملیات بازگشت برای جستجوی یک ناحیه بود که توسط این سرور سرویس داده نمی شد، مسموم کنند. زمانی که حافظه نهان مسموم می شد، یک کاربر قانونی به سمت شبکه مورد نظر حمله کننده یا یک شبکه ناموجود هدایت می شد. این مشکل با نسخه های جدیدتر BIND برطرف شده است. در این روش حمله کننده اطلاعات DNS غلط که می تواند باعث تغییر مسیر درخواست ها شود، ارسال می کند.

حملات DDoS

حملات DDoS (Distributed Denial of Service) حمله گسترده ای از DoS است. در اصل DDos حمله هماهنگ شده ای برعلیه سرویس های موجود در اینترنت است. در این روش حملات DoS بطور غیرمستقیم از طریق تعداد زیادی از کامپیوترهای هک شده بر روی کامپیوتر قربانی انجام می گیرد. سرویس ها و منابع مورد حمله ، «قربانی های اولیه» و کامپیوترهای مورد استفاده در این حمله «قربانی های ثانویه» نامیده می شوند. حملات DDoS عموماً در از کار انداختن سایت های کمپانی های عظیم از حملات DoS مؤثرتر هستند.

انواع حملات DDoS

عموماً حملات DDoS به سه گروه Trinoo، TFN/TFN2K و Stecheldraht تقسیم می شوند.

Trinoo

Trinoo در اصل از برنامه های Master/Slave است که با یکدیگر برای یک حمله طغیان UDP بر علیه کامپیوتر قربانی هماهنگ می شوند. در یک روند عادی، مراحل زیر برای برقراری یک شبکه Trinoo DDoS واقع می شوند:

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

مرحله۲: به محض اینکه این لیست آماده شد، اسکریپت ها برای هک کردن و تبدیل آنها به اربابان(Masters) یا شیاطین (Daemons) اجراء می شوند. یک ارباب می تواند چند شیطان را کنترل کند. شیاطین میزبانان هک شده ای هستند که طغیان UDP اصلی را روی ماشین  قربانی انجام می دهند.

مرحله۳: حمله DDoS هنگامی که حمله کننده فرمانی به میزبانان Master ارسال می کند، انجام می گیرد. این اربابان به هر شیطانی دستور می دهند که حمله DoS را علیه آدرس IP مشخص شده در فرمان آغاز کنند و با انجام تعداد زیادی حمله DoS  یک حمله DDoS شکل می گیرد.

TFN/TFN2K

TFN (Tribal Flood Network) یا شبکه طغیان قبیله ای، مانند Trinoo، در اصل یک حمله Master/Slave است که در آن برای طغیان SYN علیه سیستم قربانی هماهنگی صورت می گیرد. شیاطین TFN قادر به انجام حملات بسیار متنوع تری شامل طغیان ICMP، طغیان SYN و حملات Smurf هستند، بنابراین TFN از حمله Trinoo پیچیده تر است.

TFN2K نسبت به ابزار TFN اصلی چندین برتری و پیشرفت دارد. حملات TFN2K با استفاده از جعل آدرس های IP اجرا می شوند که باعث کشف مشکل تر منبع حمله می شود. حملات TFN2K فقط طغیان ساده مانند TFN نیستند. آنها همچنین شامل حملاتی می شوند که از شکاف های امنیتی سیستم عامل ها برای بسته های نامعتبر و ناقص سوءاستفاده می کنند تا به این ترتیب باعث از کار افتادن سیستم های قربانی شوند. حمله کنندگان TFN2K دیگر نیازی به اجرای فرمان ها با وارد شدن به ماشین های مخدوم (Client) )به جای Master در TFN) ندارند و می توانند این فرمان ها را از راه دور اجراء کنند. ارتباط بین Clientها و Daemonها دیگر به پاسخ های اکوی ICMP محدود نمی شود و می تواند روی واسط  های مختلفی مانند TCP و UDP صورت گیرد. بنابراین TFN2K خطرناک تر و همچنین  برای کشف کردن مشکل تر است.

Stacheldraht

کد Stacheldraht بسیار شبیه به Trinoo و TFN است، اما Stacheldraht اجازه می دهد که ارتباط بین حمله کننده و Masterها (که در این حمله Handler نامیده می شوند) رمزنگاری شود؛ عامل ها می توانند کد خود را بصورت خودکار ارتقاء دهند، می توانند اقدام به انواع مختلفی از حملات مانند طغیان های ICMP، طغیان های UDP و طغیان های SYN کنند.

آیا معاملات اینترنتی امن، واقعاً امن هستند؟

آیا معاملات اینترنتی امن، واقعاً امن هستند؟

امروزه مرورگرها از تکنیکی به نام SSL (Secure Socket Layer) استفاده می کنند تا اطلاعاتی را که بین مرورگر شما و وب سرور مبادله می شود، رمزنگاری کنند. هنگامی که علامت «قفل» در گوشه پایین مرورگر نمایش داده می شود، به این معنی است که مرورگر ارتباط رمزشده امن با سرور برقرار کرده است و لذا ارسال دیتای حساس مانند شماره کارت اعتباری امن است. اما آیا واقعا این سیستم امن است و می توان از این طریق با اطمینان تراکنشهای حساس مالی را رد و بدل کرد؟ پاسخ این است که SSL فقط ارتباط بین مرورگر شما و وب سرور را امن می کند و برای محافظت از اطلاعات شما در آن سرور کاری انجام نمی دهد. در شرکت های بزرگ که می توانند سرورها و خطوط ارتباطی با ظرفیت های بالا را اختصاصی و برای ارتباط مستقیم تهیه کنند، تا جایی که شما بتوانید به شرکت اعتماد کنید، مشکلی ایجاد نخواهد شد. اما بسیاری از شرکت های کوچک تر توانایی تهیه سرور اختصاصی را ندارند. آنها از «میزبانی شخص ثالث» استفاده می کنند و این جایی است که عدم امنیت بوجود می آید. شما مجبورید به میزبانی که هیچ شناختی از آن ندارید، اطمینان کنید و به ایمن بودن نحوه دریافت اطلاعاتتان از آن میزبان توسط شرکت مورد نظرتان اعتماد کنید. اما تضمینی برای ایمن بودن این ارتباط نیست!

 

بیشتر میزبان های وب برای کلاینت های خود یک برنامه  (CGI (Common Gateway Interface ارائه می دهند که FormMail نام دارد. آنچه که این برنامه انجام می دهد این است که محتوای یک فرم اینترنتی را، مانند فرمی که شما اطلاعات کارت اعتباری خود را در آن قرار می دهید، می گیرد و از طریق ایمیل به شرکت ارسال می کند. برای این ایمیل نه محافظتی وجود دارد و نه رمزنگاری صورت می گیرد.

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

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

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

 

ایمن کردن معاملات

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

روش امن دیگر، ذخیره اطلاعات در پایگاه داده ای روی وب سرور اما در جایی است که از وب دسترسی مستقیم به آن ممکن نباشد. زمانی که شرکت میزبان اینترنت قابل اعتماد نیست و یا قصد دارید امنیت بیشتری را به وجود آورید، این پایگاه داده می تواند رمزنگاری شود. تاجران بعداً می توانند اطلاعات مربوط به معاملات را با استفاده از ارتباط رمزشده SSL خود بازیابی کنند. اما در این روش فروشنده باید بتواند سیستم امن را برای خود ایجاد کند. این عمل به میزان مشخصی از تواناییهای برنامه سازی احتیاج دارد تا اسکریپت های CGI برای استفاده از این سیستم نوشته شود.

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

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

بهرحال، هنوز روش کاملی برای تضمین امن ماندن اطلاعات وجود ندارد. بنابراین به جمله Caveat Emptor می رسیم که «بگذارید خریدار خود آگاه و مواظب باشد.»

رویدادهای امنیتی و اقدامات لازم در برخورد با آنها (Incident Hand

مقدمه

حتماً در مقوله های مرتبط با امنیت کامپیوتر و شبکه با عبارت Incident Handling مواجه شده اید. ابتدا ببینیم یک رویداد امنیتی ( (Security Incident چیست. هر سازمان باید رویداد امنیتی را برای تشکیلاتش کند. تعاریف زیر نمونه هایی از این دست هستند:

هر رویداد مضر مشخص یا مشکوکی که به امنیت سیستم ها یا شبکه های کامپیوتری مربوط باشد.

یا

عمل نقض کردن آشکار یا ضمنی سیاست امنیتی.

فعالیت هایی زیر مثال هایی از  یک رویداد امنیتی هستند:

·         تلاشهایی (چه موفق و چه ناموفق) برای حصول دسترسی غیرمجاز به یک سیستم یا دیتای آن

·         ازکار افتادن ناخواسته یا عدم پذیرش سرویس

·         استفاده غیرمجاز از یک سیستم به هدف پردازش یا ذخیره سازی دیتا

·         تغییراتی در مشخصات سخت افزار یا نرم افزار بدون آگاهی یا اجازه یا دخالت صاحب آن.

فعالیت شبکه یا میزبان که بالقوه امنیت کامپیوتر را تهدید می کند نیز می تواند بعنوان رویداد امنیتی کامپیوتری تعریف گردد.

برخورد با رویداد

 منظور از این عبارت نحوه مقابله و اقداماتی است که در هنگام وقوع یک مسأله امنیتی انجام می گیرد. در حقیقت این اقدامات به سه بخش تقسیم می شود. گزارش رویداد، تحلیل رویداد و واکنش به رویداد.

اهمیت واکنش به رویدادهای امنیتی سیستم ها، کمتر از تشخیص آنها نیست. اقداماتی که شما بدنبال تشخیص یک رویداد انجام می دهید، نه تنها عملیات سازمان را تحت تأثیر قرار می دهد، بلکه ممکن است باعث تغییرات بسیاری در آینده چنین روندهایی و وضعیت امنیتی خودتان گردد.

در این مقاله به برخورد با رویدادهای امنیتی نه از دیدگاه تکنیکی بلکه از دیدگاه عواملی مانند عوامل انسانی، سیاست برخورد و زمان پرداخته می شود. برای اینکه بتوان بیشتر با نحوه  برخورد یک سازمان به یک رویداد امنیتی آشنا شد، به مثالی در این باره می پردازیم.

مثالی از واکنش به یک رویداد در یک سازمان بزرگ

این مثال فقط برای نشان دادن تلاش های ممکن برای واکنش ارائه شده است و یک مدل کلی نیست.

هنگام مشاهده ثبت وقایع مربوط به نفوذ در ساعت ۲ بامداد، پرسنل ۲۴ ساعته مراقبت از شبکه کشف می کنند که حمله ای با موفقیت انجام شده است.

برای بسیاری از سازمان ها، واکنش فوری، قطع شبکه برای تأخیر یا قطع افشای اطلاعات بیشتر خواهد بود، اما ما سعی داریم که از چنین واکنشی پرهیز کنیم و پرسنل بخش مراقبت نیز از این قضیه مطلع هستند. درعوض، چک لیست هایی را که در اختیار دارند برای برخورد با این نوع رویداد به اجرا می گذارند.

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

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

حالا از اخطار اولیه ۲۸ دقیقه گذشته است.

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

سایر اعضای گروه  به صورت پراکنده در طول این زمان وارد شده اند و پرسنل بخش مراقبت نیز تحقیق بیشتری در مورد نفوذ انجام داده است. بررسی اولیه آشکار می کند که نفوذگر به سیستم یک کاربر وارد شده است، اما هنوز به نقاط دیگر شبکه پیشروی نکرده است. حمله از طریق استفاده یک کاربر از یک اتصال dial-up که مورد تأیید نبوده صورت گرفته است. نفوذ واقعی هشت ساعت قبل از کشف اولیه صورت گرفته است.

کل گروه ۹۲ دقیقه بعد از اولین اخطار گرد هم می آیند. تمام اعضاء با سرعت در محل حاضر و شروع به فکر کردن و نقشه کشیدن و ارائه راه حل شده اند. مناظرات به موافقت هایی منجر می شود. سیستم مورد نفوذ از شبکه جدا خواهد شد و عملیات تعیین و تشخیص آغاز خواهد شد. خلاصه ای برای مدیر ارشد تهیه و مراحل اولیه کامل می شوند. ۱۰۸ دقیقه گذشته است.

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

 

با سپری شدن ۱۴۱ دقیقه از آغاز، گروه برای مرور و به روز رسانی پیشرفت کار دوباره دور هم جمع می شوند. مشخص شده است که نفوذگر از یک IP بیگانه جعلی از طریق اتصال dial-up استفاده کرده است و فقط قادر به دستیابی به همان سیستم بوده است. بررسی کامل شبکه احتیاج به این دارد که سرورها از شبکه جدا شوند و این عملیات ۶ ساعت زمان نیاز دارد. گروه با مشورت و تصویب مدیریت ارشد، تصمیم به این بررسی می گیرد اما بعد از بسته شدن سازمان در انتهای روز کاری بعد.

هنگامی که روز کاری آغاز می شود، فعالیت ها به بیرون فاش می شود و فردی که سیستمش مورد نفوذ قرار گرفته مورد مصاحبه قرار می گیرد و سیستم مورد نفوذ پاکسازی می گردد و به افراد ارشد گزارشها بصورت خلاصه ارائه می شود. بهرحال، عملیات امداد به اوج خود می رسد و مرتفع سازی آغاز می شود. تا ساعت ۲۳ رویداد برطرف شده است و گزارش نهایی روز بعد آماده خواهد شد.

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