Архив статей

Все статьи

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

Обзор интересных секьюрных фич


<Страсти по цгайкам>

Исходя из соображений безопасности, web-сервер Apache запускается и работает с правами непривилегированного пользователя nobody из группы nobody. В некоторых случаях на стороне сервера требуется, используя cgi-сценарии, динамически изменять содержимое документов от имени пользователя со специальными привилегиями, а также предотвращать возможность исполнения cgi-программ с неверно заданными правами доступа как к ним самим, так и к каталогам, в которых они находятся. Для решения такого рода задач служит механизм suExec. Проверить, включена ли поддержка cgi-анализатора в web-сервере можно с помощью команды:

$ /usr/local/apache/bin/httpd -l

[skipped]

suexec: disabled; invalid wrapper /usr/local/apache/bin/suexec

По умолчанию, модуль suExec не собирается во время установки индейца. Для его включения необходимо переконфигурировать и перекомпилировать Apache с указанием учетной записи (в данном случае hoster) для выполняемых cgi-сценариев, корневой директории, файла для журналирования событий, подкаталога пользователя, а также минимальных групповых и пользовательских идентификаторов, с которыми будет производиться работа. Но сначала добавим в систему новые группу и учетную запись hoster:

# groupadd -g 1001 hoster

# useradd -c `suExec user` -d /var/www/users/hoster -g hoster -s /bin/false -u 1001 hoster

./configure --prefix=/usr/local/apache --sysconfdir=/etc/httpd --datadir=/var/www --logfiledir=/var/log/httpd --enable-suexec --suexec-caller=hoster --suexec-docroot=/var/www/htdocs --suexec-logfile=/var/log/httpd/suexec.log --suexec-userdir=cgi-wrap --suexec-uidmin=1000 --suexec-gidmin=1000 --suexec-safepath=/usr/bin

$ make

# make install

$ /usr/local/apache/bin/httpd -l

[skipped]

suexec: enabled; valid wrapper /usr/local/apache/bin/suexec

Все, механизм suExec подключен, осталось добавить следующие строки в главный конфигурационный файл web-сервера:

# vi /etc/httpd/httpd.conf



User hoster

Group hoster

UserDir cgi-wrap

AddHandler cgi-script .cgi .pl





Options ExecCGI



Запустим демона Apache:

# /usr/local/apache/bin/apachectl start

Теперь создадим в каталоге /var/www/users/hoster/cgi-wrap простенький cgi-сценарий:

# touch test.cgi

# vi test.cgi

#!/usr/bin/perl

print "Content-type: text/html\n\n";

foreach $key (keys %ENV) {

print "$key --> $ENV{$key}
";

}

Определим для него права доступа:

# chown hoster:hoster /var/www/users/hoster/cgi-wrap/test.cgi

# chmod 755 /var/www/users/hoster/cgi-wrap/test.cgi

И для проверки правильности всех настроек скормим браузеру следующий URL: http://www.shellbox.ru/~hoster/test.cgi


При успешном выполнении сценария в журнальном файле /var/log/httpd/suexec.log появится запись типа:

[2002-10-11 01:24:22]: info: (target/actual) uid: (hoster/hoster) gid: (hoster/hoster) cmd: test.cgi

Следует отметить, что применять механизм suExec можно и для серверных вставок ssi, а также не только для персональных каталогов пользователей, но и для виртуальных хостов.

<Что в имени тебе моем, 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;

Скопируем из директории с сырцами ftp-сервера пример конфигурационного файла для базы данных и изменим в нем записи, связанные с именем пользователя, имеющего доступ к MySQL, его паролем, базой данных для pureftpd и методом шифрования паролей (по умолчанию разработчики предлагают нам insecure метод - хранить пароли plaintext`ом).

# cp pureftpd-mysql.conf /etc/

# vi /etc/pureftpd-mysql.conf

MYSQLUser shocker

MYSQLPassword my_password

MYSQLDatabase warezzz

MYSQLCrypt crypt

Остальные настройки в этом файле можно оставить без изменений. Настала очередь запустить ftp-сервер:

# /usr/local/pureftpd/sbin/pure-ftpd -4 -A -B -c 5 -C 3 -I 12 -E -H -k 90 -j -r -T 250:100 -l mysql:/etc/pureftpd-mysql.conf -O clf:/var/log/pureftpd.log

Для создания зашифрованных паролей с помощью функции crypt() библиотеки glibc воспользуемся программой htpasswd, которая входит в поставку Apache. Напомню, что во введенной строке для шифрации значащими являются только первые восемь символов, последующие символы ввиду специфики алгоритма отсекаются.

$ /usr/local/apache/bin/htpasswd -n -d xakep

Теперь подключаемся к MySQL, создаем базу данных warezzz и таблицу users, в которой будут храниться имя ftp-пользователя, его криптованный пароль, уникальные пользовательский и групповой идентификаторы, а также домашний каталог (если каталога в системе еще нет, то он будет автоматически создан при первом входе варезника на сервер и при запущенном pureftpd с ключом `-j`):

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

mysql> CREATE DATABASE warezzz;

mysql> SHOW DATABASES;

mysql> USE warezzz

mysql> CREATE TABLE users (

-> User varchar(12) NOT NULL default ``,

-> Password varchar(64) NOT NULL default ``,

-> Uid varchar(8) NOT NULL default ``,

-> Gid varchar(8) NOT NULL default ``,

-> Dir varchar(128) NOT NULL default ``,

-> PRIMARY KEY (User)

-> );

mysql> SHOW TABLES;

mysql> DESCRIBE users;

mysql> INSERT INTO users VALUES (`xakep`,`XQ4udTKGGiDxw`,`666`,`666`,`/home/xakep`);

mysql> SELECT * FROM users;

Обращу твое внимание, что работа с uid и gid в буквенном представлении возможна в том случае, когда они уже зарегистрированы в системе и в таблице users для них используется тип переменной varchar(). Если ты планируешь оперировать только виртуальными ftp-юзверями и цифровыми идентификаторами, то смело применяй тип int() вместо varchar().


<Портим статистику спайлогам>

Предоставление централизованного доступа клиентских машин в глобальную сеть, кэширование входящего трафика, ограничение пропускной способности интернет-канала, авторизация пользователей, обеспечение дополнительного уровня безопасности - все это входит в задачи кэширующего прокси-сервера Squid http://www.squid-cache.org/. Но сегодня нас будет интересовать не менее интересная функция кальмара – возможность подменять заголовки http-запросов клиентов с помощью директивы anonymize_headers. К примеру, изменим возвращаемые версии клиентских бродилок. Сначала запретим передавать данные о браузере, а затем модифицируем информацию о нем:

# vi /etc/squid/squid.conf

anonymize_headers deny User-Agent

fake_user_agent Bugzilla/6.6.6 (Andrushock build 13)

Перевести Squid в режим работы полупараноидального анонимного проксика можно с помощью вот таких директив:

# vi /etc/squid/squid.conf

forwarded_for off

anonymize_headers deny From Referer Server

anonymize_headers deny User-Agent WWW-Authenticate Link


Изменения вступят в силу после перезапуска squid:

# /etc/rc.d/init.d/squid restart

Теперь, указав браузеру клиентского хоста 192.168.158.100 использовать нашу анонимную проксю 192.168.158.118, запросим URL тестового web-сервера 192.168.158.216, в логах которого сможем обнаружить примерно следующие записи:

192.168.158.118 - - [07/Oct/2002:02:08:21 +0300] "GET /images/tuxracer.png HTTP/1.0" 200 302363 "http://192.168.158.216/" "Bugzilla/6.6.6 (Andrushock build 13)"

<Танцуем самбу>

Как правило, крупная домашняя сеть имеет гетерогенный характер, т.е. присутствуют машины как под управлением Windows, так и различных Unix-систем, и поделена на сегменты, каждый из которых имеет территориальную привязку: либо это этаж, либо подъезд, либо дом etc. Для контроля использования сетевых ресурсов в конкретном сегменте, для обеспечения дополнительного уровня безопасности и существенного ускорения работы клиентов в "Сетевом Окружении" часто требуется на роутерах оградить компьютеры, состоящие в разных рабочих группах, друг от друга.

В особо экстремальных обстоятельствах, когда, например, программа подсчета трафика была написана невменяемым кодером, или брандмауэр работает в режиме отладки, у нас нет возможности изменять правила firewall`a "на лету", поэтому роль "заглушки" в данном случае может выполнять пакет Samba http://www.samba.org/, предназначенный для совместного использования файлов и принтеров. Инсталляция не должна вызвать особых проблем, поэтому сразу перейдем к конфигурированию файла самбы с целью тотального ограничения доступа к расшаренным ресурсам заданной подсети 192.168.5.0 с маской 255.255.255.0.

# vi /etc/samba/smb.conf

/* список узлов и подсетей, которым разрешен доступ */

hosts allow = 192.168.5. 127.

/* сетевой интерфейс роутера, на который разрешено подвиснуть самбе */

interfaces = 192.168.5.1/24

/* насильно привязываем Samba использовать только указанный выше сетевой интерфейс */

bind interfaces only = yes

Запускаем демон winbindd:

# /etc/rc.d/init.d/winbind start


<Пароль рыба-ssh>

Иногда возникают ситуации, когда необходимо автоматизировать процесс резервирования (в определенное время запускать скрипт для переноса информации с одного узла на другой), либо приходится довольно часто вводить пароли, чтобы получить доступ к командному интерпретатору на различных узлах. В этих случаях очень удобно производить беспарольную аутентификацию на удаленном хосте с помощью защищенной оболочки OpenSSH http://www.openssh.org/ с использованием ассиметричных алгоритмов шифрования RSA и DSA.

В алгоритме шифрования с открытым ключом для шифрации и дешифрации данных применяется асимметричная пара ключей, состоящая из публичного и приватного ключей. Первый из них используется для шифрования, и его можно свободно распространять среди абонентов даже по незащищенным каналам. Второй ключ, отвечающий за дешифровку, необходимо держать в секрете. В настоящее время одним из самых популярных алгоритмов шифрования открытым ключом является алгоритм RSA http://www.rsasecurity.com/, предложенный еще в 1977 году американскими учеными Ronald Rivest, Adi Shamir и Leonard Adleman.


Для работы по протоколу SSH версии 2 следует убедиться, что на сервере в файле sshd_config присутствуют следующие строки:

Protocol 2,1

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

А в ssh_config (на сервере), либо в файле ~/.ssh/config на клиентской машине имеются такие настройки:

Protocol 2,1

IdentityFile ~/.ssh/id_rsa

Теперь сгенерируем пару ключей RSA протокола SSH2 без указания парольной фразы:

$ ssh-keygen -t rsa -N `` -C `Shell account` -f ~/.ssh/id_rsa

Скопируем полученный публичный ключ на удаленную систему:

$ scp ~/.ssh/id_rsa.pub my.shellbox.ru:~/.ssh/authorized_keys

Если файл authorized_keys уже существует, то просто добавим в него новый ключ:

$ scp ~/.ssh/id_rsa.pub my.shellbox.ru:~/

$ ssh my.shellbox.ru `cat ~/id_rsa.pub >> ~/.ssh/authorized_keys`

С этого момента, для того, чтобы войти на my.shellbox.ru достаточно набрать:

$ ssh my.shellbox.ru


Работа с ключами DSA протокола SSH версии 2 полностью аналогична описанной выше схеме. Для использования ключей RSA протокола SSH1 необходимо убедиться, что обе стороны поддерживают RSA1 аутентификацию. На сервере:

Protocol 2,1

RSAAuthentication yes

На стороне клиента:

Protocol 2,1

RSAAuthentication yes

IdentityFile ~/.ssh/identity

Сгенерируем пару ключей:

$ ssh-keygen -t rsa1

Скопируем открытую часть из пары ключей на удаленную систему:

$ scp ~/.ssh/identity.pub my.shellbox.ru:~/.ssh/authorized_keys

Насильно заставим клиента ssh использовать первый протокол SSH:

$ ssh -1 my.shellbox.ru

Конечно, при использовании этого бесспорно удобного метода существует немалый риск, так как злоумышленник, получивший доступ к секретному ключу на клиентской машине, автоматически становится обладателем шелла на удаленной системе, где применяется публичный ключ из этой пары. Альтернативным и более безопасным способом беспарольной аутентификации является использование демона-посредника ssh-agent, предназначенного для хранения парольной фразы секретного ключа. Сгенерируем пару ключей RSA, введем и подтвердим парольную фразу:

$ ssh-keygen -t rsa

Запустим программу ssh-agent так, чтобы его процесс породил еще один командный интерпретатор, но уже с измененными переменными окружения:

$ eval `ssh-agent`

И добавим в базу защищенного агента наш приватный ключ:

$ ssh-add ~/.ssh/id_rsa

На этом настройка закончена. Теперь можно установить соединение с удаленным хостом, не вводя ни пароль пользователя, ни парольную фразу для пары ключей:

$ ssh my.shellbox.ru

Если тебе нужно на время отлучиться от компа, и существует вероятность, что кто-то может воспользоваться твоим отсутствием в корыстных целях, просто выгрузи из кэша агента все ключи:

$ ssh-add -D


Установить брекеты в харькове на сайте ortodont.blogspot.com.