Система защиты - Безопасность сайтов на Joomla

Здравствуйте

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

Мы разработали систему защиты,  которая основана на анализе post, get запросов.
Если система защиты обнаруживает подозрительный запрос, то система его блокирует и он до сайта не доходит.

Мы понимаем, что клиентам порой бывает трудно следить за обновлениями и уязвимостями Joomla, система настроена на работу даже с такими сайтами, где содержатся общеизвестные уязвимости.

Так же ведётся полный лог post, get запросов на тот случай, если всё же система безопасности пропустит вредоносный запрос и сайт будет взломан.

По логам мы обнаружим слабое место и обучим нашу систему.

Кому интересно, напишите в личку, мы сообщим сайт.

Если возможно, то можем написать в теме.

преимущества такие, что система не борется с вирусами или шелами, она заранее не даёт проникнуть им

принцип раскройте вашей системы, что требуется и как интегрируется ваш код для работы, и какая гарантия, что через ваш же код не поступит то от чего защита

Здравствуйте

Предположим имеется некий сайт
111.ru

Что бы попытаться атаковать сайт(взломать его), злоумышленник отправляет post get запросы.

Перед тем как их отправить сайту, система анализирует по нашим сигнатурам на зловредность(всё это происходит на лету и без задержек).

Если всё же система обнаружила атаку, то данный запрос блокируется, а система выдаёт, что такой-то запрос заблокирован и емэйл, куда можно обратиться, если блокировка ложная(блокировки ложные бывают, но крайне редко)

Какими методами осуществляется перехват?
Где находятся и как часто обновляются сигнатуры?
Черный или белый список и есть ли переключатель и дообучение?

написано два модуля для nginx и apache(перехват в двух местах)

система постоянно обучается(но пока в полуручном режиме), запускается скрипт для анализа post get запросов сервера, выдаются подозрителньные, далее человек проверяет действительно ли они опасны и если да, то добавляется сигнатура.


Для каждого отдельного сайта имеется возможность добавить исключения(это как раз про ложные срабатывания)

написано два модуля для nginx и apache

Под какие версии и ОС?

Так то весьма интересно.
Запросы отправляются вам или контролируются локально?

Планируете платно распостранять или как?

И да, умеет ли система отслеживать ответ и реагировать только если код ответа 200?

На самом деле мы пока тестили для сайтов своих клиентов, не совсем уверен, можно ли здесь сообщать, но укажем.(yutex.ru)

Если  в этой ветке нельзя оставлять сайты хостеров, то удалите данное сообщение.

Одно время мы стали получать по 3-5 абуз каждый день, что спам, сайты заражены и так далее(почти все сайты были на Joomla или водпрессе)

После разработки и установки системы, кол-во абуз свелось практически к нулю(судим по сайтам наших клиентов)

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

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

Схема примерно такая.
Предположим сайт 111.ru и айпи его хостера(1.1.1.1)

Клиент в А записи домена пропишет наш айпи(2.2.2.2)
айпи написал для примера

post get запросы направляются к нам, мы блокируем вредоносные, а белые перенаправляем на  айпи хотера 1.1.1.1

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

И да, умеет ли система отслеживать ответ и реагировать только если код ответа 200?

Код ответа не проверяет

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

К сожалению, пока данный вариант невозможен.
Но я понимаю Вас.

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


Проксирование все равно будет запущено через 1-2 месяца.
Нас сейчас интересуют сайты, которые часто взламывают и которые ничего не могут поделать.
Если сайт реально устоит перед взломом, хорошо, если нет, то мы проанализируем как и обучим систему

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

Здравствуйте
Мы не бесплатно всё это делали.
Была потребность в этом у наших клиентов, мы постарались решить данный вопрос.

Если ещё у кого-нибдуь имеется данная потребность, мы так же готовы решить данный вопрос.

Но само собой, мы не предоставляем защиту от ддос-атака.

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

Возможно мы Неправильно понимаем друг друга, но мы защищаем не от ддос-атак, а от того, что клиенты называют вирусами.
МЫ им не даём проникнуть на сайт.
А порой что бы взломать сайт требуется один вредоносный Post запрос, то есть фактически такие запросы не создают какой-то  большой нагрузки на сервер.

У нас не один сервер и если будет наплыв клиентов мы поставим новые сервера

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

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

Здравствуйте
один из примеров того, от чего защищает наша система.
Имеется некий сайт 111.ru, например движок у него Joomla

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

А повторяется это из-за того, что большая часть пользователей не могут найти через что их заражают.

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

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

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

Мы защищаем сайты от взломов.

Да и обновление Joomla до последней тоже не панацея от взломов, так как часто уязвимлсти содержат сами компоненты.

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

Как писал выше, послу установки системы, проблема была решена.

Ранее мы чистили сайты от вирусов, но это происходило до бесконечности.

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

либо даже если они попадут на сайт, мы найдём как это произошло и обучим нашу систему

кто чистить будет?

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

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

Чистить мы будем сами.
У нас имеется не мало наработок в данной области(shell-скрипты для удаления как вирусов, так и shell-скриптов).


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

Мы считаем, что чистить вирусы это хорошо, но сделать так, что бы они не попадали на сайт ещё лучше.

полностью согласен
но!
разве для nginx и apache нет того что вы предлагаете и практически по дефолту, то что предлагают практически сейчас все хостеры, или ошибаюсь 

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

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

полностью согласен
но!
разве для nginx и apache нет того что вы предлагаете и практически по дефолту, то что предлагают практически сейчас все хостеры, или ошибаюсь 

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

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

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

У нас тысячи сайтов.
Вот пример
Например есть сайт 1 и на него была попытка взлома с такими то post запросами(возможно она даже удачно прошла), скрипт обнаруживает данный запрос, сообщает нам.
Мы добавляем сигнатуру и для всей остальной тысячи  сайтов уже такая такая атака не сработает.

Далее есть сайт 500, на него тоже были некие запросы, добавляется сигнатура и вновь подобные атаки не срабатывают уже для всех остальных и так далее.

Чем больше сайтов у нас, тем больше сигнатур добавляем.

Есть некие универсальные сигнатуры, которые подходят для 99% всех сайтов, которые мы добавили изначально

Здравствуйте

Судя по исследованием очень часто шелл на сайты попадают именно через адмику Joomla.

1. Подбирается пароль  методом перебора(у многие юзерей до сих пор стоят очень простые пароли типа admin1 qwerty zaqwsx и так далее)
2. устанавливается компонент через админку, один файл которого является шелом

Судя по исследованием очень часто шелл на сайты попадают именно через адмику Joomla.

сами исследовали  или мысли в слух

сами исследовали  или мысли в слух

----
К нам иногда поступают данные о взломах, мы каждый запрос рассматриваем(так как логгируем все post get запросы) и почти в каждом случае происходит по схеме выше

то что брутят админки не секрет, но утверждать именно попадание в неё не стоит, это больше как ddos получается
тем более сейчас все хоть конечно и не айс но бейсик авторизацию на папку ставят, не айс потому что это Неправильно и она потом о себе знать даст при очередных массовых взломах

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

188.190.99.21 - - [07/Jan/2014:16:51:56 +0400] domain.ru "POST /administrator/index.php HTTP/1.1" 200 570 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/24.0.1309.0 Safari/537.17" "-"username=user&passwd=18121995&option=com_login&task=login&return=&5553b14af0e26b3c07a523fa0a591f31=1
188.190.99.21 - - [07/Jan/2014:16:56:34 +0400] domain.ruu "POST /administrator/index.php HTTP/1.1" 200 570 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/24.0.1309.0 Safari/537.17" "-"username=user&passwd=18121965&option=com_login&task=login&return=&ae8999f3765dd304bc6c90f986eed151=1
188.190.99.21 - - [07/Jan/2014:16:59:12 +0400] domain.ru "POST /administrator/index.php HTTP/1.1" 200 570 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/24.0.1309.0 Safari/537.17" "-"username=user&passwd=18111975&option=com_login&task=login&return=&de682c959ebb27e3aba1aec3bc612f5f=1
188.190.99.21 - - [07/Jan/2014:17:01:02 +0400] domain.ru "POST /administrator/index.php HTTP/1.1" 200 570 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/24.0.1309.0 Safari/537.17" "-"username=user&passwd=18041991&option=com_login&task=login&return=&c4c1dfb3a510186f14e6e231ce860692=1
188.190.99.21 - - [07/Jan/2014:17:10:28 +0400] domain.ru "POST /administrator/index.php HTTP/1.1" 200 570 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/24.0.1309.0 Safari/537.17" "-"username=user&passwd=17031987&option=com_login&task=login&return=&cff4aded21a8e45db1447becf2eb912d=1
188.190.99.21 - - [07/Jan/2014:17:15:02 +0400] domain.ru "POST /administrator/index.php HTTP/1.1" 200 570 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/24.0.1309.0 Safari/537.17" "-"username=user&passwd=17011970&option=com_login&task=login&return=&3792409bdd92e902beefc8acf2e89d0f=1
и таких запросов тысячи на разные домены


Почему мы ведём такие логи и утверждаем, что шеллы  часто попадаю именно так.
1. Логи мы ведём что бы исследовать атаки и вносить новые правила в защиту
2. И по таким логам мы видим как шелл попадает на тот или иной сайт


И назвать это ддос-атакой нельзя, это брутфорс но точно не ддос

да это не ddos это мини нагрузка если на шараде 200 сайтов на сервере и на них на каждый идет по 2000-3000 запросов во время брута для сайта это не ddos а сервер ляжет, некорректно написал не утверждал что ddos но типа ddos получается
на счет логов вы не правы сейчас масса таких брутфорсов было в последние взломы после устранения уязвимостей которые в последние массовые взломы помогли завладеть серверами для проведения этих брутфорс акат но результат не сравнить с ingection, он очень мал в десятки раз, не ту статистики но не более 5-10% подбора пароля потому что после массовых многие меняли пасы на такие что брутить теперь столетиями их придется

----
К нам иногда поступают данные о взломах, мы каждый запрос рассматриваем(так как логгируем все post get запросы) и почти в каждом случае происходит по схеме выше

еще имеет смысл логировать $_REQUEST и $_COOKIE

мы их логи не ведём, но в системе защиты используются правила с cookies, понимаем, что они тоже используются для взломов

еще имеет смысл логировать $_REQUEST и $_COOKIE

вот их и надо логировать, но они утверждают что у них защита и shell не проскочит