Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
А есть ли в природе какие либо программы (shell/bash/perl скрипты) для анализа популярных CMS на предмет сверки того что на сайте с эталонным архивом этой CMS по контрольным суммам?
Я это к тому, то если откинуть факт модификации исходных файлов установленной CMS самими разработчиками сайта, то зная версию CMS можно сравнить основные файлы с эталонными на предмет различий. Конечно если CMS нашпигована плагинами + менялся код, то тут все сложнее.
Я это к тому, то если откинуть факт модификации исходных файлов установленной CMS самими разработчиками сайта, то зная версию CMS можно сравнить основные файлы с эталонными на предмет различий. Конечно если CMS нашпигована плагинами + менялся код, то тут все сложнее.
Если CMS оформить например в виде docker-контейнера, то там нет никаких проблем откатить систему к исходному виду.
Если после настройки сайта положить его под git (или другую систему контроля версий), то git status быстро покажет все изменения. В некоторых CMS есть встроенные механизмы контроля за изменениями системных файлов (ядра CMS). Также можно поискать плагины для своего "движка", они делают эталонный слепок файловой системы и регулярное слежение за изменениями файлов и их атрибутов.
При желании можно найти системы контроля целостности под ваш сервер или установить хостовую систему обнаружения вторжений (HIDS), одним из элементов которой является integrity checker.
При желании можно найти системы контроля целостности под ваш сервер или установить хостовую систему обнаружения вторжений (HIDS), одним из элементов которой является integrity checker.
git как раз и используем на своем хостинге для контроля за особо важными сайтами, но для того же netcat к примеру, где почти вся рабочая часть php-кода в БД такой финт с git не сильно прокатит, а делать каждый день dump БД и ложить его в тот же git — сомнительно в плате контроля, будет огромная мешанина php-кода и sql кода.
Кладите только таблицы со скриптами в дамп.
Обновите уже неткат. Там давно уже не так.
Мы то с радостью бы обновили, но клиенты не хотят за это платить деньги и сидят на старых неткатах аж еще версии 2.2. Так что работаем с тем что есть.
Ну, собственно, это одна из причин, по чему ломают сайты. 2.2 — этому релизу уже лет 10. Не хотят обновляться до свежих версий.
Хотя стоит это смешных денег.
Хотя стоит это смешных денег.
Не знаю как там в Неткат. Но в 1С обновление с 7.7 на 8.х стоит безумных денег. И не потому что лицухи новые нужны, нет. И не потому что данные надо портировать, нет. Данные более-менее автоматически можно портировать. Просто уж очень много у людей которые всё еще (за столько лет то) не перешли — уж очень много собственной бизнеслогики. Плагинчики всякие, собственные документы, бизнеспроцессы и т.п… Повторюсь что не знаю Неткат, но судя по вашему обсуждению о том, что архитектура другая и т.п., думаю переход на свежак будет с потерей совместимости…
Нет, неткат очень хорош тем, что вы можете обновиться с 2.2, которой уже 10 лет, то свежей 5.7 и у вас ни чего не должно сломаться. При условии, что в исходный код не вносили изменений.
Т.е. все это время поддерживается обратная совместимость. А продление техподдержки на 2 недели (как раз, чтобы обновиться) стоит 25% от стоимости лицензии (от 1500 до 10 000 где-то, в зависимости от редакции) Т.е. если у вас сайт для бизнеса, то такая экономия — это обычное жлобство, которое потом выливается в гораздо большие траты.
У меня прямо сейчас есть клиент, у него сайт — дырявое решето, которого хостер блокирует за вредоносную активность каждую неделю. Каждую неделю регулярно начинаются простои, при этом сайт — центральный элемент бизнеса, он продавать должен.
На мое предложение взять и все сделать заново (единственное верное решение для того, что там есть) клиент думает уже месяц. При этом я понимаю, что он судорожно ищет где это сделать подешевле. И также понимаю, что с таким подходом он будет продолжать страдать и бизнес загнется все равно.
Т.е. все это время поддерживается обратная совместимость. А продление техподдержки на 2 недели (как раз, чтобы обновиться) стоит 25% от стоимости лицензии (от 1500 до 10 000 где-то, в зависимости от редакции) Т.е. если у вас сайт для бизнеса, то такая экономия — это обычное жлобство, которое потом выливается в гораздо большие траты.
У меня прямо сейчас есть клиент, у него сайт — дырявое решето, которого хостер блокирует за вредоносную активность каждую неделю. Каждую неделю регулярно начинаются простои, при этом сайт — центральный элемент бизнеса, он продавать должен.
На мое предложение взять и все сделать заново (единственное верное решение для того, что там есть) клиент думает уже месяц. При этом я понимаю, что он судорожно ищет где это сделать подешевле. И также понимаю, что с таким подходом он будет продолжать страдать и бизнес загнется все равно.
Главная проблема — большое количество мелких сайтов хостится на shared-хостингах, где нет возможности использовать Git. Как примеры — это Wordpress, Joomla, которые можно запустить практически везде. Усугубляет проблему, что они достаточно популярны и имеют огромное количество расширений разного качества, в том числе и плохого.
знаю только за Битрикс. Там есть инструмент "контроль целостности". Он позволяет и ядро и публичку по контрольной сумме проверять.
Но проблема в том, что такие инструменты не закрывают весь сегмент возможных модификаций. Например, у того же битрикса если используется кеширвоание не в мемкеш, а в файлах, то следить за ними нереально (постоянная ротация же), а вот сложить между ними что-нибудь эдакое — за милое дело...
Думаю, у других CMS ситуация схожая.
Но проблема в том, что такие инструменты не закрывают весь сегмент возможных модификаций. Например, у того же битрикса если используется кеширвоание не в мемкеш, а в файлах, то следить за ними нереально (постоянная ротация же), а вот сложить между ними что-нибудь эдакое — за милое дело...
Думаю, у других CMS ситуация схожая.
Не совсем то, о чем Вы спрашиваете, но что то похожее. Не реклама.
Антивирус Санти, который сканирует файлы сайта на целостность. В случае изменения файлов, отправляет уведомление на почту пользователя.
Антивирус Санти, который сканирует файлы сайта на целостность. В случае изменения файлов, отправляет уведомление на почту пользователя.
Для сайтов на фреймворке WordPress — http://wp-cli.org/commands/core/verify-checksums/ — проверка контрольных сумм
Вордпресс стал фреймворком? Можно я это развижу?..
Все мы не без греха. Я даже в 2015 говнокодил под ВП.
Все мы умные, брезгливые и т.п. Но всякое бывает.
Но в ВП простенький портал на десяток кастомных таксономий да дюжину кастомных типов записей, пятком шорткодов, пятком своих виджетов и дюжиной чужих плагинов — превращается в адов ад.
Задача на неделю в условиях простейшего MVC в ВП превращается в задачу на месяцы.
Но это то и ладно. Среду обитания можно создать и в рамках темы ВП (темы, Карл!).
Ад начинается когда ты берешь готовые темы и плагины. Ведь 2/3 из них уязвимы а то и впрямую содержат бекдоры.
Движок без DRY, SOLID, KISS и стандартов кодирования не может называться фреймворком.
Я не требую ООП или MVC (хотя SOLID обычно подразумевает ООП, но по большому счету эти принципы худо-бедно можно применить и в других парадигмах). Это во многом вкусовщина. Но есть некоторые основы основ.
Черт, вот простейшая задача сейчас стоит. В устаревшем но еще живеньком фреймворке сделана CRM. Полсотни контроллеров всего. Нужно интегрировать в нее телефонию. Интеграция с биллингами нескольких видов АТС (облачных и не очень). Проброс биллинговой информации в CRM, инициализация звонков из CRM. В общем более менее типовая задачка на дюжину классов.
Представляю себе это всё на ВП))))
Все мы умные, брезгливые и т.п. Но всякое бывает.
Но в ВП простенький портал на десяток кастомных таксономий да дюжину кастомных типов записей, пятком шорткодов, пятком своих виджетов и дюжиной чужих плагинов — превращается в адов ад.
Задача на неделю в условиях простейшего MVC в ВП превращается в задачу на месяцы.
Но это то и ладно. Среду обитания можно создать и в рамках темы ВП (темы, Карл!).
Ад начинается когда ты берешь готовые темы и плагины. Ведь 2/3 из них уязвимы а то и впрямую содержат бекдоры.
Движок без DRY, SOLID, KISS и стандартов кодирования не может называться фреймворком.
Я не требую ООП или MVC (хотя SOLID обычно подразумевает ООП, но по большому счету эти принципы худо-бедно можно применить и в других парадигмах). Это во многом вкусовщина. Но есть некоторые основы основ.
Черт, вот простейшая задача сейчас стоит. В устаревшем но еще живеньком фреймворке сделана CRM. Полсотни контроллеров всего. Нужно интегрировать в нее телефонию. Интеграция с биллингами нескольких видов АТС (облачных и не очень). Проброс биллинговой информации в CRM, инициализация звонков из CRM. В общем более менее типовая задачка на дюжину классов.
Представляю себе это всё на ВП))))
Ад начинается когда ты берешь готовые темы и плагины
Все зависит от квалификации разработчика в конкретной области, я специализируюсь на WP, использую только проверенные временем плагины (в большинстве своем платные), остальные плагины мы пишем сами, соблюдая code-style и прочие премудрости.
Я не требую ООП или MVC
WP постепенно переходит на ООП, но в связи с обратной совместимостью — сделать это не так просто. MVC можно получить за счет какого-нибудь WP-MVC.
Движок без DRY, SOLID, KISS и стандартов кодирования
Стандарты кодирования WordPress
Проброс биллинговой информации в CRM
В моих проектах есть и биллинг и CRM и интеграция с 1С — все написано на базе WP, особых затруднений не наблюдаем.
Среду обитания можно создать и в рамках темы ВП
Так делать не нужно)
PS: я защищаю WordPress, потому что он мне близок, я его понимаю и принимаю таким какой он есть на данном этапе и слежу за его развитием, за развитием RestFull API, WP-CLI.
Удачного вам кодинга, коллега
WP не перейдет на ООП. Авторы могут. Движок нет.
Наследие такое, что это невозможно.
Сделать там можно всё, но это каша из топора. Нужно только не использовать петлю (только для основного цикла), отделям вью от контроллера, т.е. шаблоны становятся контроллерами, вьювы делаем отдельно, для простоты работы добавляем построитель запросов, активрекорд, валидацию. Вешаем какой-то автозагрузчик, чтобы хоть как-то разгрузить память. Пару классов заготовок под виджеты (у меня они даже есть вроде), под админку… пару хелперов чтобы более нативно и красиво управлять менюшкой в админке ибо при росте колва сущностей становится сложно… Всё это сделать можно. Для много чего уже есть даже плагины (будь они неладны). Но только есть нюанс. Если среда для себя состоит на 80% из внешних надстроек, то это каша из топора. Ядро тут не помогает а только мешает навязывая устаревшую архитектуру и обратную совместимость. Проще уйти туда где всё это нативно. Один черт учить современные принципы. Так лучше на живом чем-то а не на эмуляции. Для поддержки старых проектов? Блин, ну у каждого же всё свое. Это болезнь движков «из коробки ничего нет, но можно поставить». Плагины где в пять кликов создаешь новый тип записи или таксономии и хранишь его в базе — таких есть вагон и маленькая тележка. Заходишь такой в чужой проект перламутровые пуговицы пришить, а там уже свой велосипед стоит. Тащить проверенный в довесок к нему? Изучать чужой?
Всё что не нативно — не существует.
У Вас куча проверенных временем плагинов? Ой) Это неуловимый Джо и не более. Каждый пятый плагин из популярных имеет XSRF или прямую инъекцию. Но это как правило целенаправленный вектор. Нужно знать что этот пользователь админ именно этого сайта, и у него стоит именно этот плагин. Ну и да, признаюсь, большинство уязвимостей при этом позволяют лишь вандалить, уронить функционал, поудалять там и т.п. Получить контроль, повышать права и т.п. обычно не выйдет. Но это чертов авось, и ради чего? Нет, я понимаю, знаешь только ВП и ничего больше, учить лень потому то заказов хватает и денег достаточно, чего же более? К примеру один мой знакомый миллионер ездил на старенькой Таврии. Рабочая машина приличная, жене купил приличную, а сам на Таврии. Спрашивал мол в чем фишка. Сказал «а нафига? Машина еще не выработала свой ресурс. Начнет ломаться, продам, куплю новую.» Так собственно и сделал.
Вордпресс это как Битрикс и другие пережитки древности или необразованности. Но как Таврию не называют чудомашиной, так и тут — рухлять она и есть рухлять)
Наследие такое, что это невозможно.
Сделать там можно всё, но это каша из топора. Нужно только не использовать петлю (только для основного цикла), отделям вью от контроллера, т.е. шаблоны становятся контроллерами, вьювы делаем отдельно, для простоты работы добавляем построитель запросов, активрекорд, валидацию. Вешаем какой-то автозагрузчик, чтобы хоть как-то разгрузить память. Пару классов заготовок под виджеты (у меня они даже есть вроде), под админку… пару хелперов чтобы более нативно и красиво управлять менюшкой в админке ибо при росте колва сущностей становится сложно… Всё это сделать можно. Для много чего уже есть даже плагины (будь они неладны). Но только есть нюанс. Если среда для себя состоит на 80% из внешних надстроек, то это каша из топора. Ядро тут не помогает а только мешает навязывая устаревшую архитектуру и обратную совместимость. Проще уйти туда где всё это нативно. Один черт учить современные принципы. Так лучше на живом чем-то а не на эмуляции. Для поддержки старых проектов? Блин, ну у каждого же всё свое. Это болезнь движков «из коробки ничего нет, но можно поставить». Плагины где в пять кликов создаешь новый тип записи или таксономии и хранишь его в базе — таких есть вагон и маленькая тележка. Заходишь такой в чужой проект перламутровые пуговицы пришить, а там уже свой велосипед стоит. Тащить проверенный в довесок к нему? Изучать чужой?
Всё что не нативно — не существует.
У Вас куча проверенных временем плагинов? Ой) Это неуловимый Джо и не более. Каждый пятый плагин из популярных имеет XSRF или прямую инъекцию. Но это как правило целенаправленный вектор. Нужно знать что этот пользователь админ именно этого сайта, и у него стоит именно этот плагин. Ну и да, признаюсь, большинство уязвимостей при этом позволяют лишь вандалить, уронить функционал, поудалять там и т.п. Получить контроль, повышать права и т.п. обычно не выйдет. Но это чертов авось, и ради чего? Нет, я понимаю, знаешь только ВП и ничего больше, учить лень потому то заказов хватает и денег достаточно, чего же более? К примеру один мой знакомый миллионер ездил на старенькой Таврии. Рабочая машина приличная, жене купил приличную, а сам на Таврии. Спрашивал мол в чем фишка. Сказал «а нафига? Машина еще не выработала свой ресурс. Начнет ломаться, продам, куплю новую.» Так собственно и сделал.
Вордпресс это как Битрикс и другие пережитки древности или необразованности. Но как Таврию не называют чудомашиной, так и тут — рухлять она и есть рухлять)
Спасибо. Любопытно наблюдать то, на что хакеры тратят свое время. Их бы навыки да в мирное русло…
Зараженный Wordpress это хорошо, но как быть с самодельными продуктами без git, с регулярно обновляющимся кодом скриптов? Вижу только один вариант — иметь локальную копию и регулярное сравнение контрольных сумм.
Подскажите пжлст инструменты для мониторинга джумлы.
возможно вам хватит Manul от Yandex?
yandex.ru/promo/manul#about
yandex.ru/promo/manul#about
Спасибо, посмотрю. Софт типа) burp'a и Acunetix'a я знаю, но вот некоторые из инструментов ниасилил, т.к. не владею (достаточно) собственно теорией да у разных cms разные структуры сайтов.
Забавно, но криво. Запустил на двух сайтах, на обоих сканер умирает на каких-то безобидных файлах по разным причинам, один раз права файла (хостер создает закрытую папку внутри рабочей) второй не совсем понятно почему. В общем доходит до файла и глохнет. Сколько не перезапускай — застревает в одном месте. Глупо застревать. В результате даже проверить функционал не выходит.
Второе это то, что хотелось бы иметь лог всех мд5 всех файлов, и информацию о том какие папки в прошлый раз админ считал неизменяемыми, какие изменяемыми и т.п. Есть ли это — непонятно, но думаю нет…
Остается только форкать и писать свое) Выходит останется в основном только база сигнатур. А насколько она хороша не ясно…
Второе это то, что хотелось бы иметь лог всех мд5 всех файлов, и информацию о том какие папки в прошлый раз админ считал неизменяемыми, какие изменяемыми и т.п. Есть ли это — непонятно, но думаю нет…
Остается только форкать и писать свое) Выходит останется в основном только база сигнатур. А насколько она хороша не ясно…
ну по сути своей это всегда выход :) только кроме базы «сигнатур» нужен еще контроль за появившимися файлами. жаль что на shared хостингах git невозможен.
Ну если сохранять базу сигнатур межбу сессиями сканирования, то новые файлы будут видны. Новые или модифицированные проверяются по белому/черному списку или вручную. Перед и после обновлений, установок плагинов и т.п. сообщаем об этом сканеру. Видя историю с хешами всегда можно понять динамику. Единственное что — базу сигнатур надо держать в надежном месте :)
Хватит уже пользоваться shared-хостингами без git. Эта экономия «у нас тариф за двадцать центов» — она потом приводит к попыткам судорожно изобрести собственные велосипеды и самопальные скрипты (это ещё ладно), но главное — это то, что не настоящая экономия, а псевдоэкономия. Вы потом в двадцать раз больше заплатите тем, что у вас нет нормальных инструментов.
PS Как-то довелось попасть на экскурсию по закрытой части московского кремля. Много там красивых вещей, но запомнилась мне одна стена: простая, деревянная — покрыта витиеватым узором. Чтобы сделать узор размером 2х2 сантиметра — нужно было полдня сидеть аккуратно и тщательно выпиливать. А там эта стена огромных размеров — годы труда вложены, сидели с утра до вечера при лучине не разгибаясь.
Но там это — искусство! И — не было у мастеров других инструментов, более производительных. А тут люди добровольно годами сидят и стругают самопальные скрипты, хотя рядом лежат высокопроизводительные эффективные, принятые в отрасли инструменты. Как так?? Зачем??
PS Как-то довелось попасть на экскурсию по закрытой части московского кремля. Много там красивых вещей, но запомнилась мне одна стена: простая, деревянная — покрыта витиеватым узором. Чтобы сделать узор размером 2х2 сантиметра — нужно было полдня сидеть аккуратно и тщательно выпиливать. А там эта стена огромных размеров — годы труда вложены, сидели с утра до вечера при лучине не разгибаясь.
Но там это — искусство! И — не было у мастеров других инструментов, более производительных. А тут люди добровольно годами сидят и стругают самопальные скрипты, хотя рядом лежат высокопроизводительные эффективные, принятые в отрасли инструменты. Как так?? Зачем??
Вы наверное пишите на фреймворке который я очень не люблю. Его любители такие же категоричные :)
Я не люблю проекты в которых обязательное требование «свой сервер или ВДС» по той причине что этим сервером кто-то должен заниматься. И если я отдаю проект клиенту, у клиента нет ИТ-штата, и клиент не заказывает хостинг у меня, то это должен быть шаред-хостинг от приличного хостера. Микросервисы для пятистраничной визитки и гит для деплоя этой визитки с обязательными нестандартными расширениями пхп для фич которые МОЖЕТ БЫТЬ понадобятся, это извините идиотизм.
Второй кейс — у меня есть клиент, у которого под различные сервисы обеспечивающие рекламную поддержку основного проекта заведено около 20 аккаунтов у разных хостеров. Бюджет там приличный, так что первое время 50/100 баксов в год на акк никто не считал. Но объединив некоторые аккаунты, поменяв регистратора, отказавшись в половине случаев от ВДС/дорогих тарифов удалось не только 1,5к$ в год экономить, но и уменьшить з/п админа в два раза заменив ставку аутсорсом.
Я не люблю проекты в которых обязательное требование «свой сервер или ВДС» по той причине что этим сервером кто-то должен заниматься. И если я отдаю проект клиенту, у клиента нет ИТ-штата, и клиент не заказывает хостинг у меня, то это должен быть шаред-хостинг от приличного хостера. Микросервисы для пятистраничной визитки и гит для деплоя этой визитки с обязательными нестандартными расширениями пхп для фич которые МОЖЕТ БЫТЬ понадобятся, это извините идиотизм.
Второй кейс — у меня есть клиент, у которого под различные сервисы обеспечивающие рекламную поддержку основного проекта заведено около 20 аккаунтов у разных хостеров. Бюджет там приличный, так что первое время 50/100 баксов в год на акк никто не считал. Но объединив некоторые аккаунты, поменяв регистратора, отказавшись в половине случаев от ВДС/дорогих тарифов удалось не только 1,5к$ в год экономить, но и уменьшить з/п админа в два раза заменив ставку аутсорсом.
вы в целом говорите о коммерческих проектах, а когда проект делает обычный человек, можно сказать ученик на поприще? ему проще найти копеечный, а-то и бесплатный хостинг с php/mysql и запускать там свои штуки. этот человек еще не освоил unix shell, он далек от apt get или yum install не говоря уж о ./configure и make install. ну не сисадмин он и не advanced unix user. но контроллировать свой проект — хочется. вот и вынуждены люди пилить свои инструменты, скрипты и прочее. я уже не говорю о хостинге достаточном для работы скромного сайтика без особенной разработки и т.п нужного для скромной компании без it персонала и аутсорса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Небольшое погружение внутрь взломанного сайта