веб атака что это
👨⚕️️ Атаки веб-приложений: что это такое и как оставаться защищенным👨⚕️
Поскольку популярность веб-приложений продолжает расти, злоумышленники продолжают использовать различные векторы и методы атаки для таргетинга на веб-сайты и веб-приложения.
Атаки веб-приложений могут негативно повлиять на организации и могут стоить их времени, денег и репутации.
Распространенные атаки веб-приложений
Межсайтовый скриптинг (XSS)
Атака межсайтового скриптинга (XSS) – одна из широко используемых атак веб-приложений.
Атаки XSS происходят, когда злоумышленники внедряют свой вредоносный код в веб-приложение или выполняют вредоносные скрипты в браузере другого пользователя.
Атаки XSS также могут изменить веб-страницу приложения веб-сайта, чтобы перенаправить авторизованных пользователей на мошеннические сайты.
SQL-инъекция
При атаке с использованием SQL-инъекции злоумышленник вставляет вредоносный оператор SQL в запрос базы данных веб-приложения.
Успешное внедрение SQL-кода может позволить злоумышленнику получить несанкционированный доступ к скомпрометированной базе данных, содержащей конфиденциальные данные, и обойти механизмы безопасности приложения.
Злоумышленники также могут добавлять, изменять и удалять записи в скомпрометированной базе данных.
Обход пути
При атаке путем обхода злоумышленники пытаются получить доступ к неавторизованным файлам или каталогам, расположенным вне корневой веб-папки, путем введения таких шаблонов, как «../».
Успешный обход пути может позволить злоумышленнику неправомерно получить доступ к учетным данным сайта или пользователя, файлам конфигурации, базам данных или другим сайтам, расположенным на одной и той же физической машине.
Локальное включение файлов
При атаке с включением локального файла злоумышленник использует обход каталога или аналогичный метод, чтобы запустить веб-приложение на выполнение файла, находящегося на сервере.
Распределенный отказ в обслуживании (DDoS)
При атаке с распределенным отказом в обслуживании (DDoS) несколько скомпрометированных систем используются для нацеливания на сервер с огромным объемом трафика.
DDoS-атака направлена на то, чтобы серверы упали, бомбардируя их таким большим трафиком, что их сервисы и инфраструктура не могут с этим справиться.
Защита сайта от хакерских атак
Современные реалии показывают постоянно растущие атаки на веб-приложения — до 80% случаев компрометации систем начинаются с веб-приложения. В статье будут рассмотрены наиболее распространенные уязвимости, которые активно используют злоумышленники, а также эффективные методы противодействия им.
При увеличении количества инструментов и техник атак все сложнее становится обеспечить доступность сайта, защитить веб-приложение или его компоненты от взлома и подмены контента. Несмотря на усилия технических специалистов и разработчиков обороняющаяся сторона традиционно занимает догоняющую позицию, реализовывая защитные меры уже после того, как веб-приложение было скомпрометировано. Веб-сайты подвергаются атакам из-за публичной доступности, не всегда качественно написанному коду, наличию ошибок в настройке серверной части, а также отсутствующему контролю со стороны службы ИБ, тем самым обеспечивая злоумышленникам доступ к критичным данным.
В связи с этим возникает необходимость использовать защитные средства, учитывающие архитектуру веб-приложения, и не приводящие к задержкам в работе сайта.
Уязвимости нулевого дня
Уязвимость нулевого дня или 0-day – это ранее неизвестная уязвимость, которая эксплуатируется злоумышленниками. Происхождение термина связано с тем обстоятельством, что уязвимость или атака становится публично известна до момента выпуска производителем ПО исправлений ошибки (то есть потенциально уязвимость может эксплуатироваться на работающих копиях приложения без возможности защититься от нее).
Природа уязвимостей нулевого дня позволяет злоумышленникам успешно атаковать веб-приложения в период от нескольких минут до нескольких месяцев. Такой большой период обусловлен множеством факторов:
В качестве примера можно привести хронологию атаки Struts2: CVE-2013-2251 Struts2 Prefixed Parameters OGNL Injection Vulnerability — c момента появления «боевого» эксплойта прошло несколько дней, прежде чем многие компании смогли накатить патч.
Тем не менее, при использовании защитных средств можно было выявить запрос вида:
http://host/struts2-blank/example/X.action?action:%25<(new+java.lang.ProcessBuilder(new+java.lang.String[]<'command','goes','here'>)).start()>
для блокирования атаки, т.к. он явно не является легитимным в контексте пользовательских действий.
«Классические» атаки
Статистика показывает, что многие веб-приложения компрометируются также, как и годами ранее — это разного рода инъекции, инклуды, клиент-сайд атаки, поэтому защитное средство должно уметь выявлять и блокировать атаки, направленные на эксплуатацию следующих уязвимостей:
Защита на прикладном уровне
Веб-приложения отличаются от обычных приложений двумя вещами: огромным разнообразием и значительной интерактивностью. Это создаёт целый ряд новых угроз, с которыми традиционные межсетевые экраны не справляются.
Протокол прикладного уровня — протокол верхнего (7-го) уровня сетевой модели OSI, обеспечивает взаимодействие сети и пользователя. Уровень разрешает приложениям пользователя иметь доступ к сетевым службам, таким, как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты. Защита на прикладном уровне является наиболее надежной. Уязвимости, эксплуатируемые злоумышленниками, зачастую полагаются на сложные сценарии ввода данных пользователем, что делает их трудноопределимыми с помощью классических систем обнаружения вторжений. Также этот уровень является самым доступным извне. Возникает необходимость понимать группы протоколов и зависимостей, свойственных для веб-приложений, которые строятся над прикладными протоколами http/https.
Основной принцип защиты сайта на прикладном уровне — верификация и фильтрация данных запросов, передаваемых методами GET, POST и т.д. Подмена или модификация запроса — это базовая основа практически всех способов взлома и атак на сайты.
Цели атак
Веб-приложения могут быть атакованы независимо от их принадлежности к той или иной области деятельности: сайты малой посещаемости, неоперирующие большими объемами информации и не хранящие критичных данных могут быть атакованы в результате нецелевых атак. Значимые сайты, имеющие высокие показатели трафика, огромные объемы пользовательских данных и т.д. являются привлекательной мишенью для злоумышленников и подвергаются атакам практически ежедневно:
Пункт 6.6 гласит, что помимо проведения аудита веб-приложения необходимо обеспечить применение специализированных защитных средств:
To gain a better understanding of the Requirement 6.6, we should refer to PCI DSS 3.1 standard which says that public-facing web applications shall “address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.”
What is important here is the “on an ongoing basis” condition, which makes it very clear that web security is a permanent process and highlights the importance of continuous web security.
PCI DSS proposes two ways to achieve this requirement:
“Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.”
“Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.”
Пункт 6.6 носит обязательный характер, если веб-приложение входит в CDE (Cardholder Data Environment).
Обеспечение защиты сайта
Оптимальным решением для обеспечения защиты сайта является применение Web Application Firewall — межсетевого экрана прикладного уровня, позволяющего эффективно защищать сайты от атак злоумышленников.
Web Application Firewall — это специальный механизм, накладывающий определенный набор правил на то, как между собой взаимодействуют сервер и клиент, обрабатывая HTTP-пакеты. В основе кроется тот же принцип, что и в обычных пользовательских фаерволах, — контроль всех данных, которые поступают извне. WAF опирается на набор правил, с помощью которого выявляется факт атаки по сигнатурам – признакам активности пользователя, которые могут означать нападение.
Как это работает
Web Application Firewall работает в режиме прозрачного проксирующего механизма, анализирую на лету приходящие от клиента данные и отбрасывая нелегитимные запросы:
После установки Web Application Firewall необходима настройка под целевое веб-приложение — в зависимости от типа и вида CMS добавляются учитывающие веб-приложение настройки фильтрации и правила и защитное средство переводится в режим обучения, для сбора эталонных моделей коммуникации с веб-приложением, идентификаторов и т.д.
Эффективность применения Web Application Firewall складывается из нескольких факторов:
Одним из источников, позволяющих выявлять новые сценарии и реализацию атак на веб-приложения, являются «Лаборатории тестирования на проникновение», имитирующие реальную инфраструктуру современных компаний. В лабораториях принимают участие около 9000 специалистов по информационной безопасности со всего мира, с разным уровнем подготовки, навыков и инструментария. Анализ атак, направленных на объекты лаборатории, позволяют составить модели нарушителя и реализации векторов атаки.
Эти данные тщательно анализируются и на их основе добавляются новые правила фильтрации.
Безопасность веб-приложений: от уязвимостей до мониторинга
Уязвимости веб-приложений возникают тогда, когда разработчики добавляют небезопасный код в веб-приложение. Это может происходить как на этапе разработки, так и на этапе доработки или исправления найденных ранее уязвимостей. Недостатки часто классифицируются по степени критичности и их распространенности. Объективной и наиболее популярной классификацией уязвимостей считается OWASP Top 10. Рейтинг составляется специалистами OWASP Project и актуализируется каждые 3-4 года. Текущий релиз выпущен в 2017 году, а следующий ожидается в 2020-2021.
Распространенные уязвимости
Для начала рассмотрим типовые уязвимости, которым подвержены многие веб-приложения.
Инъекции
Как и полагается, атаки класса «Инъекции» занимают лидирующую строчку рейтинга OWASP Top 10, встречаясь практически повсеместно и являясь крайне разнообразными в реализации. Уязвимости подобного класса начинаются SQL-инъекциями, в различных его вариациях, и заканчивая RCE — удаленным выполнением кода.
Межсайтовый скриптинг — уязвимость, встречающаяся на данный момент куда реже, чем раньше, если верить рейтингу OWASP Top 10, но несмотря на это не стала менее опасной для веб-приложений и пользователей. Особенно для пользователей, ведь атака XSS нацелена именно на них. В общем случае злоумышленник внедряет скрипт в веб-приложение, который срабатывает для каждого пользователя, посетившего вредоносную страницу.
LFI/RFI
Уязвимости данного класса позволяют злоумышленникам через браузер включать локальные и удаленные файлы на сервере в ответ от веб-приложения. Эта брешь присутствует там, где отсутствует корректная обработка входных данных, которой может манипулировать злоумышленник, инжектировать символы типа path traversal и включать другие файлы с веб-сервера.
Атаки через JSON и XML
Веб-приложения и API, обрабатывающие запросы в формате JSON или XML, также подвержены атакам, поскольку такие форматы имеют свои недостатки.
JSON (JavaScript Object Notation) — это облегченный формат обмена данными, используемый для связи между приложениями. Он похож на XML, но проще и лучше подходит для обработки с помощью JavaScript. Многие веб-приложения используют этот формат для обмена данными между собой и сериализации/десериализации данных. Некоторые веб-приложения также используют JSON для хранения важной информации, например, данных пользователя. Обычно используется в RESTful API и приложениях AJAX.
JSON чаще всего ассоциируется с API, тем не менее, часто используется даже в обычных и хорошо известных веб-приложениях. Например, редактирование материалов в WordPress производится именно через отправку запросов в формате JSON:
JSON Injection
Простая инъекция JSON на стороне сервера может быть выполнена в PHP следующим образом:
Простая инъекция JSON на стороне клиента может быть выполнена следующим образом:
JSON Hijacking
Захват JSON — атака, в некотором смысле похожая на подделку межсайтовых запросов (CSRF), при которой злоумышленник старается перехватить данные JSON, отправленные веб-приложению с веб-сервера:
XML External Entity
Атака внешней сущности XML (XXE) — это тип атаки, в котором используется широко доступная, но редко используемая функция синтаксических анализаторов XML. Используя XXE, злоумышленник может вызвать отказ в обслуживании (DoS), а также получить доступ к локальному и удаленному контенту и службам. XXE может использоваться для выполнения подделки запросов на стороне сервера (SSRF), заставляя веб-приложение выполнять запросы к другим приложениям. В некоторых случаях c помощью XXE может даже выполнить сканирование портов и удаленное выполнение кода.
XML (Extensible Markup Language) — очень популярный формат данных. Он используется во всем: от веб-сервисов (XML-RPC, SOAP, REST) до документов (XML, HTML, DOCX) и файлов изображений (данные SVG, EXIF). Для интерпретации данных XML приложению требуется анализатор XML, известный как XML-процессор. XML можно использовать не только для объявления элементов, атрибутов и текста. XML-документы могут быть определенного типа. Тип указывается в самом документе, объявляя определение типа. Анализатор XML проверяет, соответствует ли XML-документ указанному типу, прежде чем обрабатывать документ. Вы можете использовать два варианта определений типов: определение схемы XML (XSD) или определение типа документа (DTD). Уязвимости XXE встречаются в последнем варианте. Хотя DTD можно считать устаревшими, но он все еще широко используются.
Фактически, объекты XML могут поступать практически откуда угодно, включая внешние источники (отсюда и название XML External Entity). При этом, XXE может стать разновидностью атаки подделки запросов на стороне сервера (SSRF). Злоумышленник может создать запрос, используя URI (известный в XML как системный идентификатор). Если синтаксический анализатор XML настроен для обработки внешних сущностей, а по умолчанию многие популярные анализаторы XML на это настроены, веб-сервер вернет содержимое файла в системе, потенциально содержащего конфиденциальные данные.
Злоумышленник, разумеется, не ограничивается системными файлами. Можно легко заполучить и другие локальные файлы, включая исходный код, если известно расположение файлов на сервере или структура веб-приложения. Атаки на внешние объекты XML могут позволить злоумышленнику выполнять HTTP-запросы к файлам в локальной сети т.е. доступным только из-за брандмауэра.
💉 9 популярных типов атак на веб-приложения
Атаки брутфорса больше не являются угрозой благодаря политике паролей, ограниченным попыткам входа в систему и капчам.
Но киберпреступники любят открывать новые технологии и использовать их для выполнения новых типов атак.
Давным-давно они обнаружили, что текстовые поля в приложениях или на веб-страницах можно использовать, вводя в них какой-либо текст, который заставит приложение делать то, что оно не должно было делать.
Таким образом, на сцену вышли так называемые инъекционные атаки.
Атаки с помощью инъекций могут использоваться не только для входа в приложение без знания имени пользователя и пароля, но также для раскрытия частной, конфиденциальной или даже для захвата всего сервера.
Вот почему эти атаки представляют угрозу не только для веб-приложений, но и для пользователей, чьи данные находятся в этих приложениях, а в худшем случае – для других подключенных приложений и служб.
Инъекция кода
Внедрение кода является одним из наиболее распространенных типов атак.
Если злоумышленники знают язык программирования, структуру, базу данных или операционную систему, используемую веб-приложением, они могут ввести код через поля ввода текста, чтобы заставить веб-сервер делать то, что они скажут.
Эти типы инъекционных атак возможны в приложениях, в которых отсутствует проверка входных данных.
Если текстовое поле ввода позволяет пользователям вводить все, что они захотят, то приложение потенциально может быть скомпрометировано.
Чтобы предотвратить атаки такого рода, приложение должно ограничивать входные данные от пользователей.
Например, необходимо ограничить объем ожидаемых данных, проверять формат данных и ограничить набор разрешенных символов.
Уязвимости внедрения кода легко найти, просто протестировав ввод текста в веб-приложения с различным типом контента.
Обнаруженные уязвимости трудно использовать.
Но если злоумышленнику удастся использовать одну из этих уязвимостей, это может привести к потере конфиденциальности, целостности, доступности или функциональности приложения.
SQL-инъекция
Инъекция команд
Внедренные системные команды выполняются операционной системой хоста с привилегиями приложения, которые могут предоставлять доступ к содержимому произвольных файлов, находящихся на сервере, для отображения структуры каталогов сервера, для изменения паролей пользователей и т.д.
Эти атаки могут быть предотвращены системным администратором путем ограничения уровня доступа к системе веб-приложений, работающих на сервере.
Межсайтовый скриптинг
Всякий раз, когда приложение позволяет осуществлять ввод пользователю в вывод, который оно генерирует, не проверяя и не кодируя его, оно дает злоумышленнику возможность отправлять вредоносный код другому конечному пользователю.
Атаки с использованием межсайтовых сценариев (XSS) используют эти возможности для внедрения вредоносных сценариев в надежные веб-сайты, которые в конечном итоге отправляются другим пользователям приложения, которые становятся жертвами злоумышленника.
Браузер жертвы выполняет вредоносный скрипт, не подозревая, что ему нельзя доверять.
Поэтому браузер разрешает ему получать доступ к токенам сеансов, файлам cookie или конфиденциальной информации, хранящейся в браузере.
При правильном программировании сценарии могут даже переписать содержимое файла HTML.
Атаки XSS обычно можно разделить на две категории: хранимые и отраженные.
В хранимых XSS-атаках вредоносный скрипт постоянно находится на целевом сервере, в пуле сообщений, в базе данных, в журнале посещений и т. д.
Жертва получает его, когда браузер запрашивает сохраненную информацию.
В отраженных атаках XSS вредоносный сценарий отражается в ответе, который включает входные данные, отправленные на сервер.
Это может быть, например, сообщение об ошибке или результат поиска.
XPath инъекция
Этот тип атаки возможен в том случае, когда веб-приложение использует информацию, предоставленную пользователем, для создания запроса XPath для данных XML.
Эта атака работает аналогично SQL-инъекции: злоумышленники отправляют искаженную информацию в приложение, чтобы узнать, как структурированы данные XML, а затем снова атакуют, чтобы получить доступ к этим данным.
XPath – это стандартный язык, с помощью которого, подобно SQL, вы можете указать атрибуты, которые хотите найти.
Чтобы выполнить запрос к данным XML, веб-приложения используют пользовательский ввод для установки шаблона, которому должны соответствовать данные.
Посылая некорректный ввод, шаблон может превратиться в операцию, которую злоумышленник сможет применить по отношению к данным.
Внедрение команд почты
Чтобы использовать SMTP-сервер, злоумышленникам нужна действующая учетная запись электронной почты для отправки сообщений с введенными командами.
Если сервер уязвим, он будет отвечать на запросы злоумышленников, позволяя им, например, переопределять ограничения сервера и использовать свои службы для рассылки спама.
CRLF инъекция
Вставка символов и перевода строки – комбинации, известной как CRLF, – в поля ввода веб-формы представляет собой метод атаки, называемый инъекцией CRLF.
Эти невидимые символы указывают на конец строки или конец команды во многих традиционных интернет-протоколах, таких как HTTP, MIME или NNTP.
Например, вставка CRLF в HTTP-запрос с последующим определенным HTML-кодом может отправлять пользовательские веб-страницы посетителям веб-сайта.
Эта атака может быть выполнена на уязвимых веб-приложениях, которые не применяют надлежащую фильтрацию к пользовательскому вводу.
Эта уязвимость открывает двери для других типов атак с использованием инъекций, таких как XSS и внедрение кода.
Внедрение заголовков хоста
На серверах, на которых размещено множество веб-сайтов или веб-приложений, заголовок узла становится необходимым для определения того, какой из резидентных веб-сайтов или веб-приложений, каждое из которых известно как виртуальный хост, должен обрабатывать входящий запрос.
Значение заголовка сообщает серверу, на какой виртуальный хост отправлять запрос.
Когда сервер получает неверный заголовок узла, он обычно передает его первому в списке виртуальному узлу.
Это представляет собой уязвимость, которую злоумышленники могут использовать для отправки произвольных заголовков узлов первому виртуальному узлу на сервере.
Инъекция LDAP
LDAP – это протокол, разработанный для облегчения поиска ресурсов (устройств, файлов, пользователей) в сети.
Он очень полезен для интрасетей, и когда он используется как часть системы единого входа, он может использоваться для хранения имен пользователей и паролей.
Запросы LDAP включают использование специальных управляющих символов, которые влияют на его управление
Злоумышленники могут потенциально изменить предполагаемое поведение запроса LDAP, если они могут вставить в него управляющие символы.
Атаки на сайты
Атаки на сайты — совершение противоправных действий, направленных на получение конкурентных преимуществ путем взлома, заражения вредоносным кодом, блокирования доступа (с дальнейшем требованием выкупа), кражи конфиденциальных данных, вывода из строя программного обеспечения, в отношении сетевых ресурсов (веб-сайтов).
Веб-сайт — это информационный актив и вид собственности. Он может подвергаться атакам злоумышленников с самыми разными целями. Сайт всегда на виду, всегда должен быть доступен, и это делает его крайне уязвимым.
Способы атак на сайты
На первом этапе киберпреступник изучает ресурс на предмет уязвимостей. Они, в свою очередь, бывают нескольких типов.
Уязвимости кода сайта появляются ввиду ошибок или недостаточной проработки вопросов безопасности со стороны программистов, создающих ядро и расширения сайта. При наличии подобных изъянов злоумышленник может внедрить свой код в исполняемые сценарии, запросы к базе данных (SQL-инъекции) или почтовому серверу сайта (email-инъекции), либо в страницу, которую пользователь открывает в своем браузере, с целью кражи его личных данных, включая пароли (межсайтовый скриптинг).
Ошибки в настройке прав пользователей проявляются по-разному.Распространенной ошибкой можно назвать слабые пароли. Они по-прежнему встречаются сплошь и рядом, хотя о правилах составления надежных паролей написаны тысячи статей. Злоумышленнику достаточно подобрать брутфорсом хотя бы одно из кодовых слов.
Бекдоры в сторонних модулях и расширениях также позволяют проводить атаки на сайты. Очень редко весь код сайта пишется с нуля, гораздо чаще используются одна из существующих CMS (систем управления контентом), а также различные модули и расширения, добавляющие нужную функциональность. Часть из них распространяется бесплатно, за другие просят деньги. Взломав такое платное расширение, злоумышленник добавляет в него шелл-код, открывающий доступ к сайту или веб-серверу, и предлагает для скачивания уже бесплатно.
Наконец, уязвимым может быть и хостинг-провайдер. Часто десятки и сотни сайтов размещаются на одном сервере, и если он настроен неправильно, то киберпреступник сможет получить доступ ко всем этим многочисленным ресурсам.
Наличие любого типа уязвимости веб-сайта приводит к атакам, целью которых в большинстве случаев становится полный несанкционированный доступ к содержимому сайта. Получение доступа зависит от характера уязвимости — например, при SQL-инъекции путем различных запросов к базе данных извлекают логины и пароли всех пользователей, включая администратора.
Имея же права администратора, с зараженным сайтом можно делать что угодно. Иногда злоумышленники не вмешиваются в нормальную работу, ограничиваясь кражей клиентской базы и данных пользователей, а в других случаях они уничтожают или подменяют содержимое либо дополняют функциональность согласно собственным нуждам — размещают рекламные баннеры, ссылки на распространяющие запрещенную информацию ресурсы или фишинговые сайты, сценарии для межсайтовой подделки запроса, когда от лица пользователя, зашедшего на страницу и имеющего аккаунт на другом ресурсе (к примеру, в электронной платежной системе), делается запрос на перевод денег преступнику.
Отчасти особняком стоят получившие широкую известность и распространенность DDoS-атаки. Их цель — не внедриться в систему, подменить контент или украсть чужие данные, а сделать сайт недоступным на некоторое время. После этого владельцев сайта, как правило, шантажируют, вымогая у них деньги за остановку атаки. Осуществляется DDoS-атака одновременной посылкой запросов с множества компьютеров ботнета. Перегружая сервер потоком бессмысленных сообщений, атакующий делает его недоступным для обычных посетителей.
Какие сайты атакуют?
Интернет-сайты на популярных CMS взламывают массово с целью заражения через типовые уязвимости.
Что же касается DDoS-атак, то их делают по заказу, и здесь есть конкретные группы риска. Например, очень часто атакуют бизнес, который зависит от интернета, так что любой инцидент простоя приводит к убыткам. Злоумышленники начинают атаку и предлагают владельцу откупиться.
По статистике, чаще всего подвергаются нападениям:
Веб-страницы банков и электронных платежных систем взламывают с целью кражи денег; сайты коммерческих компаний атакуют ради клиентской базы и создания проблем конкуренту, либо ради шантажа, требуя деньги за возобновление нормальной работы; сайты правительственных органов и общественных организаций атакуются идеологическими противниками.
Анализ угроз для сайтов
Основным источником угрозы для сайта является его собственный код, написанный небрежно, с ошибками, без учета строгих правил безопасности, вкупе с использованием устаревших либо скачанных с пиратских сайтов модулей, расширений и плагинов.
Другая серьезная проблема — неправильное администрирование. Предоставляя пользователям излишне широкие права, позволяя им загружать на сайт файлы без должной проверки, администратор фактически открывает ворота для всевозможных троянов, бэкдоров и прочих экземпляров вредоносного кода.
Третий источник опасности — плохие пароли.
Наконец, еще одна, не связанная напрямую с созданием и работой сайта угроза — содержимое как таковое. Например, движущей силой многих DDoS-атак является месть. От таких нападений не спасает самый идеальный код и надежное администрирование — атака целиком и полностью идет извне.
Сделать сайт стопроцентно устойчивым к любым атакам нереально. Можно лишь усложнить преступникам достижение их целей. В конце концов, атака на сайт требует времени и денег, и если предполагаемая выгода или ущерб противника окажется меньше затрат на попытку взлома, то злоумышленник переключится на более привлекательную цель.
Как не допустить атаку на сайт?
Следует использовать при создании сайта лишь надежные, проверенные ядра, а если заказывается свой «движок», то нужно поручать его написание команде опытных профессионалов. При использовании готовых систем управления контентом необходимо регулярно их обновлять — большинство обновлений предназначено как раз для устранения очередной выявленной уязвимости. Нельзя использовать старые и уж тем более необновляемые CMS — изъяны в их безопасности никем не закрываются и хорошо известны хакерам, которые не замедлят ими воспользоваться.
То же самое касается любых приложений и расширений. Бесплатные — скачивать только с официальных сайтов разработчиков и своевременно обновлять, платные — либо честно покупать, либо отказаться от их использования. За условно-бесплатное скачивание с пиратского сайта в конечном счете придется заплатить намного больше, когда понадобится восстанавливать как содержимое, так и репутацию в глазах поисковых систем, которые игнорируют сайты, содержащие нерелевантные ссылки и распространяющие зараженные файлы.
Необходимо четко разграничить права разных категорий пользователей. Никто не должен иметь больше возможностей, чем необходимо.
Пароли для администраторов и привилегированных групп пользователей должны быть сложными.
Желательно использовать различные программы и утилиты, повышающие безопасность. Неплохо также проверить сайт специальными программами поиска уязвимостей, либо, если надежность важна и финансы позволяют, поручить задачу профессионалам.
Защита от DDoS-атак (по крайней мере, низкой и средней мощности) осуществляется размещением сайта на серверах с высокой пропускной способностью. Также используются анализ и фильтрование трафика с блокировкой IP-адресов атакующих машин. В случае же мощных атак зачастую остается лишь переждать, пока они прекратятся. Заказчики DDoS-атак редко располагают собственными ресурсами для их проведения и вынуждены платить хакерам — владельцам ботнетов (сетей зараженных компьютеров, с которых и ведется атака). Соответственно, мощная атака стоит немалых денег и редко длится дольше нескольких дней. Другим вариантом является приобретение специальных средств для защиты от отказа в обслуживании. Чтобы снизить вероятность DDoS-атак, не стоит размещать контент, оскорбительный для больших групп людей или влиятельных структур, способных отомстить.
Наконец, полезно регулярно выполнять резервное копирование сайта, чтобы в случае серьезных проблем быстро его восстановить.