Как защитить сайт от взлома и атак. Безопасность для владельцев сайта

Сооснователь и технический директор PR-CY Евгений Баранов на вебинаре рассказал о безопасности сайта и почему важно за ней следить.

Евгений Баранов

Сооснователь и технический директор PR-CY

Сегодня мы разберем ряд вопросов: Почему важна безопасность сайта? Какие существуют основные угрозы и что с ними делать? По ходу презентации будут приводиться примеры, демки.

В данном материале рассмотрим: 

• Как вирусы попадают на сайт? 
• Как защитить сайт от хакеров? 
• Что может получить хакер после взлома вашего сайта? 
• Какие есть виды взлома? 
• Как защитить сервер от взлома? 
• Как узнать, заражен ли сайт вирусами? 

Начнем с того, зачем нужна безопасность. Из очевидного, если у нас сайт взламывают, вы теряете деньги, клиентов и трафик. Менее очевидное — это санкция от поисковых систем. 

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

Время на восстановление — это момент, который многие упускают из виду. Здесь ведь ситуация связана не только с тем, что надо сайт привести в порядок. Это то время, которое вы могли бы потратить на разработку новых фич. Вместо этого вы тратите его на попытки найти вектор атаки, разобраться в логах, как же вас все-таки взломали. Тратите свои усилия на то, чтобы восстановиться из backup, если он был. Если его не было, то ситуация вообще из разряда "Плохие новости". Постарайтесь избегать этого.

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

В России есть Закон о персональных данных, в Европе — GDPR (General Data Protection Regulation), который вы обязаны соблюдать, если работаете на европейском пространстве, иначе вам прилетят многомиллионные штрафы. Каждый факт утечки персональных данных — это штрафы, большие штрафы. Поэтому безопасность здесь важна со всех сторон.

Чтобы узнать, не взломали ли ваш сайт, можно использовать: 

• онлайн-сервисы;
• антивирусы;
• панель вебмастеров Google Search Console. 

Остановимся на третьем варианте — самом простом и самом быстром.

Google Search Console

В Google Search Console перейдите на вкладку "Проблемы безопасности и меры, принятые вручную" -> "Проблемы безопасности". 

Если вы обнаружили проблемы, у меня для вас плохай новость: вы потеряете трафик из поисковых систем, будут проблемы индексацией. Узнайте детально, как проверить индексацию сайта, как ускорить индексацию, если ваш сайт или страницу не нашел поисковый робот. 

Начнем с самого простого и важного, конечно, это не совсем связано с технической стороной,— личной безопасности, личной гигиены. Немного расскажу о том, какие уязвимости могут быть в коде, системах управления контентом, системном софте и библиотеках. Также затрону небольшой раздел — атаки класса DoS и DDoS, чем они отличаются, почему вам, в первую очередь, будет угрожать DoS, а не DDoS, вопреки тому, что многие думают.

Личная безопасность

Под личной безопасностью я подразумеваю данные, которые вы как администратор сайта можете скомпрометировать. К этому относятся пароли, сетевая активность, просто ваши файлы на дисках. 

Начнем с самого частого вектора атаки — паролей. Чаще всего уводят пароли от админки, добавляют туда порнографию, размещают внешние ссылки на какие-то платные ресурсы и т. п.

Компрометация паролей может происходить несколькими путями:

• Трояны на вашем компьютере (привет пользователям Windows)
• Фишинг, когда вам присылают ссылку на очень похожую страницу, например, на админку хостинга или на вашу собственную админку от сайта. Вы туда вводите пароль, а он уходит в файл к злоумышленнику. 
• Брутфорс. Здесь даже можно разделить на два вектора. Первый, это очень простой пароль (123 и т.п). Второй вектор — это уязвимость самого софта к брутфорсу. Про это все забывают. Например, если админка без какого-либо Raid лимита, без ограничений позволяет очень быстро вводить пароли, то их очень легко перебирать. Здесь даже установка какой-нибудь элементарной защиты в виде задержки в минуту между неудачной попыткой ввода пароля, свела бы на нет весь возможный брутфорс. 
• Одинаковые пароли. Если вы используете один и тот же пароль на нескольких сервисах, у меня плохие новости, связанная с тем, что есть такая штука как сливы данных с разных сайтов. То есть я захожу на какой-нибудь сайт регистрируюсь, ввожу свой пароль, который у меня используется еще в ста местах. Потом что-то происходит, например, администраторы решили сделать выгрузку из базы данных, а по какой-то интересной случайности все пароли на сайте хранятся в открытом виде. И все пользователи ВКонтакте с их email-адресами, телефонными номерами попадает в DarkNet на публичные площадки хакеров.

Перехват сетевого трафика

С сетевым трафиком все очень интересно. Дело в том, что если мы используем беспроводное соединение Wi-Fi, а иногда и проводное соединение, то его можно перехватить. 

Как его можно перехватить? Например, вы сидите в кафе, подключились к бесплатному Wi-Fi с открытой сети и какой-нибудь парень за соседним столиком открывает обычный laptop и начинает перехватывать все пакеты, которые идут от вас. В самом примитивном виде он может делать это даже с Mac, где есть уже установленный софт, который позволяет перехватывать трафик с соседних столиков.

У злоумышленника может быть установлено и специальное программное обеспечение Kali Linux или что-то подобное, может даже хитроумные устройства, которые это делают все автоматически. Вы заходите на свой сайт, на котором по стечению обстоятельств не используется https, то есть трафик не шифруется, вводите туда пароль и как следствие пароль оказывается у злоумышленника. 

Здесь можно утащить даже не пароль, а авторизационные cookies, если трафик не шифрованный. Это может произойти как в бесплатном публичном Wi-Fi, так и в корпоративной сети. Как это происходит? Здесь очень много от администраторов и владельцев бизнеса, устанавливается специального программного обеспечения для мониторинга за своими сотрудниками. Точно также какой-нибудь админ смотрит логии, ваш пароль и думает, дай-ка я зайду что-нибудь поверчу на вашем сайте. То есть даже корпоративная сеть небезопасна для ваших персональных данных.

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

Как-то давно, когда я еще занимался разработкой веб-сайтов, нам понадобилось взять на поддержку сайт, разработчик которого попал в СИЗО и отказывался давать нам пароль от админки от домена. То есть мы не могли перенастроить DNS записи. Условие разработчика было в том, что мы приходим к нему в СИЗО и он на нашем на ноутбуке набирает пароль, мы все делаем и он оттуда выходит. 

Что сделал я? Я установил на свой ноутбук специальную программу, которая записывает все пароли, пришел в СИЗО, поставил ноутбук, он ввел этот пароль, вышел оттуда и все замечательно. Я ушел, открыл эту программу, вытащил пароль и спокойно пользовался. Я про этот Keylogger уже успел забыть, когда до меня дошло: иногда знакомые на моем компьютере заходят в свои соцсети и, соответственно, вводят свой пароль.

По факту получилось, что все пароли, которые они вводили, оставались на моем компьютере. Я этим, конечно, не пользовался, но вы понимаете что, если вы вводите свой пароль на чужом устройстве, помните, что его можно перехватить.

Здесь небольшая демка, с помощью которой я покажу, как это все происходит в реальности. Есть такой сервис "have I been pwned", который специализируется на том, что сканирует публичные сливы приватных данных. Здесь вы можете ввести свой email или пароль и проверить. Я ввожу свой пароль и вижу, что мой пароль встречается как минимум в 10 утечках с сайтов. Что это за сайты? Adobe, Bookmate, CD Project Red (я играл в Ведьмака), DISQUS, Dropbox, Houzz, Kickstarter и наш любимый ВКонтакте. 

Если посмотреть мой публичный пароль, так называемый public пароль (он не очень сложный), помимо меня его использовали 782 раза. Наверное, у меня не очень богатое воображение, поэтому такие пароли лучше не использовать. В целом, этот сайт не был замечен в чем-то криминальном, но после того, как вы проверите свой пароль, я советую на всякий случай его сменить.

Защита паролей

Совет 1. Делайте сложные пароли. Никогда не используйте одинаковые пароли для соцсетей, админок, доступа к сайту и еще 100 сервисам. 

Теперь перейдем от угроз к решению. Здесь ничего нового, все уже давно придумано до нас. Если вам надо ввести на каком-то сервисе, каждый раз на каждом сайте используйте уникальный пароль. У меня, когда я смотрел в последний раз, уже было больше тысячи паролей. Естественно, тысячу паролей я запомнить не могу, поэтому у меня стоит менеджер паролей "1Password". Это платный сервис, свое время он очень хорошо синхронизировался, но можно использовать и бесплатные программы. 

Что это дает? Это дает вам один мастер-пароль, который вы помните и нигде не записываете. Он должен быть довольно сложным, но его тоже иногда желательно менять. Когда вы его вводите, у вас открывается база данных, где находятся все ваши пароли для всех сервисов. Здесь есть автозаполнение, сейчас оно работает на мобильных устройствах и в браузерах. Если честно, я даже здесь храню пин-коды от своих карт и номера паспортов. Плюс менеджер синхронизируется на все устройства. И как уже упоминалось в истории с СИЗО, не вводите пароли на чужих компьютерах.

Как защитить сайт? 

В действительности самая действенная киллер фича — это двухфакторная авторизация. К сожалению, она используется не на всех сервисах. В чем смысл двухфакторной авторизации. Вы входите на сервис, вводите свой обычный пароль, после чего у вас запрашивают второй фактор. Второй фактор может быть, например, в виде смс-сообщения, как во многих онлайн-банках. То есть вам на телефонный номер приходит СМС с кодом, вы этот код вводите. Также второй фактор может быть в виде отправки сообщения на email. Например, этим Steam этим очень грешит. Когда вы входите в свой Steam-аккаунт на каком-то устройстве, у вас запрашивают сообщение с email.

Также есть двухфакторная авторизация с помощью специального приложения, например, Google Authenticator, в котором постоянно генерируются одноразовые ключи. В отличии от смс-сообщений, где сим-карту можно легко украсть, здесь плюс в том, что мобильное устройство с приложением — это самое безопасное, что сейчас есть. Если вам надо, например, провести банковскую операцию, ее в десятки раз безопаснее проводить с помощью мобильного приложения на IOS и даже Android. Конечно, если у вас не стоит шпионское оборудование, то все будет хорошо и вас не взломают. Поэтому второй фактор на телефоне самый безопасный. Если есть возможность настройте Google Authenticator, это не сложно.

По поводу смс, кстати, не так давно была волна взломов банков с помощью смс. То есть у людей либо воровали сим-карту, либо делали ее дубликат и получали авторизационный код от банка через смс-сообщение. Чаще всего именно воровали сим-карту, потому что на ней практически у всех нас стоит пароль "0000". Так что стоит поменять себе пароль на сим-карте либо использовать более надежные средства аутентификации.

Сетевая безопасность

Совет 2. Не используйте публичный Wi-Fi и бесплатные прокси.

С сетевой безопасностью не все так однозначно. С одной стороны, сейчас все используют https, которого зачастую достаточно, если не брать во внимание сложные атаки. 

С другой стороны, VPN, у которого есть свои нюансы. Если вы используете какой-то сервис VPN, возникает вопрос, насколько вы доверяете провайдеру. Я не доверяю, вообще, никому. Если я использую VPN, то только VPN с self-host на своем сервисе, который я поставил туда собственными руками.

Как защитить сайт?

Как я говорил выше, никакого публичного Wi-Fi, никаких бесплатных прокси. VPN, https — хорошо. Кроме того, на https сайтах уже давно есть маст-хэв, потому что, если вы его не используете, поисковики вас начнут пессимизировать в выдаче и вводить предупреждение о том, что этот сайт небезопасный не вводите здесь пароль. Кстати, использование на сайте https является важным пунктом seo-чеклиста любого seo-специалиста.  

Устранение уязвимостей в коде

Совет 3. Найдите хорошего разработчика, чтобы он предотвратил уязвимости в коде. 

В коде есть четыре класса больших уязвимостей:

• RCE; 
• SQL Injection; 
• XSS и CSRF (удаление, выполнение кода);
• DoS. 

Самое опасное это, когда вам на сайт загружают shell и начинают выполнять любые команды. Доступ к базе данных, файловой системе, в общем, доступ ко всему. Это, наверное, самое страшное, что может с вами случиться.

Как это зачастую происходит. Чаще всего — через загрузку исполняемых файлов. Наиболее популярный язык вебита все еще PHP. То есть мы берем php-файл переименовываем его в shell.gpeg.php и загружаем его куда-нибудь в виде картинки на древний WordPress и т.п. Есть ненулевая вероятность, что он загрузится, поместится в определенную папку на сервере. После того, как мы к нему обратимся, код из этого файла начнет исполняться (из-за того, что там стоит расширение php) и злоумышленник начнет выполнять любые команды на этом сервере. Это очень простой, утрированный случай. Сегодня в чистом виде такое не происходит, но все еще возможно. 

У нас масса старого программного обеспечения, в котором могут быть подобные дыры. Например, это могут быть редакторы, галереи, комментарии или любое другое место, куда можно загрузить файл.

SQL Injection — это довольно распространенный класс, который встречается почти на всех сайтах. Я уже знаком с SQL Injection 15 лет и на моих сайтах они были. Два раза допускал с SQL Injection ошибку, хотя все прекрасно про это знал. Все мы люди, все мы допускаем ошибки и это наиболее частая. 

Когда вы берете параметр от пользователя (допустим, он вводит username), и как есть вставляете в sql запрос. И если вы не фильтруете специальные символы, то злоумышленник может отредактировать username таким образом, что он будет содержать часть запроса. После того, как это выполнится на сервере, данные из базы данных появятся у него на странице сайта. Например, вместо username. 

Суть SQL Injection в том, что злоумышленник получает доступ к вашей базе данных, достает оттуда пароли, а может и дропнуть, если у вас нет ограничения у пользователя, также может записать туда новую админскую учетную запись. В общем, может делать, что хочет. Зачастую данные сливаются таким образом.

Дальше, с одной стороны, менее опасные, с другой стороны, крайне распространенные, это Cross Site Scriptin и Cross-Site Request Forgery. 

Cross Site Scriptin — это, когда на ваш сайт вставляется JavaScript код, который выполняется в браузере у клиента. 

Вам присылают ссылку, как админу этого ресурса, вы по ней переходите, ваши авторизационные cookies улетают злоумышленнику. Злоумышленник заходит на ваш сайт и попадает в админку.

Cross-Site Request Forgery. Здесь суть в том, что на сайте выполняется действие от имени пользователя. 

Пользователь заходит на посторонний сайт и выполняет там какое-то действие, например, двигает мышкой и вот в этот момент хитрым образом выполненный JavaScript код на самом деле выполняет действие на вашем сайте (переводит деньги, меняет пароль). Такое возможно, от этого можно защититься, но это требует изменения кода, то есть здесь требуются навыки программирования. 

Вообще все классы уязвимости требуют изменения в коде. Почти в 99% случаев. Бывает можно ограничиться на уровне конфигурации, но все равно нужны специалисты.

Denial of Service. Я здесь специально пишу DoS, а не DDoS (Distributed Denial of Service), потому что DoS — это, в первую очередь, ошибка программиста, ошибка архитектуры. Это, когда запросы на ваш сайт идут очень медленно. И злоумышленник просто находит такие медленные страницы сайта, отправляет туда массу запросов и все у вас падает.

Плохие новости в том что, не имея навыков программирования и серьезно не вглядываясь в код, маловероятно, что вы найдете эту уязвимость. Хорошие новости — хакеры в той же самой ситуации, только у них еще и нет доступа к исходникам, и сделать это им будет еще сложнее. Когда у вас написан кастомный код (даже если он насквозь дырявый), а не готовые CMS, вероятнее всего, пока вы не станете мега популярны (как Google, Facebook), вы никому не будете интересны и никто вас не будет взламывать.

Как защитить сайт? 

Решения уязвимости. Правильное решение: просто платить деньги хорошим разработчикам. Если у вас сервис приносит тысячи долларов в месяц, а вы разработчику платите 100 баксов, чтобы он вам что-то поправил в WordPress, то это неверное решение. Найдите хорошего разработчика.

Устранение уязвимостей CMS

Совет 4.  Испольуйте SSL-сертификат, не ставиьте ворованный софт, регулярно обновляйте CMS. 

Переходим к части, которая касается большей части аудитории, уязвимости в популярных CMS. Здесь я отметил WordPress, Drupal, Joomla.

Хакеры могут легко узнать CMS и использовать эту информацию против вас. Подробнее мы писали в статье Как узнать CMS сайта. 

Я себе как-то раз на свой персональный сайт поставил WordPress и меня через какое-то время взломали. Я уже успел забыть про WordPress, я его не обновлял и меня взломали. 

Как это происходит. Эти системы с открытым исходным кодом. Они бесплатны и код может смотреть кто угодно. И хакеры их регулярно смотрят, находят там какую-то уязвимость, вводят в Google "WordPress версия такая-то", находят там тысячи сайтов, пишут script и просто одной волной все эти сайты взламывают, размещают там платные ссылки и т. п. Таким образом, монетизируются ошибки, ведь часто о взломе вашего сайта и не догадываются вебмастера при покупке ссылок на сайт. Еще хуже, если он заливает какие-нибудь бэкдоры для пользователей нулевого дня и все ваши посетители заражаются и превращаются в огромный бэкнет.

Второй вектор — это бесплатный сыр. Это какие-то ломанные CMS, плагины, темы. Стоит ли объяснять, что бесплатно редко что бывает. Если вы скачиваете бесплатные взломанные программные обеспечения, скорее всего, в нем будет бэкдор либо будут размещены ссылки либо он зашифрует вам весь диск и т.п. 

Если у вас нет денег на платный софт, поставьте бесплатный WordPress. Просто новый, свежий, чистый WordPress. Скачивать с бесплатных сайтов себе дороже, особенно сейчас. Раньше еще были благородные пираты, которые взламывали софты и раздавали нуждающимся, то сейчас таких я не встречал.

Как защитить сайт? 

Собственно, решение уязвимости — это не ставить ворованный софт, регулярно обновлять софт (если у вас старая программа, скорее всего, в ней уже есть дыры), мониторинг, минимизация рисков.

Давайте попробуем просканировать какой-нибудь сайт. Берем самый популярный — WordPress. Есть такой инструмент, называется WPScan. Он сканирует WordPress-сайты на наличие уязвимостей. 

Я проверил свой персональный сайт. В результате он выдал массу уязвимостей. Здесь и Cross Site Scriptin и CSRF, всего 44 уязвимости. Почему меня это не беспокоит? Я давно снес WordPress со своего сайта и просто загрузил туда статичные html-странички, которые от него остались. Просто я довольно ленивый человек (давно не обновлял сам контент на сайте), поэтому я взял Wget, загрузил рекурсивно все страницы и положил их в виде html. 

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

Уязвимости в системном софте и библиотеках

Совет 5. Ограничьте доступ к старому софту, закройте базу данных от внешнего мира, устанавливайте только необходимый софт. 

На самом деле, это самая неприятная штука, потому что мы все забываем обновлять системное программное обеспечение. Например, веб-сервер Nginx, Apache, PHP сам по себе. Проблема в том, что в системном софте уязвимости сложнее эксплуатируются, но последствия от них зачастую страшнее. Здесь, получается, есть доступ ко всему серверу и на системном уровне. Это очень опасно.

Например, вот банальный вопрос. Какая версия PHP у вас стоит? Для многих будет новостью, что актуальная версия PHP на данный момент только "PHP 7.4". Версия PHP 7.3 еще саппортится, она на поддержке, но уже устаревает. Версии PHP 7.2 и ниже уже не поддерживаются и даже security уязвимостей в них не обновляется. 

То есть если там есть уязвимость, то, соответственно, ваш сайт уязвим. Самое частое, что я слышу, когда говорю о том, что надо обновлять PHP: "Я не могу обновить PHP, потому что у меня работает какой-то специфичный софт, которому уже 10 лет и, который работает только на версии PHP 5". 

Вроде бы уже четвертую версию похоронили, но, тем не менее, раньше была и четвертая. Пятая версия, что это значит? Даже с оглядкой на то, что у этой версии нет критических уязвимостей, PHP старый. У него стоит софт, которому десять лет, который написан неизвестно кем, неизвестно когда. И вот он уже на 99% уязвим.

Решение то же самое. Это регулярно обновлять софт. Если у вас sharing хостинг, то это и плюс и минус. С одной стороны плюс, потому что о вас заботиться ваш хостинг-провайдер и, он обновляет программное обеспечение. С другой стороны, минус, потому что не все хостинг-провайдеры обновляют программное обеспечение. В силу своей деятельности я предпочитаю все это брать в свои руки. Кому-то проще найти действительно хороший, дорогой хостинг, который будет решать все проблемы за них.

Как защитить сайт? 

Если у вас стоит старый софт, то постарайтесь ограничить к нему доступ. Если у вас установлен какой-то специфичный софт, например, база данных. Очень специфичная — работает на порту MySQL 3128 и смотрит она на весь мир. Если в этом MySQL есть какая-то уязвимость, то любой пользователь интернета может сделать запрос к этому порту и получить доступ. Не говоря уже о том, что базу данных, в принципе, наружу светить плохая идея. 

Если вы умеете пользоваться Firewall, то можете закрыть всю базу данных для внешнего мира кроме SSH, через который вы получаете доступ к консоли, и 80 и 443 порта для https-трафика. То есть локально у вас доступ к базе данных сохраниться, после того как вы подключите SSH, он тоже сохраниться, но снаружи никто не сможет "достучаться" до этого программного обеспечения. 

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

Третий пункт — устанавливать только необходимый софт. Зачастую, если у вас установлено (это относится к cms и системному софту) масса всякого "мусора" на сервере, то статистически повышается вероятность того, что что-то из этого уязвимо. Если вам не нужен этот софт, например PhpMyAdmin, удалите его. Если вам не нужен плагин для Wordpress, если вы можете без него жить и обойтись, удалите его. Этим вы минимизируете себе риски уязвимости. 

Чем меньше софта, тем меньше вероятность уязвимостей. Можно разносить еще на разные изолированные сервера. Таким образом, если у вас взломают один сайт, то вы не потеряете хотя бы все остальное.

DoS DDoS

Совет 6. Следите за DDoS-атаками и предотвращайте их. Можно подключить CDN/прокси, использовать специальную EGS капча. Все рекомендации ниже. 

Давайте поговорим про DoS и DDoS. В чем разница.

DoS — Denial of Service — это, когда злоумышленник искусственно нагружает ваш сайт (не только сайты), который впоследствии перестает работать.

Distributed Denial of service отличается только тем, что атака идет не с одного устройства (ни с какого-то конкретного ноутбука, лэптопа и т.д.), а из ботнета. То есть из большого количества взломанных компьютеров, которые отправляют к вам запросы. Иногда это могут быть даже не взломанные устройства.

Пример из моей молодости. У меня есть относительно популярный сайт, несколько десятков тысяч посетителей в сутки приходит. И когда мне кто-то очень сильно "насолил", я просто вставил iFrame, в котором указал в качестве source очень медленную страницу этого нехорошего человека. В итоге все мои посетители, которые заходили на мой сайт, делали запрос к этой медленной странице и просто эффективно укладывали сайт этого человека, что называется "мордой в пол". То есть у него переставал работать. 

Я не рекомендую никому так делать. Это незаконно, это плохо и вообще это моя больная фантазия, но, тем не менее, такое возможно, такой вектор атаки тоже есть.

Как это эксплуатируется. Какой-то человек находит у вас медленную страницу. Такие страницы практически есть у всех. Это может быть страница сложной фильтрации в интернет-магазинах, это может быть поиск. Это может быть пагинация на тысячную страницу, потому что классический способ пагинации — это просто скипнуть первую тысячу записей и перейти к 1001. Это медленная операция. Злоумышленник находит подобные страницы, делает к ним запросы, много параллельных запросов и ваш сайт перестает работать. На этот счет у меня есть отдельная демка.

Я сделал небольшой сайт на своем стареньком домене. Делаем к нему запрос, замеряя время этого запроса. Запрос происходит быстро за 100 миллисекунд, даже меньше. Все отлично, все работает. Также я сделал на сайте медленную slow php-страницу, в которой эмулируется задержка в 5 секунд. То есть я выполнил, раз, два, три, четыре, пять. Результат, запрос выполнился за 5 секунд. 

Существуют специальные программы, которые позволяют делать параллельные запросы к странице. Самая известная и популярная — это Apache benchmark. То есть Benchmark для замеров производительности. Зачастую она используется в тестировании.

Но не все так просто. Например, если я сделаю запрос не к медленной, а к главной странице. Здесь получается: AB — C 200 параллельных запросов — n. Это 1000 запросов всего, запускаю и оно начинает работать. Сделано 100, 200, 300, 400, 500, 600, 700, 800, 900, 1000 запросов. Все. Работает очень быстро, 157 запросов в секунду пролетело даже с моего относительно медленного домашнего интернета. 

Что произойдет, если я сделаю запросы к slow php, открою еще одну консоль и сделаю запрос к главной странице. Ничего не работает. Только что главная страница отвечала быстро, отвечала 157 запросов в секунду, сейчас она упала. Более того, если я сейчас, для примера, открою эту страницу в браузере, начинаю загружать, она не отвечает. 

Возвращаемся обратно в терминал, он с трудом сделал 200 запросов, мы его выключаем. Самое главное, если вы думаете, что сайт вот так просто заработает, нет он не заработает. Он все еще висит. Оживать самостоятельно сайт еще может довольно долго, поэтому я все перезапускаю и, он снова работает. Здесь риск получить огромное количество конкурентов от наших пользователей, поэтому эту демку мы не будем делать на сайтах пользователей.

Как защитить сайт? 

Ответ один: заплатите разработчику чеканной монетой, поправьте проблемы в коде, чтобы отвечали быстро. Фактически в сервере происходит то, что на каждый ваш запрос php стартует процесс, и количество этих параллельных процессов у него ограничено. 

В данном случае у меня на сервере было 128 параллельных процессов. Когда я запустил 200 и они не выполнились быстро, а зависли на 5 секунд, то все новые запросы некому было обрабатывать. Поэтому мы здесь можем увеличить сильно, очень сильно мощность сервера либо сделать запросы быстрее. То есть, если бы запросы выполнялись за миллисекунды, то никакой проблемы бы не было. С главной страницы видно, что это обычный виртуальный сервер за 200 рублей и, он запросто обрабатывает 157 запросов в секунду, вообще не напрягаясь.

Можно еще добавить кэширование. Можно добавить кэширование на уровне веб-сервера или даже на уровне CDN, но с динамическими сайтами это работает откровенно плохо. Динамические сайты ставят cookies, ставят user specific информацию и кэширование не работает, потому что по факту для каждого пользователя генерируется какая-то отдельная страница. Если вы не можете взять Wget, загрузить свой сайт и положить его в виде html-файлов, что, кстати, хорошая идея, то кэширование для вас вряд ли будет работать.

Третий пункт — это подключение CDN/прокси, так называемый реверс прокси. Зачастую, это защита не от DoS, потому что сайт все равно можно положить 200 параллельных запросов, а защита от DDoS, когда на сайт сыпется действительно неконтролируемый, неспецифичный для него трафик. Это очень легко сделать. Есть провайдеры, наподобие Cloudflare, на dns сервера, которых вы можете делегировать свой домен, а они уже будут защищать от серьезных проблем. На самом деле, они и от многих других проблем защитят, потому что там пользователям иногда даже капча покажется. 

Специальная EGS капча, которая проверит, действительно ли это легальный пользователь и, только после этого средиректит его на ваш сайт. Но это палка о двух концах. Во-первых, если Cloudflare ляжет, а он уже ложился пару раз на моей памяти, то у вас сайт не будет работать. Во-вторых, он Cloudflare может отсечь ту часть трафика, которая абсолютно легальна и, которая вам и нужна, тем самым уменьшить ваши доходы, выручку и прочее. Поэтому здесь надо балансировать.

Открытые системы управления

Совет 7. Не используйте открытые системы управления.

Кратенько пройдемся. Я, правда, удивлен, что 2021 году это еще встречается. Если у вас для управления базой данных стоит где-нибудь PhpMyAdmin, просто удалите его. Это такая дыра. Если где-то случайным образом засветиться ваш пароль от базы данных, то хакеру даже ничего придумывать не придется. Он просто зайдет в вашу админку, введет туда пароль от базы данных и все готово. Он может скачать все дампы, все замечательно.

Как это решается в сети здорового человека? Если вам нужен доступ к каким-то специфическим сервисам, вы устанавливаете VPN, подключаетесь сначала к VPN, а потом уже получаете доступ к вашим ресурсам, базам данных. Для этого вам даже не придется устанавливать PhpMyAdmin, вы просто установите любой прямой GUI-клиент на свой компьютер, подключитесь к базе данных и будете удобно всем пользоваться. Но наружу базу данных лучше не светить, не стоит светить и разные файл-менеджеры. 

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

Вывод не очень радостный.

Истина в том, что если вас не взломали, то вы, скорее всего, никому не нужны.

Потому что взламывают даже крупные корпорации, такие как Facebook, ВКонтакте. Эти компании инвестируют огромные ресурсы в безопасность. У них есть специальные программы Bounty Hunting, где они платят хакерам за то, чтобы они находили у них уязвимости. Собственно хакеры тоже не дураки, им рисковать не очень нравиться, поэтому они действительно часто присылают репорты.

Все что мы можем сделать, это минимизировать какие-то откровенно веерные атаки. Например, установленное пиратское программное обеспечение, где вы сами себе устанавливаете дыру на сайт. Это можно сделать. Можно не использовать пароли, но если вы растете и развиваетесь, вам нужно инвестировать все больше и больше ресурсов в безопасность.

У нас на сайте PR-CY есть проверка на вирусы. Поэтому если вы хотите проверить свой сайт, вы можете воспользоваться нашей аналитикой и увидеть заражены вы или нет. Чтобы это было более приятно, мы даем скидку 20% на расширенные тарифы всем участникам вебинара. Увидеть свои проблемы вы можете и на бесплатном тарифе, но если вы захотите чего-то большего, то, пожалуйста, обращайтесь.

Перед тем, как перейти к сессии вопросов и ответов, хотим вам рассказать больше о продвижении сайтов: 

• Какие есть сервисы для проверки позиций сайта в поисковых системах;
• Как проверить обратные ссылки на сайт: лучшие инструменты для анализа внешних ссылок на сайт;
• Как наращивать ссылочную массу сайта и как обраные ссылки влияют на позиции сайта в поисковых системах;
• Как сделать правильную внутреннюю перелинковку сайта. 

А теперь перейдем к ответам спикера. 
 

— Смотрите, с backup интересная ситуация. Backup, также называется backup Шредингера. Потому что он вроде бы есть, но пока его не попробуешь восстановить, ты не знаешь в каком он состоянии и, можно ли его восстановить. Поэтому в крупных компаниях с backup интересная штука. Их мало того, что делают, их еще и регулярно проверяют на то, что можно ли из них восстановиться. За свою практику не раз сталкивался с такой ситуацией. Ребята, есть backup? Да, есть, но мы его не можем восстановить. И такое происходит даже в крупных компаниях.

— Во-первых, я не юрист. Во-вторых, если бы я был юрист, то, наверное, я ввел бы уголовное наказание за использование FTP в 2021 году. Правда, есть масса вариантов, таких как SRTP, что угодно только не FTP. FTP можно только, когда вам надо телнетом подключиться к сайту и прямо руками вбить команду. Кроме этого, нельзя использовать. Все, что я говорил про сетевую безопасность, правда. У вас эти файлы может перехватить кто угодно, все кому не лень. Мне кажется, даже ребенок может это сделать.

— Смотрите, при использовании любого программного обеспечения есть вопросы вашего персонального доверия. То есть, как я уже говорил, 1Password не был замечен в чем-то криминальном. Насколько можно доверять? Если честно, то полностью доверять нельзя даже "железу". Уже были такие случаи, когда у вас просто в устройствах, процессорах закладывались уязвимости, которые сводили на нет всю безопасность. 

Я бы сказал так: менеджеры паролей гораздо безопаснее, чем использовать один пароль или записывать его на бумажке. Это факт. На 100% безопасных, скорее всего, нет. Здесь надо смотреть в совокупности, потому что безопасность операционной системы, безопасность процессора, сети и т.д. Но менеджер паролей все равно безопаснее, чем один пароль на всех ресурсах.

По поводу, что использовать. Я использую 1Password, можно использовать встроенный в Chrome менеджер паролей, у которого есть плюсы — он регулярно обновляется. Можно использовать LastPassword, я сам его не пробовал, но отзывы, в принципе, положительные. При желании можно заморочиться с KeePass. Он полностью open сорсный.

— Если используется SSH, шифрованный канал связи, то это безопасно даже в небезопасной сети. Если вы установили это соединение, то, скорее всего, будет все безопасно. Здесь встречается иногда такой кейс, когда подменяется сертификат. То есть атака Man in the Middle, кто-то посередине меняет сертификаты. Но SSH-клиенты это детектят. 

Если произошла подмена ключа шифрования, то у вас появиться оповещение "Ребята, у вас сменился ключ, подумайте это ожидаемо или не ожидаемо". Если это происходит непонятно почему (сервер не переустанавливался, ip-адрес не менялся), вероятнее всего, у вас пытаются перехватить трафик. В этом случае подключаться не стоит, необходимо сменить сеть, проверить свой компьютер и т.п. Но, в целом, если у вас компьютер безопасен и используется безопасное соединение, то никто ваши команды на удаленном устройстве не перехватит.

— Здесь всегда будет война "Щита и топора". Конечно, вы можете добавить на сайт капчу. Существуют эвристики, когда по поведению пользователя вы сами решаете, реальный это пользователь или нет. Сделаете ли вы это лучше, чем это делает Google, а он это делает. Они сами проверяют пользователя, бот он или не бот и, довольно неплохо проверяют. Сможете ли вы сделать это лучше их? Вот в чем вопрос. 

Да, вы можете такие запросы блокировать, пытаться как-то их списать, но смысла в этом я не вижу. На вашем месте, я бы больше привлекал живого трафика, чтобы исключить влияние этих поведенческих факторов. Мне было бы интересно написать какую-то эвристику, использовать сложные схемы fingerprint, чтобы отделять легальных пользователей от нелегальных. 

Но это интересно мне как разработчику, как конечный пользователь я бы просто купил рекламу и залил все трафиком. Это мое не очень профессиональное мнение в этом вопросе.

— Я говорил не совсем про приложение, а про саму экосистему. То есть само по себе мобильное устройство и установленном на нем Android или IOS (в 99% мы говорим именно о них). Эти операционные системы они гораздо более безопасны, потому что они не позволяют устанавливать вообще никакой непроверенный код на устройство. Android позволяет, но это надо постараться. То есть это надо самому загрузить, обойти как-то все системы защиты, 10 раз сказать "да, я дурак, я ставлю пиратский софт и, я отвечаю за свои поступки". 

Но в целом, если вы ставите из Store, это безопасно. Сами операционные системы, Google и Apple, следят за тем, чтобы у вас на устройстве не было трояна. Здесь, скорее всего, антивирусы все равно есть, но они бесполезны на мобильных устройствах. Безопаснее сама операционная система. Ноутбук на MacOS, Linux или Windows менее безопасен. Формально здесь трафик шифруется, все нормально, клиент-банк работает, но это менее безопасно.

— Есть сайты, которые собирают базы уязвимостей. Там можно ввести название любого программного обеспечения, в том числе и упомянутого OpenCart, и посмотреть по уровням какие конкретно были уязвимости. Можно даже подписаться, чтобы приходили уведомления о том, что есть такая-то проблема. 

Что из них более уязвимо или менее уязвимо не могу сказать, потому что я очень мало использовал готовых CMS, по существу я работал с самописным кодом, где ты сам отвечаешь за свои багги. Wordpress, как я уже говорил, у меня ломали. Я психанул, взял Wget и все загрузил. По опыту, все современные программные продукты последних версий более или менее защищены. Даже тот же самый Wordpress. Если вы просто скачаете ванильную версию Wordpress, то маловероятно, что вас взломают. Если вы скачаете ванильную версию OpenCart, Magnett или Tilix, вряд ли вас взломают. Если вы используете что-то старое, то это не надежно.

— Гроб, кладбище, вот что я могу сказать. Я как разработчик абсолютно не могу это поддерживать. Это просто ужас. Понимаете, даже у того хакера, который это хакнул, перед вами нет никакой моральной ответственности. Если поставить себя на его место, то меня совесть бы не грызла даже если бы я туда SHL залил. То есть человек сам скачал, грех не пользоваться.

— На самом деле, нормально к этому отношусь. Это надежный механизм, он хорошо работает. Если у вас веб-сервер, то, как дополнительное средство защиты, почему бы и нет. 

Еще лучшее средств защиты, в принципе админку не иметь в публичном интернете. То есть вы можете настроить VPN, который вам ограничит доступ. Кстати, колаборатор тоже светит наружу массу разных бета-версий и прочее. Если вы можете ограничить это на сетевом уровне, то это еще лучше. 

Если у вас весит админка, дополнительно защитить ее htt password — хорошее решение. Если вы можете ее в публичном интернете без подключения VPN вообще не светить, еще лучшее решение. В PR-CY мы, обычно, закрываем все VPN.

— Да, удобно, но опасно. Рисков это не лишает. Не 100%-ная защита. Я даже в свое время видел, как бегун напортачил с конфигурацией и высвечивал весь свой код на главной странице. Где гарантия того, что ваше ограничение ip-адресу будет всегда работать на 100%.

— Сам не пользовался, но вообще это не ваша проблема будет. В этом прелесть конструкторов сайтов. Вы его там сделали, заплатили-не заплатили в зависимости от вашего тарифа и, все проблемы, которые на вашем сайте возникнут, будут у Tilda. Там ребята знают свое дело и от такого рода атак они вас защитят. Кроме того, если я все правильно понимаю, у Tilda все практически статичное, то есть не так много динамических элементов. 

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

Все, что я говорил в самом начале о персональной безопасности, это основа. Если у вас увели пароль в вашем доступе, то вам уже ничего не поможет на сервере или сайте.

— За взломы, которые в их зоне ответственности, конечно, несет. Если наломали панель управления, например, или управление хостингом, то, конечно, это их зона ответственности. 

Если же взломали клиента, то тут ситуация обратная. Человек, который размещает сайт на хостинге, берет на себя ответственность, что его не взломают и у хостинга не будет проблем по этому поводу, например, от спама. В этом случае хостинг-провайдер просто отключает сайт. И он будет прав. Если ваш сайт заразили каким-то вирусом, он начал рассылать спам или размещать детскую порнографию, то хостинг-провайдер сразу же обрежет вам кислород. Это уже ваша ответственность перед хостинг-провайдером.

— PCI DSS — это система аудита, по-моему, для процессинга. Ее часто используют, когда процессят карты на сайтах. Я здесь небольшой эксперт. Это уже серьезные корпоративные стандарты. Я видел, как ребята носились с аудиторами из PCI DSS. Чисто субъективно, там двоякая ситуация. В одной ситуации они слишком придираются к мелочам, а слона иногда могут и не заметить. Я бы не стал полагаться только на стандарты. Как образец можно взять, а дальше уже здравый смысл. Я думаю, человек, который знает слово PCI DSS, он уже неплохо разбирается.

— Почему бы и нет. Если у вас изолированная сеть, если у вас не торчит наружу MySQL, а он доступен только с VPN, то все отлично. Я сам так делаю.

— Конкретно на 1С Битрикс, я думаю, вам нужно готовить довольно много денег на хостинг. Я уже это говорил, современное программное обеспечение в большинстве своем безопасно. Если вы берете последнюю версию, если вы сами себе в ногу не стреляете, не ставите какие-то непроверенные модули, то у вас все будет хорошо. 1С Битрикс я не касался, но когда "проходил" где-то рядом, понял, что он требует огромное количество ресурсов. И, здесь пункт по поводу DoS-атак становиться очень актуальным. То есть, если ваше программное обеспечение потребляет много ресурсов и долго отвечает на запросы, то вас очень легко положить также с ноутбука. Были случаи, когда пытались взять и скачать пару страниц сайта, сайты ложились.

— На восьмую? Если у вас настолько хорошо готов код, то я вам завидую. Пока я еще внимательно не смотрел восьмую версию. Но вам надо будет софт опять обновлять, переписывать большое количество кодовой базы. Хостинг-провайдер он такой. Скорее всего, там ванильная версия Wordpress так, что заведется с полуоборота. Все остальное нужно смотреть.