💻 P0SCon2019

Join P0SCon2019 and send your abstract of speech or workshop to be a speaker at P0SCon.

More information:
https://poscon.ir

Deadline:
11 Sep 2019

Conference Date:
12 Oct 2019

Urmia University of Technology

خبر خوش :
پروکسیموکس با ویژگی های جدید ریلیز شد .
Whats new in Proxmox VE 6.0

#jobs #oracle @unixmens

#jobs #linux @unixmens

آشنایی با پروتکل های مسیر یابی #routing #route @unixmens

پروتکل های مسیریابی شبکه

همان‌گونه که پیش‌تر بیان کردیم، به انتخاب مناسب‌ترین مسیر در بین روترهای شبکه مسیریابی گفته می‌شود. هدف از پروتکل‌های مسیریابی این است که بتوانیم مسیرهای موجود در شبکه‌ی یک شرکت یا سازمان را شناسایی کرده، جدول‌های مسیریابی بسازیم و درنهایت درباره‌ی مسیریابی بتوانیم تصمیم‌گیری کنیم.

رایج‌ترین پروتکل‌های مسیریابی شبکه عبارت‌اند از: RIP, IGRP, EIGRP, OSPF, IS-IS, BGP.

این پروتکل‌ها در دو گروه مسیریابی قرار می‌گیرند که عبارت‌اند از پروتکل‌های Distance Vector و پروتکل‌های Link State.
Distance vector protocols

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

مشکل این پروتکل‌ها این است که هر روتر باید اطلاعات جدید را به‌ همسایه‌ی خود اطلاع دهد. بنابراین ممکن است مدت‌زمان زیادی طول بکشد تا همه‌ی روترها بتوانند اطلاعات دقیقی از شبکه داشته باشند.

این پروتکل‌ها از subnet mask های ثابت استفاده می‌کنند که مقیاس‌پذیر نیستند.
Link state protocols

این پروتکل‌ها اطلاعات مسیریابی را تنها زمان بروز تغییرات انتشار می‌دهند؛ به همین دلیل به صورت مؤثر از پهنای باند استفاده می‌کنند.

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

این پروتکل‌ها از چندین subnet mask استفاده می‌کنند که هم مقیاس‌پذیر هستند و هم مسیریابی را بهتر انجام می‌دهند.
پروتکل های مسیریابی شبکه
پروتکل IGRP

پروتکل IGRP مخفف عبارت Interior Gateway Routing Protocol بوده و یک پروتکل distance vector است. این پروتکل در سیستم‌های «سیسکو» (Cisco) فراهم شده و به‌منظور مسیریابی چندین پروتکل در شبکه‌های کوچک و متوسط سیسکو مورد استفاده قرار می‌گیرد. به همین دلیل جهت استفاده از این پروتکل حتماً باید از روترهای شرکت سیسکو استفاده کنید؛ برخلاف IP RIP و IPX RIP که برای انواع شبکه‌ها طراحی شده‌اند.

ا IGRP می‌تواند پروتکل‌های IP، IPX، Decnet و AppleTalk را مسیریابی کند. این امر باعث می‌شود که IGRP برای کاربرانی که از چندین پروتکل استفاده می‌کنند بسیار تطبیق‌پذیر باشد.

این پروتکل تا حدی مقیاس‌پذیری بیشتری از RIP دارد. زیرا از تعداد ۱۰۰ هاپ (hop) پشتیبانی کرده، هر ۹۰ ثانیه اطلاع‌رسانی می‌کند و از ترکیبی از پنج معیار مختلف برای انتخاب بهترین مقصد مسیر استفاده می‌کند.

توجه داشته باشید چون IGRP دیرتر اطلاع‌رسانی می‌کند و پهنای باند کمتری را نسبت به RIP مصرف می‌کند، همگرایی آن کندتر انجام خواهد شد. علت آن است که ۹۰ ثانیه طول می‌کشد تا روترها از تغییرات به وجود آمده در شبکه مطلع شوند.
ویژگی های پروتکل IGRP

یک پروتکل Distance Vector است.
پروتکل‌های IP، IPX، Decnet و Appletalk را مسیریابی می‌کند.
جداول مسیریابی هر ۹۰ ثانیه منتشر می‌شود.
تعداد هاپ : ۱۰۰
ا Subnet Masks ثابت
متریک: پهنای باند، تأخیر، قابلیت اطمینان، بارکاری و MTU Size
خلاصه‌سازی در Network Class Address
ا Load Balancing در ۶ مسیر برابر یا نابرابر (IOS 11.0)
محاسبه متریک = کمترین پهنای باند در طول مسیر * میزان تاخیر (usec)
تقسیم افقی
تایمرها: (Invalid Timer (270 sec), Flush Timer (630 sec), Holddown Timer (280 sec

پروتکل EIGRP

پروتکل EIGRP مخفف عبارت Enhanced Interior Gateway Routing Protocol است. این پروتکل در حقیقت نسخه‌ی پیشرفته‌ی پروتکل IGRP است. EIGRP یک پروتکل مسیریابی هیبرید بوده که توسط سیستم‌های سیسکو فراهم شده و در اکثر پروتکل‌های شبکه‌ای شرکت سیسکو مورد استفاده قرار می‌گیرد.

ا EIGRP ویژگی‌های هر دو پروتکل مسیریابی distance vector و link state را دارد. این پروتکل تمام مشخصات IGRP را داشته و از متریک‌های مشابهی جهت انتخاب بهترین مسیر استفاده می‌کند.

علاوه‌براین، تنظیماتی برای Load balance ترافیک از طریق مسیرهای برابر یا نابرابر در این پروتکل وجود دارد. در این پروتکل خلاصه‌سازی آدرس‌های شبکه به‌صورت خودکار بوده که البته می‌توان آن را به نحوی پیکربندی کرد که خلاصه‌سازی در محدوده‌ی مشخصی انجام شود.

توزیع مجدد بین پروتکل‌های IGRP و EIGRP هم خودکار است. این پروتکل از ۲۵۵ هاپ و Variable Length Subnet mask پشتیبانی می‌کند.
همگرایی

همگرایی با EIGRP سریع‌تر صورت می‌گیرد؛ چون در آن از الگوریتمی به نام DUAL استفاده می‌شود. هنگامی‌که یک روتر تشخیص می‌دهد که یکی از مسیرها از دسترس خارج شده، این الگوریتم اجرا می‌شود. روتر از همسایه‌هایش درخواست می‌کند که به دنبال یک مسیر جایگزین بگردند؛ به‌گونه‌ای که دور (loop) در شبکه ایجاد نکند.

ا EIGRP جدول مسیریابی را با مسیر جدید و متریک مربوط به آن به‌روزرسانی می‌کند. فقط زمانی که مسیر تغییر پیدا می‌کند، اطلاع‌رسانی صورت می‌گیرد. همین امر باعث می‌شود که از پهنای باند، به‌مراتب بهتر از پروتکل‌های distance vector استفاده شود.
سیستم‌های مستقل

ا EIGRP وظیفه‌ی سیستم‌های مستقل مختلف را که تحت یک دامنه‌ی مسیریابی اجرا می‌شوند، شناسایی می‌کنند. سیستم‌های مستقل در IGRP و EIGRP جهت تغییر در توزیع مجدد مسیر، فیلتر کردن و خلاصه‌سازی نقاط استفاده می‌شوند.
ویژگی‌ های پروتکل EIGRP

یک پروتکل پیشرفته‌ی Distance Vector است.
پروتکل‌های IP، IPX، Decnet و Appletalk را مسیریابی می‌کند.
اطلاع‌رسانی مسیریابی: فقط زمانی که تغییر مسیر اتفاق بیفتد.
متریک: پهنای باند، تأخیر، قابلیت اطمینان، بارکاری و MTU Size
تعداد هاپ: ۲۵۵
Length Subnet Mask Variable
خلاصه‌سازی در Network Class Address یا Subnet Boundary
ا Load Balancing در ۶ مسیر برابر یا نابرابر (IOS 11.0)
تایمرها: زمان فعال (۱۸۰ ثانیه)
محاسبه متریک: کمترین پهنای باند در طول مسیر * میزان تاخیر (میلی‌ثانیه) * ۲۵۶
تقسیم افقی
آدرس چندگانه LSA: 224.0.0.10

پروتکل OSPF

ا OSFP مخفف عبارت Open Shortest Path First بوده و یک پروتکل Link State است. این پروتکل برای مسیریابی IP شبکه‌های گسترده استفاده می‌شود. پروتکل Link State یک اطلاعیه برای تمام همسایگان متصل در یک ناحیه می‌فرستد. هر روتر OSPF که فعال شود، یک بسته‌ با نام Hello به تمام روترهای دیگر ارسال می‌کند.

بسته‌ی Hello حاوی اطلاعاتی نظیر تایمرهای روتر، ID روتر و Subnet mask است. چنانچه روترهای دیگر این اطلاعات را تائید کنند، آنگاه روتر جدید وارد سیستم می‌شود. روترهای همسایه با تغییر پایگاه داده‌ی link state یک مجاورت یا adjacency ایجاد می‌کنند.

روترهای point-to-point و point-to-multipoint به‌صورت خودکار مجاورت ایجاد می‌کنند. روترهای پیکربندی شده با رابط‌های OSPF مانند broadcast و NBMA از یک روتر تعیین شده استفاده می‌کنند تا بتوانند این مجاورت را ایجاد کنند.
همگرایی

الگوریتم SPF با نام Dijkstra باعث می‌شود که کوتاه‌ترین مسیر از منبع تا مقصد مشخص شود. ازآنجایی‌که هر روتر OSPF یک کپی از توپولوژی پایگاه داده را در اختیار دارد، هر تغییر مسیری به‌سرعت تشخیص داده می‌شود. تشخیص تغییرات و جایگزینی روترها بسیار سریع‌تر از پروتکل‌های distance vector انجام می‌شود.
ویژگی ‌های پروتکل OSPF

یک پروتکل Link State است.
قابلیت مسیریابی IP
اطلاع‌رسانی مسیریابی: فقط زمانی که تغییر مسیر اتفاق بیفتد.
متریک: هزینه‌ی ترکیبی هر روتر تا مقصد.
تعداد هاپ: هیچ (محدود شده توسط شبکه)
Variable Length Subnet Mask
خلاصه‌سازی در Network Class Address یا Subnet Boundary
ا Load Balancing از طریق ۴ مسیر برابر
نوع روتر: Internal, Backbone, ABR, ASBR
نوع نواحی: Backbone, Stubby, Not-So-Stubby, Totally Stubby
LSA نوع: (Intra-area (1,2) Inter-area (3,4), External (5,7
تایمرها: Hello Interval و Dead Interval (برای انواع شبکه متفاوت است)
LSA Multicast آدرس: ۲۲۴.۰.۰.۵ و ۲۲۴.۰.۰.۶
نوع رابط: Point to Point, Broadcast, Non-Broadcast, Point to Multipoint, Loopback

پروتکل IS-IS

پروتکل مسیریابی IS-IS مخفف عبارت Intermediate System-Intermediate System است. IS-IS یک پروتکل link state مشابه با OSPF بوده که در سازمان‌های بزرگ و مشتریان ISP مورد استفاده قرار می‌گیرد. سیستم Intermediate یک روتر است و IS-IS یک پروتکل مسیریابی بوده که بسته‌ها را بین سیستم‌های Intermediate مسیریابی می‌کند. IS-IS از دیتابیس link state و الگوریتم SPF برای انتخاب کوتاه‌ترین مسیر استفاده می‌کند.

روترهای همسایه در لینک‌های Point to point و point to multipoint مجاورت را توسط ارسال بسته‌های Hello و تبادل دیتابیس link state ایجاد می‌کنند. روترهای IS-IS موجود در شبکه‌های broadcast و NBMA، یک روتر مشخص را انتخاب می‌کنند که مجاورت را با تمام روترهای همسایه در شبکه ایجاد می‌کند.

این روتر تعیین‌شده و روترهای دیگر، مجاورت را با تمام روترهای همسایه از طریق خبررسانی چندرسانه‌ای 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 آدرس هاپ بعدی

Implementing Mandatory Access Control with SELinux or AppArmor in Linux
https://www.tecmint.com/mandatory-access-control-with-selinux-or-apparmor-linux/

جایگزین Icinga، یک fork از Nagios
به موجب اختلاف نظر در مدل توسعه انتخابی برای Nagios (که توسط یک شرکت کنترل می‌شود)، تعدادی از توسعه‌دهندگان آن را fork و از نام جدید Icinga استفاده کردند. Icinga کماکان ـ تا جای ممکن - با پیکربندی‌ها و پلاگین‌های Nagios سازگار، اما ویژگی‌های اضافی را به آن افزوده است.
→ https://www.icinga.org/

راه‌اندازی 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شامل مستندات کاملی درباره چگونگی عملکرد و توسعه پلاگین‌ها است.
→ 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 مدیریت شود.

ا AppArmor یک سیستم کنترل دسترسی ضروری یا Mandatory Access Control (MAC) است که درون رابط ماژول‌های امنیتی لینوکس یا Linux Security Modules (LSM) پیاده‌سازی شده است. در عمل، کرنل قبل از هر فراخوانی سیستمی از AppArmor پرس و جو می‌کند تا بداند آیا فرآیند مجاز به انجام عملیات مذکور است یا خیر. از طریق این مکانیزم، AppArmor برنامه‌ها را محدود به مجموعه کوچکی از منابع می‌کند.
ا 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 با مانیتور کردن فراخوانی سیستمی به آن بتواند منابع مصرفی‌اش را تحت نظر قرار دهد.
مهمترین برنامه‌هایی که باید دسترسی محدود داشته باشند تحت شبکه بوده و آن‌هایی هستند که بیشتر هدف حملات راه‌دور قرار می‌گیرند. به همین دلیل است که 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

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” ثبت شود تغییر می‌دهیم.

5 نکته اینکه این درخواست دسترسی قسمتی از پروفایل dhclient نبوده ولی در پروفایل جدید فراهم شده توسط /usr/lib/NetworkManager/nm-dhcp-helper در زمان اختصاص پروفایل ویژه به آن قرار دارد.
پس از بازرسی تمام رویدادهای ثبت شده، برنامه پیشنهاد می‌دهد که تمام پروفایل‌های ایجاد شده در زمان اجرا ذخیره‌سازی شوند. در این مورد، دو پروفایل داریم که به صورت همزمان با استفاده از “Save” می‌توانیم ذخیره‌سازی کنیم (اما امکان ذخیره‌سازی انفرادی آن‌ها نیز وجود دارد) قبل از اینکه برنامه را با “Finish” به پایان برسانیم.