Written by Kurt Seifried
WWW-трафик на сегодня один из главных компонентов использования Internet. Есть несколько популярных WWW-серверов для Linux, самый популярный, конечно, Apache (свыше 50% пользователей). Есть несколько новых WWW-серверов тоже с поддержкой SSL для безопасных соединений (для e-commerce). Этот раздел очень ориентирован на Apache, но поскольку он является сервером по умолчанию почти для всех дистрибутивов Linux (и *BSD), это имеет смысл. Я также написал о версии 1.3.9 сервера Apache, которая больше не использует access.conf или srm.conf, но взамен применяет httpd.conf.
HTTP работает на порте 80, протокол tcp, и если он предназначен только для внутреннего использования (Intranet или www-механизмы контроля firewall, например) его нужно закрыть с помощью firewall.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 80
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 80
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 80
или в ipchains:
ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 80
ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 80
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 80
HTTPS работает на порте 443, протокол tcp, и если он предназначен только для внутреннего использования (Intranet или www-механизмы контроля firewall, например) его нужно закрыть с помощью firewall.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 443
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 443
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 443
или в ipchains:
ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 443
ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 443
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 443
По умолчанию Apache работает как пользователь 'nobody', давая очень небольшой доступ к системе, и вообще говоря группа авторов Apache сделала превосходную работу по обеспечению безопасности. Вообще-то все www-серверы безопасны, все что они делают, это получают данные из системы и отсылают их. Опасность ждет Вас со стороны плохих CGI, server side includes и тому подобного.
Многие серверы, основанные на Apache (Red Hat Secure Server, Stronghold и другие) имеют исправленные ошибки, но в них появились другие проблемы. Скачать Apache можно с http://www.apache.org. Он также входит почти во все дистрибутивы как пакет программ.
Chroot'ing Apache
Если Вы хотите быть параноидальными, я предложил бы запускать Apache в chroot'ed среде, но это иногда создает больше проблем, чем решает. Выполнение этого разорвет очень многие вещи. Вы должны также установить многочисленные библиотеки, Perl и любые другие утилиты, которые Apache будет использовать, также как любые файлы конфигурации, к которым Вы желаете иметь доступ. Использование CGI также превратится в проблему.
Самый простой путь к установке chroot'ed просто поставить его, переместить и отредактировать некоторые файлы. Хорошая мысль: создайте каталог (например, /chroot/apache), предпочтительно на отдельной файловой системе и создать структуру файлов для Apache. В примере ниже просто поменяйте /chroot/apache на Ваш выбор. Вы должны, конечно, выполнить эти шаги как root. RPM поддерживает директиву “--root /some/dir”, что позволяет легко поставить Apache и все нужные библиотеки с помощью rpm. Используйте ldd, чтобы выяснить какие именно библиотеки нужны, и переместите их в каталог /chroot/apache (если Ваша система не поддерживает rpm).
[seifried@host seifried]$ ldd /usr/bin/httpd
libm.so.6 => /lib/libm.so.6 (0x40017000)
libc.so.6 => /lib/libc.so.6 (0x40060000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Apache протоколирует запросы и свою работу сам, так что не нужно ставить pseudo logging daemons вроде holelogd для передачи данных в syslog.
Самый простой способ ограничить доступ: создайте каталог /www или подобный и разместите в его иерархии ВСЕ данные, доступные для web-сервера: все сайты, cgi и прочее. Затем установите в access.conf запрет доступа к / и разрешите доступ к /www и разлиным его каталогам cgi-bin.
Пример httpd.conf:
<Directory />
Options None
AllowOverride None
</Directory>
<Directory /www >
Options Indexes FollowSymLinks Includes
AllowOverride None
</Directory>
Контроль доступа
Доступ к каталогам может также легко управляться, Apache поддерживает определение и размещение файлов (обычно упоминаемых как htaccess-файлы), которые могут управлять доступом, основываясь на username и пароле, IP-адресе происхождения и т.д. Это определено в файле srm.conf:
AccessFileName .htaccess
Формат этого файла подробно описан в документации на Apache и идентичен директивам в access.conf. Авторизация пользователей по username и паролю также подробно описана на http://www.apacheweek.com/features/userauth.
Если Вы хотите, чтобы никто не мог просмотреть файлы .htaccess, впишите в srm.conf:
<Files .htaccess>
order allow,deny
deny from all;
</Files>
Это запретит просмотр файлов с именем '.htaccess'.
apache-userdirldap
apache-userdirldap позволяет использовать каталог LDAP для просмотра домашних каталогов пользователей. Другими словами, можно переместить всех пользователей в структуру LDAP directory, и они будут авторизоваться через нее. Скачать можно с http://horde.net/~jwm/software/apache-userdirldap.
Простой сервер http для web-интерфейса (например, Phoenix Adaptive firewall использует такой интерфейс). Скачать можно с http://www.acme.com/software/thttpd
Я знаю, это звучит странно, но это правда. AOL Server это свободный www-сервер с доступными исходными кодами. К тому же, он поддерживает SSL и несколько других продвинутых свойств. Определенно, стоит посмотреть... Скачать можно с http://aolserver.com.
После установки и настройки www-сервера надо предоставить доступ к файловой системе, чтобы пользователи могли выкладывать странички. Для этого есть 4 наиболее популярных способа, но о них позже.
webfs легкий www-сервер с поддержкой базовых функций, доступен на http://www.in-berlin.de/User/kraxel/webfs.html.
Simple Web Server полностью соответствует своему названию. Базовые функции и никаких наворотов. Скачать можно с http://linuxstuffs.cjb.net.
Простой и быстрый www-сервер, скачать можно с http://www.cs.rice.edu/~vivek/flash.
Имеется несколько свободных и несколько коммерческих вариантов Apache с SSL. Здесь Вас ждут бюрократические рогатки, связанные с политикой разных государств относительно стойкой криптографии. Что ж, регулирование интернета пока ни у кого не получилось, хотя и пытались... Есть несколько статей в которых подробно рассматриваются защищенные серверы:
Это то, которое я в настоящее время использую (просто потому, что я пробовал прежде Apache с mod_ssl, и это работало). Вам понадобится счкачать Open-SSL, откмпилировать и поставить его, а затем поставить патч Apache-SSL для Apache и пересобрать Apache. Open-SSL доступен на http://www.openssl.org, просто скачайте последний tarball, распакуйте его и выполните:
./config
make
make test
make install
Затем получите Apache-SSL stuff с http://www.apache-ssl.org, распакуйте куда-нибудь исходники Apache, cd в каталог верхнего уровня (например, /usr/local/src/apache_1.3.9) и распакуйте сюда же Apache-SSL stuff. Затем просто запустите:
./FixPatch
Это должно работать (если не работает, прочтите инструкцию в README.SSL), затем настройте Apache как обычно, выполните make, затем make install. Теперь читайте раздел "Создание сертификатов".
Apache с mod_ssl доступен на http://www.modssl.org. Я его почти не тестировал.
Создание сертификатов
Это простая часть, следующий шаг должен создать набор ключей и затем конфигурировать httpsd.conf, чтобы использовать их. Найдите, где установлен "openssl" и убедитесь, что он прописан в path, затем cd туда, где лежат файлы настройки Apache. Если нужно создать тестовый сертификат для внутреннего пользвания, скомандуйте:
openssl genrsa -des3 > httpsd.key
openssl req -new -x509 -key httpsd.key > httpsd.crt
Браузеры будут громко жаловаться относительно этого сертификата, потому что он создан человеком, который его подписал, и они недоверяют ему. Если Вы хотите генерировать сертификат и запрос удостоверения, чтобы послать кому-то подобно Thawte или Verisign, скомандуйте:
openssl genrsa -des3 > httpsd.key
openssl req -new -key httpsd.key > httpsd.csr
Вы можете также получать реальные сертификаты с ограниченным сроком действия (обычно неделя или две) от Verisign, чтобы использовать для тестирования их в среде "реального мира".
Настройка Apache для работы с SSL
Имеется несколько вещей, которые Вы будете должны добавить к Вашему файлу конфигурации Apache, чтобы получить Apache с SSL-расширениями, фактически делающими что-нибудь полезное с Вашими сертификатами. Вы будете должны добавить некоторые глобальные параметры настройки конфигурации (обратите внимание, что они применимы для 1.3.9 и не будут работать в более ранних версиях Apache):
# you will need to tell apache to listen to port 443, by default
# it only goes for 80
Listen 443
# if you use more then one secure site on an IP (BAD IDEA) you will need:
NameVirtualHost 10.1.1.1:443
#it's a good idea to disable SSL globally and enable it on a per host basis
SSLDisable
# SSL cache server, without this your server will die
SSLCacheServerPath /usr/bin/gcache
# port the cache server runs on
SSLCacheServerPort 12345
# timeout for the SSL cache, set shorter for testing, 300 is a good
# "real world" value
SSLSessionCacheTimeout 300
Создайте виртуальный хост с поддержкой SSL:
<VirtualHost www.example.com:443>
DocumentRoot /www/secure
ServerName www.example.com
ServerAdmin example@example.com
ErrorLog logs/https_error.log
TransferLog logs/https_access.log
# enable SSL for this virtual host
SSLEnable
# this forbids access except when SSL is in use. Very handy for defending
# against configuration errors that expose stuff that should be protected
SSLRequireSSL
SSLCertificateFile /usr/conf/httpsd.crt
# if the key is not combined with the certificate, use this
# directive to point at the key file. [OPTIONAL]
SSLCertificateKeyFile /usr/conf/httpsd.key
# If you want to require users to have a certificate you will need
# a bundle of root certificates so you can verify their personal certificates
#SSLCACertificateFile /etc/ssl/ca-cert-bundle.pem
SSLVerifyClient none
</VirtualHost>
Red Hat Secure Server основан на Apache. По существу, это Apache с RSA cryptographic модулями (которые являются тем, за что Вы платите по существу) и можете также обслуживать стандартные (не cryptographic) http запросы. Из-за бюрократии, он продается только в США и Канаде, но реально сильная криптография давно используется всеми и везде. Red Hat Secure Server стоит $100 US и Вы получает скидку в $25 на Thawte-сертификат сайта (в результате такой сертификат будет стоить еще $100 US). Купить Red Hat Secure Server можно на http://store.redhat.com/commerce.
Roxen еще один коммерческий www-сервер с поддержкой https, доступен по GPL. Вы можете свободно скачать его, если Вы находитесь в Объединенной Европе, Австралии, Канаде, Японии, Новой Зеландии, Норвегии, США или Швейцарии. Версия со “слабой” (40 бит) криптографией может быть загружена из любой страны без проблем. Roxen доступен на http://www.roxen.com.
Zeus www-сервер высшего уровня с поддержкой SSL. Это коммерческий продукт, и Вы можете получить 30-дневную демонстрашку с http://www.zeustechnology.com.
Пока на тестировании (но ставится и работает нормально) для Linux, доступен на http://www.iplanet.com/downloads/iwsonlinux.html.
IBM также сделала HTTP-сервер для Linux (основанный на Apache), который можно скачать с http://www-4.ibm.com/software/webservers/httpservers/download.html.
Теперь надо обновлять файлы на сервере... Зайти и использовать текстовый редактор (даже если у Вас shell-доступ) не самая лучшая мысль. Писать файлы на другой машине, а потом синхронизировать с сайтом... Бр-р, я сам этим занимаюсь, и должен сказать, что такая система заставляет о дальнейшем совершенствовании процесса. Есть несколько популярных пакетов HTML-разработки, способных обновлять сайт самостоятельно по FTP или windows file sharing.
Классический способ предоставления доступа пользователям к ftp-серверу. Пользователи имеют обыкновение читать чужие файлы, лазать везде, куда дотянутся, и вообще портить жизнь сисопу. Chroot’ing ftp-сессий решает большинство этих проблем, однако основная проблема с ftp, в том что шифрование username и пароля обычно является невыполнимым из-за факта, что большинство людей работают с клиентами FTP для Windows. Я рекомендую ProFTPD вместо WU-FTPD, ProFTPD имеет много лучшие средства управления доступом.
Samba полезен для деления www-каталогов Windows-клиентами, Вы можете хранить usernames и пароли, отдельно от системы (использование smbpasswd, лучше системной passwd) и шифрование входов в систему не проблема. Просто создайте non-browseable разделяемый ресурс и используйте директиву “ valid users”, чтобы ограничить, какие пользователи могут рассматривать общие данные. Например:
[www-example]
path = /www/www.example.org
valid users = someuser
read only = No
browseable = No
Будет установлен довольно безопасный общий ресурс для каталога “/www/www.example.org”, к которому только пользователь “example” сможет обращаться.
FrontPage одна из наиболее популярных программ HTML для пользователей Windows (я сам ей пользуюсь). Она может говорить непосредственно с WWW-серверами и обмениваться данными с сайтом (называемым “FrontPage Site”), если сервер поддерживает расширения FrontPage. Они свободно доступны для различных UNIX-платформ с Ready To Run Software http://www.rtr.com. Есть коммерческие альтернативы, например, Instant ASP доступен на http://www.halcyonsoft.com. Хорошее описание взаимодействия FrontPage с Apache 1.3.X есть на http://www.itma.lu/howto/apache.
RearSite представляет собой cgi-программу для предоставления пользователям доступа к их каталогам через обычный web-браузер. Скачать можно с http://listes.cru.fr/rs/fd.
Fast Webpage Exchanger сам синхронизирует файлы через ftp и имеет удобный файл настройки. Скачать можно с http://www.enjoy.ne.jp/~gm/program/iwe_en.html.
WebRFM (Web-based Remote File Manager), CGI-программа (на Perl), позволяет пользователям управлять своими файлами. Скачать можно с http://webrfm.netpedia.net.
|
Written by Kurt Seifried |