Комментарии 141
Если есть какие то вопросы по технической части расширения — велкам в аську/джаббер, дам контакты программиста (аккаунта на Хабре у него нет).
интересно, спасибо
скажите, а почему вы не прикрыли в php.ini такие опасные функции вроде exec(), system() и т.д.?
А почему лог пишется в /tmp? Разве после рестарта сервера у Вас все логи не канут в лету? А что вызвало рестарт так и не узнаете.
НЛО прилетело и опубликовало эту надпись здесь
Как ниже верно заметили, местоположение файла с логом кастомизируется через php.ini
интересно было бы еще почитать, что за дыра там обнаружилась
Но те-же php-shell'ы замечательно умеют подтирать логи за собой :( в принципе, в вашем случае, можно натравить inotify на /tmp/baxtep_messages и отсылать мыло на интересующие события
систему они писали для себя так что вряд ли пхп-шелл будет подтирать информацию в этом логе, по крайней мере пока система не станет популярной.
Ну насколько я помню исходник одного, там делалось rm -rf /tmp/;rm -rf /var/log/
Да, многие делают так — но это же просто пример… Никто не мешает уложить лог куда нибудь похитрей (и не светить его в phpinfo).
ну это уж слишком палевно. смысл так логи удалять?
:) камрад alfa погорячился скорее всего, /var/log никто удалить и не даст
Удалятся те файлы в директории, куда хватила правов собственно разумеется речь не шла что вся директория будет удалена. Как говорится юзайте suphp т.п. вещи, и будет немножечко счастье. Я имел удовольствие помогать одним знакомым восстанавливать работоспособность системы после очередного взлома. /var/log/ была без самых нужных файлов на тот момент, собственно одним из первых действий стало писать syslog по сети на другой сервер.
Цели взлома же разные бывают, правда? Где-то цель не поставить красивый iframe на страницу, а тупо нарушить работу системы.
Тогда зачем вообще тереть логи?
Чтобы сложнее было разобраться, каким образом поломали систему, зачем же ещё удаляют логи по вашему?
ну если цель нарушить работу системы и есть права на удаление /var/log, почему бы тогда не удалить /?
Потому-что зачастую в /tmp или /var/log лежит то, чему бездумно делалось
chmod 777 /tmp/baxtep_messages
а так разумеется, если правов на корень хватило, то можно грохнуть и его, впрочем смысла то большого нет, достаточно убить хомяк, /etc, почистить /var и у рута и отправить систему в ребут, какой смысл ждать пока удалится /usr и иже с ним если и этого достаточно.
а так разумеется, если правов на корень хватило, то можно грохнуть и его, впрочем смысла то большого нет, достаточно убить хомяк, /etc, почистить /var и у рута и отправить систему в ребут, какой смысл ждать пока удалится /usr и иже с ним если и этого достаточно.
Да по большому счёту rm -rf /boot/* && reboot достаточно тогда уж…
Чтобы тачка не поднялась, да, а чтобы админ потрахался с восстановлением данных нет.
Ну, ежель точка наодится за океаном — админ и так потрахается. И IP-KVM не поможет. Пока до reboot monkeys донесёшь, что от них требуется Кнопикс вставить и настроить сеть и ССШ на нём — не один час пройдёт…
Эмм… попросить КВМ да установочный диск от ОС — думаю до СП быстро дойдёт смысл просьбы, даже на ломанном английском
Согласитесь, что неработающих 3 часа сервер != неработающий 3 часа сервер и потерянные данные? А зная как многие админы относятся к бэкапам…
cat /dev/urandom > /dev/hda
систему они писали для себя так что вряд ли пхп-шелл будет подтирать информацию в этом логе, по крайней мере пока система не станет популярной.
Да, многие делают так — но это же просто пример… Никто не мешает уложить лог куда нибудь похитрей (и не светить его в phpinfo).
Защита путём сокрытия (или ставка на малоизвестность), это как прерванный половой акт, очень часто используется как средство контрацепции, но и наименее надёжное из всех остальных.
а про ` не забыли? :-)
svn checkout baxtep.googlecode.com/svn/trunk/ baxtep поправьте в тексте на svn checkout http://baxtep.googlecode.com/svn/trunk/ baxtep
чтобы оно линк не заменяло
будем тестить, модуль интересный :)
действительно работает ;)
тестировал на PHP Version 4.4.9, собранный статиком в апач
тестировал на PHP Version 4.4.9, собранный статиком в апач
Ну вобщем и целом именно 14-я ревизия у меня работает уже пол-года на серверах — тьфу-тьфу без багов.
Хотя конфузы случались :) Когда в самом неожиданном месте отваливались все скрипты из-за бага с работой с Zend Engine в расширении.
Хотя конфузы случались :) Когда в самом неожиданном месте отваливались все скрипты из-за бага с работой с Zend Engine в расширении.
запрос фичи :)
нельзя ли сделать так, чтобы лог хотя бы пытался сам создасться?
после каждого ребута создавать тяжко (я понимаю что можно прописать в rc.local, но все-таки) особенно если серверов сотня
нельзя ли сделать так, чтобы лог хотя бы пытался сам создасться?
после каждого ребута создавать тяжко (я понимаю что можно прописать в rc.local, но все-таки) особенно если серверов сотня
Это в вишлисте есть :) Посмотрите страницу Wiki на GoogleCode.
Будет время — посмотрим.
Будет время — посмотрим.
супер, ну и последние пожелания — добавить остальные функции в мониторинг, через которые обычно выполняют команды:
proc_open
popen
и сделать этот список настраиваемым из конфига, чтобы можно было добавлять другие функции в мониторинг
proc_open
popen
и сделать этот список настраиваемым из конфига, чтобы можно было добавлять другие функции в мониторинг
> сделать этот список настраиваемым из конфига
тоже в вишлисте.
В любом случае список перехватываемых ф-ций — hardcoded, потому что на каждую пишется свой обработчик… То есть будет список предопределённых ф-ций, которые можно перехватить, а из конфига будет определяться — хэндлить эту ф-цию через расширение или нет.
тоже в вишлисте.
В любом случае список перехватываемых ф-ций — hardcoded, потому что на каждую пишется свой обработчик… То есть будет список предопределённых ф-ций, которые можно перехватить, а из конфига будет определяться — хэндлить эту ф-цию через расширение или нет.
Поправил, спасибо.
Вообще есть SELinux, зачем «велосипед»?
Под виндовс аудит есть, не проще ли админа позвать для помощи?
Под виндовс аудит есть, не проще ли админа позвать для помощи?
По определённым причинам SELinux нам не подходит.
> Под виндовс аудит есть, не проще ли админа позвать для помощи?
«Программа выполнила недопустимую операцию и будет закрыта. Обратитесь за помощью к системному администратору»? :)
А если серьёзно — про Win* не в курсе совсем, так получилось, что админю Linux only.
> Под виндовс аудит есть, не проще ли админа позвать для помощи?
«Программа выполнила недопустимую операцию и будет закрыта. Обратитесь за помощью к системному администратору»? :)
А если серьёзно — про Win* не в курсе совсем, так получилось, что админю Linux only.
Опять же chroot никто не отменял для таких целей,
просто есть куча готовых решений, почему бы не попробовать сначала их, потом (если не получится) попросить помочь людей которые в этом более сведущи, а потом уже (если совсем ничего не вышло) писать дополнительный код.
Задача выглядит вполне решабельной готовыми на данный момент средствами, зачем разводить зоопарк и путать начинающих специалистов?
просто есть куча готовых решений, почему бы не попробовать сначала их, потом (если не получится) попросить помочь людей которые в этом более сведущи, а потом уже (если совсем ничего не вышло) писать дополнительный код.
Задача выглядит вполне решабельной готовыми на данный момент средствами, зачем разводить зоопарк и путать начинающих специалистов?
ну на шаред хостинге например, каждого в chroot не засунешь, SELinux опять же, пока(!) тяжко, мне не кажется, что кто-то кого-то путает, расширение полезное, а тем кому оно не нужно вряд ли будут его ставить
Вот начинающие специалисты (ежель они серьёзно относятся к профессии) пусть проходят все этапы с поиском готового решения.
Изобретать велосипеды никто и не думал и доп. код пишется тогда и только тогда, когда это действительно необходимо. Нам — было действительно необходимо.
странно что про suhosin никто не вспомнил
Изобретать велосипеды никто и не думал и доп. код пишется тогда и только тогда, когда это действительно необходимо. Нам — было действительно необходимо.
странно что про suhosin никто не вспомнил
С suhosin свои грабли :) Хочу на недели потестить suhosin + greensql на предмет оверхеда.
— Как вы смотрите на suhosin?
— Косо.
Как то меня в своё время не впечатлило. Может, зря, надо будет посмотреть ещё раз.
— Косо.
Как то меня в своё время не впечатлило. Может, зря, надо будет посмотреть ещё раз.
Я использую его на массхостинге одном своём. Для меня как для хостера с ним довольно много проблем, т.к. сайты пишут многие так, что волосы дыбом встают вначале у suhosin, а потом уже у меня :) Но проблемы больше с тем, что месяца два его приходится тюнить, пока не выявлены все криворукие скрипты, а потом уже в обычном порядке мониторить и реагировать на жалобы, когда очередной мегаскрипт не смог постом отправить тысяч 5 переменных :)
Но после добавления его проблем со взломанными сайтами стало ощутимо меньше. Есть соображение, что после добавления greensql их ещё немного уменьшится.
Но после добавления его проблем со взломанными сайтами стало ощутимо меньше. Есть соображение, что после добавления greensql их ещё немного уменьшится.
а не пробовали связку apache-fastcgi-suexec-php?
у нас четвертый год работает, никаких нареканий и проблем с безопасностью поменьше, чем при использовании suhosin, единственный минус(хотя я считаю это плюсом) директивы php_flag не работают в .htaccess
у нас четвертый год работает, никаких нареканий и проблем с безопасностью поменьше, чем при использовании suhosin, единственный минус(хотя я считаю это плюсом) директивы php_flag не работают в .htaccess
у меня всё так :) + suhosin и + nginx в качестве фронтенда.
По поводу минуса указанного вами, он очень просто решается, кидаете в
/home/user/ файл пустой php.ini с правами не дающими юзверю самому править его, кидаете туда дерективы которые хотите переопределить юзверю и в
/home/user/public_html/.htaccess добавляете
suPHP_ConfigPath /home/user
и всё (пути разумеется даны исключительно для примера)
По поводу минуса указанного вами, он очень просто решается, кидаете в
/home/user/ файл пустой php.ini с правами не дающими юзверю самому править его, кидаете туда дерективы которые хотите переопределить юзверю и в
/home/user/public_html/.htaccess добавляете
suPHP_ConfigPath /home/user
и всё (пути разумеется даны исключительно для примера)
Хм, а если стоит задача именно пользователю дать возможность тюнить директивы php.ini?
Кстати, стесняюсь спросить…
Cpanel?
Cpanel?
а мы просто добавляем в конфиг виртуалхоста:
SetEnv PHPRC "/home/user/domain.com"
suexec предварительно пропатчен, для него разрешены переменные окружения GEOIP_* и PHPRC
в папке домена лежит тот же php.ini
но изменять его может только админ по запросу,
обычно просят изменить register_globals
SetEnv PHPRC "/home/user/domain.com"
suexec предварительно пропатчен, для него разрешены переменные окружения GEOIP_* и PHPRC
в папке домена лежит тот же php.ini
но изменять его может только админ по запросу,
обычно просят изменить register_globals
А мы и под это расширение написали ;) Но тут уж сорри — корпоративный копирайт не позволяет сорцы отдавать (ВАХТЕР писался по собственной инициативе, а вот процессинг php_flag/php_value в .htaccess для suphp — коммерческий заказ непосредственно владельца серверов).
Я как представлю заживление suhosin у себя — брррр.
Не, я не готов снова отбивать 100+ жалоб в час (реальная цифра после перехода на PHP5 по-умолчанию)…
Не, я не готов снова отбивать 100+ жалоб в час (реальная цифра после перехода на PHP5 по-умолчанию)…
То есть мне не придется теперь проверять вводимые данные, прежде чем отравить запрос? ): Ну, право слово, всю романтику убивает.
странно что про suhosin никто не вспомнил
а помогает?
А зачем именно расширение?
Можно было бы просто…
rename_function('exec', '_exec');
override_function('exec','safe_exec');
ну и как вариант задать в safe_exec допустимые команды.
Можно было бы просто…
rename_function('exec', '_exec');
override_function('exec','safe_exec');
ну и как вариант задать в safe_exec допустимые команды.
Эм… Оно ж вроде только внутри скриптов работает.
А нам как то влом было лопатить скрипты 100+ аккаунтов :)
Посему спустились на уровень движка Zend, чтоб бить врага на подходах, так сказать.
А нам как то влом было лопатить скрипты 100+ аккаунтов :)
Посему спустились на уровень движка Zend, чтоб бить врага на подходах, так сказать.
Во-первых, rename_function и override_function — функции другого расширения APD. Какая разница, если нужно подключать APD вместо вахтера.
Во-вторых, как заметил br0ziliy, этот код нужно добавлять во все скрипты. И есть возможность и даже скорее всего так и будет, что php-шелл будет пускаться отдельным скриптом с обыкновенным exec. Как туда включить Ваш код?
Ну и в-третьих, мне очень хотелось ковырнуть php extensions :)
Во-вторых, как заметил br0ziliy, этот код нужно добавлять во все скрипты. И есть возможность и даже скорее всего так и будет, что php-шелл будет пускаться отдельным скриптом с обыкновенным exec. Как туда включить Ваш код?
Ну и в-третьих, мне очень хотелось ковырнуть php extensions :)
НЛО прилетело и опубликовало эту надпись здесь
чьорт моим ником прогу назвали
777 на лог-файл?? Вы его исполнять собрались?
А где припска «Не зануда»?
Ну привык я world-writeable permissions выставлять как 777. Да и chmod 666 как то не того… В системе и так демонов достаточно. 777 получше выглядит ;)
Ну привык я world-writeable permissions выставлять как 777. Да и chmod 666 как то не того… В системе и так демонов достаточно. 777 получше выглядит ;)
chmod a+w %)
При чем тут занудство?
А привычку Вы свою меняйте. Ибо негоже на логи ставить +x бит. Да и что тут такого в 666? Суеверность? Глупо в век цифровых технологих отмахиватся суеверием.
В любом случае правильное присвоение прав залог успеха.
А привычку Вы свою меняйте. Ибо негоже на логи ставить +x бит. Да и что тут такого в 666? Суеверность? Глупо в век цифровых технологих отмахиватся суеверием.
В любом случае правильное присвоение прав залог успеха.
В качестве здравой дискуссии…
Чем принципиально плохо назначение исполняемого бита файлу, который не планируется выполнять?
Не, я конечно сам любитель при случае пустить find ./ -type f -name *php -exec chmod 644 '{}' \; — хотелось бы услышать стороннее мнение.
Чем принципиально плохо назначение исполняемого бита файлу, который не планируется выполнять?
Не, я конечно сам любитель при случае пустить find ./ -type f -name *php -exec chmod 644 '{}' \; — хотелось бы услышать стороннее мнение.
Вставлю свои 5 копеек.
Я считаю что все зависит от контекста файла. Если это «надежный» файл, т.е. в него не попадет код какой-нибудь, который можно исполнить, то ничего страшного нету, в крайнем случае он просто не сможет выполнится. Если же файл «ненадежный», т.е. при каком-то стечении обстоятельств может попасть исполняемый код, то, естественно, это потенциальная уязвимость.
К тому же права 777 просто показывают всеобщий доступ (666 уже говорит о каких-то ограничениях).
С другой стороны, если обратится к первоисточнику (лог файл в папке /tmp с правами 777), то зря спорите. Естественно файл будет затираться, конечно же права 777 никуда не годятся… Просто это не конечный продукт, и основная его задача не «красиво писать логи», а вообще дать возможность писать логи ) Все мои силы были направлены на корректный оптимальный отлов событий.
Я считаю что все зависит от контекста файла. Если это «надежный» файл, т.е. в него не попадет код какой-нибудь, который можно исполнить, то ничего страшного нету, в крайнем случае он просто не сможет выполнится. Если же файл «ненадежный», т.е. при каком-то стечении обстоятельств может попасть исполняемый код, то, естественно, это потенциальная уязвимость.
К тому же права 777 просто показывают всеобщий доступ (666 уже говорит о каких-то ограничениях).
С другой стороны, если обратится к первоисточнику (лог файл в папке /tmp с правами 777), то зря спорите. Естественно файл будет затираться, конечно же права 777 никуда не годятся… Просто это не конечный продукт, и основная его задача не «красиво писать логи», а вообще дать возможность писать логи ) Все мои силы были направлены на корректный оптимальный отлов событий.
Я бы на него и 666 ставить не стал на Вашем месте. В Вашем случае еще веселее — любой кулхацкер может его сначала переписать своим контентом, а потом выполнить. Причем первое и второе может быть без труда проделано под разными юзерами.
Чем вам не угодили варианты вида 660, 600, где право записи можно отдать только тому, кому нужно?
Чем вам не угодили варианты вида 660, 600, где право записи можно отдать только тому, кому нужно?
Бро, тут же не в красоте дело, а в безопасности :)
а не подскажите ли, есть готовые способы логирования mail()?
Готовых — нет. У нас (опять же по корпоративному заказу) это реализовано php-расширением
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.
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.
писать логи нужно использую syslog
а уж в нем можно настроить запись на другую машину, так более безопасно
а уж в нем можно настроить запись на другую машину, так более безопасно
Статья — рщалоя и вот почему
1) Опасные функции можно банально отключить, php позволяет это делать
2) Для защиты от phpshell и тп очень помогает mod_security
1) Опасные функции можно банально отключить, php позволяет это делать
2) Для защиты от phpshell и тп очень помогает mod_security
Я конечно не админ, но скажу так:
1) exec и подобные ф-ции не всегда нужно отключать, но их нужно контролировать. Для этого и писался этот экстеншен. В дальнейшем планируется система правил. Какие-то вызовы можно разрешить, какие-то запретить вообще и т.п.
2) Вахтер не замена для mod_security, но очень ему помогает. Дыру можно прикрыть с помощью mod_security, но с помощью вахтера можно быстрее ее обнаружить и увидеть что шелл успел натворить в системе…
1) exec и подобные ф-ции не всегда нужно отключать, но их нужно контролировать. Для этого и писался этот экстеншен. В дальнейшем планируется система правил. Какие-то вызовы можно разрешить, какие-то запретить вообще и т.п.
2) Вахтер не замена для mod_security, но очень ему помогает. Дыру можно прикрыть с помощью mod_security, но с помощью вахтера можно быстрее ее обнаружить и увидеть что шелл успел натворить в системе…
1. зачем же так категорично? выше уже писали про imagemagic
2. не апачем единым, для nginx «ничего подобного нет и не предвидится»
Да и не всегда php-shell'ы используют во зло, вы не поверите.
2. не апачем единым, для nginx «ничего подобного нет и не предвидится»
Да и не всегда php-shell'ы используют во зло, вы не поверите.
Ну в том же творении товарища Сысоева, не столь давно была найдена дырка, которая кстати анонсировалась на Хабрахабр. Это. к сожалению в очередной раз доказывает мерзкую и противную аксиому «что один написал — другой может сломать» :)
Есть мысль написать статью про вахтер со стороны программиста. Конечно сроки я не знаю, но могу постараться.
pcntl_exec забыли. Еще подргузку библиотек придется отрубить (если не ошибаюсь, то ваш модуль не залогирует системные вызовы из подгруженной либы), а так же функции get_loaded_extensions, ini_get_all, phpinfo, ибо они могут скомпрометировать путь до логов
пардон, popen и proc_open забыл.
Я знаю про все эти ф-ции, просто еще не успел их заимплементить. Хотя там даже ничего сложного, за исключением pcntl_exec.
Вот про загрузку сторонних либ я не подумал, хотя насколько мне известно, просто так библиотеку трудно подключить, она должна лежать в папке с экстеншенами, куда без рута очень трудно положить файл (если система корректно настроена).
Вот про загрузку сторонних либ я не подумал, хотя насколько мне известно, просто так библиотеку трудно подключить, она должна лежать в папке с экстеншенами, куда без рута очень трудно положить файл (если система корректно настроена).
Еще нужно ловить copy, unlink и все-все-все, что работает с файлами, т.к. вместо имен файлов могуть быть вызовы системных команд. И доступ к unix-сокетам через fsockopen — тоже сомнительная деятельность. И наверняка еще можно придумать варианты.
т.к. вместо имен файлов могуть быть вызовы системных команд.
И вызов действительно произойдет? А в остальном согласен.
ой, промазал
Вроде как, все-таки, нет. Ошбися. см. ответ выше.
Гм, както не системненько, рвать зад, кодить подпорку, когда велосипед уже придуман:
ua.php.net/manual/en/features.safe-mode.functions.php
А нужно бинари — так покласть их куда нужно и позволить кому нужно.
ua.php.net/manual/en/features.safe-mode.functions.php
А нужно бинари — так покласть их куда нужно и позволить кому нужно.
Мне данная софтина уже помогла. Так что я сделал сборки пакетов для CentOS 5 (i386 и x86_64), качать можно тут: rpm.l0rda.biz/CentOS/5/RPMS/
ключик: rpm.l0rda.biz/L0RDA-KEY
ключик: rpm.l0rda.biz/L0RDA-KEY
Спасибо! Обновил топик.
А под какую версию ПХП сборку сделали?
в CentOS стандартный 5.1.6 сейчас
привет,
а измени плз ссылку в посте, чтобы не на рпм указывала, а на папку с ним, а то там уже апдейт был, и еще один будет на днях и ссылка изменилась
а измени плз ссылку в посте, чтобы не на рпм указывала, а на папку с ним, а то там уже апдейт был, и еще один будет на днях и ссылка изменилась
в следующей версии сделаю жесткие зависимости к версии php
НЛО прилетело и опубликовало эту надпись здесь
Проект живой? А то никаких обновлений уже давненько =(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вахтёр: на страже системы