بررسی اجمالی ساختار امنیتی در سیستم عامل فدورا

سیستم عامل فدورا که بعد از ردهت گسترش یافت تاکنون توجه بسیاری ار کاربران ٬ چه کاربران فعلی لینوکس و چه کاربران سیستم عامل ویندوز را به خود جلب نمود . در این مقاله سعی خواهم کرد که ویژگی ها مهم و جدید امنیتی این سیستم عامل را مورد بررسی قرار دهم .

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

 

:: Exec-Shield

 

Exec-Shield بر این اساس فعالیت می کند که حافظه اطلاعات را با حالت non-executable یا غیر قابل اجرا  و حافظه برنامه ها را با حالت non-writeable یا غیر قابل نوشتن ٬ بر این نحو برچسب گذاری می نماید . هم چنین Exec-Shield آدرس هایی که قسمت های مختلف برنامه ها در آن جا قرار گرفته اند را به صورت تصادفی قرار می دهد . این ویژگی بسیاری از مشکلات امنیتی Buffer OverFlow را از بین می برد ٬ به این دلیل که بسیاری از کراکر ها نمی توانند حدس بزنند قسمت هایی که حالت اجرایی دارند در کدام قسمت حافظه قرار می گیرند . قابل ذکر است که Exec-Shield جهت سیستم های x86 است .

 

:: (PIE) Position Independent Executables

 

مانند Exec-Shield به حافظه اطلاعات اجازه می دهد که بطور تصادفی به محل های متفاوت جابجا گردند ٬ PIE به برنامه نویس ها اجازه می دهد که قسمت های اجرایی کد هایشان ٬ هر زمان که اجرا می گردند در قسمت های مختلف حافظه قرار بگیرند . با این حالت فرد نفوذگر نمی تواند حدس بزند که در کدام قسمت حافظه برنامه اجرا شده و امکان ایجاد اکسپلویت را خیلی دشوار و یا تقریبا غیر ممکن می سازد .

 

:: ELF ( Executable and Linkable Format )

 

یکسری تغییرات در کامپوننت فایل که ساختار آن را محافظت می نماید .

 

:: SELinux

 

SELinux در مشارکت با NSA و دیگر توسعه دهندگان نظیر Gentoo و Debian ایجاد شد . SELinux یا

Security Enhaced Linux ٬ کاربران و پروسه ها را با مشاهده همه اتفاقات سیستم محافظت می نماید ٬ از باز نمودن فایل گرفته تا استفاده از سوکت . کاربران می توانند SELinux مدنظر خود را با سیاست های دلخواه تعریف نمایند .  به طور پیش فرض ٬ فدورا خود دارای سیاست امنیت ست که Daemon های شبکه را که  دارای ضریب خطر بالا تری جهت نفوذ می باشند را محافظت می نماید .

به طور مثال ٬ وب سرور آپاچی در چهار حالت محافظت گردیده است : قسمت های اجرایی آپاچی ٬ httpd

هنگام کامپایل شدن توسط PIE و Exec-Shield محافظت گردیده است . فایل باینری اجرایی نیز توسط ELF محافظت شده است .

 

اما توضیحات تخصصی در مورد هر یک را در مقالات بعدی ارائه خواهم داد .

 

Resource :

RedHat Offical WebSite

 

Copyright (c)  2006  Ehsan Omidvar

بررسی ساختار امنیتی Postfix

مسلما کاربران حرفه ای لینوکس ٬ با نرم افزار Postfix آشنا بوده و در مورد عملکرد و ویژگی های آن اطلاعاتی دارند . اما جهت آشنایی کاربران دیگر٬ توضیحاتی مختصر در مورد آن خواهم داد .

Postfix نرم افزاری « اپن سورس » با عنوان mail transfer agent ( MTA ) و یا نماینده انتقال ایمیل است٬ همان طور که از نام آن به نظر می رسد جهت حمل و مسیر یابی ایمیل استفاده می شود و همواره از آن به عنوان نرم افزاری سریع با مدیریت آسان و امنیت بالا یاد می گردد که با نام های VMailer و IBM Secure Mailer نیز شناخته شده است .

 

سیستم Postfix

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

بیشتر پروسه های Postfix می توانند در یک محیط chroot ( محیط chroot در واقع یک محیط محدوده شده است ٬ نظیر یک زندان که زندانی نمی تواند به محیط خارج دسترسی داشته باشد ٬ برنامه ای که در یک فولدر با حالت chroot قرار گرفته باشد ٬ نمی تواند دسترسی به محیط بیرون داشته باشد ) اجرا گردند . این حالت بویژه جهت برنامه هایی نظیر SMTP سرور و SMTP کلاینت که اکثرا در مقابل تهدیدات شبکه بی دفاع هستند صدق می کند .

 

پروسه های مستقل

اما مکانیزم دیگری که در Postfix پیاده شده است ٬ استفاده از پروسه های مستقل جهت جداسازی فعالیت پروسه ها از یگدیگر است ٬ بخصوص اینکه مسیر مستقیمی از شبکه به برنامه های داخلی که ساختار امنیتی حساسی دارند وجود ندارد . چنانچه شخصی بخواهد که به Postfix نفوذ کند ابتدا بایستی به پروسه های مختلف وارد شود ٬ بعضی از قسمت های Postfix حالت Multi-Threat را دارند و از طرفی تمام برنامه هایی که با دنیای بیرون در ارتباط هستند با حالت Single-Threat پیش می روند .

 

کنترل برنامه ها

هیچ کدام از برنامه های delivery در Postfix تحت کنترل یک « user process » اجرا نمی گردند . بیشتر برنامه های Postfix  تحت یک Daemon ( Daemon به زبان ساده پروسه ایست که در Background سیستم عامل اجرا شده و غالبا تحت کنترل کاربر نیستند ) مقیم در سیستم ٬ در یک محیط کنترل شده اجرا می گردند .

 

مستقل از set-uid

نکته جالب دیگر این است که هیچ کدام از برنامه های Postfix ٬ set-uid ( setuid و هم خانواده آن setgid ٬ اکثرا به این دلیل به کار می رود که کاربر بتواند فایل های باینری را با حالتی موقت اجرا کند )  نیستند ٬ در واقع setuid موجب پیدایش اشکالات بیشتری می شود تا اینکه بخواهد سودمند باشد ! هر زمانی که یک ویژگی جدید به سیستم عامل یونیکس اضافه می شد ٬ set-uid باعث مشکل امنیتی می گردید : shared libraries ٬  

پشتیبانی چند زبانه ٬  فایل سیستم /proc و ... که همه این موارد نمونه ای از آن ها بود .

 

چندی دیگر از ویژگی ها

 

:: حافظه جهت رشته ها و بافرها به طور دینامیک سازماندهی می شود ٬ به این دلیل که از مشکلات امنیتی buffer overrun جلوگیری گردد .

:: خط های طولانی در پیغام ها ٬ به قسمت هایی با سایز منطقی تقسیم بندی شده است.

 

و دیگر ویژگی های امنیتی که Postfix را در مقابل حملاتی نظیر buffer overrun مقاوم نموده است .

 

 

Resources :

http://www.postfix.org/

http://www.wikipedia.org/

 

Copyright (c)  2006  Ehsan Omidvar

ادامه . . .

 

 

---------------------------------4.4.3

:polimorphism

 

 این مفهوم ویا ویژگی روش شئ گرا امکان پیاده سازی چند تابع با یک نام و ساختارهای متفاوت را برای برنامه نویس فراهم میکند.

بعد از عنوان شدن مفهوم وراثت یکسری مشکلات پیش روی برنامه نویسان قرار گرفت که منجر به پیدایش مفهوم" چند ریختی" گردید.

برای درک مشکلات ذکر شده توجه شما را همان مثال ماشین ها جلب مینماییم.

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

در این حالت سیستم و فرآیند حرکت کردن و ایستادن در دو ماشین  بنز و بی ام و یکسان خواهد بود در حالی که در عمل اینطور نیست.

برای رفع این مشکل بحث چند ریختی مطرح شده است  یعنی برنامه نویس میتواند تابعی هم نام با تابع حرکت کردن یا ایستادن ولی با ساختای متفاوت ایجاد کند.

برای پیاده سازی این مفهوم ا دو عبارت زیر استفاده میکنیم:

--------------------------------------

Over load  نام یکسان  (پارامتر ها متفاوت)

 

 

 

 

              پیاده سازی یکسان

 

 

 

 

-------------------------------------------------

 

Over write نام یکسان   (پارامترها یکسان)

            

 

 

 

              پیاده سازی متفاوت

 

 

 

----------------------------------------5.3

 

 

روش برنامه نویسی شئ گرا:

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

برای اینکه بتوانیم بهترین انتخاب را داشته باشیم روش های متعددی مطرح شده است که در این قسمت به بررسی روش آقای کد میپردازیم:

  codd

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

PERSON(1

 place(2

things event(3

 

یعنی بهتر است ابتدا برای هر یک از اشخاص یا انسان های برنامه یک کلاس طراحی کنیم

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

 

نويسنده: سيدمحمود شجاعي كياسري