С демона по нитке

Andrushock

Xakep, номер #051, стр. 051-076-2

<Что в имени тебе моем, named?>

Вероятно, пингуя через небольшие промежутки времени пользующийся популярностью (читай загруженный) Web-узел, ты уже неоднократно замечал, что в ответ приходят пакеты с откликами echo-reply с различных IP-адресов. Такой трюк с закреплением за одним доменным именем нескольких айпишников применяется для распределения нагрузки между web-серверами. Его можно произвести как с помощью аппаратного обеспечения, например, оборудования от Cisco - Load Director, так и программного: демона named - сервера имен пакета BIND, на котором мы сейчас по-подробнее и остановимся. Согласно документу RFC 1035 вот так выглядит запись типа A базы данных DNS:

owner ttl class A address

Для примера закрепим за доменным именем www.xakep.ru следующие IP-адреса, которые будут возвращаться клиентам последовательно и в циклическом порядке, причем для быстрого устаревания адресов время жизни [ttl] установим равным одной минуте:

www.xakep.ru. 60 IN A 62.16.80.1

www.xakep.ru. 60 IN A 62.16.80.2

www.xakep.ru. 60 IN A 62.16.81.3

После такого определения DNS-сервер из своей базы будет циклически возвращать клиенту записи типа А вот в таком порядке:

для первого запроса - 62.16.80.1, 62.16.80.2, 62.16.81.3

для второго - 62.16.80.2, 62.16.81.3, 62.16.80.1

и для третьего - 62.16.81.3, 62.16.80.1, 62.16.80.2

Однако у этого довольно эффективного способа есть и ряд недостатков:

1) Демон named не определяет, "жив" выдаваемый им клиенту хост или нет;

2) Демон named не занимается балансировкой нагрузки;

3) Клиенты при повторном запросе могут получить предыдущий ответ из-за отрицательной разности между временем хранения в кэше данных промежуточного DNS-сервера и временем жизни для записей в базе DNS-сервера с механизмом round robin;

4) Атакующий может без особого труда вычислить цикл и число записей, поэтому теоретически вероятность взлома Web-сервера увеличивается во столько раз, сколько IP-адресов закреплено за именем.

<Дефиле с SQL’ем>

Держать информацию об учетных записях пользователей, имеющих доступ к ftp-серверу, в стандартных системных файлах /etc/passwd[group; shadow; master.passwd; pam.d/passwd] стало уже не модно :), поэтому рассмотрим вариант идентификации и хранения аккаунтов варезников с использованием SQL на примере связки Pureftpd + MySQL. Забираем с http://www.pureftpd.org/ последнюю версию Pureftpd, распаковываем, переходим в созданный каталог и конфигурируем при условии, что серверная и клиентская части MySQL уже получены с http://www.mysql.com/ и установлены в /usr/local/mysql:

$ ./configure --prefix=/usr/local/pureftpd --without-inetd --without-humor --without-banner --with-altlog --with-pam --with-ratios --with-ftpwho --with-quotas --with-throttling --with-mysql=/usr/local/mysql

$ make

# make install

Предоставим возможность пользователю shocker рулить mysql'ом со всеми базами:

$ /usr/local/mysql/bin/mysql -h localhost -u root -p

mysql> GRANT ALL PRIVILEGES ON *.* TO shocker@localhost IDENTIFIED BY 'my_password' WITH GRANT OPTION;

Назад на стр. 051-076-1  Содержание  Вперед на стр. 051-076-3

ttfb: 2.9549598693848 ms