Пользователь
0,0
рейтинг
25 февраля 2014 в 23:51

Разработка → Обнаружение изменений в файлах на веб-сервере

Здравствуйте, уважаемые читатели!

Картинка, кратко и аллегорично передающая смысл описанного в посте скрипта:


У меня есть несколько сайтов, на которых в какой-то момент начал появляться вредоносный код, выглядящий как отдельные php-файлы либо дополнительные строки с длинными eval() в существующих файлах.

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

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

Я слыхал, что есть готовые серьезные решения для этого, но хотелось:
  1. Простого и быстрого в настройке и работе.
  2. Самописного, чтобы немного прокачать мой программистский скилл.


В результате за несколько часов в течение ~недели я написал проверяльщик, который не долго думая назвал Simple File Integrity Checker (SFIC).

Он:
  • прост до необходимого минимума;
  • работает с файловой системой от указанного пути и глубже;
  • проверяет, не изменились ли файлы с момента предыдущего сканирования. Если изменились — отправляет уведомление по почте;
  • позволяет задавать исключения (изменение которых не считается вторжением на сайт) в виде имен файлов, расширений файлов и имен каталогов;
  • может проверять файлы по размеру и дате изменения либо контенту.


Его можно запускать по CRON (у меня запускается каждые 15 минут на каждом сайте) или открывать в браузере.

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

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

Спасибо за внимание!


Дополнение: тема актуальна не только для меня, т.к. в комментах нашлось более проработанное решение того же вопроса (но пока недоступное общественности).
Дополнение 2: в комментах навели на веб-антивирус САНТИ, который помимо проверки целостности файлов делает еще много всего.
Дмитрий @dimonier
карма
10,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

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

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

  • +5
    >Код оформлен так себе.
    Мягко сказано, простите уж за бестактность=)
    И поясните плз юз-кейс, не лучше ли устранить причину (дыру в безопасности), чем бороться с последствиями?
    • –4
      Подобніе вещи можно считать детектором наличия дыры.
    • +6
      К примеру, у компании есть пара сайтов на древней джумле с кучей левых плагинов, каждый существует по принципу «работает — не трожь», и каждый сплошная — черная дыра, искать и устранять причины занятие тут бесполезное. Было принято единственно верное решение — переписать все с нуля. На разработку качественных новых сайтов нужно время, но старые имеют некоторую посещаемость — поддерживать как то надо, а зловреды так и лезут со всех щелей :3, яндекс банит сайты. В короткое время, был написан скриптик по типу как у ТС, который позволил продержаться на плаву, до разработки новых.
      • 0
        Поддержу этот комментарий. Сам с таким сталкивался. Только в действительности оказывается, что «до разработки новых» так и не наступает. Правда мы стараемся держать подобные сайты вообще на отдельном хостинге, мало ли что.
    • 0
      1. Я же предупредил ;-)
      2. Юз кейсы хорошо описаны ниже тут и тут
  • +2
    touch -t200911030000 file.php
    + подгонка файла по размеру под существующий
  • +7
    По моему, без проверки контрольной суммы это всё не очень эффективно.
    • 0
      Да вроде в коде есть узнавание хеша файла
      $fhash=md5_file($filename);
      

      Имхо хеш единственное что надо проверять — сложновато в файл что-то внедрить, чтобы при этом не поменялся md5/sha/итд
      • 0
        И правда есть. Просто в тексте было про размер и дату.
      • 0
        Для быстрого режима достаточно проверять размер. Если изменился, то файл 100% изменен.
        • +2
          Что мешает удалть нужное количество проблельных символов из документа и дописать вместо них скрипт?
          • 0
            Ну это уже ручная работа по сути, ведь нужно чтобы файл еще работоспособным был. Всяким спаммерам и ботнетчикам же не нужно сломать сайт. Нужно закинуть какой-нибудь webshell-скрипт, ну или сделать возможность этот скрипт заливать когда нужно. Основная задача в том, чтобы зловред долго не могли обнаружить.
  • +7
    man inotify
  • +14
    а не пробовали парсить svn/git status?
    проще и надежнее
    • 0
      Мне кажется человек просто не очень знаком с VCS.
      Тут давеча пробегал пост, кажется ребят из Селектела (ну если нет, то думаю amarao меня поправит) про то как они серверные конфиги в гит кладут.

      С успехом юзаю данную идею — всё критично важное в гите и синкается с внешним сервером, мне кажется это маст хэв даже для проекта размеров визитки.
      • 0
        по сути весь топик из области XY Problem. грустно когда разрабов нагружают задачами администрирования. проблемы недофинансирования в малых проектах многим известны не понаслышке.
    • 0
      Не пробовал, т.к. не умею.
      Вчера в первый раз воспользовался git, когда выкладывал код.
      • 0
        Попробуйте и не изобретайте костыли.
  • +9
    А почему файлы доступны для изменения кому попало? Если есть проблемы — положите на раздел в RO, ни один хаккер без рутового доступа ничего вам там не поменяет даже при большом усердии. А с рутовым доступом ему ваши похапе-файлы до лампочки будут.
    • 0
      Зачастую два раздела (разве что своп не считая) непозволительная рокошь. Плюс есть файлы, которые веб-сервер должен писать. Ну и деплоить от рута надо будет.
    • 0
      Сайты на shared хостинге.
      • +1
        Отличный повод завязать с shared-хостингом?
        • +1
          Если человек любит молоко, ему обязательно заводить корову? ;-)
  • +1
    tripwire не слышали?
    • 0
      О, какая ностальгия. А что, проект еще живет и развивается?
    • 0
      Да, классика,
      А еще есть aide. И события фс. А они очередной велосипед придумывают.
  • 0
    Чего люди только не придумают лишь бы на картошку не ехать.
    Готовых инструментов для контролирования целостности файлововй структуры вагон и маленькая тележка. Часть из них даже стоит по дефолту в некоторых дистрибутивах.
    Это как сказали выше и tripware и aide и так далее
  • +1
    Если бы вы хотели скилл прокачать то взяли бы лучше компилируемый язык типа Go или C. Сторадж вроде редиса или монги.
    И запилили бы индекс по файлам с хэшами. Обернули бы всё это в .deb и .rpm.

    Вот вам мысль облеченная в апи бинарника:
    sfic add /etc/nginx
    sfic add /home/www/project
    sfic verify
    • 0
      А на PHP (а лучше на nodejs, мы же скилл качаем) запилили бы веб-интерфейс и научили бы бинарник синкаться на мастер сервер. И получился бы у вас такой клиент-серверный мониторинг за состоянием файлов.

      Оповещения через SMS гейты бы прикрутили, email-спамилку… Ну короче вы поняли — можно было бы немного помасштабней. Для прокачки скилла самое оно если терпения хватит. А там авось и команда подберется и сообщество оценит и ваще success open source story :)
    • 0
      Чтобы это сделать, мне попутно еще нужно будет скилл общения с Linux на порядок прокачать ;-)

      Ваше предложение, насколько я понял, будет работать на своем сервере, а у меня shared хостинг.
      • 0
        Сейчас самая задрипанная виртуалка стоит дешевле shared хостинга.

        Две первые ссылки которые возникли в голове, без вского умысла и рекламы:
        www.digitalocean.com/
        www.clodo.ru/
        • +2
          Виртуалки предполагают на уровень выше навыки администрирования.
          • 0
            В сети сейчас столько мануалов и документации что с нуля до вменяемого уровня можно за 2-3 месяца поднять скилл. И наслаждаться полным контролем над проектом.

            Мы ведь говорим о том что бы делать хорошо? Или о том что раз уж скилла не хватает, то давайте смиримся с этим и будем лепить очередное говно? Мы же не хотим расти, развивать рунет, ага…
            • 0
              Зачастую администрированием подобных проектов занимается разработчик в силу того, что у заказчика нет средств на оплату услуг администратора (варианты, когда разработчик просто дурит заказчика, заявляя что является профи и в администрировании, беря соотвествующую оплату, не рассматриваем), но отказаться от администрирования значит потерять клиента. Тут уже стоит вопрос бизнес-стратегии — окупятся ли инвестиции (как минимум времени) в повышение качества дополнительных услуг и как скоро, или лучше инвестировать ресурсы в основные услуги.
              • 0
                судя по количеству вакансий которые мимо меня в Киеве пробегают с хорошей оплатой и другими плюшками администраторам Linux, которые умеют готовить web&hiload, я думаю что этот набор знаний окупится за пару месяцев.
                • 0
                  Вряд ли речь идёт о хайлоаде в контексте шаред-хостингов :)

                  Ну и ещё администрирование может быть банально не интересно по сравнению с разработкой. Одно дело терпеть немного администрирования ради возможности заниматься разработкой, а совсем другое отдаться ему полностью.
                  • 0
                    ну сразу на толстый хайлоад врядли кто-то пустит, а начинать то с чего-то надо.
                    свой сервер в этом плане даже лучше — всякие nginx, memcache и т.п… А там и скиллы поднимутся.

                    Я ведь тоже не сразу админил win-домен на 500+ человек.

                    начинать можно с малого.
                    • 0
                      Можно, но нужно ли? Собственно если бі какой разработчик спросил меня как ему лучше стать админом, то подобній сценарий я бі ему и посоветовал.
                • 0
                  У разработчиков ЗП всяко больше.
  • +3
    Вообще странное решение. git status разве не решает проблему?
  • +1
    А зачем кстати делать изменение слэшей в путях? Винда же понимает любые, в любых комбинациях, так что все пути можно в линукс стайле писать.
  • +3
    На самом деле проблема актуальная. Большинство сайтов хостится на shared без всякого shell и дополнительных прав. Их периодически взламывают и они очень бы хотели как можно быстрее узнавать о таких проблемах. Меня тут попросил один из клиентов поискать что-нибудь для этих целей, но я что-то ничего подходящего не нашел. Поэтому взял и написал такой инcтрумент сам, используются PHP +AngularJS + MySQL, open-source + MIT License. Клиент вроде доволен. Напишу документацию и выложу все на github.
    Скриншот
    • 0
      Зачем лечить симптомы? Нет возможности править дырявый код, значит надо сделать так чтобы уязвимостью невозможно было воспользоваться. Не думаю что простенький VPS стоит намного дороже shared hosting. Не можете сделать второй RO раздел — отнимите права на запись у пользователя под которым веб сервер крутится. Смысл перезаливать скомпроментированные файлы если их тут же ломают?
      Время, затраченное на хождение по кругу, обойдется вам дороже чем самая дешевая виртуалка. Отвлекает от работы над новым проектом. Вероятность не только кражи данных, но и полный вайп базы. Нагрузка на процессор, повышение disk io в условиях shared hosting, вы покажите нам метрику загрузки страниц в час пик.
      • 0
        Вы внимательнее, пожалуйста, читайте о чем я говорил. Есть какая-нибудь компания с сайтом за 20-30 тысяч на 20 страниц, у них даже программиста нет. На кой хрен им VPS? Но по разным причинам их иногда взламывают, после чего Google и Яндекс выкидывают из поиска. Вот им и нужно вовремя обнаруживать все изменения. А такие мелкие сайты как правило взламываются в автоматическом режиме ботами и нечасто, так что вполне себе метод.
        Вы конечно у себя можете навешивать любую защиту, но все равно 100% не будете защищены от взлома. Элементарно, например, могут увести пароль на FTP с компьютера.
        • 0
          Да, вы совершенно верно описали ситуацию.
          Спасибо!
        • 0
          конечно, лучше лечить симптомы а не болезнь.
    • 0
      О, ваш продукт весьма похож на мой скрипт, только более красив и удобен в администрировании.
      На shared веб-хостинге будет работать?
      • +1
        Да, в любую директорию залить, открыть в браузере, указать настройки MySQL, свой пароль и все. Единственно, при установке, если shared не дает выполнять create table, то придется вручную импортировать .sql файл в phpmyadmin.
        • 0
          всегда задавался вопросом — зачем файловой структуре (вы же проверяете именно файлы) MySQL? может проще\лучше использовать что-то вроде sqlite или свое хранилище (как, например, это делает автор Sypex)? библиотека для php есть в 99.9% на хостингах, а в случае своего хранилища — так вообще 100% переносимость. Или хотя бы предоставить выбор. Структура базы кардинально не изменится и, как мне кажется, переносимость 100%
    • 0
      Выложили Watcher4site в открытый доступ под MIT лицензией. Система отслеживает изменения файлов на веб-сайтах. Требуется PHP и MySQL. Сайт www.novostrim.com. Исходники доступны на github.
    • 0
      del
  • 0
    То есть по вашему компания может себе позволь выпасть из индекса, потерять рейтинг; а вот тысячу в месяц на хостинг увы никак? Потери от упущенных возможностей вы учитывете?

    Имхо от таких клиентов надо бежать, причём не просто бежать, а менять телефон, почту и фио, чтоб наверняка вас больше не нашли. Ибо 30 тысяч за 20 страниц их разработчик выбивал в течении года. А последующие пять лет на стену лез от звонков с требованиями быстренько поправить вот тут и там, причём за бесплатно, потому что «мы же тебе заплатили (аж 30 тыр!!!), свинья ты неблагодарная»
    • 0
      Вы в реальности работали с мелкими клиентами? Делали им сайты, обслуживали их? Вы в курсе потребностей и забот регионального мелкого бизнеса? Да, они не готовы выкладывать за сайт из 20 страниц 100 тысяч, у них нет возможности нанимать кого-то, кто установит и настроит им VPS. Они мало понимают в Интернете и ИТ, но они вполне адекватные люди и придурков среди них не больше чем среди программистов.
      • 0
        Ну так консолидируйте своих клиентов. Возьмите в аренду полноценный сервер. Настройте все по человеческих. Стоимость аренды + вам на пиво распределите между клиентами. Вот вам shared environment с полным контролем. И не надо будет костыли подставлять.
        Не хотите, гемороя много? Так это отдельный разговор.

        Вот вопрос по вашему продукту: может вместо постоянной проверки даты, чексум и прочего; вы 2-3 раза в неделю по фтп весь сайт обновляйте? По сути эффект тот же при меньших затратах.
      • 0
        Я работал с мелкими клиентами.

        Они легко поддаются на хостинг проектов на вашем сервере и плату 30$/год. Берем хотя бы здесь (http://www.host1plus.com/vps-hosting/) — VPS по 2$/мес или по 1.5$ если платить сразу за год.

        Окей, давайте теперь прикинем что мы получим:
        — Полный доступ к серверу по SSH, что открывает не ограниченные возможности по перемещению, упаковке, развертыванию и любым другим манипуляциям с сайтом
        — Любые на вкус и цвет инструменты и языки программирования
        — Опять же Git, который решает проблему с определением какие файлы были изменены и сиюсекундным восстановлением предыдущей версии

        Конечно же от вас требуется начать разбираться с новыми для себя явлениями, как Linux, командная строка, SSH, Git. Но. Это окупится со временем слихвой.

        Если бы я сейчас вернулся бы к работе, как фрилансер — только работа с Linux + Git. Никакие shared хостинги не заменят полноценный доступ к серверу.
        • 0
          Для меня лично дело в другом. Свой хобби-проект я подниму на ВДС-ке без проблем, как говорится, с закрытыми глазами. Но это лично мои риски, если я что-то где-то неправильно настрою. Но оказывать платные услуги в области где я себя не считаю профессионалом (а в администрировании я себя таковым не считаю) как-то неправильно что ли. И ладно бы речь шла о том, что неправильно настроил размеры кэшей и буферов и поэтому меньшую пиковую нагрузку сервер может держать, но речь ведь о безопасности клиентских данных прежде всего. Я вот вообще не знаю какие виды атак могут быть на ssh или http, соотвественно не знаю как от них защищаться.
        • +1
          Риски выше, как уже правильно выше сказали — за бекапы данных клиента отвечаете теперь вы лично, а не хостер, нужно следить за серверами, аптайм, обновления, пиковая нагрузка, мониторинг и техподдержка и т. п. Я всецело за виртуализацию, но нужно ещё развивать культуру администрирования Linux в России, а с этим у нас пока туговато. Стоимость VPS как бы подоспела, а вот клиенты и администраторы не все к этому готовы: кому-то некогда, кому-то лень, кому-то не хватит знаний. Обучение MS Paint в школах и MS Word в университетах особенно способствует этому.
  • 0
    Знакомая ситуация и ничего не поделаешь: на виртуальных хостингах порой не то что отсутствует git/ssh, даже cron отсутствует.

    Довольно часто причиной такой печальной ситуации являются банальные вирусы у клиентов, имеющих доступ к сайту по фтп. Те в свою очередь в автоматическом режиме могут имплантировать в php-файлы рекламу вплоть до банальной дозаписи в конец index.php рекламного баннера. Костыльное решение — удалить ?> в конце всех php файлов иногда спасает. Но лучше — вообще огородить сайт от «клиента».

    Правда, попадаются умные зловреды, которые ещё и htaccess нужным образом подправляют. В вашем скрипте проверки на «левые» .htaccess и вообще на наличие новых файлов я не нашёл — так что возьмите на заметку — может пригодиться. Вектор атаки через htaccess прост: создаётся новый php-скрипт, на который делается htaccess-перенаправление со всех страниц. Старые файлы не тронули и черное дело сделано.

    По делу — git/svn/php — это не очень серьёзно. Есть опенсорсная система обнаружения вторжений: AIDE. Для пущей гарантии сам верификатор и контрольные суммы должны храниться на внешнем носителе — флешке например. Ибо одна строчка alias git=: — и вся защита полетит.
    • 0
      По делу — git — это не очень серьёзно

      Что, простите?

      Ибо одна строчка alias git=: — и вся защита полетит.

      Что, что?

      То бишь вы на полном серьезе полагаете что человек обнаружив что git не ссылается на бинарник заплачет, встанет и уйдет? :)
      Набрать /usr/bin/git status не судьба? Ну или грохнуть .bashrc?
      • 0
        Что, простите?

        Я согласен, что деплоить приложение путем git pull, а проверять целостность путем git status несерьезно.
        человек обнаружив

        Как человеку в голову такая мысль может прийти?
        • 0
          Эээ… Кто-то что то говорил про git pull? Тут лишь вопрос в том что на сервере есть git реп который выполняет очень тупую функцию — обнаруживает изменения файлов и только — больше у него нет предназначений.

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

          Про мысль — не совсем понял. Поясните?
          • 0
            Даже если держать реп на сервере, то задвать там док-рут не самая удачная идея по-моему для продакшена. Или я вашу мысль не понимаю и вы про образцовый «снэпшот» с которым производится сравнение приложения? Так да, неплохой вариант.

            Ну вот пишу я git status — изменений не вижу. Как мне должна прийти в голову мысль, что git это алиас, или что path изменён?
          • 0
            >обнаруживает изменения файлов и только — больше у него нет предназначений.

            man 7 inotify

  • 0
    Есть куда лучше штука… События файловой системы…
    • 0
      Проблема не в том, что есть штука лучше. Проблема в том, что никто на гитхаб её не выложил.
  • 0
    для информации. есть альтернатива habrahabr.ru/company/santi/blog/202976/ для мониторинга хватает.
    • 0
      Спасибо! Добавил ссылку в топик.
  • 0
    Хм. В принципе есть такие вещи как подсчёт контрольных сумм/хешей всех файлов, как это делают антивирусы.
    Никто не мешает делать «слепки» после каждого коммита на сайт новой информации и проверять их с последним предыдущим слепком.
    Учитывая что контент в основном пишется в БД, то должны добавляться только файлы вложений
    • 0
      Файлы кэша ещё как минимум. Конфиги.
      • 0
        я не говорил что считать надо только файлы /var/www
        многие кто это делают делают полный слепок хоста. С виртуалкой это даже немного проще, т.к всё важное можно хранить уровнем ниже, на хосте
        • 0
          Я про то, что нужно игрорировать изменения не только в аплоадс, но и в других каталогах.

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