محل استفاده از سامانه پیشگیری/تشخیص نفوذ (NIDS)


استفاده از
Network Intrusion
Detection System
با توجه به افزایش روزافزون مخاطرات ناشناخته و یا غیرقابل پیش
بینی (حمله هایی که سرمنشا داخلی دارند و یا zero-day ها) انتخاب عاقلانه و در برخی
موارد اجباری است. محل به کارگیری یک
NIDS بر اساس این سه عامل قابل بررسی است:

بودجه

حساسیت و محرمانگی

توانایی ها و قابلیت های موجود در سازمان

اگر بتوان با عامل بودجه مقابله کرد، استفاده از سناریوی زیر
به عنوان الگوی اولیه (برای ارتباطات LANبهWAN) همواره بهترین نقطه شروع برای شبکه
هایی با حساسیت متوسط و بالا است (شبکه های سازمانی، شبکه های مالی و شبکه های
نظامی_یا محرمانه_):

سامانه پیشگیری/تشخیص نفوذ خارجی (External NIDS)
– پوشش امنیتی اولیه که به صورت پیش فرض تمامی درخواست ها را با
حالت Deny پاسخ می دهد:
۱- Router
با الزمات امنیتی و Access Control Lists
۲- فایروال
۳-
پروکسی (Application
aware proxies
بسته به برنامه هایی که استفاده می شوند یا خواهند شد.)
– سامانه پیشگیری/تشخیص نفوذ داخلی (Internal
NIDS)
DMZ برای برنامه هایی که به صورت
عمومی استفاده خواهند شد.
– پیاده سازی سرویس های شبکه با دید امنیتی و به کار بردن شیوه
نامه های موجود
– سامانه پیشگیری/تشخیص نفوذ شبکه های بی سیم در صورت استفاده (Wireless
IDS/IPS)

چرا از سامانه پیشگیری/تشخیص نفوذ خارجی (External NIDS)
استفاده کنیم؟
NIDS خارجی به عنوان نقطه امنیتی صفر وظیفه تشخیص،
تحلیل و جمع آوری (و در برخی سناریوها پیشگیری) مخاطرات امنیتی که از سمت شبکه های
مبتنی بر IP خارجی (مانند اینترنت و شبکه های
WAN مشترک) روی می دهند را دارد. داده های جمع آوری شده
می تواند به صورت real-time تحلیل شود و همچنین برای
پیگیری های آینده مورد استفاده قرار بگیرد. همچنین این سامانه می بایست توانایی
تولید پیغام های خطر را پیش از بروز مشکل داشته باشد.  چهار هدف اولیه که منجر
به استفاده از NIDS خارج از محدوده شبکه
LAN در نقطه اتصال با WAN می
شوند، عبارتند از:

۱- تحلیل نفوذ با استفاده از داده های جمع
آوری شده در قبل
۲- تشخیص بی وقفه و real-time نفوذ
۳- جمع آوری مدارک (Evidence
gathering
) مستند
۴- جمع آوری آمار

حفاظت در مقابل درخواست های دوگانه

Response Cache: Double Request Protection

(کش پاسخ: حفاظت در مقابل درخواست های دوگانه)

یک مشکل استاندارد در web-application ها پردازش مناسب درخواست های دوگانه (چندگانه) با دیتای یکسان است. سناریوهای ممکن عبارتند از:
۱- refresh کردن صفحه جاری
۲- انجام bakc-forward در صفحات وب
۳ – کلیک کردن بیش از یکبار دکمه submit

درخواست های چندگانه می تواند اثرات جدی بر روی برخی application ها مانند خرید و فروش اینترنتی داشته باشد. راه حل های client-side برای رفع این مشکل، کامل نیستند. به عنوان مثال می توان توسط JavaScript، double click را بر روی submit غیرفعال کرد، مشروط بر اینکه کاربر JavaScript را در مرورگر خود فعال کرده باشد.
هر چند مشکل در مورد refresh و back- forward به قوه خود باقی است. و یا تنظیم هدرهای HTML تنها منجر به اعلام warning به کاربر می شود که می تواند از آن صرف نظر کند. تنها متد قابل اعتماد، حفاظت در طرف سرور است. راه حل ساده و اولیه، تولید شناسه های یکتا در پاسخ به درخواست های یک کاربر (هر session) و ارسال یه سرور توسط hidden fields و  مقایسه آن با id ذخیره شده در session است. در صورت یکسان بودن هر دو id، کاربر به صفحه خطا هدایت می شود. اما نمایش صفحه خطا چندان مطلوب نیست چون کاربر گزارش وضعیتی مناسبی در مورد عمل قبلی خود دریافت نمی کند. Response cache یک راه حل کلی مبتنی بر Servlet Filter است. کلیه درخواست ها به یک فیلتر ارسال می شود. در صورتی که درخواست برای اولین بار ارسال شده باشد پردازش توسط سرولت های مقصد انجام شده و نتیجه به کاربر ارسال و ضمنا در کش ذخیره می گردد. در صورت تکراری بودن، نتیجه قبلی از کش ارسال می شود.

– این library را می توانید از اینجا دانلود کنید.
منبع از گروه FINGO
– اطلاعات بیشتر در مورد Servlet Filter را می توانید در The Essentials of Filters بیابید.