SUDO_LOGSRVD(8) System Manager's Manual SUDO_LOGSRVD(8)

sudo_logsrvd - دیمن سرور لاگ رویدادها و نشستهای sudo

sudo_logsrvd [-hnV] [-f file] [-R percentage]

sudo_logsrvd یک سرور لاگ با کارایی بالا است که لاگ‌های رویداد و ورودی/خروجی (I/O) را از sudo می‌پذیرد. می‌توان از آن برای پیاده‌سازی ثبت متمرکز لاگ‌های sudo استفاده کرد. این سرور دو حالت عملیاتی دارد: محلی (local) و بازفرست (relay). به‌طور پیش‌فرض، sudo_logsrvd لاگ‌ها را به صورت محلی ذخیره می‌کند، اما همچنین می‌تواند به‌گونه‌ای پیکربندی شود که آن‌ها را به سرور دیگری که از پروتکل sudo_logsrv.proto(5) پشتیبانی می‌کند، بازفرستد.

در صورت عدم بازفرست، ورودی‌های لاگ رویداد می‌توانند از طریق syslog(3) یا در یک فایل محلی ثبت شوند. لاگ‌های ورودی/خروجی که به صورت محلی توسط sudo_logsrvd ذخیره شده‌اند را می‌توان از طریق ابزار sudoreplay(8) به همان روشی که لاگ‌های تولیدشده مستقیم توسط پلاگین sudoers پخش می‌شوند، بازپخش کرد.

این سرور همچنین از شروع مجدد انتقال‌های قطع‌شدهٔ لاگ پشتیبانی می‌کند. برای تشخیص لاگ‌های ورودی/خروجی کامل از موارد ناقص، فایل زمان‌بندی (timing) لاگ ورودی/خروجی پس از تکمیل لاگ، به صورت فقط‌خواندنی تنظیم می‌شود.

پارامترهای پیکربندی برای sudo_logsrvd می‌توانند در فایل sudo_logsrvd.conf(5) یا فایلی که از طریق گزینهٔ -f مشخص شده است، تعیین شوند.

sudo_logsrvd هنگام دریافت سیگنال SIGHUP فایل پیکربندی خود را دوباره می‌خواند و در زمان دریافت سیگنال SIGUSR1 وضعیت سرور را در فایل اشکال‌زدایی (در صورت پیکربندی شدن) می‌نویسد.

گزینه‌ها به شرح زیر هستند:

file, --file=file
خواندن پیکربندی از file به جای فایل پیش‌فرض، /etc/sudo_logsrvd.conf.
, --help
نمایش یک پیام راهنمای کوتاه در خروجی استاندارد و خروج.
, --no-fork
اجرای sudo_logsrvd در پیش‌زمینه، به جای جدا شدن از ترمینال و تبدیل شدن به یک دیمن.
percentage, --random-drop=percentage
برای هر پیام، به احتمال percentage درصد، سرور اتصال را قطع خواهد کرد. این گزینه فقط برای اشکال‌زدایی از قابلیت کلاینت در شروع مجدد اتصال در نظر گرفته شده است.
, --version
چاپ نسخهٔ sudo_logsrvd و خروج.

داده‌های لاگ ورودی/خروجی ارسال‌شده به sudo_logsrvd ممکن است حاوی اطلاعات حساسی مانند گذرواژه‌ها باشند و باید با استفاده از امنیت لایهٔ انتقال (TLS) ایمن شوند. انجام این کار مستلزم داشتن یک گواهی امضاشده روی سرور است و اگر در sudo_logsrvd.conf(5) فعال باشد، وجود یک گواهی امضاشده روی کلاینت نیز الزامی خواهد بود.

گواهی‌ها می‌توانند توسط یک مرجع صدور گواهی (CA) شناخته‌شده امضا شوند، یا می‌توان از یک CA خصوصی استفاده کرد. دستورالعمل‌های ایجاد یک CA خصوصی در زیر در بخش مثالها (EXAMPLES) آمده است.

sudo_logsrvd از یک چارچوب اشکال‌زدایی انعطاف‌پذیر پشتیبانی می‌کند که از طریق خطوط در فایل sudo.conf(5) پیکربندی می‌شود.

برای اطلاعات بیشتر در مورد پیکربندی sudo.conf(5) ، به راهنمای آن مراجعه کنید.

/etc/sudo.conf
پیکربندی پیشانهٔ Sudo
/etc/sudo_logsrvd.conf
فایل پیکربندی سرور لاگ Sudo
/var/log/sudo_logsrvd/incoming
دایرکتوری محل ذخیرهٔ ژورنال‌های جدید هنگامی که تنظیم store_first relay فعال است.
/var/log/sudo_logsrvd/outgoing
دایرکتوری محل ذخیرهٔ ژورنال‌های تکمیل‌شده هنگامی که تنظیم store_first relay فعال است.
/var/log/sudo-io
محل پیش‌فرض فایل‌های لاگ ورودی/خروجی
/run/sudo/sudo_logsrvd.pid
فایل شناسهٔ فرآیند (PID) برای sudo_logsrvd

مگر اینکه از گواهی‌های امضاشده توسط یک مرجع صدور گواهی (CA) معتبر (یا یک CA سازمانی محلی) استفاده کنید، باید CA اختصاصی خود را بسازید تا بتواند گواهی‌های مورد استفادهٔ sudo_logsrvd, sudo_sendlog و پلاگین sudoers را امضا کند. مراحل زیر از دستور openssl(1) برای ایجاد کلیدها و گواهی‌ها استفاده می‌کنند.

ابتدا باید ساختار دایرکتوری مناسب برای ذخیرهٔ فایل‌های CA ایجاد کنیم. بدین منظور یک سلسله‌مراتب دایرکتوری جدید در /etc/ssl/sudo ایجاد خواهیم کرد.

# mkdir /etc/ssl/sudo
# cd /etc/ssl/sudo
# mkdir certs csr newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial

فایل‌های serial و index.txt برای پیگیری گواهی‌های امضاشده استفاده می‌شوند.

سپس باید یک رونوشت از فایل openssl.cnf تهیه کرده و آن را برای CA جدید خود سفارشی‌سازی کنیم. مسیر openssl.cnf وابسته به سیستم است، اما /etc/ssl/openssl.cnf رایج‌ترین مکان آن است. اگر این فایل در سیستم شما مسیر متفاوتی دارد، باید مثال زیر را تنظیم کنید.

# cp /etc/ssl/openssl.cnf .

اکنون فایل openssl.cnf موجود در دایرکتوری فعلی را ویرایش کرده و اطمینان حاصل کنید که شامل بخش‌های “ca ،” “CA_default ،” “v3_ca” و “usr_cert” باشد. این بخش‌ها باید دست‌کم تنظیمات زیر را در بر داشته باشند:

[ ca ]
default_ca              = CA_default

[ CA_default ]
dir                     = /etc/ssl/sudo
certs                   = /certs
database                = /index.txt
certificate             = /cacert.pem
serial                  = /serial

[ v3_ca ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
basicConstraints        = critical,CA:true
keyUsage                = cRLSign, keyCertSign

[ usr_cert ]
basicConstraints        = CA:FALSE
keyUsage                = nonRepudiation, digitalSignature, \
                          keyEncipherment
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid,issuer

اگر فایل openssl.cnf شما از قبل دارای بخش “CA_default” است، ممکن است فقط نیاز به تغییر تنظیم “dir” و فعال‌سازی تنظیمات “keyUsage” (در صورتی که کامنت شده باشند) داشته باشید.

به منظور ایجاد و امضای گواهی‌های اختصاصی خود، باید یک کلید خصوصی و یک گواهی برای ریشهٔ CA بسازیم. ابتدا کلید خصوصی را ایجاد کرده و با یک عبارت عبور (passphrase) از آن محافظت می‌کنیم:

# openssl genrsa -aes256 -out private/cakey.pem 4096
# chmod 400 private/cakey.pem

سپس گواهی ریشه را با مقادیر مناسب برای فیلدهای خاص سایت تولید می‌کنیم:

# openssl req -config openssl.cnf -key private/cakey.pem \
    -new -x509 -days 7300 -sha256 -extensions v3_ca \
    -out cacert.pem

Enter pass phrase for private/cakey.pem:
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank.
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Colorado
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgets Pty Ltd]:sudo
Organizational Unit Name (eg, section) []:sudo Certificate Authority
Common Name (e.g., server FQDN or YOUR name) []:sudo Root CA
Email Address []:

# chmod 444 cacert.pem

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

# openssl x509 -noout -text -in cacert.pem

گواهی‌های سرور و کلاینت توسط CA ریشه‌ای که پیش‌تر ایجاد شد، امضا خواهند شد. معمولاً از CA ریشه برای امضای مستقیم گواهی‌های سرور/کلاینت استفاده نمی‌شود. در عوض، گواهی‌های میانی (intermediate) ایجاد شده و با CA ریشه امضا می‌شوند، و از این گواهی‌های میانی برای امضای درخواست‌های امضای گواهی (CSR) استفاده می‌گردد. در این مثال برای سادگی از این بخش صرف‌نظر کرده و CSRها را مستقیماً با CA ریشه امضا می‌کنیم.

ابتدا کلید خصوصی را بدون عبارت عبور تولید می‌کنیم.

# openssl genrsa -out private/logsrvd_key.pem 2048
# chmod 400 private/logsrvd_key.pem

سپس یک درخواست امضای گواهی (CSR) برای گواهی سرور ایجاد می‌کنیم. نام سازمان (organization name) باید دقیقاً با نام ذکرشده در گواهی ریشه یکسان باشد. نام مشترک (common name) باید یا نشانی IP سرور باشد یا یک نام دامنهٔ کاملاً واجد شرایط (FQDN).

# openssl req -config openssl.cnf -key private/logsrvd_key.pem -new \
    -sha256 -out csr/logsrvd_csr.pem

Enter pass phrase for private/logsrvd_key.pem:
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank.
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Colorado
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgets Pty Ltd]:sudo
Organizational Unit Name (eg, section) []:sudo log server
Common Name (e.g., server FQDN or YOUR name) []:logserver.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

اکنون CSR ایجادشده را امضا می‌کنیم:

# openssl ca -config openssl.cnf -days 375 -notext -md sha256 \
    -in csr/logsrvd_csr.pem -out certs/logsrvd_cert.pem

Using configuration from openssl.cnf
Enter pass phrase for ./private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4096 (0x1000)
        Validity
            Not Before: Nov 11 14:05:05 2019 GMT
            Not After : Nov 20 14:05:05 2020 GMT
        Subject:
            countryName               = US
            stateOrProvinceName       = Colorado
            organizationName          = sudo
            organizationalUnitName    = sudo log server
            commonName                = logserve.example.com
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Key Identifier:
                4C:50:F9:D0:BE:1A:4C:B2:AC:90:76:56:C7:9E:16:AE:E6:9E:E5:B5
            X509v3 Authority Key Identifier:
                keyid:D7:91:24:16:B1:03:06:65:1A:7A:6E:CF:51:E9:5C:CB:7A:95:3E:0C

Certificate is to be certified until Nov 20 14:05:05 2020 GMT (375 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

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

# openssl verify -CAfile cacert.pem certs/logsrvd_cert.pem
certs/logsrvd_cert.pem: OK

دایرکتوری /etc/ssl/sudo/certs اکنون شامل یک گواهی امضاشده و تأییدشده برای استفاده با sudo_logsrvd است.

برای تولید گواهی کلاینت، فرآیند بالا را با نام فایلی متفاوت تکرار کنید.

جهت استفاده از TLS برای ارتباط کلاینت/سرور، هم sudo_logsrvd و هم پلاگین sudoers باید برای استفاده از TLS پیکربندی شوند. با فرض استفاده از همان مسیرهای نام‌برده‌شده در مراحل قبل، پیکربندی sudo_logsrvd برای TLS نیازمند تنظیمات زیر است:

# Listen on port 30344 for TLS connections to any address.
listen_address = *:30344(tls)

# Path to the certificate authority bundle file in PEM format.
tls_cacert = /etc/ssl/sudo/cacert.pem

# Path to the server's certificate file in PEM format.
tls_cert = /etc/ssl/sudo/certs/logsrvd_cert.pem

# Path to the server's private key file in PEM format.
tls_key = /etc/ssl/sudo/private/logsrvd_key.pem

گواهی CA ریشه (cacert.pem) باید روی سیستمی که sudo_logsrvd را اجرا می‌کند نصب شده باشد. اگر احراز هویت همتا (peer authentication) در کلاینت فعال باشد، یک نسخه از cacert.pem باید در سیستم کلاینت نیز موجود باشد.

sudo.conf(5), sudo_logsrv.proto(5), sudo_logsrvd.conf(5), sudoers(5), sudo(8), sudo_sendlog(8), sudoreplay(8)

افراد بسیاری در طول سال‌ها روی sudo کار کرده‌اند؛ این نگارش عمدتاً از کدهای نوشته‌شده توسط شخص زیر تشکیل شده است:

Todd C. Miller

برای مشاهدهٔ فهرست کامل افرادی که در sudo مشارکت داشته‌اند، فایل CONTRIBUTORS.md را در توزیع sudo (https://www.sudo.ws/about/contributors) ببینید.

اگر فکر می‌کنید باگی در sudo_logsrvd یافته‌اید، می‌توانید گزارش باگ را در پایگاه دادهٔ باگ sudo در https://bugzilla.sudo.ws ثبت کنید یا یک issue در https://github.com/sudo-project/sudo/issues باز نمایید. اگر ترجیح می‌دهید از ایمیل استفاده کنید، پیام‌ها می‌توانند به لیست پستی sudo-workers در https://www.sudo.ws/mailman/listinfo/sudo-workers (عمومی) یا <sudo@sudo.ws> (خصوصی) ارسال شوند.

لطفاً آسیب‌پذیری‌های امنیتی را از طریق issueهای عمومی گیت‌هاب، Bugzilla یا لیست‌های پستی گزارش ندهید. در عوض، آن‌ها را از طریق ایمیل به <Todd.Miller@sudo.ws> ارسال نمایید. در صورت تمایل می‌توانید پیام خود را با استفاده از کلید PGP موجود در https://www.sudo.ws/dist/PGPKEYS رمزگذاری کنید.

پشتیبانی رایگان محدود از طریق لیست پستی کاربران sudo در دسترس است؛ برای عضویت یا جستجو در آرشیو نشانی https://www.sudo.ws/mailman/listinfo/sudo-users را ببینید.

sudo_logsrvd به‌صورت “همان‌گونه که هست” (AS IS) ارائه می‌شود و هرگونه ضمانت صریح یا ضمنی، شامل و نه محدود به ضمانت‌های ضمنی خریدوفروش و تناسب برای یک هدف خاص، سلب می‌شود. برای جزئیات کامل، فایل LICENSE.md توزیع‌شده با sudo یا نشانی https://www.sudo.ws/about/license را ملاحظه فرمایید.

July 14, 2024 Sudo 1.9.17p2