Academy and Foundation unixmens | Your skills, Your future
آشنایی با پروتکل های مسیر یابی #routing #route @unixmens
این روتر تعیینشده و روترهای دیگر، مجاورت را با تمام روترهای همسایه از طریق خبررسانی چندرسانهای multicasting در شبکه ایجاد میکنند. IS-IS از ناحیهی سلسلهمراتبی با روترهای سطح ۱ و ۲ استفاده میکند. روترهای سطح ۱ مانند روترهای OSPF هستند که هیچ ارتباط مستقیمی با خارج از ناحیهی خود ندارند. روترهای سطح ۲ شامل نواحی اصلی میشوند که با نواحی دیگر اتصال برقرار میکنند.
هر روتر IS-IS باید یک آدرس خاص برای مسیریابی دامنه داشته باشد. توجه داشته باشید که IS-IS فرایند مسیریابی را بهجای یک شبکه، به یک رابط اختصاص میدهد.
ویژگی های پروتکل IS-IS
یک پروتکل Link State است.
ا IP و CLNS را مسیریابی میکند.
اطلاعرسانی مسیریابی: فقط زمانی که تغییر مسیر اتفاق بیفتد.
متریک: هزینه متغیر
تعداد هاپ: هیچ (محدود شده توسط شبکه)
Variable Length Subnet Mask
ا خلاصهسازی در Network Class Address یا Subnet Boundary
ا Load Balancing از طریق ۶ مسیر برابر
تایمرها: Hello Interval, Hello Multiplier
نوع نواحی: مانند OSPF سلسله مراتبی است.
نوع روترها: سطح ۱ و سطح ۲
LSP نوع: Internal L1 and L2, External L2
انتخاب روتر تعیینشده، بدون BDR
پروتکل BGP
پروتکل BGP مخفف عبارت Border Gateway Protocol است. BGP یک پروتکل Exterior gateway بوده که با پروتکلهای interior gateway کاملاً متفاوت است. این تمایز بسیار مهم است چون سیستمهای مستقل باید از پروتکلهای دیگری مانند EIGRP استفاده کنند. پروتکلهای Exterior gateway مانند BGP سیستمهای مستقلی را مسیریابی میکنند که یک AS ویژه به آنها اختصاص دادهشده است.
شمارههای AS میتوانند به یک موقعیت با یک یا چند روتر BGP اختصاص یابند. جدول مسیریابی BGP از IP آدرسهای مقصد، مسیر AS برای رسیدن به مقصد و آدرس هاپ روتر بعدی تشکیل شده است. مسیر AS مجموعهای از شمارههای AS است که بستههای مسیریابی هر موقعیت را نشان میدهد ( برخلاف EIGRP که از سیستمهای مستقل هم استفاده میکند).
یک شبکه EIGRP میتواند چندین سیستم مستقل را پیکربندی کند. تمام سیستمها توسط شرکت مدیریت میشوند تا مواردی مانند خلاصهسازی مسیر، توزیع مجدد و فیلتر کردن اعمال شوند. از پروتکلهای BGP در سازمانهای بسیار بزرگ و ارائهدهندگان خدمات اینترنتی (ISP) که دارای ارتباطات اینترنتی دوگانه هستند، استفاده میشود. این شرکتها دارای یک یا دو روتر هستند که به ارائهدهندهی خدمات اینترنتی متصل میشوند. BGP بستهها را از طریق یک شبکه ISP مسیریابی میکند.
ا ISP دارای شماره AS مخصوصی است که توسط InterNIC به آن اختصاص داده شده است. مشتریان جدید میتوانند برای دفتر خود یک AS اختصاصی از ISP یا InterNIC سفارش دهند. هر روتر BGP میتواند با استفاده از نقشههای مسیر بهجای ارسال / دریافت کل جدول مسیریابی اینترنت پیکربندی شود.
مؤلفههای جدول مسیریابی BGP
IP آدرس مقصد / Subnet Mask
مسیر AS
IP آدرس هاپ بعدی
هر روتر IS-IS باید یک آدرس خاص برای مسیریابی دامنه داشته باشد. توجه داشته باشید که IS-IS فرایند مسیریابی را بهجای یک شبکه، به یک رابط اختصاص میدهد.
ویژگی های پروتکل IS-IS
یک پروتکل Link State است.
ا IP و CLNS را مسیریابی میکند.
اطلاعرسانی مسیریابی: فقط زمانی که تغییر مسیر اتفاق بیفتد.
متریک: هزینه متغیر
تعداد هاپ: هیچ (محدود شده توسط شبکه)
Variable Length Subnet Mask
ا خلاصهسازی در Network Class Address یا Subnet Boundary
ا Load Balancing از طریق ۶ مسیر برابر
تایمرها: Hello Interval, Hello Multiplier
نوع نواحی: مانند OSPF سلسله مراتبی است.
نوع روترها: سطح ۱ و سطح ۲
LSP نوع: Internal L1 and L2, External L2
انتخاب روتر تعیینشده، بدون BDR
پروتکل BGP
پروتکل BGP مخفف عبارت Border Gateway Protocol است. BGP یک پروتکل Exterior gateway بوده که با پروتکلهای interior gateway کاملاً متفاوت است. این تمایز بسیار مهم است چون سیستمهای مستقل باید از پروتکلهای دیگری مانند EIGRP استفاده کنند. پروتکلهای Exterior gateway مانند BGP سیستمهای مستقلی را مسیریابی میکنند که یک AS ویژه به آنها اختصاص دادهشده است.
شمارههای AS میتوانند به یک موقعیت با یک یا چند روتر BGP اختصاص یابند. جدول مسیریابی BGP از IP آدرسهای مقصد، مسیر AS برای رسیدن به مقصد و آدرس هاپ روتر بعدی تشکیل شده است. مسیر AS مجموعهای از شمارههای AS است که بستههای مسیریابی هر موقعیت را نشان میدهد ( برخلاف EIGRP که از سیستمهای مستقل هم استفاده میکند).
یک شبکه EIGRP میتواند چندین سیستم مستقل را پیکربندی کند. تمام سیستمها توسط شرکت مدیریت میشوند تا مواردی مانند خلاصهسازی مسیر، توزیع مجدد و فیلتر کردن اعمال شوند. از پروتکلهای BGP در سازمانهای بسیار بزرگ و ارائهدهندگان خدمات اینترنتی (ISP) که دارای ارتباطات اینترنتی دوگانه هستند، استفاده میشود. این شرکتها دارای یک یا دو روتر هستند که به ارائهدهندهی خدمات اینترنتی متصل میشوند. BGP بستهها را از طریق یک شبکه ISP مسیریابی میکند.
ا ISP دارای شماره AS مخصوصی است که توسط InterNIC به آن اختصاص داده شده است. مشتریان جدید میتوانند برای دفتر خود یک AS اختصاصی از ISP یا InterNIC سفارش دهند. هر روتر BGP میتواند با استفاده از نقشههای مسیر بهجای ارسال / دریافت کل جدول مسیریابی اینترنت پیکربندی شود.
مؤلفههای جدول مسیریابی BGP
IP آدرس مقصد / Subnet Mask
مسیر AS
IP آدرس هاپ بعدی
Implementing Mandatory Access Control with SELinux or AppArmor in Linux
https://www.tecmint.com/mandatory-access-control-with-selinux-or-apparmor-linux/
https://www.tecmint.com/mandatory-access-control-with-selinux-or-apparmor-linux/
Implementing Mandatory Access Control with SELinux or AppArmor in Linux
In this article we will explain the essentials of SELinux and AppArmor and how to use one of these tools for your benefit depending on your Linux distribution.
جایگزین Icinga، یک fork از Nagios
به موجب اختلاف نظر در مدل توسعه انتخابی برای Nagios (که توسط یک شرکت کنترل میشود)، تعدادی از توسعهدهندگان آن را fork و از نام جدید Icinga استفاده کردند. Icinga کماکان ـ تا جای ممکن - با پیکربندیها و پلاگینهای Nagios سازگار، اما ویژگیهای اضافی را به آن افزوده است.
→ https://www.icinga.org/
به موجب اختلاف نظر در مدل توسعه انتخابی برای Nagios (که توسط یک شرکت کنترل میشود)، تعدادی از توسعهدهندگان آن را fork و از نام جدید Icinga استفاده کردند. Icinga کماکان ـ تا جای ممکن - با پیکربندیها و پلاگینهای Nagios سازگار، اما ویژگیهای اضافی را به آن افزوده است.
→ https://www.icinga.org/
Icinga
Icinga » Monitor your entire Infrastructure with Icinga
Tackle the monitoring challenge » Get a complete overview of all your systems and applications. Flexible, scalable and automated monitoring.
راهاندازی Munin
هدف Munin مانیتور کردن ماشینهای متعدد است؛ بنابراین، طبیعی است که از معماری کلاینت/سرور استفاده کند. میزبان مرکزی - یا grapher - داده را از تمام میزبانهای قابل مانیتور کردن دریافت کرده و نمودارهای گرافیکی تولید میکند.
پیکربندی میزبانها برای مانیتور شدن
اولین گام نصب بسته munin-node است. فرآیند پسزمینهای که توسط این بسته نصب میشود به درگاه ۴۹۴۹ گوش کرده و دادههای دریافتی از پلاگینهای فعال را ارسال میکند. هر پلاگین یک برنامه ساده است که توضیح مرتبط با داده دریافتی همراه با آخرین مقدار بدست آمده را باز میگرداند. پلاگینها در مسیر /usr/share/munin/plugins/ ذخیره شدهاند اما تنها آنهایی که به صورت پیوند نمادین در /etc/munin/plugins/ قرار داشته باشند، استفاده میگردند.
زمانی که بسته نصب شود، مجموعهای از پلاگینهای فعال بر اساس نرمافزار موجود و پیکربندی فعلی میزبان تشخیص داده میشوند. اگرچه، این پیکربندی خودکار وابسته به قابلیتی است که هر پلاگین باید فراهم کرده باشد و بهتر است که نتایج را به صورت دستی مرور و ویرایش کنیم. مرور گالری پلاگین میتواند جالب باشد با این وجود که همه پلاگینها ممکن است شامل مستندات جامع نباشند. با این حال، تمام پلاگینها اسکریپت هستند که اکثر آنها ساده بوده و دارای توضیحات خوبی میباشند. مرور /etc/munin/plugins/ شیوه خوبی برای اطلاع از کارکرد هر پلاگین و تشخیص اینکه کدام یک باید حذف شود میباشد. به طور مشابه، فعالسازی یک پلاگین جالب در /usr/share/munin/plugins/ به سادگی ایجاد پیوند نمادین با استفاده از ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/ میباشد. به یاد داشته باشید اگر نام پلاگین به زیرخط یا “_” تمام شود، پلاگین نیازمند یک پارامتر است. این پارامتر باید در نام مرتبط با پیوند نمادین ذخیرهسازی شود؛ برای نمونه، پلاگین “if_” باید همراه با پیوند نمادین if_eth0 فعالسازی شود، تا بتواند ترافیک شبکه رابط eth0 را مانیتور کند.
زمانی که تمام پلاگینها راهاندازی شوند، پیکربندی فرآیند پسزمینه به منظور تعریف کنترل دسترسی به دادههای گردآوری شده باید بروزرسانی گردد. اینکار شامل عبارتهای allow در فایل /etc/munin/munin-node.conf میشود. پیکربندی پیشفرض به صورت allow ^127\.0\.0\.1$ است که تنها اجازه دسترسی به میزبان محلی را میدهد. یک مدیرسیستم معمولا خطی مشابه را همراه با نشانی IP میزبان grapher میافزاید، سپس اقدام به راهاندازی مجدد فرآیند پسزمینه با استفاده از service munin-node restart میکند.
هدف Munin مانیتور کردن ماشینهای متعدد است؛ بنابراین، طبیعی است که از معماری کلاینت/سرور استفاده کند. میزبان مرکزی - یا grapher - داده را از تمام میزبانهای قابل مانیتور کردن دریافت کرده و نمودارهای گرافیکی تولید میکند.
پیکربندی میزبانها برای مانیتور شدن
اولین گام نصب بسته munin-node است. فرآیند پسزمینهای که توسط این بسته نصب میشود به درگاه ۴۹۴۹ گوش کرده و دادههای دریافتی از پلاگینهای فعال را ارسال میکند. هر پلاگین یک برنامه ساده است که توضیح مرتبط با داده دریافتی همراه با آخرین مقدار بدست آمده را باز میگرداند. پلاگینها در مسیر /usr/share/munin/plugins/ ذخیره شدهاند اما تنها آنهایی که به صورت پیوند نمادین در /etc/munin/plugins/ قرار داشته باشند، استفاده میگردند.
زمانی که بسته نصب شود، مجموعهای از پلاگینهای فعال بر اساس نرمافزار موجود و پیکربندی فعلی میزبان تشخیص داده میشوند. اگرچه، این پیکربندی خودکار وابسته به قابلیتی است که هر پلاگین باید فراهم کرده باشد و بهتر است که نتایج را به صورت دستی مرور و ویرایش کنیم. مرور گالری پلاگین میتواند جالب باشد با این وجود که همه پلاگینها ممکن است شامل مستندات جامع نباشند. با این حال، تمام پلاگینها اسکریپت هستند که اکثر آنها ساده بوده و دارای توضیحات خوبی میباشند. مرور /etc/munin/plugins/ شیوه خوبی برای اطلاع از کارکرد هر پلاگین و تشخیص اینکه کدام یک باید حذف شود میباشد. به طور مشابه، فعالسازی یک پلاگین جالب در /usr/share/munin/plugins/ به سادگی ایجاد پیوند نمادین با استفاده از ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/ میباشد. به یاد داشته باشید اگر نام پلاگین به زیرخط یا “_” تمام شود، پلاگین نیازمند یک پارامتر است. این پارامتر باید در نام مرتبط با پیوند نمادین ذخیرهسازی شود؛ برای نمونه، پلاگین “if_” باید همراه با پیوند نمادین if_eth0 فعالسازی شود، تا بتواند ترافیک شبکه رابط eth0 را مانیتور کند.
زمانی که تمام پلاگینها راهاندازی شوند، پیکربندی فرآیند پسزمینه به منظور تعریف کنترل دسترسی به دادههای گردآوری شده باید بروزرسانی گردد. اینکار شامل عبارتهای allow در فایل /etc/munin/munin-node.conf میشود. پیکربندی پیشفرض به صورت allow ^127\.0\.0\.1$ است که تنها اجازه دسترسی به میزبان محلی را میدهد. یک مدیرسیستم معمولا خطی مشابه را همراه با نشانی IP میزبان grapher میافزاید، سپس اقدام به راهاندازی مجدد فرآیند پسزمینه با استفاده از service munin-node restart میکند.
در واقع muninشامل مستندات کاملی درباره چگونگی عملکرد و توسعه پلاگینها است.
→ https://munin-monitoring.org/wiki/plugins
یک پلاگین بهتر است در شرایط مشابه با فراخوانی توسط munin-node مورد آزمون قرار گیرد؛ این عمل با اجرای munin-run plugin به عنوان root شبیهسازی میشود. یک پارامتر دوم احتمالی که به این دستور داده میشود (از جمله config) به عنوان یک پارامتر به پلاگین فرستاده میشود.
زمانی که یک پلاگین توسط پارامتر config فراخوانی میشود، باید خود را با بازگرداندن مجموعهای از فیلدها تعریف کند:
$ sudo munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average
فیلدهای موجود مختلف توسط “مرجع پلاگین” موجود در قسمت “راهنمای Munin” توضیح داده شدهاند.
→ https://munin.readthedocs.org/en/latest/reference/plugin.html
زمانی که بدون پارامتر فراخوانی میشود، پلاگین به سادگی آخرین مقدار محاسبه شده را باز میگرداند؛ برای نمونه، اجرای sudo munin-run load میتواند مقدار load.value 0.12 را باز گرداند.
در نهایت، زمانی که یک پلاگین توسط پارامتر autoconf فراخوانی میشود، باید مقدار “yes” (گزارش خروج ۰) یا “no” (گزارش خروج ۱) با توجه به اینکه آیا پلاگین باید در این میزبان فعال شود یا خیر را باز گرداند.
→ https://munin-monitoring.org/wiki/plugins
یک پلاگین بهتر است در شرایط مشابه با فراخوانی توسط munin-node مورد آزمون قرار گیرد؛ این عمل با اجرای munin-run plugin به عنوان root شبیهسازی میشود. یک پارامتر دوم احتمالی که به این دستور داده میشود (از جمله config) به عنوان یک پارامتر به پلاگین فرستاده میشود.
زمانی که یک پلاگین توسط پارامتر config فراخوانی میشود، باید خود را با بازگرداندن مجموعهای از فیلدها تعریف کند:
$ sudo munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average
فیلدهای موجود مختلف توسط “مرجع پلاگین” موجود در قسمت “راهنمای Munin” توضیح داده شدهاند.
→ https://munin.readthedocs.org/en/latest/reference/plugin.html
زمانی که بدون پارامتر فراخوانی میشود، پلاگین به سادگی آخرین مقدار محاسبه شده را باز میگرداند؛ برای نمونه، اجرای sudo munin-run load میتواند مقدار load.value 0.12 را باز گرداند.
در نهایت، زمانی که یک پلاگین توسط پارامتر autoconf فراخوانی میشود، باید مقدار “yes” (گزارش خروج ۰) یا “no” (گزارش خروج ۱) با توجه به اینکه آیا پلاگین باید در این میزبان فعال شود یا خیر را باز گرداند.
پیکربندی Grapher
ا “grapher” در واقع رایانهای است که دادهها را گردآوری کرده و نمودارهای مرتبط با آن را رسم میکند. نرمافزار مورد نیاز در بسته munin قرار دارد. پیکربندی استاندارد munin-cron را هر ۵ دقیقه یکبار اجرا کرده، تا اطلاعات از تمام میزبانهای موجود در /etc/munin/munin.conf گردآوری شوند (فقط میزبان محلی به صورت پیشفرض قرار دارد)، دادههای بدست آمده را در فایلهای RRD، که مخفف Round Robin Database و مناسب ذخیرهسازی دادههای متغیر در طول زمان است، ذخیرهسازی میکند که این فایلها در مسیر /var/lib/munin/ قرار دارند و در نهایت یک صفحه HTML همراه با نمودارها در /var/cache/munin/www/ ایجاد میکند.
بنابراین تمام ماشینهای مانیتور شده باید در فایل پیکربندی /etc/munin/munin.conf قرار داشته باشند. هر ماشین به عنوان یک قسمت کامل همراه با نام آن و حداقل یک مدخل address که شامل نشانی IP ماشین است، قرار میگیرد.
[ftp.falcot.com]
address 192.168.0.12
use_node_name yes
قسمتها میتوانند پیچیدهتر باشند، تا با ترکیب دادههای بدست آمده از چند ماشین نمودارهای اضافی رسم گردد. مثالهای موجود در فایل پیکربندی نقطه آغاز مناسبی برای سفارشیکردن این فرآیند هستند.
آخرین گام انتشار صفحات تولید شده است؛ اینکار نیازمند پیکربندی سرور وب به گونهای است که محتوای /var/cache/munin/www/ از طریق یک وبسایت قابل دسترس باشد. دسترسی به این وبسایت میتواند با استفاده از مکانیزم احرازهویت یا کنترل دسترسی مبتنی بر IP مدیریت شود.
ا “grapher” در واقع رایانهای است که دادهها را گردآوری کرده و نمودارهای مرتبط با آن را رسم میکند. نرمافزار مورد نیاز در بسته munin قرار دارد. پیکربندی استاندارد munin-cron را هر ۵ دقیقه یکبار اجرا کرده، تا اطلاعات از تمام میزبانهای موجود در /etc/munin/munin.conf گردآوری شوند (فقط میزبان محلی به صورت پیشفرض قرار دارد)، دادههای بدست آمده را در فایلهای RRD، که مخفف Round Robin Database و مناسب ذخیرهسازی دادههای متغیر در طول زمان است، ذخیرهسازی میکند که این فایلها در مسیر /var/lib/munin/ قرار دارند و در نهایت یک صفحه HTML همراه با نمودارها در /var/cache/munin/www/ ایجاد میکند.
بنابراین تمام ماشینهای مانیتور شده باید در فایل پیکربندی /etc/munin/munin.conf قرار داشته باشند. هر ماشین به عنوان یک قسمت کامل همراه با نام آن و حداقل یک مدخل address که شامل نشانی IP ماشین است، قرار میگیرد.
[ftp.falcot.com]
address 192.168.0.12
use_node_name yes
قسمتها میتوانند پیچیدهتر باشند، تا با ترکیب دادههای بدست آمده از چند ماشین نمودارهای اضافی رسم گردد. مثالهای موجود در فایل پیکربندی نقطه آغاز مناسبی برای سفارشیکردن این فرآیند هستند.
آخرین گام انتشار صفحات تولید شده است؛ اینکار نیازمند پیکربندی سرور وب به گونهای است که محتوای /var/cache/munin/www/ از طریق یک وبسایت قابل دسترس باشد. دسترسی به این وبسایت میتواند با استفاده از مکانیزم احرازهویت یا کنترل دسترسی مبتنی بر IP مدیریت شود.
ا AppArmor یک سیستم کنترل دسترسی ضروری یا Mandatory Access Control (MAC) است که درون رابط ماژولهای امنیتی لینوکس یا Linux Security Modules (LSM) پیادهسازی شده است. در عمل، کرنل قبل از هر فراخوانی سیستمی از AppArmor پرس و جو میکند تا بداند آیا فرآیند مجاز به انجام عملیات مذکور است یا خیر. از طریق این مکانیزم، AppArmor برنامهها را محدود به مجموعه کوچکی از منابع میکند.
ا AppArmor مجموعهای از قوانین (که بنام “پروفایل” شناخته میشوند) را روی هر برنامه اعمال میکند. پروفایل اعمال شده توسط کرنل وابسته با مکان نصب اولیه برنامه اجرایی است. بر خلاف SELinux قوانین اعمال شده مبتنی بر کاربر نیستند. تمام کاربران هنگام اجرای برنامه مشابه از یک مجموعه قوانین پیروی میکنند (اما مجوزهای سنتی کاربری هنوز برقرار بوده و ممکن است عملکرد متفاوتی داشته باشند!).
پروفایلهای AppArmor در /etc/apparmor.d/ ذخیرهسازی شده و شامل فهرستی از قوانین کنترل دسترسی هستند که منابع مختلف را برای هر برنامه مشخص میکنند. پروفایلها با استفاده از دستور apparmor_parser کامپایل شده و درون کرنل قرار میگیرند. هر پروفایل تنها میتواند در یکی از حالتهای enforcing یا complaining بارگیری شود. اولی با توجه به خط مشی امنیتی، تلاشهای خرابکارانه را گزارش میدهد در صورتی که دومی اجباری در پیروی از خط مشی نداشته ولی فراخوانیهای سیستمی غیرمجاز را ذخیرهسازی میکند.
#security @unixmens
ا AppArmor مجموعهای از قوانین (که بنام “پروفایل” شناخته میشوند) را روی هر برنامه اعمال میکند. پروفایل اعمال شده توسط کرنل وابسته با مکان نصب اولیه برنامه اجرایی است. بر خلاف SELinux قوانین اعمال شده مبتنی بر کاربر نیستند. تمام کاربران هنگام اجرای برنامه مشابه از یک مجموعه قوانین پیروی میکنند (اما مجوزهای سنتی کاربری هنوز برقرار بوده و ممکن است عملکرد متفاوتی داشته باشند!).
پروفایلهای AppArmor در /etc/apparmor.d/ ذخیرهسازی شده و شامل فهرستی از قوانین کنترل دسترسی هستند که منابع مختلف را برای هر برنامه مشخص میکنند. پروفایلها با استفاده از دستور apparmor_parser کامپایل شده و درون کرنل قرار میگیرند. هر پروفایل تنها میتواند در یکی از حالتهای enforcing یا complaining بارگیری شود. اولی با توجه به خط مشی امنیتی، تلاشهای خرابکارانه را گزارش میدهد در صورتی که دومی اجباری در پیروی از خط مشی نداشته ولی فراخوانیهای سیستمی غیرمجاز را ذخیرهسازی میکند.
#security @unixmens
فعالسازی و مدیریت پروفایلهای AppArmor:
پشتیبانی از AppArmor در کرنلهای استاندارد دبیان وجود دارد. از این رو، فعالسازی AppArmor به سادگی نصب چند بسته و افزودن برخی پارامترها به خط فرمان کرنل است:
# apt install apparmor apparmor-profiles apparmor-utils
[...]
# perl -pi -e 's,GRUB_CMDLINE_LINUX="(.*)"$,GRUB_CMDLINE_LINUX="$1 apparmor=1 security=apparmor",' /etc/default/grub
# update-grub
پس از راهاندازی مجدد سیستم، AppArmor عملیاتی بوده و میتوان وضعیت آن را با استفاده از aa-status بررسی کرد:
# aa-status
apparmor module is loaded.
44 profiles are loaded.
9 profiles are in enforce mode.
/usr/bin/lxc-start
/usr/lib/chromium-browser/chromium-browser//browser_java
[...]
35 profiles are in complain mode.
/sbin/klogd
[...]
3 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/libvirtd (1295)
2 processes are in complain mode.
/usr/sbin/avahi-daemon (941)
/usr/sbin/avahi-daemon (1000)
0 processes are unconfined but have a profile defined.
یادداشت پروفایلهای بیشتر AppArmor
بسته apparmor-profiles شامل پروفایلهایی است که توسط جامعه کاربری AppArmor مدیریت میشوند. برای دریافت پروفایلهای بیشتر میتوانید بسته apparmor-profiles-extra را نصب کرده که شامل پروفایلهای توسعهیافته توسط دبیان و اوبونتو میباشند.
حالت هر پروفایل میتواند با استفاده از فراخوانیهای aa-enforce و aa-complain به وضعیت enforcing و complaining تغییر یابد که اینکار به عنوان پارامتر در مسیر اجرایی برنامه یا مسیر فایل خطی مشی امنیتی صورت میپذیرد. به علاوه، یک پروفایل میتواند با استفاده از aa-disable غیرفعال شده یا در حالت audit (برای ثبت فراخوانیهای سیستمی مجاز) با استفاده از aa-audit قرار گیرد.
# aa-enforce /usr/sbin/avahi-daemon
Setting /usr/sbin/avahi-daemon to enforce mode.
# aa-complain /etc/apparmor.d/usr.bin.lxc-start
Setting /etc/apparmor.d/usr.bin.lxc-start to complain mode.
پشتیبانی از AppArmor در کرنلهای استاندارد دبیان وجود دارد. از این رو، فعالسازی AppArmor به سادگی نصب چند بسته و افزودن برخی پارامترها به خط فرمان کرنل است:
# apt install apparmor apparmor-profiles apparmor-utils
[...]
# perl -pi -e 's,GRUB_CMDLINE_LINUX="(.*)"$,GRUB_CMDLINE_LINUX="$1 apparmor=1 security=apparmor",' /etc/default/grub
# update-grub
پس از راهاندازی مجدد سیستم، AppArmor عملیاتی بوده و میتوان وضعیت آن را با استفاده از aa-status بررسی کرد:
# aa-status
apparmor module is loaded.
44 profiles are loaded.
9 profiles are in enforce mode.
/usr/bin/lxc-start
/usr/lib/chromium-browser/chromium-browser//browser_java
[...]
35 profiles are in complain mode.
/sbin/klogd
[...]
3 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/libvirtd (1295)
2 processes are in complain mode.
/usr/sbin/avahi-daemon (941)
/usr/sbin/avahi-daemon (1000)
0 processes are unconfined but have a profile defined.
یادداشت پروفایلهای بیشتر AppArmor
بسته apparmor-profiles شامل پروفایلهایی است که توسط جامعه کاربری AppArmor مدیریت میشوند. برای دریافت پروفایلهای بیشتر میتوانید بسته apparmor-profiles-extra را نصب کرده که شامل پروفایلهای توسعهیافته توسط دبیان و اوبونتو میباشند.
حالت هر پروفایل میتواند با استفاده از فراخوانیهای aa-enforce و aa-complain به وضعیت enforcing و complaining تغییر یابد که اینکار به عنوان پارامتر در مسیر اجرایی برنامه یا مسیر فایل خطی مشی امنیتی صورت میپذیرد. به علاوه، یک پروفایل میتواند با استفاده از aa-disable غیرفعال شده یا در حالت audit (برای ثبت فراخوانیهای سیستمی مجاز) با استفاده از aa-audit قرار گیرد.
# aa-enforce /usr/sbin/avahi-daemon
Setting /usr/sbin/avahi-daemon to enforce mode.
# aa-complain /etc/apparmor.d/usr.bin.lxc-start
Setting /etc/apparmor.d/usr.bin.lxc-start to complain mode.
ایجاد یک پروفایل جدید
با اینکه ایجاد یک پروفایل AppArmor کار سادهای است، اما اکثر برنامهها چنین پروفایلی ندارند. این قسمت به شما نشان میدهد که چطور میتوان یک پروفایل جدید را از ابتدا و با استفاده از برنامه هدف ایجاد کرد تا AppArmor با مانیتور کردن فراخوانی سیستمی به آن بتواند منابع مصرفیاش را تحت نظر قرار دهد.
مهمترین برنامههایی که باید دسترسی محدود داشته باشند تحت شبکه بوده و آنهایی هستند که بیشتر هدف حملات راهدور قرار میگیرند. به همین دلیل است که AppArmor یک دستور متداول aa-unconfined را فراهم میکند تا فهرستی از برنامههای تحت شبکه با سوکت باز که پروفایل مشخصی ندارند بدست آید. با گزینه --paranoid شما فهرستی از تمام فرآیندهای تعریف نشده که حداقل یک ارتباط فعال شبکه را دارند دریافت میکنید.
# aa-unconfined
801 /sbin/dhclient not confined
890 /sbin/rpcbind not confined
899 /sbin/rpc.statd not confined
929 /usr/sbin/sshd not confined
941 /usr/sbin/avahi-daemon confined by '/usr/sbin/avahi-daemon (complain)'
988 /usr/sbin/minissdpd not confined
1276 /usr/sbin/exim4 not confined
1485 /usr/lib/erlang/erts-6.2/bin/epmd not confined
1751 /usr/lib/erlang/erts-6.2/bin/beam.smp not confined
19592 /usr/lib/dleyna-renderer/dleyna-renderer-service not confined
در مثال پیش رو، تلاش میکنیم که یک پروفایل برای /sbin/dhclient ایجاد کنیم. برای این منظور از aa-genprof dhclient استفاده میکنیم. این دستور از شما دعوت میکند تا از برنامه در پنجره دیگری استفاده کنید و زمانی که به پایان رسید به aa-genprof بازگشته تا رویدادهای سیستمی مورد نظر AppArmor پیمایش شوند و از میان آنها قوانین دسترسی برنامه مشخص گردند. برای هر رویداد ثبت شده، یک یا چند پیشنهاد برای قانون مورد نظر ارائه میدهد که میتوانید تایید یا به روشهای دیگر آنها را ویرایش کنید:
# aa-genprof dhclient
Writing updated profile for /sbin/dhclient.
Setting /sbin/dhclient to complain mode.
Before you begin, you may wish to check if a
profile already exists for the application you
wish to confine. See the following wiki page for
more information:
https://wiki.apparmor.net/index.php/Profiles
Please start the application to be profiled in
another window and exercise its functionality now.
Once completed, select the "Scan" option below in
order to scan the system logs for AppArmor events.
For each AppArmor event, you will be given the
opportunity to choose whether the access should be
allowed or denied.
Profiling: /sbin/dhclient
[(S)can system log for AppArmor events] / (F)inish
Reading log entries from /var/log/audit/audit.log.
Profile: /sbin/dhclient 1
Execute: /usr/lib/NetworkManager/nm-dhcp-helper
Severity: unknown
(I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish
P
Should AppArmor sanitise the environment when
switching profiles?
Sanitising environment is more secure,
but some applications depend on the presence
of LD_PRELOAD or LD_LIBRARY_PATH.
(Y)es / [(N)o]
Y
Writing updated profile for /usr/lib/NetworkManager/nm-dhcp-helper.
Complain-mode changes:
WARN: unknown capability: CAP_net_raw
Profile: /sbin/dhclient 2
Capability: net_raw
Severity: unknown
[(A)llow] / (D)eny / (I)gnore / Audi(t) / Abo(r)t / (F)inish
A
Adding capability net_raw to profile.
Profile: /sbin/dhclient 3
Path: /etc/nsswitch.conf
Mode: r
Severity: unknown
1 - #include <abstractions/apache2-common>
2 - #include <abstractions/libvirt-qemu>
3 - #include <abstractions/nameservice>
4 - #include <abstractions/totem>
[5 - /etc/nsswitch.conf]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
3
Profile: /sbin/dhclient
Path: /etc/nsswitch.conf
Mode: r
Severity: unknown
1 - #include <abstractions/apache2-common>
2 - #include <abstractions/libvirt-qemu>
[3 - #include <abstractions/nameservice>]
4 - #include <abstractions/totem>
5 - /etc/nsswitch.conf
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding #include <abstractions/nameservice> to profile.
Profile: /sbin/dhclient
Path: /proc/7252/net/dev
Mode: r
Severity: 6
با اینکه ایجاد یک پروفایل AppArmor کار سادهای است، اما اکثر برنامهها چنین پروفایلی ندارند. این قسمت به شما نشان میدهد که چطور میتوان یک پروفایل جدید را از ابتدا و با استفاده از برنامه هدف ایجاد کرد تا AppArmor با مانیتور کردن فراخوانی سیستمی به آن بتواند منابع مصرفیاش را تحت نظر قرار دهد.
مهمترین برنامههایی که باید دسترسی محدود داشته باشند تحت شبکه بوده و آنهایی هستند که بیشتر هدف حملات راهدور قرار میگیرند. به همین دلیل است که AppArmor یک دستور متداول aa-unconfined را فراهم میکند تا فهرستی از برنامههای تحت شبکه با سوکت باز که پروفایل مشخصی ندارند بدست آید. با گزینه --paranoid شما فهرستی از تمام فرآیندهای تعریف نشده که حداقل یک ارتباط فعال شبکه را دارند دریافت میکنید.
# aa-unconfined
801 /sbin/dhclient not confined
890 /sbin/rpcbind not confined
899 /sbin/rpc.statd not confined
929 /usr/sbin/sshd not confined
941 /usr/sbin/avahi-daemon confined by '/usr/sbin/avahi-daemon (complain)'
988 /usr/sbin/minissdpd not confined
1276 /usr/sbin/exim4 not confined
1485 /usr/lib/erlang/erts-6.2/bin/epmd not confined
1751 /usr/lib/erlang/erts-6.2/bin/beam.smp not confined
19592 /usr/lib/dleyna-renderer/dleyna-renderer-service not confined
در مثال پیش رو، تلاش میکنیم که یک پروفایل برای /sbin/dhclient ایجاد کنیم. برای این منظور از aa-genprof dhclient استفاده میکنیم. این دستور از شما دعوت میکند تا از برنامه در پنجره دیگری استفاده کنید و زمانی که به پایان رسید به aa-genprof بازگشته تا رویدادهای سیستمی مورد نظر AppArmor پیمایش شوند و از میان آنها قوانین دسترسی برنامه مشخص گردند. برای هر رویداد ثبت شده، یک یا چند پیشنهاد برای قانون مورد نظر ارائه میدهد که میتوانید تایید یا به روشهای دیگر آنها را ویرایش کنید:
# aa-genprof dhclient
Writing updated profile for /sbin/dhclient.
Setting /sbin/dhclient to complain mode.
Before you begin, you may wish to check if a
profile already exists for the application you
wish to confine. See the following wiki page for
more information:
https://wiki.apparmor.net/index.php/Profiles
Please start the application to be profiled in
another window and exercise its functionality now.
Once completed, select the "Scan" option below in
order to scan the system logs for AppArmor events.
For each AppArmor event, you will be given the
opportunity to choose whether the access should be
allowed or denied.
Profiling: /sbin/dhclient
[(S)can system log for AppArmor events] / (F)inish
Reading log entries from /var/log/audit/audit.log.
Profile: /sbin/dhclient 1
Execute: /usr/lib/NetworkManager/nm-dhcp-helper
Severity: unknown
(I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish
P
Should AppArmor sanitise the environment when
switching profiles?
Sanitising environment is more secure,
but some applications depend on the presence
of LD_PRELOAD or LD_LIBRARY_PATH.
(Y)es / [(N)o]
Y
Writing updated profile for /usr/lib/NetworkManager/nm-dhcp-helper.
Complain-mode changes:
WARN: unknown capability: CAP_net_raw
Profile: /sbin/dhclient 2
Capability: net_raw
Severity: unknown
[(A)llow] / (D)eny / (I)gnore / Audi(t) / Abo(r)t / (F)inish
A
Adding capability net_raw to profile.
Profile: /sbin/dhclient 3
Path: /etc/nsswitch.conf
Mode: r
Severity: unknown
1 - #include <abstractions/apache2-common>
2 - #include <abstractions/libvirt-qemu>
3 - #include <abstractions/nameservice>
4 - #include <abstractions/totem>
[5 - /etc/nsswitch.conf]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
3
Profile: /sbin/dhclient
Path: /etc/nsswitch.conf
Mode: r
Severity: unknown
1 - #include <abstractions/apache2-common>
2 - #include <abstractions/libvirt-qemu>
[3 - #include <abstractions/nameservice>]
4 - #include <abstractions/totem>
5 - /etc/nsswitch.conf
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding #include <abstractions/nameservice> to profile.
Profile: /sbin/dhclient
Path: /proc/7252/net/dev
Mode: r
Severity: 6
GitLab
Wiki · AppArmor / apparmor
The AppArmor user space development project.
1 - /proc/7252/net/dev
[2 - /proc/*/net/dev]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding /proc/*/net/dev r to profile
[...]
Profile: /sbin/dhclient 4
Path: /run/dhclient-eth0.pid
Mode: w
Severity: unknown
[1 - /run/dhclient-eth0.pid]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
N
Enter new path: /run/dhclient*.pid
Profile: /sbin/dhclient
Path: /run/dhclient-eth0.pid
Mode: w
Severity: unknown
1 - /run/dhclient-eth0.pid
[2 - /run/dhclient*.pid]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding /run/dhclient*.pid w to profile
[...]
Profile: /usr/lib/NetworkManager/nm-dhcp-helper 5
Path: /proc/filesystems
Mode: r
Severity: 6
[1 - /proc/filesystems]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding /proc/filesystems r to profile
= Changed Local Profiles =
The following local profiles were changed. Would you like to save them?
[1 - /sbin/dhclient]
2 - /usr/lib/NetworkManager/nm-dhcp-helper
(S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t
S
Writing updated profile for /sbin/dhclient.
Writing updated profile for /usr/lib/NetworkManager/nm-dhcp-helper.
Profiling: /sbin/dhclient
[(S)can system log for AppArmor events] / (F)inish
F
Setting /sbin/dhclient to enforce mode.
Setting /usr/lib/NetworkManager/nm-dhcp-helper to enforce mode.
Reloaded AppArmor profiles in enforce mode.
Please consider contributing your new profile!
See the following wiki page for more information:
https://wiki.apparmor.net/index.php/Profiles
Finished generating profile for /sbin/dhclient.
به یاد داشته باشید که برنامه کاراکترهای کنترلی از طرف شما را نشان نمیدهد ولی در اینجا به منظور بررسی شیوه عملکرد آن نمایش داده شدهاند.
1 اولین رویداد تشخیص داده شده مربوط به اجرای برنامه دیگری است. در این مورد، شما چندین انتخاب دارید: میتوانید برنامه را با پروفایل فرآیند والد آن (گزینه “Inherit”)، با پروفایل اختصاصی خود (گزینههای “Profile” و “Named”، که تنها در شیوه گزینش نام تفاوت دارند)، با پروفایل زیرمجموعه فرآیند والد آن (گزینه “Child”)، بدون پروفایل (گزینه “Unconfined”) اجرا کنید یا میتوانید تصمیم بگیرید که برنامه اصلا اجرا نشود (گزینه “Deny”).
به یاد داشته باشید که در صورت انتخاب یک پروفایل اختصاصی و عدم وجود آن، این ابزار پروفایل جدید را برای شما ایجاد کرده و در همان قسمت قوانین پیشنهای را به شما ارائه میدهد.
2 در سطح کرنل، قدرت ویژه کاربر root به چندین “قابلیت” تقسیم میشود. زمانی که یک فراخوانی سیستمی نیازمند ... خاصی است، AppArmor تایید میکند آیا پروفایل به برنامه اجازه استفاده از چنین قابلیتی را میدهد یا خیر.
3 در اینجا برنامه به دنبال مجوزهای /etc/nsswitch.conf است. aa-genprof تشخیص داد که این مجوز توسط چندین “موجودیت” صادر شده و آنها را به عنوان گزینههای جایگزین پیشنهاد میدهد. یک موجودیت مجموعهای از قوانین دسترسی را فراهم میکند که این قوانین منابع مختلفی که معمولا با یکدیگر استفاده میشوند را گروهبندی میکنند. در این مورد بخصوص، فایل معمولا توسط nameservice مرتبط با توابع کتابخانهای C قابل دسترسی است و برای انتخاب گزینه “#include <abstractions/nameservice>” عبارت “3” را وارد کرده و با درج “A” آن را تایید میکنیم.
4 برنامه قصد ایجاد فایل /run/dhclient-eth0.pid را دارد. اگر فقط اجازه ایجاد چنین فایل ویژهای را بدهیم، برنامه زمانی که کاربر از آن در یک رابط شبکه دیگر استفاده کند کار نخواهد کرد. بنابراین با انتخاب “New” نام فایل را به عبارت متداولتر “/run/dhclient*.pid” قبل از اینکه توسط “Allow” ثبت شود تغییر میدهیم.
[2 - /proc/*/net/dev]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding /proc/*/net/dev r to profile
[...]
Profile: /sbin/dhclient 4
Path: /run/dhclient-eth0.pid
Mode: w
Severity: unknown
[1 - /run/dhclient-eth0.pid]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
N
Enter new path: /run/dhclient*.pid
Profile: /sbin/dhclient
Path: /run/dhclient-eth0.pid
Mode: w
Severity: unknown
1 - /run/dhclient-eth0.pid
[2 - /run/dhclient*.pid]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding /run/dhclient*.pid w to profile
[...]
Profile: /usr/lib/NetworkManager/nm-dhcp-helper 5
Path: /proc/filesystems
Mode: r
Severity: 6
[1 - /proc/filesystems]
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore
A
Adding /proc/filesystems r to profile
= Changed Local Profiles =
The following local profiles were changed. Would you like to save them?
[1 - /sbin/dhclient]
2 - /usr/lib/NetworkManager/nm-dhcp-helper
(S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t
S
Writing updated profile for /sbin/dhclient.
Writing updated profile for /usr/lib/NetworkManager/nm-dhcp-helper.
Profiling: /sbin/dhclient
[(S)can system log for AppArmor events] / (F)inish
F
Setting /sbin/dhclient to enforce mode.
Setting /usr/lib/NetworkManager/nm-dhcp-helper to enforce mode.
Reloaded AppArmor profiles in enforce mode.
Please consider contributing your new profile!
See the following wiki page for more information:
https://wiki.apparmor.net/index.php/Profiles
Finished generating profile for /sbin/dhclient.
به یاد داشته باشید که برنامه کاراکترهای کنترلی از طرف شما را نشان نمیدهد ولی در اینجا به منظور بررسی شیوه عملکرد آن نمایش داده شدهاند.
1 اولین رویداد تشخیص داده شده مربوط به اجرای برنامه دیگری است. در این مورد، شما چندین انتخاب دارید: میتوانید برنامه را با پروفایل فرآیند والد آن (گزینه “Inherit”)، با پروفایل اختصاصی خود (گزینههای “Profile” و “Named”، که تنها در شیوه گزینش نام تفاوت دارند)، با پروفایل زیرمجموعه فرآیند والد آن (گزینه “Child”)، بدون پروفایل (گزینه “Unconfined”) اجرا کنید یا میتوانید تصمیم بگیرید که برنامه اصلا اجرا نشود (گزینه “Deny”).
به یاد داشته باشید که در صورت انتخاب یک پروفایل اختصاصی و عدم وجود آن، این ابزار پروفایل جدید را برای شما ایجاد کرده و در همان قسمت قوانین پیشنهای را به شما ارائه میدهد.
2 در سطح کرنل، قدرت ویژه کاربر root به چندین “قابلیت” تقسیم میشود. زمانی که یک فراخوانی سیستمی نیازمند ... خاصی است، AppArmor تایید میکند آیا پروفایل به برنامه اجازه استفاده از چنین قابلیتی را میدهد یا خیر.
3 در اینجا برنامه به دنبال مجوزهای /etc/nsswitch.conf است. aa-genprof تشخیص داد که این مجوز توسط چندین “موجودیت” صادر شده و آنها را به عنوان گزینههای جایگزین پیشنهاد میدهد. یک موجودیت مجموعهای از قوانین دسترسی را فراهم میکند که این قوانین منابع مختلفی که معمولا با یکدیگر استفاده میشوند را گروهبندی میکنند. در این مورد بخصوص، فایل معمولا توسط nameservice مرتبط با توابع کتابخانهای C قابل دسترسی است و برای انتخاب گزینه “#include <abstractions/nameservice>” عبارت “3” را وارد کرده و با درج “A” آن را تایید میکنیم.
4 برنامه قصد ایجاد فایل /run/dhclient-eth0.pid را دارد. اگر فقط اجازه ایجاد چنین فایل ویژهای را بدهیم، برنامه زمانی که کاربر از آن در یک رابط شبکه دیگر استفاده کند کار نخواهد کرد. بنابراین با انتخاب “New” نام فایل را به عبارت متداولتر “/run/dhclient*.pid” قبل از اینکه توسط “Allow” ثبت شود تغییر میدهیم.
GitLab
Wiki · AppArmor / apparmor
The AppArmor user space development project.
5 نکته اینکه این درخواست دسترسی قسمتی از پروفایل dhclient نبوده ولی در پروفایل جدید فراهم شده توسط /usr/lib/NetworkManager/nm-dhcp-helper در زمان اختصاص پروفایل ویژه به آن قرار دارد.
پس از بازرسی تمام رویدادهای ثبت شده، برنامه پیشنهاد میدهد که تمام پروفایلهای ایجاد شده در زمان اجرا ذخیرهسازی شوند. در این مورد، دو پروفایل داریم که به صورت همزمان با استفاده از “Save” میتوانیم ذخیرهسازی کنیم (اما امکان ذخیرهسازی انفرادی آنها نیز وجود دارد) قبل از اینکه برنامه را با “Finish” به پایان برسانیم.
پس از بازرسی تمام رویدادهای ثبت شده، برنامه پیشنهاد میدهد که تمام پروفایلهای ایجاد شده در زمان اجرا ذخیرهسازی شوند. در این مورد، دو پروفایل داریم که به صورت همزمان با استفاده از “Save” میتوانیم ذخیرهسازی کنیم (اما امکان ذخیرهسازی انفرادی آنها نیز وجود دارد) قبل از اینکه برنامه را با “Finish” به پایان برسانیم.
ا aa-genprof در حقیقت به عنوان یک لایه انتزاعی برای aa-logprof عمل میکند: این ابزار یک پروفایل خالی ایجاد کرده، آن را در حالت complain قرار میدهد و با اجرای aa-logprof، که ابزاری برای بروزرسانی پروفایل است، محتویات آن را مبتنی با رویدادهای ثبت شده در سیستم برورزسانی میکند. بنابراین در زمان دیگری میتوانید با اجرای این ابزار پروفایل خود را بهینهسازی کنید.
اگر میخواهید که پروفایل تولید شده کامل باشد، باید از برنامه به شیوهای که توضیح داده شده است استفاده کنید. در مورد dhclient، یعنی آن را با استفاده از Network Manager، ifupdown یا manual اجرا کنید. در انتها، ممکن است فایل /etc/apparmor.d/sbin.dhclient مشابه به این را دریافت کنید:
# Last Modified: Tue Sep 8 21:40:02 2015
#include <tunables/global>
/sbin/dhclient {
#include <abstractions/base>
#include <abstractions/nameservice>
capability net_bind_service,
capability net_raw,
/bin/dash r,
/etc/dhcp/* r,
/etc/dhcp/dhclient-enter-hooks.d/* r,
/etc/dhcp/dhclient-exit-hooks.d/* r,
/etc/resolv.conf.* w,
/etc/samba/dhcp.conf.* w,
/proc/*/net/dev r,
/proc/filesystems r,
/run/dhclient*.pid w,
/sbin/dhclient mr,
/sbin/dhclient-script rCx,
/usr/lib/NetworkManager/nm-dhcp-helper Px,
/var/lib/NetworkManager/* r,
/var/lib/NetworkManager/*.lease rw,
/var/lib/dhcp/*.leases rw,
profile /sbin/dhclient-script flags=(complain) {
#include <abstractions/base>
#include <abstractions/bash>
/bin/dash rix,
/etc/dhcp/dhclient-enter-hooks.d/* r,
/etc/dhcp/dhclient-exit-hooks.d/* r,
/sbin/dhclient-script r,
}
}
اگر میخواهید که پروفایل تولید شده کامل باشد، باید از برنامه به شیوهای که توضیح داده شده است استفاده کنید. در مورد dhclient، یعنی آن را با استفاده از Network Manager، ifupdown یا manual اجرا کنید. در انتها، ممکن است فایل /etc/apparmor.d/sbin.dhclient مشابه به این را دریافت کنید:
# Last Modified: Tue Sep 8 21:40:02 2015
#include <tunables/global>
/sbin/dhclient {
#include <abstractions/base>
#include <abstractions/nameservice>
capability net_bind_service,
capability net_raw,
/bin/dash r,
/etc/dhcp/* r,
/etc/dhcp/dhclient-enter-hooks.d/* r,
/etc/dhcp/dhclient-exit-hooks.d/* r,
/etc/resolv.conf.* w,
/etc/samba/dhcp.conf.* w,
/proc/*/net/dev r,
/proc/filesystems r,
/run/dhclient*.pid w,
/sbin/dhclient mr,
/sbin/dhclient-script rCx,
/usr/lib/NetworkManager/nm-dhcp-helper Px,
/var/lib/NetworkManager/* r,
/var/lib/NetworkManager/*.lease rw,
/var/lib/dhcp/*.leases rw,
profile /sbin/dhclient-script flags=(complain) {
#include <abstractions/base>
#include <abstractions/bash>
/bin/dash rix,
/etc/dhcp/dhclient-enter-hooks.d/* r,
/etc/dhcp/dhclient-exit-hooks.d/* r,
/sbin/dhclient-script r,
}
}
با tomoyo آشنا شوید :
https://en.wikipedia.org/wiki/TOMOYO_Linux
https://en.wikipedia.org/wiki/TOMOYO_Linux
Wikipedia
Tomoyo Linux
Linux security module
با lsm های لینوکس آشنا شوید :
https://kernsec.org/wiki/index.php/Projects
https://kernsec.org/wiki/index.php/Projects
:: 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 محافظت شده است .
#security @unixmens
ا 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 محافظت شده است .
#security @unixmens
پارامتر هایی در etc/sysctl.conf برای امنیت : (exec shield توضیح داده شد )
# Turn on execshield
kernel.exec-shield=1
kernel.randomize_va_space=1
# Enable IP spoofing protection
net.ipv4.conf.all.rp_filter=1
# Disable IP source routing
net.ipv4.conf.all.accept_source_route=0
# Ignoring broadcasts request
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_messages=1
# Make sure spoofed packets get logged
net.ipv4.conf.all.log_martians = 1
# Turn on execshield
kernel.exec-shield=1
kernel.randomize_va_space=1
# Enable IP spoofing protection
net.ipv4.conf.all.rp_filter=1
# Disable IP source routing
net.ipv4.conf.all.accept_source_route=0
# Ignoring broadcasts request
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_messages=1
# Make sure spoofed packets get logged
net.ipv4.conf.all.log_martians = 1