Вахтёр: на страже системы

«Однажды, в студёную зимнюю пору,
Залили на сервер бэкдорчиков гору...»


Народное админское творчество



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

После третьей бутылки пива родилась идея: «А почему бы не отлавливать выполнение системных вызовов из php скриптов?».
Смысл в том, что большинство php-шеллов так или иначе используют функции exec();, system();, shell_exec(); или passthru();. Соответственно выполнение этих функций можно перехватить и тихонько в лог записать, что такого-то числа такой-то скрипт на такой-то строке вызвал функцию exec() с параметром «rm -rf /».
Сказано-сделано. Хорошему человеку kastigar было поставлено тех. задание и работа закипела.
Уж как он расковыривал тонкости Zend Engine я рассказывать не буду, но в конце концов родилось расширение для PHP4/PHP5 под кодовым именем BAXTEP.
Изначально мы не планировали выкладывать код в общий доступ, ибо писалось всё в общем и целом «для себя» и «от и до» не тестировалось, но дух open source всё-таки взял своё — и исходники были выложены на GoogleCode.

Сборка и установка:



Расширение поддерживает версии PHP 4 и 5.

Требования:

— пакеты для разработки PHP4/PHP5 (php4-dev, php5-dev)
— gcc
— subversion

Забираем исходники:

svn checkout http://baxtep.googlecode.com/svn/trunk/ baxtep


Собираем:

cd baxtep
phpize
./configure
make


После сборки вытаскиваем baxtep.so из директории ./modules/ и кладём в extension_dir, и в php.ini добавляем примерно такие строки:

;;;;;;;;;;
; BAXTEP ;
;;;;;;;;;;
; Load extension
extension=baxtep.so

; Absolute path to logfile. File must exist and have write access for php
baxtep.logfile = "/tmp/baxtep_messages"


Лог-файл нужно создавать самому. Кроме того, php-скрипты должны иметь достаточно прав для записи в этот файл:

touch /tmp/baxtep_messages
chmod 777 /tmp/baxtep_messages


Всё, рестартуем Апач, пишем тестовый скрипт и смотрим лог. Там будет нечто навроде этого:

2009-03-13 07:59:05 BAXTEP: system CMDLINE: `pwd` FILE: /var/www/html/test.php on line 5 URI: /test.php

Формат:

ГГГГ-ММ-ДД ЧЧ:ММ:СС BAXTEP: функция CMDLINE: команда FILE: полный путь к файлу на ФС on line N URI: собственно REQUEST_URI
_________
Текст подготовлен в ХабраРедакторе

UPD: l0rda собрал пакеты для CentOS 5 (i386 и x86_64), скачать можно тут: rpm.l0rda.biz/CentOS/5/RPMS/i386/, ключ: rpm.l0rda.biz/L0RDA-KEY
+102
16 сентября 2009, 04:00
160
br0ziliy 33,1

комментарии (138)

+4
br0ziliy #
Если есть какие то вопросы по технической части расширения — велкам в аську/джаббер, дам контакты программиста (аккаунта на Хабре у него нет).
+5
lasc #
ну для хорошего человека и инвайта не жалко, у меня как раз завалялся
+1
br0ziliy #
Камрад ayurganov уже отправил инвайт, спасибо!
+7
kastigar #
Спасибо за инвайт, уже с вами )
+1
v_k #
интересно, спасибо
+3
druzhkov #
скажите, а почему вы не прикрыли в php.ini такие опасные функции вроде exec(), system() и т.д.?
+1
psyhomo #
Бывает, что они используются и в мирных целях =) Например, при использовании netpbm для ресайза картинок.
+3
1amer #
Я, например, во многих проектах использую imagemagic
0
tnz #
Так лучше вкрутить расширение IMagick и пользовать всё изнутри.
+2
br0ziliy #
Не всегда лучше/есть возможность. Тут уже программисты пусть меня поправят.
НЛО прилетело и опубликовало эту надпись здесь
+2
GreenDay #
А почему лог пишется в /tmp? Разве после рестарта сервера у Вас все логи не канут в лету? А что вызвало рестарт так и не узнаете.
+2
naPmu3aH #
Добавляйте в php.ini примерно другие строки, с путем для лога который вам больше нравится
0
br0ziliy #
Как ниже верно заметили, местоположение файла с логом кастомизируется через php.ini
+2
GreenDay #
Это я просто к тому, что многие используют готовое неосмысленно и писать логи в /tmp плохая затея. Поэтому для вышеозначенных людей такие примеры могут закончится плачевно. :)
+1
br0ziliy #
Админ, который «неосознанно» ставит непонятный php-extension, который работает напрямую с ситемными вызовами — плохой админ :) Как минимум исходники глянуть стОит — вдруг троян.
+1
lenar #
интересно было бы еще почитать, что за дыра там обнаружилась
0
br0ziliy #
Да стандартный XSS, не проверялась переменная на то, что внутри приезжает — вот и налили фекалий… А там директории с 777-правами… Ну вобщем как то так :)
Закрыл через mod_security и забыл.
+1
alfa #
Но те-же php-shell'ы замечательно умеют подтирать логи за собой :( в принципе, в вашем случае, можно натравить inotify на /tmp/baxtep_messages и отсылать мыло на интересующие события
+1
1amer #
систему они писали для себя так что вряд ли пхп-шелл будет подтирать информацию в этом логе, по крайней мере пока система не станет популярной.
+1
alfa #
Ну насколько я помню исходник одного, там делалось rm -rf /tmp/;rm -rf /var/log/
0
br0ziliy #
Да, многие делают так — но это же просто пример… Никто не мешает уложить лог куда нибудь похитрей (и не светить его в phpinfo).
0
1amer #
ну это уж слишком палевно. смысл так логи удалять?
+2
br0ziliy #
:) камрад alfa погорячился скорее всего, /var/log никто удалить и не даст
0
alfa #
Удалятся те файлы в директории, куда хватила правов собственно разумеется речь не шла что вся директория будет удалена. Как говорится юзайте suphp т.п. вещи, и будет немножечко счастье. Я имел удовольствие помогать одним знакомым восстанавливать работоспособность системы после очередного взлома. /var/log/ была без самых нужных файлов на тот момент, собственно одним из первых действий стало писать syslog по сети на другой сервер.
0
alfa #
Цели взлома же разные бывают, правда? Где-то цель не поставить красивый iframe на страницу, а тупо нарушить работу системы.
0
1amer #
Тогда зачем вообще тереть логи?
0
alfa #
Чтобы сложнее было разобраться, каким образом поломали систему, зачем же ещё удаляют логи по вашему?
0
1amer #
ну если цель нарушить работу системы и есть права на удаление /var/log, почему бы тогда не удалить /?
0
alfa #
Потому-что зачастую в /tmp или /var/log лежит то, чему бездумно делалось

0
alfa #
chmod 777 /tmp/baxtep_messages

а так разумеется, если правов на корень хватило, то можно грохнуть и его, впрочем смысла то большого нет, достаточно убить хомяк, /etc, почистить /var и у рута и отправить систему в ребут, какой смысл ждать пока удалится /usr и иже с ним если и этого достаточно.
0
br0ziliy #
Да по большому счёту rm -rf /boot/* && reboot достаточно тогда уж…
0
alfa #
Чтобы тачка не поднялась, да, а чтобы админ потрахался с восстановлением данных нет.
0
br0ziliy #
Ну, ежель точка наодится за океаном — админ и так потрахается. И IP-KVM не поможет. Пока до reboot monkeys донесёшь, что от них требуется Кнопикс вставить и настроить сеть и ССШ на нём — не один час пройдёт…
0
zvirusz #
Эмм… попросить КВМ да установочный диск от ОС — думаю до СП быстро дойдёт смысл просьбы, даже на ломанном английском
0
br0ziliy #
С английским как раз всё ок.
Не ок стафф в ДЦ, где сервера стоят. Они по-моему даже не знают, с какой стороны ЦД-РОМ находится у сервера.

(Личный опыт к сожалению)
0
zvirusz #
омг, сочувствую
0
alfa #
Согласитесь, что неработающих 3 часа сервер != неработающий 3 часа сервер и потерянные данные? А зная как многие админы относятся к бэкапам…
0
br0ziliy #
> А зная как многие админы относятся к бэкапам…
Если вы потеряли важные данные — восстановите их из бэкапа. Если бэкапа нет — значит данные были не важные.
Как то так :)
0
alfa #
Интересно, хоть 10% комментариев в этом посте по теме? :)
0
br0ziliy #
А чего, неплохой такой топик получился… Удивило практически полное отсутствием говна в каментах. Хабр тот?
0
lolipop #
cat /dev/urandom > /dev/hda
0
alfa #
систему они писали для себя так что вряд ли пхп-шелл будет подтирать информацию в этом логе, по крайней мере пока система не станет популярной.


Да, многие делают так — но это же просто пример… Никто не мешает уложить лог куда нибудь похитрей (и не светить его в phpinfo).


Защита путём сокрытия (или ставка на малоизвестность), это как прерванный половой акт, очень часто используется как средство контрацепции, но и наименее надёжное из всех остальных.
0
br0ziliy #
Мы от лога вообще отказаться хотим, в вишлисте есть пункт «возможность писать в syslog»
0
zerkms #
а про ` не забыли? :-)
+2
l0rda #
это обертка вокруг функции shell_exec
0
br0ziliy #
Из мануала по PHP:

Use of the backtick operator is identical to shell_exec().
0
zerkms #
а. пардон %)
+2
l0rda #
svn checkout baxtep.googlecode.com/svn/trunk/ baxtep
поправьте в тексте на
svn checkout http://baxtep.googlecode.com/svn/trunk/ baxtep

чтобы оно линк не заменяло

будем тестить, модуль интересный :)
+1
l0rda #
действительно работает ;)
тестировал на PHP Version 4.4.9, собранный статиком в апач
0
br0ziliy #
Ну вобщем и целом именно 14-я ревизия у меня работает уже пол-года на серверах — тьфу-тьфу без багов.
Хотя конфузы случались :) Когда в самом неожиданном месте отваливались все скрипты из-за бага с работой с Zend Engine в расширении.
+1
l0rda #
запрос фичи :)
нельзя ли сделать так, чтобы лог хотя бы пытался сам создасться?
после каждого ребута создавать тяжко (я понимаю что можно прописать в rc.local, но все-таки) особенно если серверов сотня
+1
br0ziliy #
Это в вишлисте есть :) Посмотрите страницу Wiki на GoogleCode.

Будет время — посмотрим.
0
l0rda #
супер, ну и последние пожелания — добавить остальные функции в мониторинг, через которые обычно выполняют команды:
proc_open
popen

и сделать этот список настраиваемым из конфига, чтобы можно было добавлять другие функции в мониторинг
+1
br0ziliy #
> сделать этот список настраиваемым из конфига
тоже в вишлисте.
В любом случае список перехватываемых ф-ций — hardcoded, потому что на каждую пишется свой обработчик… То есть будет список предопределённых ф-ций, которые можно перехватить, а из конфига будет определяться — хэндлить эту ф-цию через расширение или нет.
+1
br0ziliy #
Поправил, спасибо.
+1
youlose #
Вообще есть SELinux, зачем «велосипед»?
Под виндовс аудит есть, не проще ли админа позвать для помощи?
+2
br0ziliy #
По определённым причинам SELinux нам не подходит.

> Под виндовс аудит есть, не проще ли админа позвать для помощи?
«Программа выполнила недопустимую операцию и будет закрыта. Обратитесь за помощью к системному администратору»? :)
А если серьёзно — про Win* не в курсе совсем, так получилось, что админю Linux only.
0
youlose #
Опять же chroot никто не отменял для таких целей,
просто есть куча готовых решений, почему бы не попробовать сначала их, потом (если не получится) попросить помочь людей которые в этом более сведущи, а потом уже (если совсем ничего не вышло) писать дополнительный код.
Задача выглядит вполне решабельной готовыми на данный момент средствами, зачем разводить зоопарк и путать начинающих специалистов?
+1
l0rda #
ну на шаред хостинге например, каждого в chroot не засунешь, SELinux опять же, пока(!) тяжко, мне не кажется, что кто-то кого-то путает, расширение полезное, а тем кому оно не нужно вряд ли будут его ставить
0
br0ziliy #
Вот начинающие специалисты (ежель они серьёзно относятся к профессии) пусть проходят все этапы с поиском готового решения.
Изобретать велосипеды никто и не думал и доп. код пишется тогда и только тогда, когда это действительно необходимо. Нам — было действительно необходимо.

странно что про suhosin никто не вспомнил
+1
alfa #
С suhosin свои грабли :) Хочу на недели потестить suhosin + greensql на предмет оверхеда.
0
br0ziliy #
— Как вы смотрите на suhosin?
— Косо.

Как то меня в своё время не впечатлило. Может, зря, надо будет посмотреть ещё раз.
+1
alfa #
Я использую его на массхостинге одном своём. Для меня как для хостера с ним довольно много проблем, т.к. сайты пишут многие так, что волосы дыбом встают вначале у suhosin, а потом уже у меня :) Но проблемы больше с тем, что месяца два его приходится тюнить, пока не выявлены все криворукие скрипты, а потом уже в обычном порядке мониторить и реагировать на жалобы, когда очередной мегаскрипт не смог постом отправить тысяч 5 переменных :)

Но после добавления его проблем со взломанными сайтами стало ощутимо меньше. Есть соображение, что после добавления greensql их ещё немного уменьшится.
0
l0rda #
а не пробовали связку apache-fastcgi-suexec-php?
у нас четвертый год работает, никаких нареканий и проблем с безопасностью поменьше, чем при использовании suhosin, единственный минус(хотя я считаю это плюсом) директивы php_flag не работают в .htaccess
+1
alfa #
у меня всё так :) + suhosin и + nginx в качестве фронтенда.

По поводу минуса указанного вами, он очень просто решается, кидаете в
/home/user/ файл пустой php.ini с правами не дающими юзверю самому править его, кидаете туда дерективы которые хотите переопределить юзверю и в
/home/user/public_html/.htaccess добавляете

suPHP_ConfigPath /home/user

и всё (пути разумеется даны исключительно для примера)
0
br0ziliy #
Хм, а если стоит задача именно пользователю дать возможность тюнить директивы php.ini?
0
alfa #
Ну тогда дать права на запись :)
0
br0ziliy #
Кстати, стесняюсь спросить…
Cpanel?
0
alfa #
На одном из серверов, ага.
0
l0rda #
а мы просто добавляем в конфиг виртуалхоста:
SetEnv PHPRC "/home/user/domain.com"

suexec предварительно пропатчен, для него разрешены переменные окружения GEOIP_* и PHPRC

в папке домена лежит тот же php.ini
но изменять его может только админ по запросу,
обычно просят изменить register_globals
0
br0ziliy #
А мы и под это расширение написали ;) Но тут уж сорри — корпоративный копирайт не позволяет сорцы отдавать (ВАХТЕР писался по собственной инициативе, а вот процессинг php_flag/php_value в .htaccess для suphp — коммерческий заказ непосредственно владельца серверов).
0
br0ziliy #
Я как представлю заживление suhosin у себя — брррр.
Не, я не готов снова отбивать 100+ жалоб в час (реальная цифра после перехода на PHP5 по-умолчанию)…
0
acy #
То есть мне не придется теперь проверять вводимые данные, прежде чем отравить запрос? ): Ну, право слово, всю романтику убивает.
0
alfa #
Умные люди делают все проверки сами, глупцы полагаются на авось, никто не виноват, что на массхостингах основная масса альтернативно умные.
0
pietrovich #
странно что про suhosin никто не вспомнил

а помогает?
0
br0ziliy #
Ну именно для перехвата системных вызовов — нет. А так — от переполнения буфера и обращения не в своё адресное пространство может и спасёт :)
0
pietrovich #
потому и не вспомнили :)
0
squint #
А зачем именно расширение?
Можно было бы просто…

rename_function('exec', '_exec');
override_function('exec','safe_exec');

ну и как вариант задать в safe_exec допустимые команды.
+1
br0ziliy #
Эм… Оно ж вроде только внутри скриптов работает.
А нам как то влом было лопатить скрипты 100+ аккаунтов :)
Посему спустились на уровень движка Zend, чтоб бить врага на подходах, так сказать.
0
kastigar #
Во-первых, rename_function и override_function — функции другого расширения APD. Какая разница, если нужно подключать APD вместо вахтера.
Во-вторых, как заметил br0ziliy, этот код нужно добавлять во все скрипты. И есть возможность и даже скорее всего так и будет, что php-шелл будет пускаться отдельным скриптом с обыкновенным exec. Как туда включить Ваш код?
Ну и в-третьих, мне очень хотелось ковырнуть php extensions :)
0
squint #
всё верно, я уже вижу что предложил бесполезный на практике вариант)
0
mazy #
после добавления сухосина на сервер (debian, php 5.2.10, запущен как fastcgi ) fcgi сервера дружно попадали в корку сразу же при старте. пришлось отказаться.
0
br0ziliy #
А не разбирались, в чём именно проблема?
0
mazy #
к сожалению не было времени и желания разбираться.
пробовалось на 3х разных серверах с одинаковой настройкой — debian — php-cgi —
на всех 3х валится.
+2
baxtep2 #
чьорт моим ником прогу назвали
0
br0ziliy #
:)

имя расширения сильно раньше 02 марта 2009 появилось
+1
baxtep2 #
:) я родился еще раньше
0
lolipop #
ник вы при рождении получили? ;)
+2
zCooler #
777 на лог-файл?? Вы его исполнять собрались?
–2
br0ziliy #
А где припска «Не зануда»?
Ну привык я world-writeable permissions выставлять как 777. Да и chmod 666 как то не того… В системе и так демонов достаточно. 777 получше выглядит ;)
0
zvirusz #
chmod a+w %)
–1
br0ziliy #
буэ
Никогда не юзал символьную запись если честно :) И не помню, какие буквы там за что отвечают.
+3
kibizoidus #
Вообще за «777» на любом файле руки отбивать нужно.
Получается, вы пишете .so'шку для сохранения безопасности, и тут же нарушаете ее основы.
Деление на ноль прям.
+3
zCooler #
При чем тут занудство?

А привычку Вы свою меняйте. Ибо негоже на логи ставить +x бит. Да и что тут такого в 666? Суеверность? Глупо в век цифровых технологих отмахиватся суеверием.
В любом случае правильное присвоение прав залог успеха.
0
br0ziliy #
В качестве здравой дискуссии…

Чем принципиально плохо назначение исполняемого бита файлу, который не планируется выполнять?
Не, я конечно сам любитель при случае пустить find ./ -type f -name *php -exec chmod 644 '{}' \; — хотелось бы услышать стороннее мнение.
0
kastigar #
Вставлю свои 5 копеек.
Я считаю что все зависит от контекста файла. Если это «надежный» файл, т.е. в него не попадет код какой-нибудь, который можно исполнить, то ничего страшного нету, в крайнем случае он просто не сможет выполнится. Если же файл «ненадежный», т.е. при каком-то стечении обстоятельств может попасть исполняемый код, то, естественно, это потенциальная уязвимость.
К тому же права 777 просто показывают всеобщий доступ (666 уже говорит о каких-то ограничениях).

С другой стороны, если обратится к первоисточнику (лог файл в папке /tmp с правами 777), то зря спорите. Естественно файл будет затираться, конечно же права 777 никуда не годятся… Просто это не конечный продукт, и основная его задача не «красиво писать логи», а вообще дать возможность писать логи ) Все мои силы были направлены на корректный оптимальный отлов событий.
0
youlose #
Надёжных файлов не бывает, любой серьёзный вирус или прямая сессия злоумышленника и сразу это начинаешь понимать. Лучьше сразу всё правильно делать… поначалу неудобно, а потом привыкаешь.
0
Bambr #
Я бы на него и 666 ставить не стал на Вашем месте. В Вашем случае еще веселее — любой кулхацкер может его сначала переписать своим контентом, а потом выполнить. Причем первое и второе может быть без труда проделано под разными юзерами.

Чем вам не угодили варианты вида 660, 600, где право записи можно отдать только тому, кому нужно?
0
Bambr #
Забыл приписку: «Зануда».
0
RamonZzz #
Бро, тут же не в красоте дело, а в безопасности :)
0
zvirusz #
а не подскажите ли, есть готовые способы логирования mail()?
+1
br0ziliy #
Готовых — нет. У нас (опять же по корпоративному заказу) это реализовано php-расширением
0
zvirusz #
а можно и его опубликовать? :) а в идеале — скрестить с вахтёром?
+2
kastigar #
ммммм. А это идея :) Можно в вишлист/todo добавить
0
br0ziliy #
Нелья его опубликовать — это коммерческий проект, не имеем права.
А вот написать нечто подобное — можно. Если время и желание будет :)
+2
mvs #
ru2.php.net/manual/en/mail.configuration.php#ini.mail.log

mail.log Available since PHP 5.3.0.
Log all mail() calls including the full path of the script, line number, To address and headers.
0
zvirusz #
Чёрт, забыл упомянуть, что php 5.2 — сервак на debian etch, на lenny (для него хоть есть готовые бинарные) перейти не можем — Plesk мешает (да и неизвестно, как то же самый плеск себя поведёт на 5.3) :(
0
trolik #
писать логи нужно использую syslog
а уж в нем можно настроить запись на другую машину, так более безопасно
0
br0ziliy #
> писать логи нужно использую syslog
Нужно. Выше я писАл что этот функционал запланирован.
А так — расширение по GPLv2 распространяется, никто не мешает взять и дописать самому «чонада» ;)
–5
odessky #
Статья — хуйня и вот почему
1) Опасные функции можно банально отключить, php позволяет это делать
2) Для защиты от phpshell и тп очень помогает mod_security
0
kastigar #
Я конечно не админ, но скажу так:
1) exec и подобные ф-ции не всегда нужно отключать, но их нужно контролировать. Для этого и писался этот экстеншен. В дальнейшем планируется система правил. Какие-то вызовы можно разрешить, какие-то запретить вообще и т.п.
2) Вахтер не замена для mod_security, но очень ему помогает. Дыру можно прикрыть с помощью mod_security, но с помощью вахтера можно быстрее ее обнаружить и увидеть что шелл успел натворить в системе…
0
zvirusz #
1. зачем же так категорично? выше уже писали про imagemagic
2. не апачем единым, для nginx «ничего подобного нет и не предвидится»
Да и не всегда php-shell'ы используют во зло, вы не поверите.
0
DevArt #
Ну в том же творении товарища Сысоева, не столь давно была найдена дырка, которая кстати анонсировалась на Хабрахабр. Это. к сожалению в очередной раз доказывает мерзкую и противную аксиому «что один написал — другой может сломать» :)
+2
kastigar #
Есть мысль написать статью про вахтер со стороны программиста. Конечно сроки я не знаю, но могу постараться.
0
bSun #
pcntl_exec забыли. Еще подргузку библиотек придется отрубить (если не ошибаюсь, то ваш модуль не залогирует системные вызовы из подгруженной либы), а так же функции get_loaded_extensions, ini_get_all, phpinfo, ибо они могут скомпрометировать путь до логов
0
bSun #
пардон, popen и proc_open забыл.
0
kastigar #
Я знаю про все эти ф-ции, просто еще не успел их заимплементить. Хотя там даже ничего сложного, за исключением pcntl_exec.
Вот про загрузку сторонних либ я не подумал, хотя насколько мне известно, просто так библиотеку трудно подключить, она должна лежать в папке с экстеншенами, куда без рута очень трудно положить файл (если система корректно настроена).
0
l0rda #
не совсем так, когда php работает как модуль апача и в конфиге по-умолчанию:
enable_dl = On
extension_dir = "./"

то возможно подгрузить экстеншен динамически.

С динамической загрузкой, возможно игнорировать все open_basedir ограничения
0
unxed #
Еще нужно ловить copy, unlink и все-все-все, что работает с файлами, т.к. вместо имен файлов могуть быть вызовы системных команд. И доступ к unix-сокетам через fsockopen — тоже сомнительная деятельность. И наверняка еще можно придумать варианты.
0
kastigar #
Что значит вызовы системных команд? Вы имеете ввиду бинарные файлы? И что? Максимум это их можно скопировать или прочитать. Ну и удалить, если прав хватит, а прав хватит в некорректно настроенной системе )
Про сокеты — ничего толкового сказать не могу, нужно исследовать…
0
unxed #
Пардон, перепутал с перлом, в котором можно делать так:
open(PASS, «sort -n -t: +3 -4 +0 /etc/passwd|»);
0
WGH #
т.к. вместо имен файлов могуть быть вызовы системных команд.

И вызов действительно произойдет? А в остальном согласен.
0
WGH #
0
unxed #
Вроде как, все-таки, нет. Ошбися. см. ответ выше.
–1
shalb #
Гм, както не системненько, рвать зад, кодить подпорку, когда велосипед уже придуман:
ua.php.net/manual/en/features.safe-mode.functions.php
А нужно бинари — так покласть их куда нужно и позволить кому нужно.
0
br0ziliy #
Прочитайте выше, safe_mode не всегда подходит.
0
l0rda #
Мне данная софтина уже помогла. Так что я сделал сборки пакетов для CentOS 5 (i386 и x86_64), качать можно тут: rpm.l0rda.biz/CentOS/5/RPMS/
ключик: rpm.l0rda.biz/L0RDA-KEY
0
br0ziliy #
Спасибо! Обновил топик.
0
br0ziliy #
А под какую версию ПХП сборку сделали?
0
l0rda #
в CentOS стандартный 5.1.6 сейчас
0
l0rda #
привет,

а измени плз ссылку в посте, чтобы не на рпм указывала, а на папку с ним, а то там уже апдейт был, и еще один будет на днях и ссылка изменилась
0
br0ziliy #
сделал
0
br0ziliy #
а что за апдейты?
0
l0rda #
в версии 0.1.0-3 сделана жесткая зависимость от версии php
в версии 0.1.0-4 будет добавлен скрипт для logrotate, чтобы все было совсем красиво

а у вас там апдейтов не предвидится на основании изложенного в комментах этого топика?
0
br0ziliy #
AFAIK нет, разработка приостановлена по причине нехватки времени — коммерческими проектами занимаемся пока, на лето зарабатываем :)
0
l0rda #
в следующей версии сделаю жесткие зависимости к версии php
0
Antispammer #
круто, спасибо за полезный модуль)

BTW:

«Среди опасных, есть еще функция proc_open, чтобы ее перехватывать, нужно добавить в файл baxtep.c строчку:

1
php_baxtep_substitute_function(»proc_open" TSRMLS_CC);
и пересобрать/переподгрузить модуль." ©netspider.com.ua
bit.ly/z7bGGZ

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