Знакомая ситуация и ничего не поделаешь: на виртуальных хостингах порой не то что отсутствует git/ssh, даже cron отсутствует.
Довольно часто причиной такой печальной ситуации являются банальные вирусы у клиентов, имеющих доступ к сайту по фтп. Те в свою очередь в автоматическом режиме могут имплантировать в php-файлы рекламу вплоть до банальной дозаписи в конец index.php рекламного баннера. Костыльное решение — удалить ?> в конце всех php файлов иногда спасает. Но лучше — вообще огородить сайт от «клиента».
Правда, попадаются умные зловреды, которые ещё и htaccess нужным образом подправляют. В вашем скрипте проверки на «левые» .htaccess и вообще на наличие новых файлов я не нашёл — так что возьмите на заметку — может пригодиться. Вектор атаки через htaccess прост: создаётся новый php-скрипт, на который делается htaccess-перенаправление со всех страниц. Старые файлы не тронули и черное дело сделано.
По делу — git/svn/php — это не очень серьёзно. Есть опенсорсная система обнаружения вторжений: AIDE. Для пущей гарантии сам верификатор и контрольные суммы должны храниться на внешнем носителе — флешке например. Ибо одна строчка alias git=: — и вся защита полетит.
Сгенерированные статьи достаточно легко обнаружить
Только сгенерированные SCIgen. Наверняка сумрачный гений уже состряпал что-то более хитроумное, ведь SCIgen — это всего лишь небольшой перловый скрипт…
Возможно, кому-то — переучиваться, но учитывая что в коммьюнити много молодых разработчиков, знакомство с Git им не повредит (им ещё в вуз/на работу устраиваться).
Ну или другой вариант: сейчас пока ваш SVN-сервер где-то далеко, контрибьютить я туда скорее всего не буду без острой на то нужды (ещё зависит от сложности отправки/скорости рассмотрения патчей и т. п.). Гитхаб же — социальная сеть, там отправить патч — дело минуты, не нужно нигде регистрироваться и вести нудную переписку на форуме/по e-mail. Количество патчей точно не уменьшится, а коммьюнити гитхаба — это сильное подспорье. Перевод svn на гихтаб дело пары команд. А попробовав силу слияния веток гита уже невозможно отказаться:)
Не видел QA команд, которые проводят регулярный регресс СПО.
Вам просто не попадались на глаза такие крошечные компании как Google, Red Hat, Oracle, IBM, Apple, Intel, Mozilla и Apache… Их работа незаметна и растворяется в исходниках ядра Linux, прикладного ПО, системных библиотек. А вот кто и как тестирует ПО от Microsoft — ещё надо посмотреть.
то девочкам, которые всю жизнь щелкали по кнопкам ворда, будет крайне сложно объяснить весь дзен работы в текстовом редакторе с набором неизвестным им тегов
Зря надеетесь, что девочки из ворда с лёгкостью освоят TeX:) Я в своё время замучился выискивать забытые скобочки и опечатки в командах. А когда дело доходит до экранирования символов и всяких листингов — пропажу можно обнаружить порой только после вычитки документа. Тут любой язык разметки — что в лоб, что по лбу — для технически неподготовленного писателя сущий ад. Особенно, если периодически устраиваются дворцовые перевороты вроде Word -> TeX -> XML…
Есть аналогичный и не менее мощный вариант — LaTeX + LyX. Докбук может стать проблемой, если в команде разработчиков есть ещё и технические писатели, которым в XML разбираться будет крайне некомфортно. LyX же имеет графический интерфейс и плагины экспорта в тот же DocBook, но главное — движок TeX-а. Недостаток — исходник практически нечитабелен, и в случае конфликта…
Другой возможный вариант — fodt (Open Document Format в чистом XML-е), его поддерживает LibreOffice — в особых случаях, когда нет возможности отказаться от вордоподобного интерфейса. Тут получается полноценный ворд-редактор и формат, относительно дружественный к VCS. Пляски стилей при этом останутся, зато самый щадящий режим для зажатых со всех сторон виндовыми форматами разработчиков, когда не отвертеться и вынь да положь *.doc.
Комментарий этот к тому, что недостаёт сравнения с аналогами. По самому докбуку — стоит добавить, что есть ещё проект publican, насколько знаю, его использует в Red Hat — набор решений для выпуска готовых к печати книг (PDF) + HTML-онлайн версии из одного исходника.
Но радует, что не благодаря, а вопреки «офисный» режим постепенно сходит на нет:)
Собственно, сам автор (руткита, разумеется) уже написал статью о менее изощрённом способе его детектить. Впрочем, на него тоже найдётся анти-анти-руткит:)
Тогда вопрос с другой стороны: как маскируется мусор в домашнем каталоге и .bashrc (предположим что пользователь или антивирус в состоянии туда дотянуться)? Т. е. он может скрыть само по себе присутствие записи в bashrc?
Ну зачем же так сурово. Можно на Fedora с targeted потестировать сначала. Вот этого явно не хватает в текущей статье — как оно реально применимо? Механизмы нападения совершенствуются, но и защиты — не отстают.
По иронии судьбы, Азазель маскируется под libselinux.
By default, Azazel installs itself as libselinux.so into /lib. An entry is then added to /etc/ld.so.preload in order to hook system wide dynamically compiled programs.
нужны права рута для полноценной эксплуатации руткита?
Я точно не ручаюсь сейчас, но вроде бы make CFLAGS=-O2 и CFLAGS=-O2 make — будет по-разному интерпретироваться. Т.е. в первом случае CFLAGS будет принудительно перезаписан, вне зависимости от того что прописано в самом makefile, а во втором — только если разработчик разрешил.
> Что такое make --trace
Возможно, потому что у меня Linux и немного другой Mac Make?:) В GNU Make --trace есть и здорово помогает отладочными сообщениями в случае чего.
> Я не представляю как легко и просто перевести монструозный проект
Никак. Если сразу выбрали cmake — хорошо. Но в мире OpenSource не принято таскать за собой thirdparty, а как раз разруливать зависимости, уже имеющиеся в операционной системе, с чем cmake/autotools и справляется. Из крупных проектов, которые тащат за собой груз из унаследованного ПО: Qt, Chromium. При этом у них ещё и собственный велосипед — своя система сборки.
> они могут собираться с разными abi
Эти нюансы тоже должны прятаться внутри cmake/autotools. Перед сборкой проекта они проверяют возможности компиляторов, наличие библиотек и их возможности и в соответствии с этим генерируют Makefile.
Довольно часто причиной такой печальной ситуации являются банальные вирусы у клиентов, имеющих доступ к сайту по фтп. Те в свою очередь в автоматическом режиме могут имплантировать в php-файлы рекламу вплоть до банальной дозаписи в конец index.php рекламного баннера. Костыльное решение — удалить
?>в конце всех php файлов иногда спасает. Но лучше — вообще огородить сайт от «клиента».Правда, попадаются умные зловреды, которые ещё и htaccess нужным образом подправляют. В вашем скрипте проверки на «левые» .htaccess и вообще на наличие новых файлов я не нашёл — так что возьмите на заметку — может пригодиться. Вектор атаки через htaccess прост: создаётся новый php-скрипт, на который делается htaccess-перенаправление со всех страниц. Старые файлы не тронули и черное дело сделано.
По делу — git/svn/php — это не очень серьёзно. Есть опенсорсная система обнаружения вторжений: AIDE. Для пущей гарантии сам верификатор и контрольные суммы должны храниться на внешнем носителе — флешке например. Ибо одна строчка
alias git=:— и вся защита полетит.Только сгенерированные SCIgen. Наверняка сумрачный гений уже состряпал что-то более хитроумное, ведь SCIgen — это всего лишь небольшой перловый скрипт…
Ну или другой вариант: сейчас пока ваш SVN-сервер где-то далеко, контрибьютить я туда скорее всего не буду без острой на то нужды (ещё зависит от сложности отправки/скорости рассмотрения патчей и т. п.). Гитхаб же — социальная сеть, там отправить патч — дело минуты, не нужно нигде регистрироваться и вести нудную переписку на форуме/по e-mail. Количество патчей точно не уменьшится, а коммьюнити гитхаба — это сильное подспорье. Перевод svn на гихтаб дело пары команд. А попробовав силу слияния веток гита уже невозможно отказаться:)
Вам просто не попадались на глаза такие крошечные компании как Google, Red Hat, Oracle, IBM, Apple, Intel, Mozilla и Apache… Их работа незаметна и растворяется в исходниках ядра Linux, прикладного ПО, системных библиотек. А вот кто и как тестирует ПО от Microsoft — ещё надо посмотреть.
Geany в этом формате документацию пишет, так вот пока обновил там одну таблицу — проклял всё.
Зря надеетесь, что девочки из ворда с лёгкостью освоят TeX:) Я в своё время замучился выискивать забытые скобочки и опечатки в командах. А когда дело доходит до экранирования символов и всяких листингов — пропажу можно обнаружить порой только после вычитки документа. Тут любой язык разметки — что в лоб, что по лбу — для технически неподготовленного писателя сущий ад. Особенно, если периодически устраиваются дворцовые перевороты вроде Word -> TeX -> XML…
Другой возможный вариант — fodt (Open Document Format в чистом XML-е), его поддерживает LibreOffice — в особых случаях, когда нет возможности отказаться от вордоподобного интерфейса. Тут получается полноценный ворд-редактор и формат, относительно дружественный к VCS. Пляски стилей при этом останутся, зато самый щадящий режим для зажатых со всех сторон виндовыми форматами разработчиков, когда не отвертеться и вынь да положь *.doc.
Комментарий этот к тому, что недостаёт сравнения с аналогами. По самому докбуку — стоит добавить, что есть ещё проект publican, насколько знаю, его использует в Red Hat — набор решений для выпуска готовых к печати книг (PDF) + HTML-онлайн версии из одного исходника.
Но радует, что не благодаря, а вопреки «офисный» режим постепенно сходит на нет:)
По иронии судьбы, Азазель маскируется под libselinux.
нужны права рута для полноценной эксплуатации руткита?
Возможно, потому что у меня Linux и немного другой
MacMake?:) В GNU Make --trace есть и здорово помогает отладочными сообщениями в случае чего.> Я не представляю как легко и просто перевести монструозный проект
Никак. Если сразу выбрали cmake — хорошо. Но в мире OpenSource не принято таскать за собой thirdparty, а как раз разруливать зависимости, уже имеющиеся в операционной системе, с чем cmake/autotools и справляется. Из крупных проектов, которые тащат за собой груз из унаследованного ПО: Qt, Chromium. При этом у них ещё и собственный велосипед — своя система сборки.
> они могут собираться с разными abi
Эти нюансы тоже должны прятаться внутри cmake/autotools. Перед сборкой проекта они проверяют возможности компиляторов, наличие библиотек и их возможности и в соответствии с этим генерируют Makefile.