Защита виртуального сервера VDS Linux

После покупки виртуального сервера, первым делом необходимо его настроить и позаботится о защите VDS. В статье покажу, как правильно настроить и защитить виртуальный сервер на Linux. Погнали!

Еще по теме: Форензик кейс взлома серверов под управлением Linux

Мы будем рассматривать нас­трой­ку VDS на при­мере дистрибутива Ubuntu, но инструкция, также актуальна для других дистрибутивов.

Смена пароля пользователя root

Обычно, после покупки виртуального сервера вам должны сооб­щить его IP-адрес и пароль поль­зовате­ля. Пароль можно найти в панели управле­ния сер­вером. Обычно пароль создается генератором паролей и хранится в базе дан­ных. Такие пароли не всегда отвечают требования. Это говорим о том, что его лучше сразу изменить.

Зай­дите по SSH с правами root и вве­дите следующую коман­ду:

При изменении пароля сим­волы не будут отоб­ража­ться — это нор­маль­но. Вве­дите новый пароль и наж­ми Enter. На данном эта­пе мы уже себя немного обе­зопа­сили. Теперь можно прис­тупить к последующей нас­трой­ке.

Есть разные стра­тегии обеспечения безопасности учет­ной записи root:

Вы создаете учет­ную запись поль­зовате­ля с извес­тным толь­ко вам име­нем, пре­дос­тавля­ете ей воз­можность исполь­зовать коман­ду sudo (что­бы вы могли редак­тировать фай­лы кон­фигура­ции и уста­нав­ливать ПО), а затем отклю­чаете вход для пользователя root по SSH. На выходе мы получим пароль­ную аутен­тифика­цию, но будет исполь­зована учет­ная запись, имя которой извес­тно только вам. Пре­иму­щес­тва такие: ник­то не взло­мает учет­ную запись root, пос­коль­ку она всегда будет вык­лючена. Недос­таток один — пароль­ная аутен­тифика­ция не настолько надеж­на, как аутен­тифика­ция по пуб­лично­му клю­чу.

Вто­рая стра­тегия зак­люча­ется в исполь­зовании пуб­лично­го клю­ча. Недос­таток заключается в  более слож­ной нас­трой­ке, именно для конеч­ных поль­зовате­лей:  им при­дет­ся генери­ровать пару клю­чей, и для пользователя, который никог­да это­го не делал, будет слож­но. Большое пре­иму­щес­тво аутен­тифика­ции по пуб­лично­му клю­чу заключается в том, что ник­то не смо­жет сбрутить пароль и получить дос­туп к вашему виртуальному сер­веру.

Если собираетесь исполь­зовать аутен­тифика­цию по клю­чу, тогда можете про­пус­тить главы 2 и 4 — не необходимости соз­давать допол­нитель­ную учет­ную запись и вно­сить ее в sudoers. А вот главу 3 стоит прочитать, так как хороший редак­тор вам очень при­годит­ся.

Создание обычного пользователя

Пос­ле покуп­ки виртуального сервера VDS клиенту сооб­щают пароль root, после чего, поль­зователь вставляет его в про­филь сво­его SSH-кли­ента. Но так поступать нельзя. Во‑пер­вых, учет­ка root — это всем извес­тное имя пользователя, и, ког­да хакер начнет пытаться взло­мать ваш сер­вер методом перебора, он начнет именно с учет­ной записи root. Учетные записи созданные вами он не знает, а root знают все. Поэто­му нам нужно создать обыч­ного поль­зователя, под которым вы будете работать всегда.

Соз­дайте свою учетную запись (обязательно изме­ните имя на свое):

• Коман­да adduser добавит нового пользователя с име­нем user.
• Команда passwd изме­нит пароль новой учетной записи.

Что­бы данный поль­зователь мог работать с пра­вами root, надо будет добавить его в sudoers. Для этого нужен редактор, не просто редактор, а удобный редактор!

Установка удобного редактора

Ис­поль­зуемый подавляющим боль­шинс­твом про­вай­деров редак­тор по умол­чанию Vi очень неудоб­ный и тре­бует дополнительных зна­ний, что может напугать начина­ющего поль­зовате­ля.

Пе­ред уста­нов­кой ПО всегда начинайте с обно­вления спис­ков пакетов. Сделать это можно с помощью коман­ды apt update. Обновлять спи­сок пакетов надо как минимум один раз — перед пер­вой уста­нов­кой. Потом выполняют обновле­ние по мере необ­ходимос­ти.

Итак, уста­новите любой удобный тек­сто­вый редак­тор, который вам нра­вит­ся. Мне нравится редак­тор nano:

За­пус­тить отдель­но можете с помощью команды nano. Находим местоположение редактора:

Как правило он находится здесь /bin/nano. Теперь, настроим его редактором по умолчанию. В последних версиях Ubuntu это дела­ется таким образом:

Теперь выберите nano из спис­ка. Если этот способ не работает (нет коман­ды update-alternatives), пропишите перемен­ную окру­жения EDITOR:

Для автоматического запуска при каждом входе, отре­дак­тируйте файл .bashrc, который лежит в домаш­нем катало­ге поль­зовате­ля. Добавьте в него коман­ду

Эту операцию надо проделать для каж­дого поль­зовате­ля. Для учетной записи root домаш­ний каталог — /root. Для учетной записи spysoftnet — /home/spysoftnet.

Пос­ле этих манипуляций, все коман­ды будут вызывать редак­тор nano. Одна из них — visudo.

Права администратора

Ра­нее мы соз­дали обыч­ного поль­зовате­ля user. Теперь нуж­но прев­ратить его в адми­нис­тра­тора, то есть пре­дос­тавить воз­можность исполь­зовать sudo. Вве­дите в тер­минале коман­ду

Эта коман­да запус­тит тек­сто­вый редак­тор для изме­нения фай­ла кон­фигура­ции sudoers. Най­дите и рас­коммен­тируйте строч­ку:

Ука­зан­ная строч­ка раз­реша­ет всем поль­зовате­лям груп­пы wheel исполь­зовать коман­ду sudo. Если она уже рас­коммен­тирова­на, ничего делать не нуж­но. Наж­мите F10 для выхода из редак­тора.

Пос­ле это­го добавьте нашего поль­зовате­ля user в груп­пу wheel:

Да­лее отклю­читесь от SSH-сер­вера и попытай­тесь вой­ти как поль­зователь user с задан­ным ранее паролем. Обра­тите вни­мание, что, ког­да вы работали как поль­зователь root, приг­лашение коман­дной стро­ки име­ло вид #, теперь оно выг­лядит как $. Залоги­нив­шись, вве­дите коман­ду:

Ес­ли приг­лашение коман­дной стро­ки поменя­лось на #, теперь у вас есть пра­ва root. Такой трюк поз­воля­ет вво­дить коман­ды от име­ни root без исполь­зования коман­ды sudo, что, несом­ненно, удоб­нее.

Запрет входа как root по SSH

Де­ло оста­лось за малым — зап­ретить поль­зовате­лю root вхо­дить в сис­тему по SSH. Для это­го, работая уже под новым поль­зовате­лем user, вве­дите коман­ду:

До­бавьте в кон­фигура­цион­ный файл сер­вера SSH такую стро­ку (или рас­коммен­тируйте ее):

Сох­раните файл кон­фигура­ции, перезаг­рузите SSH (systemctl restart ssh) и поп­робуйте под­клю­чить­ся как поль­зователь root — у вас не получит­ся.

Как вари­ант, мож­но не отклю­чать вход под учет­ной записью root, а нас­тро­ить вход по клю­чу (см. далее) и лишь пос­ле того, как убе­дитесь, что можете вой­ти как root по клю­чу, в кон­фиг SSH добавить строч­ку:

Ко­неч­но, пос­ле это­го нуж­но опять перезаг­ружать SSH.

Вход на сервер по ключу

Су­щес­тву­ет прак­тика аутен­тифика­ции по клю­чу (public key authentication), а не по паролю. Пре­иму­щес­тва и недос­татки это­го метода рас­смат­ривать не будем, здесь одни пре­иму­щес­тва — пароль ник­то не под­берет, так как его поп­росту нет. Это самый надеж­ный спо­соб аутен­тифика­ции.

Прин­цип аутен­тифика­ции по клю­чу сле­дующий: соз­дает­ся пара клю­чей (откры­тый и зак­рытый). Зак­рытый ключ хра­нит­ся на сто­роне кли­ента, и в иде­але он не дос­тупен ни для кого. Откры­тый заг­ружа­ется на сер­вер, к которо­му нуж­но получить дос­туп.

В иде­аль­ном мире клю­чи дол­жны генери­ровать сами поль­зовате­ли. Сге­нери­ровать их мож­но с помощью коман­ды ssh-keygen, а так­же исполь­зуя фун­кци­ональ­ность SSH-кли­ента (нап­ример, воз­можность соз­дания клю­чевой пары есть в Bitvise SSH Client и во мно­гих дру­гих кли­ентах). Если у вас Linux, никакой допол­нитель­ный софт уста­нав­ливать не нуж­но. Вве­дите коман­ду:

Здесь мы генери­руем RSA-клю­чи дли­ной 2048 бит. Пос­ле того как клю­чи будут сге­нери­рова­ны, пуб­личный ключ ста­нет дос­тупен по име­ни:

Далее нуж­но передать откры­тый ключ на сер­вер. Самый прос­той и пра­виль­ный спо­соб сде­лать это — исполь­зовать коман­ду ssh-copy-id:

При выпол­нении этой коман­ды вы можете уви­деть это:

Ваш локаль­ный компь­ютер прос­то не рас­позна­ет уда­лен­ный сер­вер — это нор­маль­но при пер­вом под­клю­чении. Вве­дите yes (имен­но yes, а не y) и наж­мите Enter. Коман­да ssh-copy-id най­дет соз­данный ключ и отпра­вит его на сер­вер. Содер­жимое клю­ча ~/.ssh/id_rsa.pub будет ско­пиро­вано в файл ~/.ssh/authorized_keys уда­лен­ной учет­ной записи. Дан­ный спо­соб сра­бота­ет, если пока еще дей­ству­ет аутен­тифика­ция по паролю.

На эта­пе пер­воначаль­ной нас­трой­ки это обыч­ное дело — сна­чала все поль­зовате­ли генери­руют клю­чевые пары и заг­ружа­ют на сер­вер свои откры­тые клю­чи, а затем зак­рыва­ется вход по паролю. Но если вход по паролю уже отклю­чен, а вам надо заг­рузить ключ для нового поль­зовате­ля, то пот­ребу­ется най­ти спо­соб дос­тавить ключ (файл id_rsa.pub) на сер­вер. Далее нуж­но перей­ти в каталог ~/.ssh учет­ной записи, для которой нас­тра­ивает­ся ключ, и помес­тить содер­жимое id_rsa.pub в конец фай­ла authorized_keys:

Но не будем стро­ить лиш­ние пред­положе­ния и усложнять себе жизнь. Счи­таем, что дос­туп по паролю пока открыт и дос­таточ­но исполь­зовать коман­ду ssh-copy-id для заг­рузки клю­чей на сер­вер. Ког­да откры­тые клю­чи всех поль­зовате­лей заг­ружены, мож­но отклю­чить вход по паролю. Для это­го откройте в любом тек­сто­вом редак­торе файл /etc/ssh/sshd_config и уста­новите в зна­чение No дирек­тиву PasswordAuthentication:

Так­же нуж­но убе­дить­ся, что три сле­дующие дирек­тивы уста­нов­лены таким обра­зом:

Пер­вая вклю­чает аутен­тифика­цию по пуб­лично­му клю­чу, а вто­рая ука­зыва­ет имя фай­ла, в котором дол­жны хра­нить­ся клю­чи. Третья раз­реша­ет вход как root без исполь­зования пароля (по клю­чу).

Ос­талось перезаг­рузить SSH:

На сто­роне кли­ента вой­ти по клю­чу на SSH-сер­вер мож­но так:

Здесь мы ука­зыва­ем имя фай­ла клю­ча, имя поль­зовате­ля и имя сер­вера. В Windows нуж­но нас­тра­ивать исполь­зуемый вами SSH-кли­ент, нап­ример в Bitvise SSH Client необ­ходимо нажать кноп­ку‑ссыл­ку Client key manager на вклад­ке Login и в появив­шемся окне нажать кноп­ку Generate New. В окне Generate New Keypair мож­но прос­то вос­поль­зовать­ся кноп­кой Generate. А мож­но допол­нитель­но защитить клю­чевую пару паролем — для это­го ввес­ти пароль, под­твер­дить его и нажать кноп­ку Generate. Рекомен­дует­ся исполь­зовать пароль­ную фра­зу — если во вре­мя вашего отсутс­твия кто‑то запус­тит SSH-кли­ент и поп­робу­ет под­клю­чить­ся к сер­веру, исполь­зуя ваш откры­тый ключ, у него ничего не получит­ся, так как он не зна­ет пароль.

Па­роль нужен для дос­тупа к клю­чевой паре толь­ко на локаль­ном компь­юте­ре, он не переда­ется в каком бы то ни было виде на сер­вер. Пос­ле того как клю­чевая пара сге­нери­рова­на, нуж­но нажать кноп­ку Export для экспор­та пуб­лично­го клю­ча. Фор­мат — OpenSSH. Пос­ле того как вы сох­раните откры­тый ключ в каком‑нибудь фай­ле, заг­рузите этот ключ на сер­вер и добавьте его содер­жимое в файл:

Спо­собов мно­го, нап­ример мож­но исполь­зовать учет­ку, в которой уже нас­тро­ена аутен­тифика­ция для заг­рузки это­го фай­ла. Мож­но заг­рузить ключ на какой‑то сайт и на сер­вере ска­чать его с помощью коман­ды:

В общем, про­явите фан­тазию, и у вас все получит­ся. Пос­ле того как сер­вер «узна­ет» ваш ключ, в основном окне кли­ента выберите Initial method — publickey, а из спис­ка Client Key — про­филь, в котором вы сох­ранили ключ.

Установка нестандартного порта SSH

По умол­чанию SSH исполь­зует порт 22. Но вы можете перенас­тро­ить его на дру­гой порт из сооб­ражений безопас­ности — тог­да для под­клю­чения по SSH нуж­но знать еще и номер пор­та. Откройте /etc/ssh/sshd_config и най­ди дирек­тиву Port. Вмес­то 22 ука­жите дру­гой порт:

Пос­ле это­го переза­пус­тите SSH и перело­гиньте­сь. При вхо­де в нас­трой­ках кли­ента ука­жите новый номер пор­та.

Настройка брандмауэра

Ра­зоб­равшись с безопас­ностью поль­зовате­лей, нуж­но нас­тро­ить бран­дма­уэр. Тра­дици­онно в качес­тве бран­дма­уэра (филь­тра пакетов) в Ubuntu исполь­зует­ся iptables, но пос­коль­ку Ubuntu позици­они­рует­ся как прос­той дис­три­бутив, то и обо­лоч­ка для iptables была раз­работа­на соот­ветс­тву­ющая — UFW (Uncomplicated Firewall). Это нес­ложный фай­рвол. Пер­вым делом убе­дитесь, что пакет ufw вооб­ще уста­нов­лен, и уста­новите его, если это не так:

Базовая настройка брандмауэра

Те­перь пос­мотрим сос­тояние бран­дма­уэра:

По умол­чанию филь­тр пакетов вык­лючен, поэто­му коман­да выведет сооб­щение Status: inactive. Не нуж­но спе­шить вклю­чать фай­рвол: сна­чала его тре­бует­ся нас­тро­ить. Ведь если порт 22 ока­жет­ся по умол­чанию недос­тупен, то вы потеря­ете дос­туп к сво­ему VDS. Конеч­но, сап­порт поможет, но это нап­расная тра­та вре­мени.

С базовы­ми нас­трой­ками бран­дма­уэр зап­реща­ет все вхо­дящие соеди­нения и раз­реша­ет все исхо­дящие. Такая полити­ка иде­аль­на с точ­ки зре­ния безопас­ности — ведь если кто‑то (и вы в том чис­ле) захочет к нему под­клю­чить­ся, у него это не получит­ся. В то же вре­мя при­ложе­ния на сер­вере смо­гут соз­давать исхо­дящие соеди­нения.

Рас­смот­рим две коман­ды:

Эти два пра­вила как раз и зада­ют полити­ку по умол­чанию: зап­реща­ются все вхо­дящие соеди­нения и раз­реша­ются все исхо­дящие.

Итак, все вхо­дящие соеди­нения зап­рещены. Что­бы до сер­вера мож­но было дос­тучать­ся по опре­делен­ному пор­ту, его нуж­но сна­чала открыть. UFW хорош тем, что адми­ну даже не тре­бует­ся пом­нить номер пор­та — необ­ходимо знать толь­ко наз­вание сер­виса. Нап­ример, вот как мож­но раз­решить под­клю­чение по SSH:

При этом UFW сам соз­даст пра­вило для пор­та 22 — имен­но этот порт исполь­зует­ся для SSH. Бран­дма­уэр зна­ет пор­ты и име­на всех рас­простра­нен­ных служб (HTTP, SSH, FTP, SFTP и так далее).

Од­нако если вы перенас­тро­или SSH на нес­тандар­тный порт, нуж­но явно ука­зать номер пор­та:

Пос­ле раз­решения SSH (это глав­ное, что­бы сей­час фай­рвол нам не разор­вал соеди­нение) мож­но вклю­чить ufw сле­дующей коман­дой:

Не­обхо­димо под­твер­дить запуск:

Раз­берем­ся, что про­изош­ло. Сна­чала мы раз­решили SSH и получи­ли ответ Rules updated, то есть пра­вила обновле­ны. Затем мы вклю­чаем фай­рвол и получа­ем сооб­щение, что он акти­вен и будет запус­кать­ся при заг­рузке сис­темы. На этом базовая нас­трой­ка выпол­нена — SSH успешно работа­ет, и мы можем прис­тупить к даль­нейшей нас­трой­ке филь­тра пакетов.

Создание правил для сервисов

Те­перь нуж­но раз­решить работу дру­гих при­ложе­ний. Как пра­вило, тре­бует­ся раз­решить служ­бу HTTP (веб‑сер­вер), FTP (если этот сер­вис вам нужен) и пос­тарать­ся не забыть о HTTPS (что очень важ­но в пос­леднее вре­мя):

Сде­лать то же самое мож­но было бы и по номерам пор­тов:

При желании мож­но раз­решить целый диапа­зон пор­тов, ука­зав при этом тран­спортный про­токол (UDP или TCP):

Разрешение IP-адресов

Ufw поз­воля­ет раз­решить опре­делен­ному IP-адре­су дос­туп ко всем пор­там сер­вера, нап­ример:

Ес­ли нуж­но раз­решить дос­туп кон­крет­ному IP-адре­су толь­ко к опре­делен­ному пор­ту, то дела­ется это так:

Здесь мы раз­реша­ем не все под­клю­чения к SSH, а толь­ко под­клю­чения с IP-адре­са 111.222.33.44.

Раз­решить дос­туп целого диапа­зона IP-адре­сов (нап­ример, ког­да у адми­на динами­чес­кий IP) мож­но таким обра­зом:

Запрещение IP-адреса и службы

Что­бы зап­ретить дос­туп с опре­делен­ного IP-адре­са, вос­поль­зуйтесь вот такой коман­дой:

При желании мож­но зап­ретить все под­клю­чения к опре­делен­ной служ­бе:

Удаление и сброс правил

Сбро­сит все пра­вила сле­дующая коман­да:

Но до того, как вво­дить эту коман­ду, убе­дитесь, что отклю­чили фай­рвол (коман­да ufw disable), ина­че потеря­ете дос­туп по SSH.

Уда­лить кон­крет­ное пра­вило мож­но по номеру. Сна­чала вве­дите сле­дующую коман­ду, что­бы узнать номер пра­вила:

Да­лее вве­дите коман­ду такого вида:

Настройка резервного копирования

Как пра­вило, в админке управле­ния сер­верами и дру­гими услу­гами про­вай­дера есть воз­можность нас­тро­ить резер­вное копиро­вание для каж­дого сер­вера. В зависи­мос­ти от усло­вий тариф­ного пла­на бэкап может быть бес­плат­ным (то есть вы можете исполь­зовать какой‑то объ­ем прос­транс­тва под бэкапы), а может быть плат­ным. Как показы­вает прак­тика, час­то про­вай­деры тре­буют пла­ту за хра­нение бэкапов, поэто­му сама воз­можность резер­вно­го копиро­вания хоть и име­ется, но вык­лючена, что­бы у кли­ента не было допол­нитель­ных трат.

У вас, как у адми­на VDS, есть два вари­анта. Пер­вый — исполь­зовать средс­тва резер­вно­го копиро­вания про­вай­дера, вто­рой — нас­тро­ить резер­вное копиро­вание на сво­ем сер­вере. Бэкап на сто­роне про­вай­дера надеж­нее, так как резер­вная копия хра­нит­ся за пре­дела­ми сер­вера. Вто­рой вари­ант менее надежен, пос­коль­ку если что‑то слу­чит­ся с фай­ловой сис­темой сер­вера, то вы потеря­ете все свои дан­ные.

Как быть? Луч­ше все­го исполь­зовать ком­биниро­ван­ную сис­тему — нас­тро­ить бэкапы на сто­роне про­вай­дера со сред­ней пери­одич­ностью, ска­жем раз в неделю. При такой пери­одич­ности счет за бэкапы не будет кос­мичес­ким. Зато, если что‑то слу­чит­ся с фай­ловой сис­темой, смо­жете вос­ста­новить дан­ные, пусть и не самые акту­аль­ные, но это луч­ше, чем начинать все с нуля.

А теперь погово­рим о бэкапе вруч­ную на сто­роне сер­вера. Есть целые решения для резер­вно­го копиро­вания. Нуж­ны они или нет — решать вам. Я же пред­лагаю пой­ти по самому прос­тому пути. Пер­вым делом надо опре­делить­ся, какие дан­ные сто­ит резер­вировать.

Если у вас на сер­вере сайт (нап­ример, интернет‑магазин), то копиро­вать нуж­но толь­ко фай­лы кор­невого катало­га веб‑сер­вера ( DocumentRoot, обыч­но это /var/www/html, но зависит от нас­тро­ек сер­вера) и базу дан­ных.

Фай­лы веб‑сер­вера мож­но копиро­вать раз в неделю — они меня­ются отно­ситель­но нечас­то. Если вы дела­ете бэкап средс­тва­ми про­вай­дера, ска­жем каж­дую пят­ницу, то бэкап фай­лов сер­вера мож­но делать в середи­не недели — в сре­ду. Тог­да у вас будет на вся­кий слу­чай две резер­вные копии за неделю. Мож­но и чаще — глав­ное, что­бы хва­тило мес­та на дис­ке. Если у вас 1 Тбайт, а сайт весит 250 Гбайт, то очень час­то бэкапы соз­давать не при­дет­ся.

Соз­дать архив с резер­вной копи­ей фай­лов сай­та мож­но коман­дой:

Эту коман­ду нуж­но добавить в рас­писание crontab. Вве­дите коман­ду crontab –e и добавьте строч­ку:

Де­лать бэкап луч­ше все­го ночью, что­бы сни­зить наг­рузку на сер­вер. Здесь копия будет соз­давать­ся по сре­дам в два часа ночи. Рас­паковать архив мож­но с помощью коман­ды unzip.

Те­перь о базе. Изме­нения в базу дан­ных вно­сят­ся пос­тоян­но: менед­жеры добав­ляют информа­цию о про­дук­тах, какой‑то скрипт импорта изме­няет цены и остатки товаров, а посети­тели дела­ют заказы. Поэто­му копия базы дол­жна соз­давать­ся раз в день. Для копии исполь­зуем mysql-dump:

Здесь cp_user — имя поль­зовате­ля БД, cp_main_v2 — имя базы дан­ных, опция max_allowed_packet зада­ет мак­сималь­ный раз­мер пакета — на слу­чай, если БД занима­ет нес­коль­ко гигов, эта опция вас спа­сет. Бэкап дела­ется в файл db-latest.sql. Вос­ста­новить­ся мож­но так:

Наз­начение парамет­ров дол­жно быть понят­но. Парамет­ры host и port мож­но не ука­зывать, если MySQL работа­ет на localhost и исполь­зует стан­дар­тный порт. Коман­ду соз­дания дам­па нуж­но запус­кать каж­дый день, поэто­му в crontab добав­ляем стро­ку

Бэ­кап будет сни­мать­ся каж­дый день в час ночи (а в два мы запус­каем соз­дание бэкапа фай­лов).

Кро­ме бэкапов не забывайте о снап­шотах! Перед каж­дым зна­чимым изме­нени­ем на сер­вере (вро­де уста­нов­ки рас­ширения, перес­борки CMS, обновле­ния ПО, нап­ример уста­нов­ки новой вер­сии PHP) делайте снап­шот. Да, всег­да мож­но вос­ста­новить­ся из бэкапа, но бэкап у нас не самый све­жий, да и вре­мени такое вос­ста­нов­ление занима­ет боль­ше, чем вос­ста­нов­ление из снап­шота. Снап­шоты тоже плат­ные, но их цена нич­тожна на фоне прос­тоя production-сер­вера.

Установка админки

Лич­но мне про­ще и при­выч­нее управлять сер­вером через SSH. Но если нужен гра­фичес­кий интерфейс для выпол­нения ежед­невных рутин­ных задач, можете уста­новить панель управле­ния. Выбор кон­крет­ной панели зависит от двух фак­торов: необ­ходимой фун­кци­ональ­нос­ти и сто­имос­ти панели управле­ния. Если нуж­ны бес­плат­ные решения, смот­рите в сто­рону Webmin и VestaCP. Осталь­ные вари­анты менее популяр­ны.

Заключение

Собс­твен­но, на этом все — базовая нас­трой­ка и защита виртуального сервера VDS завер­шена. Теперь мож­но прис­тупить к уста­нов­ке и нас­трой­ке необ­ходимо­го ПО (Nginx, MySQL, PHP и все такое).

Полезные ссылки:

• Как зашифровать трафик на Linux
• Инструменты для защиты сервера VPS
• Обзор инструментов аудита безопасности Linux