Инструмент для защиты сайтов - Ваше мнение?

Ну это-то понятно и из объяснений ТСа.

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

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

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

О! О такой технологии (способе) контроля файлов я периодически говорю уже 3-е десятилетие и почти удивляюсь, почему это до сих пор не было реализовано другими мониторингами :) Сие же есть просто и замечательно. Да, замечательно, если бы не одно "НО" - доверие ЦА со многими вытекающими. Я бы себе ни за что не поставил продукт непонятно от кого, да ещё и закодированный. Сертификация? Как бы да, повышает доверие, но для меня всё равно ничего не значит. Не говоря уже за доп. расходы разработчиков.

С другой стороны - существуют же всякие сервисы, предлагающие свои исп. коды и получающие доступы к серверам клиентов (чит: клиент добровольно устанавливает шелл). И не только существуют, но и имеют достаточное кол-во клиентов (пока имеющие ;))

Эт я, собсно, к чему - к главному вопросу ТСа о целесообразности продвижения этого продукта. Казалось бы, тут ЦА понятна - люди, краем уха слыхавшие о безопасности, но не понимающие и\или игнорирующие даже основы оной (ака "не тянуть в рот всякую неизвестную гадость"). Но поскольку большинство спецов, мягко выражаясь, не будут поддерживать такой продукт (к тому же платный) для популяризации его в ЦА понадобятся огромные ресурсы, что вряд ли станет оправданным.

В целом, да. Описанные Вами продукты расчитаны на администраторов серверов, phpsec на владельцев сайтов.

Отвечу вот на это. Логи? Да - пишет. Забить диск? Нет - нельзя, лог ограничен по колву записей.

Долбится? Ну да, раз в 3-4 часа проверяет обновления (если включены автообновления). Если положить сервер обновлений - один раз сайт "тормознет" на 10 секунд (таймаут) и всё - следующая проверка через 3-4 часа.

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

Теперь, эти сайты работают, приносят деньги и не взламываются.

А есть категория людей, которую можно обозначить как "критики" - что ж, без критиков мир был бы скучным :)

понятно. то есть на критические проблемы отвечать не принято :)

буду в лоб:

как ваш код поведет себя в содружестве с форумом программистов, где написание запроса или ПХП кода - нормальное дело?

Правильно ли я понимаю, что юзеру просто не положено иметь пароль вида "select * from hubbabubba;"? Так как ваш скрипт его просто будет херить.

какой логин будет у пользователя, если при регистрации он укажет в качестве логина "eval()" и существует ограничение движка на длину логина 16 символов?

критерии фильтрации вообще непрозрачны, поэтому это тыкание пальцем в небо.

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

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

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

Код поведет себя корректно. Фильтрация запросов включает в себя два вида фильтров - "простые фильтры", где "ключевое_слово" заменяется на "ключевое_слово<!--PHPSECURED-->" и регулярные выражения, где можно указать что заменить и чем заменить. Предполагаю, что админ форума программистов знаком с регулярными выражениями и даже в том случае, если форум будет отображать <!--PHPSECURED--> как есть (т.е. если html-комментарий не будет восприниматься комментарием и будет выводиться на страницу, то админ форума сможет перенести все "простые фильтры" в регулярные выражения, заменив <!--PHPSECURED--> на какой либо BB-код, например на пустой код типа [ b ][/ b], который не будет отображаться в тексте (заменяясь на <b></b>) и таким образом не будет портить цитаты кода - цитируемый код при копипасте будет рабочим.

Ответил немного сумбурно, но надеюсь мысль ясна.

Понимаете не правильно. Если юзер укажет пароль вида "select * from hubbabubba;", то его пароль может быть преобразован, например, в "select<!--PHPSECURED--> * from hubbabubba;". При этом, каждый раз, когда юзер будет вводить пароль при авторизации, пароль будет преобразовываться, таким образом для юзера он так и будет выглядеть как "select * from hubbabubba;" и будет рабочим.

Что же касается логина - это зависит от модели поведения движка. Если движок будет выдавать ошибку при попытке ввести логин длиннее 16-ти символов, то соответственно возникнет ошибка и юзеру придется использовать другой логин (что не является катастрофой, на мой взгляд). Если же движок будет обрезать все лишние символы, то логин в базе будет сохранен как "eval<!--PHPSECUR", что конечно не есть хорошо, но опять же не является катастрофой и легко решаемо (например изменением шаблона замены с <!--PHPSECURED--> на <!--!-->.

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

Критерии фильтрации могут редактироваться самим пользователем. SQL-запрос без пробелов, это конечно сильно, но мне сложно судить об эффективности не имея перед глазами примера такого запроса являющегося инъекцией.

Лог имеет ограничение как на количество записей (этот пункт настраивается), так и на длину данных, записываемых в лог. При этом в лог пишется не весь запрос, а непосредственно имя и содержимое той переменной, которая была подвергнута фильрации. При этом пишется содержимое переменной ДО и ПОСЛЕ срабатывания фильтра, т.е. что и чем было заменено. Туда же пишется к какому файлу был адресован запрос, IP-адрес с которого пришел запрос и дата/время.

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

Надеюсь, что смог ответить достаточно развернуто.

мысль ясна, но не ясна цель этого велосипеда.

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

это уже зависит от последующего использования пароля.

к примеру, если я в АПИ использую контрольную сумму в виде хэша от строки с паролем и данными, то хэши всегда будут неправильными.

это является катастрофой ибо ваш механизм искажает входные данные.

это же касается имейлов, содержащих ключевые слова. куда код активации, уведомления слать будете? на деревню дедушке?

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

ему проще и правильнее тот же вордпресс просто своевременно обновлять.

тогда как вы вообще определяете, что заменять, а что нет?

такое мыло вы тоже наверное испортите? selector@insert.com

вот вам переменная с инъекцией и 8 мегабайтами мусора

?name=%27%20union%20select%20*%20from20users/*..8..megs..of..trash..*/

если надо - могу мусор вставить до запроса.

Какая наивная вера :)

Чо, правда? ;)

Выходит и кириллица в логинах не допускается? (или ограничивается до 5 симв?)

Не хочу верить, но у меня сложись впечатлении, что "метод" удлиняет гет-запрос, искажает его. Так ли это?

Т.е ЧПУ поломается, а из запроса в 254 байта тупо потеряется кусок?

Как же так далёк от реальности... Воспользуйся что ли гуглом... Да даже банальный ТОР начинающих кулцхакеров обходит такую защиту, чего уж говорить о более проф. ломателях.

это ж было понятно из скринов на второй странице :)

ЧПУ отработает раньше, если оно на уровне хтацесс разруливается, а не движком.

к тому же не ясно, как обрабатываются кастомные форматы передачи переменных.

например xml или json в POST,

или в тех же урлах: //site/page?param-value/param-value/param-value/

анализирует ли содержимое загружаемых файлов? там же тоже могут быть шеллы в картинках.

если да, то что, так же похерит картинку из-за случайно встреченого ключевого слова?

Были скрины? О_о. Точно. Я что-то их только увидел (мб не отобразились когда тогда читал страницу).

Тогда алес..

Но так далеко не всегда. Тот же ВП например.

Более корректное поведение, в случае срабатывания фильтра, всё же, как и в ModSecurity, выдача кода ошибки и не выполнение кода, чем потом вебмастеру <!--PHPSECURED--> из базы вычищать.

да, реально. вордпрессу скорей всего дойдут уже искаженные урлы :)