Способы защиты от веб атак

Как обезопасить свой веб-сайт?

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

Этот небольшой, но важный список конкретных действий, который следует производить каждому со своим веб-ресурсом, если репутация компании, безопасность веб-ресурсов и данных клиентов – это не пустые слова для вас.

Можно выделить несколько основных способов защитить свой сайт:

• обеспечить защиту от DDoS-атак;
• подключить SSL-сертификат;
• использовать надёжный хостинг;
• использовать безопасные плагины/библиотеки/фреймворки/CMS (далее – «сторонние модули»);
• применять существующие техники защиты от SQL-инъекций и XSS-атак;
• обеспечить ведение журнала веб-сайта и мониторинг событий безопасности;
• производить регулярное резервное копирование веб-сайта и всех важных данных;
• использовать надёжные и сложные пароли, а также защиту от перебора паролей;
• в случае наличия административной панели, с помощью которой происходит управление содержимым веб-сайта, необходимо изменить стандартный адрес входа и обеспечить контроль доступа.

Естественно, у каждого пункта есть своё «но» и ряд подпунктов, на которых следует заострить внимание. Также их можно разделить на подгруппы исходя из следующих соображений: одни действия требуют одноразового подключения, настройки и редких проверок работоспособности (настройка хостинга и SSL-сертификата), а другие подразумевают под собой постоянные проверки, обновления и требуют пристального внимание (всё остальное).

Надёжный хостинг и SSL

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

Защита от DDoS

Если ваш хостинг-провайдер предоставляет услуги защиты от DDoS-атак или вы пользуетесь услугами анти-DDoS-сервисов, то этот вопрос можно считать закрытым, но почему бы не усилить защиту и не организовать её своими руками, что несомненно является трудоёмкой задачей и подразумевает одновременное использование следующих техник: если в качестве веб-сервера используется Apache, то необходимо поставить перед ним кеширующий прокси – Nginx или Lighttpd, а лучше на фронтенде использовать Nginx, но с несколькими надстройками (ограничить размеры буферов и соединения в Nginx, настроить тайм-ауты и т.п.; использовать модуль testcookie-nginx; использовать фильтрацию по URL и отдавать нестандартный код 444, который позволяет закрыть соединение и не отдавать ничего в ответ); в некоторых случаях использовать блокировку по географическому признаку; автоматизировать процесс анализа логов веб-сайта, обращая особое внимание на объём трафика, время ответа сервера, количество ошибок и количество запросов в секунду.

Безопасность сторонних модулей

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

SQL-инъекции и XSS-атаки

Рекомендация, относящаяся к обеспечению защиты от SQL-инъекций и XSS-атак, требует самого подробного объяснения, ведь целью злоумышленников здесь являются конкретные данные из базы данных (SQL-инъекция) и пользовательские данные (XSS-атака). Стоит также понимать, что вопросы, связанные с SQL-инъекциями, затрагивают обширный раздел, посвящённый обеспечению безопасного доступа ко всем хранилищам данных, включая реляционные базы данных и базы данных NoSQL, и включают вопросы безопасности запросов (необходимо избегать нелегитимных входных данных в составе SQL-команд и наилучшим решением является использование параметризованных запросов, которые можно применять к конструкциям SQL/OQL и хранимым процедурам), конфигурации (необходимо убедиться в корректной настройке имеющихся средств обеспечения безопасности СУБД и платформы, на которой она установлена), аутентификации (должна выполняться по защищенному каналу) и соединений (в связи с существованием нескольких способов взаимодействия с базой данных (посредством службы или API), необходимо обеспечить безопасность соединений с помощью шифрования и аутентификации).

Что касается межсайтового выполнения сценариев (XSS-атака), то в данном случае последствия средней степени тяжести могут нанести отражённая XSS или XSS на основе объектной модели документа (DOM), а к серьезным последствиям может привести межсайтовое выполнение хранимых сценариев с исполнением кода в браузере пользователя с целью кражи учётных данных, перехвата сессий или установки вредоносного программного обеспечения. Главной мерой защиты в данном случае является экранирование (добавление определённых комбинаций символов перед символами или строками для недопущения их некорректной интерпретации), кодирование данных (преобразование определённых символов в комбинации символов, которые не представляют опасности для интерпретатора) на стороне сервера и использование набора HTTP-заголовков, в частности, Set-Cookie с параметрами HttpOnly и Secure, а также X-XSS-Protection со значением 1.

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

Журналирование и мониторинг

Рекомендация, относящаяся к журналированию всех событий и мониторингу событий безопасности, уже упоминалась при рассмотрении методов защиты от DDoS-атак, но в данном случае рассматривается более широкая сторона вопроса, связанная с обнаружением атак и противодействием им, а также расследованием уже случившихся инцидентов безопасности. Таким образом, кроме стандартных средств журналирования, предоставляемых веб-сервером, необходимо убедиться в регистрации времени события и идентификатора пользователя, а также потенциально опасной активности, характерной для вашего веб-сайта. В случае обнаружения вредоносной активности ваше приложение должно заблокировать пользовательскую сессию или заблокировать по IP-адресу, в общем принять меры и сообщить об этом администратору. Тут уже речь идет о таких средствах, как WAF или IDS/IPS.

Бэкапы

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

12345 или qwerty?

Рекомендация по использованию надежных и сложных паролей не только и не столько про пароли, а в целом про аутентификацию и управление сессиями пользователей. Существует три уровня аутентификации и использование только паролей относится лишь к первому – самому простому уровню (второй – многофакторная аутентификация; третий – аутентификация на основе шифрования). Однако даже здесь есть ряд требований к самим паролям, механизму восстановления пароля, а также к безопасному хранению паролей. Управление сессиями позволяет контролировать состояние аутентификации пользователя для работы с веб-сайтом без повторной аутентификации. К сессиям также предъявляются требования к созданию и завершению.

Защита административной панели

Заключительной рекомендацией является защита административной панели веб-сайта, ведь она является одним из слабых мест в общей системе из-за обширного функционала, связанного с добавлением/редактированием постов и страниц, работой с файлами и многим другим. Поэтому важным условием является обеспечить надлежащий контроль доступа, а также максимальную скрытность от злоумышленников местонахождения административной панели, реализуемую простым переносом адреса на нестандартный и максимальной защитой данной точки входа посредством защиты от перебора, фильтрации по IP-адресам и т.д. При создании системы контроля доступа следует придерживаться следующих принципов: отправка всех запросов через систему контроля доступа; запрет доступа по умолчанию (т.е. отклонять запрос, если он не был разрешен специально); минимальные привилегии для всех пользователей, программ или процессов; отказ от использования ролевой модели управления доступом, жёстко заданной в коде; регистрация всех событий, связанных с контролем доступа.

Вывод

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

На правах рекламы

VDSina предлагает надёжные серверы с посуточной или единоразовой оплатой, каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от 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()>
для блокирования атаки, т.к. он явно не является легитимным в контексте пользовательских действий.

«Классические» атаки

Статистика показывает, что многие веб-приложения компрометируются также, как и годами ранее — это разного рода инъекции, инклуды, клиент-сайд атаки, поэтому защитное средство должно уметь выявлять и блокировать атаки, направленные на эксплуатацию следующих уязвимостей:

• SQL Injection — sql инъекции;
• Remote Code Execution (RCE) — удаленное выполнение кода;
• Cross Site Scripting (XSS) — межсайтовый скриптинг;
• Cross Site Request Forgery (CSRF) — межстайтовая подделка запросов;
• Remote File Inclusion (RFI) — удалённый инклуд;
• Local File Inclusion (LFI) — локальный инклуд;
• Auth Bypass — обход авторизации;
• Insecure Direct Object Reference — небезопасные прямые ссылки на объекты;
• Bruteforce — подбор паролей.

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

Защита на прикладном уровне

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

Протокол прикладного уровня — протокол верхнего (7-го) уровня сетевой модели OSI, обеспечивает взаимодействие сети и пользователя. Уровень разрешает приложениям пользователя иметь доступ к сетевым службам, таким, как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты. Защита на прикладном уровне является наиболее надежной. Уязвимости, эксплуатируемые злоумышленниками, зачастую полагаются на сложные сценарии ввода данных пользователем, что делает их трудноопределимыми с помощью классических систем обнаружения вторжений. Также этот уровень является самым доступным извне. Возникает необходимость понимать группы протоколов и зависимостей, свойственных для веб-приложений, которые строятся над прикладными протоколами http/https.

Основной принцип защиты сайта на прикладном уровне — верификация и фильтрация данных запросов, передаваемых методами GET, POST и т.д. Подмена или модификация запроса — это базовая основа практически всех способов взлома и атак на сайты.

Цели атак

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

• Каждый третий сайт был взломан или подвергался атакам хакеров;
• 80% сайтов взламываются в ходе нецелевых атак с использованием популярных сканеров или утилит;
• Около 60% взломанных сайтов были заражены и заблокированы поисковыми системами.

Для сайтов, оперирующих платежными данными, обрабатывающих онлайн-транзакции существует специализированные требования соответствия стандарту PCI DSS. Payment Card Industry Data Security Standard (PCI DSS) — стандарт безопасности данных индустрии платёжных карт, разработанный Советом по стандартам безопасности индустрии платежных карт (Payment Card Industry Security Standards Council, PCI SSC), учреждённым международными платёжными системами Visa, MasterCard, American Express, JCB и Discover.

Пункт 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 складывается из нескольких факторов:

• Простая интеграция в инфраструктуру;
• Гибкая система адаптации с веб-приложением;
• Блокирование угроз OWASP Top 10;
• Анализ и блокирование аномалий протокола или данных;
• Обнаружение и блокирование подделки идентификаторов сессий;
• Обнаружение и блокирование подбора паролей;
• Инспекция ответов сервера на наличие критичных данных;
• Динамическое обновление сигнатур атак;
• Низкое количество ложных срабатываний;
• Самозащита WAF;
• Удобный сервис информирования об атаках;
• Статистика и регламентная отчетность.

Одним из источников, позволяющих выявлять новые сценарии и реализацию атак на веб-приложения, являются «Лаборатории тестирования на проникновение», имитирующие реальную инфраструктуру современных компаний. В лабораториях принимают участие около 9000 специалистов по информационной безопасности со всего мира, с разным уровнем подготовки, навыков и инструментария. Анализ атак, направленных на объекты лаборатории, позволяют составить модели нарушителя и реализации векторов атаки.

Эти данные тщательно анализируются и на их основе добавляются новые правила фильтрации.

Источник