ورودهای سیستم یک جزء بسیار مهم مدیریت سیستمهای لینوکس است. چرا که بینشی ارزشمند از نحوه کار سیستم ها و همچنین نحوه استفاده از آنها ارائه می دهد زیرا علاوه بر خطاها ، اطلاعات عملیاتی مانند رخدادهای امنیتی را ضبط می کنند. پیکربندی استاندارد برای سیستم های لینوکس این است که ورودهای مربوط به آنها را بصورت محلی در همان سیستمی که در آن رخ داده است ذخیره کنیم. این برای سیستم های مستقل کار می کند اما با افزایش تعداد سیستم به سرعت مشکل ایجاد می شود. راه حل مدیریت همه این ورودها ایجاد یک سرور مجازی متمرکز ورود به سیستم است که در آن هر میزبان لینوکس ورودهای خود را در زمان واقعی به یک سرور اختصاصی مدیریت ورودها ارسال می کند.
شیوه متمرکز ورود به سیستم مزایای مختلفی را در مقایسه با ذخیره ورودهای مربوط به هر میزبان ارائه می دهد:
• مقدار فضای دیسک مورد نیاز هر میزبان را برای ذخیره فایل های log کاهش می دهد.
• ورودها را می توان طولانی تر نگه داشت زیرا سرور مجازی اختصاصی ورود با ظرفیت ذخیره سازی بیشتر می تواند پیکربندی شود.
• تجزیه و تحلیل پیشرفته ورود به سیستم می تواند انجام شود که به ورودهای مربوط به چندین سیستم و همچنین منابع محاسبه شده تر از آنچه ممکن است در هاست موجود باشد ، نیاز دارد.
• ادمین های سیستم ها می توانند به دلایل امنیتی به طور مستقیم وارد سیستم خود شوند که ممکن است در شرایط دیگر نتوانند مستقیماً وارد گردند.
در این راهنما ، یک مولفه از مجموعه سیستمی ابزارها را برای وابسته کردن پیامهای ورود از سیستمهای کلاینت به یک سرور مجازی جمع آوری متمرکز پیکربندی می کنید. شما سرور مجازی و کلاینت را تنظیم می كنید تا از گواهینامه های TLS برای رمزگذاری پیام های ورود استفاده كنند زیرا آنها در شبکه های ناامن مانند اینترنت و همچنین برای احراز هویت یكدیگر منتقل می شوند.
پیش نیازها
قبل از شروع این راهنما به موارد زیر نیاز خواهید داشت:
• دو سرور مجازی Ubuntu 20.04.
• یک کاربر غیر ریشه با امتیازات sudo در هر دو سرور مجازی. برای راهنمایی در مورد نحوه انجام این کار ، راهنمای ستاپ اولیه سرور مجازی برای اوبونتو 20.04 را دنبال کنید. همچنین باید همانطور که در راهنمای توضیح داده شده است ، فایروال UFW را در هر دو سرور پیکربندی کنید.
• دو نام هاست که به سرور مجازی های شما اشاره می کنند. یک نام هاست برای سیستم کلاینت است که ورودها را تولید می کند و دیگری برای سرور مجازی جمع آوری ورودها.
این راهنما از دو نام هاست مثال زیر استفاده خواهد کرد:
client.your_domain: سیستم کلاینت که ورودها را تولید می کند.
server.your_domain: سرور مجازی جمع آوری log.
برای شروع این آموزش به کلاینت و سرور مجازی در ترمینال های جداگانه از طریق SSH وارد شوید.
توجه: در سرتاسر این آموزش، بلوکهای دستوری با نام سرور مجازی (کلاینت یا سرور مجازی ) برچسب گذاری می شود که دستور باید روی آن اجرا شود.
مرحله 1 – نصب systemd-journal-remote
در این مرحله بسته systemd-magazine-Remote را بر روی کلاینت و سرور مجازی نصب خواهید کرد. این بسته شامل مؤلفه هایی است که کلاینت و سرور مجازی برای وابسته کردن پیام های ورود به سیستم از آنها استفاده می کنند.
ابتدا ، هم در کلاینت و هم سرور مجازی ، یک بروزرسانی سیستم اجرا کنید تا از وجود بانک اطلاعاتی بسته و سیستم اطمینان حاصل شود:
Client and Server
$ sudo apt update

$ sudo apt upgrade

در مرحله بعد ، بسته systemd-journal-remote را نصب کنید:
Client and Server
$ sudo apt install systemd-journal-remote

در سرور مجازی ، دو مؤلفه سیستمی مورد نیاز خود را برای دریافت پیام های ورود به سیستم با استفاده از دستور زیر فعال و راه اندازی کنید:
Server
$ sudo systemctl enable –now systemd-journal-remote.socket

$ sudo systemctl enable systemd-journal-remote.service

گزینه –now در دستور اول سرویس ها را فوراً شروع می کند. در دستور دوم از آن استفاده نکردید زیرا این سرویس تا زمانی که دارای گواهینامه TLS نباشد ، شروع نمی شود ، که در مرحله بعدی ایجاد خواهید کرد.
روی کلاینت ، مؤلفه ای که از systemd  استفاده می کند را برای ارسال پیام های ورود به سرور مجازی فعال کنید:
Client
$ sudo systemctl enable systemd-journal-upload.service

در مرحله بعد ، روی سرور مجازی ، پورت های 19532 و 80 را در فایروال UFW باز کنید. با این کار سرور مجازی می تواند پیام های ورود به سیستم را از کلاینت دریافت کند. پورت 80 پورتي است كه از certbot براي توليد گواهينامه TLS استفاده خواهد كرد. دستورات زیر، این پورت ها را باز می کنند:
Server
$ sudo ufw allow in 19532/tcp

$ sudo ufw allow in 80/tcp
روی کلاینت ، شما فقط باید پورت 80 را با این دستور باز کنید:
Client
$ sudo ufw allow in 80/tcp

اکنون اجزای مورد نیاز را نصب کرده اید و پیکربندی سیستم پایه را روی کلاینت و سرور مجازی تکمیل کرده اید. قبل از اینکه بتوانید این مؤلفه ها را برای شروع رله پیام های ورود به سیستم پیکربندی کنید ، مجوزهای  Let’s Encrypt TLS را برای کلاینت و سرور مجازی با استفاده از ابزار certbot ثبت می کنید.
مرحله 2 – نصب Certbot و ثبت گواهینامه ها
Let’s Encrypt مجوزی است که مجوزهای TLS رایگان صادر می کند. این گواهینامه ها به رایانه ها اجازه می دهد داده هایی را که بین آنها می فرستند رمزگذاری کنند و هویت یکدیگر را نیز بررسی کنند. این گواهینامه ها همان چیزی هستند که به شما امکان می دهند جستجوی اینترنتی خود را با HTTPS تضمین کنید. از همان گواهینامه ها می توانید توسط هر برنامه دیگری که همان سطح امنیتی را می خواهد استفاده کرد. روند ثبت گواهینامه ها یکسان است و مهم نیست از آنها برای چه چیزی استفاده میشود.
در این مرحله ، ابزار certbot را نصب کرده و از آن برای ثبت گواهینامه ها استفاده می کنید. همچنین به طور خودکار از تمدید گواهینامه ها هنگام انقضا مراقبت خواهد کرد. مراحل ثبت نام در اینجا مشابه کلاینت و سرور مجازی است. شما فقط باید نام میزبان را تغییر دهید تا با میزبانی که در آن فرمان ثبت دارید مطابقت داشته باشید.
ابتدا ، مخزن جهانی Ubuntu را فعال کنید چرا که ابزار جهانی certbot در مخزن جهانی اوبونتو قرار گرفته است . اگر قبلاً مخزن جهانی را فعال کرده باشید ، اجرای این دستورات کاری با سیستم شما نخواهد داشت و اجرای آن بی خطر است:
Client and Server
$ sudo apt install software-properties-common

$ sudo add-apt-repository universe

$ sudo apt update

سپس ، هر دو هاست certbot را نصب کنید:
Client and Server
$ sudo apt install certbot

اکنون certbot را نصب کرده اید ، دستور زیر را برای ثبت گواهینامه ها در کلاینت و سرور مجازی اجرا کنید:
Client and Server
$ sudo certbot certonly –standalone –agree-tos –email sammy@your_domain -d your_domain

گزینه های موجود در این دستور به شرح زیر است:
certonly: گواهی را ثبت میکند و هیچ تغییری در سیستم ایجاد نمیکند.
–standalone: ​​برای تأیید درخواست گواهی از سرور مجازی داخلی certbot استفاده میکند.
–agree-tos: به طور خودکار با شرایط سرویس Let’s Encrypt موافقت می کند
name your_email–: آدرس ایمیلی است که Let’s Encrypt برای اطلاع به شما درمورد انقضا گواهینامه و سایر اطلاعات مهم استفاده می کند.
-d your_domain: نام میزبانی که گواهی نامه برای آن ثبت می شود. باید با سیستمی که شما آن را اجرا می کنید مطابقت داشته باشد.
وقتی این دستور را اجرا کردید از شما سؤال می شود که آیا می خواهید آدرس ایمیل را با Let’s Encrypt به اشتراک بگذارید تا بتوانند به شما خبر و اطلاعات دیگری در مورد کارشان ارسال کنند. انجام این کار اختیاری است ، اگر آدرس ایمیل خود را به اشتراک نگذارید ، ثبت نام گواهینامه همچنان به طور عادی کامل می شود.
پس از اتمام مراحل ثبت گواهینامه ، گواهی و فایل های اصلی را در / etc / letsencrypt / live / your_domain / قرار میگیرد، جایی که your_domain نام هاست شماست که گواهی را برای آن ثبت کرده اید.
در آخر باید یک نسخه از گواهی نامه های Let’s Encrypt’s CA و Let’s Encrypt’s واسطه را دانلود کرده و در همان فایل قرار دهید. journald از این فایل برای تأیید صحت گواهینامه های کلاینت و سرور مجازی هنگام برقراری ارتباط با یکدیگر استفاده می کند.
دستور زیر این دو گواهینامه را از وب سایت Let’s Encrypt دانلود می کند و آنها را در یک فایل واحد با نام letsencrypt-Combined-certs.pem در دیرکتوری هوم کاربر شما قرار می دهد.
برای دانلود گواهینامه ها و ایجاد فایل ترکیبی ، این دستور را روی کلاینت و سرور مجازی اجرا کنید:
Client and Server
$ curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.tx

در مرحله بعد ، این فایل را در دیرکتوری Let’s Encrypt که حاوی گواهینامه ها و کلیدها است ، انتقال دهید:
Client and Server
$ sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

اکنون گواهی ها و کلیدها را ثبت کرده اید. در مرحله بعد ، سرور مجازی جمع آوری ورودها را پیکربندی می کنید تا شروع به گوش دادن و ذخیره پیام های ورود به سیستم از کلاینت کنید.
مرحله 3 – پیکربندی سرور مجازی
در این مرحله ، سرور مجازی را پیکربندی می کنید تا از گواهی و فایلهای کلیدی که در آخرین مرحله تولید کرده اید ، استفاده کند تا بتواند شروع به پذیرش پیام های ورود به سیستم از کلاینت کند.
systemd-journal-remote مؤلفه ای است که به پیام های ورود به سیستم گوش می دهد. فایل پیکربندی خود را در /etc/systemd/journal-remote.conf با یک ویرایشگر متن باز کنید تا پیکربندی آن در سرور مجازی شروع شود:
$ sudo nano /etc/systemd/journal-remote.conf

در مرحله بعد ، تمام خطوط را در قسمت [Remote] لغو کنید و مسیرها را برای اشاره به فایل های TLS که اخیراً ایجاد کرده اید تنظیم کنید:
/etc/systemd/journal-remote.conf
[Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combin

گزینه هایی که در اینجا استفاده کرده اید به این شرح است:
Seal = false: داده های ورود به سیستم را در ژورنال امضا میکند. اگر به امنیت حداکثر نیاز دارید ، این گزینه را فعال کنید؛ در غیر این صورت ، می توانید آن را به صورت false رها کنید.
SplitMode = host: ورود های مربوط به کلاینت از راه دور توسط هاست در /var/log/journal/remote تقسیم می شوند. اگر ترجیح می دهید تمام ورودهای مربوط به یک فایل اضافه شوند ، این را روی SplitMode = false قرار دهید.
ServerKeyFile: فایل کلید خصوصی سرور مجازی.
ServerCertificateFile: فایل گواهی سرور مجازی.
TrustedCertificateFile: فایل حاوی گواهی نامه های Let’s Encrypt CA.
حال باید مجوزها را در دایرکتوری های Let’s Encrypt که حاوی گواهی نامه ها و کلید هستند تغییر دهید تا systemd-journal-remote بتواند آنها را بخواند و از آنها استفاده کند.
ابتدا مجوزها را تغییر دهید تا گواهی و کلید خصوصی قابل خواندن باشد:
$ sudo chmod 0755 /etc/letsencrypt/{live,archive}

$ sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

در مرحله بعد ، مالکیت گروهی کلید خصوصی را به گروه systemd-journal-remote تغییر دهید:
$ sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

اکنون می توانید systemd-journal-remote را شروع کنید
$ sudo systemctl start systemd-journal-remote.service

سرور مجازی مجموعه ورود به سیستم شما اکنون در حال اجرا و آماده پذیرش پیام های ورود به سیستم از یک کلاینت است. در مرحله بعد ، کلاینت را پیکربندی می کنید تا ورود ها را به سرور مجازی مجموعه خود منتقل کند.
مرحله 4 – پیکربندی کلاینت
در این مرحله ، مؤلفه ای که پیام ها را به سرور مجازی جمع آوری log مرتبط می کند ، پیکربندی می کنید. به این مؤلفه systemd-magazine-upload گفته می شود.
پیکربندی پیش فرض برای systemd-journal-upload این است که از یک کاربر موقتی استفاده می کند که فقط در حین انجام روند وجود دارد. این امر باعث می شود که systemd-journal-upload بتواند گواهی نامه ها و کلیدهای TLS را پیچیده تر بخواند. برای حل این مشکل شما یک کاربر سیستم جدید با همان نام کاربر موقت که به صورت جایگزین استفاده میشود، ایجاد می کنید.
ابتدا کاربر جدیدی بنام systemd-journal-upload را با دستور adduser زیر در کلاینت ایجاد کنید:
sudo adduser –system –home /run/systemd –no-create-home –disabled-login –group systemd-journal-upload

این گزینه ها در دستور عبارتند از:
–system: کاربر جدید را به عنوان کاربر سیستم ایجاد کنید. به کاربر UID (شناسه کاربر) زیر 1000 را می دهد. شناسه های بزرگتر از 1000 معمولاً به حسابهای کاربری داده می شود که یک انسان برای ورود به سیستم از آنها استفاده می کند.:
–home /run/system: –run/systemd را به عنوان دیرکتوری اصلی این کاربر تنظیم میکند.
–no-create-home : مجموعه دیرکتوری هوم را آنگونه که از قبل موجود است ، ایجاد نمیکند.
–disabled-login: کاربر نمی تواند از طریق SS ، به عنوان مثال SS وارد سرور مجازی شود
–group: گروهی را با همان نام کاربری ایجاد میکند.
سپس ، مجوزها و مالکیت فایل های گواهی نامه رمزگذاری شده را تنظیم کنید:
$ sudo chmod 0755 /etc/letsencrypt/{live,archive}

$ sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem

$ sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

اکنون پیکربندی مربوط به systemd-journal-upload را که در /etc/systemd/journal-upload.conf است ، ویرایش کنید. این فایل را با ویرایشگر متن باز کنید:
$ sudo systemctl restart systemd-journal-upload.service

این فایل را طوری ویرایش کنید که به شکل زیر باشد:
/etc/systemd/journal-upload.conf
[Upload]
URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-cer

سرانجام ، سرویس systemd-journal-upload را مجدداً راه اندازی کنید تا از تنظیمات جدید استفاده کند:
$ sudo systemctl restart systemd-journal-upload.service

کلاینت شما اکنون تنظیم و راه اندازی شده است و پیامهای ورود به سیستم را به سرور مجازی جمع آوری ورود ارسال می کند. در مرحله بعد ، بررسی می کنید که ورودها به درستی ارسال و ضبط می شوند.
مرحله 5 – آزمایش کلاینت و سرور مجازی
در این مرحله ، آزمایش خواهید کرد که کلاینت در حال انتقال پیام های ورود به سرور مجازی است و اینکه سرور به طور صحیح آنها را ذخیره می کند.
سرور مجازی جمع آوری ، ورودهای مربوط به کلاینت را در یک دیرکتوری در /var/log/journal/remote/ ذخیره می کند. هنگامی که کلاینت را در انتهای آخرین مرحله ریستارت کردید ، شروع به ارسال پیام های ورود به سیستم می کند ، بنابراین اکنون یک فایل ورود به سیستم در /var/log/journal/remoteوجود دارد. این فایل با نام میزبانی که برای گواهی TLS از آن استفاده کرده اید ، نامگذاری می شود.
از دستور ls برای بررسی وجود فایل ورود کلاینت روی سرور مجازی استفاده کنید:
Server
$ sudo ls -la /var/log/journal/remote/
با این کار محتوای دایرکتوری که فایل ورود را نشان می دهد چاپ می شود:
Output
total 16620
drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 .
drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 ..
-rw-r—– 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 ‘remote-CN=client.your_domain’

در مرحله بعد ، یک پیام ورود به سیستم را برای کلاینت بنویسید تا بررسی کنید که سرور مجازی همانطور که انتظار دارید پیامهای کلاینت را دریافت می کند. برای ایجاد پیام ورود به سیستم بر روی کلاینت از ابزار logger استفاده خواهید کرد. اگر همه چیز کار می کند systemd-magazine-upload این پیام را به سرور مجازیمنتقل می کند.
روی کلاینت دستور logger زیر را اجرا کنید:
Client
$ sudo logger -p syslog.debug “### TEST MESSAGE from client.your_domain ###”

-p syslog.debug در این دستور امکانات و شدت پیام را تعیین می کند. تنظیم این گزینه در syslog.debug ، مشخص خواهد کرد که این یک پیام آزمایشی است. این دستور پیام ### TEST MESSAGE from client.your_domain ### را از ژورنال کلاینت ضبط می کند ، که سپس systemd-journal-upload به سرور مرتبط می نماید.
در مرحله بعدی ، فایل ژورنال کلاینت را روی سرور بخوانید تا بررسی کنید که پیام های ورود به سیستم از کلاینت دریافت می کنند. این فایل یک فایل ورود binary است بنابراین قادر نخواهید بود آن را با ابزارهایی مانند less بخوانید. در عوض ، فایل را با استفاده از Journalctl با گزینه –file = که به شما امکان می دهد یک فایل ژورنال اختصاصی را مشخص کنید ، بخوانید:
Server
$ sudo journalctl –file=/var/log/journal/remote/remote-CN=client.your_domain.journal

پیام ورود به شرح زیر است:
Test log message
. . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

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

 

 

نحوه تنظیم برنامه Node.js برای تولید در اوبونتو 20.04

نحوه نصب وردپرس در اوبونتو 20.04 با پشته LAMP

نصب و پیکربندی Postfix به عنوان سرور SMTP به صورت Send-Only در اوبونتو 20.04

نحوه ایجاد یک گواهی SSL خود-امضا شده برای Apache در اوبونتو 20.04

نحوه متمرکز کردن ورود ها با Journald در اوبونتو 20.04

نحوه ایمن کردن Apache با Let’s Encrypt در Debian 9

نحوه نصب و ایمن سازی phpMyAdmin در Debian 9

نصب و پیکربندی Postfix به عنوان سرور SMTP به صورت Send-Only در Debian 9

نحوه نصب و پیکربندی Nextcloud در Debian 901

نحوه تنظیم Jupyter Notebook با پایتون 3 در Debian 9

 

 

خرید vps – خرید سرور مجازی – خرید سرور – سرور هلند – فروش vps – سرور مجازی آمریکا – خریدvps – سرور مجازی هلند – فروش سرور مجازی – سرور آمریکا – vps – سرور مجازی انگلیس – سرور مجازی آلمان – سرور مجازی کانادا – خرید vps آمریکا – خرید وی پی اس – سرور – خرید سرور مجازی هلند – vps خرید – سرور مجازی فرانسه – سرور مجازی هلند – خرید vps آمریکاخرید سرور مجازی ارزان هلندvpsخرید vps هلندخرید سرور مجازی آمریکاخرید vps فرانسهتست vpsسرور مجازی تستسرور مجازی ویندوزارزانترین vpsخرید وی پی اسvps ارزان – 

 

 

برچسب‌ها: