Saman Yazdannik - مرکز آموزش زاگریو

Saman Yazdannikنمایش همه نوشته ها

laus Deo

RDP و RDS چیست؟

2.8kviews

در این مطلب شما با مفهوم کلی (Remote Desktop Services) RDS و (Remote Desktop Protocol) RDP و همچنین اجزای آن، به طور کامل آشنا خواهید شد، احتمالا شما با کلمه Remote آشنایی دارید و از Remote Desktop Connection موجود در ویندوز 7 استفاده کرده‌اید و حداقل یک بار به گوشتان خورده است. در زاگریو به بررسی این مطالب خواهیم پرداخت.

RDP/RDS چیست؟

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

RDP/RDS

در گذشته TSE (Terminal Services) و حالا RDS (Remote Desktop Services) یک نقش بومی یا نیتیو در Windows Server 2008, 2012/2012R2, 2016 و 2019 می‌بود و مجموعه‌ای از سرویس‌هاست که به یک یا چند کاربر اجازه می‌دهد از طریق پروتکل RDP به برنامه‌های (RemoteApp Programs), Windows Desktop (Remote Desktop Sessions) یا دسکتاپ مجازی (VDI) دسترسی همزمان داشته باشند. این اتصال و دسترسی با استفاده از شبکه داخلی درون یک مجموعه یا اینترنت صورت می‌گیرد.

اجزای RDS

RDS شامل شش سرویس است:

1 . Remote Desktop Session Host (RDSH): به شما اجازه می دهد چندین دسکتاپ را با اتصال همزمان از راه دور مدیریت کنید.

2 . Remote Desktop Virtualization Host (RDVH): سرور RDVH با “Microsoft Hyper-V” ادغام می شود تا دسکتاپ‌های مجازی یا ویرچوآل ماشین‌ها را بر اساس تقاضا توزیع نماید. نقش RDVH نشان دهنده زیرساخت Microsoft VDI می‌باشد.

3 . Remote Desktop License Server (RDLS): این نقش نصب و توزیع کلیه RDS CAL را مدیریت می کند. (برای هر کاربر و هر دستگاه)

4 . Remote Desktop Connection Broker (RDCB): برای مدیریت لود بالانس و سشن‌های اتصال مجدد RDS بکار می‌رود.

5 . Remote Desktop Gateway (RDG): RDG به عنوان یک فایروال RDP برای تمامی کاربران از راه دور دسکتاپ عمل می‌کند. RDG فقط از HTTPS / 443 استفاده می کند و برای ایمن سازی، RDP را روی HTTPS انتقال می‌دهد.

6 . Remote Desktop Web Access (RDWA): این یک پورتال دسترسی به وب RDS است که به شما امکان انتشار منابع (ریسورس‌های) داخلی RDS و توزیع‌ها را از طریق یک پورتال وب را به شما می‌دهد.

معماری RDS

در یک نگاه، معماری استاندارد RDS ویندوز سرور از نسخه 2008 تا 2019 با اجزای ذکر شده در بالا به صورت تصویر زیر اجرایی می‌گردند:

RDP Components

آیا RDP یک پروتکل امن است؟

پیکربندی پیش فرض RDP هنگام فعال بودن، آن را در برابر چند حمله متفاوت آسیب پذیر می‌کند. با این حال، برخی از پیشرفت های امنیتی در نسخه جدید RDS برای Windows Server ارائه شده است.

به طور پیش فرض، چندین حمله امکان پذیر است:

Denial of Service 🙁DoS) یا همان داس
Man-in-The-Middle 🙁MiTM)
Brute-Force: بروت فورس

ریسک‌های امنیتی پروتکل RDS

هنگام سروکله زدن با پروتکل RDP، به طور پیش فرض چندین آسیب پذیری و خطر امنیتی وجود دارد که باید آن‌ها را بشناسید و آن‌ها را در نظر بگیرید:

نمایش RDS بر روی اینترنت
Man-in-the Middle (MiTM)
حمله رمزگذاری
حمله داس Denial of Service (DOS)
تخلیه هش‌های رمزعبور
پیکربندی اشتباه RDS
باج افزار
حمله بروت فورس
استفاده از RDSH فضای اشتراک گذاشته‌ شده‌‌‌‌‌‌‌‌‌‌‌‌‌ی RDS
استفاده از KEY LOGGERها

نمایش RDS بر روی اینترنت

هیچ ضرورتی وجود ندارد که سرویس Remote Desktop را در در معرض اینترنت و اتصال از طریق اینترنت قرار دهید، اتصال از طریق اینترنت و خارج از شبکه داخلی باعث می‌شود کاربران خطرناک و افرادی که قصد حمله به RDS شما را دارند از این فرصت استفاده کنند و بیشتر نیز سعی می‌نمایند اکانت administrator را هدف قرار دهند. در این میان اگر هکرها موفق شوند رمز عبور با موفقیت حدس بزنند و پیدا کنند، دسترسی حاصل می‌تواند پیامدهای قابل توجهی برای سازمان شما داشته باشد و حملات بیشتر علیه زیرساخت های قابل اعتماد شما یا متصل به شما را تسهیل کند.

حمله Man-in-the Middle (MiTM)

اگرچه سرویس Remote Desktop رمزگذاری داده را بین کاربر و سرور به طور پیش فرض فراهم می‌کند ، اما تأیید هویت سرور Terminal / RDSH را تأیید نمی‌کند. این عدم تأیید هویت به هکر اجازه می دهد، با به کارگیری سایر روش‌های حمله و نفوذ، کلیه ارتباطات ارسالی بین کاربر و Terminal Server را رهگیری کند. احتمال این نوع حمله به توانایی هکر در کنترل ارتباطات بین سرویس گیرنده(کاربر) و Terminal Server بستگی دارد. به طور معمول، هکر نیاز به حملات دیگری مانند جعل ARP (پروتکل حل آدرس) یا جعل اطلاعات DNS (Domain Name System) دارد که اطلاعات را قبل از ارسال به سرور اصلی به سرور خود هدایت کند.

حمله رمزگذاری

به طور پیش فرض، سرویس Remote Desktop از تنظیمات رمزگذاری متوسط سازگار با کلاینت استفاده می‌کند. این سطح از رمزگذاری، اطلاعات ارسالی بین کاربر و سرور را با حداکثر قدرت کلید پشتیبانی شده توسط کاربر رمزگذاری می‌کند. به طور کلی در چنین محیطی تعدادی از کاربرها از نسخه‌های اولیه کلاینت استفاده می‌کنند که خود ریسک‌را افزایش می‌دهد. تنظیم رمزگذاری متوسط ممکن است باعث شود در مدت محدودی رمز شکسته شود و اطلاعات افشا شود.

حمله داس Denial of Service (DOS)

ترمینال‌هایی که از تأیید هویت سطح شبکه (NLA) پشتیبانی می کنند اما پیکربندی نشده اند بسیار خطرناک هستند. زیرا NLA قبل از اینکه سرور سشنی را برای آن کاربر ایجاد کند، رایانه کاربر را مجبور می کند تا اعتبار کاربر را برای تأیید اعتبار ارائه دهد. ایجاد سشن از منابع سرور استفاده می‌ند و برای همین NLA نیز یکسری دیوار دفاعی برای جلوگیری از اتصال کاربران ناخواسته یا هکرها دارد حال هکرها با استفاده از حمله DoS تعداد زیادی کانکشن به سرور ایجاد می‌کنند و همین امر و درگیری سرور برای شناختن کاربر صحیح از هکر منابع خود را صرف می‌کند واین کار موجب جلوگیری از اتصال کاربران صحیح به سرور می‌شود.

تخلیه هش‌های رمزعبور

باید اطمینان حاصل کنید ک هیچ یک از کاربران ریموت دسکتاپ شما “Local Administrators” نیستند زیرا اگر چندین Local Admin داشته باشید، این مدیران می‌توانند با استفاده از ابزارهای dump hash password رمز دیگر adminها را بر روی شبکه متوجه شوند. برای جلوگیری از هرگونه خطر مربوط به استفاده از ابزار dump hash password مانند Mimikatz، باید از AppLocker استفاده شود.

پیکربندی اشتباه RDS

همه سرور‌های RDS باید با استفاده از ابزارهای امنیتی امن گردند و قابلیت دسترسی برای پیکربندی غلط نداشته باشند تا خطر پیکربندی نادرست توسط افرادی که اجازه دسترسی ندارند نداشته باشند.

باج افزار

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

حمله بروت فورس

اگر از پسوردهای ضعیف استفاده می‌نمایید امکان آسیب پذیری شما در مقابل حملات بروت فورس بسیار بالاست. برای جلوگیری از این نوع حمله بهترین راه حل اطمینان از رمز عبور قدرتمند برای تمامی افرادی است که به RDS شما متصل می‌گردند. یکی دیگر از نکات مفید کم کردن تعداد افرادی است که به RDSHشما دسترسی دارند، هیچگاه از تنظیمات « illimited » با تعداد نامعلومی کاربر برای اتصال به سرور استفاده نکنید.

فضای اشتراک گذاشته‌ شده‌‌‌‌‌‌‌‌‌‌‌‌‌ی RDS

هنگامی که زیرساخت جدید RDS را مستقر می کنید ، مجموعه RDS جدید به طور خودکار ایجاد می شود. اکثر دپارتمان‌های IT مجموعه RDS را با تنظیمات پیش فرض نگه ایجاد می‌کنند و آن را طوری پیکربندی می‌کنند که به همه کاربران ریموت دسکتاپ اجازه می‌دهند به یک بخش مشترک متصل شوند.

مجموعه RDS اغلب برای میزبانی از همه نوع برنامه‌ها یک شرکت (منابع انسانی، امور مالی، IT … ) استفاده می شود و هیچ استثنا و تغییری از لحاظ محدودیت دسترسی برنامه‌ها وجود ندارد در واقع همه برنامه‌ها در یک محیط “مشترک” / سرورهای میزبان RD اجرا می‌گردند. و این امر باعث ایجاد حمله و نفوذ می‌شود. برای حل این موضوع بهتر است هر برنامه یا هر محیطی بر یک مجموعه RDS جداگانه اجرا شود.

حمله با استفاده از Keyloggerها به RDP

کی‌لاگر یک نرم افزار جاسوسی است که هر کلیدی که بر روی کیبور فشار داده شود را ثبت و ارسال می‌کند برای جلوگیری از آلوده شدن و ثبت کلیدها توسط کی‌لاگر نیاز است تا در AppLocker سیاستی اتخاذ شود تا برنامه‌های خاصی قابلیت اجرا بر روی سشن‌های RD داشته باشند.

تمهیدات امنیتی مهم برای RDP:

فعال کردن HA (High Availability) برای تمامی سرویس‌های RDS: فعال کردن برای RDSH/RDCB/RDWA/RDG/RDLS و SQL server
ایجاد یک مجموعه جدید RDS برای هر کاربر و هر برنامه
نصب RDG (Remote Desktop Gateway) برای همه کاربران خارج از مجموعه
فعال کردن MFA (یا 2FA)
فعال کردن NLA (Network Level Authentication) برای تمام مجموعه‌های RDS
رمزگذاری سطح بالا برای کلیه ارتباطات RDP (رمزگذاری 128 بیتی)
استفاده از احراز هویت TLS برای همه RDSH ها
AppLocker را در تمام سرورهای میزبان RD سشن‌ها تعریف و اعمال کنید
ایجاد پسورد قوی برای همه استفاده کنندگان
تغییر پورت پیش فرض RDP
عدم دسترسی حضوری به سرورهای RD
محدود کردن تعداد کاربران
تمام لاگ‌های RDباید ذخیره گردد و به صورت مداوم آنالیز شود

فعال کردن HA (High Availability) برای RDP

کلیه سرویس‌ها و اجزای RD باید در دسترس باشند:

1 . RD Session Host Server: حداقل دو سرور RDSH باید بخشی از یک مجموعه اختصاصی RDS باشند

2 . RD Connection Broker: حداقل دو سرور RDCB باید مستقر و پیکربندی شوند، حالت HA (SQL Server مورد نیاز است)

3 . RD Web Access: حداقل دو سرور RD Web Access باید در کنار Load balancer مستقر و پیکربندی شوند

4 . RD Gateway: حداقل دو سرور RD Gateway باید در حالت HA و کنار Load Balancer مستقر و پیکربندی شوند

5 . RD Licensing Server: حداقل دو سرور لایسنس RD در حالت HA باید مستقر و پیکربندی شوند

ایجاد یک مجموعه جدید RDS برای هر کاربر و هر برنامه

ابتدا باید تمام برنامه های منتشر شده خود را لیست کنید (RemoteApps) سپس، باید یک لیست دسته‌بندی از برنامه های خود ایجاد کنید. هر گروه برنامه باید از طریق یک مجموعه اختصاصی RDS Session (سرورهای اختصاصی RDSH) منتشر و توزیع شود. RD Web Access & RD Gateway را می توان برای همه کاربران ریموت دسکتاپ به اشتراک گذاشت (حالت اشتراکی برای سرویس های وب RD مجاز است).

نصب RDG (Remote Desktop Gateway) برای RDP

توصیه می شود برای همه کاربران ریموت دسکتاپ یک RD Gateway مستقر کنید و یک CAP قوی (خط مشی های دسترسی اتصال) و RAP (خط مشی های دسترسی به منابع) را برای بهبود سطح امنیت محیط RDS تعریف کنید. RD Gateway برای کار کردن به یک گواهینامه SSL معتبر نیاز دارد، گواهی SSL که به RD Gateway تحویل داده می شود باید توسط CA معتبر/معتمد (مرجع صدور گواهینامه) ارائه شده باشد.

فعال کردن MFA (یا 2FA)

توصیه می شود MFA (احراز هویت چند عاملی) را برای همه کاربران ریموت دسکتاپ فعال کنید که از خارج به منابع داخلی RDS شما متصل می‌شوند. سرویس MFA برای کارکرد به یک RD Gateway نیاز دارد. کاربران ریموت دسکاپ برای تکمیل فرآیند MFA باید حداقل یک دستگاه فیزیکی (تلفن هوشمند و …) داشته باشند.

فعال کردن NLA (Network Level Authentication)

تأیید اعتبار سطح شبکه (یا NLA) از ارائه دهنده CredSSP برای ارائه اعتبارنامه کاربر به سرور، قبل از اینکه سرور یک سشن ایجاد کند استفاده می‌کند. این امر با جلوگیری از هرگونه خطر امنیتی مربوط به حمله DOS، سطح امنیتی محیط RDS را بهبود می‌بخشد. توصیه می شود NLA را در همه مجموعه‌های RDS خود فعال کنید.

رمزگذاری سطح بالا برای کلیه ارتباطات RDP (رمزگذاری 128 بیتی)

به طور پیش فرض، سرویس Remote Desktop از تنظیمات رمزگذاری متوسط سازگار با کلاینت استفاده می‌کند. این سطح از رمزگذاری، اطلاعات ارسالی بین کاربر و سرور را با حداکثر قدرت کلید پشتیبانی شده توسط کاربر رمزگذاری می کند. به طور کلی در چنین محیطی تعدادی از کاربرها از نسخه‌های اولیه کلاینت استفاده می‌کنند که خود ریسک‌را افزایش می‌دهد. بنابراین توصیه می‌شود از سطح رمزنگاری “High”برای رمزنگاری استفاده نمایید.

استفاده از احراز هویت TLS برای همه RDSH ها

تمامی سرورهای ایجاد کننده سشن RD باید توسط TLS برای RDS احرازهویت شوند، این کار برای جلوگیری از به سرقت رفتن هویت کاربران از راه دور اجباری است. گواهینامه های SSL که برای تأیید اعتبار سرورهای RDSH استفاده می شوند باید توسط CA معتبر (مرجع صدور گواهینامه) یا PKI داخلی شما تایید و تحویل گردند.

اعمال AppLocker

شما باید RD Session Host خود را که میزبان جلسات و برنامه های منتشر شده است را قفل کنید. یک سیاست یا پالیسی قوی AppLocker باید برای همه سرورهای میزبان RD شما تعریف و اعمال شود. ابتدا باید برنامه های خود را بررسی کرده و تمام اطلاعات مورد نیاز مانند “Apps Thumbprint” را برای تعریف و استفاده از AppLocker خود جمع آوری و ارسال کنید. در آخر توصیه می‌کنیم که یک لیست سفید از اپلیکیشن‌هایی که می‌توانند اجرا شوند ایجاد کنید.

ایجاد پسورد قوی برای همه استفاده کنندگان

ایجاد یک رمز قوی و یا یک سیاست رمز برای ایجاد آن توسط کاربران ریموت بسیار مهم و تاثیرگذار است. با استفاده از AD Group Policy Object ، می توانید سیاست گذرواژه خود را ایجاد ، پیکربندی و اعمال کنید (به عنوان مثال: RDS-USERS).

تغییر پورت پیش فرض RDP

به طور پیش فرض ، پروتکل RDP با پورت 3389 کار می‌کند. و این پورت توسط چندین نرم افزار مخرب/باج افزار هدف قرار می‌گیرد. هکرها نیز در مرحله Footprinting این پورت پیش فرض را هدف قرار می دهند پس توصیه ما تغییر این پورت به پورتی مانند 33381 می‌باشد. برای این تغییر می‌توانید از این اسکریپت استفاده کنید.

امن کردن دستگاه کاربران متصل به RDP

اگر خط مشی امنیتی شما محدود کردن کلیه تغییر مسیر منابع محلی (درایو محلی، چاپگرها، کلیپ بورد و… ) می‌باشد، باید تمام گزینه های تغییر مسیر منابع محلی را بر روی سرورهای RD Session Hosts خود (از طریق GPO) را انجام دهید و همین سیاست را نیز برای دستگاه‌های متصل از راه دور کاربران در پیش بگیرید. کلید رجیستری ذکر شده در بخش “ضمیمه” را می توان از طریق GPO پیکربندی کرد تا تمام تغییر مسیر منابع محلی RDC را غیرفعال کند> MSTSC.exe

محدود کردن تعداد کاربران

اگر لیست کاملی از همه کاربران ریموت دسکتاپ (داخلی و خارجی) را دارید، توصیه می شود حداکثر تعداد سشن‌های ریموت دسکتاپ مجاز را روی RD Gateway تنظیم کنید.

تمام لاگ‌های RDباید ذخیره و آنالیز گردند

تمام عملیات انجام شده در محیط RDS شما باید ثبت شوند: اتصالات ، اتصال مجدد ، تغییر/اصلاح ها تجزیه و تحلیل شوند تا ارتباطات مشکوک یا رفتارهای غیرعادی اگر وجود دارد کشف و رهگیری شود. در کمترین حالت حداقل باید سیاست WEF (Windows Event Forwarding) تعریف و پیکربندی شود.

تست نفوذ محیط RDS

پس از استقرار RDS، باید آزمایشات نفوذ را در محیط RDS خود انجام دهید، این HLV به شما امکان می دهد قبل از ادغام آن در محیط پروداکشن، سطح امنیتی بستر RDS خود را تأیید کنید. برای تأیید وضعیت امنیتی RDS باید چندین آزمایش زیر انجام شود:

امنیت تمام اجزای RDS شامل: RDG, RD Web Access
روند احراز هویت
حمله رمزگذاری
احراز هویت TLS
حمله MiMT
حمله D/DoS
انزوای شبکه
خط مشی محدودیت برنامه ها
مجموعه RDS Multi-tenancy

ضمیمه: (محدود کردن تغییر مسیر منابع محلی(MSTSC.exe))

برای غیرفعال کردن تغییر مسیر کلیپ بورد، کلید رجیستری زیر باید در دستگاه های ریموت دسکتاپ/لپ تاپ های کاربر ایجاد شود:

Key Path : HKLM\SOFTWARE\Microsoft\Terminal Server Client
Registry Key Name : DisableClipboardRedirection
Key Type : REG_DWORD
Data Value : 1

برای غیرفعال کردن تغییر مسیر Local Drive، باید کلید رجیستری زیر در دستگاه های ریموت دسکتاپ/لپ تاپ های کاربر ایجاد شود:

Key Path : HKLM\SOFTWARE\Microsoft\Terminal Server Client
Registry Key Name : DisableDriveRedirection
Key Type : REG_DWORD
Data Value : 1

برای غیرفعال کردن تغییر مسیر پرینترها، اید کلید رجیستری زیر در دستگاه های ریموت دسکتاپ/لپ تاپ های کاربر ایجاد شود:

Key Path : HKLM\SOFTWARE\Microsoft\Terminal Server Client
Registry Key Name : DisablePrinterRedirection
Key Type : REG_DWORD
Data Value : 1

قفل کردن سرورهای RDSH

RDP 2

RDP 4

هرچیزی که در مورد Firewalld باید بدانید

Saman Yazdannik19 اردیبهشت 1400

504views

در بعضی موقعیت‌ها استفاده از firewalld بر روی سیستم‌های systemd از مدیریت و پیکربندی iptableها راحت تر است. برای بیشتر بخش‌ها دیگر به یادگیری و به خاطر سپردن پرش‌ها، قبول کردن‌ها و رد کردن‌ها نمی‌باشید. قوانین راه‌اندازی firewalld بسیار ساده‌تر و در دسترس تر می‌باشند. اما همزمان این مورد باعث نمی‌شود که به قدرت و امکانات iptables دسترسی نداشته باشید.

firewalld چیست؟

firewalld از یک کامندلاین با نام firewall-cmd برای پیکربندی و تغییر قوانین استفاده می‌کند. قبل از اینکه firewalld را پیکربندی کنیم نیاز است که مطمئن شویم سرویس درحال اجراست، با استفاده از دستور systemctl شما سرویس firewalld را راه‌اندازی، متوقف، شروع، پایان یا راه‌اندازی مجدد می‌نمایید. متاسفانه برای تمامی استفاده‌های ذکر شده هیچ خروجی متفاوتی توسط systemctl نمایش داده نمی‌شود که بتوان میان آن‌ها تمایز قائل شد. پس نیاز است که بعد از هربار استفاده از این دستور از وضعیت firewalld آگاه شوید.

firewalld

Systemctl و Firewalld

فعال‌سازی Firewalld

برای اینکه مطمئن شوید firewalld بصورت اتوماتیک با سرور راه‌اندازی شده از دستور زیر استفاده نمایید.

systemctl enable firewalld

شروع firewalld

بعد از اینکه firewalld فعال شد، نیاز است که برای بار اول آن را راه‌اندازی(شروع یا استارت) نماییدو برای این کار نیاز است که از دستور زیر استفاده نمایید:

systemctl start firewalld

توقف firewalld

زمانی که به اصلاح قوانین یا رفع اشکال اتصالات(کانکشن‌ها) می‌پردازید لازم است که firewalld را متوقف کنید، برای منظور می‌توانید از دستور زیر استفاده نمایید.

systemctl stop firewalld

راه‌اندازی مجدد firewalld

اگر به هر دلیلی مجبور شدید تا firewalld را راه اندازی مجدد نمایید می‌توانید از دستور زیر در systemctl استفاده نمایید:

systemctl restart firewalld

وضعیت firewalld

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

systemctl status firewalld

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

[root@centos-7 ~]# systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-01-22 22:50:32 EST; 1h 0min ago Main PID: 808 (firewalld) CGroup: /system.slice/firewalld.service └─808 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

مدیرت firewalld و پیکربندی آن

حال که با دستورات ابتدایی اجرایی firewalld آشنا شدیم و firewalld خود را راه‌اندازی نمودیم‌ میتوانیم به مبحث مدیریت و پیکربندی firewalld بپردازیم بعنوان مثال یک پورت را باز کینم، به سرویس‌ها اجازه فعالیت دهیم، IPها را در لیست سفید قرار دهیم و کارهایی از این قبیل. در تمامی این مثال‌ها ما از پرچم یا فلگ –permanent استفاده می‌کنیم این مهم به این معنی است که قانون وضع شده شما ذخیره می‌گردد حتی بعد از راه اندازی مجدد Firewalld یا ریبوت کردن سرور. بعد از اضافه کردن قوانین جدید لازم است که شما firewall خود را راه اندازی مجدد نمایید تا قوانین جدید اجرا شوند.

اضافه کردن پورت برای UDP یا TCP

برای اضافه کردن یا باز کردن یک پورت در UDP یا TCP نیاز است تا به صورت جداگانه آن دستورات را برای هر نوع پروتکل اجرا نمایید:

firewall-cmd --permanent --add-port=22/TCP

firewall-cmd --permanent --add-port=53/UDP

حذف کردن پورت برای UDP یا TCP

دستور زیر که برای حذف یا بستن یک پورت در پروتکل‌های ذکر شده کاربرد دارد بسیار شبیه به دستورات بالاست با تفاوتی اندک:

firewall-cmd --permanent --remove-port=444/tcp

اضافه کردن سرویس

سرویس‌ها به صورت پیشفرض از پورت‌هایی که در بخش /etc/services پیکربندی شده استفاده می‌نمایند، اما اگر نیاز دارید تا از پورتی خارج از پورت‌های پیش‌فرض برای سرویس‌های خود استفاده نمایید باید آن پورت را باز کنید برای این منظور می‌توانید از دستور زیر استفاده نمایید:

firewall-cmd --permanent --add-service=ssh

firewall-cmd --permanent --add-service=http

حذف کردن یک سرویس

با دستور زیر می‌توانید یک سرویس و پورت گشوده شده برای آن را پاک کنید/ ببندید:

firewall-cmd --permanent --remove-service=mysql

اضافه کردن یک IP به لیست سفید

برای اضافه کردن یک IP یا یک رنج از IPها کافیست با دستور زیر این IPها را به لیست مورد اعتماد firewall اضافه نمایید:

firewall-cmd --permanent --add-source=192.168.1.100

برای اضافه کردن بک رنج از IPها نیز می‌توانید از دستور زیر بهره جویید:

firewall-cmd --permanent --add-source=192.168.1.0/24

حذف کردن یک IP از لیست سفید

برای حذف کردن یک IP یا یک رنج IP می‌توانید از –remove-source مانند مثال زیر استفاده کنید:

firewall-cmd --permanent --remove-source=192.168.1.100

بلاک کردن یک IP

به صورت عمومی firewall-cmd برای اجازه دسترسی و بلاک کردن دسترسی استفاده می‌شود و یکی از بیشترین استفاده‌ها نیز بلاک کردن دسترسی یک IP است برای این منظور ما نیاز به rich rule داریم که بسیار شبیه به قوانینی است که برای iptable استفاده می‌کنیم:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.100' reject"

برای بلاک کردن یک رنج IP نیز همانند بالا می‌توانیم از دستور CIDR زیر استفاده کنیم:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.0/24' reject"

اضافه کردن یک IP به لیست سفید در یک پورت مشخص

برای این عمل نیاز به اعمال قوانین بیشتر یا rich rule بیشتر می‌باشد، برای این منظور باید به iptable برگردیم و از قوانین خود استفاده نماییم و در پایان از accept استفاده می‌کینم تا IP به لیست سفید افزوده گردد نه اینکه reject شود.

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'

حذف یک Rich Rule

برای حذف یک rich rule از آپشن —remove-rich-rule استفاده می‌نماییم هرچند که در این فرایند باید مشخص نمایید که چه قانونی قرار است حذف گردد، توصیه ما کپی کردن و پیست کردن کامل آن قانون است تا انکه آن را تایپ نمایید زیر ممکن است آن را کامل به یاد نیاورید و دچار مشکل شوید:

firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'

ذخیره قوانین Firewall

بعد از اینکه تمامی قوانین مورد نظر خود را اضافه نمودید و تصمیمی گرفتید که آنها را اجرایی کنید نیاز است که فایروال خود را بار دیگر راه‌اندازی نمایید برای این منظور باید دستور زیر را با firewall-cmdاجرا نمایید.

firewall-cmd --reload

مشاهده قوانین firewall

بعد از اینکه فایروال را راه‌اندازی مجدد نمایید بهتر است که مطمئن شویم تمامی قوانین مورد نظر ما در جای خودشان قرار گرفتته‌اند برای این منظور می‌توان از دستور زیر استفاده نمود:

firewall-cmd --list-all

مثال زیر یک نمونه از خروجی آپشن –list-all می‌باشد، در مثال زیر می‌توانید پورت‌ها، rich ruleها و سرویس‌های باز را مشاهده نمایید.

[root@centos-7 ~]# firewall-cmd --list-all public (default, active) interfaces: enp1s0 sources: 192.168.1.0/24 services: dhcpv6-client dns http https mysql nfs samba smtp sshports: 443/tcp 80/tcp 5900-5902/tcp 83/tcp 444/tcp 3260/tcp masquerade: no forward-ports: icmp-blocks: rich rules: rule family="ipv4" source address="192.168.1.0/24" forward-port port="5423" protocol="tcp" to-port="80"

پیکربندی Firewalld به صورت تصویری

اگرچه مطلب نوشته شده تمرکزش بیشتر بر روی اجرای دستورات و استفاده از firewall-cmd بود اما راه دیگر ایجاد قوانین و اجرای دستورات استفاده از رابط گرافیکی firewalld می‌باشد که می‌توانید آن را در قسمت Applications > Sundry در CentOS 7 و RedHat 7.x پیدا کنید. برای نصب این رابط گرافیکی می‌توانید از دستور زیر استفاده نمایید:

sudo yum install firewall-config

با استفاده از بخش utility می‌توانید rich rule های متفاوت و پیچیده‌ای را ایجاد نمایید، که این کار با استفاده از کامندلاین بسیار پیچیده تر است. باید توجه داشته باشید که حتی در رابط گرافیکی نیز برای ایجاد قوانین نیاز است از آپشن permanent استفاده شود.

قوانین مستقیم Firewalld

قوانین مستقیم نوعی از قوانین هستند که به صورت مخصوصی از دیگر قوانین جدا شده‌اند، برای این هستند که به صورت مستقیم با firewall ارتباط برقرار شود این قوانین را می‌توانید در فایلی به آدرس /etc/firewalld/direct.xml ویرایش نمایید. هرچند این قوانین نیز مانند دیگر قوانین نیاز است که فایروال برای اجرای این قوانین راه اندای دوباره گردد. این قوانین مانند rich ruleها یا قوانین iptables می‌باشند فقط در یک فایل XML نوشته شده‌اند. رابط کاربری قوانین مستقیم بیشتر توسط سرویس‌‍ها و اپلیکیشن‌ها برای اضافه کردن قوانین مخصوصی استفاده می‌گردد. در مثال زیر تعدای IP را می‌بینید که برخلاف لیست سیاه می‌باشند و به فایروال می‌گوید که با بررسی IPها و مچ شدن با آن‌ها کانکشن را قطع نماید، باید توجه داشت که شما می‌توانید برای اضافه کردن قوانین مستقیم از firewall-cmd استفاده نمایید اما باید در انتهای دستور از –direct استفاده نمایید.

<?xml version="1.0" encoding="utf-8"?> <direct> <chain ipv="ipv4" table="raw" chain="blacklist"/> <rule ipv="ipv4" table="raw" chain="PREROUTING" priority="0">-s 192.168.1.0/24 -j blacklist</rule> <rule ipv="ipv4" table="raw" chain="PREROUTING" priority="1">-s 192.168.5.0/24 -j blacklist</rule> <rule ipv="ipv4" table="raw" chain="blacklist" priority="0">-m limit --limit 1/min -j LOG --log-prefix "blacklisted: "</rule> <rule ipv="ipv4" table="raw" chain="blacklist" priority="1">-j DROP</rule></direct>

کلام آخر..

در این مقاله هرچیزی را که باید در مورد firewalld بدانید را برای شما کاربران عزیز، توضیح دادیم، برای حفظ امنیت سرور خود و مدیریت سرور بهتر،‌ مواردی را که در این مقاله گفتیم را رعایت کنید.

ولی اگر به هرگونه مشکلی برخوردید، کارشناسان زاگریو، به صورت ۲۴ ساعته جواب‌گوی سوالات شما عزیزان هستند.

سئو صفحه اصلی: بهبود و نکات مورد نیاز موتورهای جستجو

Saman Yazdannik21 اسفند 1399

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

مشخص کردن استراتژی فروش

زمانی که موتورهای جستجو وب‌سایت شما را بررسی و ایندکس می‌نمایند از صفحه نخست یا هوم پیج استفاده می‌کنند تا متوجه شوند وب‌سایت شما درباره‌ی چیست؟ چه محصول و خدماتی ارائه می‌نمایید. مسلما وب‌سایت ها و رقبای زیادی در هر زمینه کاری وجود دارد پس بهترین استراتژی مشخص کردن تفاوت شما با دیگر رقبا در صفحه اصلی است که به آن نقطه فروش منحصر به فرد یا استراتژی فروش انحصاری یا به انگلیسی unique selling point اطلاق می‌گردد. هرچند که بیان این موضوع نباید باعث شود که شما در مورد خدمات و محصولات خود توضیح ندهید بلکه این دو باید در کنار هم باشند.

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

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

کلمات کلیدی صحیح برای بهبود سئو صفحه اصلی

بسیار اعتقاد دارند صفحه نخست باید دارای تمامی کلمات کلیدی محصولات و خدمات آن شرکت و یا کسب و کار باشد، درست است که این استراتژی خوبی است اما در اکثر مواقع بیشتر افراد این عمل را به گونه ای با کلمات کلیدی بسیار انجام می‌دهند که باعث می‌شود، نتیجه عکس گردد و باعث رتبه بدتری شود.

هر صفحه‌ای باید روی یک کلمه کلیدی تمرکز نماید و هیچ دو صفحه ای نباید کلمه کلیدی متمرکز یکسانی داشته باشند. مثلا اگر کسب و کار شما در مورد فروش کفش است نباید هم در صفحه اصلی کلمه کلیدی متمرکز شما کفش و صفحه فروش هم کفش باشد زیر باعث می‌شود این دو صفحه با یک دیگر رقابت کنند می‌توانید صفحه فروش را کفش در نظر بگیرید و درصفحه اصلی از مترادف های آن استفاده نمایید.

کسب و کاری که مشتریان بتوانند به آن اعتماد کنند

اگر موتورهای جستجو بازدیدکنندگان را به صفحات وب‌سایت‌های غیرقابل اطمینان و کلاه بردار هدایت کنند مردم دیگر به سراغ آن موتورهای جستجو نمی‌روند برای حل این مشکل موتورهای جستجو از الگوریتم‌هایی برای فیلتر کردن وب‌سایت‌های غیرقابل اطمینان استفاده می‌کنند.

به صورت فنی‌تر موتورهای جستجو بررسی می‌کنند که آیا شما گواهی SSL دارید( خرید گواهی SSL )، از سرویس میزبانی قابل اعتمادی استفاده می‌کنید، سرعت سایت شما چقدر است، صفحات 404 سایت شما چندتاست و آیا برای خرید مشتریان را به سایت‌های غیرقابل اعتماد دیگر ری‌دایرکت می‌نمایید یا خیر.

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

صفحه اصلی طراحی شده برای مصرف کننده

موتورهای جستجو بررسی می‌کنند که صفحه اصلی شما چقدر برای بازدیدکنندگان شما بهینه است برای بهبود سئو صفحه اصلی سایت باید به سوال های زیر پاسخ دهید. چقدر راحت یک بازدید کننده می‌تواند به صفحه محصول خود هدایت شود؟ تصاویر و هدینگ‌های شما چگونه قرار گرفته اند؟ نوشته‌های سایت شما چقدر خوانا هستند؟ منوهای شما چقدر کارا هستند؟ اطلاعات USP شما چقدر به راحتی در دسترس کاربر است؟

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

هاست وردپرسی: ویژگی‌های مورد نیاز

Saman Yazdannik10 بهمن 1399

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

سرور بهینه شده برای وردپرس:

تفاوت اصلی میان یک‌هاست عادی با یک‌هاست وردپرس چیز نیست جز بهینه شدن و پیکربندی بهینه برای استفاده توسط وبسایت وردپرس شما، در این حالت شرکت میزبانی سرور را برای استفاده بهینه وردپرس با ویژگی‌هایی مانند NGINX، PHP7+OPcache و HTTP2 پیکربندی می‌نماید. موتور کش NGINX این اطمینان را به شما می‌دهد که اطلاعات در کسری از ثانیه به مرورگر کاربران شما برسد، PHP7 و OPcache افزایش بازده و پروتکل HTTP/2 را برای وبسایت شما به ارمغان می‌آورند که نویددهنده واکنشگر بودن بیشتر وبسایت شماست.

گزینه بعدی مدیریت دیتابیس MySQL می‌باشد زمانی که با MariaDB همراه باشد می‌تواند فشار بالای کاری را که همیشه یکی از معضل‌های وب‌سایت وردپرس بوده به‌خوبی مدیریت نماید در این میان بودن PHPMyAdmin نیز به شما این امکان را می‌دهد که دیتابیس خود را به‌راحتی مدیریت نمایید.

با اینکه در حال حاضر PHP 7 بهترین بازده را برای سایت‌های وردپرس دارد اما تعدادی از سایت‌ها و قالب‌های قدیمی‌تر نیاز به نسخه‌های قدیمی‌تر php دارند در این میان شرکت هاستینگ مدنظر شما باید بتواند گزینه‌ای را در اختیار شما قرار دهد تا از میان نسخه‌های php برای وبسایت خود نسخه‌ای را انتخاب نمایید که قالب و افزونه‌های شما کارایی صددرصدی داشته باشند.

نکته مهم دیگر وجود گزینه انتخاب میان SSD و HDD برای فضای ذخیره‌سازی می‌باشند، باتوجه‌به اینکه SSDها سرعتی باورنکردنی در خوانش اطلاعات دارند.

امنیت بیشتر

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

شرکت‌های ارائه‌دهنده میزبانی خوب به شما یک جعبه ابزار یا TOOLKIT امنیتی ارائه می‌دهند که در اصل یک پنل است و به شما این امکان را می‌دهد که در هر شرایط و در هر نقطه از جهان با هر پلتفرم بتوانید به آن دسترسی داشته باشید و بتوانید از انواع ابزارهای امنیتی بر روی سایت خود استفاده کنید و سایت خود را اسکن کنید ایرادات را رفع نمایید و بتوانید از به‌روزرسانی‌های متفاوت آگاه گردید و ریسک‌های موجود را رفع نمایید.

در کنار اینها به دنبال ارائه دهنده‌ای باشد که گواهینامه رایگان SSL به شما ارائه دهد تا اطلاعات ردوبدل شده بین کاربران شما و وبسایتتان به‌صورت کامل رمزگذاری شده باشد. وبسایتی از SSL بهره‌مند است که در بالا مرورگر کنار آدرس وبسایت یک علامت قفل سبز یا سفیدرنگ وجود داشته باشد.

مهم‌تر ار موارد ذکر شده به دنبال ارائه‌دهنده خدماتی باشید که به‌صورت روزانه از اطلاعات شما نسخه پشتیبان تهیه نماید.

راحتی استفاده از امکانات

راحتی استفاده با کاربرپسند بودن معنی می‌شود، پنل ارائه شده‌ای کاربرپسند است که شما بتوانید تمامی امکانات وبسایت خود را با یک کلیک مدیریت نمایید و در هرکجا و با هر دستگاهی به آن دسترسی داشته باشید برای مثال نصب یک پلاگین و مدیریت آن نباید بیش از یک کلیک و 30 ثانیه از شما وقت بگیرد. شما باید بتوانید بسیاری از تسک‌های خود را درون پنل خود به انجام رسانید مانند ساخت فضای توسعه، کلون کردن وب‌سایت، نصب و بررسی پلاگین‌ها قبل از تست و بررسی در وبسایت اصلی و … امکانات

پشتیبانی همه‌جانبه

اولین و مهم‌ترین ویژگی موردنظر شما باید پشتیبانی همه‌جانبهٔ سرکت ارائه‌دهنده میزبانی باشد، اینکه 24 ساعت روز و هفت روز هفته پشتیبانی وجود داشته باشد تا مشکلات وردپرس شما را حل کند و به شما مشاوره بدهد باید مهم‌ترین ویژگی مدنظر شما باشد. همچنین باید به ویژگی‌هایی نظیر زمان uptime سرویس، پهنای باند بی‌نهایت و تعداد وبسایت‌ها و صندوق‌های پستی که می‌توانید بر هاست خود میزبانی کنید نیز توجه نمایید.

اگر از یک‌هاست دیگر قرار است به هاست دیگری نیز مهاجرت کنید بهتر است دنبال ارائه دهنده‌ای باشید که انتقال سایت شما را به‌صورت رایگان انجام می‌دهد.

نتیجه‌گیری

وردپرس یک سیستم توزیع محتوا با امکانات متنوع است که بیشتر نیازهای کاربران را به بهترین نحو پوشش می‌دهد، در این میان پیداکردن یک پکیج کامل برای میزبانی وردپرس کاری دشوار است توصیه ما به شما استفاده از هاست ورپرس زاگریو است که تمامی ویژگی‌های ذکر شده را داراست.

آموزش ایجاد Master-to-Master replication در MariaDB

Saman Yazdannik8 آذر 1399

745views

در این آموزش قصد داریم به بحث sql master-to-master replication بپردازیم، اگر نمی‌دانید که replication به شیوه master-to-master چیست در ادامه در این آموزش با ما همراه باشید، تا هم نحوه ایجاد و هم با این نوع replication آشنا شوید.

در این شیوه اجازه داده می‌شود که اطلاعات و داده ها توسط گروهی از سرورها ذخیره شوند و در هر زمان با آپدیت شدن این اطلاعات در هر کدام از این سرورها اطلاعات و داده‌های ما بروزرسانی و آپدیت شود. در مثال زیر ما از دو سرور استفاده می‌کنیم و همزمان در پیکربندی این سرورها آنها را Master و slave یکدیگر قرار می‌دهیم.

replication چیست

قبل از هرچیزی، به صورت مختصر به بررسی معنی کلمه Replication می‌رسیم، کلمه Replication، به معنی تشکیل کپی‌ها یا Replica‌ها از یک استوریج (storage)، روی استوریج (مخزن اطلاعات) دیگری است، تا در صورت بروز خرابی و حادثه، کپی از اطلاعات موجود باشد و داده‌ها به صورت دائمی پاک نشوند. مکان این دستگاه‌ها ممکن است از شهر یا کشور متفاوتی باشد.

استفاده از Replication، خصوصا برای شرکت‌هایی که اطلاعات مهم – mission critical data دارند بسیار مهم است. در پیاده سازی ریپلیکیشن باید تست‌های لازم انجام شود و بررسی شود که آیا پهنای باند لازم برای این کار فراهم است یا خیر.

موارد مورد نیاز ایجاد master-to-master replication

برای آموزش پیش رو ما فرض می‌کنیم که شما موارد زیر را در اختیار دارید و می‌توانید آن‌ها پیکربندی نمایید.

replication

دو سرور با دیتابیس MariaDB که از پیش نصب شده باشد.
یک دیتابیس نمونه
دسترسی روت به سرور
کلاینت SSH

در ادامه روند آموزش ما نام دیتابیس نمونه را replicate.db در نظر گرفته‌ایم. این دیتابیس در شروع آموزش اطلاعاتی در خود ندارد. اگر تمامی موارد بالا را در اختیار دارید می‌توانیم به سراغ ایجاد master-to-master replication برویم.

پیکربندی سرور A

این سرور قرار است اولین Master server ما باشد و باید آن را برای پروسه replication و فعال کردن آن آماده نماییم. برای این منظور دستور زیر را اجرا نمایید.

sudo nano /etc/my.cnf

1	sudo nano /etc/my.cnf

در بخش [mysqld] باید بخش‌های زیر را اضافه نمایید.

log-bin
server_id=1
replicate-do-db=replicate
bind-address=192.168.0.12

log-bin

server_id=1

replicate-do-db=replicate

bind-address=192.168.0.12

سپس sql سرور خود را دوباره راه اندازی نمایید.

systemctl restart mariadb

1	systemctl restart mariadb

به MariaDB خود با دسترسی روت لاگین نمایید. و یک یوزر master با دسترسی‌های مورد نیاز ایجاد نمایید.

CREATE USER '$master_username'@'%' IDENTIFIED BY '$master_password';

1	CREATE USER '$master_username'@'%' IDENTIFIED BY '$master_password';

GRANT REPLICATION SLAVE ON *.* TO '$master_username'@'%';

1	GRANT REPLICATION SLAVE ON . TO '$master_username'@'%';

FLUSH PRIVILEGES;

1	FLUSH PRIVILEGES;

SHOW MASTER STATUS;

1	SHOW MASTER STATUS;

کامند ‘SHOW MASTER STATUS’ لاگ باینری فعلی موقعیتی که master باید از آن replication را شروع نماید را نشان می‌دهد. مانند زیر:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB|
+------------------+----------+--------------+------------------+
| mariadb-bin.000001 |      626 |            |                 |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

+------------------+----------+--------------+------------------+

+------------------+----------+--------------+------------------+

| mariadb-bin.000001 | 626 | | |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

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

پیکربندی سرور B

قبل از شروع پروسه replication توجه داشته باشید که دیتابیس ساخته شده در سرور A را کپی نموده و به اینجا منتقل نمایید. این سرور دومین master سرور ما می‌باشد و برای عملیات replication باید آن را پیکربندی نماییم. برای شروع مثل قبل دوباره از دستور:

sudo nano /etc/my.cnf

1	sudo nano /etc/my.cnf

در بخش [mysqld] باید بخش‌های زیر را اضافه نمایید.

log-bin
server_id=2
replicate-do-db=replicate
bind-address=192.168.0.15

log-bin

server_id=2

replicate-do-db=replicate

bind-address=192.168.0.15

سپس sql سرور خود را دوباره راه اندازی نمایید.

systemctl restart mariadb

1	systemctl restart mariadb

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

CREATE USER '$master_username'@'%' IDENTIFIED BY '$master_password';

1	CREATE USER '$master_username'@'%' IDENTIFIED BY '$master_password';

GRANT REPLICATION SLAVE ON *.* TO '$master_username'@'%';

1	GRANT REPLICATION SLAVE ON . TO '$master_username'@'%';

FLUSH PRIVILEGES;

1	FLUSH PRIVILEGES;

قدم بعدی شامل بعضی از اطلاعات سرور A می‌شود که باید در سرور B نیز وارد شوند برای وارد نمودن این اطلاعات باید مانند زیر عمل نمایید.

SLAVE STOP;

1	SLAVE STOP;

CHANGE MASTER TO MASTER_HOST = '192.168.0.12', MASTER_USER = '$master_username', MASTER_PASSWORD = '$master_password', MASTER_LOG_FILE = 'mariadb-bin.000001', MASTER_LOG_POS = 626;

1	CHANGE MASTER TO MASTER_HOST = '192.168.0.12', MASTER_USER = '$master_username', MASTER_PASSWORD = '$master_password', MASTER_LOG_FILE = 'mariadb-bin.000001', MASTER_LOG_POS = 626;

SLAVE START;

1	SLAVE START;

قدم آخری که در سرور B باید برای تکمیل مراحل replication انجام دهیم تا اطلاعات را دریافت نماید بر مستر لاگ ذخیره کند و به سرور A ارسال نماید.

SHOW MASTER STATUS;

1	SHOW MASTER STATUS;

دستور ‘SHOW MASTER STATUS‘ لاگ باینری فعلی موقعیتی که master باید از آن replication را شروع نماید را نشان می‌دهد. مانند زیر:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB|
+------------------+----------+--------------+------------------+
| mariadb-bin.000002 |      635 |            |                 |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

+------------------+----------+--------------+------------------+

+------------------+----------+--------------+------------------+

| mariadb-bin.000002 | 635 | | |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

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

کامل کردن replication بر روی سرور A

برای اتمام پروسه replication نیاز است که به سرور A وارد شوید و در MariaDB لاگین نمایید تا اطلاعتی که از سرور B دریافت کردیم را در این سرور وارد نماییم برای این منظور مانند زیر عمل نمایید:

SLAVE STOP;

1	SLAVE STOP;

CHANGE MASTER TO MASTER_HOST = '192.168.0.15', MASTER_USER = '$master_username', MASTER_PASSWORD = '$master_password', MASTER_LOG_FILE = 'mariadb-bin.000002', MASTER_LOG_POS = 635;

1	CHANGE MASTER TO MASTER_HOST = '192.168.0.15', MASTER_USER = '$master_username', MASTER_PASSWORD = '$master_password', MASTER_LOG_FILE = 'mariadb-bin.000002', MASTER_LOG_POS = 635;

SLAVE START;

1	SLAVE START;

بررسی عملکرد درست master-to-master

حالا که تمام پیکربندی‌ها کامل شد نیاز است که بررسی کنیم که آیا سیستم به درستی کار می‌کند یا نه؟ برای این منظور به سرو A لاگین می‌نماییم و وارد دیتابیس MariaDB می‌شویم، حالا یک جدول در دیتابیس replicate.db می‌سازیم.

CREATE TABLE replicate.sample (`name` varchar(18));

1	CREATE TABLE replicate.sample (`name` varchar(18));

حالا وارد سرور B شوید در این سرور نیز باید جدول ساخته شده را مشاهده نمایید.

SHOW TABLES IN replicate;

1	SHOW TABLES IN replicate;

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

+---------------------+
| Tables_in_replicate |
+---------------------+
| sample              |
+---------------------+
1 row in set (0.00 sec)

+---------------------+

| Tables_in_replicate |

+---------------------+

| sample |

+---------------------+

1 row in set (0.00 sec)

برای اینکه مطمئن شوید بر روی سرور B نیز این امر امکان پذیر است می‌توانید مانند عملیات بالا را برای سرور B نیز انجام دهید.

هدف وجود فایل‌های utmp, wtmp و btmp در لینوکس چیست؟

Saman Yazdannik25 آبان 1399

1.6kviews

در لینوکس همه چیز در دایرکتوری /var/log به صورت Log ذخیره می‌شود. این دایرکتوری شامل لاگ‌های تمامی سرویس‌ها و اپلیکیشن‌ها می‌باشد. اگر این دایرکتوری را بررسی کنید با فایل‌های utmp, wtmp و btmp روبرو خواهید شد. این فایل‌ها بر خلاف لاگ‌های سیستمی و لاگ‌های احراز هویت authentication، باینری binary می‌باشند. برای همین ما نمی‌توانیم از text editor های معمول خود یا دستورات ویرایش تکست مانند less یا grep استفاده نماییم. برای خواندن این فایل‌ها یا استخراج داده از این فایل‌ها نیاز است که ما از ابزاری استفاده نماییم که بتواند این نوع فایل باینری را برای ما بخواند.

utmp شامل اطلاعاتی نظیر ورود کاربران در هر ترمینال، خروج‌ها، رویدادهای سیستم(event)، وضع فعلی سیستم و system boot time می‌باشد.

wtmp شامل تاریخچه اطلاعت utmp می‌شود.

btmp شامل اطلاعات ورودهای شکست خورد و نامعتبر می‌شود.

دستور w یا who

کامند who یا w به ما کمک می‌کند اطلاعات یوزرهایی که لاگین کرده اند و فعالیتی که هم‌اکنون به آن مشغولند را مشاهده نماییم. و از فایل /var/run/utmp استخراج نماییم. اگر می‌خواهید لیست یوزرهایی که هم‌اکنون لاگین نموده اند را مشاهده نمایید باید از دستور who به شیوه زیر استفاده نمایید.

$ who
geek    console  Jul  1 23:27
geek    ttys000  Jul  7 13:13
geek    ttys001  Jul 18 18:34

$ who

geek console Jul 1 23:27

geek ttys000 Jul 7 13:13

geek ttys001 Jul 18 18:34

دستور last

کامند last اطلاعاتی نظیر اینکه چگونه یک یوزر لاگین نموده، چه زمانی لاگین نموده و چه زمانی لاگ‌اوت نموده را به ما نمایش می‌دهد.

# last

# last

همچنین ما می‌توانیم از کامند last برای خواندن فایل‌های utmp, wtmp و btmp نیز استفاده نماییم، اینکار به صورت زیر انجام می‌شود.

# last -f /var/log/wtmp    ### To open wtmp file and view its content use blow command.
# last -f /var/run/utmp    ### To see still logged in users view utmp file use last command.
# last -f /var/log/btmp    ### To view btmp file use same command

# last -f /var/log/wtmp ### To open wtmp file and view its content use blow command.

# last -f /var/run/utmp ### To see still logged in users view utmp file use last command.

# last -f /var/log/btmp ### To view btmp file use same command

دستور lastb

با این کامند می‌توانید تاریخچه سشن‌های لاگ شده در /var/run/btmp را مشاهده نمایید.

# lastb

# lastb

دستور utmpdump

همانطور که اشاره کردیم بعلت آنکه فایل‌های ذکر شده به صورت باینری می‌باشند نمی‌توانیم آن‌ها را به صورت عادی با دستوراتی مانند cat، less و غیره بخوانیم، اما شاید راه حل درست استفاده از دستورات ساده‌ای مانند lastb، last و who نباشد، راه حل دیگر استفاده از دستور utmpdump می‌باشد که به صورت زیر می‌شود از آن استفاده نمود.

# utmpdump /path/to/binary

1	# utmpdump /path/to/binary

اگر قصد دارید محتوای باینری فایل‌های utmp, wtmp و btmp می‌توانید به صورت زیر از این کامند استفاده نمایید.

# utmpdump /var/run/utmp
# utmpdump /var/log/wtmp
# utmpdump /var/log/btmp

# utmpdump /var/run/utmp

# utmpdump /var/log/wtmp

# utmpdump /var/log/btmp

نصب WP-CLI بر روی سرور

Saman Yazdannik14 آبان 1399

370views

در این آموزش قصد داریم نحوه نصب WP-CLI را برای شما شرح دهیم، WP-CLI یک کامند لاین برای وردپرس است که شما می‌توانید عملیات‌های مربوط به وردپرس خود را توسط این کامندلاین به انجام برسانید. برای این منظور نیاز به چند مولفه دارید:

-محیط Unix سیستم عامل‌هایی مانند OSX، Linux یا FreeBSD

-PHP 5.4 یا ورژن بالاتر

-WordPress 3.7 یا بالاتر نسخه‌های قدیمی تر ممکن است با بعضی فانکشن‌ها مشکل داشته باشند.

در اولین قدم نیاز است که ما فایل wp-cli را دانلود نماییم برای این امر می‌توانید از دستور زیر استفاده نمایید.

# curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

1	# curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

که نتیجه‌ای مشابه زیر برای شما به ارمغان می‌آورد.

root@web [/]# curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5294k 100 5294k 0 0 8635k 0 --:--:-- --:--:-- --:--:-- 8637k
root@web [/]#

root@web [/]# curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 5294k 100 5294k 0 0 8635k 0 --:--:-- --:--:-- --:--:-- 8637k

root@web [/]#

حال نیاز است که از عملکرد صحیح فایل دانلود شده مطمئن شویم. برای این امر از دساور زیر استفاده می‌کنیم:

# php wp-cli.phar --info

1	# php wp-cli.phar --info

که نتیجه‌ای مانند زیر به ارمغان می‌آورد:

root@web [/]# php wp-cli.phar --info
OS: Linux 2.6.32-042stab134.3 #1 SMP Sun Oct 14 12:26:01 MSK 2018 x86_64
Shell: /bin/bash
PHP binary: /opt/cpanel/ea-php73/root/usr/bin/php
PHP version: 7.3.4
php.ini used: /opt/cpanel/ea-php73/root/etc/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.1.0
root@web [/]#

root@web [/]# php wp-cli.phar --info

OS: Linux 2.6.32-042stab134.3 #1 SMP Sun Oct 14 12:26:01 MSK 2018 x86_64

Shell: /bin/bash

PHP binary: /opt/cpanel/ea-php73/root/usr/bin/php

PHP version: 7.3.4

php.ini used: /opt/cpanel/ea-php73/root/etc/php.ini

WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli

WP-CLI vendor dir: phar://wp-cli.phar/vendor

WP_CLI phar path: /

WP-CLI packages dir:

WP-CLI global config:

WP-CLI project config:

WP-CLI version: 2.1.0

root@web [/]#

برای استفاده از wp-cli با دستور wp از کامند لاین زیر استفاده می‌کنیم:

# chmod +x wp-cli.phar
# mv wp-cli.phar /usr/local/bin/wp

1 2	# chmod +x wp-cli.phar # mv wp-cli.phar /usr/local/bin/wp

اولین کامند بالا باعث می‌شود فایل WP قابل اجرا باشند. و دومین کامند باعث تغییر مکان به /usr/local/bin/ folder می‌شود.

خب حالا که همه چیز انجام شده بیایید تا این امر را تست نماییم، این کار را با ران کردن کامند زیر انجام می‌دهیم:

# wp --info

1	# wp --info

که نتیجه‌ای مانند زیر در پی دارد.

root@web [/]# wp --info
OS: Linux 2.6.32-042stab134.3 #1 SMP Sun Oct 14 12:26:01 MSK 2018 x86_64
Shell: /bin/bash
PHP binary: /opt/cpanel/ea-php73/root/usr/bin/php
PHP version: 7.3.4
php.ini used: /opt/cpanel/ea-php73/root/etc/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.1.0
root@web [/]#

root@web [/]# wp --info

OS: Linux 2.6.32-042stab134.3 #1 SMP Sun Oct 14 12:26:01 MSK 2018 x86_64

Shell: /bin/bash

PHP binary: /opt/cpanel/ea-php73/root/usr/bin/php

PHP version: 7.3.4

php.ini used: /opt/cpanel/ea-php73/root/etc/php.ini

WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli

WP-CLI vendor dir: phar://wp-cli.phar/vendor

WP_CLI phar path: /

WP-CLI packages dir:

WP-CLI global config:

WP-CLI project config:

WP-CLI version: 2.1.0

root@web [/]#

برای بروزرسانی wp-cli می‌توانید از دستور زیراستفاده نمایید.

# wp cli update

1	# wp cli update

که نتیجه‌‌ِی زیر را دربر دارد.

root@web [/]# wp cli update
Success: WP-CLI is at the latest version.
root@web [/]#

root@web [/]# wp cli update

Success: WP-CLI is at the latest version.

root@web [/]#

برای نصب wp-cli می‌توانید از طریق YUM نیز عمل نمایید برای اینکار کاکمند زیر را اجرا نمایید.

# yum install wp-cli

1	# yum install wp-cli

root@web [~]# yum install wp-cli
Loaded plugins: fastestmirror, tsflags, universal-hooks
Loading mirror speeds from cached hostfile
* EA4: 185.125.185.32
* cpanel-addons-production-feed: 185.125.185.32
* cpanel-plugins: 185.125.185.32
* base: mirrors.advancedhosters.com
* epel: d2lzkl7pfhq30w.cloudfront.net
* extras: mirror.teklinks.com
* updates: mirror.cogentco.com
Resolving Dependencies
--&gt; Running transaction check
---&gt; Package wp-cli.noarch 0:2.4.0-2.el7 will be installed
--&gt; Finished Dependency Resolution
Dependencies Resolved
========================================================================================================================================================================
Package                                Arch                                   Version                                       Repository                            Size
========================================================================================================================================================================
Installing:
wp-cli                                 noarch                                 2.4.0-2.el7                                   epel                                 1.0 M
Transaction Summary
========================================================================================================================================================================
Install  1 Package
Total download size: 1.0 M
Installed size: 5.3 M
Is this ok [y/d/N]: y
Downloading packages:
wp-cli-2.4.0-2.el7.noarch.rpm                                                                                                                    | 1.0 MB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : wp-cli-2.4.0-2.el7.noarch                                                                                                                            1/1
Verifying  : wp-cli-2.4.0-2.el7.noarch                                                                                                                            1/1
Installed:
wp-cli.noarch 0:2.4.0-2.el7
Complete!
root@web [~]#

root@web [~]# yum install wp-cli

Loaded plugins: fastestmirror, tsflags, universal-hooks

Loading mirror speeds from cached hostfile

* EA4: 185.125.185.32

* cpanel-addons-production-feed: 185.125.185.32

* cpanel-plugins: 185.125.185.32

* base: mirrors.advancedhosters.com

* epel: d2lzkl7pfhq30w.cloudfront.net

* extras: mirror.teklinks.com

* updates: mirror.cogentco.com

Resolving Dependencies

--> Running transaction check

---> Package wp-cli.noarch 0:2.4.0-2.el7 will be installed

--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================================================================

Package Arch Version Repository Size

========================================================================================================================================================================

Installing:

wp-cli noarch 2.4.0-2.el7 epel 1.0 M

Transaction Summary

========================================================================================================================================================================

Install 1 Package

Total download size: 1.0 M

Installed size: 5.3 M

Is this ok [y/d/N]: y

Downloading packages:

wp-cli-2.4.0-2.el7.noarch.rpm | 1.0 MB 00:00:00

Running transaction check

Running transaction test

Transaction test succeeded

Running transaction

Installing : wp-cli-2.4.0-2.el7.noarch 1/1

Verifying : wp-cli-2.4.0-2.el7.noarch 1/1

Installed:

wp-cli.noarch 0:2.4.0-2.el7

Complete!

root@web [~]#

ساخت اکانت FTP در cPanel

Saman Yazdannik6 آبان 1399

در این آموزش کوتاه قصد داریم به نحوه ساخت حساب FTP در cPanel بپردازیم. برای این منظور باید مانند مراحل زیر عمل نمایید.

قدم اول: با گذرواژه و نام کاربری خود وارد پنل cPanel خود شوید.

قدم دوم: به بخش Files category بروید سپس به صفحه FTP Accounts بروید.

قدم سوم: در بالای صفحه بخش با نام Add FTP Account مشاهده خواهید نمود، در این بخش نام کاربری و گذرواژه مورد نیز خود را انتخاب نمایید.

قدم چهارم: در این بخش root اکانت FTP خود را انتخاب خواهید نمود.

قدم پنجم: با کلیک بر Create FTP Account اکانت شما ساخته خواهد شود وحالا می‌توانید آن را در بخش FTP Accounts مشاهده نمایید.

تعیین-ایمل-پیش‌فرض-برای-دامنه‌ها-در-cPanel

تعیین ایمیل پیش‌فرض برای دامنه‌ها در cPanel

Saman Yazdannik6 آبان 1399

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

قدم اول: با گذز واژه و نام کاربری وارد پنل cPanel خود شوید.

قدم دوم: به بخش EMAIL بروید و وارد بخش Default Address شوید.

قدم سوم: به دنبال Default Address Maintenance بگردید.

قدم چهارم: از منوی drop-down دامنه‌ی مورد نظر خود را انتخاب نمایید.

در این بخش می‌توانید انتخاب نمایید که ایمیل دریافت شده چگونه وارد فرایند مورد نظر شما شود.

cpanel

فعال نمودن gzip در cPanel

Saman Yazdannik5 آبان 1399

برای اینکه محتوای وب‌سایت شما سریعتر لود شود و پهنای باند کمتری مصرف نماید می‌توانید آن را فشرده نمایید این امر cPanel با استفاده از gzip انجام می‌شود. این بدان معنی است که محتوای وب سایت شما به صورت فشرده توسط Apache Web Server در اختیار کاربران قرار می‌گیرد. برای فعال کردن ایم قابلیت می‌توانید طبق آموزش زیر این کار را انجام دهد.

قدم اول: با استفاده از گذرواژه و نام کابری خود وارد پنل cPanel خود شوید.

قدم دوم: بخش Optimize Website را بیابید و آن را باز نمایید.

قدم سوم: در این بخش شما با سه انتخاب روبرو هستید:

–Disabled – این گزینه به معنای غیر فعال بودن gzip است.

-Compress All Content – این گزینه همانطور که از اسمش هم پیداست نشان دهنده فشرده سازی تمام محتوای سایت است.

-Compress the specified MIME types – این گزینه شما می توانید انتخاب کنید که چه گروه از MIME هایی فشرده شوند.

قدم چهارم: اگر گزینه دوم را انتخاب نمایید یک پیام موفقیت مانند این پیام برای شما ظاهر می‌شود:

Website optimization preferences updated. Content compression is now enabled. Content compression is now enabled for all content.

قدم پنج: شما می‌توانید صحت فعال شدن GZIP را از این سایت بررسی نمایید.