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 ، به راهنماي درك و اجراي غير مجاز مي باشدing 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”

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

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 ~ .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;
}
}

بلوك سرور مجازي 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”

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

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

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

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 مراجعه كنيد.

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 غير مجاز مي باشد 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

Success! The your_domain server block is working!

پس از اتمام ، فايل را با تايپ كردن 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 را بررسي كنيد.

هنگام راه اندازي زيرساخت هاي 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 احتياج دارم؟
نتيجه
استراتژي هاي ذكر شده در بالا ، مروري بر برخي از پيشرفتهايي است كه مي توانيد براي بهبود امنيت سيستم هاي خود داشته باشيد. مهم است كه بدانيد ، اگرچه دير انجام دادن بهتر از هرگز انجام ندادن است ، اما اثربخشي اقدامات امنيتي با تاخير طولاني در اجراي آن ها كاهش مي يابد. امنيت نمي تواند يك امر فرعي باشد و بايد از ابتدا در كنار سرويس ها و برنامه هايي كه ارائه مي دهيد اجرا شود.

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
. . .
# 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 ، تغيير را اعمال كنيد:
$ 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 ، فايروال شماست (كه در صورت پيروي از آموزش مقدماتي راه اندازي اوليه سرور مجازي اوليه، آن را پيكربندي كرده ايد) ، زيرا اين كار پرش از آن حصار امنيتي را براي حمله گران بسيار دشوار مي كند.

Redis يك فروشگاه با حافظه داخلي و مقدار كليد است كه به دليل انعطاف پذيري ، عملكرد و پشتيباني گسترده از زبان شناخته شده است. اين آموزش نحوه نصب ، پيكربندي و ايمن سازي Redis در يك سرور مجازي 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 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 انجام دهيد ، بنابراين پس از اتمام آن را ذخيره كنيد و ببنديد. سپس ، سرويس 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 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 را به صورت دستي راه اندازي كنيد ، مي توانيد اين كار را با دستور زير تنظيم كنيد:
$ 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

127.0.0.1:6379> get test
مقدار كليد شما هنوز بايد در دسترس باشد:
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 1422

اين خروجي نشان مي دهد كه برنامه 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 ، يك اخطار كامنت وجود دارد:
# 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.
اين يك ليست جامع نيست ، اما تغيير نام يا غيرفعال كردن كليه دستورات موجود در آن ليست ، نقطه شروع خوبي براي افزايش امنيت سرور مجازي Redis شما است.
اين كه آيا شما بايد يك فرمان را غيرفعال كنيد يا تغيير نام دهيد ، به نيازهاي خاص شما يا نيازهاي سايت شما بستگي دارد. اگر مي دانيد هرگز از دستوري كه مورد سوءاستفاده قرار مي گيرد استفاده نمي كنيد ، مي توانيد آن را غيرفعال كنيد. در غير اين صورت ، تغيير نام آن مفيد خواهد بود.
براي فعال يا غيرفعال كردن دستورات Redis ، فايل پيكربندي را يك بار ديگر باز كنيد:
$ sudo nano /etc/redis/redis.conf

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

براي غيرفعال كردن يك دستور ، كافي است آن را به يك رشته خالي تغيير دهيد (كه توسط يك جفت علامت نقل قول بدون هيچ كاراكتري بين آنها مشخص شده است) ، همانطور كه در زير نشان داده شده:
/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 ، تغيير را اعمال كنيد:
$ 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’

با اين وجود فراخواني فرمان تغيير نام داده شده موفقيت آميز خواهد بود. به كوچك و بزرگ بودن كاراكترها حساس نيست:
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 ، فايروال شماست (كه در صورت پيروي از آموزش مقدماتي راه اندازي اوليه سرور مجازي اوليه، آن را پيكربندي كرده ايد) ، زيرا اين كار پرش از آن حصار امنيتي را براي حمله گران بسيار دشوار مي كند.

يكي از راه هاي محافظت در برابر خطاهاي اتمام حافظه در برنامه ها ، اضافه كردن فضاي 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 (اتمام حافظه) برخورد مي كنيد ، يا مي بينيد كه سيستم شما قادر به استفاده از برنامه هاي مورد نياز شما نيست ، بهترين راه حل اين است كه تنظيمات برنامه خود را بهينه كنيد يا سرور مجازي خود را به روز كنيد.

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: mtu 1500 qdisc pfifo_fast state
. . .
3: eth1: 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: قوانين و فرمان هاي معمول فايروال استفاده كنيد.

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 سرور مجازي شما به آن تعلق دارد نشان مي دهد:
utput
AS | IP | BGP Prefix | AS Name
14061 | your-ip-address | 157.230.80.0/20 | vpsgol-ASN, US

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

خروجي اطلاعات بيشتري در مورد AS نشان مي دهد:
Output
AS | CC | Registry | Allocated | AS Name
14061 | US | arin | 2012-09-25 | 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

در حالي كه بسياري از كاربران به عملكرد سيستم مديريت ديتابيس مانند 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’;
⦁

سپس روش تأييد اعتبار استفاده شده توسط هريك از كاربران خود را دوباره بررسي كنيد تا تأييد كنيد كه root ديگر با استفاده از افزونه auth_socket تاييد اعتبار نميكند:
⦁ Mysql> SELECT user,authentication_string,plugin,host FROM mysql.user;
⦁
Output
+——————+——————————————-+———————–+———–+
| user | authentication_string | plugin | host |
+——————+——————————————-+———————–+———–+
| root | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | caching_sha2_password | 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)

مي توانيد از اين خروجي مشاهده كنيد كه كاربر اصلي با استفاده از يك رمز عبور تأييد اعتبار مي كند. اكنون مي توانيد
به عنوان كاربر اصلي خود با گذرواژه اي كه در اينجا براي آن تنظيم كرده ايد وارد رابط 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 را در بخش فايل پيكربندي ، مانند اين اضافه كنيد:
/etc/apache2/conf-available/phpmyadmin.conf

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 خود تنظيم و آماده استفاده كرده باشيد. با استفاده از اين رابط ، مي توانيد به راحتي پايگاه داده ، كاربران ، جداول و غيره ايجاد كرده و عمليات معمول مانند حذف و اصلاح ساختارها و داده ها را انجام دهيد.

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
require __DIR__ . ‘/vendor/autoload.php’;

use CocurSlugifySlugify;

$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 ، چگونگي گنجاندن متعلقات جديد در يك پروژه و نحوه به روزرساني اين متعلقات را در صورت وجود نسخه هاي جديد ، بررسي كرديم.