WordPress-ის დაცვა, რომელიც ძალისხმევას ღირს

WordPress core ჩვეულებრივ ის არ არის, რითაც საიტში შეღწევა ხდება. გზა არის განახლების გარეშე დარჩენილი პლაგინი საჯარო advisory-თი, პაროლი, რომელიც იმ ადგილიდან იმეორებ, სადაც გაჟონა, ან ფაილი, რომელშიც ვებ სერვერს ჩაწერა არასოდეს უნდა შეძლებოდა. დაცვა, რომელიც ამ სამს უგულებელყოფს და სამაგიეროდ გვერდის წყაროში ვერსიის ნომერს მალავს, დეკორაციაა.

ამიტომ ასეთია პატიოსანი თანმიმდევრობა: ყველაფერი განახლებული გქონდეს, შესვლა თავდამსხმელისთვის უსარგებლო გახადე, PHP იმ ადგილებში არ გაუშვა, სადაც მას არაფერი ესაქმება, ნაკლები პლაგინი გამოიყენე იმ ადამიანებისგან, ვინც მათ ჯერ კიდევ ინახავს, და backup-ები იქ შეინახე, სადაც კომპრომეტაციას ვერ მიუწვდება ხელი. ყველაფერი ქვემოთ ამ ხუთიდან ერთ-ერთია, და სადაც პოპულარული რჩევა არაფერს აკეთებს, ამას ამბობს.

როგორ ტეხავენ WordPress საიტებს სინამდვილეში#

ოთხი გზა თითქმის ყველაფერს ფარავს.

• მოწყვლადი პლაგინი ან თემა. ვიღაც advisory-ს აქვეყნებს, ავტომატური სკანერები საათებში იწყებენ ინტერნეტის ყველა საიტის ამ პლაგინის გზაზე გამოკვლევას, და საიტები, რომლებიც კვირაა არ განახლებულა, აღმოჩენილია. ეს ყველაზე დიდი კატეგორიაა და მთლიანად patch-ის პრობლემაა.
• მოპარული ან გაჟონილი მონაცემები. Brute force wp-login.php-ზე, მაგრამ უფრო ხშირად credential stuffing იმ პაროლით, რომელიც სრულიად უკავშირო სერვისიდან გაჟონა. ასევე მოპარული SFTP ან პანელის მონაცემები, რაც ჩვეულებრივ ნიშნავს, რომ კომპრომეტირებული მანქანა სერვერი კი არა, მფლობელის ლეპტოპი იყო.
• მიტოვებული ან გაყიდული პლაგინები. პლაგინი 40 000 ინსტალაციით ტოვებს მხარდაჭერას ან მფლობელს იცვლის და ახალი მფლობელი განახლებას უშვებს, რომელიც დისტანციურ კოდს ტვირთავს. იშვიათია და უსიამოვნოა, როცა ხდება, რადგან თავად განახლებაა შეტევა.
• მეზობლები. გაზიარებულ ჰოსტინგზე სუსტი იზოლაციით ერთი საიტის კომპრომეტაცია შემდეგამდე აღწევს ყველასთვის ჩაწერადი ფაილებით ან საერთო მონაცემთა ბაზის მომხმარებლით. Container-ი თითო საიტზე ამას აშორებს, რაც ჰოსტინგის მოდელებს შორის ნამდვილი განსხვავებაა და არა მარკეტინგული ფრაზა.

შეამჩნიე, რა აკლია: zero-day თავად WordPress-ში. Core-ს მძიმედ აუდიტავენ, უსაფრთხოების რელიზებს სწრაფად უშვებს და მათ თვითონ აყენებს. თუ შენი საიტი კომპრომეტირებულია, core-მდე პლაგინების სია და წვდომის ლოგები ნახე.

განახლებები და რომელი ავტომატიზო#

3.7-დან WordPress საკუთარ მცირე და უსაფრთხოების რელიზებს თავად აყენებს. ეს ხელუხლებელი დატოვე. მასზე მაკონტროლებელი კონსტანტა wp-config.php-ს ეკუთვნის და სამი მნიშვნელოვანი მნიშვნელობა აქვს:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

'minor' ნაგულისხმევია და თითქმის ყველასთვის სწორი პასუხი: 6.7.1-დან 6.7.2-ზე თავისით გადადის, 6.7-დან 6.8-ზე შენ გელოდება. true მთავარ ვერსიებსაც ავტომატურად იღებს, რაც მარტივ საიტზე კარგია და page builder-იან საიტზე სარისკო. false core-ის განახლებებს სრულად თიშავს და გამართლებულია მხოლოდ თუ რაღაც სხვა მათ ერთ დღეში აყენებს.

პლაგინისა და თემის ავტომატური განახლებები ელემენტის მიხედვით ირთვება Plugins ეკრანიდან WordPress 5.5-დან. მუშა პოლიტიკა:

რასაც არ ავტომატიზებ, უნდა გააკეთო. განახლებების რიგი, რომელსაც არავინ ცარიელებს, ავტომატურ განახლებებზე უარესია, რადგან კონტროლის ილუზიას ქმნის. დაამატე განმეორებადი დავალება კალენდარში, შეამოწმე ის advisory-ებთან იმ პლაგინებისთვის, რომლებსაც უშვებ, და ყოველი პარტიის წინ აიღე backup, რომ "განახლებამ საიტი გააფუჭა" ხუთწუთიანი პრობლემა იყოს.

შესვლის გვერდი და მის უკან მდგარი ანგარიშები#

WordPress-ს core-ში ორფაქტორიანი ავტორიზაცია არ მოაქვს, ამიტომ დაამატე პლაგინით და მოითხოვე ყველასგან, ვისაც administrator ან editor როლი აქვს. ეს ერთი ცვლილება პაროლის გაჟონვას თითქმის უმნიშვნელოს ხდის, რაც ათი წუთის სამუშაოზე ყველაზე დიდი უკუგებაა.

შემდეგ შეამცირე თავად შესვლის გვერდის ღირებულება:

1. ანგარიში, რომელსაც `admin`, `administrator` ან საიტის სახელი ჰქვია, არ უნდა არსებობდეს. ეს სამი ავტომატური მცდელობებით გამოიყენება. შექმენი ახალი administrator, შედი მისით, წაშალე ძველი და მისი პოსტები გადააკუთვნე.
2. უნიკალური პაროლები, გენერირებული, პაროლების მენეჯერში შენახული. პაროლი, რომელიც 2016 წლის ფორუმის ანგარიშსაც ხსნის, პაროლი არ არის.
3. შეზღუდე შესვლის მცდელობები. ამას ნებისმიერი შესვლის შემზღუდველი პლაგინი აკეთებს: ერთი მისამართიდან რამდენიმე წარუმატებლობა და შემდეგ ბლოკი. ის credential stuffing-ს წუთში ათასობით მცდელობიდან იმად აქცევს, რაც წლებს მოითხოვს.
4. როლები ადამიანებისგან განაცალკევე. Contributor-ებსა და editor-ებს administrator არ სჭირდებათ. ანგარიში, რომელსაც პლაგინის დაყენება შეუძლია, ანგარიშია, რომელსაც backdoor-ის დაყენება შეუძლია.
5. მომხმარებლების სია ყოველთვიურად გადახედე. მოაშორე ადამიანები, ვინც წავიდა. 2023 წელს შენთან მომუშავე დეველოპერის მიძინებული administrator ანგარიში პასუხისმგებლობაა, რომელსაც არავინ უყურებს.

Application password-ები, რომლებიც WordPress 5.6-ში დაემატა, სწორი გზაა, რომ გარე ხელსაწყომ REST API-ს ესაუბროს: ერთი პაროლი ინტეგრაციაზე, ცალ-ცალკე გაუქმებადი, admin-ში შესასვლელად უსარგებლო. თუ პლაგინი სერვისის დასაკავშირებლად შენი ნამდვილი ანგარიშის პაროლს გთხოვს, ეს პლაგინის უნდობლობის მიზეზია.

შესვლის URL-ის შეცვლა პლაგინით გაურკვევლობაა და არა უსაფრთხოება, და ის ტეხს პროცესებს, რომლებიც wp-login.php-ს ელიან. ის ლოგებში ნაგვის მოცულობას ამცირებს, რასაც გარკვეული ღირებულება აქვს პატარა გეგმაზე, სადაც ეს მოთხოვნები CPU-ს ჯდება. შეაფასე ეს ამით და არა უსაფრთხოებით. /wp-admin-სა და /wp-login.php-ის ცნობილი მისამართების სიის გარდა ყველასთვის დაბლოკვა ამ იდეის ნამდვილი ვერსიაა და შესანიშნავია, როცა შენს გუნდს ფიქსირებული მისამართები აქვს.

XML-RPC, REST API და მომხმარებლების ჩამოთვლა#

xmlrpc.php ძველი დისტანციური ინტერფეისია. ის ჯერ კიდევ გამოიყენება მობილური აპლიკაციის, Jetpack-ისა და რამდენიმე გამოქვეყნების ხელსაწყოს მიერ, და თუ შენს სტეკში არაფერი იყენებს, დახურე. ის ორი სახის ტრაფიკს იზიდავს: პაროლების გამოცნობას და pingback-ის ბოროტად გამოყენებას, როცა შენს საიტს მესამე მხარეზე მოთხოვნების გაგზავნას აიძულებენ.

location = /xmlrpc.php {    deny all;    access_log off;}

Apache-ზე ეკვივალენტი .htaccess-ში მიდის საიტის ძირში:

<Files "xmlrpc.php">    Require all denied</Files>

REST API განსხვავებულია და მთლიანად დაბლოკვა არ შეიძლება: მას block editor იყენებს, და პლაგინებიც, რომლებსაც ენდობი. რისი შეზღუდვაც ღირს, მომხმარებლების ჩამოთვლაა. ნაგულისხმევად /wp-json/wp/v2/users ჩამოთვლის ანგარიშებს გამოქვეყნებული პოსტებით, /?author=1 ავტორის slug-ზე გადამისამართებს, და wp-sitemap.xml ავტორების sitemap-ს შეიცავს. არცერთი ეს მოწყვლადობა არ არის - მომხმარებლის სახელი საიდუმლო არ არის - მაგრამ ის თავდამსხმელს უფასოდ აძლევს მონაცემთა წყვილის პირველ ნახევარს. თუ ავტორების არქივები არ გაქვს დასაკარგი, hardening პლაგინს სამივეს გამორთვა შეუძლია, და ავტორების sitemap-ის გამორთვა ერთხაზიანი ფილტრია.

მეორე endpoint, რაზეც უნდა იფიქრო, wp-cron.php-ია. WordPress დაგეგმილ სამუშაოებს ვიზიტორების მოთხოვნებზე უშვებს, ამიტომ ყოველ ჰიტს შეუძლია cron-ის სამუშაოს გამოწვევა, და დატვირთულ საიტზე თავდამსხმელები სიამოვნებით მოითხოვენ ამ ფაილს ციკლში, რომ PHP ძვირ საქმეს განმეორებით აკეთებდეს. დააყენე define( 'DISABLE_WP_CRON', true ); და ის ნამდვილი განრიგით გამოიძახე - პანელის დაგეგმილი დავალება, რომელიც URL-ს წუთში ერთხელ ურტყამს, ნაგულისხმევზე სწრაფიც არის და იაფიც.

ფაილების უფლებები და ორი კონსტანტა, რომელიც admin-ს ჩაკეტავს#

დირექტორიები 755-ზე, ფაილები 644-ზე, wp-config.php 640-ზე. არასოდეს 777, რაც ნიშნავს, რომ მანქანის ნებისმიერ ანგარიშს შეუძლია შენი კოდის გადაწერა. თუ რაღაც 755-ზე ვერ წერს, პრობლემა მფლობელობაშია და არა რეჟიმში, და chmod 777 არის გზა უფლებების პრობლემის კომპრომეტაციად გადასაქცევად.

ორი კონსტანტა უმეტეს ზიანს აშორებს, რომლის მიყენებაც თავდამსხმელს administrator სესიით შეუძლია:

define( 'DISALLOW_FILE_EDIT', true );define( 'DISALLOW_FILE_MODS', true );

პირველი admin-იდან თემისა და პლაგინის რედაქტორებს აშორებს - ფუნქციას, რომელიც "მოპარულ პაროლს" სამ დაწკაპუნებაში "თვითნებურ PHP-ად შენს სერვერზე" აქცევს. ყველამ უნდა დააყენოს. მეორე უფრო შორს მიდის და პლაგინებისა და თემების დაყენებასა და განახლებას dashboard-იდან მთლიანად ბლოკავს, რაც სწორია საიტისთვის, რომელიც რეპოზიტორიდან იტვირთება, და არასწორია საიტისთვის, რომლის მფლობელი პლაგინებს ხელით ანახლებს.

მეორე წესია, რომ uploads დირექტორიაში არაფერი უნდა სრულდებოდეს. მედიაფაილის ატვირთვა, რომელიც ცუდად დაწერილ პლაგინს .php ფაილს გაუტარებს, უსარგებლოა, თუ სერვერი მის გაშვებაზე უარს ამბობს:

location ~* ^/wp-content/uploads/.*\.(?:php|phtml|php5)$ {    deny all;}

ბოლოს, შეამოწმე, რა დევს web root-ში, რაც არ უნდა იყოს. ძველი wp-config.php.bak ფაილები, მიგრაციის site-backup.zip, ექსპორტირებული database.sql, .git დირექტორია: ყველა ეს ჩამოსატვირთია ყველასთვის, ვინც სახელს გამოიცნობს, და სკანერები გამუდმებით ხვდებიან. Firewall-ის წესები, რომლებსაც მნიშვნელობა აქვს იმავე პრინციპს ფენით ქვემოთ ფარავს.

პლაგინებისა და თემების ჰიგიენა#

ყოველი პლაგინი კოდია, რომელიც შენ არ დაგიწერია და შენს მონაცემთა ბაზაზე სრული წვდომით მუშაობს. რიცხვი, რომელიც უნდა გაინტერესებდეს, არა რამდენი გაქვს, არამედ რამდენს ვერ ხსნი.

• წაშალე და არა გამორთე. გამორთულ პლაგინს დისკზე მაინც აქვს ფაილები და რამდენიმე ისტორიული მოწყვლადობა პლაგინის აქტიურობის გარეშეც იყო ექსპლუატირებადი. იგივე ეხება სამ ნაგულისხმევ თემას, რომელსაც არ იყენებ - ერთი დატოვე, დანარჩენი წაშალე.
• დაყენებამდე შეამოწმე მხარდაჭერა. ბოლო განახლების თარიღი, tested-up-to ვერსია, ღია support თემები, ინსტალაციების რაოდენობა. პლაგინი, რომელიც ბოლოს სამი წლის წინ განახლდა, გადაწყვეტილებაა, რომ თავად შეინახავ.
• არასოდეს დააყენო nulled თემა ან პლაგინი. ფასიანი კოდი, რომელიც უფასოდ ვრცელდება, შეცვლილია, და ეს შეცვლა არის ბიზნეს მოდელი. ეს პირველივე დღეს კომპრომეტაციის ყველაზე საიმედო გზაა.
• ერთი პლაგინი სამს სჯობს. სამი პლაგინი, რომლებიც სამუშაოს მესამედს აკეთებენ, სამი განახლების ნაკადი და სამი შეტევის ზედაპირია.
• გამოიწერე advisory-ები იმ პლაგინებისთვის, რომლებსაც უშვებ. მოწყვლადობების მონაცემთა ბაზები feed-ებს აქვეყნებენ; სკანერი პლაგინიც გეტყვის, თუმცა მოვლენის შემდეგ.

საიდუმლოებები, მონაცემთა ბაზის მომხმარებელი და ჰოსტინგის ანგარიში#

მონაცემთა ბაზის მომხმარებელს, რომლითაც WordPress უკავშირდება, საკუთარ ბაზაზე სრული უფლებები უნდა ჰქონდეს და სხვაგან არცერთი. არა ადმინისტრაციული ანგარიში, არა მომხმარებელი, რომელიც მეორე საიტს ჰყავს გაზიარებული. თუ პლაგინი SQL injection-ით იქნება ექსპლუატირებული, ეს grant არის საზღვარი ერთი საიტის დაკარგვასა და ანგარიშის ყველა საიტის დაკარგვას შორის - მსჯელობა გადაწერილია მონაცემთა ბაზის უსაფრთხოების ჩეკლისტში.

შეცვალე salt-ები wp-config.php-ში ნებისმიერი ეჭვმიტანილი კომპრომეტაციის შემდეგ. ამ რვა კონსტანტის ჩანაცვლება არსებულ ყველა სესიის cookie-ს ბათილს ხდის, თავდამსხმელისაც. ახლები მოდის https://api.wordpress.org/secret-key/1.1/salt/-დან.

შემდეგ დაიცავი ანგარიში WordPress-ის ზემოთ, რომელსაც ადამიანები ივიწყებენ. RE:NODE-ზე ეს ნიშნავს TOTP ორფაქტორიანს პანელის ანგარიშზე, აღდგენის კოდებით, რომლებიც იქ ინახება, სადაც კვლავ გექნება, subuser-ებს ვიწრო როლებით და არა ერთი login-ის გაზიარებას - მხოლოდ კონსოლი, მხოლოდ ფაილები, ბილინგის გარეშე - და API გასაღებებს, მისამართით შეზღუდულს. ყოველ სერვერს აქვს საკუთარი SFTP მონაცემები და არა ერთი ანგარიშის გასაღები, რომელიც ყველაფერს ხსნის, და არის სერვერზე აქტივობის ლოგი, რომელიც აჩვენებს, ვინ რა გააკეთა. ორფაქტორიანი შენს პანელის ანგარიშზე და subuser-ები და მინიმალური პრივილეგიები ორივეს სათანადოდ ფარავს. ანგარიშს, რომელსაც authenticator-იც და აღდგენის კოდებიც დაკარგული აქვს, ვერ აღდგება, ამიტომ ისინი ცალ-ცალკე შეინახე.

Backup-ები, რომლებიც კომპრომეტაციას გადაურჩება#

Backup იმავე დისკზე, სადაც საიტია, backup არ არის, და backup, რომელიც არასოდეს აღგიდგენია, ჰიპოთეზაა. WordPress-ისთვის სრული backup ორი ნახევარია - wp-content-ის ფაილები და მონაცემთა ბაზა - და აღდგენის პროცედურამ ორივე უნდა დაფაროს, თორემ მიიღებ საიტს, რომლის პოსტები მედიაზე მიუთითებს, რომელიც აღარ არსებობს.

• აიღე ერთი ყოველი განახლების პარტიის წინ. ეს ის backup-ია, რომელსაც რეალურად გამოიყენებ, და ალბათ ამ თვეში.
• ასლები მანქანის გარეთ შეინახე. Ransomware-ც და უხერხული წაშლაც ყველაფერს იღებს, რაც მისაწვდომია.
• აღდგენა staging ასლში გამოსცადე წელიწადში ორჯერ. აღდგენის გამოცდა, სანამ დაგჭირდება მთელი არგუმენტია.
• იცოდე შენახვის ვადა. სამი კვირა დაგვიანებით აღმოჩენილ კომპრომეტაციას სამ კვირაზე ძველი backup სჭირდება, და შვიდდღიანი როტაცია ამას ვერ იძლევა. შეინახე ყოველთვიური ასლი როტაციის მიღმა.

RE:NODE-ის ვებ გეგმები შეიცავს backup-ის სლოტებს, რომლებიც მოთხოვნისამებრ ან განრიგით იქმნება Schedules ჩანართიდან, ინახება იმ მანქანის გარეთ, რომელსაც იცავს, აღდგება ღილაკით და როტაციისგან ჩაიკეტება - ზუსტად ის, რაც ყოველთვიურ ასლს სჭირდება. ერთი ლიმიტი, რომელიც წინასწარ უნდა იცოდე: სერვერის წაშლა მის backup-ებსაც შლის, ჩაკეტილებსაც, ამიტომ ყველაფერი, რაც ანგარიშს უნდა გადაურჩეს, გადმოიწერება.

რას აკეთებს უსაფრთხოების პლაგინი და რას ვერა#

Scanner და firewall პლაგინი - Wordfence, Sucuri, Solid Security და მსგავსი - ღირს, რომ გაუშვა, იმის ნათელი წარმოდგენით, რას იღებ. მას შეუძლია core-ის ფაილები ოფიციალურ checksum-ებთან შეადაროს და შეცვლილი შეამჩნიოს, ახალი administrator ანგარიშების შესახებ გააფრთხილოს, შესვლის მცდელობები შეზღუდოს და ცნობილი პლაგინის მოწყვლადობებზე virtual patch-ები გამოიყენოს, სანამ შენ განაახლებდე.

მას არ შეუძლია დაიცვას ყველაფრისგან, რაც PHP-მდე სრულდება, და ის თავად PHP-ია: მოთხოვნა, რომელიც firewall პლაგინამდე აღწევს, WordPress-ს უკვე ჩატვირთავდა, ამიტომ დატბორვისას ის სამუშაოს ამატებს და არა აკლებს. მას ვერ დაინახავს კომპრომეტაცია, რომელიც შენი SFTP მონაცემებით შემოვიდა და ფაილი ვალიდური სესიით შეცვალა. და მისი malware სკანერი მხიარული რეგულარობით იძლევა false positive-ებს შემცირებულ JavaScript-ზე.

გაუშვი, იმოქმედე იმაზე, რასაც პოულობს, და ნუ მისცემ განახლების დისციპლინის ჩანაცვლების უფლებას. თუ უარესი უკვე მოხდა, შეკავების თანმიმდევრობას ხელსაწყოზე მეტი მნიშვნელობა აქვს - რა უნდა გააკეთო, როცა შენი სერვერი გატეხეს შეიცავს თანმიმდევრობას: იზოლაცია, ყველა მონაცემის შეცვლა, აღდგენა შეღწევაზე ძველი backup-იდან, შემდეგ კარის პოვნა, სანამ ისევ ონლაინ დააბრუნებ.

FAQ#

აუმჯობესებს თუ არა wp_ ცხრილის პრეფიქსის შეცვლა უსაფრთხოებას?

არა. ყველაფერს, რასაც შენი მონაცემთა ბაზის მოთხოვნა შეუძლია, მისი ცხრილების ჩამოთვლაც შეუძლია, ამიტომ პრეფიქსი თავდამსხმელისგან, რომელიც უკვე შიგნითაა, დაფარული არ არის. ის გამოსადეგია ორი საიტის ერთ მონაცემთა ბაზაში ჰოსტინგისთვის და სხვა არაფრისთვის, და ცოცხალ საიტზე მისი შეცვლა admin-ის გაფუჭების რისკს ქმნის სარგებლის გარეშე.

უნდა დავმალო თუ არა WordPress-ის ვერსიის ნომერი?

არაფერი ჯდება და თითქმის არაფერს იძლევა. სკანერები საიტებს ფაილების გამოკვლევით ამოიცნობენ და არა generator tag-ის კითხვით, და თავს ესხმიან ვერსია ემთხვევა თუ არა. ძალისხმევა განახლებაზე დახარჯე.

უსაფრთხოა XML-RPC-ის გამორთვა?

დიახ, თუ შენ გამოყენებულს არაფერს სჭირდება. Jetpack-ს, WordPress-ის მობილურ აპლიკაციას და ზოგიერთ დისტანციური გამოქვეყნების ხელსაწყოს სჭირდება. გამორთე და შემდეგ შეამოწმე, რომ აპლიკაცია და პლაგინები მაინც მუშაობს; თუ რამე გაფუჭდა, ფაილი დაუშვი და შეზღუდე მისი სიხშირე და არა ფართოდ ღია დატოვე.

რამდენი პლაგინია ძალიან ბევრი?

რიცხვი არ არსებობს. ოცი კარგად მხარდაჭერილი პლაგინი ხუთ მიტოვებულზე უფრო უსაფრთხოა. ნამდვილი ზღვარია, რამდენი შეგიძლია patch-ით შეინახო და გაამართლო - თუ ვერ ამბობ, რას აკეთებს პლაგინი და ბოლოს როდის გამოუშვა განახლება, ის ერთით მეტია.

ჩემი ჰოსტი ამბობს, რომ საიტი spam-ს აგზავნის. რა ვქნა?

თითქმის ყოველთვის კომპრომეტაციაა, რომელმაც mailer სკრიპტი დააყენა. გამოიყვანე საიტი ონლაინიდან, შეცვალე ყველა პაროლი, SFTP-სა და პანელის ჩათვლით, მოძებნე ახლახან შეცვლილი PHP ფაილები wp-content/uploads-სა და wp-content/plugins-ში, და აღადგინე ცვლილებამდე არსებული backup-იდან და არა ფაილების ერთმანეთის მიყოლებით წაშლით.

მჭირდება backup-ები, თუ ჩემი ჰოსტი მათ იღებს?

დიახ. პლატფორმის backup-ები პლატფორმას იცავენ და ნებისმიერ ჰოსტზე შენი საკუთარი სერვერის წაშლას მისი backup-ების წაშლაც შეუძლია. შეინახე ფაილებისა და მონაცემთა ბაზის სულ მცირე ერთი ასლი იქ, სადაც შენ აკონტროლებ, და იცოდე, რამდენ ხანს გრძელდება შენი საკუთარი აღდგენა.