ویژگی امنیتی Cisco IOS

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

  • Class-Based Access Control یا CBAC

  • Port-to-Address Mapping یا PAM

  • Authentication Proxy

  • TCP Intercept

  • Intrusion Prevention

  • AutoSecure

میزان دسترسی

طراحی سیستم ها با مشخص کردن یک مقیاس به عنوان معیار قابل دسترس بودن (درصد میزان دسترسی)، به صورت واقعی تا حدودی مشکل (غیر ممکن) است. وجود پارامترهای مختلفی که در سرویس دهی سیستم ها (چه سیستم های شبکه ای، چه سیستم های نرم افزاری) وجود دارند و غیر قابل کنترل بودن بعضی از این پارامتر ها از جمله مواردی است که باعث مشکل بودن این کار می شود. از مجموع ۸۷۶۰ ساعتی که در سال وجود دارد، بسته به حساسیت، اهمیت و حیاتی بودن سیستم، محدوده Uptime مشخصی برای سرویس دهی می بایست مورد هدف قرار بگیرد. جدولی برای این محدوده را که در حالت معمول تعداد ۹ها (Nines) آن را مشخص می کند، می تواند مشاهده کنید. (برای تفریح > Uptime-Project)

میزان دسترسی % Downtime در سال Downtime در ماه Downtime  در هفته
۹۰% ۳۶٫۵ days ۷۳ hours ۱۶٫۸۴ hours
۹۵% ۱۸٫۲۵ days ۳۶٫۵ hours ۸٫۴۲ hours
۹۸% ۷٫۳۰ days ۱۴٫۴ hours ۳٫۳۶ hours
۹۹% ۳٫۶۵ days ۷٫۲۰ hours ۱٫۶۸ hours
۹۹٫۵% ۱٫۸۳ days ۳٫۶۰ hours ۵۰٫۴ min
۹۹٫۹% ۸٫۷۶ hours ۴۳٫۲ min ۱۰٫۱ min
۹۹٫۹۹% ۵۲٫۶ min ۴٫۳۲ min ۱٫۰۱ min
۹۹٫۹۹۹% ۵٫۲۶ min ۲۵٫۹ s ۶٫۰۵ s
۹۹٫۹۹۹۹% ۳۱٫۵ s ۲٫۵۹ s ۰٫۶۰۵ s

استاندارد های امنیتی کاربردی

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

Application Security Standards

  • Common Intrusion Detection Signatures Standard (CIDSS)
  • Common Vulnerabilities and Exposures (CVE)
  • DMTF Alert Standard Format Specification (ASF)
  • IETF Incident Object Description and Exchange Format (IODEF)
  • IETF Intrusion Detection Exchange Format (IDMEF)
  • OASIS Application Vulnerability Description Language TC (AVDL)
  • OASIS Web Application Security TC (WAS)
  • OpenSec Advisory and Notification Markup Language (ANML)
  • Open Vulnerability Assessment Language (OVAL)
  • Open Web Application Security Project (OWASP)
  • VulnXML Project: A Web Application Security Vulnerability Description Language

سیستم های ردیابی و کشف نفوذ توزیع شده – dIDS

سیستم های ردیابی و کشف نفوذ توزیع شده که با dIDS از آن یاد می کنیم،از چندین IDS در یک شبکه بزرگ تشکیل شده اند. تمامی این Intrusion Detection System ها، در ارتباط با یدیگر هستند و یا به وسیله یک سیستم (شاید یک سرور) مرکزی در حال پایش شبکه، تحلیل رویدادها و جمع آوری اطلاعات حمله های شناسایی شده، می باشند. این ترکیب برای جمع آوری اطلاعات امکان ایجاد یک دید وسیع برای تیم امنیتی/نگهدارنده شبکه در مورد وقایعی که در هر لحظه در حال جریان است را فراهم می کند.

یک distributed IDS به سازمان ها و اپراتورهای شبکه اجازه می دهد تا به صورت موثر و مستند منابع شبکه ای و سازمانی خود را تحت کنترل قرار دهند و در صورت نیاز به سرعت اطلاعات مورد نیاز را از سیستم بیرون بکشند. برای آشنایی بیشتر مقاله زیر را بخوانید:

An Introduction To Distributed Intrusion Detection Systems

Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred.

تبادل اطلاعات بین IDS ها در سه گونه تقسیم بندی می شود. دسته اول محصولاتی که برای dIDS طراحی شده اند و با استفاده agentهای مختلف در نقاط مختلف شبکه اطلاعات را برای سرور کنترلی IDS ارسال می کنند. دسته دوم محصولاتی که شامل IDS هایی از یک دسته هستند و لاگ فایل های خود را در یک محل متمرکز ذخیره می کنند و مانند دسته اول ادامه کار می دهند. و بالاخره دسته سوم که شامل IDS ها و IPS های (به طور کلی آن ها را sensor خطاب می کنیم.) مختلف از مارک های متفاوتی هستند که به وسیله ابزار های مدیریت سیستم های امنیتی لاگ فایل ها را ذخیره و پردازش می کنند. استاندارد تبادل اطلاعات در سنسور ها، در قالب یک پیش نویس استاندارد IETF در حال شکل گیری است.

The Intrusion Detection Message Exchange Format (IDMEF) is intended to be a standard data format that automated intrusion detection systems can use to report alerts about events that they deem suspicious. The development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal implementation.

به دو علت پروژه های کمی در مورد dIDS هم اکنون وجود دارد. اولین مورد عدم درک نیاز به چنین سیستمی در بخش تجاری و صنعتی و دلیل دوم نو بودن چنین ترکیبی است. همانطور که پیشتر گفتم، IDMEF هنوز به حالت استاندارد در نیامده است. البته جایگزینی این سیستم به وسیله سیستم های یکپارچه مدیریت امنیت گران قیمت نیز دلیل دیگری در کم بودن پروژه ها است. تعدادی از این پروژه ها را در freshmeat ببینید. بدنیست نگاهی هم به پروژه رو به پیشرفت Prelude Hybrid IDS ( حداقل What is Prelude Hybrid IDS را بخوانید.) بندازید.

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

کارت های CRC

یکی از ارزشمندترین تکنیک ها در یک طراحی شی گرای خوب مرور تعاملات اشیاست که بر رفتار به جای دیتا متمرکز است.دیاگرام های CRC (سر واژه Class Responsibilities Collaboration) در اواخر دهه ۱۹۸۰ ابداع شده و هر چند جز UML نیست به عنوان یک تکنیک بسیار رایج در میان طراحان شی گرا شناخته شده است.
هر کارت CRC نماینده یک کلاس است که responsibilityها و collaboratorهای کلاس در آن بیان می شود.
یک responsibility یک عبارت کوتاه است که یکی از وظایف شی را خلاصه می کند: عملیاتی که انجام می دهد، دانشی که نگهداری می کند و تصمیمات مهمی که شی اتخاذ می نماید.ایده این است که طراح باید قادر باشد هر کلاس را در قالب تعدادی responsibility خلاصه کند. Responsibility ممکن است متناظر با یک operation، یک attribute و یا مجموعه نامشخصی از operationها و attributeها باشد.
برای هر کلاس collaboratorها کلاس های دیگری هستند که این کلاس نیاز به کار با آنها دارد.تعیین collaboratorها ایده هایی در مورد لینک های بین کلاس ها به دست می دهد.
برای استفاده از این متد اعضای تیم گردهم آمده و سناریوهای متفاوت را با استفاده از کارت ها مرور می کنند. به این صورت که کارت اشیای فعال بالا نگه داشته شده و برای نشان دادن نحوه ارسال پیغام به یکدیگر حرکت داده می شوند.
مهم ترین مزیت کارت های CRC امکان بررسی سریع گزینه های مختلف است، در حالی که این کار به وسیله نمودارهای UML بسیار زمان بر و ناکاراست. دیگر اینکه فکر کردن در مورد responsibilityهای یک کلاس ذهن طراح را از طرح یک کلاس به عنوان نگهدارنده دیتا دور و فهم رفتار سطح بالاتر یک کلاس را ممکن می سازد.

منبع / مطالعه بیشتر: The Original Paper On CRC By Beck
Object Design: Roles, Responsibilities, and Collaborations

ارسال گزارش برای DShield

آمار و اطلاعات حمله ها و تهدیدات امنیتی در فضای مجازی ایران، تقریبا به دو علت وجود ندارد و یا بسیار ناقص است. اولین و مهمترین مورد، عدم وجود مرکزی برای رسیدگی و سازماندهی به این اطلاعات است. آرزوی مرکزی به اسم CERT ایران که هیچ وقت واقعا وجود نداشته است و علت دوم تحریم بر علیه ایران. در مورد مشکل اول، فعلا فقط می توان امیدوار بود و در مورد دوم می بایست سعی کنیم تا منابع جمع آوری اطلاعات را در قدم اول تغذیه کنیم. یکی از این روش ها، غنی کردن DShield از لاگ فایل های فایروال های نصب شده در ایران است. پیش نهاد می کنم، اگر مسئول یک فایروال (ویا هم خانواده هایش مثل IDS/IPS) هستید و محل کار شما دارای حساسیت و دستورالعمل ویژه ای در این مورد نیست، از روش های موجود برای ارسال لاگ فایل ها به DShield استفاده کنید. شاید این کار مقدمه ای باشد که در گزارش های حمله، بتوانیم از آمار ایران هم استفاده کنیم. در صفحه زیر روش ارسال لاگ فایل در مورد نرم افزارها/سخت افزارهای موجود و متنوعی توضیح داده شده است.

How to submit your firewall logs to DShield

DShield provides a platform for users of firewalls to share intrusion information. DShield is a free and open service.
If you use a firewall, please submit your logs to the DShield database. You may either download one of our ready to go client programs, or use our Web Interface to manually submit your firewall logs. Registration is encouraged, but is not required.
Everybody is welcome to use the information in the DShield reports and database summaries to protect their network from intrusion attempts.

پروفسور تننبام و سیستم های قابل اطمینان

تصویر اصلی از http://www.cse.unsw.edu.au/~sruoccoکنفرانس لینوکس استرالیا امسال یک اتفاق جالب به همراه داشت. پروفسور تننبام و لینوس تروالدز که ترکیب نام آن ها بیشتر خاطرات بحث های اولیه این دو نفر در مورد ساختار سازنده هسته اصلی(مونولتیک کرنل یا میکروکرنل) لینوکس را زنده می کند (می‌توانید در نوشته پیدایش لینوکس بیشتر بخوانید.)، این بار برخورد دوستانه تری داشتند.

پروفسور Andrew Tanenbaum در صحبتی برای این کنفرانس نکاتی درباره ساخت سیستم های قابل اطمینان داشتند. مقاله اصلی و مانند رسم همیشگی LWN توضیجات مفصل کاربران درباره آن را در نوشته ویژه LWN می توانید بخوانید : LCA: Andrew Tanenbaum on creating reliable systems

آقای تننبام، مدل طراحی تلویزیون (TV Model) را برای سیستم ها، قابل قبول می دانند. در این مدل، مانند خرید تلوزیون شما تنها کافی است که به مرکز خرید مراجعه کنید، تلوزیون خود را انتخاب کنید، آن را بخرید، در خانه نصب کنید و برای ۱۰ سال آینده از آن استفاده کنید. پخش کننده های DVD، تلویزیون، سیستم های استریو و شاید تلفن های همراه از دسته این مدل هستند. در نقطه مقابل، مدل کامپیوتری وجود دارد. در این مدل شما کامپیوتر را می خرید، آن را نصب می کنید، سرویس پک ها را نصب می کنید، وصله های امنیتی را نصب می کنید، درایور ها را نصب می کنید، آنتی ویروس و برنامه ها را نصب می کنید، برنامه های جانبی را نصب می کنید، کامپیوتر را ریبوت می کنید و دیگر کامپیوتر کار نمی کند! گزارشی از New York Times نشان می دهد، در این مرحله ۲۵درصد از کاربران از سیستم خود نامید شده اند!؟

برای حداقل رساندن این موارد، یک طراحی هوشمند از دید پروفسور تننبام باید این ویژگی ها را داشته باشد:

– اجزا را تا حد امکان از یکدیگر منفک کنید، به گونه ای که امکان برقراری تماس با یکدیگر را تا زمانی که دلیلی وجود ندارد، نداشته باشند.

– به قوانین کف اختیار (principle of least authority) توجه کنید. هیچ قسمتی و جزیی، اختیار بیشتری از حداقل نیاز خود، برای انجام وظیفه خود نباید داشته باشد.

– نقص و مشکل در یک قسمت/جز نمی بایست باعث بروز مشکل در قسمت های دیگر شود.

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

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

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