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

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

Port 2206  

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

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

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

sudo apt install ufw  

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

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

sudo ufw status verbose  

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

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

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

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

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

ufw allow http
ufw allow https
ufw allow ftp  

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

ufw allow 80
ufw allow 443
ufw allow 21  

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

sudo ufw allow 2000:2200/tcp
sudo ufw allow 4000:4400/udp  

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

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

ufw allow from 111.222.33.44  

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

ufw allow from 111.222.33.44 to any port 22  

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

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

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

ufw allow from 123.45.67.89/24 to any port 22  

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

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

ufw deny from 123.45.67.89  

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

ufw deny ftp  

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

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

ufw reset  

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

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

ufw status numbered  

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

ufw delete <номер правила>  

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

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

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

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

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

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

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

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

zip -r /backups/latest.zip /var/ww/html  

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

1 0 2 * * 3 /usr/bin/zip –r /backups/latest.zip /var/ww/html  

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

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

mysqldump -u cp_user -p --opt cp_main_v2 --max_allowed_packet=100M > db-latest.sql  

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

mysql --host=127.0.0.1 --port=3310 --max_allowed_packet=100M -u cp_user -p cp_main_v2 < /db-latest.sql  

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

0 1 * * * /usr/bin/mysqldump -u cp_user -p --opt cp_main_v2 --max_allowed_packet=100M > /root/db-latest.sql  

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

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

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

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

Заключение 

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