Архив за месяц: Октябрь 2009

Установка Centos 5.3 на Raid 1 (mirror)

Опубликовано автором
Добавить комментарий

Здесь я расскажу о установке ОС Linux — Centos 5.3 (Final) на Raid 1 (Зеркало).
Режим установки выбираем графический.
Запускается anaconda, в разделе инициализации дискового массива выбираем ручной режим.
В моем случае имеется четыре Sata_2 диска по 500GB в сервере HP proliant ML100 G5, которые я объединяю в две пары Raid_1 зеркал, получая двойную избыточность, надежность, практически без потери времени доступа к данным в режимах записи, чтения, поиска. Но при этом из двух терабайт всего пространства — получаем один терабайт, но — зато программный Raid_1 зеркальный массив.
1. Создаем необходимые разделы программного RAID на первом диске каждой пары, выбирая его из доступных устройств и устанавливая размер раздела, нажав кнопку RAID. (Допустим это будут sda1 — для /, sda2 — для /boot, sda3 — для /home и sdc1 — для /var, sdc2 — для /var/www, sdc3 — для /var/ftp).
Незабываем про отдельный swap…
2. Клонируем созданные разделы на первом из каждой пары дисков на второй диск. Для этого снова нажимаем кнопку RAID, и выбираем клонирование всего sda на sdb диск, внимательно выбрав весь диск в окне выбора разделов, и тоже проделываем с sdc и sdd диском, если у вас тоже есть вторая пара.
3. Объединяем созданные пары программных рейд дисков наших зеркал в md0, md1, …. mdN (Multiple drive), привязывая к ним точки монтирования, которые продумали заранее. Для этого снова нажимаем кнопку RAID и выбираем необходимое действие: sda1,sdb1->md0,…., sdc3,sdd3->mdN…

После создания рейд массива сохраняем нашу конфигурацию и продолжаем установку ОС до конца.

Если хотите проверить отказоустойчивость только что созданной системы на программном зеркальном рейде — отключите один из дисков, и попробуйте загрузиться. Диски должны подключиться и система должна работать в аварийном режиме.
Удачи!

Закрываем основные уязвимости Lenny

Опубликовано автором
Добавить комментарий

Итак, обновив наш debian до lenny, вооружившись сканером безопасности с сайта Securitylab.ru, обнаруживаем следующие уязвимости, пользуясь которыми возможен несанкционированный доступ к нашим службам, вплоть до получения полного контроля над системой:

1. Apache HTTP Server mod_proxy_ftp cross-site scripting (apache-modproxyftp-xss)
Межсайтовое выполнение сценариев в Apache HTTP Server.
Описание:
Межсайтовое выполнение сценариев в proxy_ftp.c и mod_proxy_ftp.c в модуле mod_proxy_ftp в Apache позволяет злоумышленникам, действующим удаленно, внедрить произвольный web-сценарий или HTML-код, используя групповой символ в пути в FTP URI.
Решение:
Пробуем пересобрать apache2 с динамическими модулями из последних исходников, но у меня нет времени, поэтому -
;) ) отключаем модуль mod_proxy_ftp, если он нам не нужен, удаляя ссылку/etc/apache2/mods_enabled/proxy_ftp.load
И перезапускаем apache2.
$sudo rm /etc/apache2/mods_enabled/proxy_ftp.load
$sudo /etc/init.d/apache2 restart

2. Apache HTTP Server и Squid Proxy Server
Доступен метод TRACE
Описание:
С помощью использования метода TRACE в протоколе HTTP возможно выполнение атаки межсайтовый скриптинг.
Решение:
Запретить выполнение данного метода:
Для отключения метода HTTP TRACE, устанавливаем:
TraceEnable Off — в /etc/apache2/apache2.conf,
или, запрещаем этот метод на уровне модуля mod_rewrite, разрешая в дальнейшем только доверенным хостам:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* — [F]
в файлах конфигурации /etc/apache2/… , или в файлах .htaccess наших сайтов.
Но первый способ — TraceEnable Off , более прямолинейный и надежный.

Продолжение следует….

Проверьте свой WP 2.8.* на опасную уязвимость url (MySQL Injection)

Опубликовано автором
Добавить комментарий

Если Ваш блог:

- не отвечает, или переадресован на другой сайт;
- или ссылки блога не работают;
- или Вы заметили автора, с правами администратора, который может редактировать Ваши записи, но которого нет в списке пользователей.
- или Вы просто заподозрили что Ваш сайт пытаются взломать…

Проверьте свои таблицы на опасную инъекцию, так как Ваш блог, скорее всего, был взломан!
Опасным кодом можете считать любые скрипты содержащие eval() или base64_decode() команды, которые найдете в своих файлах или таблицах баз данных.

Что делать в этом случае:

Открываем PhpMyAdmin и идем рассматривать таблицы нашего блога, первая таблица wp_options:

  • находим и удаляем запись содержащию _transient_rewrite_rules
  • редактируем запись, содержащую permalink_structure, если находим ее, удаляя запись:
    &({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&

Исправить ссылки также можно в админке блога http://your-site/wp-admin/options-permalink.php, если Вы используете постоянные ссылки.

Далее, в таблице пользователей wp_users:

  • ищем лишних пользователей, запоминаем их id и удаляем их,
  • а в таблице wp_usermeta удаляем все записи относящиеся к user_id = id тех пользователей, которых мы удалили.

А если есть доступ по ssh, то можно поискать инъекции так:

grep -H -r “eval(base64_decode)” /var/lib/mysql
grep -H -r “var setUserName = function” /var/lib/mysql

-> Если таблицы WP заражены, результат будет следующим:

Binary file /var/lib/mysql/database1/wp_usermeta.MYD matches
Binary file /var/lib/mysql/database2/wp_usermeta.MYD matches
Binary file /var/lib/mysql/databae3/wp_usermeta.MYD matches,

Где database1..3 — это Ваши зараженные базы данных.

Затем, из phpMyAdmin, найдите строки “var setUserName = function” во всех зараженных таблицах и удалите их!

Надеюсь это Вам поможет исправить последствия взлома!

p.s. Почему такой взлом стал возможен — разберем в следующем выпуске и закроем уязвимости