Прошу прощения, за отсутствие в теме - в связи со сменой места жительства, некоторое время не мог принимать участие в диалоге.
Как вернулся в онлайн - почитал тему, окинул немного "освежевшим" взглядом и захотелось просто вкратце описать одну ситуацию из недавних событий.
Сайт на WP. Был взломан, с него распространялись вирусы.
После того, как пришла абуза из датацентра, сайт вычистили, однако он был взломан повторно.
Его снова вычистили, в том числе всю заразу, найденную maldet'ом, обновили WP, сменили все пароли, но сайт снова был взломан - снова абузы, снова чистка сайта... и снова взлом, с последствиями в виде попадания сайта в BL, потерей аудитории и т.д. и т.п.
Случай довольно сложный, по сути владельцу требовалось полностью переустановить WP на новом (чистом) хост-аккаунте, потом перенести туда его тему (шаблон дизайна), тщательно ее проверив, подключить плагины, которые ему нужны (да еще и обсудить, а зачем они ему нужны) и всё еще была вероятность повторного взлома (уязвимость могла быть где угодно, включая плагин, тему и т.д.).
Все это довольно объемная работа, которой сам владелец заниматься не мог и не хотел, а нанимать кого-то - либо "студента", который сделает неизвестно что и как, либо достаточно дорогого специалиста, который проверит код сайта вдоль и поперек и скорее всего разместив сайт на VPS, настроит индивидуально средства защиты (тот же mod_sec и т.п.) и врядли даст гарантии.
Владелец сайта купил лицензию phpsec и попросил помочь с обеспечением безопасности сайта, при этом объяснил, что он не программист, не веб-мастер и просто хочет, чтобы сайт работал и на него могли заходить люди.
После установки и настройки phpsec взломы прекратились.
Далее, благодаря фильтрации запросов, был найден плагин (и конкретный его файл) через который, с большой вероятностью и взламывался сайт.
Есть аналогичная история с сайтом работающим на Joomla - там вообще блокировали файлы от изменений посредством "chattr +i" чтобы в конце концов прекратить если даже не взломы, то хотя бы изменение файлов и распространение вирусом. А потом установили phpsec и он также помог.
Есть другие примеры.
В общем, бывают тяжелые случаи, требующие сложных решений. Phpsec был разработан для того, что бы помочь в таких ситуациях, причем в качестве достаточно простого решения. И он помогает.
Да, он пока не идеален и есть над чем работать. Но работу свою выполняет и имеет достаточно гибкие настройки, для того, чтобы можно было
тот же пхпмайадмин и другие веб-редакторы БД добавить в список исключений фильтрации запросов.
А обезопасить сайт даже содержащий уязвимость и уже неоднократно взламываемый - становится проще.
А в ситуациях, когда обновление и смена паролей не помогает, для человека, который никогда не видел консоль SSH, не знает, что такое phpmyadmin и привык просто нажимать на кнопки - гораздо проще.
Так-что отвечая на вопрос, зачем нужен этот "велосипед" - он проще, чем существующие "мотоциклы", не требует "прав на вождение" и позволяет "добраться до места" тогда, когда "мотоциклом" управлять не умеешь, "такси" слишком дорого, а "автобусы не ходят".
Большое спасибо за дельное замечание. Будет добавлено в ближайшей версии (в качестве опции на выбор - фильтровать или отдавать ошибку).
И вообще функционал фильтрации запросов будет существенно расширен, впоть до возможности указать, какие переменные для какого файла не фильтровать (т.е. выборочные исключения) и автонастройки фильтров/исключений для популярных CMS.
Это, а также другие замечания из темы, обязательно будут учтены в новых версиях.
Отдельное спасибо скептикам - Ваши комментарии предоставили достаточно много пищи для размышлений.
Код поведет себя корректно. Фильтрация запросов включает в себя два вида фильтров - "простые фильтры", где "ключевое_слово" заменяется на "ключевое_слово<!--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 можно банально забанить, соответственно нужен целый ботнет - согласитесь, всё это уже само по себе является для взломщика лишними "палками в колесах".
Надеюсь, что смог ответить достаточно развернуто.
В целом, да. Описанные Вами продукты расчитаны на администраторов серверов, phpsec на владельцев сайтов.
Отвечу вот на это. Логи? Да - пишет. Забить диск? Нет - нельзя, лог ограничен по колву записей.
Долбится? Ну да, раз в 3-4 часа проверяет обновления (если включены автообновления). Если положить сервер обновлений - один раз сайт "тормознет" на 10 секунд (таймаут) и всё - следующая проверка через 3-4 часа.
В целом, вижу следующее - есть несколько категорий людей. Есть люди, у которых на аккаунте по 20-30 сайтов с продающимися ссылками и когда взламывается один из них, начинаются проблемы и все сайты перестают приносить деньги. Несколько таких клиентов уже установили phpsec, который успешно отловил запросы направленные на уязвимости и позволил защитить эти сайты.
Теперь, эти сайты работают, приносят деньги и не взламываются.
А есть категория людей, которую можно обозначить как "критики" - что ж, без критиков мир был бы скучным :)
RiDDi, спасибо за интересный комментарий :) Отвечаю по порядку:
Какое же лучшее? Права доступа не помогут, поскольку если файл с разрешением на запуск будет модифицирован, то это будет означать взлом. На большинстве серверов, прав на запуск не требуется, требуются только права на чтение (если говорить о chmod), в общем это не совсем нужная область, тогда же как PHPSECURE нацелен именно на контроль запускаемых файлов, в том числе контроль их содержимого. Никакими грамотными расстановками прав такого эффекта не добьешся.
Это Вы немного выдернули из контекста - я отвечал человеку в ключе "сайты тоже работают на уровне сервера". И то и другое работает на сервере. Да и кстати, у PHPSECURE есть модуль PHP (расширение.so) позволяющее подключать его в обход auto_prepend_file, т.е. по сути именно на уровне сервера.
Начнем с того, что взломать сайт, на котором установлен PHPSECURE в любом случае на порядок сложнее. И если уж сайт будет взломан даже при наличии на нем PHPSECURE (да просто пароль украсть можно с компа владельца сайта), то тут уже так и так ничем не поможешь.
А касательно auto_prepend_file - кусочек конечно лакомый, да только никто не запрещает взломщику подключать свой auto_prepend_file так или иначе и phpsec ему для этого совершенно не требуется.
При этом, хочу обратить внимание, что содержимое выполняемых файлов phpsecure проверяется при каждом запуске, поэтому в случае изменения одного из файлов, он будет попросту скачан с сервера обновлений и восстановлен.
Это не распространяется только на файл, подключаемый непосредственно через auto_prepend_file, поскольку непосредственно для этого файла такая проверка не имеет смысла.
Однако в ближайших версиях, для пользователей с административным доступом, планируется добавление функционала проверки непосредственно в расширение php, после чего, описанная Вами ситуация станет совершенно невозможной.
И повторюсь - phpsecure не делает работу взломщика легче, не дает дополнительых привелегий, зато наоборот на порядок увеличивает защищенность сайта и снижает риск из описанных Вами примеров.
Вопрос немного в некорректном ключе на мой взгляд. Если можно, немного перефразирую:
Изменение опции auto_prepend_file обычно разрешено посредством директивы php_value
При условии, что PHP работает модулем apache (только в этом случае, директива будет иметь значение).
Вопрос - у Вас разрешено использование директив php_value в .htaccess ?
Если у Вас PHP работает не модулем apache, а через CGI - вопрос:
У Вас разрешено использование своей директории cgi-bin ?
Как то так... заранее спасибо всем ответившим :)
Я и не утверждал, что Ваша позиция "опустить". Ваша позиция - недоверие (что вполне оправданно) и огромное вам спасибо за желание разобраться в теме.
Я прекрасно понимаю, что для "не технаря" сама мысль о том, что можно взять и изменить конфиг PHP не спрашивая разрешения хостера выглядит нелепой, тем не менее, обычно, это возможно :)
Что же касается корректности изложения своих мыслей - что ж, прошу простить, вероятно я слишком сильно "технарь" и слишком мало "менеджер", поэтому и разучился корректно излагать мысли человекопонятным языком :)
Хотя, подозреваю, здесь еще и просто вопрос недоверия (типа "да как так, это ж невозможно, а значит он лукавит или неправильно выражается").
Так-что предлагаю просто заказать хостинг (любой какой скажете), предоставить Вам все доступы и проверить.
Либо дождаться, когда появятся "смельчаки", которые установят продукт у себя и отпишутся в теме.
P.S. Первым трем, кто примет участие в тестировании - установит продукт у себя на хостинге и отпишется в этой теме (установился или нет и т.п.), годовая лицензия в подарок.
P.P.S.
Возможно Вы будете удивлены - но далеко не все хостеры сами знают, что возможно, а что невозможно на их серверах. Речь не идет о крупных хостерах со штатном специалистов (хотя и там в саппорте работают не технари обычно, а технари не общаются с "простыми смертными") как не идет о небольших конторах и/или даже частных предприятиях, где за администрирование отвечают понастоящему подготовленные спецы. Речь об арендованных серверах с аутсоринг-администрированием, а таких немало :)
Мне кажется, я предложил более простой вариант - купить любой хостинг (только не дорогой) и проверить :) Либо дождаться, когда в теме появятся небезразличные, кто "рискнет" проверить у себя на хостинге.
P.S.
Так приятно разрушать стереотипы :)
Пусть технари пожалуют конечно, но как можно спорить может оно или не может, даже не попробовав? ;) Да еще и ярлыки навешивать. Фу-фу-фу :) Диванные теоремы. Попробуйте! А потом спорьте :)
Уважаемые технари (да и просто не безразличные), прошу помощи, только не теоритической, а практической - человек не знает, что возможно без участия хостера изменить конфиг PHP, даже если хостер считает, что это невозможно. Я утверждаю обратное.
Мой автоинсталлятор является доказательством моему утверждению.---------- Добавлено 08.11.2014 в 11:54 ----------
Я на этом рынке десятилетие. Продукт исследован и одобрен компанией FastVPS - посмотрите в левый нижний угол SE, там надпись есть Hosted by FastVPS, может быть это Вам о чем то скажет. В целом, Вы можете спросить напрямую у них - исследование продукта производил их системный администратор Павел Одинцов, да и тема ихняя здесь есть, наверное можно пригласить их представителя сюда.
Это на случай, если не доверяете непосредственно мне (меня ведь Вы не знаете - рекламы мы давным давно не даем). Хотя и среди пользователей данного форума есть мои клиенты, которые хостятся у меня годами.
В общем, Ваша позиция мне ясна и она вполне адекватна, но по крайней мере не стоит вешать ярлыки, основываясь лишь на своих предположениях :)
ЗЫ. Готов оплатить минимальный тариф с PHPна любом указанном Вами хостинге или просто перечислить Вам деньги на оплату этого тарифа, для теста.
Проверьте у себя ;) Скорее всего, Вы будете удивлены (да и "хостеры" некоторые могут удивиться). Не забывайте - продукт разрабатывал не студент школоло, а системный администратор с многолетним стажем.
Единицами будут те, у кого на сервере инсталлятор не сможет автоматически сконфигурировать PHP :)
При этом, инсталлятор ничего не взламывает и не хакает, он не лезет в системные файлы, не затрагивает Ваши файлы - сам продукт устанавливается в отдельную директорию, а настройка PHP выполняется, в зависимости от PHP-API (CGI/Apache) либо с помощью опции php_value, либо с помощью cgi-wrapper.
Впрочем, зачем углубляться в технические подробности - просто проверьте :) Для удаления PHPSECURE, достаточно удалить файл .htaccess расположенный в корневой директории Вашего аккаунта, примеры:
/home/login/.htaccess
/var/www/login/data/.htaccess
И директорию с файлами продукта, которая также расположена в корневой директории и имеет название в виде даты установки, примеры:
/home/login/08112014
/var/www/login/data/08112014
Так-что проверяя, Вы ничем не рискуете :)
Автоинсталлятор не сможет автоматически сконфигурировать PHP в следующих случаях:
1. PHP работает как CGI, но у пользователя отсутствуют разрешения на CGI/cgi-bin (в этом случае инсталлятор не сможет использовать cgi-wrapper).
2. PHP работает модулем Apache, но отсутствует разрешение на использование директивы php_value
Обе описанных ситуации встречаются крайне редко.
Я еще и хостер обеспечивающий поддержку более тысячи сайтов.
99% сайтов размещенных на наших серверах используют исключительно и только язык PHP для своей работы (речь не идет о СуБД MySQL и т.п. API, с которыми работают скрипты CMS). Имеется ввиду, что не используются иные языки подключаемые через cgi, например perl, parser и т.п.
Эти языки используют единицы и PHPSECURE не подходит для обеспечения безопасности таких сайтов.
Точно также, как не подходит для обеспечения безопасности сайтов на других языках (ASP и т.д.). Потому он и называется PHPSECURE.
В текущих реалиях, когда все наиболее популярные CMS используют PHP и для их работы совершенно не требуется иных языков выполняемых через cgi-интерфейс, PHPSECURE охватывает основную массу потребителей.
Все ссылки на описание продукта и краткие видео-обзор доступны на Бирже оптимизатора.
Сканер? Например, что бы выяснить, требуется ли чистка сайту.
Насчет правил - правила о рекламе. Создал тему на бирже.
Вы не правильно поняли. Продукт устанавливается практически на любом shared-хостинге, буквально в три клика, причем установка обычно не требует вмешательства хостера, так-что речь идет именно о защите сайтов, а не VPS.
Просто, чтобы было понятно - любой, у кого есть аккаунт на shared-хостинге может скачать и установить продукт, потратив на это не более нескольких минут, в том числе и Вы. Для скачивания доступны бессрочная бесплатная версия и полнофункциональная пробная версия на 1 месяц.
Я корректно употребляю слово сайты. Конечно, продукт работает на уровне сервера - сайты тоже работают на уровне сервера. Помимо изменения в файлах и запуска незнакомых (новых) / измененных файлов, система контролирует также данные, которые передаются сайтам через веб-формы и иными средствами, в GET, POST, REQUEST и даже FILES запросах.
В целом, продукт нацелен именно на защиту сайтов, работающих на PHP.
Если речь идет об идентификации по популярным сигнатурам запускаемых скриптов - такого нет. Сигнатуры создаются системой отдельно, для каждого сайта, в процессе сбора информации о запускаемых скриптах и не передаются никуда, т.е. система собирает информацию локально для хост-аккаунта и использует её непосредственно на этом хост-аккаунте. Похожие алгоритмы реализованы в продукте Agnitum Outpost Firewall, только там контролируется запуск программ в Windows.
Что касается модуля апача - он не требуется. Есть свой модуль PHP (расширение), но этот модуль требуется только в тех случаях, если скрипты на сайте закрыты Ioncube с опцией запрета использования auto_prepend_file
Так-что этот продукт расчитан не на хостеров, а на "end users", т.е. на владельцев сайтов, являющихся конечными пользователями.
К слову о хостерах и защите на уровне сервера/vps - сейчас занимаюсь параллельной разработкой продукта выполняющего аналогичные функции, только в виде Server Wide приложения, по предварительному заказу крупной компании, известной практически любому русскоязычному хостеру.
Здесь уже логика будет по больше части перенесена в модули, управление будет осуществляться непосредственно хостером (владельцем сервера) с дополнительным доступом для клиентов путем интеграции в панели управления.
Но этот продукт - уже отдельный разговор, для совсем другой темы :)
Пример работы фильтрации запросов (проще показать, чем рассказать).
