Определение сайта, на который идет DDoS

Данная статья имеет смысл, если на сервере установлен Nginx.

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

# vi /etc/nginx/nginx.conf

Меняем строку

access_log /var/log/nginx/access.log;

На

log_format main ‘$remote_addr — $remote_user [$time_local] $status «$host» «$request» $body_bytes_sent «$http_referer» «$http_user_agent» «$http_x_forwarded_for»‘;
access_log /var/log/nginx/access.log main;

И перезапускаем nginx:

# invoke-rc.d nginx restart

Если установлен Apache, то его желательно отключить, чтобы сервер не повис от нагрузки от атаки.

# invoke-rc.d apache2 stop

После чего ждем, чтобы access.log «поднакопил» данные от запросов.
Через некоторое время можно останавливать nginx и запускать следующую команду:

# tail -n 1000 /var/nginx/access.log | awk ‘{print $7}’ | sort | uniq -c | sort -n

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

# tail -n 1000 /var/log/nginx/access.log | awk ‘{print $1}’ | sort | uniq -c | sort -n

Есть и более простой вариант.

После того, как мы сделали свой log_format в Nginx и перезапустили его, можно просто запустить:
# tail -f /var/log/nginx/access.log

И мониторить запросы на наличие корректного браузера, реферрера и т.д.

Такие же манипуляции можно производить и с error.log’ом.

Установка и настройка Subversion (SVN) + mod_dav в Debian

Для начала обновляем информацию о пакетах:

# apt-get update

Устанавливаем subversion и mod_dav

# apt-get install subversion libapache2-svn

Создаем папку с репозиторием:

# mkdir /var/www/svn

Меняем владельца на www-data:

# chown www-data:www-data /var/www/svn

Настраиваем dav_svn

# nano /etc/apache2/mods-enabled/dav_svn.conf

Приводим к такому виду:

<Location /svn>
DAV svn
SVNParentPath /var/www/svn
AuthType Basic
AuthName «Subversion Repository»
AuthUserFile /etc/apache2/dav_svn.passwd
Require valid-user
</Location>
Создаем файл с пользователями
# touch /etc/apache2/dav_svn.passwd
Перезапускаем апач
# /etc/init.d/apache2 restart
Добавляем пользователя так:
# htpasswd /etc/apache2/dav_svn.passwd user_name
На этом все. Создаем репозиторий командой svnadmin create /var/www/svn/repo_name. Но об этом в другой статье.

Как разблокировать доступ к ISPManager по IP?

Если Вы ставили ограничение на вход в ISPmanager по IP и у Вас он сменился, достаточно просто изменить IP (в файле) или удалить этот файл:

/usr/local/ispmgr/var/userconf/ispmgr.root

Установка PEAR\HTTP_REQUEST в Debian

Сначала обновляем информацию о пакетах:

# apt-get update

Устанавливаем пакет php-pear

# apt-get install php-pear

Устанавливаем PEAR\HTTP_REQUEST

# pear install —alldeps HTTP_REQUEST

Перезапускаем апач:

# /etc/init.d/apache2 restart

Downgrade PHP 5.3 до PHP 5.2 в Debian

Вот, понадобилось вернуть стандартную для stable Debian версию PHP — 5.2.х.

Версия Debian 5.0.7

Для начала редактируем файл /etc/apt/sources.list

В моём случае нужно было удалить/закомментировать эти строчки:

deb http://php53.dotdeb.org stable all
deb-src http://php53.dotdeb.org stable all


Удаляем PHP:

# aptitude purge -y php5-cli php5-cgi php5-common

Далее обновляем информацию о пакетах:

# aptitude update

Обновляем кеш ISPManager’a:

# /usr/local/ispmgr/sbin/pkgctl cache

И устанавливаем PHP:

# /usr/local/ispmgr/sbin/pkgctl install php

Необходимо будет еще установить PHPMyAdmin и Webmail, если требуется.

ISPManager и MODx. Разрешение конфликтов

При заходе на http://site.com/manager — открывается ISPManager, а не админка MODx’a.

Решение такое.

Открываем ispmgr.inc:

# vi /usr/local/ispmgr/etc/ispmgr.inc

И меняем

Alias /manager /usr/local/ispmgr/bin/

На

Alias /ispmanager /usr/local/ispmgr/bin/

Сохраняем, закрываем.

Рестартим апач: (В Debian)

# /etc/init.d/apache2 restart

В CentOS:

# service httpd restart

Все. Теперь по адресу http://site.com/ispmanager — у нас будет открываться  ISPManager

Не могу зайти под рутом в FreeBSD (su sorry)

В кратце:

Имеем FreeBSD.

Логиниться на SSH рутом запрещено, есть доступ под рутом  в ISPManager. Создаем нового пользователя, напрмер sharkov.

Даем права на shell. Логинимся на ssh. Вводим su и видим:

su: Sorry

А это значит, что пользователь не состоит в группе wheel. Через midterm так же не пускает (ну ессно же =) ).

В общем нужно как-то посадить юзера в группу wheel. (Ну можно еще через встроенный файловый менеджер это сделать, или отредоктировать конфиг ssh). Но мы легких путей не ищем.

Вот мой извращенческий способ:

Добавляем задачу в крон (планировщик задач):

/usr/sbin/pw user mod sharkov -G wheel

И запускаем.

apr_sockaddr_info_get() failed

Если появилась такая ошибка в error_log’e, значит у Вас неверный хостнейм.

Решаем так:

# echo ‘site.com’ > /proc/sys/kernel/hostname

Меняем хостнейм в /etc/hostname

И перезапускаем в Debian:

# /etc/init.d/apache2 restart

В CentOS:

# service httpd restart

Как изменить URL репозитория SVN?

Все просто.

Заходим в папку с файлами. Вводим:

# svn info

Видим URL:

URL: file:///var/www/svn/site/branches/production

Теперь меняем на новый командой svn switch:

svn switch —relocate file:///var/www/svn/site/branches/production http://my.ip.add.r/svn/site/branches/production

Первый URL — адрес старого репозитория,

Второй — нового.

Убеждаемся, что все ОК:

# svn info

URL: http://my.ip.add.r/svn/site/branches/production

Вот так.

Порты и FreeBSD

При скачивании и распаковке портов имеем ошибки:

# portsnap fetch && portsnap extract
Looking up portsnap.FreeBSD.org mirrors… 5 mirrors found.
Fetching snapshot tag from portsnap2.FreeBSD.org… done.
Fetching snapshot metadata… done.
Updating from Tue Nov 9 14:35:59 MSK 2010 to Sat Nov 13 13:01:26 MSK 2010.
Fetching 1 metadata patches. done.
Applying metadata patches… done.
Fetching 0 metadata files… done.
gunzip: can’t stat: files/18e2c2d3e5e2ba6583fbe574fba1fa36efc7887046f25d20dd79971dd7b16390.gz: No such file or directory
Fetching 0 patches. done.
Applying patches… done.
Fetching 0 new ports or files… done.
Building new INDEX files… gunzip: can’t stat: /var/db/portsnap/files/c18a355ef772b8d5deaee48dcc48dc86e06a4252f7f4441a521621d194e9e0fb.gz: No such file or directory
gunzip: can’t stat: /var/db/portsnap/files/1ac36646f895592a28adc8af555c941402082a5ea43955c0e669324122ff28fe.gz: No such file or directory
done.

Решение:

Удаляем тэги и все, что связано со старым деревом:

# rm /var/db/portsnap/tag
# rm -rf /var/db/portsnap/files
# rm -rf /usr/ports

Скачиваеи и обновляем:

# portsnap fetch && portsnap extract

Готово!