server

server

نحوه نصب Drupal با Docker Compose

Drupal یک سیستم مدیریت محتوا (CMS) است که به زبان PHP نوشته شده و تحت مجوز عمومی منبع آزاد GNU توزیع می شود. مردم و سازمانهای مختلف در سراسر جهان از Drupal برای ایجاد سایتهای دولتی ، وبلاگ های شخصی ، کسب و کارها و موارد دیگر استفاده می کنند. آنچه Drupal را از سایر چارچوبهای CMS منحصر به فرد می کند ، جامعه در حال رشد آن و مجموعه ای از ویژگی هایی است که شامل فرآیندهای ایمن ، عملکرد قابل اعتماد ، مدولاریتی (پیمانه ای بودن) و انعطاف پذیری در انطباق است.
Drupal نیاز به نصب پشته LAMP (Linux ، Apache ، MySQLیا PHP) یا پشته LEMP (Linux، Nginx ، MySQL و PHP) دارد ، اما نصب تک تک مؤلفه ها یک کار زمان بر است. ما می توانیم از ابزارهایی مانند Docker و Docker Compose برای ساده کردن روند نصب Drupal استفاده کنیم. در این آموزش از تصاویر Docker برای نصب مولفه های جداگانه در کانتینر Docker استفاده خواهد شد. با استفاده از Docker Compose می توان چندین کانتینر را برای پایگاه داده ، برنامه و شبکه / ارتباط بین آنها تعریف و مدیریت کرد.
در این آموزش Drupal را با استفاده از Docker Compose نصب خواهیم کرد تا بتوانیم از کانتینرینگ استفاده کرده و وب سایت Drupal خود را روی سرورها مستقر کنیم. کانتینرهایی برای یک پایگاه داده MySQL ، وب

سرور مجازی Nginx و Drupal اجرا خواهیم کرد. همچنین با بدست آوردن گواهینامه های TLS / SSL با Let’s Encrypt برای دامنه مورد نظر جهت پیوند با سایت خود ، نصب خود را ایمن خواهیم کرد. سرانجام ، یک فرآیند cron را برای تمدید گواهینامه های خود تنظیم خواهیم کرد تا دامنه مان ایمن بماند.
پیش نیازها
برای دنبال کردن این آموزش ، به موارد زیر نیاز خواهیم داشت:
⦁ سروری که اوبونتو 18.04 را اجرا می کند ، به همراه یک کاربر غیر ریشه با امتیازات sudo و یک فایروال فعال. برای راهنمایی در مورد نحوه تنظیم این موارد ، لطفاً به این راهنمای تنظیم اولیه

سرور مجازی مراجعه کنید.
⦁ Docker که طبق مراحل 1 و 2 نحوه نصب و استفاده از Docker در اوبونتو 18.04 بر روی

سرور مجازی نصب شده باشد. این آموزش بر روی نسخه 19.03.8 تست شده است.
⦁ Docker Compose که طبق مرحله 1 نحوه نصب Docker در اوبونتو 18.04 بر روی

سرور مجازی نصب باشد. این آموزش بر روی نسخه 1.21.2 تست شده است.
⦁ نام دامنه ثبت شده. در سراسر این آموزش از your_domain استفاده خواهد کرد. می توانید یک نام دامنه به صورت رایگان در Freenom دریافت کنید ، و یا از ثبت کننده دامنه مورد نظر خود استفاده کنید.
⦁ هر دو فایل DNS زیر برای

سرور مجازی شما تنظیم شده باشد.
⦁ یک رکورد A با your_domain که به آدرس IP عمومی

سرور مجازی شما اشاره کند.
⦁ رکورد A با www.your_domain که به آدرس IP عمومی

سرور مجازی شما نشان می دهد.
مرحله 1 – تعریف پیکربندی وب سرور
قبل از اجرای هر نوع کانتینر ، باید پیکربندی

سرور مجازی وب Nginx خود را تعریف کنیم. فایل پیکربندی ما شامل برخی از بلوک های مکانی مخصوص Drupal ، به همراه بلوک موقعیت مکانی برای هدایت درخواست های تأیید Let’s Encrypt به کلاینت Certbot برای تمدید خودکار گواهینامه میباشد.
ابتدا ، اجازه دهید یک دایرکتوری پروژه برای مجموعه Drupal خود به نام drupal ایجاد کنیم:
⦁ $ mkdir drupal
⦁
به دیرکتوری جدید ایجاد شده بروید:
⦁ $ cd drupal
⦁
اکنون می توانیم یک دایرکتوری برای فایل پیکربندی خود تهیه کنیم:
⦁ $ mkdir nginx-conf
⦁
فایل را با nano یا ویرایشگر متن مورد علاقه خود باز کنید:
⦁ $ nano nginx-conf/nginx.conf
⦁
در این فایل ، یک بلوک

سرور مجازی با دستورالعمل هایی برای نام

سرور مجازی و ریشه اسناد ، و بلوک های مکان برای هدایت درخواست کلاینت Certbot برای صدور گواهینامه ها ، پردازش PHP و درخواست های دارایی استاتیک اضافه خواهیم کرد.
کد زیر را در فایل اضافه کنید. حتماً your_domain را با نام دامنه خود جایگزین کنید:
~/drupal/nginx-conf/nginx.conf
server {
listen 80;
listen [::]:80;

server_name your_domain www.your_domain;

index index.php index.html index.htm;

root /var/www/html;

location ~ /.well-known/acme-challenge {
allow all;
root /var/www/html;
}

location / {
try_files $uri $uri/ /index.php$is_args$args;
}

rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1;

location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass drupal:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
}

location ~ /\.ht {
deny all;
}

location = /favicon.ico {
log_not_found off; access_log off;
}
location = /robots.txt {
log_not_found off; access_log off; allow all;
}
location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
expires max;
log_not_found off;
}
}

بلوک

سرور مجازی ما شامل اطلاعات زیر است:
دستورالعمل ها:
⦁ listen: به Nginx می گوید که به پورت 80 گوش دهد ، که به ما این امکان را می دهد تا از پلاگین webroot Certbot برای درخواست های گواهی خود استفاده کنیم. توجه داشته باشید که ما هنوز پورت 443 را دراختیار نداریم – پس از اینکه گواهینامه های خود را با موفقیت به دست آوردیم ، پیکربندی خود را برای شامل شدن SSL به روز خواهیم کرد.
⦁ server_name: نام

سرور مجازی ما و بلوک

سرور مجازی را که باید برای درخواست به

سرور مجازی ما استفاده شود ، تعریف می کند. حتما your_domain را در این خط با نام دامنه خود جایگزین کنید.
⦁ index: فایل هایی را که هنگام پردازش درخواست به

سرور مجازی ما به عنوان دیرکتوری استفاده می شوند ، تعریف می کند. ما ترتیب پیش فرض اولویت را در اینجا تغییر داده ایم ، index.php را در جلوی index.html قرار می دهیم تا Nginx در صورت امکان فایلهایی به نام index.php را در اولویت قرار دهد.
⦁ Root: دستورالعمل root دیرکتوری اصلی برای درخواست به

سرور مجازی ما را نامگذاری می کند. این دیرکتوری ، / var / www / html ، به عنوان یک نقطه نصب در زمان ساخت با دستورالعمل هایی در Drupal Dockerfile ما ایجاد می شود. این دستورالعمل Dockerfile همچنین اطمینان حاصل می کند که فایل های موجود در نسخه Drupal روی این حجم نصب شده اند.
⦁ rewrite: اگر عبارت معمول و مشخص شده (^/core/authorize.php/core/authorize.php(.*)$) با یک URI درخواستی مطابقت داشته باشد ، URI همانطور که در رشته جایگزینی مشخص شده است تغییر می کند (/core/authorize.php$1)
بلوک های موقعیت مکانی:
⦁ location ~ /.well-known/acme-challenge : این بلوک موقعیت مکانی درخواست ها به دایرکتوری .well-known را مدیریت میکند که در آن Certbot یک فایل موقت قرار می دهد تا تأیید کند که DNS برای دامنه ما روی

سرور مجازی مناسب میباشد. با استقرار این پیکربندی ، می توانیم از پلاگین webroot Certbot برای به دست آوردن گواهینامه های دامنه خود استفاده کنیم.
⦁ location / : در این بلوک موقعیت مکانی ، ما از یک دستورالعمل try_files برای بررسی فایل های مطابق با درخواست های URI استفاده خواهیم کرد. با این وجود ، به جای بازگشت یک وضعیت 404 Not Found به عنوان پیش فرض ، با آرگومان های درخواست ، کنترل را به فایل index.php Drupal خواهیم داد.
⦁ location ~ \.php$ : این بخش موقعیت مکانی پردازش PHP و پروکسی این درخواستها به کانتینر Drupal را مدیریت می کند. از آنجا که تصویر Drupal Docker ما مبتنی بر تصویر php: fpm خواهد بود ، همچنین گزینه های پیکربندی خاص را در پروتکل FastCGI در این بلوک قرار خواهیم داد. Nginx برای درخواست های PHP به یک پردازنده مستقل PHP احتیاج دارد: در مورد ما ، این درخواست ها توسط پردازنده php-fpm که همراه با تصویر php: fpm است ، انجام می شود. علاوه بر این ، این بلوک موقعیت مکانی شامل دستورالعمل ها ، متغیرها و گزینه های خاص FastCGI است که درخواست ها به برنامه Drupal را که در کانتینر Drupal ما اجرا می شود ، پروکسی میکند، و شاخص مورد نظر را برای URI درخواستی تجزیه شده و درخواست های URI تنظیم میکند.
⦁ location ~ /\.ht : این بلوک فایل های html دسترسی را از آنجایی که Nginx به آنها سرویس نمی دهد ، مدیریت خواهد کرد. دستورالعمل deny_all تضمین می کند که فایل های .htaccess هرگز در اختیار کاربران قرار نمی گیرد.
⦁ location = /favicon.ico, location = /robots.txt : این بلوک ها اطمینان حاصل می کنند که درخواست ها به /favicon.ico و /robots.txt وارد نشوند.
⦁ location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ : این بلوک ورود به سیستم برای درخواست های دارایی استاتیک را غیرفعال می کند و تضمین می کند که این دارایی ها بسیار قابل ذخیره هستند ، زیرا ارائه آن ها معمولاً گران است.
برای کسب اطلاعات بیشتر در مورد پراکسی FastCGI ، به راهنمای درک و اجرای Proxying FastCGI در Nginx مراجعه کنید. برای کسب اطلاعات در مورد بلوک های سرور و موقعیت مکانی ، به راهنمای درک سرور Nginx و الگوریتم های انتخاب بلوک موقعیت مراجعه کنید.
پس از پایان ویرایش ، فایل را ذخیره کنید و ببندید.
با تنظیم Nginx در محل خود ، می توانید به سراغ ایجاد متغیرهای محیط بروید تا در زمان اجرا به کانتینرها برنامه و پایگاه داده خود منتقل شوید.
مرحله 2 – تعیین متغیرهای محیط
برنامه Drupal ما برای ذخیره اطلاعات مربوط به سایت به یک پایگاه داده (MySQL ، PostgresSQL و غیره) نیاز دارد. برای دسترسی به کانتینر پایگاه داده (MySQL) ، کانتینر Drupal در زمان اجرا به برخی از متغیرهای محیطی نیاز دارد. این متغیرها حاوی اطلاعات حساسی مانند اعتبارات پایگاه داده هستند ، بنابراین نمی توانیم مستقیماً آنها را در فایل Docker Compose قرار دهیم – فایل اصلی که حاوی اطلاعاتی در مورد نحوه اجرای کانتینرهای ما است.
همیشه توصیه می شود مقادیر حساس را در فایل .env تنظیم کنید و گردش آن را محدود کنید. این کار مانع از کپی شدن این مقادیر در مخازن پروژه می شود و در معرض دید عموم قرار نمیگیرد.
در دیرکتوری اصلی پروژه ، ~ / drupal ، فایلی با نام .env ایجاد و آن را باز کنید:
⦁ $ nano .env
⦁
متغیرهای زیر را به فایل .env اضافه کنید و بخش هایلایت شده را با اعتبار مورد نظر خود جایگزین کنید:
~/drupal/.env
MYSQL_ROOT_PASSWORD=root_password
MYSQL_DATABASE=drupal
MYSQL_USER=drupal_database_user
MYSQL_PASSWORD=drupal_database_password

اکنون گذرواژه را برای حساب ریشه MySQL و همچنین نام کاربری و رمزعبور مورد نظر خود برای بانک اطلاعات برنامه خود اضافه کرده ایم.
فایل .env ما حاوی اطلاعات حساسی است ، بنابراین همیشه توصیه می شود آن را در فایل های .gitignore و .dockerignore یک پروژه قرار دهید تا به مخازن Git و تصاویر Docker اضافه نشود.
اگر می خواهید برای کنترل نسخه با Git کار کنید ، دیرکتوری کاری فعلی خود را به عنوان یک مخزن با git init مقداردهی کنید:
⦁ $ git init
⦁
فایل gitignore را باز کنید:
⦁ $ nano .gitignore
⦁
موارد زیر را اضافه کنید:
~/drupal/.gitignore
.env
فایل را ذخیره کنید و از آن خارج شوید.
به همین ترتیب ، فایل .dockerignore را باز کنید:
⦁ $ nano .dockerignore
⦁
سپس موارد زیر را اضافه کنید:
~/drupal/.dockerignore
.env
.git
فایل را ذخیره کنید و از آن خارج شوید.
اکنون که برای حفظ اعتبار خود به عنوان متغیرهای محیطی اقداماتی انجام داده ایم ، بیایید به مرحله بعدی تعریف خدمات خود در فایل docker-compose.yml برویم.
مرحله 3 – تعریف خدمات با Compose Docker
Docker Compose ابزاری برای تعریف و اجرای برنامه های چند کانتینری Docker است. ما برای پیکربندی خدمات برنامه خود ، یک فایل YAML تعریف می کنیم. سرویس در Docker Compose یک کانتینر در حال اجرا است و Compose به ما اجازه می دهد تا این سرویس ها را با حجم و شبکه های مشترک پیوند دهیم.
کانتینرهای مختلفی را برای برنامه Drupal ، پایگاه داده و

سرور مجازی وب خود ایجاد خواهیم کرد. در کنار اینها ، همچنین یک کانتینر برای اجرای Certbot ایجاد خواهیم کرد تا بتوانیم گواهینامه هایی را برای

سرور مجازی وب خود بدست آوریم.
یک فایل docker-compose.yml ایجاد کنید:
⦁ $ nano docker-compose.yml
⦁
برای تعریف نسخه فایل Compose و سرویس پایگاه داده mysql کد زیر را اضافه کنید:
~/drupal/docker-compose.yml
version: 3”

services:
mysql:
image: mysql:8.0
container_name: mysql
command: –default-authentication-plugin=mysql_native_password
restart: unless-stopped
env_file: .env
volumes:
– db-data:/var/lib/mysql
networks:
– internal

بیایید همه گزینه های پیکربندی سرویس mysql را یک به یک مرور کنیم:
⦁ image: تصویری را که برای ایجاد کانتینر استفاده یا واکشی خواهد شد، مشخص می کند. همیشه برای جلوگیری از مشکلات بعدی توصیه می شود از تصویر با برچسب نسخه مناسب به استثنای آخرین برچسب استفاده کنید. اطلاعات بیشتر در مورد بهترین روش های Dockerfile را از اسناد Docker بخوانید.
⦁ container_name:برای تعریف نام کانتینر.
⦁ Command: از این گزینه برای رونویسی دستور پیش فرض (دستورالعمل CMD) در تصویر استفاده می شود. MySQL از افزونه های مختلف تأیید اعتبار پشتیبانی کرده است ، اما mysql_native_password m روش معمول تأیید اعتبار است. از آنجا که PHP ، و از این رو Drupal ، از تأیید هویت MySQL جدیدتر پشتیبانی نمی کنند ، ما باید –default-authentication-plugin=mysql_native_password را به عنوان مکانیزم پیش فرض تأیید اعتبار تنظیم کنیم.
⦁ restart: برای تعریف رویکرد ریستارت کانتینر استفاده می شود. رویکرد unless-stopped یک کانتینر را مجدداً راه اندازی می کند مگر اینکه به صورت دستی متوقف شود.
⦁ env_file: متغیرهای محیط را از یک فایل اضافه می کند. در مورد ما متغیرهای محیط را از فایل .env تعریف شده در مرحله قبل می خواند.
⦁ volumes: مسیرهای هاست یا والیوم های نامگذاری را به عنوان گزینه هایی برای یک سرویس مشخص می کند. ما یک والیوم نامگذاری شده به نام db-data را در دیرکتوری / var / lib / mysql روی کانتینر نصب می کنیم ، جایی که MySQL بصورت پیش فرض فایل های داده خود را خواهد نوشت.
⦁ networks: شبکه داخلی را که سرویس برنامه ما به آن ملحق می شود ، تعریف می کند. ما در انتهای فایل شبکه ها را تعریف خواهیم کرد.
تعریف سرویس mysql ما را انجام داده ایم ، بنابراین اکنون بیایید تعریف سرویس برنامه Drupal را به انتهای فایل اضافه کنیم:
~/drupal/docker-compose.yml
…
drupal:
image: drupal:8.7.8-fpm-alpine
container_name: drupal
depends_on:
– mysql
restart: unless-stopped
networks:
– internal
– external
volumes:
– drupal-data:/var/www/html

در این تعریف سرویس ، ما همانطور که با سرویس mysql انجام دادیم ، کانتینر خود را نامگذاری می کنیم و یک ت راه اندازی مجدد را تعریف می کنیم. ما همچنین گزینه های خاصی را برای این کانتینر اضافه می کنیم:
Image: در اینجا ، از تصویر 8.7.8-fpm-alpine استفاده می کنیم. این تصویر دارای پردازنده php-fpm است که

سرور مجازی وب Nginx ما برای پردازش PHP نیاز دارد. علاوه بر این ، از تصویر alpine ، مشتق از پروژه Alpine Linux استفاده می کنیم ، که باعث کاهش سایز تصویر کلی می شود و در بهترین روش های Dockerfile توصیه می شود. Drupal نسخه های بیشتری از تصاویر دارد ، بنابراین آنها را در Dockerhub بررسی کنید.
depends_on : برای بیان وابستگی بین خدمات استفاده می شود. تعیین سرویس mysql به عنوان وابستگی به کانتینر Drupal ما ، اطمینان حاصل می کند که کانتینر Drupal ما پس از کانتینر mysql ایجاد می شود و برنامه ما را قادر می سازد تا یکنواخت شروع شود.
networks: در اینجا ، ما این کانتینر را به همراه شبکه داخلی به شبکه خارجی اضافه کرده ایم. این اطمینان حاصل می کند که سرویس mysql ما فقط از طریق کانتینر داخلی Drupal از طریق شبکه داخلی قابل دسترسی است در حالی که این کانتینرها را از طریق شبکه خارجی در دسترس سایر کانتینرها قرار می دهد.
volumes: یک والیوم نامگذاری شده به نام drupal-data را بر روی Mount / var / www / html قرار می دهیم که توسط تصویر Drupal ایجاد شده است. استفاده از یک والیوم مشخص از این طریق به ما امکان می دهد تا کد برنامه خود را با سایر کانتینرها به اشتراک بگذاریم.
سپس ، تعریف خدمات Nginx را بعد از تعریف سرویس Drupal اضافه خواهیم کرد:
~/drupal/docker-compose.yml
…
webserver:
image: nginx:1.17.4-alpine
container_name: webserver
depends_on:
– drupal
restart: unless-stopped
ports:
– 80:80
volumes:
– drupal-data:/var/www/html
– ./nginx-conf:/etc/nginx/conf.d
– certbot-etc:/etc/letsencrypt
networks:
– external

مجدداً ، برای شروع کار ، کانتینر خود را نامگذاری می کنیم و آن را به کانتینر Drupal وابسته می کنیم. همچنین از یک تصویر alpine– تصویر 1.17.4-alpine Nginx – استفاده می کنیم .
این تعریف خدمات نیز گزینه های زیر را شامل می شود:
⦁ ports: پورت 80 را برای فعال کردن گزینه های پیکربندی تعریف شده در فایل nginx.conf در مرحله 1 در معرض نمایش قرار می دهد.
⦁ volumes: در اینجا ، ما هم والیوم نامگذاری شده و هم مسیر هاست را تعریف می کنیم:
⦁ drupal-data:/var/www/html : کد برنامه Drupal ما را روی دیرکتوری / var / www / html سوار می کند ، که ما آن را به عنوان ریشه در بلوک

سرور مجازی Nginx قرار داده ایم.
⦁ ./nginx-conf:/etc/nginx/conf.d : دایرکتوری پیکربندی Nginx را بر روی هاست برای دیرکتوری مربوطه در کانتینر سوار می کند ، و اطمینان حاصل می کند که هرگونه تغییری که در فایل ها ایجاد کنیم روی هاست در کانتینر منعکس می شود.
⦁ certbot-etc:/etc/letsencrypt : مجوزها و کلیدهای Let’s Encrypt برای دامنه ما را روی دایرکتوری مناسب موجود در کانتینر سوار می کند.
⦁ networks: ما شبکه خارجی را فقط برای این تعریف کرده ایم تا این کانتینر بتواند با کانتینر Drupal و نه با کانتینر mysql ارتباط برقرار کند.
سرانجام آخرین تعریف سرویس خود را برای سرویس certbot اضافه خواهیم کرد. حتماً sammy @ your_domain و your_domain را با ایمیل و نام دامنه خود جایگزین کنید:
~/drupal/docker-compose.yml
…
certbot:
depends_on:
– webserver
image: certbot/certbot
container_name: certbot
volumes:
– certbot-etc:/etc/letsencrypt
– drupal-data:/var/www/html
command: certonly –webroot –webroot-path=/var/www/html –email sammy@your_domain –agree-tos –no-eff-email –staging -d your_domain -d www.your_domain

این تعریف به Compose می گوید تا تصویر certbot / certbot را از Docker Hub دریافت کند. همچنین از این والیوم های نامگذاری شده برای به اشتراک گذاری منابع با کانتینر Nginx ، از جمله گواهینامه های دامنه و کلید در certbot-etcو کد برنامه در drupal-data استفاده می کند.
همچنین از depends_on استفاده کرده ایم تا مطمئن شویم که پس از اجرای سرویس وب

سرور مجازی ، کانتینرهای certbot شروع می شوند.
ما هیچ شبکه ای را در اینجا مشخص نکرده ایم زیرا این کانتینر با هیچ سرویس دیگری از طریق شبکه ارتباط برقرار نخواهد کرد. تنها گواهی نامه های دامنه و کلید را اضافه میکند که ما با استفاده از والیوم نام گذاری شده نصب کرده ایم.
همچنین گزینه command را گنجانده ایم که یک فرمان فرعی را برای اجرا با دستور certbot پیش فرض کانتینر مشخص می کند. کلاینت Certbot از پلاگین ها برای بدست آوردن و نصب گواهینامه ها پشتیبانی می کند. ما از پلاگین webroot برای بدست آوردن گواهی نامه با درج نام مستقل و – webroot در خط فرمان استفاده می کنیم. اطلاعات بیشتر در مورد افزونه و دستورات اضافی را از مستندات رسمی Certbot بخوانید.
پس از تعریف سرویس certbot ، تعریف شبکه و والیوم را اضافه کنید:
~/drupal/docker-compose.yml
…
networks:
external:
driver: bridge
internal:
driver: bridge

volumes:
drupal-data:
db-data:
certbot-etc:

کلید شبکه سطح بالا به ما امکان می دهد شبکه هایی که باید ایجاد شوند مشخص کنیم. شبکه ها امکان ارتباط بین سرویس ها و کانتینرهای موجود در کلیه پورت ها را از زمان ورود به سایت فراهم می کنند زیرا در همان هاست Docker daemon هستند. ما دو شبکه داخلی و خارجی تعریف کرده ایم تا ارتباط وب سرورها ، Drupal و mysql را تضمین کنیم.
از کلید volumes برای تعریف والیوم های نامگذاری drupal-data ، db-data و certbot-etc استفاده می شود. هنگامی که Docker والیوم ها را ایجاد می کند ، محتوای والیوم در یک دیرکتوری در سیستم فایل هاست ، / var / lib / docker / volumes / ، که توسط Docker اداره می شود ، ذخیره می گردد. محتویات هر والیوم از این دیرکتوری روی هر کانتینر دیگری که از والیوم استفاده کند سوار می شود. به این ترتیب ، امکان اشتراک گذاری کد و داده ها بین کانتینرها وجود دارد.
فایل نهایی docker-compose.yml این گونه به نظر می رسد:
~/drupal/docker-compose.yml
version: 3”

drupal:
image: drupal:8.7.8-fpm-alpine
container_name: drupal
depends_on:
– mysql
restart: unless-stopped
networks:
– internal
– external
volumes:
– drupal-data:/var/www/html

webserver:
image: nginx:1.17.4-alpine
container_name: webserver
depends_on:
– drupal
restart: unless-stopped
ports:
– 80:80
volumes:
– drupal-data:/var/www/html
– ./nginx-conf:/etc/nginx/conf.d
– certbot-etc:/etc/letsencrypt
networks:
– external

certbot:
depends_on:
– webserver
image: certbot/certbot
container_name: certbot
volumes:
– certbot-etc:/etc/letsencrypt
– drupal-data:/var/www/html
command: certonly –webroot –webroot-path=/var/www/html –email sammy@your_domain –agree-tos –no-eff-email –staging -d your_domain -d www.your_domain

networks:
external:
driver: bridge
internal:
driver: bridge

volumes:
drupal-data:
db-data:
certbot-etc:

ما کار تعریف سرویس ها را انجام داده ایم. سپس ، بیایید کانتینر را شروع کنیم و درخواست های گواهینامه خود را آزمایش کنیم.
مرحله 4 – اخذ گواهینامه ها و اعتبارات SSL
ما می توانیم کانتینرهای خود را با دستور docker-compose up شروع کنیم ، که کانتینرهای ما را به ترتیبی که مشخص کرده ایم ، ایجاد و اجرا می کند. اگر درخواست های دامنه ما موفق باشد ، وضعیت خروجی صحیح در خروجی خود و گواهی های صحیح نصب شده در پوشه / etc / letsencrypt / live در کانتینر

سرور مجازی وب را مشاهده خواهیم کرد.
برای اجرای کانتینرها در پس زمینه ، از دستور docker-compose up با پرچم -d استفاده کنید:
⦁ $ docker-compose up -d
⦁
خروجی مشابهی مشاهده خواهید کرد که تأیید می کند خدمات شما ایجاد شده اند:
Output
…
Creating mysql … done
Creating drupal … done
Creating webserver … done
Creating certbot … done

با استفاده از دستور docker-compose ps وضعیت خدمات را بررسی کنید:
⦁ $ docker-compose ps
⦁
خدمات mysql ، Drupal و وب سرور را با وضعیتUp مشاهده خواهیم کرد ، در حالی که certbot با یک پیام وضعیت 0 خارج می شود:
Output
Name Command State Ports
————————————————————————–
certbot certbot certonly –webroot … Exit 0
drupal docker-php-entrypoint php-fpm Up 9000/tcp
mysql docker-entrypoint.sh –def … Up 3306/tcp, 33060/tcp
webserver nginx -g daemon off; Up 0.0.0.0:80->80/tcp

اگر در ستون State برای خدمات mysql ، Drupal یا webserver چیز دیگری به غیر از up مشاهده میکنید و یا وضعیت خروج غیر از 0 برای کانتینر certbot مشاهده می کنید ، حتما ورود های خدمات را با دستور docker-comps logs بررسی نمایید:
⦁ $ docker-compose logs service_name
⦁
اکنون می توانیم بررسی کنیم که گواهینامه های ما با استفاده از دستور docker-compose exec در کانتینر webserver نصب شده است:
⦁ $ docker-compose exec webserver ls -la /etc/letsencrypt/live
⦁
خروجی زیر را می دهد:
Output
total 16
drwx—— 3 root root 4096 Oct 5 09:15 .
drwxr-xr-x 9 root root 4096 Oct 5 09:15
-rw-r–r– 1 root root 740 Oct 5 09:15 README
drwxr-xr-x 2 root root 4096 Oct 5 09:15 your_domain
اکنون که همه چیز با موفقیت اجرا شد ، می توانیم تعریف سرویس certbot خود را ویرایش کنیم تا پرچم –staging را حذف کنیم.
فایل docker-compose.yml را باز کنید ، به تعریف سرویس certbot بروید و پرچم –staging را در گزینه فرمان با پرچم –force-renewal جایگزین کنید ، که به Certbot می گوید که می خواهید یک گواهی جدید را با دامنه های مشابه گواهی موجود درخواست دهید. تعریف certbot به روز شده به شرح زیر خواهد بود:
~/drupal/docker-compose.yml
…
certbot:
depends_on:
– webserver
image: certbot/certbot
container_name: certbot
volumes:
– certbot-etc:/etc/letsencrypt
– drupal-data:/var/www/html
command: certonly –webroot –webroot-path=/var/www/html –email sammy@your_domain –agree-tos –no-eff-email –force-renewal -d your_domain -d www.your_domain
…

برای ایجاد مجدد کانتینر certbot باید دوباره docker-compose up را اجرا کنیم. همچنین گزینه –no-deps را در اختیار میگیریم تا به Compose بگوییم که می تواند از شروع سرویس وب

سرور مجازی صرفنظر کند ، زیرا در حال حاضر اجرا میشود:
⦁ $ docker-compose up –force-recreate –no-deps certbot
⦁
خروجی را نشان می دهد که تایید میکند درخواست گواهی ما موفق بوده است:
Output
Recreating certbot … done
Attaching to certbot
certbot | Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot | Plugins selected: Authenticator webroot, Installer None
certbot | Renewing an existing certificate
certbot | Performing the following challenges:
certbot | http-01 challenge for your_domain
certbot | http-01 challenge for www.your_domain
certbot | Using the webroot path /var/www/html for all unmatched domains.
certbot | Waiting for verification…
certbot | Cleaning up challenges
certbot | IMPORTANT NOTES:
certbot | – Congratulations! Your certificate and chain have been saved at:
certbot | /etc/letsencrypt/live/your_domain/fullchain.pem
certbot | Your key file has been saved at:
certbot | /etc/letsencrypt/live/your_domain/privkey.pem
certbot | Your cert will expire on 2020-01-03. To obtain a new or tweaked
certbot | version of this certificate in the future, simply run certbot
certbot | again. To non-interactively renew *all* of your certificates, run
certbot | certbot renew”
certbot | – Your account credentials have been saved in your Certbot
certbot | configuration directory at /etc/letsencrypt. You should make a
certbot | secure backup of this folder now. This configuration directory will
certbot | also contain certificates and private keys obtained by Certbot so
certbot | making regular backups of this folder is ideal.
certbot | – If you like Certbot, please consider supporting our work by:
certbot |
certbot | Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
certbot | Donating to EFF: https://eff.org/donate-le
certbot |
certbot exited with code 0

اکنون که مجوزهای خود را با موفقیت تولید کردیم ، می توانیم پیکربندی Nginx خود را به روز کنیم تا SSL را شامل شود.
مرحله 5 – اصلاح تنظیمات وب

سرور مجازی و تعریف سرویس
پس از نصب گواهینامه های SSL در Nginx ، باید کلیه درخواست های HTTP را به HTTPS تغییر مسیر دهیم. همچنین باید مجوز SSL و مکانهای کلیدی خود را مشخص کنیم و پارامترهای امنیتی و هدرها را اضافه کنیم.
از آنجا که می خواهید سرویس وب

سرور مجازی را برای گنجاندن این موارد اضافه، بازتولید کنید ، می توانید اکنون آن را متوقف کنید:
⦁ $ docker-compose stop webserver
⦁
خروجی زیر را به دست می دهد:
Output
Stopping webserver … done
سپس ، فایل پیکربندی Nginx را که قبلاً ایجاد کردیم حذف خواهیم کرد:
⦁ $ rm nginx-conf/nginx.conf
⦁
نسخه دیگری از فایل را باز کنید:
⦁ $ nano nginx-conf/nginx.conf
⦁
برای هدایت HTTP به HTTPS و اضافه کردن اعتبار ، پروتکل و هدرهای امنیتی SSL ، کد زیر را به فایل اضافه کنید. به یاد داشته باشید که your_domain را با دامنه خود جایگزین کنید:
~/drupal/nginx-conf/nginx.conf
server {
listen 80;
listen [::]:80;

server_name your_domain www.your_domain;

location ~ /.well-known/acme-challenge {
allow all;
root /var/www/html;
}

location / {
rewrite ^ https://$host$request_uri? permanent;
}
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name your_domain www.your_domain;

index index.php index.html index.htm;

root /var/www/html;

server_tokens off;

ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;

add_header X-Frame-Options SAMEORIGIN” always;
add_header X-XSS-Protection 1; mode=block” always;
add_header X-Content-Type-Options nosniff” always;
add_header Referrer-Policy no-referrer-when-downgrade” always;
add_header Content-Security-Policy default-src * data: ‘unsafe-eval’ ‘unsafe-inline'” always;

location / {
try_files $uri $uri/ /index.php$is_args$args;
}

rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1;

location ~ /\.ht {
deny all;
}

بلوک

سرور مجازی HTTP افزونه webroot را برای درخواستهای تمدید Certbot به دایرکتوری .well-known/acme-challenge مشخص می کند. این برنامه همچنین شامل یک دستورالعمل rewrite است که درخواست های HTTP را به دیرکتوری اصلی به HTTPS هدایت می کند.
بلوک

سرور مجازی HTTPS ، ssl و http2 را فعال می کند. برای کسب اطلاعات بیشتر درباره نحوه تکرار HTTP / 2 در پروتکل های HTTP و فواید آن برای عملکرد وب سایت ، لطفاً به مقدمه نحوه تنظیم Nginx با پشتیبانی HTTP / 2 در اوبونتو 18.04 مراجعه کنید.
این بلوک ها SSL را فعال می کنند ، همانطور که گواهی SSL و مکان های کلیدی ما را همراه با هدرهای توصیه شده درج کرده ایم. این هدرها به ما این امکان را می دهند که در سایت های آزمایش

سرور مجازی SSL Labs و Security Headers امتیاز A کسب کنیم.
دستورالعمل های root و index ما نیز در این بلوک قرار دارند ، مانند سایر قسمت های بلوک مکان ویژه Drupal که در مرحله 1 بحث شده است.
فایل پیکربندی Nginx به روز شده را ذخیره کنید و ببندید.
قبل از استفاده مجدد از کانتینر

سرور مجازی ، نیاز به اضافه کردن نگاشت پورت 443 روی تعریف سرویس وب

سرور مجازی خود خواهیم داشت زیرا مجوزهای SSL را فعال کرده ایم.
فایل docker-compose.yml را باز کنید:
⦁ $ nano docker-compose.yml
⦁
تغییرات زیر را در تعریف سرویس وب

سرور مجازی ایجاد کنید:
~/drupal/docker-compose.yml
…
webserver:
image: nginx:1.17.4-alpine
container_name: webserver
depends_on:
– drupal
restart: unless-stopped
ports:
– 80:80
– 443:443
volumes:
– drupal-data:/var/www/html
– ./nginx-conf:/etc/nginx/conf.d
– certbot-etc:/etc/letsencrypt
networks:
– external
…

پس از فعال کردن گواهینامه های SSL ، docker-compose.yml به صورت زیر ظاهر می شود:
~/drupal/docker-compose.yml
version: 3”

drupal:
image: drupal:8.7.8-fpm-alpine
container_name: drupal
depends_on:
– mysql
restart: unless-stopped
networks:
– internal
– external
volumes:
– drupal-data:/var/www/html

webserver:
image: nginx:1.17.4-alpine
container_name: webserver
depends_on:
– drupal
restart: unless-stopped
ports:
– 80:80
– 443:443
volumes:
– drupal-data:/var/www/html
– ./nginx-conf:/etc/nginx/conf.d
– certbot-etc:/etc/letsencrypt
networks:
– external

networks:
external:
driver: bridge
internal:
driver: bridge

volumes:
drupal-data:
db-data:
certbot-etc:

فایل را ذخیره کنید و ببندید. بیایید سرویس وب

سرور مجازی را با پیکربندی به روز شده دوباره بازیابی کنیم:
⦁ $ docker-compose up -d –force-recreate –no-deps webserver
⦁
خروجی زیر را ارائه می دهد:
Output
Recreating webserver … done
خدمات را با docker-compose ps بررسی کنید:
⦁ $ docker-compose ps
⦁
خدمات mysql ، Drupal و webserver را در حالی مشاهده خواهیم کرد که certbot با یک پیام وضعیت 0 خارج می شود:
Output
Name Command State Ports
————————————————————————–
certbot certbot certonly –webroot … Exit 0
drupal docker-php-entrypoint php-fpm Up 9000/tcp
mysql docker-entrypoint.sh –def … Up 3306/tcp, 33060/tcp
webserver nginx -g daemon off; Up 0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp

در حال حاضر ، تمام خدمات ما در حال اجرا است و بهتر است با نصب Drupal از طریق رابط وب پیش برویم.
مرحله 6 – تکمیل نصب از طریق رابط وب
بیایید نصب را از طریق رابط وب Drupal انجام دهیم.
در یک مرورگر وب ، به دامنه سرور بروید. به یاد داشته باشید که your_domain خود را در اینجا با نام دامنه خود جایگزین کنید:
https://your_domain

زبان مورد استفاده را انتخاب کنید:

روی Save and continue کلیک کنید . به صفحه نمایه نصب منتقل میشویم. Drupal دارای پروفایل های مختلف است ، بنابراین مشخصات Standard را انتخاب کرده و روی Save and continue کلیک کنید.

پس از انتخاب پروفایل ، به صفحه پیکربندی Database خواهیم رفت. نوع Database را به عنوان MySQL ، MariaDB ، Percona Server یا معادل آن انتخاب کنید و مقادیر مربوط به نام پایگاه داده ، نام کاربری و رمز عبور را از بین مقادیر مربوط به MYSQL_DATABASE ، MYSQL_USER و MYSQL_PASSWORD به ترتیب در فایل.env در مرحله 2 تعریف کردید، انتخاب نمایید. روی Advanced Options کلیک کرده و مقدار هاست را روی نام کانتینر سرویس mysql تنظیم کنید. روی Save and continue کلیک کنید.

پس از پیکربندی پایگاه داده ، نصب ماژول ها و تم های پیش فرض Drupal شروع می شود:

پس از نصب سایت ، به صفحه ستاپ سایت پیکربندی Drupal برای پیکربندی نام سایت ، ایمیل ، نام کاربری ، رمز عبور و تنظیمات ناحیه ای می رویم. اطلاعات را پر کنید و بر روی Save and continue کلیک کنید:

بعد از کلیک روی ذخیره و ادامه ، می توانیم صفحه Welcome to Drupal را مشاهده کنیم ، که نشان می دهد سایت Drupal ما با موفقیت شروع به کار کرده است.

اکنون که نصب Drupal ما تمام شد ، باید اطمینان حاصل کنیم که گواهینامه های SSL ما به صورت خودکار تمدید خواهد شد.
مرحله 7 – تمدید گواهینامه ها
گواهینامه های Let’s Encrypt به مدت 90 روز معتبر هستند ، بنابراین باید یک فرایند تمدید خودکار را تنظیم کنیم تا اطمینان حاصل شود که از بین نمی روند. یکی از راه های انجام این کار ایجاد اقدامی با ابزار برنامه ریزی cron است. در این حالت ، ما یک کار cron ایجاد خواهیم کرد تا به صورت دوره ای یک اسکریپت را اجرا کنیم که گواهینامه های ما را تمدید کرده و پیکربندی Nginx را مجدد لود کند.
بیایید فایل ssl_renew.sh را برای تمدید گواهینامه های خود ایجاد کنیم:
⦁ $ nano ssl_renew.sh
⦁
کد زیر را اضافه کنید. به یاد داشته باشید که نام دیرکتوری را با کاربر غیر ریشه خود جایگزین کنید:
~/drupal/ssl_renew.sh
#!/bin/bash

cd /home/sammy/drupal/
/usr/local/bin/docker-compose -f docker-compose.yml run certbot renew –dry-run && \
/usr/local/bin/docker-compose -f docker-compose.yml kill -s SIGHUP webserver

این اسکریپت در دیرکتوری پروژه ~ / drupal تغییر می کند و دستورات docker-compose زیر را اجرا می کند.
docker-compose run : یک کانتینر certbot را شروع می کند و فرمان ارائه شده در تعریف سرویس certbot ما را نادیده می گیرد. به جای استفاده از فرمان فرعی certonly ، ما در اینجا از فرمان فرعی renew استفاده می کنیم ، که گواهینامه هایی را که نزدیک به انقضا هستند تجدید می کند. برای آزمایش اسکریپت خود گزینه –dry run را در اینجا گنجانده ایم.
docker-compose kill : یک سیگنال SIGHUP را به کانتینر وب

سرور مجازی ارسال می کند تا پیکربندی Nginx را مجدد لود کند.
با اجرای دستور زیر فایل را ببندید و آن را قابل اجرا کنید:
⦁ $ sudo chmod +x ssl_renew.sh
⦁
در مرحله بعد ، فایل crontab ریشه را باز کنید تا اسکریپت تجدید در یک بازه مشخص اجرا شود:
⦁ $ sudo crontab -e
⦁
اگر این اولین بار است که این فایل را ویرایش می کنید ، از شما خواسته می شود ویرایشگر متن را انتخاب کنید تا فایل با آن باز شود:
Output
no crontab for root – using an empty one

Select an editor. To change later, run ‘select-editor’.
1. /bin/nano
2. /usr/bin/vim.basic
3. /usr/bin/vim.tiny
4. /bin/ed

Choose 1-4 [1]:
…

در انتهای فایل خط زیر را اضافه کنید و sammy را با نام کاربری خود جایگزین کنید:
crontab
…
*/5 * * * * /home/sammy/drupal/ssl_renew.sh >> /var/log/cron.log 2>&1

این فاصله زمانی را برای هر پنج دقیقه تعیین می کند ، بنابراین می توانیم آزمایش کنیم که آیا درخواست تجدید ما مطابق پیش بینی شده کار کرده است یا خیر. همچنین یک فایل ورود، cron.log را ایجاد کرده ایم تا خروجی مربوطه را ثبت کنیم.
پس از پنج دقیقه ، از دستور tail استفاده کنید تا cron.log را بررسی کنید و ببینید آیا درخواست تمدید موفقیت آمیز بوده است یا خیر:
⦁ $ tail -f /var/log/cron.log
⦁
خروجی تأیید موفقیت آمیز تجدید را مشاهده خواهید کرد:
Output
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/your_domain/fullchain.pem (success)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

CTRL + C را فشار دهید تا از روند tail خارج شود.
اکنون می توانیم فایل crontab را تغییر دهیم تا اسکریپت روز دوم هر هفته در ساعت 2 صبح اجرا شود. خط آخر crontab را به صورت زیر تغییر دهید:
crontab
…
* 2 * * 2 /home/sammy/drupal/ssl_renew.sh >> /var/log/cron.log 2>&1

خارج شوید و فایل را ذخیره کنید.
اکنون ، بیایید گزینه –dry run را از متن ssl_renew.sh حذف کنیم. ابتدا آن را باز کنید:
⦁ $ nano ssl_renew.sh
⦁
سپس محتوا را به شرح زیر تغییر دهید:
~/drupal/ssl_renew.sh
#!/bin/bash

cd /home/sammy/drupal/
/usr/local/bin/docker-compose -f docker-compose.yml run certbot renew && \
/usr/local/bin/docker-compose -f docker-compose.yml kill -s SIGHUP webserver

در حال حاضر کار cron از تمدید گواهینامه های SSL با تمدید آنها در صورت واجد شرایط بودن ، مراقبت می کند.
نتیجه
در این آموزش از Docker Compose برای ایجاد نصب Drupal با یک وب

سرور مجازی Nginx استفاده کرده ایم. به عنوان بخشی از این گردش کار ، گواهینامه های TLS / SSL را برای دامنه مورد نظر خود با سایت Drupal در نظر گرفتیم و یک کار cron ایجاد کردیم تا در صورت وم این گواهینامه ها را تمدید کنیم.
اگر دوست دارید درباره Docker اطلاعات بیشتری کسب کنید ، به صفحه Docker topic مراجعه کنید.

برچسب‌ها:Certbot, CMS, cron, Drupal

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

نحوه نصب Nginx در اوبونتو 20.04

Nginx یکی از محبوب ترین سرورهای وب در جهان است و مسئولیت میزبانی برخی از بزرگترین و پر ترافیک ترین سایتها در اینترنت را دارد. یک انتخاب ساده است که می تواند به عنوان

سرور مجازی وب یا پروکسی مع استفاده شود.
در این راهنما ، ما در مورد چگونگی نصب Nginx در

سرور مجازی Ubuntu 20.04 خود ، تنظیم فایروال ، مدیریت فرایند Nginx و ایجاد بلوک های

سرور مجازی برای میزبانی بیش از یک دامنه از یک سرور واحد بحث خواهیم کرد.
پیش نیازها
قبل از شروع این راهنما ، باید یک کاربر معمولی و غیر ریشه با امتیازات sudo در

سرور مجازی خود تنظیم کنید. با پیروی از راهنمای ستاپ اولیه

سرور مجازی برای اوبونتو 20.04 می توانید نحوه پیکربندی یک حساب کاربری معمولی را یاد بگیرید.
هنگامی که یک حساب کاربری در دسترس داشتید ، به عنوان کاربر غیر ریشه خود وارد شوید.
مرحله 1 – نصب Nginx
از آنجا که Nginx در مخازن پیش فرض اوبونتو موجود است ، می توان آن را از طریق این مخازن با استفاده از سیستم بسته بندی apt نصب کرد.
از آنجا که این اولین تعامل ما با سیستم بسته بندی apt در این بخش است ، دیرکتوری بسته های محلی خود را به روز می کنیم تا به جدیدترین لیست های بسته دسترسی داشته باشیم. پس از آن ، می توانیم nginx را نصب کنیم:
⦁ $ sudo apt update
⦁
⦁ $ sudo apt install nginx
پس از پذیرش روال ، apt ، Nginx و هرگونه متعلقات لازم را برای

سرور مجازی شما نصب می کند.
مرحله 2 – تنظیم فایروال
قبل از آزمایش Nginx ، برای دسترسی به سرویس باید نرم افزار فایروال تنظیم شود. Nginx پس از نصب ، خود را به عنوان سرویسی با ufw ثبت می کند ، و این باعث می شود دسترسی Nginx ساده باشد.
با تایپ دستور زیر تنظیمات برنامه را که ufw می داند چگونه با آن کار کند لیست کنید:
⦁ $ sudo ufw app list
⦁
باید لیستی از پروفایل های برنامه را دریافت کنید:
Output
Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH

همانطور که از خروجی نشان داده شده است ، سه پروفایل برای Nginx در دسترس است:
⦁ Nginx Full: این پروفایل هر دو پورت 80 (ترافیک وب عادی و بدون رمزگذاری) و پورت 443 (ترافیک رمزگذاری شده TLS / SSL) را باز می کند
⦁ Nginx HTTP: این نمایه فقط پورت 80 را باز می کند (ترافیک وب عادی و بدون رمزگذاری)
⦁ Nginx HTTPS:این پروفایل فقط پورت 443 را باز می کند (ترافیک رمزگذاری شده TLS / SSL)
توصیه می شود محدودترین نمایه ای را که هنوز امکان ترافیک تنظیم شده خود را فراهم می کند ، فعال کنید. در حال حاضر ، ما فقط نیاز به ترافیک در پورت 80 داریم.
می توانید آن را با تایپ کردن دستور زیر فعال کنید:
⦁ $ sudo ufw allow ‘Nginx HTTP’
⦁
می توانید تغییر را با تایپ این دستور تأیید کنید:
⦁ $ sudo ufw status
⦁
خروجی نشان خواهد داد که ترافیک HTTP مجاز است:
Output
Status: active

To Action From
— —— —-
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)

مرحله 3 – بررسی

سرور مجازی وب خود
در پایان مراحل نصب ، اوبونتو 20.04 ، Nginx را شروع می کند. وب

سرور مجازی اکنون راه اندازی و در حال کار میباشد.
ما می توانیم با تایپ کردن این دستور زیر سیستم شروع کار systemd را بررسی کنیم تا مطمئن شویم که این سرویس در حال اجراست:
⦁ $ systemctl status nginx
⦁
Output
● nginx.service – A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-04-20 16:08:19 UTC; 3 days ago
Docs: man:nginx(8)
Main PID: 2369 (nginx)
Tasks: 2 (limit: 1153)
Memory: 3.5M
CGroup: /system.slice/nginx.service
├─2369 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
└─2380 nginx: worker process

همانطور که با این دستور تأیید شده است ، این سرویس با موفقیت شروع به کار نموده است. با این حال ، بهترین راه برای آزمایش آن، درخواست صفحه از Nginx است.
شما می توانید با رفتن به آدرس IP

سرور مجازیخود به صفحه فرود پیش فرض Nginx دسترسی داشته باشید تا تأیید کنید که نرم افزار به درستی کار می کند. اگر آدرس IP

سرور مجازی خود را نمی دانید ، می توانید آن را با استفاده از ابزار icanhazip.com پیدا کنید ، که آدرس IP عمومی شما را همانطور که از یک مکان دیگر در اینترنت دریافت کرده است به شما می دهد:
⦁ $ curl -4 icanhazip.com
⦁
اکنون که آدرس IP

سرور مجازی خود را دارید ، آن را در نوار آدرس مرورگر خود وارد کنید:
http://your_server_ip

باید صفحه فرود پیش فرض Nginx را دریافت کنید:

اگر در این صفحه هستید ،

سرور مجازی شما به درستی کار می کند و آماده مدیریت است.
مرحله 4 – مدیریت فرایند Nginx
اکنون که

سرور مجازی وب خود را فعال کرده اید ، اجازه دهید برخی دستورات مدیریت پایه را مرور کنیم.
برای متوقف کردن

سرور مجازی وب خود ، تایپ کنید:
⦁ $ sudo systemctl stop nginx
⦁
برای شروع

سرور مجازی وب هنگام متوقف بودن ، تایپ کنید:
⦁ $ sudo systemctl start nginx
⦁
برای متوقف کردن و شروع مجدد سرویس ، تایپ کنید:
⦁ $ sudo systemctl restart nginx
⦁
اگر فقط تغییرات پیکربندی را انجام می دهید ، Nginx اغلب می تواند بدون افت اتصالات مجدد لود شود. برای انجام این کار ، تایپ کنید:
⦁ $ sudo systemctl reload nginx
⦁
به طور پیش فرض ، Nginx به گونه ای پیکربندی شده است تا وقتی

سرور مجازی بوت میشود ، به طور خودکار شروع گردد. اگر این چیزی نیست که شما می خواهید ، می توانید با تایپ کردن دستور زیر، این رفتار را غیرفعال کنید:
⦁ $ sudo systemctl disable nginx
⦁
برای فعال کردن مجدد سرویس برای راه اندازی در هنگام بوت شدن ، می توانید این دستور را تایپ کنید:
⦁ $ sudo systemctl enable nginx
⦁
اکنون دستورات مدیریت پایه را آموخته اید و باید برای پیکربندی سایت آماده باشید تا میزبان بیش از یک دامنه باشد.
مرحله 5 – تنظیم بلوک های

سرور مجازی (توصیه می شود)
هنگام استفاده از وب

سرور مجازی Nginx ، می توان از بلوک های

سرور مجازی (مشابه هاست های مجازی در Apache) برای کپسوله کردن جزئیات پیکربندی و میزبانی بیش از یک دامنه از یک

سرور مجازی واحد استفاده کرد. دامنه ای به نام your_domain.com را راه اندازی می کنیم ، اما شما باید این نام را با نام دامنه خود جایگزین کنید.
Nginx در اوبونتو 20.04 دارای یک بلوک

سرور مجازی است که بصورت پیش فرض فعال شده است تا برای ارائه اسناد از یک دیرکتوری در / var / www / html پیکربندی شود. اگرچه برای یک سایت واحد به خوبی کار می کند ، اگر میزبان چندین سایت باشید ، می تواند مشکل ساز شود. به جای تغییر / var / www / html ، بیایید یک ساختار دایرکتوری در / var / www برای سایت your_domain.com ایجاد کنیم ، و / var / www / html را به عنوان دایرکتوری پیش فرض رها کنیم تا در صورت عدم تطابق درخواست کلاینت با هیچ سایت دیگر، این دیرکتوری ارائه شود.
دایرکتوری برای your_domain.com را به شرح زیر ایجاد کنید ، از پرچم -p برای ایجاد هرگونه دیرکتوری parent لازم
استفاده نمایید.
⦁ sudo mkdir -p /var/www/your_domain/html
⦁
سپس ، مالکیت دایرکتوری را به متغیر محیط USER $ اختصاص دهید:
⦁ sudo chown -R $USER:$USER /var/www/your_domain/html
⦁
اگر مقدار umask خود را تغییر نداده باشید ، مجوزهای ریشه وب شما باید صحیح باشد که مجوزهای پیش فرض فایل را تعیین می کند. برای اطمینان از صحیح بودن مجوزهای تان و اجازه دادن به مالک برای خواندن ، نوشتن و اجرای فایل ها در حالی که فقط امکان خواندن و اجرای مجوزها برای گروه ها و دیگران مجاز است ، می توانید دستور زیر را وارد کنید:
⦁ $ sudo chmod -R 755 /var/www/your_domain
⦁
سپس ، با استفاده از nano یا ویرایشگر مورد علاقه خود ، صفحه index.html نمونه را ایجاد کنید:
⦁ $ nano /var/www/your_domain/html/index.html
⦁
در داخل ، نمونه HTML زیر را اضافه کنید:
/var/www/your_domain/html/index.html
<html>
<head>
<title>Welcome to your_domain!</title>
</head>
<body>
<h1>Success! The your_domain server block is working!</h1>
</body>
</html>

پس از اتمام ، فایل را با تایپ کردن CTRL و X و سپس Y و ENTER ذخیره کنید.
برای اینکه Nginx بتواند این محتوا را ارائه دهد ، لازم است یک بلوک

سرور مجازی را با دستورالعمل های درست ایجاد کنید. به جای تغییر مستقیم پیکربندی پیش فرض ، بیایید فایل جدیدی را در /etc/nginx/sites-available/your_domain.com ایجاد کنیم:
⦁ $ sudo nano /etc/nginx/sites-available/your_domain
⦁
در بلوک پیکربندی زیر پیست کنید که مشابه پیش فرض است ، اما برای دیرکتوری جدید و نام دامنه به روز میباشد:
/etc/nginx/sites-available/your_domain
server {
listen 80;
listen [::]:80;

root /var/www/your_domain/html;
index index.html index.htm index.nginx-debian.html;

server_name your_domain www.your_domain;

location / {
try_files $uri $uri/ =404;
}
}

توجه کنید که پیکربندی ریشه را به دیرکتوری جدید و server_name را به نام دامنه خود به روز کرده ایم.
در مرحله بعد ، اجازه خواهیم داد فایل را با ایجاد پیوندی از آن به دیرکتوری sites-enabled ، که Nginx هنگام راه اندازی از آن می خواند ، فعال کنیم:
⦁ $ sudo ln -s /etc/nginx/sites-available/your_domain /etc/nginx/sites-enabled/
⦁
اکنون دو بلوک

سرور مجازی فعال و پیکربندی شده اند تا به درخواست ها بر اساس دستورالعمل های listen و server_name آنها پاسخ دهند (می توانید درباره نحوه پردازش Nginx این دستورالعمل ها در این لینک بیشتر بخوانید):
⦁ your_domain.com: به درخواست های your_domain.com و www.your_domain.com پاسخ خواهد داد.
⦁ •default: به هر درخواست در پورت 80 که با دو بلوک دیگر مطابقت ندارد پاسخ خواهد داد.
برای جلوگیری از بروز مشکل حافظه که می تواند ناشی از افزودن نام

سرور مجازی اضافی باشد ، لازم است یک مقدار واحد را در فایل /etc/nginx/nginx.conf تنظیم کنید. فایل را باز کنید:
⦁ $ sudo nano /etc/nginx/nginx.conf
⦁

دستورالعمل server_names_hash_bucket_size را پیدا کنید و نماد # را حذف کنید تا خط را باطل کنید. اگر از nano استفاده می کنید ، می توانید با فشار دادن CTRL و w به سرعت کلمات موجود در فایل را جستجو کنید.
/etc/nginx/nginx.conf
…
http {
…
server_names_hash_bucket_size 64;
…
}
…

پس از اتمام فایل را ذخیره کنید و ببندید.
سپس ، بررسی کنید تا مطمئن شوید که هیچ خطای نحوی در هیچ یک از فایل های Nginx شما وجود ندارد:
⦁ $ sudo nginx -t
⦁
اگر مشکلی وجود ندارد ، Nginx را ریستارت کنید تا تغییرات خود را فعال نمایید:
⦁ $ sudo systemctl restart nginx
⦁
Nginx اکنون باید نام دامنه شما را ارائه دهد. می توانید با رفتن به http://your_domain.com ، جایی که باید چیزی شبیه به این تصویر را مشاهده کنید ، این فرآیند را آزمایش کنید:

مرحله ششم – آشنایی با فایل ها و دستورالعمل های مهم Nginx
اکنون که می دانید چگونه خود سرویس Nginx را مدیریت کنید ، باید چند دقیقه وقت بگذارید تا با چند دیرکتوری و فایل مهم آشنا شوید.
محتوا
⦁ / var / www / html: محتوای وب واقعی ، که به طور پیش فرض فقط شامل صفحه پیش فرض Nginx است که قبلاً دیدید ، از دیرکتوری / var / www / html ارائه می شود. با تغییر فایل های پیکربندی Nginx قابل تغییر است.
پیکربندی سرور
⦁ / etc / nginx: دیرکتوری پیکربندی Nginx . همه فایل های پیکربندی Nginx در اینجا قرار دارند.
⦁ /etc/nginx/nginx.conf: فایل اصلی پیکربندی Nginx . می تواند برای ایجاد تغییر در تنظیمات جهانی Nginx اصلاح شود.
⦁ / etc / nginx / sites-available /: دایرکتوری که می توان در آن بلوک های

سرور مجازی هر سایت ذخیره شود. Nginx از فایل های پیکربندی موجود در این دیرکتوری استفاده نمی کند مگر اینکه به دیرکتوری sites-enabled مرتبط باشند. به طور معمول ، تمام پیکربندی بلوک

سرور مجازی در این دایرکتوری انجام می شود ، و سپس با پیوند دادن به دایرکتوری دیگر فعال می شود.
⦁ / etc / nginx / sites-enabled /: دایرکتوری که در آن بلوکهای

سرور مجازی فعال در هر سایت ذخیره میشوند. به طور معمول ، با پیوند دادن به فایلهای پیکربندی موجود در دیرکتوری sites-available ایجاد می شوند.
⦁ / etc / nginx / snippets: این دیرکتوری شامل قطعات پیکربندی است که می توان در جایی دیگر در پیکربندی Nginx گنجانید. بخش های پیکربندی قابل تکرار بالقوه گزینه های خوبی برای تجزیه قطعات هستند.
ورودهای مربوط به سرور
⦁ /var/log/nginx/access.log: هر درخواستی به

سرور مجازی وب شما در این فایل log ثبت می شود ، مگر اینکه Nginx به گونه ای پیکربندی شده باشد که کاری غیر از این انجام دهد.
⦁ /var/log/nginx/error.log: هرگونه خطای Nginx در این ورود ثبت می شود.
نتیجه
اکنون که

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

برچسب‌ها:Nginx, TLS / SSL, Ubuntu 20.04, فایروال

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

7 مورد از اقدامات امنیتی برای محافظت از سرورهای شما

هنگام راه اندازی زیرساخت های cloud ، به روزرسانی برنامه ها اغلب دغدغه اصلی شما خواهد بود. با این حال ، عملکرد صحیح برنامه های کاربردی شما بدون پرداختن به نیازهای امنیتی زیرساخت های تان می تواند عواقب مخربی را در پی داشته باشد ، بنابراین بهتر است که این مورد را به عنوان بخشی از راه اندازی اولیه زیرساخت خود در نظر بگیرید.
در این راهنما ، ما برخی از شیوه های اساسی امنیتی را برای پشتیبانی از شما در پیکربندی و تنظیم زیرساخت ها ، انجام خواهیم داد.
کلیدهای SSH
SSH یا همان پوسته ایمن، پروتکل رمزگذاری شده است که برای اداره و برقراری ارتباط با

سرور مجازی ها استفاده می شود. هنگام کار با یک

سرور مجازی ، احتمالاً بیشتر وقت خود را در یک بخش ترمینال متصل به

سرور مجازی خود از طریق SSH می گذرانید. گزینه های امن تر برای ورود به سیستم مبتنی بر رمز عبور ، کلیدهای رمزنگاری SSH روشی مطمئن برای ورود به

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

برای پیکربندی احراز هویت کلید SSH ، باید کلید عمومی کاربر را روی یک

سرور مجازی در یک دیرکتوری مخصوص قرار دهید. هنگامی که کاربر به

سرور مجازی متصل میشود،

سرور مجازی از شما می خواهد اثبات کنید که کلاینت دارای کلید خصوصی مرتبط است. کلاینت SSH برای تأیید اعتبار مالکیت، از کلید خصوصی استفاده می کند.

سرور مجازی سپس به کلاینت اجازه می دهد بدون پسورد وصل شود. برای کسب اطلاعات بیشتر در مورد چگونگی عملکرد کلیدهای SSH ، مقاله ما درمورد درک فرآیند رمزگذاری و اتصال SSH را بررسی کنید.
کلیدهای SSH چگونه امنیت را تقویت می کنند؟
با SSH ، هر نوع تأیید هویت – از جمله تأیید گذرواژه – کاملاً رمزگذاری میشود. با این حال ، هنگامی که ورود به سیستم مبتنی بر رمز عبور مجاز است ، کاربران مخرب می توانند برای دستیابی به

سرور مجازی ، خصوصاً با

سرور مجازی هایی که دارای آدرس IP عمومی هستند ، بارها و بارها تلاش کنند. با داشتن قدرت محاسباتی مدرن ، می توان با خودکار کردن این فرآیند ها و امتحان رمزهای پی در پی پسورد درست را پیدا کرد.
تنظیم تأیید اعتبار کلیدی SSH به شما امکان می دهد تأیید هویت مبتنی بر گذرواژه را غیرفعال کنید. کلیدهای SSH به طور کلی تعداد بیشتری بیت های داده نسبت به رمز عبور دارند ، به این معنی که ترکیب های احتمالی بسیار بیشتری وجود دارد که یک حمله کننده مجبور به اجرای آن ها باشد. بسیاری از الگوریتم های کلید SSH توسط سخت افزار محاسباتی مدرن غیرقابل رکورد محسوب می شوند ، زیرا به مدت زمان زیادی برای اجرای همه حالت های قابل اجرا احتیاج دارند.
نحوه اجرای کلیدهای SSH
کلیدهای SSH روش پیشنهادی برای ورود از راه دور به هر

سرور مجازی لینوکس است. یک جفت کلید SSH در دستگاه محلی شما ایجاد می شود و می توانید طی چند دقیقه کلید عمومی را به

سرور مجازی های خود منتقل کنید.
برای کسب اطلاعات در مورد نحوه تنظیم کلیدها ، یکی از راهنماهای ما را در مورد SSH ، مانند نحوه تنظیم کلیدهای SSH در اوبونتو 20.04 را دنبال کنید. اگر هنوز هم احراز هویت مبتنی بر رمز عبور را میپسندید ، برای محدود کردن حدس های رمزعبور ، راهکاری مانند fail2ban را روی

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

در یک

سرور مجازی معمولی ، خدمات متعددی به طور پیش فرض اجرا می شوند. اینها را می توان در گروههای زیر طبقه بندی کرد:
• خدمات عمومی که برای هر کسی از طریق اینترنت ، غالباً به صورت ناشناس ، قابل دسترسی است. نمونه آن

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

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

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

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

سرور مجازی شما یا هنگام تغییر در آنچه در رایانه شما ارائه می شود ، باید این اتفاق بیفتد. در اینجا چند گزینه برای به روز رسانی و اجرا وجود دارد:
⦁ UFW ، یا فایروال غیر پیچیده ، به طور پیش فرض در برخی توزیع های لینوکس مانند اوبونتو نصب شده است. یک فایروال محبوب ، که می توانید در مورد آن در آموزش نحوه تنظیم فایروال با UFW در اوبونتو 18.04 بیشتر اطلاعات کسب کنید.
⦁ چگونه می توان فایروال را با استفاده از Iptables در Ubuntu 14.04 تنظیم کرد
⦁ نحوه نصب و پیکربندی فایروال

سرور مجازی (CSF) در اوبونتو
شبکه های VPC
شبکه های Virtual Private Cloud (VPC) شبکه های خصوصی برای منابع زیرساختی شما هستند. شبکه های VPC ارتباط امن تری بین منابع برقرار می کنند زیرا رابط های شبکه از اینترنت عمومی و دیگر شبکه های VPC در Cloud غیرقابل دسترسی هستند.
چگونه شبکه های VPC امنیت را بالا میبرند
استفاده از شبکه های خصوصی به جای عمومی برای ارتباطات داخلی تقریباً همیشه ترجیح داده می شود ، زیرا شبکه های VPC به شما امکان می دهد گروه هایی از منابع را در شبکه های خصوصی خاص ایزوله کنید. شبکه های VPC فقط با استفاده از رابط های شبکه خصوصی خود از طریق شبکه داخلی به یکدیگر متصل می شوند ، این بدان معناست که ترافیک بین منابع شما از طریق اینترنت عمومی هدایت نمی شود که در آن ممکن است در معرض حمله یا رهگیری قرار گیرد. شبکه های VPC همچنین می توانند برای جداسازی محیط های اجرایی استفاده شوند.
علاوه بر این ، می توانید گیت های اینترنت را به عنوان تنها نقطه دسترسی بین منابع شبکه VPC و اینترنت عمومی خود تنظیم کنید و به شما امکان کنترل و دید بیشتری در ترافیک عمومی متصل به منابع خود می دهد.
نحوه اجرای شبکه های VPC
بیشتر ارائه دهندگان زیرساخت های cloud این امکان را به شما می دهند تا منابع خود را به یک شبکه VPC در داخل دیتاسنترهای خود اضافه کنید.
پیکربندی دستی شبکه خصوصی شما می تواند به پیکربندی پیشرفته

سرور مجازی و دانش شبکه نیاز داشته باشد.
بازرسی سرویس
بخش عمده ای از امنیت شامل تجزیه و تحلیل سیستم های ما ، درک سطوح حمله موجود و قفل کردن مولفه ها به بهترین شکل ممکن است.
بازرسی سرویس (Service auditing) فرایندی است برای کشف سرویس هایی که روی

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

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

سرور مجازی ها فرآیندهای بسیاری را برای اهداف داخلی و مدیریت کلاینت های خارجی شروع می کنند. هر یک از این موارد سطح حمله گسترده ای را برای کاربران مخرب نشان می دهد. هرچه سرویس های در حال اجرای بیشتری داشته باشید احتمال آسیب پذیری موجود در نرم افزار قابل دسترسی شما بالاتر است.
هنگامی که اطلاعات کافی درباره خدمات شبکه در حال اجرا در دستگاه خود داشتید ، می توانید شروع به تجزیه و تحلیل این سرویس ها کنید. برخی از سؤالاتی که برای هر یک از خود میپرسید عبارتند از:
• آیا این سرویس باید اجرا شود؟
• آیا این سرویس با رابط های شبکه ای اجرا می شود که نباید در آن اجرا شود ؟
⦁ آیا باید به یک IP اختصاص داده شود؟
• آیا قوانین فایروال من ایجاد شده اند تا ترافیک قانونی را به این خدمات بدهد؟
• آیا قوانین فایروال من ترافیک غیرقانونی را مسدود می کند؟
• آیا من روشی برای دریافت هشدارهای امنیتی درباره آسیب پذیری برای هر یک از این خدمات دارم؟
هنگام پیکربندی هر

سرور مجازی جدید در زیرساخت های شما این نوع بررسی سرویس یک روش استاندارد است. همچنین انجام بررسی های خدمات هر 6 ماه یکبار به شما کمک می کند تا هرگونه خدماتی که پیکربندی هایی آن ها ناخواسته تغییر کرده اند را پیدا کنید.
نحوه انجام ممیزی های سرویس
برای انجام یک ممیزی اولیه سرویس ، می توانید با استفاده از دستور netstat ببینید که کدام سرویس ها پورت را در هر رابط گوش می دهند. فرمان مثال که نام برنامه ، PID و آدرسهایی را که برای گوش دادن به ترافیک TCP و UDP استفاده می شود نشان می دهد به این شرح است:
⦁ $ sudo netstat -plunt
⦁
خروجی دریافت خواهید کرد که اینگونه میباشد:
Output
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 887/sshd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 919/nginx
tcp6 0 0 :::22 :::* LISTEN 887/sshd
tcp6 0 0 :::80 :::* LISTEN 919/nginx

ستونهای اصلی که مورد توجه شما هستند ستونهای نام Proto ، Local Address و PID / Program هستند. اگر آدرس 0.0.0.0 باشد ، خدمات در کلیه رابط های شبکه اتصالات را می پذیرند.
به روزرسانی های بدون نظارت
حفظ به روزرسانی در

سرور مجازی می تواند ابزاری قدرتمند برای امنیت باشد.

سرور مجازی های unpatched عامل اکثر ناسازگاری ها هستند ، اما به روزرسانی منظم می تواند از آسیب پذیری جلوگیری کند.
به روزرسانی های معمول به یک ادمین نیاز دارند تا به روز رسانی بسته های مختلف روی

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

سرور مجازی شما و کوتاه کردن مدت زمانی که

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

سرور مجازی شما را کاهش دهد.
نحوه به روزرسانی های بدون نظارت
اکثر توزیعهای ر اکنون به روزرسانی های بدون نظارت را به عنوان گزینه ای میبینند. به عنوان مثال ، در اوبونتو یک ادمین می تواند این دستور را اجرا کند:
⦁ $ sudo apt install unattended-upgrades
⦁
برای اطلاعات بیشتر در مورد نحوه اجرای به روزرسانی های بدون نظارت ، راهنماهای مربوط به Ubuntu و Fedora را بررسی کنید.
توجه: این مکانیزم ها فقط نرم افزار به روزرسانی خودکار را از طریق مدیر بسته سیستم شما نصب می کنند. اطمینان حاصل کنید که هر نرم افزار اضافی که ممکن است در حال اجرا است (به عنوان مثال برنامه های وب) یا برای به روزرسانی های خودکار پیکربندی شده اند یا به صورت دستی و بطور مرتب چک می شوند.
غیرفعال کردن ایندکس های دیرکتوری
بیشتر

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

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

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

سرور مجازی وب شما خطر از دست دادن داده های تصادفی ، نشت یا بهره برداری را با ساختن فایل های دیرکتوری برای بازدیدکنندگان غیرفعال می کند. اگر بازدید کنندگان در دیرکتوری وجود داشته باشند ، بازهم می توانند به فایل ها دسترسی پیدا کنند ، اما غیرفعال کردن ایندکسینگ باعث می شود یافتن فایل ها به طور ناخواسته دشوارتر شوند.
چگونه ایندکس های دایرکتوری را غیرفعال کنیم
در اکثر موارد ، غیرفعال کردن ایندکس های دیرکتوری اضافه کردن یک خط به پیکربندی

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

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

سرور مجازی شما با باج افزار به خطر بیفتد ، فقدان بکاپ ممکن است به این معنا باشد که تنها انتخاب شما پرداخت باج برای بازگرداندن اطلاعات شما است. اگر به طور مرتب از سیستم ها و داده های خود نسخه پشتیبان تهیه کنید ، میتوانید بدون تعامل با سیستم به خطر افتاده ، به داده های خود دسترسی پیدا کنید و آن ها را بازیابی کنید.
بکاپ های مکرر چگونه امنیت را افزایش میدهند؟
بکاپ گیری با حفظ نسخه های دست نخورده از داده ها قبل از وقوع حملات ، باعث کاهش خطر حذف تصادفی و کاهش خطر از بین رفتن اطلاعات می شود.
علاوه بر موارد باج افزار ، بکاپ گیری منظم می تواند به تجزیه و تحلیل قانونی حملات طولانی مدت کمک کند. اگر تاریخچه داده های خود را ندارید ، تشخیص زمان شروع حمله و اطلاعات به خطر افتاده دشوار یا غیرممکن است.
نحوه اجرای بکاپ های مکرر
بر خلاف سایر روش های این لیست ، اجرای بکاپ گیری می تواند از چیزی بی اهمیت تا فرآیندی بسیار دشوار متفاوت باشد. هنگام فعال کردن نسخه های پشتیبان ، باید از خود بپرسید: اگر

سرور مجازی من فردا ناپدید شد ، چگونه می توانیم آن را به عقب برگردانم و راه اندازی کنم؟
در اینجا چند سؤال دیگر وجود دارد که باید هنگام تهیه یک برنامه بازیابی حوادث در نظر بگیرید:
• آیا همیشه باید آخرین نسخه پشتیبان تهیه شود؟ بسته به دفعات تغییر داده های شما ، ممکن است خطر را از پیش فرض به بکاپ قدیمی کاهش دهد
• روند واقعی برای بازیابی نسخه پشتیبان چیست؟ آیا نیاز به ایجاد یک

سرور مجازی جدید یا بازگرداندن

سرور مجازی موجود دارید؟
• چه مدت می توانید بدون این

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

برچسب‌ها:cloud, fail2ban, Iptables, netstat, VPC

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

نحوه نصب و ایمن سازی Redis در اوبونتو 20.04

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

سرور مجازی Ubuntu 20.04 را نشان می دهد.
پیش نیازها
برای تکمیل این راهنما ، به یک

سرور مجازی اوبونتو 20.04 که دارای یک کاربر غیر ریشه با امتیازات sudo و دارای یک فایروال اساسی است ، نیاز دارید. می توانید با دنبال کردن راهنمای راه اندازی

سرور مجازی اولیه ما این کار را تنظیم کنید.
مرحله 1 – نصب و پیکربندی Redis
ما از مدیر بسته APT برای نصب مجدد مخازن رسمی اوبونتو استفاده خواهیم کرد. از این نوشتار ، نسخه موجود در مخازن پیش فرض 5.0.7 است.
با به روز کردن حافظه نهان بسته محلی apt خود شروع کنید:
$ sudo apt update

سپس Redis را با تایپ این دستور نصب کنید:
$ sudo apt install redis-server

با این کار Redis و متعلقات آن دانلود و نصب می شوند. پس از این ، یک تغییر پیکربندی مهم برای ایجاد در فایل پیکربندی Redis وجود دارد که به طور خودکار در حین نصب ایجاد می شود.
این فایل را با ویرایشگر متن مورد نظر خود باز کنید:
$ sudo nano /etc/redis/redis.conf

در داخل فایل ، دستورالعمل supervised را پیدا کنید. این دستورالعمل به شما امکان می دهد سیستم شروع را برای مدیریت Redis به عنوان یک سرویس اعلام کنید و کنترل بیشتری بر عملکرد آن به شما ارائه می دهد. دستورالعمل supervised به صورت پیش فرض تنظیم نشده است. از آنجا که شما اوبونتو را اجرا می کنید ، که از سیستم شروع systemd استفاده می کند ، این را به systemd تغییر دهید:
/etc/redis/redis.conf
. . .

# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
# supervised no – no supervision interaction
# supervised upstart – signal upstart by putting Redis into SIGSTOP mode
# supervised systemd – signal systemd by writing READY=1 to $NOTIFY_SOCKET
# supervised auto – detect upstart or systemd method based on
# UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal process is ready.”
# They do not enable continuous liveness pings back to your supervisor.
supervised systemd

. . .

این تنها تغییری است که در این مرحله باید در فایل پیکربندی Redis انجام دهید ، بنابراین پس از اتمام آن را ذخیره کنید و ببندید. اگر از nano برای ویرایش فایل استفاده کرده اید ، این کار را با فشار دادن CTRL + X ، Y ، سپس enter انجام دهید.
سپس ، سرویس Redis را مجدداً راه اندازی کنید تا تغییراتی که در فایل پیکربندی ایجاد کرده اید اعمال شوند:
$ sudo systemctl restart redis.service

با این کار ، شما Redis را نصب و پیکربندی کرده اید و در دستگاه شما کار می کند. با این حال ، قبل از شروع استفاده از آن ، بهتر است برای احتیاط ابتدا بررسی کنید که آیا Redis عملکرد صحیحی دارد یا خیر.
مرحله 2 – تست Redis
مانند هر نرم افزاری که به تازگی نصب میشود ، بهتر است که قبل از ایجاد هرگونه تغییر بیشتر در پیکربندی آن ، از عملکرد Redis مطابق آنچه انتظار می رود ، اطمینان حاصل کنیم. ما چند روش را برای بررسی اینکه Redis در این مرحله به درستی کار می کند ، مرور میکنیم.
ابتدا بررسی کنید سرویس Redis در حال اجراست:
$ sudo systemctl status redis

اگر بدون خطا در حال اجرا باشد ، این دستور خروجی مشابه زیر را ایجاد می کند:
Output
● redis-server.service – Advanced key-value store
Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-04-30 23:26:54 UTC; 4s ago
Docs: http://redis.io/documentation,
man:redis-server(1)
Process: 36552 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
Main PID: 36561 (redis-server)
Tasks: 4 (limit: 2345)
Memory: 1.8M
CGroup: /system.slice/redis-server.service
└─36561 /usr/bin/redis-server 127.0.0.1:6379
. . .

در اینجا ، می بینید که Redis در حال اجرا فعال شده است ، به این معنی که هر بار که

سرور مجازی بوت شود ، راه اندازی می شود.
توجه: این تنظیمات برای بسیاری از موارد استفاده رایج از Redis مطلوب است. اما اگر ترجیح می دهید هر بار که

سرور مجازی خود را راه اندازی میکنید ، Redis را به صورت دستی راه اندازی کنید ، می توانید این کار را با دستور زیر تنظیم کنید:
$ sudo systemctl disable redis

برای آزمایش عملکرد صحیح Redis ، با استفاده از کلاینت خط فرمان به

سرور مجازی وصل شوید:
$ redis-cli

در اعلان زیر ، اتصال را با دستور ping تست کنید:
127.0.0.1:6379> ping

Output
PONG
این خروجی تأیید می کند که اتصال

سرور مجازی هنوز باقی است. در مرحله بعد ، بررسی کنید که می توانید با اجرای دستور زیر، کلیدها را تنظیم کنید:
127.0.0.1:6379> set test It’s working!”

Output
OK
مقدار را با تایپ این دستور بازیابی کنید:
127.0.0.1:6379> get test

با فرض اینکه همه چیز کار می کنید ، می توانید مقدار ذخیره شده خود را بازیابی کنید:
Output
It’s working!”
پس از تأیید این که می توانید مقدار را بدست آورید ، برای بازگشت به پوسته از قسمت Redis خارج شوید:
127.0.0.1:6379> exit

به عنوان یک آزمایش نهایی ، بررسی خواهیم کرد که آیا Redis قادر به حفظ داده حتی پس از متوقف شدن یا راه اندازی مجدد آن هست یا خیر. برای انجام این کار ، ابتدا نمونه Redis را ریستارت کنید:
$ sudo systemctl restart redis

سپس یک بار دیگر با کلاینت خط فرمان ارتباط برقرار کرده و تأیید کنید که مقدار تست شما هنوز در دسترس است:
$ redis-cli

مقدار کلید شما هنوز باید در دسترس باشد:
Output
It’s working!”
پس از اتمام دوباره از پوسته خارج شوید:
127.0.0.1:6379> exit

با این کار ، نصب Redis شما کاملاً عملیاتی است و برای استفاده شما آماده است. با این حال ، برخی از تنظیمات پیکربندی پیش فرض آن ناایمن است و فرصت حملات و دسترسی به

سرور مجازی و داده های آن را می دهد. مراحل باقیمانده در این آموزش ، روش های کاهش این آسیب پذیری ها را مطابق با وب سایت رسمی Redis ارائه میدهد. اگرچه این مراحل اختیاری است و اگر تصمیم به دنبال کردن آنها ندارید ، هنوز هم Redis کار خواهد کرد ، توصیه می شود آنها را انجام دهید تا امنیت سیستم شما بیشتر شود.
مرحله 3 – اتصال به localhost
به طور پیش فرض ، Redis فقط از localhost قابل دسترسی است. با این وجود ، اگر Redis را با پیروی از آموزش دیگری، نصب و پیکربندی کرده اید ، ممکن است فایل پیکربندی را به روز کرده باشید تا بتوانید از هرجای دیگر اتصالات را برقرار کنید. این روش به اندازه کافی برای اتصال به localhost مطمئن نیست.
برای اصلاح این مشکل ، فایل پیکربندی Redis را برای ویرایش باز کنید:
$ sudo nano /etc/redis/redis.conf

این خط را پیدا کرده و اطمینان حاصل کنید که باطل شده است (در صورت وجود # ، آن را حذف کنید):
/etc/redis/redis.conf
bind 127.0.0.1 ::1

پس از اتمام فایل را ذخیره کرده و ببندید (CTRL + X ، Y ، سپس ENTER را فشار دهید).
سپس ، سرویس را مجدداً راه اندازی کنید تا اطمینان حاصل شود که systemd تغییرات شما را خوانده است:
$ sudo systemctl restart redis

برای بررسی اینکه این تغییر به مرحله اجرا گذاشته شده است ، دستور netstat زیر را اجرا کنید:
$ sudo netstat -lnp | grep redis

Output
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 14222/redis-server
tcp6 0 0 ::1:6379 :::* LISTEN 14222/redis-ser

توجه: ممکن است دستور netstat به طور پیش فرض در سیستم شما در دسترس نباشد. در این صورت می توانید با دستور زیر آن را نصب کنید (به همراه تعدادی دیگر از ابزارهای مفید شبکه):
sudo apt install net-tools

این خروجی نشان می دهد که برنامه redis-server به localhost (127.0.0.1) متصل شده است و تغییری را که اخیراً در فایل پیکربندی ایجاد کرده اید ، نشان می دهد. اگر آدرس IP دیگری را در آن ستون مشاهده می کنید (به عنوان مثال 0.0.0.0) ، پس باید دوبار بررسی کنید که خط صحیح را باطل کرده اید و دوباره سرویس Redis را راه اندازی کنید.
اکنون که نصب Redis فقط به localhost گوش می کند ، انجام درخواست یا دسترسی به

سرور مجازی شما برای حمله گران دشوار خواهد بود. با این حال ، در حال حاضر Redis قبل از ایجاد تغییر در پیکربندی یا داده هایی که نگه میدارد ، از کاربران درخواست نمیکند که خود را تأیید کنند. برای رفع این مشکل ،Redis به شما امکان می دهد تا کاربران را قبل از ایجاد تغییر از طریق کلاینت Redis (redis-cli) با گذرواژه تأیید کنید.
مرحله 4 – پیکربندی رمز عبور Redis
پیکربندی رمز عبور Redis یکی از دو ویژگی امنیتی داخلی خود را ایجاد می کند – دستور auth ، که به تایید اعتبار کلاینت ها برای دسترسی به پایگاه داده نیاز دارد. رمز عبور مستقیماً در فایل پیکربندی Redis ، /etc/redis/redis.conf پیکربندی شده است ، بنابراین دوباره آن فایل را با ویرایشگر مورد نظر خود باز کنید:
$ sudo nano /etc/redis/redis.conf

به بخش SECURITY بروید و به دنبال دستورالعملی باشید که وظیفه خواندن را دارد:
/etc/redis/redis.conf
. . .
# requirepass foobared
. . .

با حذف # آن را لغو کنید و foobared را به یک رمزعبور امن تغییر دهید.
توجه: در بالای دستورالعمل requirepass در فایل redis.conf ، یک اخطار کامنت وجود دارد:
/etc/redis/redis.conf
. . .
# Warning: since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#
. . .
بنابراین ، مهم است که یک مقدار بسیار قوی و بسیار طولانی را به عنوان رمزعبور خود تعیین کنید. به جای ایجاد رمز عبور ، می توانید از دستور opensl برای ایجاد پسورد تصادفی استفاده کنید ، مانند مثال زیر. با اتصال خروجی دستور اول به دستور دوم opensl ، همانطور که در اینجا نشان داده شده است ، هرگونه وقفه بین خطوط را که توسط آن دستور اول ایجاد می شود حذف می کند:
$ openssl rand 60 | openssl base64 -A

خروجی شما اینگونه خواهد بود:
Output
RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

پس از کپی پیست کردن خروجی آن فرمان به عنوان مقدار جدید مورد نیاز ، باید این را بخواند:
$ sudo systemctl restart redis.service

پس از تنظیم گذرواژه ، فایل را ذخیره کرده و ببندید ، و Redis را ریستارت کنید:
$ redis-cli

در زیر توالی دستورات مورد استفاده برای تست رمز Redis وجود دارد. دستور اول سعی می کند قبل از تأیید اعتبار ، کلید را روی یک مقدار تنظیم کند:
127.0.0.1:6379> set key1 10

این رمز کار نخواهد کرد زیرا شما تأیید اعتبار نکردید ، بنابراین Redis خطایی را برمی گرداند:
Output
(error) NOAUTH Authentication required.

دستور بعدی با گذرواژه مشخص شده در فایل پیکربندی Redis تأیید اعتبار می کند:
127.0.0.1:6379> auth your_redis_password

Redis تصدیق می کند:
Output
OK
پس از آن ، اجرای دوباره فرمان قبلی موفق خواهد شد:
127.0.0.1:6379> set key1 10

Output
OK

get key1 مقدار کلید جدید را از Redis پرس و جو میکند.
127.0.0.1:6379> get key1

Output
10”

پس از تأیید اینکه می توانید پس از تایید اعتبار دستوراتی را در کلاینت Redis اجرا کنید ، می توانید از redis-cli خارج شوید:
127.0.0.1:6379> quit

در مرحله بعد ، تغییر نام دستورات Redis را بررسی خواهیم کرد که اگر به اشتباه یا توسط یک حمله گر مورد هدف قرار گیرد ، می تواند آسیب جدی به دستگاه شما وارد کند.
مرحله 5 – تغییر نام دستورات خطرناک
ویژگی امنیتی دیگر قرار داده شده در Redis تغییر نام یا غیرفعال کردن کامل فرامین خاصی است که خطرناک به نظر می رسند.
هنگامی که این دستورات توسط کاربران غیرمجاز اجرا می شوند ، می توانند برای پیکربندی ، از بین بردن یا پاک کردن داده های شما استفاده شوند. مانند گذرواژه تأیید اعتبار ، تغییر نام یا غیرفعال کردن دستورات در همان بخش SECURITY فایل /etc/redis/redis.conf پیکربندی شده است.
برخی از دستوراتی که خطرناک به حساب می آیند عبارتند از FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME, و DEBUG
این یک لیست جامع نیست ، اما تغییر نام یا غیرفعال کردن کلیه دستورات موجود در آن لیست ، نقطه شروع خوبی برای افزایش امنیت

سرور مجازی Redis شما است.
این که آیا شما باید یک فرمان را غیرفعال کنید یا تغییر نام دهید ، به نیازهای خاص شما یا نیازهای سایت شما بستگی دارد. اگر می دانید هرگز از دستوری که مورد سوءاستفاده قرار می گیرد استفاده نمی کنید ، می توانید آن را غیرفعال کنید. در غیر این صورت ، تغییر نام آن مفید خواهد بود.
برای فعال یا غیرفعال کردن دستورات Redis ، فایل پیکربندی را یک بار دیگر باز کنید:
$ sudo nano /etc/redis/redis.conf

هشدار: مراحل زیر نشانگر نحوه غیرفعال کردن و تغییر نام دستورات مثال است. شما فقط باید انتخاب کنید که که غیرفعال کردن یا تغییر نام چه دستوراتی منطقی میباشد. می توانید لیست کامل دستورات را برای خود مرور کنید و نحوه استفاده آنها در redis.io/commands را تعیین کنید.

برای تغییرنام یک فرمان، نام دیگری مانند زیر به آن بدهید. حدس زدن فرمان های تغییر نام یافته باید برای دیگران دشوار باشد اما به راحتی بتوانید آن ها را به خاطر بسپارید.
/etc/redis/redis.conf
. . .
# rename-command CONFIG ”
rename-command SHUTDOWN SHUTDOWN_MENOT
rename-command CONFIG ASC12_CONFIG
. . .

تغییرات خود را ذخیره کرده و فایل را ببندید.
پس از تغییر نام یک فرمان ، با راه اندازی مجدد Redis ، تغییر را اعمال کنید:
$ sudo systemctl restart redis.service

برای آزمایش دستور جدید ، وارد خط فرمان Redis شوید:
$ redis-cli

سپس ، تأیید اعتبار کنید:
127.0.0.1:6379> auth your_redis_password

Output
OK
فرض کنیم که شما دستور CONFIG را مانند مثال قبل به ASC12_CONFIGتغییر نام دادید . ابتدا سعی کنید از دستور اصلی CONFIG استفاده کنید. باید با شکست مواجه شود ، زیرا شما آن را تغییر نام داده اید:
127.0.0.1:6379> config get requirepass

Output
(error) ERR unknown command `config`, with args beginning with:

با این وجود فراخوانی فرمان تغییر نام داده شده موفقیت آمیز خواهد بود. به کوچک و بزرگ بودن کاراکترها حساس نیست:
127.0.0.1:6379> asc12_config get requirepass

Output
1) requirepass”
2) your_redis_password”

درنهایت ، می توانید از redis-cli خارج شوید:
127.0.0.1:6379> exit

توجه داشته باشید که اگر قبلاً از خط فرمان Redis استفاده کرده اید و دوباره Redis را ریستارت کرده اید ، باید مجددا تأیید اعتبار کنید. در غیر این صورت ، اگر یک دستور تایپ کنید ، این خطا را دریافت خواهید کرد:
Output
NOAUTH Authentication required.

به خاطر تغییر نام دستورات ، در پایان بخش SECURITY در /etc/redis/redis.conf یک عبارت احتیاط وجود دارد:
/etc/redis/redis.conf
. . .
# Please note that changing the name of commands that are logged into the
# AOF file or transmitted to replicas may cause problems.
. . .

توجه: پروژه Redis از اصطلاحات master” و slave” استفاده میکند ، در حالی که

vpsgol عموماً اصطلاحات primary” و secondary” را ترجیح می دهد به معنی اولیه و ثانویه.
برای جلوگیری از سردرگمی ، تصمیم گرفتیم که در اینجا از اصطلاحات استفاده شده در مستندات Redis استفاده کنیم.
این بدان معناست که اگر دستور تغییر نام یافته در فایل AOF نباشد ، یا اگر موجود باشد اما فایل AOF به slaves ارسال نشده باشد ، دیگر مشکلی وجود نخواهد داشت.
بنابراین ، هنگام تغییر نام دستورات ، این را به خاطر داشته باشید. بهترین زمان برای تغییر نام یک فرمان زمانی است که شما از ماندگاری AOF استفاده نمی کنید ، یا درست بعد از نصب ، یعنی قبل از استقرار برنامه مبتنی بر Redis.
هنگامی که از AOF استفاده می کنید و با یک نصب master slave سرو کار دارید ، این پاسخ را از صفحه صدور GitHub پروژه در نظر بگیرید.
بنابراین ، بهترین روش برای تغییر نام در مواردی از این دست ، این است که مطمئن شوید دستورات تغییر نام یافته به تمام مثال های نصب های master-slave اعمال میشود.
نتیجه
در این آموزش ، Redis را نصب و پیکربندی کرده اید ، تأیید کردید که نصب Redis شما به درستی کار می کند و از ویژگی های امنیتی داخلی استفاده کرده است تا در برابر حملات مخرب کمتر آسیب پذیر باشد.
به خاطر داشته باشید که پس از ورود شخصی به

سرور مجازی شما ، دور زدن ویژگی های امنیتی ویژه Redis که ما در آن قرار داده ایم بسیار آسان است. بنابراین ، مهمترین ویژگی امنیتی در

سرور مجازی Redis ، فایروال شماست (که در صورت پیروی از آموزش مقدماتی راه اندازی اولیه

سرور مجازی اولیه، آن را پیکربندی کرده اید) ، زیرا این کار پرش از آن حصار امنیتی را برای حمله گران بسیار دشوار می کند.

برچسب‌ها:nano, Redis, Ubuntu 20.04

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

نحوه نصب و ایمن سازی Redis در اوبونتو 18.04

سرور مجازی Ubuntu 18.04 را نشان می دهد.
پیش نیازها
برای تکمیل این راهنما ، به یک

سرور مجازی اوبونتو 18.04 که دارای یک کاربر غیر ریشه با امتیازات sudo و دارای یک فایروال اساسی است ، نیاز دارید. می توانید با دنبال کردن راهنمای راه اندازی

سرور مجازی اولیه ما این کار را تنظیم کنید.
پس از آماده شدن ، به عنوان کاربر sudo خود به

سرور مجازی Ubuntu 18.04 خود وارد شوید و در زیر ادامه دهید.
مرحله 1 – نصب و پیکربندی Redis
برای به دست آوردن آخرین نسخه Redis ، ما از apt برای نصب آن از مخزن رسمی اوبونتو استفاده خواهیم کرد.
حافظه نهان بسته محلی apt خود را به روز کنید و Redis را با تایپ دستور زیر نصب کنید:
$ sudo apt update

$ sudo apt install redis-server

. . .

این تنها تغییری است که در این مرحله باید در فایل پیکربندی Redis انجام دهید ، بنابراین پس از اتمام آن را ذخیره کنید و ببندید. سپس ، سرویس Redis را مجدداً راه اندازی کنید تا تغییراتی که در فایل پیکربندی ایجاد کرده اید اعمال شوند:
$ sudo systemctl restart redis.service

اگر بدون خطا در حال اجرا باشد ، این دستور خروجی مشابه زیر را ایجاد می کند:
Output
● redis-server.service – Advanced key-value store
Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2018-06-27 18:48:52 UTC; 12s ago
Docs: http://redis.io/documentation,
man:redis-server(1)
Process: 2421 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS)
Process: 2424 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
Main PID: 2445 (redis-server)
Tasks: 4 (limit: 4704)
CGroup: /system.slice/redis-server.service
└─2445 /usr/bin/redis-server 127.0.0.1:6379
. . .

در اینجا ، می بینید که Redis در حال اجرا فعال شده است ، به این معنی که هر بار که

برای آزمایش عملکرد صحیح Redis ، با استفاده از کلاینت خط فرمان به

سرور مجازی وصل شوید:
$ redis-cli

در اعلان زیر ، اتصال را با دستور ping تست کنید:
127.0.0.1:6379> ping

Output
PONG

این خروجی تأیید می کند که اتصال

Output
OK
مقدار را با تایپ این دستور بازیابی کنید:
127.0.0.1:6379> get test

سپس یک بار دیگر با کلاینت خط فرمان ارتباط برقرار کرده و تأیید کنید که مقدار تست شما هنوز در دسترس است:
$ redis-cli

127.0.0.1:6379> get test
مقدار کلید شما هنوز باید در دسترس باشد:
Output
It’s working!”
پس از اتمام دوباره وارد پوسته شوید:
127.0.0.1:6379> exit

این خط را پیدا کرده و اطمینان حاصل کنید که آن باطل است (در صورت وجود # ، آن را حذف کنید):
/etc/redis/redis.conf
bind 127.0.0.1 ::1

برای بررسی اینکه این تغییر به مرحله اجرا گذاشته شده است ، دستور netstat زیر را اجرا کنید:
$ sudo netstat -lnp | grep redis

Output
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 14222/redis-server
tcp6 0 0 ::1:6379 :::* LISTEN 1422

به بخش SECURITY بروید و به دنبال دستورالعملی باشید که وظیفه خواندن را دارد:
/etc/redis/redis.conf
# requirepass foobared

با حذف # آن را لغو کنید و foobared را به یک رمزعبور امن تغییر دهید.
توجه: در بالای دستورالعمل requirepass در فایل redis.conf ، یک اخطار کامنت وجود دارد:
# Warning: since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#

بنابراین ، مهم است که یک مقدار بسیار قوی و بسیار طولانی را به عنوان رمزعبور خود تعیین کنید. به جای ایجاد رمز عبور ، می توانید از دستور opensl برای ایجاد پسورد تصادفی استفاده کنید ، مانند مثال زیر. با اتصال خروجی دستور اول به دستور دوم opensl ، همانطور که در اینجا نشان داده شده است ، هرگونه وقفه بین خطوط را که توسط آن دستور اول ایجاد می شود حذف می کند:
$ openssl rand 60 | openssl base64 -A

خروجی شما باید شبیه به چیزی باشد
Output
RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

پس از کپی پیست کردن خروجی آن فرمان به عنوان مقدار جدید requirepass ، باید این را بخواند:
/etc/redis/redis.conf
requirepass RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

پس از تنظیم گذرواژه ، فایل را ذخیره کرده و ببندید ، و دوباره Redis را ریستارت کنید:
$ sudo systemctl restart redis.service

برای آزمایش اینکه رمز عبور کار می کند ، به خط فرمان Redis دسترسی پیدا کنید:
$ redis-cli

در زیر توالی دستورات مورد استفاده برای تست کار با رمز Redis وجود دارد. دستور اول سعی می کند قبل از تأیید اعتبار ، کلید را روی یک مقدار تنظیم کند:
127.0.0.16379> set key1 10

از آنجا که شما تأیید اعتبار نکردید ، کار نخواهد کرد . بنابراین Redis خطایی را برمی گرداند:
Output
(error) NOAUTH Authentication required.

دستور بعدی با گذرواژه مشخص شده در فایل پیکربندی Redis تأیید اعتبار می کند:
127.0.0.16379> auth your_redis_password

Redis تصدیق می کند:
Output
OK
پس از آن ، اجرای دوباره فرمان قبلی موفق خواهد شد:
127.0.0.16379> set key1 10

Output
OK

get key1 برای دریافت کلید جدید ، از Redis پرس و جو میکند.
127.0.0.16379> get key1

Output
10”

پس از تأیید اینکه می توانید بعد از تأیید اعتبار ، دستوراتی را در کلاینت Redis اجرا کنید ، می توانید از redis-cli خارج شوید:
127.0.0.16379> quit

در مرحله بعد ، تغییر نام دستورات Redis را بررسی خواهیم کرد که اگر به اشتباه یا توسط یک حمله گر وارد شود ، می تواند آسیب جدی به دستگاه شما وارد کند.
مرحله 5 – تغییر نام دستورات خطرناک
ویژگی امنیتی دیگر قرار داده شده در Redis تغییر نام یا غیرفعال کردن کامل فرامین خاصی است که خطرناک به نظر می رسند.
هنگامی که این دستورات توسط کاربران غیرمجاز اجرا می شوند ، می توانند برای پیکربندی ، از بین بردن یا پاک کردن داده های شما استفاده شوند. مانند گذرواژه تأیید اعتبار ، تغییر نام یا غیرفعال کردن دستورات در همان بخش SECURITY فایل /etc/redis/redis.conf پیکربندی شده است.
برخی از دستوراتی که خطرناک به حساب می آیند عبارتند از FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME, و DEBUG.
این یک لیست جامع نیست ، اما تغییر نام یا غیرفعال کردن کلیه دستورات موجود در آن لیست ، نقطه شروع خوبی برای افزایش امنیت

برای غیرفعال کردن یک دستور ، کافی است آن را به یک رشته خالی تغییر دهید (که توسط یک جفت علامت نقل قول بدون هیچ کاراکتری بین آنها مشخص شده است) ، همانطور که در زیر نشان داده شده:
/etc/redis/redis.conf
. . .
# It is also possible to completely kill a command by renaming it into
# an empty string:
#
rename-command FLUSHDB ”
rename-command FLUSHALL ”
rename-command DEBUG ”
. . .
برای تغییر نام یک فرمان ، مانند مثالهای زیر نام دیگری به آن بدهید. حدس دستورات تغییر نام یافته باید برای دیگران دشوار باشد ، اما یادآوری آن برای شما آسان باشد:
/etc/redis/redis.conf
. . .
# rename-command CONFIG ”
rename-command SHUTDOWN SHUTDOWN_MENOT
rename-command CONFIG ASC12_CONFIG
. . .

برای آزمایش دستور جدید ، وارد خط فرمان Redis شوید:
$ redis-cli

سپس ، تأیید اعتبار کنید:
127.0.0.1:6379> auth your_redis_password

Output
(error) ERR unknown command ‘config’

Output
1) requirepass”
2) your_redis_password”

درنهایت ، می توانید از redis-cli خارج شوید:
127.0.0.1:6379> exit

توجه: پروژه Redis از اصطلاحات master” و slave” استفاده میکند ، در حالی که

سرور مجازی Redis ، فایروال شماست (که در صورت پیروی از آموزش مقدماتی راه اندازی اولیه

برچسب‌ها:AOF, Github, master slave, primary

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

اضافه کردن فضای Swap در اوبونتو 20.04

یکی از راه های محافظت در برابر خطاهای اتمام حافظه در برنامه ها ، اضافه کردن فضای Swap به

سرور مجازی شما است. در این راهنما نحوه اضافه کردن فایل swap به یک

سرور مجازی Ubuntu 20.04 را پوشش خواهیم داد.
هشدار: اگرچه Swap برای سیستم هایی که از هارد دیسک های معمول چرخشی استفاده میکنند ، توصیه میشود اما قرار دادن Swap در SSD ها می تواند با گذشت زمان مشکلاتی را برای تخریب سخت افزار ایجاد کند. به همین دلیل ، ما امکان فعال کردن Swap در vpsgol یا هر ارائه دهنده دیگری که از حافظه SSD استفاده می کند را توصیه نمی کنیم.
Swap چیست؟
Swap بخشی از حافظه هارد دیسک است که برای سیستم عامل کنار گذاشته شده است تا داده هایی را که دیگر نمی تواند در RAM نگهداری کند ، به طور موقت ذخیره کند. این به شما امکان می دهد مقدار اطلاعاتی را که

سرور مجازی شما می تواند در حافظه کاری خود نگه دارد افزایش یابد. فضای Swap در هارد دیسک عمدتاً زمانی استفاده می شود که دیگر فضای کافی در حافظه رم برای نگهداری داده های برنامه وجود نداشته باشد.
اطلاعات ارسال شده روی دیسک به طور قابل توجهی کندتر از اطلاعات موجود در RAM خواهد بود ، اما سیستم عامل ترجیح می دهد داده های برنامه را در حافظه نگه داشته و از داده های قدیمی تر swap استفاده کند. به طور کلی ، داشتن فضای Swap به عنوان fallback برای زمانی که رم رو به اتمام است، می تواند یک شبکه ایمنی مناسب در برابر استثناهای اتمام حافظه در سیستم های با حافظه غیر SSD باشد.
مرحله 1 – بررسی سیستم برای اطلاعات Swap
قبل از شروع ، می توانیم بررسی کنیم که آیا سیستم از قبل فضای Swap در دسترس دارد یا خیر. ممکن است چندین فایل Swap یا پارتیشن swap داشته باشد ، اما به طور کلی یکی از آنها کافی می باشد.
با تایپ کردن این دستور می توانیم ببینیم که آیا این سیستم Swap پیکربندی شده دارد:
$ sudo swapon –show

اگر هیچ خروجی دریافت نکردید ، بدان معنی است که سیستم شما در حال حاضر فضای Swap در دسترس ندارد.
با استفاده از ابزار free می توانید تأیید کنید که هیچ Swap فعالی وجود ندارد:
$ free -h

Output
total used free shared buff/cache available
Mem: 981Mi 122Mi 647Mi 0.0Ki 211Mi 714Mi
Swap: 0B 0B 0B

همانطور که در ردیف Swap خروجی مشاهده می کنید ، هیچ Swap روی سیستم فعال نیست.
مرحله 2 – بررسی فضای موجود در پارتیشن هارد دیسک
قبل از ایجاد فایل Swap ، استفاده فعلی دیسک خود را بررسی خواهیم کرد تا مطمئن شویم که فضای کافی داریم. این کار را با وارد کردن دستور زیر انجام دهید:
$ df -h

Output
Filesystem Size Used Avail Use% Mounted on
udev 474M 0 474M 0% /dev
tmpfs 99M 932K 98M 1% /run
/dev/vda1 25G 1.4G 23G 7% /
tmpfs 491M 0 491M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 491M 0 491M 0% /sys/fs/cgroup
/dev/vda15 105M 3.9M 101M 4% /boot/efi
/dev/loop0 55M 55M 0 100% /snap/core18/1705
/dev/loop1 69M 69M 0 100% /snap/lxd/14804
/dev/loop2 28M 28M 0 100% /snap/snapd/7264
tmpfs 99M 0 99M 0% /run/user/1000

دستگاه با / در ستون Mounted on در این مورد دیسک ماست. در این مثال فضای زیادی در دسترس داریم (فقط از 1.4گیگ استفاده شده است). استفاده شما احتمالاً متفاوت خواهد بود.
اگرچه نظرات زیادی در مورد اندازه مناسب فضای swap وجود دارد ، اما واقعاً بستگی به ترجیحات شخصی شما و نیازهای برنامه شما دارد. به طور کلی ، مقداری برابر یا دو برابر مقدار RAM روی سیستم مناسب خواهد بود. یک قانون دیگر این است که اگر فقط از آن به عنوان fallback رم استفاده کنید ، احتمالاً چیزی بیش از 4 گیگ Swapنیاز نمیباشد.
مرحله 3 – ایجاد فایل swap
اکنون که فضای هارد دیسک موجود خود را می دانیم ، می توانیم یک فایل swap در سیستم فایل خود ایجاد کنیم. ما فایلی را به اندازه ای که می خواهیم به نام swapfile در دیرکتوری ریشه (/)خود قرار خواهیم داد.
بهترین راه برای ایجاد فایل swap با برنامه fallocate است. این دستور بلافاصله یک فایل با اندازه مشخص ایجاد می کند.
از آنجا که

سرور مجازی در مثال ما 1 گیگ RAM دارد ، ما یک فایل 1 گیگی را در این راهنما ایجاد خواهیم کرد. این رم را متناسب با نیازهای

سرور مجازی خود تنظیم کنید:
$ sudo fallocate -l 1G /swapfile

با تایپ این دستور می توانیم تأیید کنیم که مقدار صحیح فضا محفوظ است:
$ ls -lh /swapfile

$ -rw-r–r– 1 root root 1.0G Apr 25 11:14 /swapfile

فایل ما با مقدار صحیحی از فضای کنار گذاشته شده ایجاد شده است.
مرحله 4 – فعال کردن فایل swap
اکنون که فایلی با اندازه مناسب در دسترس داریم ، باید در عمل این را به فضای swap تبدیل کنیم.
ابتدا باید مجوزهای فایل را قفل کنیم تا فقط کاربرانی که دارای حق امتیاز هستند بتوانند مطالب را بخوانند. این کار مانع از دسترسی کاربران عادی به فایل می شود که پیامدهای امنیتی قابل توجهی دارد.
با تایپ کردن دستور زیر فایل فقط در دسترس ریشه قرار میگیرد:
$ sudo chmod 600 /swapfile

تغییر مجوزها را با تایپ دستور زیر تأیید کنید:
$ ls -lh /swapfile

Output
-rw——- 1 root root 1.0G Apr 25 11:14 /swapfile

همانطور که مشاهده می کنید ، فقط کاربر اصلی دارای پرچم های خواندن و نوشتن است.
اکنون می توانیم با تایپ کردن این دستور فایل را به عنوان فضای swap مشخص کنیم:
$ sudo mkswap /swapfile

Output
Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
no label, UUID=6e965805-2ab9-450f-aed6-577e74089dbf

پس از علامت گذاری فایل ، می توانیم فایل swap را فعال کنیم و به سیستم ما امکان استفاده از آن را می دهد:
$ sudo swapon /swapfile

با تایپ این دستور تأیید کنید که swap در دسترس است:
$ sudo swapon –show

Output
NAME TYPE SIZE USED PRIO
/swapfile file 1024M 0B -2
ما می توانیم بازده ابزار free را دوباره بررسی کنیم تا یافته هایمان را تأیید کنیم:
$ free -h

Output
total used free shared buff/cache available
Mem: 981Mi 123Mi 644Mi 0.0Ki 213Mi 714Mi
Swap: 1.0Gi 0B 1.0Gi

swap ما با موفقیت تنظیم شده است و سیستم عامل ما در صورت وم شروع به استفاده از آن خواهد کرد.
مرحله 5 – دائمی کردن فایل Swap
تغییرات اخیر ما فایل Swap بخش فعلی را فعال کرده است. اما اگر راه اندازی مجدد کنیم ،

سرور مجازی تنظیمات swap را به طور خودکار حفظ نمی کند. ما می توانیم با اضافه کردن فایل swap به فایل / etc / fstab خود ، این تنظیمات را تغییر دهیم.
از فایل / etc / fstab نسخه پشتیبان تهیه کنید تا در صورت بروز هرگونه خطا با مشکلی مواجه نشوید:
$ sudo cp /etc/fstab /etc/fstab.bak

با تایپ کردن این دستور اطلاعات فایل swap را به انتهای فایل / etc / fstab خود اضافه کنید:
$ echo ‘/swapfile none swap sw 0 0’ | sudo tee -a /etc/fstab

در مرحله بعدی برخی از تنظیماتی را میتوانیم به روز کنیم بررسی مینماییم تا فضای swap خود را تنظیم کنیم.
مرحله 6 – تنظیمات swap خود را تعیین کنید
چند گزینه وجود دارد که می توانید پیکربندی کنید که در عملکرد سیستم شما هنگام برخورد با swap تأثیر می گذارد.
تنظیم ویژگی Swappiness
پارامتر swappiness پیکربندی میکند که سیستم شما چند بار داده را از RAM به فضای swap در گردش قرار دهد. این مقدار بین 0 تا 100 است که درصد را نشان می دهد.
با مقادیر نزدیک به صفر ، هسته داده ها را به دیسک منتقل نمیکند مگر اینکه واقعا لازم باشد. به یاد داشته باشید ، تعامل با فایل swap هزینه بر” است زیرا مدت زمان زیادی نسبت به تعامل با RAM طول می کشد و می تواند باعث کاهش قابل توجه عملکرد شود. به طور کلی اعلام به سیستم مبنی بر متکی نبودن زیاد به swap ، باعث سریعتر شدن سیستم شما خواهد شد.
مقادیر نزدیک به 100 ، سعی می کنند تا داده های بیشتری را در swap قرار دهند تا فضای خالی RAM بیشتری حفظ کنند. بسته به مشخصات حافظه برنامه های شما یا آنچه از

سرور مجازی خود برای آن استفاده می کنید ، این کار ممکن است در بعضی موارد ارحج باشد.
می توانیم با تایپ کردن دستور زیر مقدار swappiness فعلی را مشاهده کنیم:
$ cat /proc/sys/vm/swappiness

Output
60

برای دسکتاپ ، تنظیم swappiness روی 60 مقدار بدی نیست. برای یک

سرور مجازی ، ممکن است بخواهید آن را به 0 نزدیک کنید.
ما می توانیم swappiness را با استفاده از دستور sysctl به مقدار دیگری تبدیل کنیم.
به عنوان مثال ، برای تنظیم swappiness روی 10 ، می توانیم تایپ کنیم:
$ sudo sysctl vm.swappiness=10

Output
vm.swappiness = 10

این تنظیم تا ریبوت بعدی ادامه خواهد داشت. ما می توانیم با اضافه کردن خط به فایل /etc/sysctl.conf ، این مقدار را به طور خودکار در ریستارت تنظیم کنیم:
$ sudo nano /etc/sysctl.conf

در پایین می توانید اضافه کنید:
/etc/sysctl.conf
vm.swappiness=10
پس از اتمام فایل را ذخیره کنید و ببندید.
تعیین تنظیمات فشار Cache
مقدار مرتبط دیگری که ممکن است بخواهید آن را تغییر دهید vfs_cache_pressure است. این تنظیمات چگونگی انتخاب سیستم برای ذخیره اطلاعات inode و dentry نسبت به سایر داده ها را پیکربندی می کند.
در اصل ، داده های دسترسی در مورد سیستم فایل است. به طور کلی جستجوی آن هزینه بر است و بسیار درخواست میشود، بنابراین یک حافظه پنهان برای سیستم شما بسیار عالی خواهد بود. با پرس و جوی مجدد سیستم فایل proc می توانید مقدار فعلی را مشاهده کنید:
$ cat /proc/sys/vm/vfs_cache_pressure

Output
100
همانطور که سیستم ما در حال حاضر پیکربندی شده است ، خیلی سریع اطلاعات inode را از حافظه نهان پاک می کند. می توانیم با تایپ کردن دستور زیر، میتوانیم آن را روی تنظیمات محافظه کارانه تری مانند 50 تنظیم کنیم:
$ sudo sysctl vm.vfs_cache_pressure=50

Output
vm.vfs_cache_pressure = 50

باز هم ، این فقط برای بخش فعلی ما معتبر است. ما می توانیم با اضافه کردن آن به فایل پیکربندی خود مانند تنظیمات swappiness آن را تغییر دهیم:
$ sudo nano /etc/sysctl.conf

در پایین ، خطی را اضافه کنید که مقدار جدید شما را مشخص می کند:
/etc/sysctl.conf
vm.vfs_cache_pressure=50

پس از اتمام فایل را ذخیره کنید و ببندید.
نتیجه
پیروی از مراحل موجود در این راهنما در مواردی که منجر به استثناهای اتمام حافظه شود ، به شما فضای تنفس می دهد. فضای swap می تواند برای جلوگیری از برخی از این مشکلات متداول فوق العاده مفید باشد.
اگر به خطاهای OOM (اتمام حافظه) برخورد می کنید ، یا می بینید که سیستم شما قادر به استفاده از برنامه های مورد نیاز شما نیست ، بهترین راه حل این است که تنظیمات برنامه خود را بهینه کنید یا

سرور مجازی خود را به روز کنید.

برچسب‌ها:fallback, RAM, SSD, swap

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

چگونه می توان فایروال را با UFW در اوبونتو 20.04 تنظیم کرد

UFW ، یا فایروال ساده (غیر پیچیده) ، یک رابط مدیریت ساده فایروال است که پیچیدگی فن آوری های فیلترینگ سطح پایین تر مانند iptables و nftables را پنهان می کند. اگر به دنبال شروع به کار در تأمین امنیت شبکه خود هستید و مطمئن نیستید از کدام ابزار استفاده کنید ، UFW میتواند انتخاب مناسبی برای شما باشد.
در این آموزش نحوه تنظیم فایروال با UFW در اوبونتو 20.04 به شما نشان داده خواهد شد.
پیش نیازها
برای دنبال کردن این آموزش ، به موارد زیر نیاز دارید:
• یک

سرور مجازی Ubuntu 20.04 با یک کاربر sudo غیر ریشه ، که می توانید با دنبال کردن ستاپ اولیه

سرور مجازی با آموزش اوبونتو 20.04 آن را تنظیم کنید.
UFW به طور پیش فرض در اوبونتو نصب شده است. اگر به دلایلی نصب نشده ، می توانید آن را با sudo apt install ufw نصب کنید.
مرحله 1 – استفاده از IPv6 با UFW (اختیاری)
این آموزش با در نظرگیری IPv4 نوشته شده است ، اما وقتی آن را فعال کنید ، برای IPv6 نیز کار خواهد کرد. اگر

سرور مجازی Ubuntu شما IPv6 را فعال کرده است ، اطمینان حاصل کنید که UFW برای پشتیبانی از IPv6 تنظیم شده باشد تا بتواند علاوه بر IPv4 ، قوانین فایروال را برای IPv6 نیز مدیریت کند. برای انجام این کار ، پیکربندی UFW را با nano یا ویرایشگر مورد علاقه خود باز کنید.
$ sudo nano /etc/default/ufw

سپس مطمئن شوید که مقدار IPV6 بله است. می بایست شبیه به این باشد:
/etc/default/ufw excerpt
IPV6=yes

فایل را ذخیره کنید و ببندید. حال ، هنگامی که UFW فعال است ، به گونه ای تنظیم می شود که قوانین IPv4 و IPv6 را بنویسید. با این حال ، قبل از فعال کردن UFW ، می خواهیم اطمینان حاصل کنیم که فایروال شما پیکربندی شده است تا به شما امکان اتصال از طریق SSH را بدهد. بیایید با تنظیم رویکرد پیش فرض شروع کنیم.
مرحله 2 – تنظیم رویکرد های پیش فرض
اگر به تازگی کار با فایروال را شروع کرده اید ، اولین قوانینی که باید تعریف کنید رویکرد پیش فرض شما هستند. این قوانین نحوه کنترل ترافیک را که صریحاً با سایر قوانین مطابقت ندارد ، کنترل می کنند. به طور پیش فرض ، UFW قرار است تمام اتصالات ورودی را رد کند و به همه اتصالات خروجی اجازه دهد. این بدان معناست که هرکسی که سعی در دستیابی به

سرور مجازی شما داشته باشد قادر به اتصال نخواهد بود ، در حالی که هر برنامه ای در

سرور مجازی قادر به دستیابی به دنیای خارج خواهد بود.
بیایید قوانین UFW را به صورت پیش فرض تنظیم کنیم ، بنابراین می توانیم اطمینان حاصل کنیم که شما قادر خواهید بود این آموزش را دنبال کنید. برای تنظیم پیش فرض های استفاده شده توسط UFW ، از این دستورات استفاده کنید:
$ sudo ufw default deny incoming

$ sudo ufw default allow outgoing

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

سرور مجازی ها باید به درخواست های دریافتی از کاربران خارجی پاسخ دهند. در ادامه به آن خواهیم پرداخت.
مرحله 3 – اجازه اتصال به SSH
اگر اکنون فایروال UFW خود را فعال کنیم ، تمام اتصالات ورودی را رد می کند. این بدان معناست که باید قوانینی را ایجاد کنیم که صریحاً اجازه ورود به اتصالات ورودی قانونی را بدهد – برای مثال اتصالات SSH یا HTTP- اگر میخواهیم

سرور مجازی ما به آن نوع درخواستها پاسخ دهد. اگر از

سرور مجازی ابری استفاده می کنید ، احتمالاً باید به اتصالات SSH ورودی اجازه دهید تا بتوانید به

سرور مجازی خود متصل شوید و مدیریت کنید.
برای پیکربندی

سرور مجازی خود جهت اجازه دادن به اتصالات SSH ، می توانید از این دستور استفاده کنید:
$ sudo ufw allow ssh

با این کار قوانین فایروال ایجاد می شود که به کلیه اتصالات در پورت 22 اجازه می دهد ، یعنی پورتی که Daemon SSH بطور پیش فرض در آن گوش می دهد. UFW می داند که پورت allow ssh به چه معنی است زیرا به عنوان یک سرویس در فایل / etc / service لیست شده است.
با این وجود ، ما در واقع می توانیم با مشخص کردن پورت به جای نام سرویس ، قانون معادل آن را بنویسیم. به عنوان مثال ، این دستور مانند دستور فوق کار می کند:
$ sudo ufw allow 22

اگر Daemon SSH خود را برای استفاده از پورت دیگری پیکربندی کرده اید ، باید پورت مناسب را مشخص کنید. به عنوان مثال ، اگر

سرور مجازی SSH شما پورت 2222 را گوش می دهد ، می توانید از این دستور برای اتصال در آن پورت استفاده کنید:
$ sudo ufw allow 2222

اکنون که فایروال شما پیکربندی شده است تا امکان اتصال SSH ورودی را فراهم کند ، می توانیم آن را فعال کنیم.
مرحله 4 – فعال کردن UFW
برای فعال کردن UFW ، از این دستور استفاده کنید:
$ sudo ufw enable

هشداری دریافت خواهید کرد که می گوید ممکن است این فرمان اتصالات SSH موجود را مختل کند. ما قبلاً یک قانون فایروال تنظیم کرده ایم که اتصالات SSH را امکان پذیر می سازد ، بنابراین میتوان ادامه داد. در پاسخ به اعلان y را وارد کنید و ENTER را بزنید.
فایروال اکنون فعال است. برای مشاهده قوانینی که تنظیم شده است ، دستور verbose status sudo ufw را اجرا کنید. بقیه این آموزش نحوه استفاده از UFW را با جزئیات بیشتر ، مانند قبول یا رد انواع مختلف اتصالات را ارائه می دهد.
مرحله 5 – اجازه برقراری سایر اتصالات
در این مرحله ، شما باید به سایر اتصالات مورد نیاز

سرور مجازی خود برای پاسخگویی اجازه دهید. اتصالاتی که شما باید به آنها اجازه دهید بستگی به نیازهای خاص شما دارد. خوشبختانه ، شما می دانید چگونه می توانید قوانینی را بنویسید که به اتصالات مبتنی بر نام سرویس یا پورت اجازه می دهد. ما قبلاً این کار را برای SSH در پورت 22 انجام دادیم.
HTTP در پورت 80 ، همان چیزی که

سرور مجازی های وب رمز گذاری نشده از آن استفاده می کنند ، از sudo ufw allow http یا sudo ufw allow 80 استفاده مینماید.
HTTPS در پورت 443 ، همان چیزی که

سرور مجازی های رمزگذاری شده از آن استفاده می کنند ، از sudo ufw allow https یا sudo ufw allow 443 استفاده مینماید.
به غیر از مشخص کردن پورت یا سرویس شناخته شده ، راه های دیگری برای اجازه سایر اتصالات وجود دارد.
محدوده های خاص پورت
شما می توانید محدوده پورت را با UFW مشخص کنید. برخی از برنامه ها به جای یک پورت واحد از پورت های مختلف استفاده می کنند.
به عنوان مثال ، برای اجازه دادن به اتصالات X11، که از پورت های 6000-6007 استفاده می کنند ، از این دستورات استفاده کنید:
$ sudo ufw allow 6000:6007/tcp

$ sudo ufw allow 6000:6007/udp

هنگام مشخص کردن محدوده پورت با UFW ، باید پروتکل (tcp یا udp) را مشخص کنید که قوانین باید روی آن اعمال شود. ما قبلاً به این موضوع اشاره نکرده ایم زیرا مشخص نکردن پروتکل، به طور خودکار به هر دو پروتکل اجازه می دهد ، که در اکثر موارد مطلوب است.
آدرس های IP خاص
هنگام کار با UFW ، می توانید آدرس IP را نیز مشخص کنید. به عنوان مثال ، اگر می خواهید از یک آدرس IP خاص مانند آدرس IP محل کار یا خانه 203.0.113.4 به اتصالات اجازه دهید ، باید from و سپس آدرس IP را مشخص کنید:
$ sudo ufw allow from 203.0.113.4

همچنین می توانید با افزودن to any port به اضافه شماره پورت ، پورت خاصی را تعیین کنید که آدرس IP مجاز به اتصال به آن باشد. به عنوان مثال ، اگر می خواهید 203.0.113.4 به پورت 22 (SSH) وصل شود ، از این دستور استفاده کنید:
$ sudo ufw allow from 203.0.113.4 to any port 22

زیرشبکه ها
اگر می خواهید به یک زیر شبکه از آدرس های IP اجازه دهید ، می توانید با استفاده از نماد CIDR این کار را برای مشخص کردن یک netmask انجام دهید. به عنوان مثال ، اگر می خواهید تمام آدرسهای IP از 203.0.113.1 تا 203.0.113.254 را مجاز کنید ، می توانید از این دستور استفاده کنید:
$ sudo ufw allow from 203.0.113.0/24

به همین ترتیب ، همچنین می توانید پورت مقصد را تعیین کنید که زیر شبکه 203.0.113.0/24 به آن وصل شود. باز هم ، ما از پورت 22 (SSH) به عنوان نمونه استفاده خواهیم کرد:
$ sudo ufw allow from 203.0.113.0/24 to any port 22

اتصالات به یک رابط شبکه خاص
اگر می خواهید یک قانون فایروال ایجاد کنید که فقط مربوط به یک رابط شبکه خاص باشد ، می توانید با مشخص کردن ” allow in on ” و به دنبال آن نام رابط شبکه ، این کار را انجام دهید.
ممکن است بخواهید قبل از ادامه ، رابط های شبکه خود را جستجو کنید. برای انجام این کار ، از این دستور استفاده کنید:
$ ip addr

Output Excerpt
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
. . .
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
. . .

خروجی هایلایت شده نشانگر نام های رابط شبکه است. معمولاً چیزی مانند eth0 یا enp3s2 نامگذاری میشوند.
بنابراین ، اگر

سرور مجازی شما یک رابط شبکه عمومی به نام eth0 دارد ، می توانید با این دستور ترافیک HTTP (پورت 80) را به آن مجاز کنید:
$ sudo ufw allow in on eth0 to any port 80

این کار به

سرور مجازی شما امکان می دهد درخواستهای HTTP را از طریق اینترنت عمومی دریافت کند.
یا اگر می خواهید به عنوان مثال

سرور مجازی پایگاه داده MySQL (پورت 3306) شما را به اتصالات رابط شبکه خصوصی eth1 گوش دهد ، می توانید از این دستور استفاده کنید:
$ sudo ufw allow in on eth1 to any port 3306

این دستور به

سرور مجازی های دیگر در شبکه خصوصی شما اجازه می دهد تا به پایگاه داده MySQL متصل شوند.
مرحله 6 – رد اتصالات
اگر رویکرد پیش فرض اتصالات ورودی را تغییر نداده اید ، UFW به گونه ای پیکربندی میشود تا تمام اتصالات ورودی را رد کند. به طور کلی ، این کار با مم کردن شما به ایجاد قوانینی که صریحاً اجازه ورود به پورت های خاص و آدرس های IP را میدهند ، فرایند ایجاد یک فایروال ایمن را ساده تر می کند.
با این وجود ، گاهی اوقات می خواهید اتصالات خاص را بر اساس آدرس IP منبع یا زیر شبکه رد کنید ، شاید به این دلیل که می دانید که

سرور مجازی شما از آنجا مورد حمله قرار می گیرد. همچنین ، اگر می خواهید رویکرد ورودی پیش فرض خود را به allow تغییر دهید (که توصیه نمی شود) ، لازم است برای هرگونه خدمات یا آدرسهای IP که نمی خواهید مجوزهای اتصال را ایجاد کنید ، قوانین deny را ایجاد کنید.
برای نوشتن قوانین deny (رد)، می توانید از دستوراتی که در بالا توضیح داده شده استفاده کنید ، و allow را با deny جایگزین کنید.
به عنوان مثال ، برای رد اتصالات HTTP ، می توانید از این دستور استفاده کنید:
$ sudo ufw deny http

یا اگر می خواهید تمام اتصالات را از 203.0.113.4 رد کنید ، می توانید از این دستور استفاده کنید:
$ sudo ufw deny from 203.0.113.4

حال اجازه دهید نگاهی به نحوه حذف قوانین بیندازیم.
مرحله 7 – حذف قوانین
دانستن چگونگی حذف قوانین فایروال به همان اندازه مهم است که بدانید چگونه می توانید آنها را ایجاد کنید. دو روش مختلف برای تعیین اینکه کدام قوانین باید حذف شوند وجود دارد: با شماره قانون یا با قانون واقعی (شبیه به نحوه تعیین قوانین هنگام ایجاد ان ها). ما با روش حذف با شماره قانون شروع خواهیم کرد زیرا ساده تر است.
به واسطه شماره قانون
اگر از شماره قانون برای حذف قوانین فایروال استفاده می کنید ، اولین کاری که باید انجام دهید این است که لیستی از قوانین فایروال خود را تهیه کنید. فرمان وضعیت UFW گزینه ای برای نمایش شماره ها در کنار هر قانون دارد ، همانطور که در اینجا نشان داده شده است:
$ sudo ufw status numbered

Numbered Output:
Status: active

To Action From
— —— —-
[ 1] 22 ALLOW IN 15.15.15.0/24
[ 2] 80 ALLOW IN Anywhere

اگر تصمیم بگیریم که می خواهیم قانون 2 را حذف کنیم ، یکی از مواردی که امکان اتصال به پورت 80 (HTTP) را فراهم می کند ، می توانیم آن را در یک فرمان حذف UFW مانند این مشخص کنیم:
$ sudo ufw delete 2

یک تأیید اعلان را نشان میدهد و سپس قانون 2 را، که به اتصالات HTTP اجازه می دهد، حذف میکند. توجه داشته باشید که اگر IPv6 را فعال کرده اید ، باید قانون IPv6 مربوطه را نیز حذف کنید.
به واسطه قانون واقعی
گزینه جایگزین برای شماره ها ، تعیین قانون واقعی برای حذف است. به عنوان مثال ، اگر می خواهید قانون http را حذف کنید ، می توانید آن را به صورت زیر بنویسید:
$ sudo ufw delete allow http

همچنین می توانید به جای نام سرویس ، قانون را با allow 80 مشخص کنید:
$ sudo ufw delete allow 80

این روش، در صورت وجود، هر دو قانون IPv4 و IPv6 را حذف می کند.
مرحله 8 – بررسی وضعیت و قوانین UFW
در هر زمان ، می توانید وضعیت UFW را با این دستور بررسی کنید:
$ sudo ufw status verbose

اگر UFW غیرفعال باشد ، که به طور پیش فرض چنین است ، خروجی زیر را مشاهده خواهید کرد:
Output
Status: inactive

اگر UFW فعال باشد ، که اگر مرحله 3 را دنبال کرده باشید ، فعال خواهد بود، خروجی می گوید که فعال است و قوانینی را که تنظیم شده لیست می کند. به عنوان مثال ، اگر فایروال تنظیم شود تا اتصالات SSH (پورت 22) را از هر مکانی امکان پذیر کند ، ممکن است خروجی چیزی شبیه به این باشد:
Output
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To Action From
— —— —-
22/tcp ALLOW IN Anywhere

اگر می خواهید بررسی کنید چگونه UFW فایروال را تنظیم کرده است ، از دستور وضعیت استفاده کنید.
مرحله 9 – غیرفعال کردن یا تنظیم مجدد UFW (اختیاری)
اگر تصمیم دارید که از UFW استفاده نکنید ، می توانید با این دستور آن را غیرفعال کنید:
$ sudo ufw disable

هر قانونی که با UFW ایجاد کرده باشید دیگر فعال نخواهد بود. اگر لازم باشد بعداً آن را فعال کنید ، همواره می توانید sudo ufw را اجرا کنید.
اگر قبلاً قوانین UFW را پیکربندی کرده اید اما تصمیم دارید که دوباره شروع کنید ، می توانید از دستور تنظیم مجدد استفاده کنید:
$ sudo ufw reset

با این کار UFW غیرفعال می شود و قوانینی را که قبلاً تعریف شده بودند حذف می شوند. به خاطر داشته باشید که اگر هر موقع آنها را تغییر دهید ، رویکرد پیش فرض به تنظیمات اصلی آنها تغییر نمی کند. این کار شروع تازه ای با UFW به شما ارائه میدهد.
نتیجه
فایروال شما اکنون پیکربندی شده است که (حداقل) اتصالات SSH را امکان پذیر کند. مطمئن شوید که هرگونه اتصالات ورودی دیگر که

سرور مجازی شما نیاز دارد امکان پذیر هستند ، و در عین حال اتصالات غیر ضروری را محدود میکند ، بنابراین

سرور مجازی شما عملکردی و ایمن خواهد بود.
برای کسب اطلاعات بیشتر در مورد تنظیمات رایج UFW ، از راهنمای ضروریات UFW: قوانین و فرمان های معمول فایروال استفاده کنید.

برچسب‌ها:Iptables, IPv4, IPv6, nftables, SSH

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

نظارت بر اطلاعیه و مسیر BGP با BGPalerter اوبونتو 18.04

BGP protocol Border Gateway یکی از پروتکل های اصلی مسئول مسیریابی بسته ها از طریق اینترنت است ، بنابراین هنگامی که اشتباه پیش برود ، ممکن است قطعی های قابل توجهی رخ دهد. به عنوان مثال ، در سال 2019 ، یک ISP کوچک یک پیکربندی غلط BGP ایجاد کرد که متأسفانه در بالادست منتشر شد و بخش های بزرگی از Cloudflare و AWS را بصورت آفلاین بیش از یک ساعت در اختیار گرفت. همچنین ، یک سال قبل ، یک BGP به منظور رهگیری ترافیک یک ارائه دهنده مشهور کیف پول ارز رمزی ربوده شد و وجوه مشتریان مورد سرقت قرار گرفت.
BGPalerter ابزاری منبع باز برای نظارت بر شبکه BGP است که می تواند هشدارهایی را در مورد فعالیت BGP در زمان واقعی ارائه دهد ، از جمله قابلیت مشاهده مسیر و اعلام مسیر جدید و همچنین فعالیت های بالقوه نامناسب مانند ربودن مسیر یا وجود نشتی اطلاعات در مسیر.
توجه: BGPalerter به طور خودکار اطلاعات مسیریابی شبکه را در دسترس عموم قرار می دهد ، به این معنی که دیگر نیازی به سطح دسترسی ممتاز یا ادغام شبکه (هایی) که مایل به نظارت آن هستید نمیباشد. کلیه نظارت ها کاملاً مطابق با قانون سوءاستفاده رایانه ای ، قانون ی کامپیوتری و سایر قوانین مشابه است. با این حال ، توصیه می شود هرگونه یافته مرتبط با اپراتور شبکه آسیب دیده را افشا کنید.

در این آموزش ،BGPalerter را نصب و پیکربندی می کنید تا شبکه های مهم خود را برای فعالیت های مشکوک پایش کنید.
پیش نیازها
برای تکمیل این آموزش ، به موارد زیر نیاز دارید:

سرور مجازی Ubuntu 18.04 که طبق راهنمای ستاپ اولیه

سرور مجازی با اوبونتو 18.04 راه اندازی، و شامل یک کاربر غیر ریشه sudo باشد.
یک یا چند شبکه یا دستگاهی که مایل به نظارت بر آن هستید، به عنوان مثال:
o

سرور مجازی که نگهداری می کنید
o شبکه شرکت تان
o ISP محلی تان
برای هر دستگاه یا شبکه باید آدرس IP شخصی ، محدوده آدرس IP یا شماره سیستم خودمختاری را که بخشی از آن است شناسایی کنید. این قسمت در مرحله 1 پوشانده شده است.
پس از آماده شدن ، به عنوان کاربر غیر ریشه خود وارد

سرور مجازی شوید.
مرحله 1 – شناسایی شبکه ها برای نظارت
در این مرحله جزئیات مربوط به شبکه هایی که می خواهید نظارت کنید را مشخص می کنید.
BGPalerter می تواند بر اساس آدرسهای IP یا پیشوندهای شبکه نظارت کند. همچنین می تواند براساس شماره سیستم خودمختار (AS) ، که یک شناساگر جهانی منحصر به فرد برای شبکه متعلق به یک نهاد اداری خاص است ، کل شبکه ها را رصد کند.
برای یافتن این اطلاعات ، می توانید از سرویس جستجوی IP-to-ASN WHOIS ارائه شده توسط سرویس هوشمند تهدید Team Cymru استفاده کنید. درواقع یک سرور WHOIS سفارشی است که به دنبال جستجوی آدرس IP و اطلاعات مسیریابی شبکه است.
اگر قبلاً whois را نصب نکرده اید ، می توانید آن را با استفاده از دستورات زیر نصب کنید:
$ sudo apt update

$ sudo apt install whois

پس از تأیید اینکه Whois نصب شده است ، با انجام جستجوی آدرس IP

سرور مجازی خود ، با استفاده از آرگومان -h برای تعیین

سرور مجازی اختصاصی ، شروع به کار کنید:
$ whois -h whois.cymru.com your-ip-address

با این کار نتیجه ای مشابه زیر حاصل می شود ، که نام و شماره AS را نشان می دهد که

سرور مجازی شما بخشی از آن است. این معمولاً به عنوان ارائه دهنده میزبان

سرور مجازی شما خواهد بود.
Output
AS | IP | AS Name
14061 | your-ip-address |

vpsgol-ASN, US

در مرحله بعد ، می توانید برای شناسایی پیشوند / گستره شبکه ای که

سرور مجازی شما بخشی از آن است ، یک جستجو انجام دهید. این کار را با اضافه کردن آرگومان -p به درخواست خود انجام می دهید:
$ whois -h whois.cymru.com ” -p your-ip-address”

خروجی بسیار شبیه به دستور قبلی خواهد بود ، اما پیشوند آدرس IP را که آدرس IP

vpsgol-ASN, US

در آخر ، می توانید جزئیات بیشتری از AS را که

سرور مجازی شما بخشی از آن است ، جستجو کنید ، از جمله منطقه جغرافیایی و تاریخ تخصیص.
در شماره AS که با استفاده از دستورات قبلی مشخص کرده اید جایگزین کنید. شما از آرگومان -v برای فعال کردن خروجی طویل استفاده می کنید ، که تضمین می کند تمام جزئیات مربوطه نشان داده شده اند:
$ whois -h whois.cymru.com ” -v as14061″

vpsgol-ASN, US

شما جزئیات اصلی در مورد شبکه (های) را که می خواهید نظارت کنید شناسایی کرده اید. یادداشتی از این جزئیات را در جایی نگه دارید ، زیرا بعداً به آنها احتیاج دارید. در مرحله بعد ، تنظیم BGPalerter را شروع می کنید.
مرحله 2 – ایجاد یک کاربر بدون امتیازت برای BGPalerter
در این مرحله ، یک حساب کاربری جدید بدون امتیازات برای BGPalerter ایجاد خواهید کرد ، زیرا این برنامه نیازی به اجرای امتیازات sudo / root ندارد.
در مرحله اول ، یک کاربر جدید با رمز عبور غیرفعال ایجاد کنید:
$ sudo adduser –disabled-password bgpalerter

نیازی به تنظیم گذرواژه یا کلیدهای SSH نیست ، زیرا از این کاربر فقط به عنوان یک حساب کاربری برای اجرا / نگهداری BGPalerter استفاده خواهید کرد.
با استفاده از su به کاربر جدید سوییچ کنید:
$ sudo su bgpalerter

اکنون به عنوان کاربر جدید وارد سیستم می شوید:
bgpalerter@droplet:/home/user$
برای رفتن به دیرکتوری اصلی کاربر جدید خود از دستور cd استفاده کنید:
bgpalerter@droplet:/home/user$ cd
bgpalerter@droplet:~$

یک کاربر جدید بدون امتیازت برای BGPalerter ایجاد کرده اید. در مرحله بعد ، BGPalerter را روی سیستم خود نصب و پیکربندی خواهید کرد.
مرحله 3 – نصب و پیکربندی BGPalerter
در این مرحله BGPalerter را نصب و پیکربندی می کنید. اطمینان حاصل کنید که هنوز به عنوان کاربر جدید بدون امتیازات خود وارد سیستم شده اید.
در مرحله اول ، برای اطمینان از دانلود جدیدترین نسخه ، باید آخرین نسخه BGPalerter را شناسایی کنید. به صفحه BGPalerter Releases بروید و یک کپی از لینک دانلود برای جدیدترین نسخه Linux x64 بگیرید.
اکنون می توانید یک کپی از BGPalerter را با استفاده از wget دانلود کنید ، مطمئن شوید که در لینک دانلود صحیح جایگزین می کنید:
$ wget https://github.com/nttgin/BGPalerter/releases/download/v1.24.0/bgpalerter-linux-x64

پس از اتمام دانلود فایل ، آن را به عنوان قابل اجرا علامت گذاری کنید:
$ chmod +x bgpalerter-linux-x64

در مرحله بعد ، با بررسی شماره نسخه ، بررسی کنید که BGPalerter دانلود و نصب شده است:
$ ./bgpalerter-linux-x64 –version

شماره نسخه فعلی را به خروجی می فرستد:
Output
1.24.0

قبل از اجرای صحیح BGPalerter ، باید شبکه هایی را که می خواهید نظارت کنید را در یک فایل پیکربندی مشخص کنید. فایل prefixes.yml را در ویرایشگر متن مورد علاقه خود ایجاد و باز کنید:
$ nano ~/prefixes.yml

در این فایل پیکربندی ، هر یک از آدرس های IP اختصاصی ، محدوده آدرس IP و شماره AS را که می خواهید نظارت کنید تعیین می کنید.
مثال زیر را اضافه کنید و مقادیر پیکربندی را مطابق نیاز با استفاده از اطلاعات شبکه ای که در مرحله 1 مشخص کرده اید تنظیم کنید:
~/prefixes.yml
your-ip-address/32:
description: My Server
asn:
– 14061
ignoreMorespecifics: false

157.230.80.0/20:
description: IP range for my Server
asn:
– 14061
ignoreMorespecifics: false

options:
monitorASns:
‘14061’:
group: default

شما می توانید بسیاری از محدوده های آدرس IP یا شماره AS را به صورت مورد نظر خود نظارت کنید. برای نظارت بر آدرسهای IP اختصاصی ، آنها را با استفاده از / 32 برای IPv4 و / 128 برای IPv6 نمایش دهید.
مقدار injoreMorespecifics برای این استفاده میشود که کنترل کند آیا BGPalerter باید فعالیت را برای مسیرهایی که خاص تر (کوچکتر) از مسیری که مشاهده می کنید ، هستند نادیده بگیرد یا خیر. به عنوان مثال ، اگر شما یک / 20 را رصد می کنید و یک تغییر مسیر برای یک / 24 در داخل آن تشخیص داده می شود ، به نظر می رسد خاص تر باشد. در بیشتر موارد ، نباید این موارد را نادیده بگیرید ، اما اگر در حال نظارت بر شبکه بزرگی با پیشوندهای مشتری نماینده متعدد هستید ، این کار ممکن است به کاهش نویز پس زمینه کمک کند.
اکنون می توانید برای اولین بار BGPalerter را برای شروع نظارت بر شبکه های خود اجرا کنید:
$ ./bgpalerter-linux-x64

اگر BGPalerter با موفقیت شروع شود ، خروجی مشابه زیر را مشاهده خواهید کرد. توجه داشته باشید که بعضی اوقات ممکن است چند دقیقه طول بکشد تا مانیتورینگ شروع شود:
Output
Impossible to load config.yml. A default configuration file has been generated.
BGPalerter, version: 1.24.0 environment: production
Loaded config: /home/bgpalerter/config.yml
Monitoring 157.230.80.0/20
Monitoring your-ip-address/32
Monitoring AS 14061

BGPalerter تا زمانی که با استفاده از Ctrl + C آن را متوقف کنید ، ادامه خواهد یافت.
در مرحله بعد برخی از هشدارهایی را که BGPalerter می تواند ایجاد کند ، تفسیر می کنید.
مرحله 4 – تفسیر هشدارهای BGPalerter
در این مرحله ، چند نمونه از هشدارهای BGPalerter را مرور می کنید. BGPalerter هشدارهایی را به عنوان منبع اصلی خروجی و همچنین به صورت اختیاری برای هر نقطه انتهایی گزارش اضافی ارسال می کند که می تواند در config.yml پیکربندی شود ، همانطور که در مستندات BGPalerter شرح داده شده است.
به طور پیش فرض ، BGPalerter در مورد موارد زیر هشدار می دهد:
ربوده شدن مسیر: هنگامی اتفاق می افتد که AS پیشوندی را که مجاز به آن نیست اعلام کند و باعث می شود ترافیک به اشتباه هدایت شود. این مسئله می تواند یک حمله عمدی باشد یا یک خطای پیکربندی تصادفی.
از دست رفتن دید در مسیر: وقتی اکثر روترهای BGP در اینترنت قادر به مسیریابی با اطمینان هستند ، یک مسیر قابل مشاهده است. از دست دادن دید به عدم امکان دسترسی شبکه شما مربوط می شود ، به عنوان مثال اگر همتای BGP شما متوقف شده باشد.
اطلاعیه های زیر پیشوند جدید: زمانی اتفاق میافتد که AS شروع به اعلام پیشوند می کند که از آنچه پیش بینی می شود کوچکتر باشد. این می تواند حاکی از تغییر پیکربندی عمدی ، پیکربندی غلط تصادفی یا در برخی موارد نشانگر حمله باشد.
فعالیت در AS: معمولاً به اطلاعیه های جدید مسیر اشاره می کند. اگر BGPalerter هنوز از آن آگاهی نداشته باشد ، به صورت new” در نظر گرفته می شود.
در زیر برخی از هشدارهای مثال ، همراه با توضیحی کوتاه از معنای آنها آمده است:
Alert #1
The prefix 203.0.113.0/24 is announced by AS64496 instead of AS65540

این هشدار شواهدی از ربودن مسیر را نشان می دهد ، جایی که جایی که AS64496 ، 203.0.113.0/24 را اعلام کرده است ولی پیش بینی می شود این مسیر توسط AS65540اعلام شود. این یک نشانگر قوی از تنظیم نادرست منجر به نشت مسیر یا ربوده شدن عمدی توسط یک مهاجم میباشد.
Alert #2
The prefix 203.0.113.0/24 has been withdrawn. It is no longer visible from 6 peers

این هشدار نشان می دهد که شبکه 203.0.113.0/24 دیگر قابل مشاهده نیست. که ممکن است به دلیل یک مشکل مسیریابی در بالادست باشد یا یک روتر دچار نقص برق شده باشد.
Alert #3
A new prefix 203.0.113.0/25 is announced by AS64496. It should be instead 203.0.113.0/24 annou

این هشدار نشان می دهد که پیشوند خاص تری در جایی که پیش بینی نشده است اعلام شده است ، برای مثال با اعلام یک / 25 هنگامی که فقط یک / 24 انتظار می رود. به احتمال زیاد یک پیکربندی نادرست است ، اما در برخی موارد می تواند شواهدی از ربودن مسیر باشد.
Alert #4
AS64496 is announcing 192.0.2.0/24 but this prefix is not in the configured list of

در نهایت ، این هشدار نشان می دهد که AS64496 پیشوندی را اعلام کرده است که BGPalerter هنوز از آن چیزی نمی داند. این امر می تواند به این دلیل باشد که شما به طور قانونی پیشوند جدید را اعلام می کنید ، یا می تواند نشان دهنده پیکربندی غلط باشد و منجر به این شود که به طور اتفاقی پیشوند متعلق به شخص دیگری را اعلام کنید.
در این مرحله ، شما چندین نمونه از هشدارهای BGPalerter را مرور کردید. در مرحله بعد ، BGPalerter را پیکربندی می کنید تا به طور خودکار در بوت اجرا شود.
مرحله 5 – شروع BGPalerter در Boot
در این مرحله آخر ، BGPalerter را پیکربندی می کنید تا در بوت اجرا شود.
اطمینان حاصل کنید که هنوز به عنوان کاربر جدید بدون امتیازت در سیستم هستید و سپس ویرایشگر crontab را باز کنید:
$ crontab -e

در مرحله بعد ، ورودی زیر را در انتهای فایل crontab اضافه کنید:
crontab
@reboot sleep 10; screen -dmS bgpalerter ./bgpalerter-linux-x64”

هر بار که سیستم شما بوت می شود ، یک بخش screen جداشده با نام bgpalerter” ایجاد می کند و BGPalerter را در داخل آن شروع می کنید.
ویرایشگر crontab را ذخیره کرده و از آن خارج شوید. اکنون می توانید سیستم خود را ریبوت کنید تا مطمئن شوید که BGPalerter به درستی از بوت شروع می شود.
ابتدا باید از کاربر BGPalerter خود خارج شوید:
$ logout

سپس با ریبوت عادی سیستم ادامه دهید:
$ sudo reboot

پس از ریبوت سیستم ، دوباره به

سرور مجازی خود وارد شوید و برای دسترسی دوباره به کاربر BGPalerter خود ، از su استفاده کنید:
$ sudo su bgpalerter

سپس می توانید در هر زمان به بخش وصل شوید تا خروجی BGPalerter را مشاهده کنید:

$ screen -r bgpalerter

در این مرحله آخر ، شما BGPalerter را پیکربندی کرده اید تا در بوت اجرا شود.
نتیجه
در این مقاله BGPalerter را تنظیم کرده اید و از آن برای نظارت بر شبکه برای تغییرات مسیریابی BGP استفاده می کنید.
اگر می خواهید BGPalerter کاربر پسندتر شود ، می توانید آن را برای ارسال هشدار به کانال Slack از طریق یک webhook پیکربندی کنید:
Configure Slack Reporting for BGPalerter
اگر می خواهید در مورد خود BGP اطلاعات بیشتری کسب کنید ، اما به یک محیط تولید BGP دسترسی ندارید ، میتوانید از DN42 برای آزمایش BGP در یک محیط امن و منزوی بهره ببرید:
Decentralized Network 42

برچسب‌ها:BGP, BGPalerter, Cloudflare, sudo

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

نصب و ایمن سازی phpMyAdmin در اوبونتو 20.04

در حالی که بسیاری از کاربران به عملکرد سیستم مدیریت دیتابیس مانند MySQL احتیاج دارند ، ممکن است از تعامل با سیستم فقط از طریق MySQL احساس راحتی نداشته باشند.
phpMyAdmin به گونه ای ایجاد شده است که کاربران بتوانند از طریق یک رابط وب با MySQL در تعامل باشند. در این راهنما ، ما در مورد نحوه نصب و ایمن سازی phpMyAdmin بحث خواهیم کرد تا بتوانید با اطمینان از آن استفاده کنید تا پایگاه های داده خود را بر روی سیستم Ubuntu 20.04 مدیریت کنید.
پیش نیازها
برای تکمیل این راهنما ، به موارد زیر نیاز دارید:
•

سرور مجازی Ubuntu 20.04. این

سرور مجازی باید دارای یک کاربر غیر ریشه با امتیازات ادمین و فایروال تنظیم شده با ufw باشد. برای تنظیم این برنامه ، راهنمای تنظیم اولیه

سرور مجازی برای اوبونتو 20.04 را دنبال کنید.
• یک پشته LAMP (Linux ، Apache ، MySQL و PHP) که روی

سرور مجازی Ubuntu 20.04 شما نصب شده باشد. اگر این کار هنوز انجام نشده است ، می توانید در مورد نصب پشته LAMP در اوبونتو 20.04 این راهنما را دنبال کنید.
علاوه بر این ، هنگام استفاده از نرم افزارهایی مانند phpMyAdmin ملاحظات امنیتی مهمی وجود دارد ، زیرا:
• به طور مستقیم با نصب MySQL شما ارتباط برقرار میکند
• احراز هویت را با استفاده از اعتبارات MySQL انجام می دهد
• نتایج را برای پرس و جوهای SQL دلخواه اجرا می کند و برمیگرداند
به همین دلایل ، و از آنجا که یک برنامه PHP با استقرار گسترده است که غالباً مورد حمله قرار می گیرد ، هرگز نباید phpMyAdmin را روی سیستم های از راه دور از طریق اتصال HTTP ساده اجرا کنید.
اگر دامنه موجود را با گواهی SSL / TLS پیکربندی نکرده اید ، می توانید این راهنما را در زمینه ایمن سازی Apache با Let’s encrypt در Ubuntu 20.04 دنبال کنید. با این کار شما نیاز به ثبت دامنه ، ایجاد رکوردهای DNS برای

سرور مجازی خود و تنظیم یک هاست مجازی Apache دارید.
مرحله 1 – نصب phpMyAdmin
می توانید از APT برای نصب phpMyAdmin از مخازن پیش فرض اوبونتو استفاده کنید.
به عنوان کاربر sudo غیر ریشه شما ، ایندکس بسته

سرور مجازی خود را به روز کنید:
⦁ $ sudo apt update
⦁
پس از آن می توانید بسته phpmyadmin را نصب کنید. در کنار این بسته ، مستندات رسمی همچنین به شما توصیه می کنند که چند پسوند PHP را روی

سرور مجازی خود نصب کنید تا قابلیت های خاص و عملکرد آن را بهبود بخشید.
اگر آموزش پیش نیاز LAMP stack را دنبال کرده باشید ، چندین مورد از این ماژول ها به همراه بسته php نصب شده اند. با این حال ، توصیه می شود که این بسته ها را نیز نصب کنید:
⦁ php-mbstring: ماژولی برای مدیریت رشته های غیر ASCII و تبدیل رشته ها به رمزگذاری های مختلف
⦁ php-zip: این افزونه از آپلود فایلهای zip در phpMyAdmin پشتیبانی می کند
⦁ php-gd: پشتیبانی از کتابخانه GD Graphics را فعال می کند
⦁ php-json: پشتیبانی از PHP را برای سریال سازی JSON فراهم می کند
⦁ php-curl: به PHP اجازه می دهد تا با انواع مختلفی از

سرور مجازی ها با استفاده از پروتکل های مختلف ارتباط برقرار کند
برای نصب این بسته ها روی سیستم خود دستور زیر را اجرا کنید. لطفاً توجه داشته باشید که مراحل نصب نیاز دارد انتخاب هایی را برای پیکربندی صحیح phpMyAdmin انجام دهید. مختصر این انتخاب ها را بررسی میکنیم:
⦁ $ sudo apt install phpmyadmin php-mbstring php-zip php-gd php-json php-curl
⦁
در اینجا گزینه هایی که باید هنگام درخواست از شما برای پیکربندی صحیح نصب خود انتخاب کنید، آمد اند:
• برای انتخاب

سرور مجازی ، apache2 را انتخاب کنید
هشدار: هنگامی که اعلان ظاهر می شود ، apache2” هایلایت می شود ، اما انتخاب نشده است. اگر برای انتخاب Apache ، SPACE نزنید ، نصب کننده هنگام نصب ، فایلهای لازم را جابجا نمی کند. برای انتخاب Apache ، کلید SPACE ، TAB و سپس ENTER را بزنید.
• وقتی از شما سؤال شد که آیا از dbconfig-Common برای راه‌اندازی پایگاه داده استفاده کنید ، yes را انتخاب کنید
• سپس از شما خواسته می شود رمزعبور برنامه MySQL را برای phpMyAdmin انتخاب و تأیید کنید
توجه: به فرض اینکه MySQL را با پیروی از مرحله 2 آموزش پیش نیاز پشته LAMP نصب کرده اید ، ممکن است تصمیم گرفته باشید که افزونه Validate Password را فعال کنید. همانند این مقاله ، هنگام تلاش برای تنظیم گذرواژه برای کاربر phpmyadmin ، فعال کردن این مؤلفه خطایی را ایجاد می کند:

برای برطرف کردن این گزینه گزینه abort را انتخاب کنید تا مراحل نصب متوقف شود. سپس اعلان MySQL را باز کنید:
⦁ $ sudo mysql
⦁
یا اگر احراز هویت رمز عبور را برای کاربر ریشه MySQL فعال کرده اید ، این دستور را اجرا کرده و در صورت درخواست ، رمزعبور خود را وارد کنید:
⦁ $ mysql -u root -p
⦁
از اعلان ، دستور زیر را برای غیرفعال کردن مؤلفه Validate Password اجرا کنید. توجه داشته باشید که این کار در واقع آن را حذف نمی کند ، بلکه فقط لود مؤلفه در

سرور مجازی MySQL را متوقف میکند:
⦁ Mysql> UNINSTALL COMPONENT file://component_validate_password”;
⦁
پس از آن ، می توانید کلاینت MySQL را ببندید:
⦁ Mysql> exit
⦁
سپس مجدداً بسته phpmyadmin را نصب کنید و مطابق آنچه انتظار می رود کار خواهد کرد:
⦁ $ sudo apt install phpmyadmin
⦁
پس از نصب phpMyAdmin ، می توانید یک بار دیگر MySQL را با sudo mysql یا mysql -u root -p باز کنید و سپس دستور زیر را اجرا کنید تا مجدداً Validate Password را فعال کنید:
⦁ Mysql> INSTALL COMPONENT file://component_validate_password”;
⦁

فرآیند نصب فایل پیکربندی phpMyAdmin Apache را به دیرکتوری / etc / apache2 / conf-enabled / اضافه می کند ، جایی که به طور خودکار خوانده می شود. برای به پایان رساندن پیکربندی Apache و PHP برای کار با phpMyAdmin ، تنها کار باقیمانده در این بخش از آموزش این است که بطور صریح افزونه mbstring PHP را فعال کنید ، که می توانید با تایپ کردن این دستور این کار را انجام دهید:
⦁ $ sudo phpenmod mbstring
⦁
پس از آن ، Apache را مجدداً راه اندازی کنید تا تغییرات شما به رسمیت شناخته شود:
⦁ $ sudo systemctl restart apache2
⦁
اکنون phpMyAdmin برای کار با Apache نصب و تنظیم شده است. با این حال قبل از اینکه بتوانید وارد شوید و تعامل خود را با پایگاه داده های MySQL شروع کنید ، باید اطمینان حاصل کنید که کاربران MySQL از امتیازات لازم برای تعامل با برنامه برخوردار هستند.
مرحله 2 – تنظیم تأیید اعتبار و امتیازات کاربر
وقتی phpMyAdmin را بر روی

سرور مجازی خود نصب کردید ، به طور خودکار کاربر پایگاه داده ای به نام phpmyadmin ایجاد کرد که فرآیندهای پایه خاصی را برای این برنامه انجام می دهد. به جای اینکه به عنوان این کاربر با گذرواژه اداری که در حین نصب تنظیم کرده اید وارد شوید ، توصیه می شود که به عنوان کاربر ریشه MySQL یا به عنوان کاربر اختصاصی برای مدیریت پایگاه داده از طریق رابط phpMyAdmin وارد شوید.
پیکربندی دسترسی رمز ورود برای حساب ریشه MySQL
در سیستم های اوبونتو که MySQL 5.7 (و نسخه های بعدی) را اجرا می کنند ، تأیید اعتبار کاربر ریشه MySQL بصورت پیش فرض با استفاده از افزونه auth_socket و نه با گذرواژه تنظیم شده است. این امر امکان امنیت و قابلیت استفاده بیشتر را در بسیاری از موارد فراهم می کند ، اما همچنین می تواند مواردی را پیچیده تر کند که شما نیاز به دسترسی به یک برنامه خارجی – مانند phpMyAdmin – برای دسترسی به کاربر دارید.
برای ورود به سیستم phpMyAdmin به عنوان کاربر ریشه MySQL ، باید روش احراز هویت آن را از auth_socket به شخصی که از رمز عبور استفاده می کند ، تغییر دهید ، اگر قبلاً این کار را نکرده اید. برای این کار ، اعلان MySQL را از پایانه خود باز کنید:
⦁ $ sudo mysql
⦁
سپس ، با دستور زیر بررسی کنید که هر یک از حسابهای کاربری MySQL از کدام روش تأیید اعتبار استفاده میکنند:
⦁ Mysql> SELECT user,authentication_string,plugin,host FROM mysql.user;
⦁
Output
+——————+——————————————-+———————–+———–+
| user | authentication_string | plugin | host |
+——————+——————————————-+———————–+———–+
| root | | auth_socket | localhost |
| mysql.session | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE | caching_sha2_password | localhost |
| mysql.sys | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE | caching_sha2_password | localhost |
| debian-sys-maint | *8486437DE5F65ADC4A4B001CA591363B64746D4C | caching_sha2_password | localhost |
| phpmyadmin | *5FD2B7524254B7F81B32873B1EA6D681503A5CA9 | caching_sha2_password | localhost |
+——————+——————————————-+———————–+———–+
5 rows in set (0.00 sec)

در این مثال ، می بینید که کاربر اصلی با استفاده از افزونه auth_socket ، در واقع تأیید اعتبار می کند. برای پیکربندی حساب اصلی برای تأیید اعتبار با یک رمز عبور ، دستور ALTER USER زیر را اجرا کنید. حتما گذرواژه را به رمز عبور قوی تغییر دهید:
⦁ Mysql> ALTER USER ‘root’@’localhost’ IDENTIFIED WITH caching_sha2_password BY ‘password’;
⦁

توجه: جمله قبلی ALTER USER کاربر ریشه MySQL را برای تأیید اعتبار با افزونه caching_sha2_password تنظیم می کند. طبق اسناد رسمی MySQL ، caching_sha2_password افزونه تأیید هویت MySQL است ، زیرا رمزگذاری پسورد ایمن تری نسبت به نسخه قدیمی ارائه میدهد ، اما هنوز به طور گسترده استفاده می شود ، mysql_native_password.
با این حال ، برخی از نسخه های PHP قابل اعتماد با caching_sha2_password کار نمی کنند. PHP گزارش داده است که این مشکل در PHP 7.4 رفع شده است ، اما اگر در هنگام تلاش برای ورود به سایت phpMyAdmin بعدا با خطایی روبرو شدید ، میتوانید به جای آن ،root را برای تأیید اعتبار خود تنظیم کنید.
⦁ Mysql> ALTER USER ‘root’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘password’;
⦁

می توانید از این خروجی مشاهده کنید که کاربر اصلی با استفاده از یک رمز عبور تأیید اعتبار می کند. اکنون می توانید
به عنوان کاربر اصلی خود با گذرواژه ای که در اینجا برای آن تنظیم کرده اید وارد رابط phpMyAdmin شوید.
پیکربندی دسترسی رمز ورود برای یک کاربر اختصاصی MySQL
از طرف دیگر ، برخی ممکن است عقیده داشته باشند که اتصال به phpMyAdmin با یک کاربر اختصاصی ، بیشتر با گردش کار آن ها تناسب دارد. برای انجام این کار ، یکبار دیگر پوسته MySQL را باز کنید:
⦁ $ sudo mysql
⦁
اگر احراز هویت رمز عبور را برای کاربر اصلی خود فعال کرده اید ، همانطور که در قسمت قبل توضیح داده شد ، لازم است دستور زیر را اجرا کنید و در صورت درخواست ، رمز ورود خود را وارد کنید:
⦁ $ mysql -u root -p
⦁
از آنجا ، یک کاربر جدید ایجاد کرده و یک رمزعبور قوی به آن بدهید:
⦁ Mysql> CREATE USER ‘sammy’@’localhost’ IDENTIFIED WITH caching_sha2_password BY ‘password’;
⦁

توجه: باز هم بسته به نوع نسخه PHP که نصب کرده اید ، ممکن است بخواهید کاربر جدید خود را به جای caching_sha2_password ، با mysql_native_password تأیید هویت کنید:
⦁ Mysql> ALTER USER ‘sammy’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘password’;
⦁
سپس به کاربر جدید خود امتیازات مناسب اعطا کنید. به عنوان مثال ، شما می توانید امتیازات کاربر را به تمام جداول موجود در دیتابیس و همچنین قدرت اضافه کردن ، تغییر و حذف امتیازهای کاربر با این دستور اعطا کنید:
⦁ Mysql> GRANT ALL PRIVILEGES ON *.* TO ‘sammy’@’localhost’ WITH GRANT OPTION;
⦁
پس از آن ، از پوسته MySQL خارج شوید:
⦁ Mysql> exit
⦁
اکنون می توانید با مراجعه به نام دامنه

سرور مجازی یا آدرس IP عمومی و به دنبال آن / phpmyadmin به رابط وب دسترسی پیدا کنید:
https://your_domain_or_IP/phpmyadmin

به عنوان روت یا با نام کاربری و رمزعبور جدیدی که پیکربندی کرده اید ، وارد رابط شوید.
وقتی وارد سیستم می شوید ، رابط کاربری را مشاهده خواهید کرد که چیزی شبیه به این خواهد بود:

اکنون که می توانید به phpMyAdmin متصل شده و با آنها ارتباط برقرار کنید ، تمام کارهایی که انجام شده است ، تضمین امنیت سیستم شما برای محافظت از آن در برابر مهاجمان است.
مرحله 3 – ایمن سازی نمونه phpMyAdmin
phpMyAdmin به دلیل فراگیر بودن آن ، یک هدف محبوب برای مهاجمین است و برای جلوگیری از دسترسی غیرمجاز باید مراقبت بیشتری کنید. یکی از ساده ترین راه های انجام این کار ، قرار دادن یک دروازه در جلوی کل برنامه با استفاده از ویژگی های تأیید اعتبار داخلی .htaccessدر Apache است.
برای انجام این کار ، ابتدا باید فایل .htaccessرا که با ویرایش فایل پیکربندی Apache نصب phpMyAdmin لغو شده را فعال کنید.
از ویرایشگر متن دلخواه خود برای ویرایش فایل phpmyadmin.conf که در دیرکتوری تنظیمات Apache شما قرار گرفته است ، استفاده کنید. در اینجا ، ما از nano استفاده خواهیم کرد:
⦁ $ sudo nano /etc/apache2/conf-available/phpmyadmin.conf
⦁
یک دستورالعمل AllowOverride All را در بخش <Directory / usr / share / phpmyadmin> فایل پیکربندی ، مانند این اضافه کنید:
/etc/apache2/conf-available/phpmyadmin.conf
<Directory /usr/share/phpmyadmin>
Options FollowSymLinks
DirectoryIndex index.php
AllowOverride All
. . .

وقتی این خط را اضافه کردید ، فایل را ذخیره کنید و ببندید. اگر از nano برای ویرایش فایل استفاده کرده اید ، این کار را با فشار دادن CTRL + X ، Y و سپس enter انجام دهید.
برای اجرای تغییراتی که ایجاد کرده اید ، Apache را مجدداً راه اندازی کنید:
⦁ $ sudo systemctl restart apache2
⦁
اکنون که استفاده از .htaccess را برای برنامه خود فعال کرده اید ، باید یک مورد از آن را ایجاد کنید تا در واقع برخی از اقدامات امنیتی را پیاده سازی کنید. برای موفقیت در این امر ، فایل باید در دیرکتوری برنامه کاربردی ایجاد شود. با تایپ کردن این دستور می توانید فایل لازم را ایجاد کرده و در ویرایشگر متن خود با امتیازات اصلی باز کنید:
⦁ $ sudo nano /usr/share/phpmyadmin/.htaccess
⦁
در این فایل اطلاعات زیر را وارد کنید:
/usr/share/phpmyadmin/.htaccess
AuthType Basic
AuthName Restricted Files”
AuthUserFile /etc/phpmyadmin/.htpasswd
Require valid-user

در اینجا منظور از هریک از این خطوط آورده شده است:
⦁ AuthType Basic: در این خط نوع تأیید هویت مورد استفاده شما مشخص می شود. این نوع، تأیید اعتبار رمز عبور را با استفاده از یک فایل رمز عبور پیاده سازی می کند.
⦁ AuthName: پیام را برای کادر گفتگوی تأیید اعتبار تنظیم می کند. شما باید آن را سری نگه دارید تا کاربران غیرمجاز هیچ اطلاعاتی درباره چیزی که محافظت می شود کسب نکنند.
⦁ AuthUserFile: مکان فایل رمز عبور را که برای تأیید اعتبار استفاده می شود را تعیین می کند. باید خارج از دایرکتوری هایی باشد که ارائه می شوند. به زودی این فایل را ایجاد خواهیم کرد.
⦁ Require valid-user : مشخص می کند که فقط کاربران معتبر باید به این منبع دسترسی داشته باشند. همان چیزی است که در واقع ورود کاربران غیرمجاز را متوقف می کند.
پس از اتمام ، فایل را ذخیره کنید و ببندید.
محلی که برای فایل رمز عبور خود انتخاب کردید /etc/phpmyadmin/.htpasswd بود. اکنون می توانید این فایل را ایجاد کرده و آن را به عنوان کاربر اولیه با ابزار htpasswd وارد کنید:
⦁ $ sudo htpasswd -c /etc/phpmyadmin/.htpasswd username
⦁
از شما خواسته می شود یک رمز عبور را برای کاربر مورد نظر خود انتخاب و تأیید کنید. پس از آن ، فایل با رمز عبور hashed که وارد کرده اید ایجاد می شود.
از شما خواسته می شود یک رمز عبور برای کاربر مورد نظر خود انتخاب و تأیید کنید. پس از آن ، فایل با رمز عبور hashed که وارد کرده اید ایجاد می شود.
⦁ $ sudo htpasswd /etc/phpmyadmin/.htpasswd additionaluser
⦁
اگر می خواهید یک کاربر اضافی وارد کنید ، باید بدون پرچم -c این کار را انجام دهید ، مانند این:
https://domain_name_or_IP/phpmyadmin

پس از وارد کردن شناسه Apache ، برای وارد کردن اعتبار MySQL به صفحه تأیید صحت phpMyAdmin منتقل می شوید. این تنظیم، لایه امنیتی بیشتری را اضافه می کند ، که از آنجایی که phpMyAdmin قبلا آسیب پذیر بود ، مطلوب خواهد بود.
نتیجه
اکنون باید phpMyAdmin را در

سرور مجازی Ubuntu 20.04 خود تنظیم و آماده استفاده کرده باشید. با استفاده از این رابط ، می توانید به راحتی پایگاه داده ، کاربران ، جداول و غیره ایجاد کرده و عملیات معمول مانند حذف و اصلاح ساختارها و داده ها را انجام دهید.

برچسب‌ها:Apache, LAMP stack, MySQL, phpMyAdmin

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

نصب و استفاده از Composer در اوبونتو 20.04

Composer یک ابزار مدیریت وابستگی محبوب برای PHP است که عمدتاً برای تسهیل نصب و به روزرسانی برای متعلقات پروژه ایجاد شده است. این ابزار بررسی خواهد کرد که یک پروژه خاص به چه بسته های دیگری متکی است و با استفاده از نسخه های مناسب با توجه به نیاز پروژه ، آنها را برای شما نصب می کند. Composer همچنین معمولاً برای راه اندازی پروژه های جدید بر اساس چارچوب های محبوب PHP مانند Symfony و Laravel استفاده می شود.
در این آموزش ، نصب و شروع Composer را روی یک سیستم Ubuntu 20.04 بررسی می کنید.
پیش نیازها
برای دنبال کردن این راهنما ، به عنوان یک کاربر sudo غیر ریشه به یک

سرور مجازی Ubuntu 20.04 و یک فایروال فعال شده روی

سرور مجازی خود نیاز دارید. برای انجام این کار، می توانید راهنمای تنظیم اولیه

سرور مجازی ما برای اوبونتو 20.04 را دنبال کنید.
مرحله 1 – نصب PHP و متعلقات اضافی
علاوه بر متعلقاتی که قبلاً باید درون سیستم اوبونتو 20.04 شما مانند git و curl وجود داشته باشد ، Composer برای اجرای اسکریپت های PHP در خط فرمان ، به php-cli نیز و برای اکسترکت بایگانی های zip شده به unzip نیاز دارد. اکنون این وابستگی ها را نصب خواهیم کرد.
ابتدا حافظه نهان مدیر بسته را با اجرای این دستور به روز کنید:
⦁ $ sudo apt update
⦁
در مرحله بعدی ، برای نصب بسته های مورد نیاز ، دستور زیر را اجرا کنید:
⦁ $ sudo apt install php-cli unzip
⦁
از شما خواسته می شود که نصب را با تایپ Y و سپس ENTER تأیید کنید.
پس از نصب پیش نیازها ، می توانید به سراغ نصب Composer بروید.
مرحله 2 – دانلود و نصب Composer
Composer اسکریپت نصب کننده ای را فراهم می کند که به زبان PHP نوشته شده است. آن را دانلود خواهیم کرد ، و تأیید می کنیم که مشکلی ندارد ، و سپس از آن برای نصب Composer استفاده خواهیم کرد.
مطمئن شوید که در دیرکتوری هوم خود قرار دارید ، سپس نصب را با استفاده از curl بازیابی کنید:
⦁ $ cd ~
⦁
⦁ $ curl -sS https://getcomposer.org/installer -o composer-setup.php

در مرحله بعد ، تأیید خواهیم کرد که نصب کننده دانلود شده با هش SHA-384 برای جدیدترین نصب کننده در صفحه کلیدهای عمومی Composer / امضاها مطابقت دارد. برای تسهیل مرحله تأیید ، می توانید از دستور زیر استفاده کنید تا آخرین hash را از صفحه Composer به طور برنامه وار بدست آورید و آن را در متغیر پوسته ذخیره کنید:
⦁ $ HASH=`curl -sS https://composer.github.io/installer.sig`
⦁
اگر می خواهید مقدار به دست آمده را تأیید کنید ، می توانید این دستور را اجرا کنید:
⦁ $ echo $HASH
⦁
Output
e0012edf3e80b6978849f5eff0d4b4e4c79ff1609dd1e613307e16318854d24ae64f26d17af3ef0bf7cfb710ca74755a

اکنون کد PHP زیر را ، همانطور که در صفحه دانلود Composer ارائه شده است ، اجرا کنید تا تأیید کنید که اسکریپت نصب برای اجرا امن است:
⦁ $ php -r if (hash_file(‘SHA384’, ‘composer-setup.php’) === ‘$HASH’) { echo ‘Installer verified’; } else { echo ‘Installer corrupt’; unlink(‘composer-setup.php’); } echo PHP_EOL;”
⦁
خروجی زیر را مشاهده خواهید کرد:
Output
Installer verified

اگر خروجی می گوید نصب کننده مشکل دارد ، باید اسکریپت نصب را بار دیگر دانلود کنید و بررسی کنید که از هش درست استفاده می کنید. سپس فرایند تأیید را تکرار کنید. وقتی یک نصب تأیید شده داشتید ، می توانید ادامه دهید.
برای نصب Composer در سطح جهانی ، از دستور زیر استفاده کنید که Composer را به عنوان یک فرمان در گستره سیستم به نام Composer تحت ، usr / local / bin دانلود و نصب می کند:
⦁ $ sudo php composer-setup.php –install-dir=/usr/local/bin –filename=composer
⦁
خروجی مشابه این را مشاهده خواهید کرد:
Output
All settings correct for using Composer
Downloading…

Composer (version 1.10.5) successfully installed to: /usr/local/bin/composer
Use it: php /usr/local/bin/composer

برای آزمایش نصب خود ، اجرا کنید:
⦁ $ composer
⦁
Output
______
/ ____/___ ____ ___ ____ ____ ________ _____
/ / / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__ ) __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
/_/
Composer version 1.10.5 2020-04-10 11:44:22

Usage:
command [options] [arguments]

Options:
-h, –help Display this help message
-q, –quiet Do not output any message
-V, –version Display this application version
–ansi Force ANSI output
–no-ansi Disable ANSI output
-n, –no-interaction Do not ask any interactive question
–profile Display timing and memory usage information
–no-plugins Whether to disable plugins.
-d, –working-dir=WORKING-DIR If specified, use the given directory as working directory.
–no-cache Prevent use of the cache
-v|vv|vvv, –verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
…

تأیید می کند که Composer با موفقیت روی سیستم شما نصب شده است و در سطح سیستم در دسترس است.
توجه: اگر ترجیح می دهید Composer قابل اجرای جداگانه برای هر پروژه ای که در این

سرور مجازی میزبانی میکنید ، داشته باشید ، می توانید آن را به صورت محلی در هر پروژه نصب کنید. این روش همچنین زمانی مفید است که کاربر سیستم شما اجازه نصب نرم افزارهای گسترده در سیستم را ندارد.
برای این کار از دستور php Composer -setup.php استفاده کنید. با این کار یک فایل composer.phar در دایرکتوری فعلی شما ایجاد می شود ، که می تواند با php comper.phar اجرا شود.
اکنون بیایید به استفاده از Composer برای مدیریت وابستگی ها بپردازیم.
مرحله 3 – استفاده از Composer در یک پروژه PHP
پروژه های PHP اغلب به کتابخانه های خارجی متکی هستند ، و مدیریت آن وابستگی ها و نسخه های آنها می تواند مشکل باشد. Composer با پیگیری نسخه های پروژه و متعلقات آن ، این مشکل را حل می کند ، ضمن اینکه روند پیدا کردن ، نصب و به روزرسانی بسته های مورد نیاز یک پروژه را نیز تسهیل می کند.
برای استفاده از Composer در پروژه خود ، به یک فایل Composer .json احتیاج دارید. فایل composer.json به Composer می گوید که به کدام متعلقات برای دانلود برای پروژه شما نیاز دارد و نصب کدام نسخه های هر بسته مجاز است. بسیار مهم است که پروژه خود را ثابت نگه دارید و از نصب نسخه های ناپایدار که به طور بالقوه می تواند باعث ایجاد مشکلات سازگاری شود ، خودداری کنید.
لازم نیست این فایل را به صورت دستی ایجاد کنید – معمولا در هنگام انجام این کار با خطاهای نحوی روبرو میشوید. Composer یک روش تعاملی برای ایجاد یک فایل جدید Composer .json بر اساس ورودی کاربر ارائه می دهد ، اگر قصد دارید پروژه خود را بعدا به عنوان یک بسته عمومی در Packagist به اشتراک بگذارید ، گزینه خوبی است. وقتی فرمان composer require را اجرا میکنید، Composer همچنین یک فایل Composer .json ایجاد می کند تا یک وابستگی را در یک پروژه تازه ایجاد شده شامل شود.
مراحل استفاده از Composer برای نصب بسته به عنوان متعلقات در یک پروژه شامل مراحل زیر است:
• شناسایی کنید که برنامه به چه نوع کتابخانه ای نیاز دارد.
• در مورد کتابخانه منبع باز مناسب در Packagist.org ، مخزن رسمی بسته بندی Composer تحقیق کنید.
⦁ بسته ای را که می خواهید به آن متکی باشید انتخاب کنید.
• composer require را اجرا کنید تا وابستگی را در فایل Composer .json شامل شده و بسته را نصب کنید.
بیایید این کار را با یک برنامه آزمایشی امتحان کنیم.
هدف از این برنامه تبدیل یک جمله معین به یک رشته سازگار با URL است- یعنی یک slug.
این معمولاً برای تبدیل عناوین صفحه به مسیرهای URL استفاده می شود (مانند قسمت نهایی URL برای این آموزش)
بیایید با ایجاد دایرکتوری برای پروژه خود شروع کنیم. آن را slugify می نامیم:
⦁ $ cd ~
⦁
⦁ $ mkdir slugify
⦁
⦁ $ cd slugify

اگرچه لازم نیست ، اکنون می توانید یک دستور composer init را اجرا کنید تا یک فایل composer.jso مفصل را برای پروژه خود ایجاد کنید. از آنجا که تنها هدف پروژه ما نشان دادن چگونگی نصب متعلقات با Composer است ، از یک فایل ساده تر Composer .json استفاده خواهیم کرد که وقتی به اولین بسته خود احتیاج داریم ، به صورت خودکار تولید می شود.
اکنون زمان آن رسیده است که Packagist.org را برای بسته ای جستجو کنیم که می تواند در تولید slugs به ما کمک کند. اگر اصطلاح Slug را در Packagist جستجو کنید ، نتیجه ای مشابه این دریافت خواهید کرد:

در سمت راست هر بسته در لیست ، دو عدد مشاهده خواهید کرد. عدد بالا نشان می دهد که چند بار بسته از طریق Composer نصب شده است ، و عدد پایین نشان می دهد که چند بار بسته بندی در GitHub ستاره دار شده است. به طور کلی ، بسته هایی با نصب بیشتر و تعداد بیشتری ستاره ، پایداری بیشتری دارند ، زیرا بسیاری از افراد از آنها استفاده می کنند. همچنین مهم است که توضیحات بسته را برای میزان ارتباط بررسی کنید تا اطمینان حاصل کنید که به چه چیز نیاز دارید.
ما به مبدل string به slug نیاز داریم. از نتایج جستجو ، بسته Cocur / slugify که به عنوان اولین نتیجه در آن صفحه ظاهر می شود ، با تعداد معینی نصب و ستاره گزینه خوبی به نظر میرسد.
بسته های Packagist دارای نام vendor و نام package هستند. هر بسته دارای یک شناسه منحصر به فرد (یک فضای نام) در همان قالب است که GitHub برای مخازن خود استفاده می کند: vendor/package. کتابخانه ای که می خواهیم نصب کنیم از فضای نام cocur / slugify استفاده می کند. برای اینکه در پروژه خود آن را به کار بگیرید ، به فضای نام بسته نیاز دارید.
اکنون که می دانید دقیقاً کدام پکیج را می خواهید نصب کنید ، می توانید composer require را اجرا کنید ، باید آن را به عنوان یک وابستگی در نظر بگیرید و همچنین فایل Composer .json را برای پروژه خود تولید کنید. نکته ای که هنگام به کارگیری بسته ها باید توجه کنیم این است که Composer هم متعلقات سطح برنامه و هم متعلقات سطح سیستم را ردیابی می کند. متعلقات سطح سیستم برای نشان دادن اینکه بسته به کدامیک از ماژول های PHP متکی است مهم هستند. بسته Cocur / slugify ، به یک ماژول PHP نیاز دارد که ما هنوز نصب نکرده ایم.
هنگامی که یک بسته مورد نیاز به یک کتابخانه سیستمی که در حال حاضر روی

سرور مجازی شما نصب نشده است متکی است ، با خطایی مبنی بر اینکه چه چیزی مورد نیاز است ، مواجه می شوید:
⦁ $ composer require cocur/slugify
⦁
Output
Using version ^4.0 for cocur/slugify
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

Problem 1
– Installation request for cocur/slugify ^4.0 -> satisfiable by cocur/slugify[v4.0.0].
– cocur/slugify v4.0.0 requires ext-mbstring * -> the requested PHP extension mbstring is missing from your system.
…

برای حل مشکل وابستگی سیستم ، می توانیم با استفاده از apt search ، بسته گمشده را جستجو کنیم:
⦁ $ apt search mbstring
⦁
Output
Sorting… Done
Full Text Search… Done
php-mbstring/focal 2:7.4+75 all
MBSTRING module for PHP [default]

php-patchwork-utf8/focal 1.3.1-1 all
UTF-8 strings handling for PHP

php7.4-mbstring/focal 7.4.3-4ubuntu1 amd64
MBSTRING module for PHP

پس از یافتن نام درست بسته ، می توانید بار دیگر از apt برای نصب وابستگی سیستم استفاده کنید:
⦁ $ sudo apt install php-mbstring
⦁
پس از اتمام نصب ، مجدداً می توانید composer require را اجرا کنید:
⦁ $ composer require cocur/slugify
⦁
Output
Using version ^4.0 for cocur/slugify
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
– Installing cocur/slugify (v4.0.0): Downloading (100%)
Writing lock file
Generating autoload files

همانطور که از خروجی مشاهده می کنید ، Composer به طور خودکار تصمیم گرفت از کدام نسخه از بسته استفاده کند. اگر اکنون دایرکتوری پروژه خود را بررسی کنید ، شامل دو فایل جدید خواهد بود: composer.json و composer.lock ، و یک دیرکتوری vendor:
⦁ $ ls -l
⦁
Output
total 12
-rw-rw-r– 1 sammy sammy 59 May 4 13:56 composer.json
-rw-rw-r– 1 sammy sammy 3229 May 4 13:56 composer.lock
drwxrwxr-x 4 sammy sammy 4096 May 4 13:56 vendor

از فایل composer.lock برای ذخیره اطلاعات در مورد این که کدام یک از نسخه های هر بسته نصب شده است استفاده می شود و اطمینان حاصل می کند اگر شخص دیگری پروژه شما را کلون کند و متعلقات آن را نصب کند ، از نسخه های مشابه استفاده می شود. دایرکتوری vendor جایی است که وابستگی پروژه در آن واقع شده باشد. پوشه vendor نباید به کنترل نسخه متعهد باشد – فقط باید فایل های Composer .json و composer.lock را شامل شوید.
هنگام نصب پروژه ای که از قبل حاوی یک فایل composer.json است ، به منظور دانلود متعلقات پروژه ، composer install را اجرا کنید.

بیایید نگاهی اجمالی به محدودیت های نسخه بیندازیم. اگر محتویات فایل Composer .json خود را بررسی کنید ، چنین چیزی را مشاهده خواهید کرد:
⦁ $ cat composer.json
⦁
Output
{
require”: {
cocur/slugify”: ^4.0”
}
}

ممکن است متوجه کاراکتر خاص ^ قبل از شماره نسخه در Composer .json شوید. Composer از چندین محدودیت و فرمت مختلف برای تعریف نسخه بسته مورد نیاز پشتیبانی می کند ، به منظور ارائه انعطاف پذیری و در عین حال ثابت نگه داشتن پروژه شما. اپراتور caret (^) که توسط فایل تولید شده توسط composer.json ایجاد شده است ، طبق semantic versioning ، اپراتور توصیه شده برای حداکثر قابلیت همکاری است. در این حالت ، 4.0 را به عنوان حداقل نسخه سازگار تعریف می کند و به روزرسانی های هر نسخه بعدی زیر 5.0 را امکان پذیر می کند.
به طور کلی ، لازم نیست که محدودیت های نسخه را در فایل Composer .json خود دستکاری کنید. با این حال ، در برخی از شرایط ممکن است نیاز باشد که شما محدودیت ها را به صورت دستی ویرایش کنید – برای مثال ، هنگامی که نسخه اصلی جدیدی از کتابخانه مورد نیاز شما منتشر میشود و می خواهید آن را ارتقا دهید ، یا وقتی کتابخانه ای که می خواهید از آن استفاده کنید ، نسخه معنایی (semantic versioning) را دنبال نمی کند.
در اینجا چند مثال برای درک بهتر نحوه عملکرد محدودیتهای نسخه Composer آورده شده است:
Constraint Meaning Example Versions Allowed
^1.0 >= 1.0 < 2.0 1.0, 1.2.3, 1.9.9
^1.1.0 >= 1.1.0 < 2.0 1.1.0, 1.5.6, 1.9.9
~1.0 >= 1.0 < 2.0.0 1.0, 1.4.1, 1.9.9
~1.0.0 >= 1.0.0 < 1.1 1.0.0, 1.0.4, 1.0.9
1.2.1 1.2.1 1.2.1
1.* >= 1.0 < 2.0 1.0.0, 1.4.5, 1.9.9
1.2.* >= 1.2 < 1.3 1.2.0, 1.2.3, 1.2.9

برای مشاهده دقیق تر محدودیت های نسخه Composer ، به مقالات رسمی مراجعه کنید.
در مرحله بعدی ، بیایید ببینیم که چگونه متعلقات را به طور خودکار با Composer لود کنیم.
مرحله 4 – مشمولیت اسکریپت Autoload
از آنجایی که خود PHP کلاسها را به طور خودکار لود نمی کند ، Composer یک اسکریپت autoload را فراهم می کند که می توانید در پروژه خود بگنجانید تا بتوانید از عملکرد لود خودکار برای پروژه خود استفاده کنید. این فایل با افزودن اولین وابستگی ، توسط Composer به طور خودکار تولید می شود.
تنها کاری که شما باید انجام دهید اینست که فایل vendor/autoload.php را در اسکریپت های PHP خود قبل معرفی و نمونه سازی کلاس بگنجانید.
بیایید آن را در برنامه نسخه ی نمایشی خود امتحان کنیم. فایل جدیدی به نام test.php را در ویرایشگر متن خود باز کنید:
⦁ $ nano test.php
⦁
کد زیر را اضافه کنید که فایل vendor/autoload.php را وارد می کند ، وابستگی Cocur / slugify را لود می کند ، و از آن برای ایجاد یک slug استفاده می کند:
test.php
<?php
require __DIR__ . ‘/vendor/autoload.php’;

use Cocur\Slugify\Slugify;

$slugify = new Slugify();

echo $slugify->slugify(‘Hello World, this is a long sentence and I need to make a slug from it!’);

فایل را ذخیره کنید و از ویرایشگر خود خارج شوید.
اکنون اسکریپت را اجرا کنید:
⦁ $ php test.php
⦁
خروجی زیر را ایجاد میکند:
hello-world-this-is-a-long-sentence-and-i-need-to-make-a-slug-from-it
هنگام انتشار نسخه های جدید، متعلقات به آپدیت نیاز دارند ، بنابراین بیایید ببینیم چگونه این کار را انجام دهیم
مرحله 5 – بروزرسانی متعلقات پروژه
هر زمان که می خواهید متعلقات پروژه خود را به نسخه های جدیدتر بروزرسانی کنید ، دستور update را اجرا کنید:
⦁ $ composer update
⦁

با این کار نسخه های جدیدتری از کتابخانه های مورد نیاز پروژه شما جستجو می شوند. اگر نسخه جدیدتری پیدا شود و با محدودیت نسخه تعریف شده در فایل composer.json سازگار باشد ، Composer نسخه جدید را جایگزین قبلی می کند. فایل composer.lock به روز خواهد شد تا این تغییرات را منعکس کند.
همچنین می توانید یک یا چند کتابخانه خاص را با مشخص کردن آنها مانند این به روز کنید:
⦁ $ composer update vendor/package vendor2/package2
⦁
بعد از به روزرسانی متعلقات خود ، حتماً فایل های Composer .json و composer.lock را در سیستم کنترل نسخه خود بررسی کنید تا دیگران بتوانند این نسخه های جدیدتر را نیز نصب کنند.
نتیجه
Composer ابزاری قدرتمند است که می تواند کارآیی مدیریت متعلقات را در پروژه های PHP تا حد زیادی تسهیل کند. و یک روش مطمئن برای کشف ، نصب و به روز رسانی بسته های PHP فراهم می کند که یک پروژه به آن بستگی دارد. در این راهنما ، ما چگونگی نصب Composer ، چگونگی گنجاندن متعلقات جدید در یک پروژه و نحوه به روزرسانی این متعلقات را در صورت وجود نسخه های جدید ، بررسی کردیم.

برچسب‌ها:Cocur / slugify, Composer, Laravel, Symfony

مشخصات

جهت مشاهده منبع اصلی و ادامه این مطلب این مطلب کلیک کنید

server

نحوه نصب Drupal با Docker Compose

مشخصات

نحوه نصب Nginx در اوبونتو 20.04

مشخصات

7 مورد از اقدامات امنیتی برای محافظت از سرورهای شما

مشخصات

نحوه نصب و ایمن سازی Redis در اوبونتو 20.04

مشخصات

نحوه نصب و ایمن سازی Redis در اوبونتو 18.04

مشخصات

اضافه کردن فضای Swap در اوبونتو 20.04

مشخصات

چگونه می توان فایروال را با UFW در اوبونتو 20.04 تنظیم کرد

مشخصات

نظارت بر اطلاعیه و مسیر BGP با BGPalerter اوبونتو 18.04

مشخصات

نصب و ایمن سازی phpMyAdmin در اوبونتو 20.04

مشخصات

نصب و استفاده از Composer در اوبونتو 20.04

مشخصات

آخرین مطالب

آخرین ارسال ها

آخرین وبلاگ ها

آخرین جستجو ها

درباره این سایت