Все лгут
Вчера наткнулся на недокументированные функции ionCube Loader, сегодня набрёл на давний пост на форуме ionCube, где Nick Lindridge (гендиректор ionCube Ltd или кто-то в этом духе) рассказывал интересующемуся пользователю, что функции _dyuweyrj4() и _dyuweyrj4r() при вызове возвращают «жемчужины мудрости». Далее »
Окт
2010
Интересно…
Как выяснилось, у ionCube Loader есть две недокументированных настройки в ini-файле: phpd.t и phpd. Что интересно, если значение phpd отлично от единицы или On, ionCube вылетает на зашифрованных файлах.
А еще у ionCube есть несколько недокументированных функций:
_dyuweyrj4()— при вызове без аргументов выдаёт «умные фразы» типаDo good, reap good; do evil, reap evil.илиA rat who gnaws at a cat's tail invites destruction._dyuweyrj4r()— аналогично предыдущей;ioncube_loader_iversion()— возвращает версию ionCube Loader в числовом виде:XYYZZ(например, 3.3.20 будет 30320);ioncube_file_not_permissioned()— судя по всему, эта функция оставлена для обратной совместимости со старыми скриптами: выдаёт ошибку видаThe file %s is not permissioned for this server._il_exec()— а это очень интересная функция: просто так её не вызвать. Но именно она ответственна за выполнение зашифрованного содержимого.
Окт
2010
Google XML Sitemaps: убираем версию и сигнатуру из карты сайта
После установки различных плагинов, отвечающих за псевдобезопасность сайта — например, путем сокрытия используемой версии WordPress, имён и версий установленных плагинов и т.п. — обычно выясняется, что они не могут справиться с Google XML Sitemaps: он как выдавал секретные данные о версии WordPress в карте сайта, так и продолжает их выдавать.
Очевидно, что это очень смущает людей, зацикленных на безопасности сайта.
К счастью, это лечится (во всех смыслах). Далее »
Автор: Wandering Soul, опубликовано в: Патчи, комментариев: 3Авг
2010
Борьба с ботами-взломщиками средствами rsyslogd
В предыдущих частях статей цикла «Скажи «Нет!» взломщику» со взломщиками мы боролись при помощи связки swatch + iptables: swatch проводил анализ системного журнала сообщений, iptables использовался для блокировки непрошеных гостей.
Тем не менее, используя swatch на нескольких серверах, я не могу сказать, что я полностью им доволен: слишком уж он хрупок. Завершение дочернего tail приводит к тихой гибели самого swatch, в системе могут оставаться зомби и т.п.
Одна из альтернатив — использование rsyslogd. Далее »
Апр
2010
Опять сломали!!!
В очередной раз разработчики WordPress ломают совместимость… Хотя справедливости ради стоит отметить, что затронуты будут далеко не все плагины, а только те, которые полагаются на то, что функция wp_nonce_field() создаёт в форме поле с именем _wp_http_referer. Далее »
Дек
2009
Скажи «Нет!» взломщику: часть 2
Продолжение статьи Скажи «Нет!» взломщику.
Прошлый раз мы использовали swatch и iptables для защиты от нехороших ботов, пытающихся сделать наш компьютер частью ботнета. У приведённого способа был существенный недостаток: IP-адреса блокировались навсегда. Это плохо, так как IP-адреса можно подделывать.
Tamdiu discendum est, quamdiu vivas, поэтому сегодня рассмотрим вариант с блокированием атакующего на заданный промежуток времени. Далее »
Автор: Vladimir, опубликовано в: Linux, Безопасность, комментариев: 2Дек
2009
Безопасный логин в WordPress с использованием nginx
WordPress, начиная с версии 2.6, имеет улучшенную поддержку работы с HTTPS.
У администратора есть две возможности:
- Использование HTTPS для работы в панели управления (
wp-admin). - Использование HTTPS только для входа в систему.
Первое достигается путём добавления строки
в wp-config.php, второе — путём добавления строки
Добавляем одну из этих двух строк в wp-config.php и проблема решена? Но в действительности всё не так, как на самом деле 
Далее »
Дек
2009
Профиль AppArmor для nginx
Данный профиль AppArmor предназначается тем, кто знает, что такое AppArmor и сознательно решил использовать профиль для nginx. Профиль не является законченным решением, работающим из коробки, а должен рассматриваться только как шаблон.
При построении профиля молчаливо предполагалось:
- рабочие процессы nginx выполняются от имени
www-data:www-data; - файлы конфигурации nginx находятся в
/etc/nginx(/etc/nginx/sites-enabled,/etc/nginx/sites-available,/etc/nginx/conf.d/*.conf,/etc/nginx/ssl); - пользовательские сайты расположены в
/home/<user>/htdocs; - логи записываются в
/var/log/nginx/*.log
Ноя
2009
ACL как одно из решений проблемы работы web-сервера под root
Я довольно часто встречал конфигурацию, когда web-сервер работает под root, чтобы обойти жёсткие права доступа, установленные на каталоги пользователей. Рассмотрим на примере: предположим, что пользовательские сайты расположены в /home/<username>/, при этом права на каталог home установлены в 0711 (rwx--x--x), а права на пользовательские каталоги установлены в 0700 (rwx------). Такие права устанавливаются, чтобы изолировать пользователей друг от друга — один пользователь не сможет зайти и посмотреть домашний каталог другого пользователя. Такая мера популярна у администраторов виртуального (shared) хостинга.
Для того, чтобы web-сервер мог нормально обслуживать сайты, обычно используется одно из следующих решений:
- web-сервер работает под учётной записью root;
- права на домашний каталог устанавливаются в 0750 (
rwxr-x---), а пользователь, под которым работает web-сервер, вносится в группу, которой принадлежит пользователь.
Ноя
2009
Простой DoS для PHP
Копался сегодня во внутренностях PHP, и обнаружил такую вещь: функция zend_hash_sort() (она вызывается из функций типа usort() и прочих) сортирует не сам массив (в терминах Zend Engine), а массив (в терминах языка C) указателей на элементы массива (в терминах Zend Engine), а потом по отсортированному C-массиву пересоздаёт PHP-массив. Далее »
Окт
2009
Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.
