Программа для защиты сайта от взлома и других кибератак

[CoreSystem]

Уверен, что вы не понаслышке знаете, сколько труда стоит настроить работу сайта так, чтобы он начал стабильно приносить деньги от рекламы или продажи ссылок. А если речь идет о целой сети сайтов, то это вообще титанические усилия, ведь работать нужно над сотнями или тысячами ресурсов. Нужно создать сам сайт, наполнить его контентом, продвинуть в поисковиках, наладить стабильную монетизацию – все это месяцы (а в случае «белых» сайтов и годы) тяжелого труда.

 

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

 

Фильтрация GET/POST запросов:

• Вы сами решаете какие запросы разрешить а какие заблокировать
  
• Все запросы пользователя сохраняются в журнал
  
• Защита CMS от загрузки и инъекций вредоносного кода
  
• Пример настройки http://isp-demo.ngens.ru/
  

Безопасность:

• Брандмауэр для блокировки по IPv4/6 и "User agent"
  
• Защита от «брута» паролей
  
• Двойная аутентификация для административных разделов сайта
  
• Программная защита от большинства типов DDoS-атак
  
• Защита от Zero Day, отражающая неизвестные угрозы
  

Защита от ботов:

• Проверка поисковых ботов по PTR
  
• Блокирует парсеры, дорвеи, спамботы, клик-боты
  
• Пример проверки "reCAPTCHA", "SignalR", "JavaScript"
  

Копирования и восстановления данных:

• Данные хранятся на серверах с шифрования AES-256
  
• Копируются отдельные измененные файлы
  
• Поддержка FTP, SFTP, WebDAV, Yandex.Disk, OneDrive
  
• Восстановление файлов по выбранной дате или по актуальному состоянию
  
• Подробный отчет о каждом выполненном задании
  

Дополнительно:

• Установка лимита запросов на IP, для снижения нагрузки
  
• Встроенный антивирус AI-Bolit
  
• Открытый API
  
• Поддержка Docker
  
• Бесплатная установка и настройка ISPCore на сервере
  

 

Пример сайта:

http://isp1.ngens.ru/

 

Попробовать бесплатно:

https://my.core-system.org/reg

[ArexMan]

..."Информация прозвучала на правах рекламы"

[a13x]

Сколько написано непонятного говна, который просто нельзя выполнить.

 

Вы сами решаете какие запросы разрешить а какие заблокировать

- т.е. мне вручную их чтоли пропускать? ))

 

Защита CMS от загрузки и инъекций вредоносного кода

- каждую строчку кода будете просматривать и искать место где возможна инъекция?

 

Блокирует парсеры, дорвеи, спамботы, клик-боты

- люди похоже вобще не в курсе как это работает.

 

Остальсь джойказино и вулкан рекламировать здесь чтобы совсем всё засрать.

[CoreSystem]

a13x, 

1) Вы заранее вписываете правила разрешенных запросов, например "GET: /topic/[\w0-9-]+/?". Пользователь сможет просматривать темы и не сможет выполнить любой другой запрос, например запросить страницу "http://forum.simplacms.ru/topic/13403/test".

2) Этого делать незачем, у вас может быть любая CMS с сотнями шелов, но выполнить их не получиться, смотрите пункт 1.

3) Никто не уделяет внимания клонировщикам, пока не увидят динамическую копию своего сайта в поисковой выдачи. 

Изменено 5 марта, 2018 пользователем CoreSystem

[a13x]

п.1 зачем мне это делать если при любом другом запросе, отличном от того что нужно, у меня отдастся ошибка 404? (допустим что у меня один обработчик на все виды урлов).

п.2 очень даже получится т.к. запрос может обращаться напрямую к скрипту

п.3 при всём желании вы не сможете сделать защиту от парсинга, её просто не существует. если я могу открыть ваш сайт в браузере и мне выдастся результат, то я в ЛЮБОМ случае смогу этот же результат получить через скрипт.

 

ну и в довесок:

Установка лимита запросов на IP, для снижения нагрузки 

- так нагрузку никто не снижает, всё что вы получите - кучу недовольных клиентов, особенно тех, которые сидят за NATом (1 ип на много человек).

 

Бесплатная установка и настройка ISPCore на сервере

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

 

 Программная защита от большинства типов DDoS-атак

- чем cloudflare хуже? облачный хостинг с защитой от ДДОС, на случай если такое конечно произойдёт.

 

Я понимаю что вы продаёте свой софт, но он не ко всему подойдёт, хотя я не исключаю что вы найдете своего клиента. Удачи.

Изменено 5 марта, 2018 пользователем a13x

[CoreSystem]

Давайте возьмем соседнюю тему http://forum.simplacms.ru/topic/13317-%D1%81%D0%B5%D1%80%D1%8C%D1%91%D0%B7%D0%BD%D0%B0%D1%8F-%D1%83%D1%8F%D0%B7%D0%B2%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D1%8C/ и представим что уязвимость серьезней, например любой пользователь имеет доступ к файлу /simpla/design/js/tiny_mce/plugins/smexplorer/php/action.php и через POST запрос, может загрузить шел в корень сайта "/shelll.php"

 

Добавим еще скрытый shell в шаблоне/модуле, который можно вызвать через запрос "/?get=shell", данный шел был скрыт в бесплатном шаблоне или модуле, а сам модуль/шаблон был установлен в CMS.

 

Для примера сайта, возьмем простенький блог для sape.ru, в нашем блоге есть только главная и сами новости /news/id, с которых идет продажа ссылок.

 

Попытка взлома CMS, без фильтра запросов

1) Пользователь загружает shell через POST запрос к файлу /simpla/design/js/tiny_mce/plugins/smexplorer/php/action.php , после чего открывает "/shell.php" и делает с сайтов все что ему нужно.

2) Пользователь загружает скрытый шел через GET запрос "/?get=shell" и получает полный доступ к сайту.

 

Попытка взлома CMS, с фильтром запросов ISPCore

Учитывая что на сайте есть только главная и /news/id, то в фильтре выбираем блокировать все кроме "^/$" и "^/news/[0-9]+$", при этом запросы должны быть только GET и не должны содержать аргументов в адресной строке "/news/id?arg=1&rg=2" и т.д.

1) Пользователь пытается загрузить shell через POST запрос к файлу /simpla/design/js/tiny_mce/plugins/smexplorer/php/action.php и получает 403, потому что POST запрос к файлу /simpla/design/js/tiny_mce/plugins/smexplorer/php/action.php отсутствует в списке разрешенных запросов. 

2) Пользователь пытается воспользоватся скрытым шелом /?get=shell" и тоже получает 403, потому что "get=shell", это аргумент, которого нету в списке разрешенных запросов.

 

В примере 2, пользователь не может воспользоватся скрытым шелом и уязвимостью CMS.

Изменено 5 марта, 2018 пользователем CoreSystem

[CoreSystem]

п.2 - В обычном варианте да, но при фильтре запросов так сделать нельзя, запрос сначала идет в ISPCore, после чего выдается 403, либо ответ скрипта (если вы в ISPCore разрешили запрос к этому файлу)

 

п.3 - Тут имеется веду более стандартные парсеры на php, которые используются в 90% случаев для автоматического парсинга контента на свой сайт, ну и конечно же популярные сейчас динамические клонировщики сайтов, которые делают полную копию вашего сайта всего за 5 минут.

 

- чем cloudflare хуже? - Не все используют cloudflare, особенно владельцы sape сайтов, при этом сервера на которых расположены сайты не имеют защиту от DDoS атак. Для таких клиентов и сделана программная реализация.

 

- Лимит запросов нужен не всем и каждый сам решает нужен он ему или нет. Многим владельцам sape сайтов, такой лимит нужен, а вот магазинам и СДЛ, такой функционал лучше отключать. 

 

В любом случаи спасибо вам за комментарий, мы поняли что текст первого поста слишком пустой и не все понимаю принцип работы софта.

Будем работать над более информативным постом 

Изменено 5 марта, 2018 пользователем CoreSystem

[yr4ik]

не сильно вчитывался, может пропустил..

 

Каким образом она ловит запросы?

Так же интересно обработка ЧПУ. Оно берет уже результат реврайта или же нужно и на них правила писать? 

Какова нагрузка и как система себя ведет при большом потоке запросов? 

[Karabaska]

1) Вы заранее вписываете правила разрешенных запросов, например "GET: /topic/[\w0-9-]+/?". Пользователь сможет просматривать темы и не сможет выполнить любой другой запрос, например запросить страницу "http://forum.simplacms.ru/topic/13403/test".

А можете дать полный список разрешенных запросов для стандартной установки Simpla?

Интересно, насколько он велик или мал...

[CoreSystem]

не сильно вчитывался, может пропустил..

 

Каким образом она ловит запросы?

Так же интересно обработка ЧПУ. Оно берет уже результат реврайта или же нужно и на них правила писать? 

Какова нагрузка и как система себя ведет при большом потоке запросов? 

 

Это серверный софт, он встраивается между nginx и php/apache/proxy, в CMS редактировать ничего не нужно. 

Если упрощено то в nginx настройка выглядит так:

location / {
    try_files /does_not_exists @fallback;
}	

location @fallback {
    proxy_pass http://unix:/var/run/ispcore.sock:/core/check/request?method=$request_method&host=$host&uri=$request_uri;
    include /etc/nginx/asp.net_params;
    proxy_intercept_errors on;
    error_page 303 = @backend;
}

location @backend {
    proxy_pass http://your_server_ip:8080;
    proxy_set_header Host $host;
}

Вариант 1

1) Запрос "/news/5" попадает в @fallback

2) ISPCore проверяет запрос "/news/5" в белом списке и возвращает код 303 (запрос подходит под правило "/news/[0-9]+")

3) Запрос уходит в @backend и обрабатывается как обычный запрос в apache

 

Вариант 2

1) Запрос "/?get=shell" попадает в @fallback

2) ISPCore не видит правила для "/?get=shell" в белом списке и отдает код 403

3) Запрос в секцию @backend не попадает 

 

Вы можете зайти на сайт http://isp-demo.ngens.ru/ , тут есть доступ к панели где можно посмотреть как записаны правила, там же вы найдете пример разрешенных и запрещенных запросов исходя из правил.

 

----------------

 

Нагрузка небольшая, при 675 запросах в секунду, уходит одно ядро CPU на 2.40Hz, это с учетом nginx.

Время задержки между @fallback и @backend при проверке запроса, в среднем 2-3ms.

Изменено 6 марта, 2018 пользователем CoreSystem

[CoreSystem]

А можете дать полный список разрешенных запросов для стандартной установки Simpla?

Интересно, насколько он велик или мал...

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

 

Но если брать за основу OpenCart, в котором часть url является базой, то выглядит это примерно так https://195.211.154.91:8793/requests-filter/template?Id=2 (пароль: SLX2mLwPpc09)

 

------------

Настройка сайта на OpenCart может занять сутки, даже с учетом базового шаблона, а вот настройка такого новостника http://isp1.ngens.ru/ занимает 5-10 минут. Можно сказать что сложность настройки зависит от количества разрешенных действий для пользователя. 

Изменено 6 марта, 2018 пользователем CoreSystem

[Karabaska]

Настройка сайта на OpenCart может занять сутки, даже с учетом базового шаблона...

Однако!

Этого для кого - для специалистов или простых пользователей?

И после такой объемной работы есть ли какие гарантии, что все настроено правильно и ничего не пропущено? Ведь если что-то упущено, то весь смысл немалой работы теряется...

 

Как проводится защита от заливка типа "/?keyword=shell" ?

[CoreSystem]

Однако!

Этого для кого - для специалистов или простых пользователей?

И после такой объемной работы есть ли какие гарантии, что все настроено правильно и ничего не пропущено? Ведь если что-то упущено, то весь смысл немалой работы теряется...

 

Как проводится защита от заливка типа "/?keyword=shell" ?

Скорее для специалистов, вы должны понимать как работает regex, а так-же уметь работать с консолью браузера. 

 

После настройки лучше проводить тесты, дописывая к url аргументы или данные которых быть не должно, если ответ будет 403, то все настроено правильно. Мы понимаем что софт специфический и сложный в освоении, поэтому вы всегда можете предоставить доступ к ISPCore и url сайта в тикет, для проверки и настройки правил. 

 

Если в списке разрешенных запросов у вас нету такого аргумента "keyword=shell" или "keyword=[a-z]+", то воспользоватся запросом "/?keyword=shell" не получится, даже если это разрешает CMS.

Изменено 6 марта, 2018 пользователем CoreSystem

[a13x]

Тройная защита получается:

1. на стороне CMS

2. на стороне сервера (через регулярки в URL Rewrite отсекаем лишнее)

3. и ISP Core

По моему достаточно грамотно настроить (создать) CMS  и последние 2 варианта просто не нужны. Ну и как написали выше, действительно нет гарантий что конечный пользователь всё правильно настроит.

Назовите мне хотя бы парочку ИМ которым нужна ваша реализация в плане безопасности? Битрикс? Опенкарт? Симпла? Вебасист?

Всё это очень похоже на многослойный пирог "безопасности", а ведь вы за свой софт ещё и денег хотите, за поддержку ежемесячно получать, не так ли?

Изменено 6 марта, 2018 пользователем a13x

[CoreSystem]

a13x, Мало людей вырезают с CMS код который не используют.

[CoreSystem]

 - Назовите мне хотя бы парочку ИМ которым нужна ваша реализация в плане безопасности?

DLE, WP, посмотрите "форумы/заказы на фрилас биржах" и увидите что эти CMS постоянно ломают, кроме того вы забываете о простых вещах - "модули и шаблоны которые можно скачать с паскалкой"

 

Даже искать долго не нужно, вторая ссылка по запросу "DLE уязвимость", http://www.dle9.com/books/poleznye-stati/4686-vzlom-dle-112-i-nizhe-stepen-opasnost-vysokaya.html

Изменено 6 марта, 2018 пользователем CoreSystem

[a13x]

DLE, WP

Это не ИМ, это ширпотреб. Эти цмс дырявые насковзь. Припишите туде же друпал и джумлу + они созданы не для ИМ, а для блогов, новостей, статей и тп., это потом уже для них написали модули корзины и прочее.

Кстати, сколько цена вашей суперзащиты в месяц стоит?

[CoreSystem]

a13x, Тем не менее эти CMS используют. Я уверен что и тут есть пользователи которые использую wp,dle.

 

Цена зависит от потребностей:

Если вам нужен только фильтр запросов, то цена 15$ в год.

Если вам нужен еще бекап на "FTP, SFTP, WebDAV, Yandex.Disk, OneDrive" и другие компоненты, то цена 32$ в год или 3$ в месяц. 

Изменено 6 марта, 2018 пользователем CoreSystem

[CoreSystem]

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

 

Вы можете поставить логи, отливить паскалки и пропатчить CMS, но через месяц может вылезти еще одна уязвимость через которую можно залить shell в CMS (если говорить о wp,dle то это происходит постоянно). Когда у вас сетки сайтов приносящие доход в пару сотен USD/месяц, имея при этом примитивный ЧПУ - (главная/категории/новости), то затрата в 15$/год за фильтр запросов не большая цена. Наши текущие клиенты это понимают, но лишь потому что постоянно подвергались взломам CMS и тратили много времени и средств на очистку/патчи своих сеток. 

Изменено 6 марта, 2018 пользователем CoreSystem

[Karabaska]

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

И что, Вы знаете все те, которых быть не должно?

Как говорится, "знал бы, где упаду, соломки б подстелил..."

[CoreSystem]

И что, Вы знаете все те, которых быть не должно?

Как говорится, "знал бы, где упаду, соломки б подстелил..."

Нет, вы настраиваете список запросов которые быть должны, например "/" и "/news/[0-9]+", все остальные запросы считаются запрещенными и при запросах "/cat", "/?arg=1", "/news/54r" пользователь должен получить 403 (если все правильно настроено). 

 

Ответ сайта, пользователь может получить только если сделает GET запрос "/" или "/news/12", "/news/5348" и т.д

Изменено 6 марта, 2018 пользователем CoreSystem

[Karabaska]

Повторю вопрос, как проводится защита от заливка типа "/?keyword=shell" ?
 

Если в списке разрешенных запросов у вас нету такого аргумента "keyword=shell" или "keyword=[a-z]+", то воспользоватся запросом "/?keyword=shell" не получится, даже если это разрешает CMS.

 

В Simpla такой адрес работает при поиске. Значит, запрещать что-то типа keyword=[a-z]+ значит практически  запретить поиск - совсем неподходяще.

Какие конкретно правила прописывать в такой ситуации?

[CoreSystem]

Повторю вопрос, как проводится защита от заливка типа "/?keyword=shell" ?

 

 

В Simpla такой адрес работает при поиске. Значит, запрещать что-то типа keyword=[a-z]+ значит практически  запретить поиск - совсем неподходяще.

Какие конкретно правила прописывать в такой ситуации?

 

Для этого есть правило 302, когда пользователь запрашивает "/?keyword=<?php echo="test 1" >" то его через 302 отправляет на "/?keyword=echotest 1", то есть из запроса убираются лишние символы. Список разрешенных символов вы прописываете сами, например "[\w0-9,- ]+"

Изменено 6 марта, 2018 пользователем CoreSystem

[Karabaska]

Ничего не понял.  Откуда и зачем тут "php", "echo" и прочее?

 

Вы же писали #6  для  примера "Пользователь загружает скрытый шел через GET запрос "/?get=shell" ... "

 

А убрать из запроса лишние символы можно одной-двумя строками в .htaccess ...

[CoreSystem]

Ничего не понял.  Откуда и зачем тут "php", "echo" и прочее?

 

Вы же писали #6  для  примера "Пользователь загружает скрытый шел через GET запрос "/?get=shell" ... "

 

А убрать из запроса лишние символы можно одной-двумя строками в .htaccess ...

Это пример, если поиск содержит уязвимость которая позволяет что-то выполнить передав запрещенные символы. 

Если вам просто нужно разрешить любые символы, то используется правило "keyword=[^&]+"

 

#6 Если включен фильтр запросов и пользователь запрашивает "/?get=shell", то он получает ошибку 403, не смотря на то, что в CMS есть возможность вызвать шел через запрос "/?get=shell"

Изменено 6 марта, 2018 пользователем CoreSystem