Как известно, ISP Manager пользуется тем софтом, что идет по умолчанию в ОС. Увы, разработчики Debian не ставили своей целью сделать дистрибутив под массовый виртуалхостинг, по этому для грамотной установки придется воспользоваться некоторыми хитростями, о которых ниже будет написано более подробно:

• Использование PHP 5.2
• Защита от атак http slow
• Мониторинг дисков
• Логирование и анализ mysql
• Сокрытие листинга и phpmyadmin

Читать далее

В публичном доступе появился рабочий эксплойт, позволяющи получить удаленно рута в FreeBSD, если там запущен ftpd или proftpd. Более подробная информация по ссылке http://lists.grok.org.uk/pipermail/full-disclosure/2011-November/084372.html

Для запуска требуется указать логин и пароль юзера, который имеет chroot в ftpd и которому разрешено создавать в этом корне файлы /etc/nsswitch.conf и /lib/nss_compat.so.1. Туда заливается код, заливает туда код, который, будучи запущенным от рута, через ptrace подключается к inetd/syslogd/cron вне chroot и внедряет в них код, который открывает TCP-коннект от рута обратно к машине атакующего на заранее указанный порт, который там должен слушать nc -l или аналог и даёт root shell уже вне chroot. Подгружает /lib/nss_compat.so.1 сама libc, в ней уязвимость.

Против взлома кроме фильтрации доступа к порту 21 или через /etc/hosts.allow, ещё помогает либо полностью запретить юзеру запись в свой домашний каталог (можно оставить право на запись в существующие подкаталоги), либо запретить создавать /etc/nsswitch.conf и /lib/nss_compat.so.1 в домашнем каталоге юзера: touch etc lib && chflags uchg etc lib

Для штатного ftpd и ftp-пользователей, не имеющих другого доступа на запись к своему домашнему каталогу (через samba/http/whatever) есть и другое временное решение, не требующее что-либо менять в домашних каталогах пользователей: патч на ftpd, позволяющий администратору задавать гибкие ограничения в зависимости от логина пользователя и IP-сети, из которой он подключился. Он доступен по ссылке ttp://www.grosbein.net/freebsd/patches/ftpd-restr-0.2.tbz

После приложения патча, для защиты от данной дырки:

В /etc/login.conf поменять для класса default строчку:
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
на строчку:
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,NOMKD=/etc=0.0.0.0/0;/lib=0.0.0.0/0:\
Перегенерировать /etc/login.db командой cap_mkdb /etc/login.conf
После этого через ftpd будет нельзя создавать каталоги /etc и /lib и как временное решение это позволит спокойно прожить до официального исправления.

Для массового хостинга будет полезен скрипт, который запрещает создавать директории в качестве временного решения:

awk -F: '{print $6}' /etc/passwd | sort -u | xargs -n 1 -I . sh -c '[ -d . ] && [ ! -O . ] && cd . && touch etc lib && chflags uchg etc lib'

Будьте бдительны!

Я не буду писать о том, что это такое и зачем это надо. Раз вы зашли сюда, то привело наверное не праздное любопытство, а вполне конкретный вопрос — как прикрутить этот itk к cpanel.

Сначала вам нужно будет собрать php в режиме dso (mod_php) со всеми опциями и настройками, которые вы посчитаете нужными.

Затем сохраните копию mod_php, так как при сборке в MPM-ITK easyapache не делает dso для php:
cp /usr/local/apache/modules/libphp5.so /root
И сделайте исполняемый скрипт для восстановления /scripts/posteasyapache:
cp /root/libphp5.so /usr/local/apache/modules/
/etc/init.d/httpd restart
/usr/local/cpanel/bin/rebuild_phpconf 5 none dso enabled

Скачайте и распакуйте модуль для easyapache:
cd /root
wget http://docs.cpanel.net/twiki/pub/EasyApache3/CustomMods/MPMitk.tar.gz
tar -C /var/cpanel/easy/apache/custom_opt_mods -xzf MPMitk.tar.gz

После чего можно через easyapache или WHM выбрать опцию MPM-ITK.

Однако следует учесть, что это расширение просто добавляет режим работы apache без настроек, что совершенно теряет какой-то смысл. Для исправления этого надо создать еще один исполняемый скрипт /scripts/postwwwacctuser:
system("chmod -R 700 /home/$username/public_html");
system("mkdir -p /usr/local/apache/conf/userdata/std/2/$username");
system("echo \"AssignUserID $username $username\" >> /usr/local/apache/conf/userdata/std/2/$username/mpm.conf");
system("echo \"MaxClientsVHost 25\" >> /usr/local/apache/conf/userdata/std/2/$username/mpm.conf");
system("/scripts/ensure_vhost_includes --user=$username");

Этот скрипт будет выставлять правильные права на директорию с сайтом (только на чтение владельцу), включат работу apache от логина и ставит максимальное число одновременных коннектов в 25. Разумеется, что потом это значение всегда можно менять и при этом индивидуально для каждого.

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

В последнее время только и разговоров об REG.RU. К ним массово перевели домены, а они на каждый чих, кроме смены DNS, хотят увидеть ваши паспортные данные. Что собственно не очень-то и правомерно. Официально они могут требовать такие данные в случае жалоб на домен. Ну ладно, достаточно лирики, приступаем к переносу доменов.

Сразу следует отметить, что забрать можно только GTLD домены. Для RU/SU наличие паспорта является обязательным.

Итак, первое что надо сделать — снять с желаемого домена приватность. Во whois домена должен быть виден ваш email.

Затем идем по ссылке и получаем на свой email информацию о том, что этот домен у реселлера reg.ru. Отлично!

Открываем эту ссылку и заполняем форму, в которую копипейстим полученные данные и говорим, что домен таки наш. А злой реселлер не дает transfer code. Естественно, что писать надо с того же email, что и во whois домена

Затем ждем 4-е дня. Потому что суппорт будет безуспешно пытать REG.RU в течении 3-х дней, чтоб отдали вам домен. А на 4-ый он вышлет вам transfer code.

После чего можно будет перенести домен к любому понравившемуся регистратору, а за одно — продлить его на год.

Лично мной эта процедура была успешно проведена дважды, еще до того как домены «приплыли» к REG.RU — имел глупость зарегистрировать там пару в зоне COM.

P.S. Если вам помог мой совет — поставьте у себя ссылочку на эту статью. Буду очень благодарен!

P.P.S. Как заполнять форму жалобы:

Email Address: Ваш email, совпадающий с whois домена
Name: Ваше имя, транслитом
Category: Compilance
Domian Name: Имя домена
Summary: Reseller don't give me transfer code
Detailed support Request: Пишем такое письмо, после него прикрепляем информацию от реселлера:

Hi!

My Reseller don't give me transfer code. Please show whois of my domain. This is my email.

Please, sent me transfer code to whois email.

Thanks!

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Очень часто можно встретить множество проблем при смешивании 64-х и 32-х битных пакетов. По этому в самом начале работы, сразу на свежеустановленной центоси надо выкинуть все i386 пакеты:

rpm -qa --queryformat "%-{name}.%{arch}\n" | grep i386 | xargs  yum -y remove

И не забыть про i686:

rpm -qa --queryformat "%-{name}.%{arch}\n" | grep i686 | xargs  yum -y remove

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Вызов скрипта с аргументами: имя-домена место/с/файлами.

#!/bin/bash
cat <<EOF> /etc/nginx/conf.d/$1.conf
server {
		listen 80;
		server_name $1 www.$1;
		error_page 404 = @fallback;
		location / {
			proxy_pass http://127.0.0.1:80;
			proxy_redirect http://$1:80/ /;
			proxy_set_header Host \$host;
			proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
			proxy_set_header X-Real-IP \$remote_addr;
		}
		location ~* ^.+\\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
			root $2;
		}
		location @fallback {
			proxy_pass http://127.0.0.1:80;
			proxy_set_header Host \$host;
			proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
			proxy_set_header X-Real-IP \$remote_addr;
		}
	}
EOF

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Я провел достаточно много времени в поисках готового компилятора PHP для CentOS 5 и убедился, что подобной проблемой пока еще никто не занялся. Более того, базовый набор, даже с учетом всех дополнительных репозитаиев, не содержит необходимых пакетов для корректной установки HipHop-PHP.

Именно по этому я сделал локальный репозитарий, который позволяет исправить этот недостаток и поставить hphp или подготовить CentOS 5 для сборки из исходных кодов (рекомендуемый вариант).

Если вы хотите установить компилятор для php, то можете скачать готовые rpm файлы

Изменение в логике

Весь hiphop-php будет в /usr/lib (64)/hph/ а hphp и hphi создаются симлинками

Экспортируются переменные окружения

Если вы хотите собрать rpm сами, то все исходные srpm можно взять тут

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Ко мне поступил сервер с Linux CentOS 5.3 64bit, выполняющий роль коммерческого хостинга сайтов (WHM/cPanel), который был взломан и взломщики не потрудились вытереть за собой все инструменты, которые они использовали.
Проанализировав их, я смог составить цепочку событий, которая привела к взлому сервера и компрометации рутовой учетной записи.
Никаких логов небыло, так как они все были почищены, так что взломщик не оставил за собой следов, и я начал поистине детективное расследование — с уликами и подозреваемыми.

Все началось с того, что один из сайтов на хостинге был RFI, то есть использовал уязвимый движок, позволяющий выполнить удаленное подключение файла. И этот сайт был найден на хостинге при помощи сканера RFI.

После этого, используя найденную уязвимость, в /tmp заливается Remote Backdoor Shell — perl скрипт, открывающий доступ к командной строке сервера, работающий с правами вебсервера, в данном случае — nobody.
Через этот скрипт в /tmp были установлены

• набор взломщика (см. ниже)
• червь для автоматизации работы со сканерами RFI ботнета, само ищет сайты на Joomla 1.x, пытается взломать через них сервер и залить весь этот комплект, автоматически скачивает эксплойты с Milw0rm и пытается их применить(!) в публичном доступе мной не найден
• модифицированный сканер RFI, который исключает из проверки уже взломанные сайты, обмениваясь информацией по IRC с такими же скриптами ботнета, за основу взят FeeLCoMz RFI Scanner Bot
• скрипт для выполнения приказов типа scan, ddos и тд, простой, в публичном доступе мной не найден
• модифицированный Jheefry RFI Scanner Bot

Все скрипты написана на Perl и управляются через IRC на порту 6667, взломанный сервер заходит под случайным логином в
специальный канал на хаккерском IRC сервере, который в свою очередь так-же устанавливается скриптами на один из взломанных серверов.

Теперь о том, что включает в себя набор взломщика, который скрипты ботнета заливают автоматически:

• psybnc скрипты
• бинарный файл irc севера собранный статически и переименованный в httpd (!)
• бинарный файл proc неизвестного назначения, собран статически, и служит скорее всего для запуска irc сервера в контексте httpd (!)
• скрипт run: ./proc «/usr/local/apache/bin/httpd -DSSL» httpd JaM5, выполняющий подключение irc сервера в контексте httpd (!!!)
• бинарник неизвестного формата с названием xh, вероятно эксплойт, не рабочий, выполняющий подключение irc сервера в контексте httpd для FreeBSD

Итак, на сервере взломщики получили доступ к запуску файлов от имени вебсервера, но как же я определил, что они получили там доступ к root?

Когда я в профилактических целях остановил вебсервер httpd, то в процессах оставался висеть один httpd процесс. Как это возможно?
На самом деле это был perl скрипт, который маскировался под /usr/bin/httpd, тем самым себя выдав, так как httpd запускался из /usr/local/apache/bin/httpd. Он использовал маскировку под procname, где procname — имя процесса:

…
$rm="rm -rf";
qx ($rm $0);
$0 = 
$procname. "";
…
Но самое интересное было не это, а то, что файл с правами nobody находился в /var/lib/mysql, куда может писать только
пользователь mysql! И я решил проверить подозреваемого целостность пакета mysql-server:
#rpm -V MySQL-server
.M5...T /usr/sbin/mysqld
M — означало смену прав, 5 — содержимого (сравнение по MD5 хешу), T — времени. Само собой понятно, что был взломан именно mysql, тем более, что shell у пользователя mysql установлен в /bin/bash, чего быть не должно.

Итак, взломщик при помощи сканов уязвимостей ядра нашел лазейку в ядре, после чего использовал эксплойт для получения консоли с правом root и запустил руткит для mysqld, который при старте запускает бекдор, маскирующийся под процесс /usr/sbin/httpd!

Наказание за небрежное администрирование сервера, точнее — за его полным отсутствием, по причине желания экономии
на сисамдине заказчиком — форматирование и переустановка ОС, восстановление из резервных копий.
Ввыоды:

• perl под nobody — зло, suexec рулит
• исходящие коннекты с сервера —зло, но порой необходимое, а вот прикрыть irc порт никогда не помешает
• каждый скрипт должен работать от своего владельца, а не от nobody, fastcgi рулит
• надо своевременно обновлять ядро — отсутствие известных уазвимостей в публичном доступе еще не означает их отсутствие в ядре
• если смонтировать разделы, доступные пользователю на запись с noexec — любой эксплойт будет отдыхать

P.S. По ссылке — увлекательная история с ботнетом и infobox.ru.

UPD. Про perl, апач, nobody и suexec:
Все дело в том, что как правило скрипты на Perl запускают с правами владельцев через suexec. И это хорошо, так как в случае проблем будут видны права владельца, через которого закачали бэкдор.
Но если права на запуск Perl доступны для всех, то его можно запустить через функцию exec () PHP. А PHP работает у большинства хостеров от nobody.
Таким образом разрешение запуска Perl от nobody — зло, так как непонятно через какого пользователя заливают бекдор.

UPD2 — ЧАВО

• Уязвимость с ld.so, которая позволяла запустить бинарник с раздела, смонтированного noexec — уже давно закрыта.
• Для хаккера все равно какой ID будет в шелле — юзерский или апача. А сисадмину — это важно знать, так как будет видно какой пользователь имеет уязвимый сайт, просто сделав ps axuwf. Именно по этому php-fastcgi предпочительней mod_php
• Исходящие коннекты нужны для многих вещей — RPC-Ping'ов, Яндекс.Маркета, бирж ссылок, именно по этому невозможно закрыть все исходящие коннекты

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

Кроме интеграции nginx, я бы хотел немного поговорить о php. Как известно, он может работать в трех режимах — mod, cgi и fast-cgi. Наиболее быстрым является mod apache. Однако самым экономным в плане работы с оперативкой — fast-cgi.

Каждый решает сам для себя, что ему важнее — быстрее рисовать страницы или экономить память. Лично мой выбор — экономить память, тем более что с fast-cgi без проблем работают такие популярные движки как Wordpress, Drupal, Битрикс и многие другие.

Для контроля за fast-cgi я предлагаю использовать php-fpm. Это нормальная интеграция fast-cgi в php, которая позволяет плодить процессы, рестартовать их, корректно убивать и менять их число в зависимости от нагрузки.

Когда DirectAdmin создает нового пользователя, то вызывает скрипт user_create_post.sh  в /usr/local/directadmin/scripts/custom в который передает информацию о логине в переменной $username. Этим и воспользуемся, написав например такой скрипт, генерирующий кусок XML конфига для php-fpm:

#!/bin/shcat << EOF > /etc/fpm/$username.conf                <section name="pool">                        <value name="name">$username</value>                        <value name="listen_address">/home/$username/php</value>                        <value name="listen_options">                                <value name="backlog">-1</value>                                <value name="owner">$username</value>                                <value name="group">apache</value>                                <value name="mode">0660</value>                        </value>                        <value name="php_defines">                            <value name="sendmail_path">/usr/sbin/sendmail -t -i -f $username@$domain</value>                            <value name="upload_tmp_dir">/home/$username/tmp</value>                            <value name="session.save_path">/home/$username/tmp</value>                        </value>                        <value name="user">$username</value>                        <value name="group">$username</value>                        <value name="pm">                                <value name="style">static</value>                                <value name="max_children">2</value>                        </value>                        <value name="request_terminate_timeout">60s</value>                        <value name="rlimit_files">206103</value>                        <value name="rlimit_core">0</value>                        <value name="catch_workers_output">yes</value>                        <value name="max_requests">256</value>                        <value name="environment">                                <value name="HOSTNAME">$HOSTNAME</value>                                <value name="PATH">/usr/local/bin:/usr/bin:/bin</value>                                <value name="TMP">/home/$username/tmp</value>                                <value name="TMPDIR">/home/$username/tmp</value>                                <value name="TEMP">/home/$username/tmp</value>                                <value name="OSTYPE">$OSTYPE</value>                                <value name="MACHTYPE">$MACHTYPE</value>                                <value name="MALLOC_CHECK_">2</value>                        </value>                </section>EOFexit 0;

Теперь о nginx и генерации конфига. Устанавливаем nginx классическим образом как акселлератор на 85-ом порту и делаем проброс через iptables. Подключаем в конфиг чтение всех файлов конфигов из /etc/nginx/vhost/*

Когда создается домен или поддомен, DirectAdmin соответственно запускает domain_create_post.sh и subdomain_create_post.sh. Просто создадим эти скрипты, чтоб они добавляли конфиг в nginx и рестартовали его:

#!/bin/shcat << EOF > /etc/nginx/vhost/$domain.conf   server {        listen       $ip:85;        server_name  $domain www.$domain;        access_log  /var/log/httpd/domains/$domain.log  main;        root   /home/$username/domains/$domain/public_html;
                location / {                        fastcgi_pass unix:/home/$username/php;                        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;                        fastcgi_index  index.php;                        include        fastcgi_params;                }                location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {                        root /home/$username/domains/$domain/public_html;                        error_page 404 = @fallback;                }                location @fallback {                        fastcgi_pass unix:/home/$username/php;                        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;                        fastcgi_index  index.php;                        include        fastcgi_params;                }        }EOFkillall -s 1 nginxexit 0;

Если же надо оставить apache и просто отдавать статику nginx, то используем такой конфиг:

#!/bin/shcat << EOF > /etc/nginx/vhost/$domain.conf   server {        listen       $ip:85;        server_name  $domain www.$domain;        access_log  /var/log/httpd/domains/$domain.log  main;        root   /home/$username/domains/$domain/public_html;
                location / {                        proxy_pass http://$ip:80;                        proxy_redirect http://$ip:80/ /;                        proxy_set_header Host $host;                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;                        proxy_set_header X-Real-IP $remote_addr;                }                location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {                        root /home/$username/domains/$domain/public_html;                        error_page 404 = @fallback;                }                location @fallback {                        proxy_pass http://$ip:80;                        proxy_redirect http://$ip:80/ /;                        proxy_set_header Host $host;                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;                        proxy_set_header X-Real-IP $remote_addr;                }        }EOFkillall -s 1 nginxexit 0;

Изначально эта статья была на сайте http://hostinghelp.biz. Но Яндекс по какой-то причине забанил этот домен.
По этому копия будет опубликована на этом блоге. А сайт http://hostinghelp.biz ожидает перерождение.

#! /bin/sh -x
#
# демонстрация возможностей по управлению входящим (ingress) трафиком
# здесь приводится пример ограничения пропускной способности для входящих SYN-пакетов
# Может оказаться полезным для защиты от TCP-SYN атак.
#
#пути к различным утилитам;
#укажите правильные значения.
#
TC=/sbin/tc
IP=/sbin/ip
IPTABLES=/sbin/iptables
INDEV=eth2
#
# пометить все SYN-пакеты, пришедшие через $INDEV, числом 1
############################################################
$iptables -A PREROUTING -i $INDEV -t mangle -p tcp --syn \
  -j MARK --set-mark 1
############################################################
#
# установить ingress qdisc на входящий интерфейс
############################################################
$TC qdisc add dev $INDEV handle ffff: ingress
############################################################ #
#
# SYN-пакет имеет размер 40 байт (320 бит), отсюда -- три пакета
# имеют размер 960 бит (примерно 1 Кбит); ограничим скорость поступления
# 3-мя пакетами в секунду ( точнее -- 1 Кбит/сек )
############################################################
$TC filter add dev $INDEV parent ffff: protocol ip prio 50 handle 1 fw \
police rate 1kbit burst 40 mtu 9k drop flowid :1
############################################################
#
echo "---- qdisc parameters Ingress  ----------"
$TC qdisc ls dev $INDEV
echo "---- Class parameters Ingress  ----------"
$TC class ls dev $INDEV
echo "---- filter parameters Ingress ----------"
$TC filter ls dev $INDEV parent ffff:#Удаление ingress qdisc

#$TC qdisc del $INDEV ingress