Компания
493,62
рейтинг
24 апреля 2015 в 11:37

Разработка → Яндекс выпустил антивирус для сайтов — Manul

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

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



Однако всегда хочется лучшего. Одна из главных проблем, с которыми мы сталкиваемся при общении с владельцами зараженных сайтов, — это поиск источника заражения на стороне сервера. У Яндекса, который каждые сутки размечает тысячи сайтов как зараженные вирусом и опасные для устройств человека, есть регулярно обновляемая база вирусов. И у нашей команды появилась идея, выросшая в большой проект, – антивирус для сайтов. Так мы создали Manul, который решили выложить в open source. Это утилита, которая поможет вебмастеру понять, что произошло с сайтом и вылечить его. Под катом я расскажу подробнее о том, как он устроен и какие проблемы решает.

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

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

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



Мы стали думать, как такое можно реализовать. Было понятно, что это должна быть легко устанавливаемая утилита, которая бы не требовала доступа к учетным записям администратора. Так как Яндекс информирует вебмастеров о заражении на их сайте, то будет достаточно, если в случае такого заражения утилиту можно будет быстро скачать и установить, а после окончания лечения – также просто удалить папку с антивирусом с сервера.

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

У Григория Земскова из Revisium был большой опыт сканирования и лечения сайтов на стороне сервера, а также работающее решение — скрипт Ai-Bolit, в который уже была заложена значительная часть желаемой функциональности. Мы объединили наши знания и пожелания, и получилось нечто новое — Manul.

Как это всё работает?


Архив с Manul заливается в корневой каталог сайта — например, через FTP/SFTP, и там распаковывается. Дальше работа с инструментом идет через браузер. При сканировании Manul собирает информацию обо всех файлах, лежащих в корневом каталоге и ниже его, — об их размере, дате последнего изменения, вычисляет хэш-сумму. Параллельно каждый файл проверяется на вредоносность по приложенной антивирусной базе и помечается одним из трех флажков:

  • желтый — в файле присутствует подозрительный код, который по различным признакам может оказаться вредоносным;
  • красный — в файле присутствует известный нам вредоносный код;
  • зеленый — в файле не найдено ничего подозрительного.

Завершив проверку, Manul сохраняет всю полученную информацию в виде XML-отчета. Фрагменты кода — как подозрительные, так и вредоносные — также прикладываются в отчет.



Для просмотра отчета существует отдельный инструмент — Анализатор логов Manul, доступный онлайн. Он представляет отчет в виде таблицы, позволяет отфильтровать файлы по набору таких свойств, как размер, дата изменения и другие, просмотреть фрагменты подозрительного кода. Для различных версий популярных CMS Анализатор автоматически применяет белые списки, чтобы сразу отфильтровать файлы из стандартной комплектации, в которых не было замечено изменений. А нажимая кнопки Quarantine и Delete, расположенные напротив каждого файла, можно сформировать скрипт для Manul, который удалит вредоносные файлы с сервера, а подозрительные поместит в архив для отправки на анализ. Исполнить этот скрипт можно, открыв Manul и перейдя на вкладку Лечение.



Manul не требует доступа к конфиденциальным данным (таким, как пароли). Все производимые с файлами действия контролирует и подтверждает владелец сайта. Чтобы инструментом не смогли воспользоваться третьи лица, при первом запуске его необходимо защитить паролем. Никакие данные о сайте и пользователе при использовании утилиты никуда автоматически не отправляются.

Утилита не требовательна к среде исполнения и рассчитана на то, чтобы запускаться даже на слабых хостингах. Но все же для запуска ей необходимо выполнение некоторых условий: версия PHP не ниже 5.2 и наличие в ней модулей ZipArchive, DOM и XML. Также Manul потребуется доступ на чтение web_root/public_html каталога виртуального хоста

Что же дальше?


Мы решили сделать так, чтобы воспользоваться нашим трудом мог любой вебмастер. Для этого мы разместили наш Антивирус на Яндекс.Вебмастере и теперь всегда будем напоминать о его возможностях вместе с оповещением о том, что с сайт был заражен вирусом.

Однако на достигнутом мы решили не останавливаться. Мы хотим, чтобы у каждого разработчика была возможность не просто воспользоваться нашим Манулом, но и дать ему новую жизнь. Manul — это проект с открытым кодом, который выложен на GitHub. Вы можете принять участие в его развитии, добавить новые возможности или адаптировать исходный код под собственные нужды.
Автор: @tigerunge
Яндекс
рейтинг 493,62

Комментарии (160)

  • –19
    «8M предупреждений» — это сколько?
  • +7
    Без скриншотов суховато как-то.
    • +12
      Спасибо за замечание, скриншоты добавили.
      • +2
        Спасибо.
  • +3
    Круто конечно. Спасибо.
    Но на мой взгляд тут есть серьезная проблема.
    Рано или поздно злоумышленники просто будут подменять файлы Манула и даже возможно появятся трояны, которые смогут при заливке на сервер изменять код Манула на лету.

    Я давно хочу сделать похожий софт, который будет работать на локальной машине и по ssh проверять сервер, файлы, настройки сервисов, логи и т.д. + делать бейкап. Жалко только, что за такой софт денег не платят.
    • +2
      Ну, на самом деле, в качестве упорина — можно взять этот же manull + sshfs :)
      • 0
        Я просто хочу полноценный и крутой инструмент. А у Яндекса есть ресурсы для создания такого, так почему бы и нет. Думаю пользовались бы практически все.

        Минусующие вероятно сочли меня параноиком. Скажу только, что вы совсем мало понимаете в том, что умеет софт, который сейчас автоматически заражает сайты.
        • 0
          Хоть я и не минусовал, но утверждение о непонимании — весьма «агульное». Я, например, как CTO ППР — вполне прекрасно это представляю.
          // более того, кстати, оно умеет и ssh пользоваться с заражённых вендомашин и даже использовать для этого найденные ключи.
          У нас так через одного программиста, который долго сопротивлялся использованию git'а и еле-еле «уговорился» на sftp вместо ftp, было дело перебекдорили все джумлы (благо, это в основном были «сторонние» дружественные проекты), вордпрессы и немного друпалы :)

          // P.S. и да, у меня баттхёрт от вордпрессов джумл и друпалов, используемых на сервисах, при том, что требования «хайлодные». Но я не знаю, что можно сделать в условиях отсутствия финансирования и нежелания редакторского «персонала» обучаться хотя бы маркдауну…
          • +2
            Вас лично обидеть не хотел, никого не хотел обидеть, просто я за дискуссию, а когда негативно относятся и игнорируют — я не понимаю этого совсем.

            Не вижу ничего страшного, в том что бы давать opensource софту свой пароль к серверу, если вы об этом. Но понятное дело, что сохранять пароли и использовать на обычном, «домашнем» компьютере такой софт конечно опасно.

            P.S. Если уж пользуетесь такими редкими терминами в общении, хотя бы пишите их правильно.
            • 0
              Простите :) Я повёлся на белорусские «корни» и при написании руководствовался любимой маминой фразой «аґульная млявасць и абыякавасть да жицця» (не гарантирую орфографическую правильность написания даже с точки зрения белорусского языка, ибо я в нём read-only) и совсем не подумал, что это панславянское слово :)
    • 0
      Ограничение «платят / не платят» находится исключительно в голове
      • 0
        Фраза звучит круто, но смысла не имеет. Вы книги случаем не пишите?
        • 0
          2 уже давно издал. Но там про скорость сайтов, не про образ мышления.

          Когда Вы сделаете бизнес с оборотом хотя бы 10М, то меня поймете.
          • 0
            Поэтому я и не люблю нынешние книги. Пишут ради количества слов, а смысла или совсем нет или очень мало.

            Может быть, вы все же выделите немного своего времени и поделитесь со мной в более простой форме, что хотели этим сказать.
            Я далек до вашего уровня с такими оборотами бизнеса, но очень уж интересно проследить логическую связь.
    • 0
      Бесспорно так и будет, код будет подменяться и никаких предупреждений получено не будет.
      А еще Manul не сможет определить угрозу, которую добавят непосредственно в базу данных, а не в сами файлы сайта.
      Для того, что бы все это определить необходим внешний мониторинг сайта, на который не сможет повлиять злоумышленник. проникнувший на сайт.
      Для своевременного оповещения можно использовать внешний мониторинг сайтов Nazamok.com и уже потом Manul в качестве лечения.
      Nazamok умеет определять следующие вещи, независимо от того, добавлены они в файлы сайта или в базу данных:
      — Несанкционированное размещение внешних ссылок;
      — Любой новый JavaScript и Iframe с вирусом или рекламой;
      — Дорвеи и фишинговые страницы, добавленные на сайт;
      — Изменения в файлах JavaScript, подключаемых к сайту;
      — Воровство трафика с мобильных устройств;
      — Воровство трафика при переходе с поисковых систем.
    • 0
      Нужна консольная версия.
      Тогда можно сделать так. Антивирь кладем в папку, права на запись даем только юзеру manul и в консоли можно будет жить (даже отключив сайт).
  • +6
    Занятно
    Но ребята…
    global $locals, $current_lang;
    

    file_put_contents2($this->configPath , $config_file_content);
    
    • –4
      а что плохого в глобальных переменных с локалью? :)
      • +3
        Это порочная практика
        • +5
          Может мне кто-нибудь расскажет почему это не так?
          • +9
            Не отчаивайся и не обращай внимания на минусы, ты прав. Глобалсы — это действительно зло во плоти, хоть кажется и безобидным.

            Смысла в них нет, просто потому что есть:
            1) Singleton
            2) Registry
            3) Dependency Injection + Ioc
            4) Facade
            5) Decomposition
            6) Traits
            7) Static-классы
            8) Наследование на крайний случай
            9) Наверняка что-то ещё

            Для примера:
            <?php
            trait Locals
            {
              protected static $locale;
              protected static $currentLang;
            }
            
            ....
            class Some
            {
              use Locals;
            }
            


            Каждый «механизм» требует столько же трудозатрат, они не идеальны, у них свои проблемы, но будут в разы лучше и надёжнее, нежели глобалсы, просто наличием контроля и перспектив контроля над данными. А если вспомнить, что старые версии php поддерживают register globals, с помощью которых можно превратить подобную переменную в дыру на сайте — можно будет просто уповать на удачу и внимательность разработчиков в каждой мелочи, когда антивирус не станет причиной «заражения».
            • 0
              Спасибо, я с вами абсолютно солидарен
            • +4
              Ну давайте, расскажите мне, чем статические поля «в разы лучше» глобальных переменных?
              • 0
                Ну со статиками я может и погорячился (т.к. в пыхе нет __get\__setStatic). Так что в данном случае всего лишь в три раза лучше:
                1) Для того, чтоб получить контроль — надо явно подключить «контейнер», т.е. программист по незнанию ничего не натворит.
                2) Повторюсь про register globals (слава всевышнему их уже давно нет).
                3) Наличие Locals, как группы этих переменных — т.е. уже первый шаг к унификации данных, как следствие объектности.

                Это уже не мало. Но никто же не спорит, что статики — это прямо совсем хорошо. Их например тестировать неудобно, да и точно так же их данные можно подменить. Плюс отсутствует возможность создавать инстансы, например объект локали и фоллбека для неё. И проч.
                • –2
                  Пункт 3 на самом деле не относится к проблеме глобальных переменных, ведь условный экземпляр класса Locals точно так же может быть объявлен глобально – унификация есть, хотя глобальная переменная никуда не делась.

                  Пункты 1 и 2 специфичные только для PHP, так что я думаю что ваше утверждение «глобальные переменные — зло» можно свести к «глобальные переменные – зло для PHP из-за пунктов 1 и 2».

                  Согласны?
                  • +1
                    Нет, т.к. мой пример — всего лишь частный случай улучшения данной ситуации (т.е. один из 9 пунктов). К слову, трейты я видел лишь в том же самом PHP. Предлагаю рассмотреть более популярный вариант — синглтон.
                    <?php
                    class Locale
                    {
                        protected static $instance;
                    
                        public static function getInstance()
                        {
                            if (!static::$instance) { static::$instance = new static; }
                            return static::$instance;
                        }
                      
                        // блокируем конструкторы, клонировние и прочее, если надо
                    
                    
                        public $locale;
                        public $currentLang;
                    
                    }
                    


                    Из минусов я наблюдаю только пару:
                    1) — Глобальность объекта в единственном экземпляре (т.е. статический класс почти что)
                    2) — Долго писать: Locale::getInstance()->locale;
                    Что компенсируется:
                    2) + Наличием в языке неймспейсов — можно убрать туда, где он не будет мешаться и сложно будет добраться к нему по ошибке.
                    3) + Возможностью работать с полями, как со свойствами — превращаем public в private\protected и добавляем метод __get.
                    4) + Можем контролировать данные (вытекает и п.3) — например добавить валидацию на язык (чтоб он был только вида [a-z]{2}\-[A-Z]{2}) или если прилетает объект локали — автоматом конвертировать.
                    5) + Можно добавить автоматическую инициализацию, при наличии, допустим $_GET['lang']
                    6) + Eщё туча всего, что можно делать с объектами

                    Это уже заметно более профитный вариант, нежели со статиками и почти что не имеет минусов, от которых можно избавиться с помощью отправки этого инстанса в фасад или Ioc-контейнер приложения.
                    • –2
                      Опять же, первый пункт специфичныя для PHP, все остальные про то, чем хорошо использование объектов, а глобальные переменные тут ни при чем. Я сделаю такой же класс Locale как у вас, только не синглтон, а потом создам его экземпляр как глобальную переменную и получу все ваши «плюсы» в глобальной переменной.
                      • 0
                        Опять же, первый пункт специфичныя для PHP

                        package org;.habrahabr.some; public class MySingleton { private static MySingleton instance = null; public static MySingleton getInstance() { if (instance == null) { return instance = new MySingleton(); } return instance; } }

                        Синглтон всё равно глобален.

                        А в остальном да, тоже самое. Но смысл глобалсов ведь в том, чтоб предоставить единовременный доступ к переменной из любой части приложения, точно так же, как смысл существования синглтона — улучшить глобальные переменные.
                        • 0
                          Если мы говорим о Java, то статические поле точно так же глобально как и ваш синглтон:

                          public static class Environment {
                          
                              public static final currentLocale;
                          
                              static {
                                  currentLocale = new Locale('en.utf-8');
                              }
                          
                          }
                          
                  • 0
                    P.S. пункт 3 относится к глобальным переменным напрямую, но не только к ним. Вариант решения проблемы — префиксы, но это получится просто некая «локальная отсебятина».

                    Пункт 1 возможен не только для PHP. В любом языке, где есть множественное наследование — в PHP просто более элегантный инструмент оного.

                    Пункт 2 — в данном примере — согласен, только для PHP.

                    Я просто не с первого раза понял к чему относится вопрос «Согласны».
                    • 0
                      Разве в PHP глобальные переменные не могут быть объектами? Почему вы рассматриваете глобальные переменные только как набор примитивов? Опять же глобальная переменная $locale типа Locale обладает всеми теми же преимуществами, которые вы приписываете синглтону.

                      Причем здесь множественное наследование? Если я правильно понял, что вы имели ввиду, проблема в том, что разработчик может случайно переопределить глобальную переменную объявленную в другом файле. Такое возможно только там, где глобальный scope глобальный для всего приложения – PHP и Javascript. В остальных языках такой проблемы нет.
                      • 0
                        От этого же никуда не денется проблема переопределения, просто ситуация улучшится. Просто я не представляю в чём тогда смысл глобальных переменных, если у нас и так уже есть нужный объект, который точно так же можно засунуть в другой объект, избавившись от всех проблем, да и ещё плюс добавив возможность автолоада.

                        З.Ы. я не готов рассматривать другие языки программирования, а говорю конкретно про PHP.
                        • 0
                          В других скриптовых языках ситуация не просто улучшится, там такой проблемы не вообще – глобальная переменная объявленная на уровне модуля не явно доступна только внутри этого модуля. Конечно же это не значит, что все можно хранить в глобальных переменных, но там где они удобны их наличие никак не вредит.

                          А я не буду с вами спорить только про PHP, ведь я уже сказал что проблемы специфины для PHP и с ним использование глобальных переменных действительно крайне сомнительно.
                          • 0
                            Думаю стоит подвести итог: В PHP и JS — глобальные переменные — это очень плохой код, в остальных языках — просто нежелательный, т.к. есть альтернативные механизмы, дающие больше контроля.

                            В этом случае Вы меня убедили.
            • +3
              Меня вот этот карго-культ в отношении глобальных переменных забавляет не первый год. Почему вдруг класс со статическим методом getIstance лучше глобальной переменной — для меня загадка. Точно такая же сущность с глобальной областью видимости получается.

              Да, я в курсе про register_globals в php; однако, во-первых, они отключены начиная с PHP 4.2, а traits появились в 5.4.0; во-вторых, глобальные переменные почему-то объявлены злом в миллионе языков без всяких register_globals.
              • –2
                Да просто все запомнили, что «глобальные переменные — зло» и бросаются каждый раз как бык на красную тряпку. А узнать почему они зло, когда они зло и как делать правильно дело десятое.
              • 0
                Я выше уже ответил, но ещё раз повторюсь — основной смысл в том, что над переменной нет никакого контроля, ну т.е. вообще никакого — что хочешь с ней делай. А любой, хоть захудалый синглтон позволит в случае чего понавешать логики, вместо перелопачивания всего кода.
                • +1
                  А на переменную-инстанцию класса какую такую логику нельзя навесить, которую можно на синглтон?
                  • 0
                    Точно такую же можно. Но ту вопрос был про глобалсы и чем они плохи, а не про поля инстансов.
                    • 0
                      Нуу. Можно завести глобальную переменную — единственную инстанцию некоторого класса. А можно сделать статический метод того же класса, который вернёт эту самую инстанцию. В чём разница-то в плане контроля? И так, и так получаешь инстанцию.
                      • +2
                        Для того, чтоб изменить поведение глобальной переменной (во время получения и установки чего-либо внутрь) — требуется исправлять способ получения этих данных везде, где переменная задействована. В случае статического метода — можно поменять способ получения данных внутри этого единственного метода.

                        И так и так получаешь инстанс, да, но в одном месте контролирует язык, а в другом лично, с помощью этого метода. Результат один и тот же, да и код столько же пишется почти что, но с помощью одной этой мелкой замены можно предотвратить возможные проблемы в будущем.
                        • 0
                          Вы сейчас написали «если вместо синглтона потребуется какой-то другой паттерн». Синглтон по определению предоставляет доступ к единственной инстанции безо всяких спецэффектов.

                          Ну и да, глобальная функция с этим справится ничуть не хуже статического метода класса.
                          • 0
                            Возьмём к примеру Yii — там весь фреймворк работает как раз с синглтоном со спецэффектами.
    • +5
      О, там не только это, кратко список проблем:
      1) Именование переменных через андер_скор
      2) Отсутствие области видимости у методов
      3) Переносы строк. Где? Стоит почитать о стандарте php-кода www.php-fig.org/psr/psr-1/ru
      4) Переменные без объявления (!!!) и в ВЕРХНЕМ_РЕГИСТРЕ github.com/antimalware/manul/blob/master/src/scanner/classes/MalwareDetector.inc.php#L20
      5) require github.com/antimalware/manul/blob/master/src/scanner/classes/MalwareDetector.inc.php#L3 Неужели spl autoload уже вышел из моды?
      6) Глобальные функции github.com/antimalware/manul/blob/master/src/scanner/classes/MalwareDetector.inc.php#L8 это ещё было бы нормальным, если бы: а) Они проверялись бы на существование б) Были бы в отдельном файле
      7) Погашение ошибок: github.com/antimalware/manul/blob/master/src/scanner/classes/MalwareDetector.inc.php#L296
      8) die github.com/antimalware/manul/blob/master/src/scanner/classes/MalwareDetector.inc.php#L238
      9) Использование глобальных массивов без проверок github.com/antimalware/manul/blob/master/src/scanner/classes/MalwareDetector.inc.php#L302

      И это только в одном файле. Простите конечно, но так даже в третьесортных компаниях по штампованию сайтиков на вордпрессах не пишут. Это просто невероятно печально.
      • +8
      • +5
        Спасибо за замечания. Сейчас код действительно не написан по единому styleguide'у, но большинство ваших замечаний будут учтены в будущем по мере его облагораживания. Также будем рады вашим пулл-реквестам!
      • +7
        Судя по именованию переменных, и любовь Яндекса к питону, предположу, что код писали питонисты.
        • 0
          Прочитали мою мысль
      • 0
        Вам шашечки или ехать?
        • +18
          А в чём смысл поездки в одну сторону и только вперёд? Зачем писать тот код, который пишется на долгосрочную перспективу, но при этом чтоб его использовать — требуется переписать?

          Просто почему-то новичкам, которые пишут дельные вещи, но при этом в таком же стиле — сливают карму и просто отписываются «RTFM» или «Не надо так писать, это же хабр, многие заходят и учатся по этому коду». А что в этому случае не так?

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

          Так что мне хочется автомобиль, и да, с шашечками по-возможности. Самолично нарисовал парочку списком выше.
          • +2
            Вы не должны помалкивать, просто интонация вашего комментария как-то не в духе сообщества open source. Принято либо молча исправлять недостаки, получая за это почет и уважение, либо, если не можете сделать это самостоятельно или просто нет времени — создать issue с подробным описанием проблемы. Ошибаются все, и на каждого умника найдется кто-нибудь еще более умный — нужно снисходительнее относится к подобным вещям.
            • 0
              Да, приму к сведению, Вы абсолютно правы.
      • 0
        5) require github.com/antimalware/manul/blob/master/src/scanner/classes/MalwareDetector.inc.php#L3 Неужели spl autoload уже вышел из моды?


        Хоть бы R поставили. Вдруг кто на работе читает или в присутствии джуниоров.
        • 0
          Какой «R»? Имеете ввиду, что надо было кинуть ссылку на PSR-0 и PSR-4, и описать как работает функция spl_autoload_register? Честно, не понимаю что вы имеете ввиду.
          • 0
            R (restricted) — прокатная категория, рекомендуемая Американской ассоциацией кино, означающая, что дети до 17 лет допускаются на фильм только в сопровождении взрослых. Как правило, содержат сцены с откровенными элементами насилия или эротики, демонстрацией наркотиков, а также ненормативную лексику.


            Я вздрогнул от буферизации, а не от ручной загрузки, хотя загрузка тоже хороша.
            Буферизация означает, что автор кода не уверен в отсутствии BOM в начале файла и таким образом подавляет возможный вывод.
            • 0
              О, ну раньше там был require, наверное стоило дать ссыль на конкретную версию, а не на мастер.

              В любом случае да, это тоже можно добавить в краткий списочек todo выше.
      • –1
        а чем плох die?
        • +1
          Это не нормальное завершение скрипта:
          1) Это не ошибка (Throwable\Exception\ErrorException)
          2) Это не возврат со статусом ответа (например exit -1)
          3) Это не конец работы программы (окончание выполнения скрипта, последняя его строка)

          Любой программист ожидает, что конец работы приложения будет в том же файле, где и начало, и будет очень сильно удивлён, когда его «echo 42» в качестве теста — не будет работать. А потом обматерившись — обнаружит через пол часа эти злосчастные 3 буквы. И это слава богу ещё исходники очень маленькие. Когда там наберётся хотя бы метр — вот это будет настоящий «ад дебага». =)
  • +2
    Ну вот, теперь ещё и для сайтов появятся подделные антивирусы в стиле «введи ссылку и проверь свой сайт! ой-йой, да на нём же вирусы! Поставь наш бесплатный AntiVirusVasyaWordpress pro и мы вылечим всё».
    • –9
      Напомнили про антивирусы Попова и Бабушкина
    • +3
      Да в 1023 байта и на WCT, если вы понимаете о чем я :)
      • +2
        Ещё и под весёленькую музычку ;)
    • 0
      Для справки. только на одном шаредхостинговом сервере небольшого хостинг проекта с полтыщи сайтов таких «супер-антивирусных-плагинов» (с сами догадываетесь каким функционалом) я выкосил с полторы сотни, неспешно просмотрев каждый вордпресс сайт — его плагины на сервере после миграции хостинг сервера на свежую ос/платформу, когда «удивился» количеству запросов к сайтам, писем от сайтов, и веселенькой нагрузке на sql.
  • +12
    Глянул код, комментариев — ноль,. Даже автогенерируемые в IDE описания методов отсутствуют. Процедура детекции куцая — сканирование стартует только при наличии сигнатуры из списка:
                  '<?php',
                  '<?=',
                  '#!/usr/',
                  '#!/bin/',
                  '#!/local/',
                  'eval(',
                  'assert(',
                  'base64_decode('

    Сразу сходу контрпример — #!/etc/../bin/sh — замечательно работает, а сканироваться не будет. Все хостинги для Битрикс поддерживают короткий тэг <?, которого здесь нет. Упаковка минимально бывает еще и функцией pack(). base64_decode обычно в сайтовых вирусах обфусцируется элементарной str_replace.

    Лимит на файл 1М (выше которого сканироваться совсем не будет) — может и разумно, но вот инжекция в IPB 3.x логи работает и на огромных логах тоже.

    Итого вижу потенциально много false negative ошибок по итогам работы скрипта. И, с точки зрения лечения и поиска заразы, это очень печально. Здесь, как мне кажется, лучше перебдеть (или хотя бы иметь такую возможность).
    • +6
      Мне кажется специально для вас последний абзац поста:
      Manul — это проект с открытым кодом, который выложен на GitHub. Вы можете принять участие в его развитии, добавить новые возможности или адаптировать исходный код под собственные нужды.
      • +7
        Это просто было удивление низким качеством инструмента от самого Яндекса (который собираются предлагать конечным пользователям). И еще показалось странным, что код детекции у фактически антивируса не правился более 7 месяцев. У вас там еще алгоритмически в тесте сигнатуры косяк есть (стал смотреть историю версий и нашел):
                // do scan for all kind of scripts 
                foreach($extensions as $scan_ext) {
                    if (strpos($ext, $scan_ext) !== false) { 
                       $need_to_scan = true;
                    }
                }  
        

        Не хватает break после присвоения (решение уже принято, сканировать дальше ни к чему). Когда в сентябре меняли здесь условие, это не учли (в if интерпретатор сам дальше сработавшего не считал). Аккаунта на гитхабе нет, pull сделать не могу.

        И еще, по детским воспоминаниям о Perl, он бы лучше подошел для такой задачи.
    • +4
      Спасибо за замечание, поправили: github.com/antimalware/manul/pull/51/files

      Комментарии к коду обязательно будут. Что же касается остальных замечаний — приглашаем вас принять участие в развитии инструмента и вместе сделать его лучше :)
    • 0
      Вызовы функций типа 'eval(' запросто могут быть записаны как 'eval (', например.
      Еще вдогонку create_function(), overrride_function() и даже preg_replace() в версии до 5.5.
  • 0
    Попробовал на 3-х сайтах в общем:
    Could not properly handle AJAX request {«readyState»:4,«responseText»:"",«status»:500,«statusText»:«Internal Server Error»}
    Так отчет и не смог получить.
    • 0
      Сообщите нам, пожалуйста, по адресу manulsupport@yandex-team.ru, какой у вас хостинг, какая версия PHP и, если возможно, пришлите вывод phpinfo();. Обязательно разберемся.
      • 0
        Такая же петрушка. Манул помер даже на сайте их трех страниц. На некоторых не помер, но при скачке XML гугл хром тут же блокирует файл (вирус там находит), а манул заново без скана скачает не дает. Замкнутый круг. Как скачать XML с вирусом?

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

        Могу залить чистый манул и дать доступ к сайту.
  • +4
    Вайтлист? Яндекс, ты чего?
    • +2
      Колмановской на них нету.
  • +1
    Похоже, тоже самое, что и AI-Bolit, а значит и обмануть можно так же.
  • +2
    вебшелл WSO пропустил мимо, зато прицепился к чистому ckeditor.js
    UPD: некоторые файлы (плагины) WSO даже зелененьким пометил))))
    • 0
      Мы не стали раскатывать на старте полную базу имеющегося вредоносного кода, но скоро грядет большой апдейт :-)
  • +6
    Этот антивирус нужно будет гладить?
    • +2
      Скорее причесывать.
      • 0
        Я бы поостерегся руку к манулу протягивать…
        image
        • +1
          Это все потому что их не гладили!
  • 0
    Какой хвост нереальный у кота…
    • 0
      Это четвертая лапа )
  • +2
    Архив с Manul заливается в корневой каталог сайта — например, через FTP/SFTP, и там распаковывается

    Там в архиве есть index.php — велика вероятность, что пользователи будут перезаписывать свой index.php тем, что лежит в архиве и потом грустить.
    • 0
      Автор, наверное, имел в виду «каталог/директория/папка (подставить любимое именование) с Manul».
      А вообще, всё намного проще: cd /path/to/site && git clone github.com/antimalware/manul ;)
      • 0
        Много Вам дадут shell и с git на шаредхостинге?
        Для своих сайтов на своих серверах — да, твоя впс/физика — делай, что угодно.

        А вот на запросы шелла на сервер шаредхостинга (не впс) я обычно жёстко говорю «данная услуга (shell) не предоставляется. берите vps». На старом хостинге шелл был, и попытки запустить на нём сервера кантры — меня сначала веселили, но быстро надоели.
        • +2
          Ну если хостинг бесплатный, то конечно там такого не будет (и то не факт). А так, нынче, даже самый дешёвый хостинг, рублей за 50 в месяц предоставляет и ssh, и гит, и много чего другого. Время же идёт, конкуренция и прочее.
    • 0
      Спасибо за замечание. Антивирус должен распаковываться в отдельный каталог /manul, архив уже исправили.

      На будущее встроим проверку на этот счет и подумаем про то, чтобы переименовать файл.
  • +1
    Отработало «красным» на «wget -O bla-bla», однако в моем блоге системные комманды частенько встречаются, т.е. он просто агрится на контент.
    • –1
      А у вас, простите, содержимое блога сохраняется в исполняемых вебсервером/интерпретатором скриптах? Или просто лежит «рядом» с ними? :)
      // Я к тому, что обычно оно лежит в базе…
      • +1
        возможно, что у него кеш в файлах
      • +1
        А зачем хранить содержимое блога _в базе_? Мы с автором Jekyll’а и разработчиками github.io уже довольно давно считаем, что блог в базе — вчерашний день.
        • 0
          обычно

          ;)
          А компиляция из маркдауна в статику это «завтрашний день» и, конечно, хорошо, и я всеми конечностями поддерживаю. Но, увы, я не могу «подопечный» редакторский состав (всяких роскомсвобод, руликсов, пиратмедий и прочего) перевести на его использование. Сопротивляются и всё тут. Привыкли, знаете ли к WYSIWYG-редакторам прямо на сайтах (локальные использовать тоже не хотят) и всяким админкам и прочему. :(
          Ну и им подавай «быстро поднял и начал постить, а не просить техотдел настроить этот ваш гит» :(

          Так что, боюсь, этот «вчерашний день» будет умирать так же долго, как и IPv4 :'(
      • 0
        А вы, простите, про кэш слышали? :)
        • 0
          Слышали. Но мы уже привыкли, что кеширование в файлах средствами самого движка — «немного не то», по сравнению с кешированием средствами opcache, NginX и memcached ;)
  • +1
    С документацией беда, начиная с установки:

    > Как использовать
    > 1. Загрузите Manul в корневую директорию сайта через FTP/SFTP и распакуйте архив.

    wget http://download.cdn.yandex.net/manul/manul.zip && unzip manul.zip
    


    В архиве естественно нет директории manul и все аккуратно(unzip выдает предупреждение о замене index.php) перемешается с файлами сайта. Ни слова про установку прав доступа к файлам.

    Раз уж есть отчет и анализатор, нужно и консольный вариант, желательно в phar, с возможностью вывода отчета в stdout (для упрощения скриптов).
    • 0
      В архиве естественно нет директории manul


      Исправили, спасибо.

      Консольный вариант анализатора пока не планировался, но, возможно, появится в будущем. Также приглашаем вас принять участие: github.com/antimalware/manul
      • +3
        Консольный вариант анализатора пока не планировался, но, возможно, появится в будущем.

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

        1) Если на сайте малваря — первое действие, вырубить vds, сеть и проч., а если нет возможности — хотяб сделать редирект .htaccess'ом на 500 ошибку с сообщением о «временной недееспособности». Чтоб ничего никуда не улетело (особенно персональные данные) — т.е. и отключить ваш антивирус вместе с этим.

        2) Эта утилита для администраторов сайтов, как следствие — смысла в html версии не много. Или есть вариант, что человек, допустим какой-нибудь менеджер будет проверять им сайты, самолично разбираться где ложное срабатывание, а где действительно что-то случилось?

        Естественно — это не абсолют, и даже более чем, но это наверняка целевая аудитория — люди, хоть сколько-нибудь разбирающиеся в вебе.

        Хотя с другой стороны обычно (буду оптимистом) используют git для деплоя, так что даже если и есть какой-то скриптик левый — он будет снесён дефолтным `checkout force`.
  • +7
    Ув. Яндекс, исходный код этого инструмента, документация и способ установки — это очень-очень сильный стыд
    • +1
      • +9
        И что? Мы тут какое-то наклепали, и даже используем и даже клиентам предлагаем. Что там внутри мы не знаем, хотим чтобы вы нам рассказали
        • –5
          нет, не так. А вот так:
          Я считаю, что вот эту, эту и вот эту вещь вы сделали неправильно. Вот пруф. Вот патч, исправляющий это. Спасибо за проект.
          • +13
            Пруфов было достаточно выше.
            Аналогично можно выпустить проект с описанием СуперМегаФреймворк/Антивирус/OS
            и кодом:
            <?php echo 'helloworld';

            Дальше апеллировать, это открытый проект присылайте патчи и недостающий функционал!

            • 0
              Более того, оно частелько так и делается (конечно, не настолько утрированно). И всех всё устраивает :)

              // В конце концов, именно так и начинался Freax (ныне известный как GNU/Linux) ;)
              • 0
                Не хочу прибегать к «начни с себя», но ты почему-то так не делал в своё время ;)
                • 0
                  ты, наверное, отвечал на два уровня выше? :3
                  // потому что недописанные хеллоуворлды я и сейчас стесняюсь выкладывать
          • 0
            Кстати, господа минусующие. Ну, предположим, что моё заминусованное предложение вести дискуссию о качестве кода в вежливом тоне и предлагать пути исправления всё-таки не к месту и нынче «правильнее» говорить «сильный стыд» вместо решения проблемы. Ладно. Ну минусуете коммент. Фиг бы с вами. Но зачем карму-то сливать? Она ж нынче на вес золота :'(
  • +2
    Ребят, большая просьба — прикрутите composer, сделайте release (для stable) и версию «standalone» (для импорта в свои «скрипты» вебмастера/девелопера/etc).
    • 0
      Спасибо за пожелание, учтем.
  • 0
    Could not properly handle AJAX request {"readyState":4,"responseText":"","status":525,"statusText":"OK"}
    


    Стабильно лезет после проверки. На обоих испробованных сайтах.
    • 0
      Если возможно, пришлите нам, пожалуйста, по адресу manulsupport@yandex-team.ru информацию о том, какой у вас хостинг, какая версия PHP и вывод phpinfo();. Будем разбираться.
      • 0
        Справедливости ради, у меня тоже

        Could not properly handle AJAX request {"readyState":4,"responseText":"\nMalwareDetector.inc.php: timeout while scanning /srv/web/s_ppru/sites/pirate-party.ru/www/sites/piratemedia.net/files/styles/article-fon-breakpoints_theme_piratemedia_narrow_1x/public/field/image/8389c7d4c5bd54e21090.png\nTry to increase an interval in settings.\n","status":200,"statusText":"OK"}
        


        Зачем картинки-то целиком сканить? :3
        • +1
          Ах, и да:
          Хотя эта страница и зашифрована, отправленная вами информация будет передана по незашифрованному соединению и может быть легко доступна третьей стороне.

          Вы действительно хотите отправить эту информацию?

          при нажатии на «передать отчёт» :)
          • 0
            Спасибо, исправим.
        • 0
          Картинки проверяются, потому что в них тоже бывают дописаны веб-шеллы.
          • 0
            Ну, тогда и вправду неплохо бы подумать о возможности общесистемной установки и «натравливании» на нужную директорию аргументом. Чтобы, в конце концов, можно было по крону проходить по сайтам :)
  • +1
    Если есть движок поиска было бы неплохо увидеть этот же движок в deb пакете с возможностью запуска для всех виртуальных хостов. Если их с десяток — всем распаковывать?
    • 0
      Вот тоже, сижу, думаю, симлинков понаделать. И закрыть доступ к /manul только паре доверенных IP-адресов из сети.
    • 0
      Спасибо за предложение, подумаем над этим.
  • 0
    Код показался сильно схож с другим продуктом одного из авторов — Григория Земского.
    Для контроля состояния файлов известных CMS всё так же применяются простые контрольные суммы, типа CRC32, которые вирусописатели давно научились подделать и, тем самым, избегать проверки? Это может быть оправдано для экономии вычислительных ресурсов, но может снизить эффективность всей системы.
    • +1
      Код показался сильно схож с другим продуктом одного из авторов — Григория Земского.

      Так один из авторов и есть Григорий, посмотрите файл лицензии.
      • +2
        questor, в комментарии указано, что Григорий является одним из авторов.
        Не возникнет в будущем проблем, что на AI-Bolit получено свидетельство о гос.регистрации, а код очень похож?
  • +1
    Оу, в пуллреквесты — плагин к популярным cms.
    второй — проверку прав доступа — на chmod 777 стоит обращать внимание.
    И третий как уже говорилось комментарием выше — deb/rpm — это была бы хорошая фича для хостинг проектов.
    • 0
      Спасибо за предложения, мы подумаем над ними.
  • 0
    Попробовал на одном сайте, получил ошибку при 'unlink' (см. #54), отчёт отправил.
    • 0
      Большое спасибо!
  • 0
    В общем, есть два пожелания по roadmap проекта.

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

    Одно соображение мы уже высказывали выше — на сервере множество виртуалхостов, не заливать же на каждый сервер, верно?

    Второе замечание касается регулярной проверки. Я не хочу каждое утро начинать с того, что проходить руками по всем сайтам, вбивать пароль и читать отчёты. Регулярный, автоматизированный мониторинг. Настройки в zabbix / cacti / ваша любимая утилита мониторинга.
    • 0
      Спасибо за ваши пожелания, мы подумаем над этим.
  • +1
    Попробовал у себя на чистом сайте, в виртуальной машине битрикса, оказалось php dom xml по умолчанию нету.

    Там внутри есть какие-то завязки именно на php? Может быть есть смысл портировать инструмент на Go и компилировать в статический бинарник — чтобы вообще без внешних зависимостей работал?
    • 0
      Спасибо за замечание. У нас в планах есть уменьшение зависимостей, в том числе и от dom xml.
      • +1
        Собстенно попробовал в двух вариантах:
        1. На VDS с окружением битрикс в его стандартной настройке (такой как настраивает скрипт установки окружения для centos 6)
        2. На виртуальном хостинге

        В обоих случаях скрипт не доработал до конца. Загрузил целиком ядро процессора, несколько минут в таком режиме поработал и отвалился с ошибкой ajax чего-то. Скрипт предложил отправить отчет, я его отправил. Вероятно в отчете информация о системе содержится.

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

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

        Так же посмотрел код проверки. Если я правильно понял, то это код github.com/antimalware/manul/blob/master/src/scanner/classes/MalwareDetector.inc.php и тут ничего специфичного для php нет, никакой сложной логики пока тоже нет).
        Предлагаю портировать инструмент на какой-то компилируемый язык и компилировать код в бинарник для уменьшения ресурсоемкости (go, c++ и т.п.) чтобы его можно было просто применять и в массовых режимах (хостерам) и в режимах виртуального хостинга (запускать как cgi-скрипт). Я бы тоже к этому проекту подключился — мысль такая уже давно есть, пока что пользуюсь для беглой проверки набором грепов. Логика работы примерно такая же, только работает несоизмеримо быстрее.
  • +3
    Как вебмастер и клиент сервиса Яндекс.Вебмастер добавлю свои 5 копеек:

    Узнать о проблеме с подозрением на вирус получается быстрее от клиентов, чем получить уведомления от сервисов Яндекса, т.е. сначала поисковик Яндекса и безопасный DNS Яндекса добавляют домен в черный список, а через часик другой админу сайта приходит email, что есть проблема. Мягко говоря свинство. Благо еще остались понимающие клиенты, которые сообщают администратору о таких проблемах.

    Об SMS-уведомлениях можно и забыть хотя в Яндекс.Паспорте он указан (для оперативности).

    Проблема была с файлом приложения на хостинга (не связанного с исполняемыми скриптами сайта), более того, Яндекс.Диск пишет, что DrWeb проверил и все ОК.

    PS В саппорт разумеется обращался, 18 из 56 тестов показали подозрительным файл (приложение для win) из-за процедуры автообновления. Так что любой архив, любой файл господа администраторы может стать поводом для бана вашего домена по единоличному решению Яндекса.
    • 0
      Используйте сервис Nazamok.com, там можно получать уведомления по смс и не надо ничего устанавливать на свой сервер.
      Производится внешний мониторинг.
      • 0
        Спасибо конечно, но как это защитит от параноидальной проверки Яндекса, ибо по факту ничего достоверно вредоносного обнаружено не было, а стало быть и ваш сервис не оповестит.
        • 0
          Этот сервис оповестит при любых изменениях, производимых на сайте, даже о том, о чем не оповещает яндекс.
          • 0
            он оповещает, но с задержкой по времени и уже после принятых им мер и избежать этого нереально пока яндекс это сам не поправит.
            Проверку хешей каждого файла на хостинге я могу и сам себе написать за бесплатно с уведомлением по sms, но суть проблемы не в вирусном заражении сайта, а в подозрении на вирус по мнению яндекса, т.е. ложной тревоге.
  • 0
    BTW, сам код «не очень», мягко говоря.

    codeclimate.com/github/antimalware/manul
    • 0
      Давно уже заметили, читайте выше.
  • +11
    Карл, они написали антивирус для проверки PHP-файлов на PHP! На PHP, Карл!
  • 0
    А как с обновлениями?
    • 0
      Обновления будут, в ближайшее время приедет большой апдейт.
      • 0
        А как он будет происходить? Заново скачать дистрибутив и базу зловредов?
        • 0
          Да. Manul не предназначен для постоянного нахождения на сайте, поэтому в нем нет автообновления. Мы рекомендуем удалять его с сервера после успешного излечения сайта.
          • +1
            Вот и неправильно. Я жду, что антивирус находится на сайте постоянно и постоянно контролирует наличие вирусов на сайте. Даже странно слышать подобные слова от яндекса, который выдаёт рекомендации веб-мастерам.
  • 0
    И еще
    Шаг 1. Анализ файлов

    Чтобы проанализировать отчет после сканирования:

    Запустите Анализатор логов.
    Запускаю — 404 ошибка.

  • –2
    -Архив с Manul заливается в корневой каталог сайта

    Переименовал ваш index.php на manul.php, запустил его — а ajax обращается только к index.php, а не к новому названию и сразу выдает ошибку.

    Окей, переименовал свой index.php -> index2.php и запускаю index.php который manul.
    В итоге в процессе работы он выдал ошибку, окей хрен с ней, жму наверху «Удалить manul», жду… че-то долго грузится, уже 10секунд прошло.
    Захожу в корневую директорию по ftp — голяк, все файлы стёрты. Кнопка «Удалить manul» удалила не только manul, а всё подчистую.
    Спасибо, Яндекс. Пошел писать тикет хостеру на резервную копию… (((

    Пожалуйста, именуйте кнопки более ответственно.

    update: почитал, оказывается небыло необходимости закидывать в корневую директорию. надо же!
    • 0
      Архив заливается в корневую директорию и распаковывается в отдельный каталог /manul. У вас произошло не так?
      • –1
        -Зачем?
        подумал я, да распаковал архив у себя локально, и просто закинул файлы по FTP, чтобы не напрягая извилины не дергая файловые менеджеры распаковывать архив.

        Вы поймите, я не гоню на вас, сайт всё-равно заброшенный, его уже восстановили. просто так бы сделал другой простой dumb-пользователь, на которых вы расчитываете.
        • 0
          Предложение: на такой случай перед удалением проверять, нет ли в директории manul чего лишнего. И если есть, то не удалять и вообще бить тревогу.
  • 0
    Ребят, начинание отличное, но в результатах бред же, 281 страница подозрений (стандартная Joomla 1.5) и в сниппетах непонятно, чтож ему не понравилось.
  • +1
    Что-то думается мне, что понижая порог вхождения в процедуру «разместить сайт на хостинге и следить, чтоб с ним всё было в порядке» вы не делаете мир лучше.
  • 0
    Попробовал проверить один сайт. Сайт работает на CMS Wordpress, сканирование прошло, никаких сообщений не выдало, в конце предложил скачать отчет. Что настораживает, так это название отчета quarantine.2015_04_24_23_59.zip. Я правильно понимаю, он туда без моего ведома вырезал код? Что значат такие строчки в отчете:
    <file detected="w" snippet="TDk4OiAnXSkgKSA/IHRyaW0oJF9QT1NUWydjb21tZW50J10pIDogbnVsbDsKCi8vIElmIHRoZSB1c2VyIGlzIGxvZ2dlZCBpbgokdXNlciA9IHdwX0BfTUFSS0VSX0BnZXRfY3VycmVudF91c2VyKCk7CmlmICggJHVzZXItJmd0O2V4aXN0cygpICkgewoJaWYgKCBlbXB0eSggJHVzZXItJmd0O2Rpc3BsYXlfbmFtZSAp" pos="2563">
      <path>./wp-comments-post.php</path>
      <size>5007</size>
      <ctime>1429819197</ctime>
      <mtime>1429819197</mtime>
      <owner>user</owner>
      <group>user</group>
      <access>0755</access>
      <md5>91c0d3c3f1d0a5f06ca9b225f966e6a7</md5>
    </file>
    
    • 0
      Предыдущий вопрос решен. Возник вопрос, удаляются все же файлы, или же вредоносный код внутри файлов? Как то боязно удалять файлы.
      • 0
        Manul не вырезает код из файла, он копирует подозрительный фрагмент в отчет.

        Сейчас файлы удаляются целиком, после чего их можно перезалить. Иной сценарий — выяснить с помощью Manul, какой код был дописан в файл, и удалить его вручную.
        • 0
          Спасибо за ответ. На сайте с Jooml-ой вышла ошибка
          Could not properly handle AJAX request
          отправил отчет.
  • 0
    А я было обрадовался, что написали что-то вроде maldetect или аля csf, с картами и ко(. Подобие Ai-Bolit конечно хорошо, но на сервере может быть сотня другая стрых и дырявеньких сайтов…
  • +2
    Мне нравится. Хотелось бы плагин для Wordpress c обновлением.
    И, как узнать о выходе новых версий в текущем варианте?
  • 0
    Три месяца нет обновлений?
    github.com/antimalware/manul

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка