Продолжаем наш чек-лист по защите сервера от взломов. С первой частью материала вы можете ознакомиться тут.
Шаг 7. Предохраняйтесь
SSH — это прекрасно. С его помощью можно передавать хоть классические HTTP-запросы, хоть файлы по FTP-протоколу, хоть видеопоток с веб-камеры. Но попробуйте приучить себя изначально использовать «безопасные» версии «стандартных» протоколов — они есть почти под все. Вместо HTTP — настройте HTTPS. Вместо FTP — SFTP. Вместо SNMP — SNMP3. Ну и так далее, исходя из того, для каких задач предназначен ваш сервер.
К сожалению, средства на все случаи жизни здесь нет — все упирается в конкретные задачи и пресеты софта/железа. Общая мысль сводится к следующему — отключите «стандартные» протоколы там, где это возможно, и оставьте только их «безопасные» версии. Вы же поедете по бездорожью на машине без подвески, верно? Так вот в данном случае подвеска — это «безопасные» версии «стандартных» протоколов.
Шаг 8. Сжигайте не корабли, а порты!
Мы закрыли доступ к ненужным протоколам — супер! Теперь давайте приучим себя закрывать неиспользуемые порты. Вы же не станете строить окно во всю стену в комнате, где планируете хранить свои миллионы? Да и простое окно сделаете бронированным. Здесь тот же принцип.
Вот только защитить порт сложнее, чем отключить, — поэтому, если порт не используется, целесообразнее его отключить (замуровать окно). В крайнем случае, если вы вдруг начнете масштабироваться и вам понадобятся новые порты — вы всегда сможете включить их обратно.
Шаг 9. Против толпы не попрешь
Какой бы совершенной ни была защита вашего сервера (а она априори даже близко не подойдет к идеалу, если вы не живете кибербезом и взломами в режиме 25/8) — все это имеет смысл лишь в том случае, если ваш сервер вообще может работать. Если сервер «уронят» DDoS-атакой — в навороченной защите не будет смысла.
Более того, при неправильной настройке во время DDoS-атаки ваш сервер может еще и «словить шизу» — например, начать выдавать зашифрованные пароли в открытом виде. Шанс подобного мал, но такое все же существует.
В целом по-настоящему защититься от DDoS-атаки невозможно. Да и не ваша это задача — оказать более-менее серьезное противодействие сможет лишь ваш хостинг-провайдер. Тем не менее это не значит, что вы не должны защищаться со своей стороны.
Подключите к своему проекту хоть какую-то защиту от DDoS, да хотя бы тот же Cloudflare — это существенно снизит риск, что ваш сервер упадет. Ведь DDoS — дорогостоящее удовольствие и позволить себе надолго «уронить» проект, пусть и с примитивной, но присутствующей защитой от DDoS, могут далеко не все кул-хацкеры.
Однако помнить, что абсолютной защиты от DDoS-атак не существует, все же нужно. А потому одним из способов защиты от DDoS является заблаговременное продумывание альтернативных каналов взаимодействия с вами. Например, если вам «уронили» интернет-магазин, альтернативой может быть бот для покупок в Телеге.
Но это скорее лирика — в классическом арбитраже «альтернативить» вряд ли получится. И все же лучше продумать свои действия при DDoS-атаках до того, как вам «уронят» сервер.
Шаг 10. Рефлексируйте
Любое развитие строится либо на прогнозировании проблем, либо на их преодолении. Актуально это и в случае с кибербезом. Для того чтобы понимать, что происходит с вашим сервером, пытался ли его кто-то атаковать и как именно пытался — нужно вести постоянный мониторинг.
Разумеется, сидеть 24/7 и все отслеживать не нужно — для этого есть логи. Однако нужно убедиться, что логи вообще ведутся. И периодически их перепроверять, выявлять нестандартные состояния. В крайнем случае, даже если вы ничего не поймете, наличие логов даст вам возможность общаться с платными специалистами предметно. А это существенно ускорит залатывание дыр и снизит стоимость их услуг.
Шаг 11. Самый главный мой враг — это я сам
В гонке между взломщиками и кибербезопасниками у последних есть одно преимущество: в отличие от хацкеров, они знают об уязвимостях своих систем. Разумеется, все не так буквально — но им, а в данном случае вам как владельцу сервера, не нужно ничего сканировать, пробивать и узнавать. Вы уже знаете, как устроена ваша система — используйте это!
Пытайтесь взломать сами себя — гуглите уязвимости своей системы и фиксите их заблаговременно. Может показаться, что это сложно — но это проще, чем кажется. Фишка в том, что вам не нужно понимать принцип взлома — вам достаточно знать, где уязвимость. Так, например, если у вас сайт на Wordpress, вам не обязательно уметь осуществлять SQL-инъекцию — но вам нужно знать, что у вас не должно быть страниц wp-login.php/wp-admin.php. Поэтому пытайтесь разобраться, как взломать ваш сервер.
Шаг 0. Сохраняйтесь
Можно очень долго копать в кибербез, но куда надежнее исходить из того, что рано или поздно вас взломают. Действуйте наперед! Облегчите себе устранение последствий по максимуму — делайте бэкапы. Именно поэтому данный шаг — номер ноль.
Делайте бэкапы регулярно — не только перед обновлениями.
А еще лучше — делайте бэкапы бэкапов.
И по возможности сохраняйте все бэкапы, а не только последние 3–5.
Дело в том, что с момента взлома до момента обнаружения взлома могут пройти годы. Наличие бэкапов позволит максимально безболезненно осуществить откат системы до работоспособного состояния.
И да — храните бэкапы отдельно! В идеале на носителе, отключенном от интернета.
Подводя итоги
Традиционно для рубрики «Киберпаранойя» напоминаем: безопасных систем не существует. Тем не менее описанные выше шаги помогут вам защититься хотя бы от профанов. Если же вы хотите обезопаситься от тех, кто в теме, — тут поможет только личное изучение вопроса и постоянное повышение своих компетенций. Таков уж путь кибербеза — это вечное соревнование между «хорошими» хацкерами и «плохими».
