نشانی‌های شنود (Listening addresses)

رفتار پیش‌فرض کارگزار (شنود روی درگاه استاندارد SNMP UDP در تمام واسط‌ها) معادل دستورالعمل زیر است:

امتیازات زمان اجرا (Run-time privileges)

کارگزار را می‌توان به‌گونه‌ای پیکربندی کرد که پس از باز کردن درگاه‌های شنود اولیه، هرگونه دسترسی ممتاز (ریشه) خود را رها کند. با در نظر گرفتن یک گروه مناسب "snmp" (تعریف‌شده در /etc/group)، این کار را می‌توان با استفاده از دستورالعمل‌های زیر انجام داد:

agentuser  nobody
agentgroup snmp

agentuser  #10
agentgroup #10

پیکربندی SNMPv3 (SNMPv3 Configuration)

شناسه موتور (engine ID) برای کارگزار به جای این‌که به صورت شبه‌تصادفی تولید شود، می‌تواند بر اساس آدرس MAC واسط شبکه دوم (eth1) با استفاده از دستورالعمل‌های زیر محاسبه شود:

کاربران SNMPv3 (SNMPv3 Users)

دستورالعمل‌های زیر سه کاربر ایجاد می‌کنند که همگی دقیقاً از تنظیمات احراز هویت و رمزنگاری یکسانی استفاده می‌کنند:

createUser me     MD5 "single pass phrase"
createUser myself MD5 "single pass phrase" DES
createUser andI   MD5 "single pass phrase" DES "single pass phrase"

می‌توان عبارت‌های عبور جداگانه‌ای را برای احراز هویت و رمزنگاری مشخص کرد:

کنترل دسترسی سنتی (Traditional Access Control)

به کاربران SNMPv3 تعریف‌شده در بالا می‌توان دسترسی به کل درخت MIB را با استفاده از دستورالعمل‌های زیر اعطا کرد:

rouser me
rwuser onering

rouser myself   .1.3.6.1.2
rwuser andI     system

توجه داشته باشید که ترکیبی که یک کاربر یکسان را تکرار می‌کند، مانند:

rouser onering
rwuser onering

دستورالعمل‌های:

rocommunity public
rwcommunity private

یک پیکربندی با آسیب‌پذیری کمی کمتر ممکن است اطلاعات قابل بازیابی را محدود کند:

پیکربندی VACM (VACM Configuration)

این جفت تنظیمات آخر معادل تعاریف کامل VACM هستند:

#         sec.name  source        community
com2sec   public    default       public
com2sec   mynet     10.10.10.0/24 private
com2sec6  mynet     fec0::/64     private
#                  sec.model  sec.name
group  worldGroup  v1         public
group  worldGroup  v2c        public
group  myGroup     v1         mynet
group  myGroup     v2c        mynet
#              incl/excl   subtree     [mask]
view   all     included    .1
view   sysView included    system
#              context model level   prefix  read    write  notify (unused)
access  worldGroup  ""  any  noauth  exact   system  none   none
access  myGroup     ""  any  noauth  exact   all     all    none

چندین نکته در این مثال قابل توجه است:

دستورالعمل‌های group باید برای هر دو درخواست SNMPv1 و SNMPv2c تکرار شوند.

نام امنیتی com2sec متمایز از رشته کامیونیتی است که به آن نگاشت شده است. آن‌ها می‌توانند یکسان ("public") یا متفاوت ("mynet"/"private") باشند - اما آنچه در دستورالعمل group ظاهر می‌شود نام امنیتی است، بدون در نظر گرفتن رشته کامیونیتی اصلی.

هر دو دستورالعمل view زیردرخت‌های ساده OID را تعریف می‌کنند، بنابراین هیچ‌کدام نیازی به ماسک صریح ندارند. همین امر برای نمای "زیردرخت ترکیبی" تعریف‌شده در زیر نیز صادق است. در واقع، یک فیلد ماسک تنها هنگام تعریف برش‌های سطری در یک جدول (یا نماهای مشابه) مورد نیاز است و تقریباً همیشه می‌توان آن را حذف کرد.

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

پیکربندی نمای نوع‌دار (Typed-View Configuration)

پیکربندی مشابهی را می‌توان به صورت زیر نیز انجام داد:

view   sys2View included    system
view   sys2View included    .1.3.6.1.2.1.25.1
authcommunity read       public  default      -v sys2View
authcommunity read,write private 10.10.10.0/8

این سازوکار اجازه می‌دهد تا نماهای چند زیردرختی (یا سایر نماهای غیرساده) با سبک پیکربندی یک‌خطی rocommunity استفاده شوند.

همچنین در صورت نیاز، از پیکربندی دسترسی "فقط-نوشتنی" نیز پشتیبانی می‌کند.

گروه سیستم (System Group)

محتوای کامل گروه 'system' (به استثنای sysUpTime) را می‌توان به‌طور صریح با استفاده از دستورات زیر پیکربندی کرد:

# بازنویسی 'uname -a' و OID سیستم تعبیه‌شده - مقادیر ذاتاً فقط-خواندنی
sysDescr     Universal Turing Machine mk I
sysObjectID  .1.3.6.1.4.1.8072.3.2.1066
# بازنویسی مقادیر پیش‌فرض از 'configure' - این اشیا را فقط-خواندنی می‌کند
sysContact   Alan.Turing@pre-cs.man.ac.uk
sysName      tortoise.turing.com
sysLocation  An idea in the mind of AT
# رفتار استاندارد میزبان نهایی (end-host)
sysServices  72

گروه منابع میزبان (Host Resources Group)

فهرست دستگاه‌های بررسی‌شده برای گنجاندن احتمالی در hrDiskStorageTable (و hrDeviceTable) را می‌توان با استفاده از هر یک از دستورالعمل‌های زیر اصلاح کرد:

ignoredisk /dev/rdsk/c0t[!6]d0
ignoredisk /dev/rdsk/c0t[0-57-9a-f]d0

پایش فرایندها (Process Monitoring)

فهرست سرویس‌های در حال اجرا روی یک سیستم را می‌توان پایش کرد (و تمهیداتی برای اصلاح هرگونه مشکل فراهم نمود)، با استفاده از:

# حداقل یک فرایند وب‌سرور باید همیشه در حال اجرا باشد
proc    httpd
procfix httpd  /etc/rc.d/init.d/httpd restart
# هرگز نباید بیش از ۱۰ فرایند ایمیل در حال اجرا باشد
#    (تعداد بیشتر نشان‌دهنده طوفان احتمالی ایمیل است، بنابراین سیستم ایمیل را خاموش کنید)
proc    sendmail   10
procfix sendmail  /etc/rc.d/init.d/sendmail stop
# باید یک کارگزار مدیریت شبکه منفرد در حال اجرا باشد
#   ("فقط یکی می‌تواند وجود داشته باشد")
proc    snmpd    1  1

پایش مصرف دیسک (Disk Usage Monitoring)

وضعیت فضای ذخیره‌سازی دیسک را می‌توان با استفاده از موارد زیر پایش کرد:

includeAllDisks 10%
disk /var 20%
disk /usr  3%
#  نگهداری ۱۰۰ مگابایت فضای خالی برای crash dumpها
disk /mnt/crash  100000

پایش بار سیستم (System Load Monitoring)

یک بررسی ساده برای سیستمی با بار کاری بیش از حد می‌تواند چنین باشد:

پایش فایل‌های گزارش (Log File Monitoring)

TODO

مدیریت اعلان‌ها (Notification Handling)

پیکربندی کارگزار برای گزارش تلاش‌های نامعتبر برای دسترسی را می‌توان به صورت زیر انجام داد:

authtrapenable 1
trapcommunity  public
trap2sink      localhost

trapsink       localhost
trap2sink      localhost
informsink     localhost

TODO - discuss SNMPv3 traps

TODO - mention trapd access configuration

پایگاه داده رخداد DisMan (DisMan Event MIB)

ساده‌ترین پیکربندی برای خودپایشی فعال کارگزار، توسط کارگزار، برای کارگزار، احتمالاً چنین است:

# تنظیم اطلاعات کاربری برای بازیابی مقادیر پایش‌شده
createUser    _internal MD5 "the first sign of madness"
iquerySecName _internal
rouser        _internal
# فعال‌سازی مدخل‌های پایش استاندارد
defaultMonitors         yes
linkUpDownNotifications yes
# اگر مشکلی وجود دارد، به کسی اطلاع بده!
trap2sink localhost

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

توجه داشته باشید که دستورالعمل‌های DisMan به خودی خود برای گزارش فعالانه مشکلات کافی نیستند - همچنین باید یک مقصد مناسب پیکربندی شده باشد تا اعلان‌های حاصل عملاً به آن ارسال شوند.

یک مثال مانیتور دقیق‌تر در زیر آورده شده است:

این یک مدخل مانیتور بولی صریح را تعریف می‌کند که به دنبال هر فرایندی است که بیش از ۱۰ مگابایت حافظه فعال استفاده می‌کند. چنین فرایندهایی با استفاده از تله استاندارد DisMan به نام mteTriggerFired گزارش می‌شوند، اما یک varbind اضافی hrSWRunName (با نویسه عمومی) نیز افزوده می‌شود.

این مدخل همچنین یک کاربر صریح (me، همان‌طور که قبلاً تعریف شد) را برای بازیابی مقادیر پایش‌شده و ساخت تله مشخص می‌کند.

اشیاء یا مقادیری که می‌توانند در حوالی سطح مشخص‌شده نوسان داشته باشند، بهتر است با استفاده از یک مدخل پایش آستانه پایش شوند:

این دستور هر زمان که ترافیک ورودی روی هر واسط شبکه از (تقریباً) ۵۰۰ کیلوبایت بر ثانیه بالاتر برود یک تله mteTriggerRising ارسال می‌کند، و هنگامی که دوباره به زیر ۱۰۰ کیلوبایت بر ثانیه کاهش یابد یک تله متناظر mteTriggerFalling ارسال می‌کند.

توجه داشته باشید که این دستور تفاوت‌های بین نمونه‌های متوالی (-D) را پایش می‌کند، نه مقادیر واقعی خود نمونه‌ها را. همین اثر را می‌توان با استفاده از دستور زیر به دست آورد:

دستورالعمل linkUpDownNotifications بالا به‌طور کلی معادل موارد زیر است:

notificationEvent  linkUpTrap    linkUp   ifIndex ifAdminStatus ifOperStatus
notificationEvent  linkDownTrap  linkDown ifIndex ifAdminStatus ifOperStatus
monitor  -r 60 -e linkUpTrap   "Generate linkUp"   ifOperStatus != 2
monitor  -r 60 -e linkDownTrap "Generate linkDown" ifOperStatus == 2

این بخش تله‌هایی را که باید ارسال شوند (با استفاده از notificationEvent) تعریف می‌کند و به‌طور صریح به اعلان مربوطه در مدخل مانیتور متناظر ارجاع می‌دهد (به جای استفاده از تله‌های پیش‌فرض DisMan).

دستورالعمل defaultMonitors بالا معادل مجموعه‌ای از مدخل‌های مانیتور (بولی) است:

monitor	-o prNames      -o prErrMessage  "procTable" prErrorFlag   != 0
monitor	-o memErrorName -o memSwapErrorMsg "memory"  memSwapError  != 0
monitor	-o extNames     -o extOutput     "extTable"  extResult     != 0
monitor	-o dskPath      -o dskErrorMsg   "dskTable"  dskErrorFlag  != 0
monitor	-o laNames      -o laErrMessage  "laTable"   laErrorFlag   != 0
monitor	-o fileName     -o fileErrorMsg  "fileTable" fileErrorFlag != 0

یک رویکرد جایگزین این است که اقدام "اصلاح" (fix) متناظر به‌طور خودکار فراخوانی شود:

setEvent   prFixIt  prErrFix = 1
monitor -e prFixIt "procTable" prErrorFlag   != 0

پایگاه داده زمان‌بندی DisMan (DisMan Schedule MIB)

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

به‌عنوان روش جایگزین، این را می‌توان برای اجرا در زمان‌های خاصی از روز پیکربندی کرد (شاید پس از چرخش گزارش‌ها):

سبک زمان‌بندی یک‌باره بسیار کمتر رایج است، اما ویروس مخفی SNMP را می‌توان در رخداد بعدی جمعه سیزدهم فعال کرد با استفاده از:

دستورات گسترش دلخواه (Arbitrary Extension Commands)

سبک قدیمی

exec [MIBOID] NAME PROG ARGS"
sh   [MIBOID] NAME PROG ARGS"
execfix NAME PROG ARGS"

extend [MIBOID] NAME PROG ARGS"
extendfix [MIBOID] NAME PROG ARGS"

دستورات گسترش مختص MIB (MIB-Specific Extension Commands)

یک‌باره (One-Shot)

مانا (Persistent)

پشتیبانی از پرل تعبیه‌شده (Embedded Perl Support)

اگر پشتیبانی از پرل تعبیه‌شده در کارگزار فعال باشد، مقداردهی اولیه پیش‌فرض معادل دستورالعمل‌های زیر است:

disablePerl  false
perlInitFile /usr/share/snmp/snmp_perl.pl

perl use Data::Dumper;
perl sub myroutine  { print "got called: ",Dumper(@_),"\n"; }
perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine);

این به شیء $agent متکی است که در فایل نمونه snmp_perl.pl تعریف شده است.

یک گرداننده MIB واقعی‌تر ممکن است چنین باشد:

XXX - WHAT ???

ماژول‌های با بارگذاری پویا (Dynamically Loadable Modules)

TODO

پشتیبانی از پروکسی (Proxy Support)

یک پیکربندی برای عمل کردن به عنوان یک پروکسی ساده برای دو کارگزار SNMP دیگر (در حال اجرا روی سیستم‌های دوردست) ممکن است چنین باشد:

com2sec -Cn rem1context  rem1user default  remotehost1
com2sec -Cn rem2context  rem2user default  remotehost2
proxy -Cn rem1context  -v 1 -c public  remotehost1  .1.3
proxy -Cn rem2context  -v 1 -c public  remotehost2  .1.3

همین دستورالعمل‌های proxy برای درخواست‌های (ورودی) SNMPv3 نیز کار می‌کنند، که می‌توانند مستقیماً یک بافتار (context) را مشخص کنند. احتمالاً منطقی‌تر خواهد بود که از بافتارهای remotehost1 و remotehost2 استفاده شود - نام‌های بالا برای نشان دادن نحوه کارکرد این دستورالعمل‌ها با یکدیگر انتخاب شده‌اند.

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

کاربرد دیگر دستورالعمل proxy ارسال بخشی از درخت OID به کارگزار دیگر است (خواه روی یک میزبان دوردست یا در حال شنود روی درگاهی متفاوت در همان سیستم)، در حالی که بقیه موارد را به‌طور داخلی مدیریت می‌کند:

یک رویکرد کمتر معمول، نگاشت یک زیردرخت به ناحیه متفاوتی از درخت کلی MIB است (خواه به صورت محلی یا روی یک سیستم دوردست):

# uses SNMPv3 to access the MIB tree .1.3.6.1.2.1.1 on 'remotehost'
# and maps this to the local tree .1.3.6.1.3.10
proxy -v 3 -l noAuthNoPriv -u user remotehost .1.3.6.1.3.10 .1.3.6.1.2.1.1

زیرکارگزارهای SMUX (SMUX Sub-Agents)

smuxsocket 127.0.0.1
smuxpeer .1.3.6.1.2.1.14 ospf_pass

زیرکارگزارهای AgentX (AgentX Sub-Agents)

کارگزار Net-SNMP را می‌توان به‌گونه‌ای پیکربندی کرد که به عنوان یک کارگزار اصلی AgentX عمل کند (با شنود روی یک سوکت نام‌گذاری‌شده غیراستاندارد، و اجرا با استفاده از امتیازات دسترسی تعریف‌شده در قبل)، با استفاده از:

master agentx
agentXSocket /tmp/agentx/master
agentXPerms  0660 0550 nobody snmp

netsnmp_ds_set_string(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_X_SOCKET, 
                      "/tmp/agentx/master");

پیکربندی AgentX تحت شبکه loopback را می‌توان با استفاده از موارد زیر تنظیم کرد:

agentXSocket   tcp:localhost:705
agentXTimeout  5
agentXRetries  2

agentXSocket   tcp:localhost:705
agentXTimeout  10
agentXRetries  1
agentXPingInterval 600

توجه داشته باشید که تنظیمات مهلت زمانی (timeout) و تلاش مجدد (retry) می‌توانند برای دو جهت نامتقارن باشند، و زیرکارگزار می‌تواند کارگزار اصلی را در فواصل منظم (۶۰۰ ثانیه = هر ۱۰ دقیقه) بررسی کند تا از برقراری اتصال اطمینان حاصل نماید.