وقتی از یکی میشنوم که لاگ هاش زیاد بوده و هاردش رو پر کرده، اون هم لاگ ها رو پاک کرده اصلا تعجب نمیکنم.
معمولا ما نمیدونم با لاگ های سرور یا سرویسمون چی کار کنیم، توی این پست سعی میکنم بیشتر به ماهیت لاگ ها بپردازم، بعد هم درمورد نصب و راه اندازی یک سرویس مناسب برای مدیریت لاگ ها صحبت میکنم.
بطور معمول هر سیستم عاملی لاگ هایی رو تولید میکنه که داده هایی مثل ورود و خروج کاربران، تغییر تنظیمات، نیاز به بروز رسانی و خیلی موارد دیگه رو توش میشه پیدا کرد.
مثلا وقتی روی سیستم عامل لینوکس از طریق SSH لاگین میکنیم چنین لاگی توی سیستم ثبت میشه:
sshd[000]: Accepted publickey for masoud from 1.1.1.1 port 0000 ssh2: RSA SHA000:000000000
شاید لاگ مربوط به یه لاگین ساده مهم نباشه(!) ولی وقتی تلاش برای ورود به سرور توسط یک اتکر اتفاق می افته میتونه مهم باشه. لاگ هایی که روی سرور ثبت میشه این شکلی هست و میتونه به کار بیاد:
Apr 8 18:48:39 SERVER-000 sshd[0000]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=1.1.1.2 user=masoud
Apr 8 18:48:41 SERVER-000 sshd[0000]: Failed password for masoud from 1.1.1.2 port 0000 ssh2
Apr 8 18:48:47 SERVER-000 sshd[0000]: message repeated 2 times: [ Failed password for masoud from 1.1.1.2 port 0000 ssh2]
Apr 8 18:48:47 SERVER-000 sshd[0000]: Connection closed by 1.1.1.2 port 0000 [preauth]
Apr 8 18:48:47 SERVER-000 sshd[0000]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=1.1.1.2 user=masoud
چطوری باید این لاگ ها رو ببینیم و ازشون استفاده کنیم؟
ساده ترین روش این هست که با دستور tail انتهای لاگ رو بخونیم و منتظر باشیم که یه اتفاقی بیوفته!
tail -f /var/log/auth.log
تا زمانی که لاگ ها بصورت متمرکز روی سرورها هستند خیلی کاربردی و عملیاتی نخواهند بود.
مثلا تصو کنید اتکر سعی میکنه به سرور وصل بشه، بعد از مدتی تلاش موفق میشه و وارد سرورتون میشه، بعد شروع میکنه به پاک کردن لاگ ها و اصطلاحا ردپاش رو پاک میکنه.
بعدا که متوجه آسیب پذیری سرورتون میشید یا متوجه میشید از سرورتون سو استفاده شده، دیگه لاگی برای بررسی ندارید.
در نتیجه اولین قدم برای ثبت و نگهداری و پایش لاگ ها، انتقال اون ها به بیرون از سرورهاتون هست.
ضمنا با این روش دیگه هاردتون پر از لاگ نمیشه و میتونید بصورت دوره ای لاگ هایی که تحلیل کردید و به بیرون منتقل شده اند رو پاک کنید.
جمع آوری لاگ ها
معمولا داریم درمورد لاگ های بیش از یک سرور صحبت میکنیم، مثلا ۲ تا سرور!
مرحله اول باید به روشی لاگ ها رو از روی سرورها جمع آوری کنیم و بفرستیم به لاگ سرور مرکزی تا هم در جای مطمئنی قرار داشته باشه و هم بتونیم سریع تر و بصورت متمرکز و تجمیع شده لاگ ها رو بررسی کنیم.
به این ابزارها Log Shipper میگن:
این ابزارها بسیار متنوع هستند و مهمترین دلیل انتخاب اون ها میتونه این موارد باشه:
روی ویندوز و لینوکس به راحتی میتونید rsyslog رو نصب کنید تا لاگ های سیستمی و با کمی تنظیمات، لاگ های سرویس هاتون رو به بیرون منتقل کنید.
ممکنه براساس نیازمندی انتخاب متفاوت باشه ولی در اصل کارکرد تاثیری نمیگذاره.
تنظمیات rsyslog ساده است:
vim /etc/rsyslog.conf ....
*.* @@graylog.company:514;RSYSLOG_SyslogProtocol23Format
با *.* داریم میگیم همه چیز رو بفرست به graylog.company پورت ۵۱۴ و در ادامه هم میگیم فرمت لاگ ها چطوری باشه. (جزییات این فرمت داخل RFC5424 هست)
ضمنا وقتی ۲ تا @ میگذاریم یعنی پورت مقصد TCP هست، یک دونه هم باشه یعنی UDP هست.
فرق TCP و UDP توی چیه؟ زمانی که پورت مقصد UDP لاگ ارسال میکنید، ممکنه به هر دلیلی لاگ ها به مقصد نرسه. اینطوری دیگه سرور تلاش نمیکنه دوباره ارسال کنه و لاگ بعدی رو میفرسته، ممکنه به دلیل قطعی شبکه یا اختلات دیگه لاگ هایی رو به لاگ سرور ارسال نکنید.
تا اینجا روی سرور تنظیم کردیم که همه لاگ هایی که توسط syslog هندل میشه رو ارسال کنه به مقصد graylog.company، بریم سراغ نصب و راه اندازی graylog که بتونه لاگ ها رو دریافت و ذخیره کنه.
لاگ سرور مرکزی
ابزار پیشنهادی برای مکانیزم دریافت و ذخیره لاگ، برای شرکت های کوچک تا متوسط Graylog هست.
این ابزار توی محیط عملیاتی که پیاده سازی کردم تونسته تا 600k لاگ بر ثانیه رو بصورت زنده و realtime هندل کنه و از 600k لاگ تا 1m لاگ بر ثانیه رو با تاخیر حتی تا ۱۰ دقیقه بهم نمایش داده.
بیشترین لاگ ارسالی 1.2m لاگ بر ثانیه بوده که به دلیل خطای Elasticsearch سرویس متوقف شده.
پیشنهاد نمیکنم برای بیش از ۱ میلیون لاگ در ثانیه از Graylog استفاده بشه، برای چنین محیط هایی باید از ابزارهای Queuing مثل Kafka استفاده کرد، حتی برای ذخیره لاگ ها هم دیگه Elasticsearch مناسب نیست و ابزارهایی مثل ClickHouse باید استفاده بشه.
این آدرس سایت گری لاگ هست و در این آدرس هم میتونید تمام مستندات مربوط به Graylog رو مطالعه کنید.
مدل ها و معماری های متنوعی برای راه اندازی گری لاگ میشه طراحی و پیاده سازی کرد. توی این آدرس دو مدل طراحی رو داره توضیح میده.
مدل ساده:
خیلی ساده میگه یک پروسه گری لاگ هست که لاگ ها رو دریافت میکنه و به سرویس های مونگو و الستیک وصل میشه و لاگ ها رو اون جا ذخیره میکنه و در نهایت ادمین هم میتونه با مرورگر به همون پروسه اصلی گری لاگ وصل بشه و لاگ ها رو مشاهده کنه.
یعنی کل سرویس رو میشه روی یک سرور با ۳ پروسه گری لاگ، مونگو و الستیک پیاده سازی کرد.
حالا یک مدل پیچیده تر هم طراحی کرده که به اینصورت هست:
توی این مدل یک لودبالانسر (مثل HAProxy) اضافه شده و بقیه پروسه ها یا سرویس ها بیشتر و البته کلاستر شدند.
مثلا کلاستر ۳ تایی از مونگو راه اندازی شده و الستیک هم بصورت کلاستر راه اندازی شده.
پروسه اصلی گری لاگ هم چند تا در نظر گرفته شده و درخواست ها از طریق لودبالانسر روی اون ها تقسیم میشند.
اینکه کدوم مدل رو باید راه اندازی کرد میتونه به عوامل زیر بستگی داشته باشه:
در ادامه نصب مدل ساده رو با هم بررسی میکنیم.
نصب Graylog
روش های نصب گری لاگ متنوع هست، از سورس گرفته تا OVA میشه سرویس رو راه اندازی کرد، توی این مسیر روش های مختلف نصب وجود داره.
اینجا روش نصب گری لاگ از طریق داکر رو دنبال میکنیم، ابتدا داکر رو نصب میکنیم و دسترسی به مخازن رو تنظیم میکنیم و بعد با این دستورات کانتینرها رو نصب و راه اندازی میکنیم.
docker run --name mongo -d mongo:3 docker run --name elasticsearch \ -e "http.host=0.0.0.0" \ -e "ES_JAVA_OPTS=-Xms512m -Xmx512m" \ -d docker.elastic.co/elasticsearch/elasticsearch-oss:6.6.1 docker run --name graylog --link mongo --link elasticsearch \ -p 9000:9000 -p 514:514 \ -e GRAYLOG_HTTP_EXTERNAL_URI="http://graylog.company:9000/" \ -e GRAYLOG_ROOT_PASSWORD_SHA2=8c6000000 -d graylog/graylog:3.0
تقریبا واضح هست، اولی که مونگو رو نصب میکنه
دومین دستور هم الستیک رو با ظرفیت مموری ۵۱۲ مگ اجرا میکنه (نسخه مهم هست)
سومین دستور هم گری لاگ رو راه اندازی میکنه و مونگو و الستیک رو هم بهش لینک میکنه.
توی دستور سوم ۲ تا گزینه برای تنظیمات هم هست که با اولی میشه نقطه دسترسی رو تنظیم کرد و با بخش دوم میشه برای کاربر ادمین پسورد تنظیم کرد.
برای تنظیم پسورد باید Hash SHA2 ایجاد کنیم، با این دستور میتونید Hash رو بسازید:
echo -n "Enter Password: " && head -1 </dev/stdin | tr -d '\n' | sha256sum | cut -d" " -f1
الان باید با دستور docker ps بتونید کانتینرها رو ببینید و با دستور netstat -ntlp هم میتونید پورت های Listen شده رو ببینید.
میشه تمام این دستورات و تنظیمات داکر رو توی docker-compose.yml قرار بدیم تا بهتر بشه سرویس رو مدیریت کنیم.
درضمن کلی تنظیمات برای گری لاگ وجود داره که توی این لینک نحوه تنظیمات رو گفته که ممکنه به کار بیاد.
اگر خیلی جدی تر خواستید داکرتون رو تنظیم کنید، توی این لینک هم میتونید تنظیمات مربوط به Persisting Data و جدا کردن استوریج سرویس رو ببینید.
حالا سرویستون روی پورت ۹۰۰۰ دردسترس هست، میتونید توی مروگر آدرس سرور و پورت ۹۰۰۰ رو بزنید و به سرویس لاگین کنید.
تنظیمات Input گری لاگ
توی تنظیمات سرور گفتم که لاگ ها رو با rsyslog میفرستیم سمت graylog.company پورت TCP 514،
حالا لاگ سرور بالاست ولی هنوز روی پورت ۵۱۴ Listen نمیکنه، برای اینکار مطمئن بشید که توی دستور داکر مربوط به اجرای گری لاگ، حتما پورت ۵۱۴ Expose شده باشه.
داخل پنل از طریق منوی System گزینه Inputs رو انتخاب میکنیم.
از داخل لیست Inputs موارد syslog رو میخوایم انتخاب کنیم:
اون گزینه Syslog TCP رو انتخاب میکنیم و Launch رو میزنیم:
فقط کافیه Global رو انتخاب و یک Title بهش بدید:
درنهایت هم روی گزینه Save کلیک کنید.
الان سرویس گری لاگ روی پورت TCP 514 داره Listen میکنه و میتونه ورودی لاگ بگیره.
توی همون صفحه Inputs میتونید میزان لاگ ورودی رو ببینید:
اون بالا سمت راست هم نمایش میده که چقدر لاگ وارد شده و چه میزان پردازش و ذخیره شده:
از طریق گزینه Streams از نوار بالا میتونید به لاگ های ورودی دسترسی پیدا کنید. داخل این صفحه بخشی هست به نام All messages:
داخل این بخش میتونید تمام لاگ های رسیده رو ببینید:
از طریق نوار بالای صفحه میتونید بین لاگ ها سرچ کنید:
الگوی سرچ خیلی ساده است:
message: "masoud"
فقط به اون گوشه بالا سمت چپ توجه کنید، زمان رو میتونید مشخص کنید. توی ۵ دقیقه اخیر چیزی نبود، بازه رو روی ۵ روز تنظیم کردم.
شاید یکی از مهمترین ویژگی های گری لاگ همین قدرت سرچ اش باشه که طبعا به دلیل Elasticsearch هست، اینجا میتونید تمام Syntax های مربوط به سرچ گری لاگ رو مشاهده کنید.
ضمنا ذیل همین توضیحات مربوط به Queries میتونید تنظیمات مربوط به کشیدن گراف ها رو هم ببینید.
البته گری لاگ توی کشیدن و نمایش گراف ها به نظرم ضعیف هست و در برابر ابزاری مثل Kibana و یا Grafana حرفی برای گفتن نداره. لذا خیلی توقع گراف های عجیب نداشته باشید.
مثلا این داشبورد سرویس HTTP هست که داخل لاگ ها بخش مربوط به HTTP Status Code ها تنظیم شده:
برای تنظیمات داشبورد میتونید این لینک رو بخونید.
علاوه بر تنظیمات مربوط به داشبورد، تنظیمات Alert هم هست که خیلی میتونه به کار بیاد.
مثلا اول مقاله خاطرتون هست گفتم اتکر تلاش میکنه که لاگین کنه، خب اینجا همون بخشی هست که باید تنظیم کنیم تا این مدل از لاگ ها رو ببینیم.
از منوهای بالا بخش Alerts رو انتخاب میکنیم و Add new condition رو انتخاب میکنیم:
در ادامه Title مناسب برای Alert انتخاب میکنیم و برای بخش Field هم message رو انتخاب میکنیم، این یعنی داخل message ها باید بگرده. میتونه براساس Queries ها پیچیده تر هم باشه.
برای بخش Value هم اون لاگ مورد نظر رو وارد میکنیم، توی مثال اول مقاله۷ هر بار کاربر نمیتونست به سرور لاگین کنه این پیام ثبت میشد:
pam_unix(sshd:auth): authentication failure
در نهایت به اینصورت میشه:
خب بعد از اینکه Save کنیم، گری لاگ شروع میکنه داخل ورودی all messages و در بخش message سرچ کردن و هر موقع با این پیام pam_unix(sshd:auth): authentication failure مواجه بشه آلرت میده:
برای تظیمات بیشتر Alert، داخل این لینک بصورت کامل توضیح داده.
استراتژی نگهداری و پاک کردن لاگ
در واقع این قسمت مهمترین بخش نگهداری لاگ هست.
معمولا بیزنس مشخص میکنه چقدر باید لاگ رو نگهداری کنید، بعضی از سرویس ها مجبورند حتی Raw Log رو هم تا یک سال یا بیشتر نگه دارند.
بصورت عادی مهمترین لاگ ها مربوط به لاگ های سیستمی هستند که برای Audit استفاده میشند، این لاگ ها رو حداقل ۳ تا ۶ ماه نگهداری کنید. اگر فضای کافی دارید تا یک سال هم ارزش نگهداری داره.
ولی در مورد سرویس هایی مثل Nginx یا HAProxy ممکنه لاگ تولید شده خیلی زیاد باشه، نگهداری لاگ خام این سرویس ها معمولا نیاز نمیشه و توصیه میکنم حداکثر ۱ تا ۳ ماه لاگ رو روی سرورها بصورت خام نگهداری کنید.
لاگ سرویس ها که بصورت تحلیل شده ذخیره شده اند رو هم میشه ۳ تا ۶ ماه نگهداری کرد، چرا که معمولا مقایسه بین وضعیت ماه های مختلف میتونه به تصمیم گیری ها کمک کنه.
اکیدا توصیه میکنم تا مجبور نشدید، لاگ های تحلیل شده رو حذف نکنید.
سرویس گری لاگ برای ذخیره لاگ ها از الستیک استفاده میکنه و برای خوندن مدل Index کردن داخل الستیک میتونید این لینک رو بخونید.
این که چه میزان لاگ ذخیره کنید رو میتونید تنظیم کنید، همینطور زمانی که هارد الستیک پر میشه میتونید استراتژی تون رو براش تعریف کنید، معمولا قدیمی ترین لاگ ها رو پاک میکنیم.
از این لینک میتونید نحوه تنظیمات میزان ذخیره لاگ برروی الستیک رو مشاهده کنید.
افزونه ها
گری لاگ یک Marketplace هم داره که توش میتونید انواع داشبورد و پلاگین و Extractor و ... رو پیدا کنید.
این افزونه ها بهتون کمک میکنه برای تحلیل لاگ ها یا تنظیم Alert ها خیلی تو زحمت نیوفتید.
از این آدرس میتونید افزونه های مورد نظرتون رو پیدا کنید.
جمع بندی
تمام این مطلب فقط برشی از فرآیند جمع آوری و نگهداری لاگ ها بود و برای نمونه هم مثالی از سرویس گری لاگ زده شد. ابزارهای متعددی هستند که میتونید براساس نیازمندی سرویس تون استفاده کنید.
دنیای لاگ خیلی وسیع و متنوع هست و میتونه برای هر شرکت و استارت آپ متفاوت باشه.
پیشنهاد میکنم از این بخش استفاده کنید تا هم دانش تون رو در این زمینه افزایش بدید و هم از تجربیات بقیه بهره مند بشید.
موفق باشید
مسعود یوسف پور
