Слияние кода завершено, страница обновится автоматически
OpenStar (WAF+)
Добро пожаловать в {OpenStar} (WAF+)! Этот проект был создан на основе реальных потребностей и прошёл через несколько версий. Это было непросто, но результат того стоил. Спасибо Сяо Гэ и его инструменту OpenResty.
Обратите внимание: для использования версии необходимо установить версию не ниже 1.11.0, поскольку используется ngx.var.request_id.
Код написан понятным образом, хотя и не является элегантным.
Вот некоторые из моих собственных разработок. Если они вам интересны, присоединяйтесь к нам.
В настоящее время обновляется раздел WIKI, а также уже обновлена информация по установке.
Обновление: способы поддержки правил
Поддерживается параллельное сопоставление регулярных выражений (с использованием https://github.com/cloudflare/lua-aho-corasick).
Добавлены: параллельные регулярные выражения («aho») — список.
Поддержка параллельных регулярных выражений («aho»):
Список:
«host»: [
«^www.baidu»,
«. *.baidu.com$»
],
«aho».
— существующие правила: равно («»), содержит («in»), список («list»), словарь («dict»), регулярное выражение («jio|jo|***»);
— добавлены: начало списка («start_list») — с чего начинается список;
— нечувствительность к регистру начала списка («ustart_list»);
— конец списка («end_list») — чем заканчивается список;
— нечувствительность к регистру конца списка («uend_list»);
— содержит список («in_list») — содержит элементы списка;
— нечувствительность к регистру содержит список («uin_list») — расширенная версия «in_list»;
— длина («len») [Min, Max] — означает длину больше или равную Min и меньше или равную Max.
Пример:
«host»: [
«www.baidu.»,
«img.baidu.»
],
«start_list».
«referer»: [0, 150], «len» — длина referer находится в диапазоне от 0 до 150.
Бесплатная неоткрытая версия
https://www.kancloud.cn/openstar/install/1136671
История изменений
1.7. Обновление способа сопоставления правил с возможностью инвертирования и отмены действия next.
По умолчанию действие next не применяется, поэтому правила можно использовать повторно. Для применения действия next необходимо внести изменения.
1.7.1.11. Обновление сопоставления правил, равных выражению, и сопоставления post_form с использованием регулярного выражения (*) для всех имён форм.
Сопоставление имени файла формы с регулярным выражением (*), например:
[post_form, [(;|-|/)], jio, [*, 2], false] — сопоставление всех имён файлов форм.
[«www.test.com», «»]
[«www.test.com», «=»] — новое выражение, равное.
1.7.1.10. Поддержка ограничения скорости на основе бизнес-атрибутов.
network_Mod: «network»: {«maxReqs»: 30, «pTime»: 10, «blackTime»: 600, «guid»: «cookie_userguid»}.
Фактически, ограничение частоты выполняется на основе значения cookie userguid. По умолчанию используется ограничение частоты на основе IP.
1.7.1.1. Изменение правил host_Mod.
На данный момент существует только два типа правил (app_ext | network). Пожалуйста, обратитесь к conf_json/host_json/101.200.122.200.json.
1.7.0.24. Изменение сопоставления host_Mod и list на dict.
Для удобства понимания list представляет собой последовательность, а dict — словарь.
Например:
«method»: [{
POST: true,
GET: true
}, «dict» — исходный list.
«ips»: [[
«101.254.241.149»,
«106.37.236.170»],
«list» — исходная таблица.
]
1.6. Улучшение производительности за счёт кэширования правил и разделения ключей.
Правила были кэшированы, что значительно улучшило производительность. Также были внесены улучшения в сохранение json-файлов.
1.5. Добавление режима Master/Slave по запросу некоторых пользователей.
Основной сервер периодически отправляет данные конфигурации в Redis, а подчинённый сервер периодически извлекает данные из Redis и сохраняет их в файл.
1.4. Обновление именования, добавление сопоставления нескольких правил.
Ранее использовалось имя uri вместо url, query_string вместо args, добавлено сопоставление app_Mod с несколькими правилами и поддержка OR.
1.3. Обновление функции перенаправления с возможностью настройки set-cookie.
Можно настроить перенаправление на определённый URL или несколько URL для выполнения операции set-cookie. Cookie не имеет состояния.
1.2. Обновление защиты от CSRF путём добавления action.
Действие allow позволяет разрешить доступ, а действие next — продолжить сопоставление правил после успешного сопоставления. Действие next используется для защиты от внешних CSRF.
Предполагается, что все последующие действия поддерживают эту функцию.
1.1. Добавление app_Mod для обогащения действия allow (ip).
Определённые каталоги веб-сайта доступны только с определённых IP-адресов (например, для доступа к административным панелям, таким как phpmyadmin).
0.9–1.0. Модификация большого количества глобальных функций.
После изучения OpenResty Best Practices код стал более профессиональным, и многие глобальные переменные и функции были изменены.
0.8. Оптимизация алгоритма.
Изначально аргументы перебирались для каждого параметра, что могло привести к снижению производительности. Теперь используется новый API для извлечения всех параметров из URL, что обеспечивает значительное улучшение производительности.
0.7. Добавление кластерной версии.
Когда существовало от 2 до 4 серверов OpenStar для обеспечения безопасности, управление осуществлялось с помощью скриптов. Однако без централизованного управления было принято решение использовать Redis.
0.6. Добавление операций API.
Поскольку я являюсь неопытным программистом (к сожалению, в настоящее время все разработчики занимаются безопасностью), интерфейс не был разработан заранее, поэтому API был реализован для удовлетворения требований автоматизации.
0.4–0.5. Добавление операций с конфигурационным файлом.
Сначала все операции выполнялись в коде Lua, но по мере увеличения функциональности было решено использовать файлы конфигурации json.
0.3. Добавление модуля WAF.
Основываясь на опыте работы с CC, я постепенно добавлял модули WAF, включая правила, основанные на ModSecurity, Loveshell и других источниках.
0.2. Версия CC для прикладного уровня.
Чтобы решить проблему CC-атак, были добавлены модули безопасности прикладного уровня, такие как установка cookie, перенаправление URL и перенаправление JS.
0.1. Версия CC базового уровня.
Первоначально проект был направлен на решение проблемы CC-атак. Из-за ограничений аппаратного обеспечения DDoS-защиты в новой сетевой среде (включая CDN) невозможно получить реальный IP-адрес пользователя, я разработал первую версию, которая ограничивает доступ на основе пользовательского HTTP-заголовка для получения реального IP-адреса пользователя (OpenStar может ограничивать доступ к определённому URL на основе частоты запросов, исключая статические файлы, например, если установлен referer_Mod или url_Mod). allow log refile rehtml relua) можно настроить различные сложные сценарии
Использование дополнительных конфигурационных файлов ngx само по себе не рассматривается, использование динамического upstream можно посмотреть в другом моём проекте https://github.com/starjun/dynamic_upstream-by-balancer. Некоторые интерфейсы не были добавлены, посмотрите код, который очень легко реализовать самостоятельно. Обратное проксирование host и бэкэнд IP находятся в DICT (обратите внимание, что это IP-группа, а не просто какой-то балансировщик, пишущий динамический upstream как IP), и поддерживает различные способы балансировки нагрузки, которые, вероятно, могут удовлетворить большинство потребностей. Время от времени я буду совершенствовать HTTPS.
В настоящее время openstar поддерживает кластеризацию, синхронизацию правил и отправку вниз и т. д., все они предоставляются API, все пассивны, и причина, по которой правила не помещаются в redis, заключается в том, что вы должны попробовать сами, каждый раз, когда правило фильтруется, оно сериализуется из redis, и сериализуется после получения из dict, и вы можете попробовать это самостоятельно, чтобы увидеть производительность. Между тем, недавно было добавлено периодическое извлечение конфигурации из redis (тестирование... ).
Адрес электронной почты admin@17173.com больше не используется, пожалуйста, не отправляйте электронные письма на этот адрес.
Нет
Коммерческая версия:
CC защита от кражи личных данных, защита от сбора данных, защита от дублирования и т.д.:
Точки атаки CC:
a: URL-адреса, доступные пользователям (поисковые запросы [запросы к базе данных], высокопроизводительные вычисления [вычисления ЦП], случайные URL-адреса [соединения] и т.д.)
b: Встроенные типы URL-адресов (URL-адреса проверки подлинности встроены в проверку подлинности [вычисление ЦП], URL-адреса определения того, существует ли пользователь, встроены в AJAX [запрос к базе данных] и т.д.)
c: Небраузерные типы интерфейсов (некоторые общедоступные API, WEBservice и другие интерфейсы без SDK)
d: Конкретные языки, серверные атаки (PHP DOS, медленные атаки и т.д.).
Предоставленный мной алгоритм защиты предназначен для защиты от атак типа a и b, при активации защиты типа a можно сначала создать страницу перехода с добавленной меткой, при активации защиты типа b динамически добавлять метки на страницы рендеринга, тип c имеет SDK, и написание собственного кода для поддержки собственного алгоритма защиты не является проблемой.
Проверка статического и динамического JavaScript:
На странице перехода / странице рендеринга добавьте метку к следующему запросу URL (openstar уже реализовал добавление метки в конец URL), добавьте параметр get с именем и значением, сгенерированным сервером или страницей переднего плана JavaScript, например, добавьте cc=1ldldj к концу URL, сервер определяет законность значения с помощью статических регулярных выражений или динамических проверок, является ли значение сгенерировано сервером, проверка законности становится более строгой.
Усиление JavaScript (получение траектории мыши, события щелчка мыши, случайная задержка, на основе конкретного браузера, JavaScript):
Обычные атаки с использованием JavaScript-инструментов или сканеров могут быть проанализированы, поэтому JavaScript может быть усилен, например, определение траектории мыши и событий щелчка мышью не будут выполнять последующие запросы; на основе браузера JavaScript, некоторые браузеры имеют свои собственные диалекты, эти инструменты сканирования и атаки не могут анализировать JavaScript, поэтому они не будут выполнять следующие запросы; также используйте функцию случайной задержки JavaScript для разделения времени следующего запроса, так что частота запросов будет разделена, таким образом, смягчая частоту запросов, а также объединяя траекторию мыши и события щелчка мышью, можно хорошо идентифицировать инструменты и людей.
Отпечаток пальца браузера (создание уникального отпечатка пальца для браузера, чтобы определить согласованность цепочки запросов отпечатков пальцев): Рекламные компании могут сделать это наполовину, потому что отпечаток пальца браузера по-прежнему имеет значительную справочную ценность в Интернете, конечно, это не означает, что отпечаток пальца должен соответствовать тегам рекламы и другим коммерческим данным, но только требуется база данных отпечатков пальцев (аналогично IP-базе данных доверия, конечно, она также имеет срок действия), потому что CC-атака, сбор данных и дублирование страниц - это очень чёткие отпечатки пальцев в Интернете. Ситуация может быть создана компанией, которая может помочь в борьбе с CC-атаками, кражей данных, дублированием страниц и т.д., и в будущем крупные компании смогут совместно использовать эти данные отпечатков пальцев браузера, создавая альянс, чтобы судить, является ли отпечаток пальца реальным пользователем и другими доступными данными.
http://123.57.220.116/fgjs2.html Посмотрите на свой отпечаток браузера (если вы не можете получить доступ, ха, мой ECS истёк!)
Ссылка: https://github.com/Valve/fingerprintjs2
Контроль/защита браузера:
Используйте JavaScript для выполнения следующего запроса и перехода, а также усиления траектории мыши, событий мыши, диалектов JavaScript браузера и других суждений, всё ещё есть определённые недостатки, поэтому вы можете напрямую использовать элементы управления или сотрудничать с браузером (браузер поддерживает этот метод защиты метки).
Пример:
HTTP://www.cc.com?cc=@{"api":"http://1.1.1.1/cc/api","key":"iodjdjkdldskl"}@
HTTP://www.cc.com?cc=@{"api":"tcp://1.1.1.1:908","key":"iodjdjkdldskl"}@
HTTP://www.cc.com?cc=@{"api":"local","key":"1:2345:44"}@ Перейдите на страницу или страницу рендеринга и элементы управления/браузер могут распознавать содержимое @, и следующий запрос будет содержать это значение.
i: Установите cookie, его законность определяется элементами управления и веб-сервером в двустороннем порядке или шифруется, чтобы определить, является ли следующий запрос законным.
ii: Добавьте параметры args в конце URL, значение параметра является законным, определённым элементами управления и веб-сервером в двустороннем порядке или зашифрованным, чтобы определить, является ли следующий запрос законным.
iii: Добавление параметров POST, значение является законным, определяется элементами управления и веб-сервером в двустороннем порядке или шифруется и т.д. для проверки следующего запроса.
Эти алгоритмы защиты я сейчас подаю заявку на соответствующий патент, будущие бесплатные версии для личного использования, платные версии только для предприятий, пожалуйста, перепечатайте, компании, пропустите меня, маленький брат, без стыда.
Эти алгоритмы защиты я сейчас подаю заявку на соответствующий патент, будущие бесплатные версии для личного использования, платные версии только для предприятий, пожалуйста, перепечатайте, компании, пропустите меня, маленький брат, без стыда.
Эти алгоритмы защиты я сейчас подаю заявку на соответствующий патент, будущие бесплатные версии для личного использования, платные версии только для предприятий, пожалуйста, перепишите, компании, пропустите меня, маленького брата, без стыда.
OpenStar - это основанный на OpenResty, высокопроизводительный WAF, который также добавляет другие гибкие, дружественные и практические функции, которые являются усиленными WAF. App_Mod поддерживает правила группы, соединительные символы поддерживают or, см. документ/demo.md.
WAF защита в OpenStar использует традиционные методы сопоставления строк, такие как регулярные выражения и включение (есть люди, которые спрашивают, разве сейчас не популярны автономные механизмы обучения? Регулярные выражения, включение и т.д. будут иметь слепые зоны и могут быть обойдены; проблемы с ложными срабатываниями и пропусками WAF и т.д....). Правила не являются универсальными, но нет правил, которые были бы абсолютно бесполезными. Здесь я кратко объясню, что механизм автономного анализа и обучения, используемый нашим механизмом анализа журналов, зарезервирован для API, который может в реальном времени добавлять блокировку, и здесь используется высокая производительность и высокая параллельная обработка для решения проблем, и в соответствии с реальной ситуацией бизнеса, мы можем решить подавляющее большинство проблем безопасности WEB 1.0 и WEB 2.0 (более 90%). Защита WAF в OpenStar осуществляется в соответствии с заголовком, аргументами, публикацией, частотой доступа и т.д., многоуровневая защита выполняется последовательно, и подробные сведения о функциях будут подробно описаны ниже.
Во времена 1.0 атаки осуществлялись через уязвимости сервера (переполнение IIS6 и т.д.), уязвимости приложений WEB (SQL-инъекция, загрузка файлов, выполнение команд, включение файлов и т.д.), которые принадлежали атакам на стороне сервера, хотя эта проблема существует уже много лет, к сожалению, эта уязвимость всё ещё существует, и она неоднократно повторяется.
С появлением социальных сетей, которые ранее не привлекали внимания, XSS, CSRF и другие уязвимости постепенно вошли в поле зрения людей, поэтому во времена 2.0 мысли об атаке будут более важными, вы можете представить себе слишком много возможностей.
Аналогично разработке и дизайну шаблонов, 3.0 будет уделять внимание безопасности бизнес-логики и данных самого приложения, таким как обход паролей, обход вторичных паролей, уязвимости платежей, отмывание денег и другие типы уязвимостей, поэтому основное внимание уделяется безопасности продукта, безопасности данных, управлению рисками и т.д..
Безопасность - это не только вопрос технологий, но и административного управления, физической безопасности и т.д., чтобы обеспечить максимальную защиту. Многолетний опыт работы в сфере безопасности: люди - это самая большая угроза; независимо от того, внешняя, внутренняя, непреднамеренная или преднамеренная ошибка (нет уродливых женщин, только ленивые женщины), я думаю, что это можно применить здесь, чисто личное мнение. В запросе текст технической направленности из области разработки и тестирования программного обеспечения. Основной язык текста запроса — китайский язык.
Перевод на русский язык:
В эпоху интернета с добавлением CDN, расширение защиты сетевого уровня становится необходимым. Статистика IP будет находиться в HTTP-заголовке, частота использования, количество и чёрный список будут обрабатываться по-прежнему.
На традиционном 4-уровневом защитном уровне проблем нет. Защита реализуется на прикладном уровне. Она должна быть адаптирована к атакам, например, если атака направлена на встроенный URL, мы не можем использовать методы, такие как перенаправление JavaScript или 302 кода подтверждения. После многократного применения CC защиты, такие методы защиты больше не работают. Позже я поделюсь своим алгоритмом защиты и уже сейчас его можно реализовать в OpenStar.
Браузер может выполнять JavaScript и Flash. Здесь я делюсь некоторыми методами защиты на основе JavaScript. Для реализации защиты Flash-приложений и защиты от захвата страниц требуется самостоятельная разработка (это немного сложнее, чем JavaScript).
Клиентская защита Используется JavaScript для реализации клиентской защиты (распознавание браузера, определение траектории мыши, добавление правил к URL, случайная задержка, получение событий клавиатуры и мыши и т.д.). Здесь очень сложно, например, браузеры могут распознавать специальные символы JavaScript, некоторые диалекты JavaScript, а некоторые браузеры имеют пользовательские теги и так далее.
Серверная защита Правила, добавляемые к URL, генерируются динамически сервером, а не используются статическими регулярными выражениями для проверки их законности.
Специфические атаки Этот тип атак можно быстро сопоставить по характерным признакам (медленные атаки, HTTP-заголовок атаки PHP5.3).
Простой сценарий
Первый этап:
Первый этап:
Второй этап:
Третий этап:
Примечание: после многократных реальных сражений с CC защитой, очень редко приходится переходить к третьему этапу защиты прикладного уровня. Конечно, важно иметь хороший запас этих сценариев JavaScript. Поэтому я предлагаю использовать элементы управления и даже сотрудничать с производителями браузеров для более точной защиты. Это обеспечивает хорошую защиту от CC атак, захвата страниц и подделки платежей.
Защита прикладного уровня используется, когда эффект защиты сетевого уровня и расширенного сетевого уровня плохой, обычно она используется нечасто, потому что под защитой OpenStar очень мало случаев, требующих третьего этапа защиты прикладного уровня. При защите от захвата страниц вы можете дать волю своему воображению (JavaScript — хороший помощник, используйте его хорошо). OpenStar может помочь вам быстро реализовать это; конечно, защита от захвата с использованием Flash лучше (недостаточно гибкая). [24]: https://github.com/starjun/openstar/wiki/14-replace_Mod [25]: https://github.com/knownsec/404StarLink-Project/raw/master/logo.png "404.png" [26]: https://github.com/knownsec/404StarLink2.0-Galaxy [27]: ./doc/xq.jpg "xq.jpg"
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Комментарии ( 0 )