آموزش‌های خط فرمانی

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

آموزش‌های خط فرمانی

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

نظارت بر عملکرد کاربران


از چه طریق می‌توانم تاریخچه را در فایل log ثبت کنم یا bash را در برابر پاک کردن آن ایمن نمایم؟

اگر شما یک کاربر پوسته هستید که می‌خواهد فعالیت‌های خود را ضبط نماید، FAQ #88 را ملاحظه کنید. اگر شما یک مدیر سیستم می‌باشید که می‌خواهد بداند، موقعی که یک کاربر تاریخچه پوسته‌اش را به ‎ /dev/null‎ فرستاده یا آن را غیر فعال نموده، چطور می‌تواند پی ببرد که او چه دستوراتی را اجرا کرده است، چند مشکل برای این مورد وجود دارد....

اولین موضوع این است:

  • ‎kill -9 $$

این فرمانِ به ظاهر بی ضرر کاری را انجام می‌دهد که شما برای آن متصور بودید: پوسته جاری را متوقف می‌کند. اما، ‎.bash_history‎ فقط موقعی روی دیسک نوشته می‌شود که به bash اجازه داده شود به طور پاکیزه خارج گردد. به این ترتیب، ارسال سیگنال SIGKILL به bash از ثبت رخداد درفایل ‎.bash_history‎ پیش‌گیری می‌کند.

همچنین شاید کاربران متغیرهایی تنظیم کنند که تاریخچه پوسته را غیر فعال نمایند، یا به سادگی ‎.bash_history‎ خودشان را یک پیوند نمادین به ‎ /dev/null‎ بسازند. تمام اینها هر کوششی برای جاسوسی آنها از طریق فایل ‎.bash_history‎ آنان را ناکام می‌کند. ساده‌ترین روش انجام این مورد است

  • unset HISTFILE

و تاریخچه حتی اگر کاربر به طور پاکیزه از پوسته خارج گردد نیز نوشته نخواهد شد.

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

سومین موضوع، جایگاه است. فرض کنید شما یک ‎chroot jailزیرنویس1‎ برای کاربران bash خودتان اتخاذ کنید. این ایده شگفت‌انگیزی است، و یک قدم مناسب به طرف امنیت سرویس‌دهنده شما می‌باشد. هرچند که قرار دادن کاربران در یک زندان chroot‎ به طور معکوس بر توانایی گزارش فعالیت های کاربران نیز تأثیر می‌گذارد. وقتی که محدودیت ایجاد شد، کاربر شما فقط می‌تواند در محتوای درون محدوده(jail) ویژه خودش بنویسد. این امر یافتن لاگهای خارجی قابل نوشتن کاربر را آسان می‌سازد، و مهاجم را قادر می‌کند نسبت به حالتی که غیر از این باشد، بسیار آسانتر فایلهای ثبت رخداد پنهان شما را پیدا کند.

این امر شما را در چه جایگاهی قرار می‌دهد؟ متأسفانه، جای خوبی نیست، و مطمئناً آنچه شما می‌خواستید بدانید نیست. اگر شما می‌خواهید تمام دستوراتی که توسط کاربر به bash صادر گردیده را ضبط کنید، اولین نیاز آن، ویرایش bash به طوری است که عملاً آن دستورات را در زمان واقعی، موقعی که اجرا می‌شوند، ضبط کند-- نه وقتی که کاربر قطع ارتباط می‌کند. دومین ضرورت ثبت کردن آنها به طریقی است که کاربر نتواند باز گردد و آنها را پاک کند(که به معنی آنست که در فایل درج نشوند).

گرچه، هنوز این هم قابل اطمینان نیست، زیرا کاربران نهایی به سادگی می‌توانند پوسته‌های خودشان را انتقال بدهند(upload) و آن را به جای bash هک شده شما اجرا کنند. یا شاید آنها یکی از پوسته‌های قبلی دیگر بر روی سیستم شما را به جای آن bash استفاده کنند.

‎Bash 4.1‎ یک گزینه پیکربندی compile-time(حین ترجمه) برای فعال کردن وقایع نگاری تمام فرمانها از طریق ‎syslog(3)‎ دارد. (توجه کنید که این مطلب فقط در صورتی کمک می‌کند که کاربران واقعاً آن پوسته را استفاده کنند که در بالا بحث شد.)

برای آنان که به طور مسلم باید بعضی توانایی‌های وقایع نگاری را در نگارشهای قدیمی‌تر bash داشته باشند: می‌توانید از وصله‌ای که در اینجا قرار داده شده استفاده کنید http://wooledge.org/~greg/bash_logging.txt (این patch توسط _sho_ ارائه شده است-- با مسئولیت خودتان استفاده کنید. نتایج بازبینی کُد همراه بهبودبخشی‌ها در اینجا http://phpfi.com/220302 می‌باشند -- Heiner. متأسفانه به نظر می‌رسد اکنون آن URL منقضی گردیده است.). توجه نمایید که این وصله از syslog استفاده نمی‌کند. وصله به عدم اطلاع کاربر از فایل وقایع نگاری تکیه می‌کند.

جهت یک رویکرد جدی‌تر برای مشکلِ پیگیری آنچه کاربران شما انجام می‌دهند، به جای تمرکز روی پوسته‌ها، BSD process accounting2 (مبتنی بر کرنل) را در نظر بگیرید.


پرسش و پاسخ 77 (آخرین ویرایش ‎2013-01-23 06:08:01‎ توسط geirha)


  1. مترجم: chroot jail یک ویژگی یونیکس است که حالت محدودی از اجرای برنامه را ایجاد می‌کند، که در آن برنامه از داشتن دسترسی کامل به تمام سیستم ممانعت می‌شود و فقط اجازه دیدن محدوده‌ای از فایل سیستم را دارد. از این رو نوعی زندان تعبیر شده است. (بازگشت)

  2. مترجم: process accounting(گزارش پردازش) یک ویژگی گزارش‌گیری است که هنگام کامپایل کرنل می‌توان آن را فعال نمود (بسیاری از سیستم‌های لینوکس طوری پیکربندی گردیده‌اند که این ویژگی در آنها فعال می‌باشد. اما ممکن است در توزیع شما چنین نباشد، در صورتیکه بخواهید با کامپایل مجدد کرنل آن را فعال کنید گزینه مربوط به آن CON‐FIG_BSD_PROCESS_ACCT است. برای اطلاعات دقیق می‌توانید به این بخش از پروژه مستندات لینوکس مراجعه نمایید). اگر این ویژگی در کرنل فعال باشد آنوقت با استفاده از فراخوان سیستم acct می‌‌توان آغاز به کار آن را درخواست نمود، که باعث می‌شود کرنل از هر پردازشی که در سیستم خاتمه می‌یابد یک رکورد در فایل گزارش بنویسد. این رکورد شامل اطلاعاتی در باره پردازشهای اجرا شده (از جمله UID، GID، زمان ایجاد، مدت زمان استفاده از منابع سیستم و غیره) می‌باشد. البته فعال بودن این گزینه فضای قابل توجهی از دیسک را استفاده خواهد نمود(در سیستم‌های شلوغ به ازای هر ساعت تقریباً بیش از یک گیگا بایت)، اما این گزارش موارد استفاده مدیریتی بسیاری دارد که بیان آنها خارج از ظرفیت این صفحه است. (بازگشت)


نظرات 0 + ارسال نظر
ایمیل شما بعد از ثبت نمایش داده نخواهد شد