Интернет и безопасность. Часть 2

Алексей Кошелев

Введение

Защита серверных приложений

Telnet и ssh

Почта, или e-mail

Доступ к файлам и сетевая печать

Web- и ftp-серверы

Сетевые атаки и взломы

Введение

В предыдущем номере в статье о безопасности Интернет-серверов были затронуты вопросы, связанные с выбором платформы и операционной системы Интернет-сервера, безопасностью сервера в целом, было рассказано о работе с пользователями, а также о работе и настройках firewall. Кратко напомню, что мы рассматриваем администрирование небольшой офисной или домашней сети, когда у вас имеется один или два выделенных компьютера. В первом случае, когда один компьютер, — это firewall плюс почтовый сервер, Web-сервер, а может быть, и ftp-сервер. Проще говоря, выделенный компьютер используется как некий общий ресурс. Во втором случае, который подразумевает наличие большой сети, один компьютер используется как шлюз плюс firewall, а второй — как сервер почты, Web-сервер и т.д. В принципе, второй способ предпочтительнее, так как вы физически отделяете шлюз как объект первого возможного удара при нападении хакеров и от общего сервера сети. В любом случае, в дальнейшем можно абстрагироваться от количества выделенных компьютеров, помня при этом, что даже если их два, загружать их другими заданиями неразумно.

Все нижесказанное продолжает линию предыдущей статьи, при этом подразумевается, что в качестве сервера используется Linux-машина, а пользователь знаком с Linux и сетями на базовом уровне. Идеи приводимых примеров заимствованы из различных руководств по Linux. Итак, какие же вопросы мы рассмотрим на этот раз? Во-первых, серверные приложения, которые вы захотите установить на сервере. Во-вторых, сетевые атаки (в том числе и типы вирусов в Linux и троянские кони) и методы борьбы с ними. Почему эти вопросы объединены в одной статье? Дело в том, что обычно взлом происходит либо из-за небрежности администратора, либо из-за прорех в защите серверных приложений. Клиент, как следует из самого этого слова, не распоряжается ресурсами системы, поэтому очевидно, что именно серверы могут стать предметом атаки.

Защита серверных приложений

Всякий, кто знаком с UNIX понимает, что почти любая сетевая программа может быть использована и как клиент и как сервер. В первом случае вы услугами пользуетесь, во втором — предоставляете их. Ясно, что в сетевом сервисе необходимы обе части. Вопрос в том, какие серверные программы нужны на сервере вашей сети. Устанавливая Linux, вы можете конечно выбрать хоть все, так как установка на диск еще не подразумевает запуска. Но какие из них потом активировать? Есть простой рецепт, которого я сам всегда придерживаюсь в работе с серверами, — чем меньше активированных серверов, тем лучше (если говорить в более общем плане: чем сложнее вещь, тем проще ее сломать). Сколько бы не твердили о надежности UNIX, здесь регулярно обнаруживаются и заделываются дыры. Поэтому чем меньше программ вы запустите, тем меньше за ними нужно будет следить. В реальной жизни это, разумеется, не должно сводиться к тому, что вы запрещаете пользователям буквально все. Это, конечно, безопасно, но зачем тогда вообще администратор? Однако ненужные вещи, типа wais, уж точно ставить не следует.

Telnet и ssh

А теперь более конкретно рассмотрим, что реально нужно и внутренним и внешним пользователям. Нужны telnet и ssh (secure shell). Может, это и не очень удобный доступ, но он необходим, по крайней мере администраторам. Это программа, обеспечивающая доступ в терминальном режиме, когда у вас на компьютере появляется окно 80x25 символов, полностью отражающее вызываемый сервер. Вы можете выполнять любые команды и запускать программы, не использующие графику, — в общем, это обычный удаленный терминал. Отличие telnet от ssh следует из названий, но все же поясним: telnet передает информацию незащищенной, даже пароль передается по сети открытым текстом, а ssh шифрует всю передаваемую информацию. Если вы хотите быть более-менее уверены в защите, то запретите использование telnet или вообще не запускайте его. Ну а если вы все же хотите использовать его, то, конечно, нужно применять firewall. Стандартные команды могут быть такие:

для ipfwadm —

ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 23
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 23
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 23

для ipchains —

ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 23

ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 23
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 23

Можно также использовать файлы /etc/hosts.allow и /etc/hosts.deny, для чего следует прописать, соответственно:

в первом файле —

in.telnetd: 10.0.0.0/255.0.0.0, some.trusted.host

во втором файле —

in.telnetd: ALL

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

Еще два важных файла, информация которых связана с безопасностью системы, — /etc/securetty и /etc/shells. Первый задает терминалы, с которых может входить пользователь root. В большинстве систем по умолчанию пользователь root может входить только с консоли. Второй файл задает список допустимых программ-оболочек, которые могут запускаться при входе пользователя. Красивый пример, который я почерпнул из руководства по Linux, — использование passwd в качестве shell. Это обеспечивает пользователям легкую смену пароля, а также гарантирует, что они больше ничего не будут делать в терминальном режиме. Для этого в файл /etc/shells нужно занести саму программу passwd, то есть вписать строчку:

/usr/bin/passwd

а в файл /etc/passwd вписать про пользователя:

username:x:1000:1000::/home/username:/usr/bin/passwd

Теперь, когда пользователь входит в сеть, он может только поменять пароль. Вывод на терминал имеет примерно следующий вид:

Trying 1.2.3.4…
Connected to localhost.
Escape character is '^]'.

Red Hat Linux release 5.2 (Apollo)
Kernel 2.2.5 on an i586
login: tester
Password:
Changing password for tester
(current) UNIX password:
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully
Connection closed by foreign host.

Даже если попытка поменять пароль была неудачной, произойдет отключение от системы. Следует обратить внимание и на стартовый вывод при подключении: telnet честно пишет имя системы и версию. Вообще, это удобно, но в таком случае вы даете потенциальному хакеру информацию, которую он может использовать в своих целях. Как этого избежать? При входе пользователя telnet отображает файл /etc/issue.net, создаваемый при старте системы. Он создается командами, стоящими в файле rc.local:

# This will overwrite /etc/issue at every boot. So, make any changes you
# want to make to /etc/issue here or you will lose them when you reboot.
echo "" > /etc/issue
echo "$R" >> /etc/issue
echo "Kernel $(uname -r) on $a $(uname -m)" >> /etc/issue
cp -f /etc/issue /etc/issue.net
echo >> /etc/issue

Поэтому, если вы не перегружаете систему, можно просто отредактировать файл /etc/issue.net, иначе — отредактировать сам rc.local. В любом случае, использовать telnet рекомендуется только тогда, когда это действительно необходимо и он не может быть заменен ssh.

Программа ssh с точки зрения пользователя аналогична telnet. В отличие от telnet, использующего 23-й порт, она использует 22-й, но основное внутреннее отличие состоит в том, что весь трафик кодирован. Во всем же остальном они схожи. Для ssh можно использовать те же самые правила firewall (с заменой номера порта) и установки в файлах /etc/hosts.allow, /etc/hosts.deny. Приятной особенностью является наличие собственного конфигурационного файла /etc/sshd/sshd_config, содержащего следующие конфигурационные строки:

Port 22
# номер порта, который может быть не только 22
ListenAddress 0.0.0.0
# какие адреса обслуживает демон
HostKey /etc/ssh/ssh_host_key
# файл кодов клиентов
RandomSeed /etc/ssh/ssh_random_seed
# файл случайных чисел, используемых при генерации кодов
ServerKeyBits 768
# длина кода в битах
LoginGraceTime 300
# время ввода имени и пароля
KeyRegenerationInterval 3600
# частота регенерации кодов
PermitRootLogin no
# может или нет пользователь root входить через ssh
IgnoreRhosts yes
# игнорировать или нет информацию из файла пользователя .rhosts
StrictModes yes
# строгий режим, блокирующий пользовательские огрехи, например ввод пароля 5 раз # или случайное нажатие enter
QuietMode no
# yes — чтобы не писать log-файл вообще и no — в противном случае
X11Forwarding no
# передавать информацию X-сервера по ssh-каналу
FascistLogging no
# степень полноты log-файлов
PrintMotd yes
# выдавать на экран некоторую фразу дня
KeepAlive yes
# поддерживать связь, обеспечивая стандартное разъединение
SyslogFacility DAEMON
# кто отвечает за создание log-файлов
RhostsAuthentication no
# допускать проверку пользователя через rhosts
RhostsRSAAuthentication no
# достаточна или нет проверка через rhosts или /etc/hosts.equiv
# по умолчанию это установлено в yes
RSAAuthentication yes
# использовать только проверку RSA
PasswordAuthentication yes
# использовать пользователям свои обычные пароли или нет
PermitEmptyPasswords no
# допускать пользователей без пароля или нет

Также есть некоторые полезные установки, в частности:

AllowGroups,
DenyGroups,
AllowUsers,
DenyUsers,
AllowHosts,
DenyHosts,
IdleTimeout time (время, по истечении которого связь будет прервана в случае неактивности).

Как следует из вышесказанного, в целом у ssh такое количество настроек, что вы можете точно прописать, кто и как может входить в систему. Но это касается сервера, а пользователи сети должны запускать ssh-клиенты. В отличие от telnet, который есть в Windows, ssh в стандартной поставке отсутствует. В Linux этой проблемы нет — клиент там тоже есть. Важно отметить, что ssh-демон имеется и в первой и во второй версиях. Неприятно, конечно, что нет обратной совместимости, но я уверен, что вы как администратор будете снабжать пользователей теми клиентами, которые смогут общаться с сервером. Вот некоторые ssh-клиенты для Windows:

• Fresh Free FiSSH. http://www.massconfusion.com/ssh/
• Tera Term. http://hp.vector.co.jp/authors/VA002416/teraterm.html telnet-клиент. http://www.zip.com.au/~roca/ttssh.html — дополнительная dll для поддержки ssh
• Putty. http://www.chiark.greenend.org.uk/~sgtatham/putty.html — всего около 200K
• Mindterm http://www.mindbright.se/mindterm/ — Java ssh-клиент
• The Java Telnet Application. http://www.mud.de/se/jta/ — есть поддержка ssh
• Secure CRT. http://www.vandyke.com/ — коммерческий клиент

О терминальном доступе необходимо упомянуть и в связи с программами типа rlogin, rexec, rsh. Их использование лишено всякой защиты и иногда даже позволяет пользователям попадать с машины на машину без ввода пароля. Это хотя и удобно, однако с точки зрения безопасности — просто никуда не годится. Такие сервисы обычно запускаются по умолчанию. Чтобы отменить их, нужно отредактировать файл /etc/inetd.conf и перезапустить демон inetd. В целом telnet и ssh исчерпывают возможности терминального доступа к системе. Поэтому перейдем к другим серверным приложениям, полезным для пользователей.

Почта, или e-mail

Что нужно, чтобы у людей была почта, без которой общение людей зачастую уже и не мыслится? Довольно распространенный способ — поставить почтовый сервер, завести там ящик на каждого пользователя и настроить pop-демон, чтобы люди могли эту почту забирать. Но для того чтобы сервер мог принимать и отправлять письма, на нем необходимо установить почтовую программу типа sendmail, postfix или qmail, обрабатывающую почту на UNIX-машине. Традиционно с этой целью использовался sendmail. Сейчас он тоже применяется на большинстве машин, но две другие упомянутые программы являются его хорошими и даже усовершенствованными заменителями. Как обычно, основные проблемы связаны с защитой, однако последние версии sendmail (8.9.x) являются вполне устойчивыми.

Sendmail имеется во всех Linux, причем последние дистрибутивы наверняка содержат версию 8.9.x. Программа использует несколько файлов конфигурации, которые она анализирует в процессе работы. Но прежде чем говорить о конфигурации, отметим, что программу можно запустить и как демон, и в режиме ожидания. В первом случае она будет постоянно слушать порт, а во втором — активироваться один раз и просто обрабатывать всю приходящую информацию. Второй способ предпочтительнее с точки зрения безопасности. Для этого в строке запуска нужно просто убрать параметр -bd.

Теперь о конфигурации. Основным является файл sendmail.cf, который может иметь (а может и не иметь) ссылки на другие файлы. Также анализируется файл access, где можно поместить такие адреса, с которых (или на которые) письма отправляться не будут. Например, записи:

10.0.0 RELAY
spam.com REJECT

означают, что письма с адресов .spam.com не будут приниматься, а письма из внутренней сети могут приниматься и отправляться.

Другой полезный и используемый файл — aliases. В нем задается, какие имена будут интерпретироваться как имя заданного ящика. Например, если задать

petrov: star

письма, приходящие Петрову по адресу petrov@host, будут направляться в ящик star@host, даже если кто-то не знает реального адреса. Это целесообразно, в частности, если вы хотите, чтобы письма приходили менеджеру, который хочет иметь почтовый ящик не с именем manager, а со своим собственным. Это означает, что менеджер будет давать свой адрес только тем, кому посчитает нужным, а на Web-странице будет висеть manager. Очевидно, что максимум удобства это принесет в случае смены менеджера. На один и тот же ящик можно перенаправить сколько угодно имен.

В файле virtusertable задается отображение одного адреса на другой, к примеру:

star@host manager

Используя эти два файла (aliases и virtusertable), можно осуществить дублирование почты, что позволит сохранять всю поступающую почту. Весь фокус в том, что вначале просматривается файл virtusertable, а затем aliases. Если с последней записью в virtusertable в файл aliases вписать:

manager: star, «/var/spool/mail2/star»

то почта, приходящая и на адрес manager, и на адрес star, будет записываться в нормальную директорию /var/spool/mail и в /var/spool/mail2.

Одно из основных отличий программы postfix от sendmail — модульность (которая присуща и qmail). В отличие от sendmail только маленькая часть кода, всего один модуль, запускается как root, а все остальные части запускаются по мере необходимости и имеют свои настройки. Вообще, конфигурационные файлы postfix обычно лежат в /etc/postfix. Файл manager.cf управляет работой различных модулей, задавая пользователей, под которыми они запускаются, и количество процессов. Файл main.cf является основным файлом конфигурации и задает основные параметры работы самой почты. Вот его примерный вид с пояснениями (точнее, те компоненты, которые скорее всего придется отредактировать):

# имя машины
myhostname = mail.example.org

# домен
mydomain = example.org

# от имени какого адреса вы отправляете письма
myorigin = $mydomain

# на каких интерфейсах работать программе
inet_interfaces = all

# файл виртуальных имен
virtual_maps = hash:/etc/postfix/virtual

# файл замен имен
alias_maps = hash:/etc/postfix/aliases

# директория, в которую нужно складывать почту, когда ее получает пользователь
home_mailbox = Maildir/

# где хранить почту
mail_spool_directory = /var/spool/mail

# команда изъятия почты
mailbox_command = /usr/sbin/scanmails

# файл с указанием адресов, почта с которых и на которые должна проходить
# беспрепятственно
relay_domains = /etc/postfix/relaydomains

# локальные машины
mynetworks = 10.0.0.0/24, 127.0.0.0/8

# что выводить, если пользователи подсоединяются к 25-му порту
smtpd_banner = $myhostname ESMTP $mail_name

Программу postfix можно получить по адресу http://www.postfix.org.

Теперь поговорим о протоколах POP и IMAP. Первый работает на 110-м порту, второй — на 143-м. В принципе, оба преследуют одну и ту же цель, но реализованы они по-разному. POP (post office protocol) — довольно старый и бедный протокол. Все, что он позволяет, это соединяться с сервером, получать почту и удалять ее из ящика на сервере. Протокол IMAP более продвинутый. Он позволяет управлять почтой прямо на сервере. Можно не скачивать всю почту, а забирать только заголовки писем, создавать каталоги на сервере и распределять почту по ним. С точки же зрения безопасности эти протоколы одинаковы, поэтому во избежание неприятностей желательно использовать firewall. Можно также поместить трафик этих протоколов внутрь ssh. Очень важно проверять почту на вирусы. Хотя в UNIX вирусы не страшны, но поскольку многие пользователи используют Windows, то разумно прогнать письма через программу-сканер, например AMAVIS. Проще всего это сделать (естественно, подразумевается, что программа AMAVIS уже установлена), если в postfix в строке конфигурации

mailbox_command

вместо:

mailbox_command = /usr/bin/procmail

вписать:

mailbox_command = /usr/sbin/scanmails

Коротко о том, как пользователь получает и отправляет почту на рабочем месте. К счастью, все популярные программы являются POP- или IMAP-клиентами (я имею в виду, по крайней мере, Netscape и Outlook). Плюс к этому, если администратор дал возможность доступа к серверу по telnet или ssh, вы можете просматривать почту и работать с ней в терминальном режиме (забрать ее в этом случае труднее). Для этого нужно соединиться с сервером и запустить в терминале какую-нибудь почтовую программу, типа mail или pine. Последняя гораздо более удобная и представляет собой полноэкранную программу с меню, только в текстовом режиме.

Доступ к файлам и сетевая печать

В UNIX-системе имеются два стандартных средства — NFS и LPD. Первое позволяет создавать сетевые файловые системы, второе — печатать на принтере. Что же касается использования ресурсов UNIX-машины из Windows, то для этого более всего, как мне кажется, подходит Samba (SMB). Эта программа позволяет получать доступ к файлам, а также предоставляет возможность сетевой печати с Windows-машины через UNIX-сервер. Поскольку эта статья в основном посвящена безопасности серверов, необходимо отметить, что разделение ресурсов внутри сети не является опасным, разумеется, при нормальной настройке внешних правил firewall. Здесь могут возникать проблемы иного плана, связанные с тем, что не все должны иметь доступ к той или иной информации, но это целиком регулируется настройками атрибутов файлов и каталогов. Каким бы проницательным администратором вы бы ни были, вы не сможете предотвратить ситуацию, когда, например, кто-то забудет закрыть сеанс работы с ssh и отойдет от компьютера. Другое дело, если вы дадите доступ на чтение каких-то файлов, но это слишком очевидные вещи, чтобы на них специально останавливаться. Поэтому теперь мы перейдем к рассмотрению серверных приложений, которые полезны не только внутренним пользователям, но и внешним. Я имею в виду в первую очередь Web-сервер и, быть может, ftp. Без первого сейчас трудно представить самую маленькую компанию или даже просто сеть, а наличие второго зависит от того, есть ли у вас реальная потребность отдельно выложить некоторые данные на ftp-сервер.

Web- и ftp-серверы

Среди ныне существующих нескольких Web-серверов по популярности и работоспособности бесспорным лидером является Apache. Этот сервер сочетает в себе скорость, стабильность, высокую защищенность, и при этом он бесплатный. Не всегда удается для своих целей найти такую программу, но здесь она есть. И нужно признать, что авторы программы прилагают очень много усилий, чтобы добиться максимальной эффективности и надежности. Прежде всего отметим, что если вы используете Web-сервер только для внутренних целей, таких как администрирование системы или разделение файлов, то его обязательно следует оградить от внешнего мира правилами firewall. Если же это сервер для всех, то необходимо понимать, что он открыт всем. Именно поэтому необходимо должным образом следить за ним, а именно: внимательно и правильно его настроить и контролировать log-файлы, чтобы определить возможную атаку заранее. Что же касается безопасности, то сам сервер имеет весьма малый доступ к системе, поскольку запускается как root только его первая копия, а остальные обычно запускаются от имени nobody. Кроме того, в настройках сервера, то есть в файлах httpd.conf, smr.conf, access.conf, четко указывается, к каким директориям сервер доступ имеет, а к каким нет. Если в файле httpd.conf прописать, например:

<Directory /> Options None
AllowOverride None
</Directory>

<Directory /www > Options Indexes FollowSymLinks Includes
AllowOverride None
</Directory>

то вы явно укажете, что сервер имеет доступ только к директории /WWW, куда и нужно поместить весь материал сайта (или сайтов), чью работу обеспечивает сервер. Если вы хотите быть уверенным, что никто не изменит прав доступа, включив, например, в какую-либо директорию файл .htaccess, то в srm.conf следует вписать:

<Files .htaccess>
order allow,deny
deny from all
</Files>

С точки зрения безопасности говорить подробнее о других настройках не имеет смысла, тем более что установка и минимальная конфигурация сервера Apache были описаны в предыдущем номере в статье, посвященной этой теме.

Следует отдельно остановиться на использовании протокола https (secure http). Этот протокол обычно работает на 443-м порту (в отличие от стандартного http, работающего на 80-м). Существует по крайней мере два способа обогатить Apache такой возможностью, как secure http. Первый — воспользоваться дополнением от open-ssl, второй — использовать модуль mod_ssl. Оба варианта приводят к почти одинаковым результатам. В общем и целом — появляется возможность устанавливать соединения, используя https по 443-м порту. При этом для сервера создается сертификат, который будет проверяться клиентами при подключении. Это позволит исключить (разумеется, не с абсолютной гарантией) прослушивание трафика. Для создания сертификата при использовании openssl нужно дать команды:

openssl genrsa -des3 > httpsd.key
openssl req -new -key httpsd.key > httpsd.csr

причем файлы должны быть в той же директории, где находятся конфигурационные файлы сервера. Для нормальной работы сервера с 443-м портом также придется изменить конфигурационные файлы. В них необходимо вписать что-то типа

# прослушивание 443-го порта (по умолчанию сервер слушает только 80-й)
Listen 443
# запрещение глобального использования ssl
SSLDisable
# место, куда сервер будет складывать временную информацию при ssl-соединении. Без
# этой установки сервер не будет работать
SSLCacheServerPath /usr/bin/gcache
# порт, через который сервер общается с CashServer
SSLCacheServerPort 12345
# время ожидания CashServer
SSLSessionCacheTimeout 300

После этих настроек ваш сервер в принципе готов к работе с https, но пока этот протокол запрещен. Целесообразно создать виртуальный хост, имеющий такое же имя, что и ваш стандартный, но с явным указанием 443-го порта, другими словами, сейчас у вас запущен Web-сервер. Он работает на 80-м порту и использует протокол http. Добавив apache-ssl и описанные выше настройки, вы дали пользователям возможность общаться с вашим сервером через протокол https. Вряд ли вся информация вашего сервера настолько засекречена, что вы хотите всю ее выдавать только в режиме защищенного соединения. Сервер Apache позволяет создавать виртуальные машины, то есть вы можете объявить какую-то поддиректорию корневой для некоторого хоста, дать ему имя, прописать набор конфигурационных файлов и все остальное, что необходимо, но физически он будет находиться на вашем компьютере и управляться будет вашем же сервером. В нашем случае даже не нужно давать другое имя, так как оно то же самое, только другой порт. Вот как могла бы выглядеть такая настройка:

<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
# Разрешение ssl для этого виртуального хоста
SSLEnable
# Требование использовать только ssl
SSLRequireSSL
SSLCertificateFile /usr/conf/httpsd.crt
SSLCertificateKeyFile /usr/conf/httpsd.key
SSLVerifyClient none
</VirtualHost>

Помимо http существует и ftp — полезный и удобный сервис, особенно если у вас много файлов, которые пользователи должны скачивать (к примеру, вы предоставляете данные каких-то исследований). Преимущество ftp перед http — это скорость. Протокол ftp имеет минимум служебной информации. Однако с ним и много проблем. Основная — его «возраст»: ftp так же стар, как и telnet. Отсюда сразу возникают сложности, связанные с безопасностью: имя пользователя и пароль передаются в открытом виде, а трафик передаваемой информации ничем не защищен. К тому же ftp умеет только передавать файлы. Поэтому если вы имеете некоторую информацию, которая доступна всем, то разумно создать одного пользователя, под чьим именем будут входить все. Часто в таких ftp-архивах этого пользователя зовут anonymous, а в качестве пароля он передает свой e-mail-адрес. В этом случае проблем с безопасностью уже гораздо меньше. Тем более в случае, когда нужно предоставить ftp-доступ нескольким пользователям, сделать chroot, чтобы они могли класть файлы только в свои директории. Что касается серверов, то, конечно, они имеются в стандартных поставках, но, быть может, вы захотите поставить не стандартный ftpd, а какой-либо иной.

Одним из популярных ftp-серверов является proftpd. Его конфигурационные файлы похожи на файлы Apache, что позволяет легче к ним адаптироваться, поскольку скорее всего ваш Web-сервер именно Apache. Основной файл конфигурации — /etc/proftpd.conf. Его примерный вид может быть таким:

ServerName "ProFTPD Default Installation"
ServerType inetd
DefaultServer on
Port 21
Umask 022
MaxInstances 30
User nobody
Group nobody
<Directory /*> AllowOverwrite on
</Directory>

В вышеприведенном листинге указано, что сервер запускается через inetd, на стандартном 21-м порту, максимальное число копий 30, а запускается он от имени группы и пользователя nobody. 022 — маска атрибутов файла при создании, которая будет стандартно накладываться изначально. Такая конфигурация не дает доступа пользователю anonymous. Чтобы сделать это, необходимо написать примерно следующие конфигурационные настройки:

<Anonymous ~ftp>
User ftp
Group ftp
RequireValidShell off
UserAlias anonymous ftp
MaxClients 10
DisplayLogin welcome.msg
DisplayFirstChdir .message
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>

После такого добавления появляется возможность работать как anonymous, причем только читать, то есть скачивать, файлы. Приведу еще один пример настройки прав пользования директориями:

<Directory incoming>
<Limit WRITE>
AllowAll
</Limit>
<Limit READ>
DenyAll
</Limit>
</Directory>

Такая запись в файле конфигурации дает доступ на запись, но не дает права скачивания файлов. Это удобно, если вы хотите, чтобы пользователи могли класть файлы, но не могли посмотреть, что положили другие.

На этом я закончу тему серверных приложений. Безусловно, следует отметить, что серверных приложений гораздо больше: существует еще DNS, серверы новостей, серверы NIS, X-сервер и множество других интересных и полезных приложений. Однако я постарался сделать упор на том, что реально может понадобиться при работе сети, которая не претендует на роль глобального киберполиса или провайдера. Теперь перейдем к рассмотрению второго вопроса, означенного в начале статьи, — к сетевым атакам и взломам.

Сетевые атаки и взломы

Прежде всего — несколько общих слов. В UNIX, в отличие от Windows, нет проблемы с вирусами. Внутренняя структура распределения памяти и прав доступа к файлам в состоянии сама справиться с тем, что обычно творят вирусы в старом DOS или Windows. Основным барьером для вирусов (в стандартном их понимании) является отсутствие доступа к физическим устройствам для программ, запущенных от имени обычного пользователя, а также то, что атрибуты файлов ставятся не вообще, а для пользователя, группы и всех пользователей. Такого в Windows нет (отчасти это реализовано в Windows 2000). Хотя неприятности, вызываемые традиционными вирусами, почти исключены, UNIX-системы все равно взламывают и рушат. Это связано с наличием совсем других технологий, которые можно условно разделить на две категории. Первая — это так называемые троянские кони, которые представляют собой программы, с виду, а может и на самом деле, выполняющие вполне разумные и легальные действия. Однако параллельно они ведут другую «работу»: прослушивают сеть или собирают информацию о паролях и посылают ее в сеть и т.п. Сами эти программы вряд ли могут принести непосредственный вред — скорее они будут посредниками между вашей системой и внешним взломщиком. Вторая категория — сетевые взломы. Эти акции изначально не апеллируют к внутреннему содержанию машины, а стараются разрушить систему или получить доступ к ней, посылая ей некоторую информацию, наподобие заведомо неправильных сетевых пакетов, либо путем специально сформированных запросов пытаются «выманить» какие-то скрытые данные. Зачем вообще нужно взламывать системы? Это вопрос скорее психологический, чем практический. Дело в том, что реально довольно большая часть взломов машин происходит не из корыстных целей, а просто из интереса к самому процессу. Среди людей, которых принято называть хакерами, не только те, кто совершает взломы для какой-то реальной выгоды, но и «энтузиасты», совершающие взлом сети ради самого взлома. Это кажется неожиданным, но это так, и об этом свидетельствует статистика. Кроме того, человека зачастую довольно сложно обвинить в содеянном, так как порой бывает невозможно доказать, что именно он и именно с этого компьютера производил те или иные незаконные действия. Однако в данной статье мы обсуждаем сами взломы, а не их психологические и юридические аспекты, и потому перейдем к конкретным вещам.

Взлом сети, как бы аккуратно он ни проводился и какие бы способы ни применялись, неизбежно приводит к некоторым изменениям в системе. Это может быть появление нового списка прослушиваемых портов, появление незнакомых программ, изменение размеров существующих программ, особенно типа ps или netstat, или даже новых пользователей. Так или иначе, суть в том, что что-то должно поменяться, и это неизбежно. Поэтому первое разумное действие, которое я советую осуществить сразу после установки и конфигурации системы, — это создание файла с информацией о системе. Что-то типа фотографии на тот момент, когда вы считаете все происходящее правильным. Если же говорить еще конкретнее, я имею в виду информацию, которую выдают программы netstat, vmstat, free, du, df. Второй совет — создавать резервные копии конфигурационных файлов системы и изначальных настроек. Их сравнение между собой тоже может дать некоторую информацию о том, что произошло в системе за последнее время.

Начнем с наблюдения за файловой системой, которое подразумевает не только слежение за использованием файловой системы (которое можно осуществить командами du и df), но и проверку на предмет неизменности тех или иных файлов (например, системных). Существует ряд программ, выполняющих эти функции:

• AIDE — программа, позволяющая создавать контрольные суммы для файлов, проверяя таким образом их целостность; позволяет использовать несколько алгоритмов. http://www.cs.tut.fi/~rammer/aide.html. (Остальные программы выполняют аналогичные функции, все они являются бесплатными.)
• L5 ftp://avian.org/src/hacks
• Gog&Magog — создает список атрибутов и владельцев файлов, позволяет автоматически делать сравнение. http://www.multimania.com/cparisel/gog/
• Sentinel — создает контрольные суммы, используя алгоритм RIPEMD-160bit MAC, имеет графический интерфейс. http://zurk.netpedia.net/zfile.html
• SuSEauditdisk — программа, помещаемая на дискету, что дает возможность производить проверку системы полностью автономно, загружаясь непосредственно с дискеты. Стандартно поставляется с SuSELinux. http://www.suse.de/~marc
• ViperDB — проверяет владельцев файлов и атрибуты, создавая log-файлы, в которых записывает произошедшие изменения. У программы есть три параметра: -init — создает базы данных по файлам, -check — проверяет файлы по базе и вносит изменения в базу, если они произошли на диске, -checkstrict — проверяет файлы по базе и возвращает старые параметры, если произошли изменения. http://www.resentment.org/projects/viperdb
• Sxid — создает контрольные суммы файлов и проверяет атрибуты и владельцев. ftp://marcus.seva.net/pub/sxid/
• nannie — запоминает время создания файла. ftp://tools.tradeservices.com/pub/nannie/
• confcollect — запоминает системную информацию, например установленного программного обеспечения, таблицы маршрутизатора и т.п. http://www.skagelund.com/confcollect/
• Pikt — средство, содержащее внутренний язык скриптов для создания программ, выполняющих стандартные, но не реализованные в виде конкретных команд функции (наблюдение за почасовым использованием системы, ликвидация долгоживущих процессов, установка размера почтового ящика и т.д.). Существует для разных платформ: Solaris, Linux и FreeBSD. http://pikt.uchicago.edu/pikt/

Можно также рассказать о программах, выполняющих функции резервного копирования, но, по моему мнению, это не имеет непосредственного отношения к безопасности системы, к тому же различные стандартные средства входят в поставки UNIX. К безопасности имеет отношение только то, что резервные копии делать необходимо, но об этом уже было сказано выше.

А теперь выясним, что делать для предупреждения сетевых атак. Конечно, нужно на шлюз установить firewall. Так или иначе, но защита на уровне пакетов необходима. Если firewall каким-либо способом обойден, то необходимы следующие программы:

• DTK — эмулирует стандартные сервисы и программы, и в случае нестандартных запросов, направляемых этим программам, происходит выдача заведомо ложной информации с целью запутать взломщика. http://all.net/dtk/
• Psionic PortSentry — отслеживает сканирование портов. Основная задача — проверять порты на сканирование и отображать все в log-файле. http://www.psionic.com/abacus/portsentry/
• Psionic HostSentry — создает базу информации об использовании машины пользователями, выдавая сообщение при нестандартном использовании ресурсов. http://www.psionic.com/abacus/hostsentry/
• Scanlogd — сканирует сетевые пакеты, создавая log-файлы в зависимости от настроек. http://www.openwall.com/scanlogd/
• Firewalls — это собирательное название программ, выполняющих функции firewall.
• TCP-WRAPPERS — программы, ограничивающие доступ к тем или иным ресурсам по имени либо номеру компьютера. Некоторые такие программы доступны по адресу. ftp://ftp.porcupine.org/pub/security/
• NFR — программа, по построению аналогичная снифферу (sniffer — программа прослушивания сетевого трафика). Производит запись log-файлов и в режиме реального времени осуществляет детектирование атак и сканирования портов. http://www.nfr.com/
• Подробный и полезный FAQ по сетевым атакам и их детектированию находится по адресу http://www.robertgraham.com/pubs/network-intrusion-detection.html.

Трудно однозначно ответить на вопрос, что и как следует делать при сетевых атаках. Здесь очень многое зависит от специфики как конкретной сети, так и той организации, в которой она находится. Даже при атаке одного и того же вида в одном случае вы захотите вначале спасти данные, а во втором — заблокировать источник атаки, то есть все зависит от приоритетов. Весьма сложную проблему атаки представляют в тех организациях, где остановка работы сети недопустима. Там вам придется проводить все операции online, по возможности сохраняя связь с внешним миром. Довольно много зависит и от характера атаки. Одно дело взлом ради взлома, а другое — целенаправленное похищение секретных данных. Может быть, правда, и более изощренный вариант, когда атака проводится с целью отвлечения администратора от более изощренного и продуманного взлома, проводимого параллельно. Но не думайте, что атака может прийти только снаружи. Она вполне может начаться изнутри. Вполне возможный сценарий — запуск троянского коня на Windows-компьютере внутренней сети. Очевидно, что такое можно сделать, просто послав письмо по почте. Теперь давайте чуть подробнее остановимся на программах-снифферах (sniffer).

Вообще sniff означает вынюхивать. Поэтому снифферами называют программы, которые тем или иным способом прослушивают сеть и всю проходящую по ней информацию. Наглядный пример — это пароль, идущий открытым текстом от внутреннего компьютера к серверу. Поскольку пакеты ходят по всей сети до тех пор, пока не найдут получателя, установка сниффера хотя бы на одном компьютере внутренней сети (например, при помощи письма, как было упомянуто выше) является удобным инструментом для внешнего взломщика. В большинстве случаев снифферы весьма пассивны, что делает трудным их детектирование. Ниже приведен перечень нескольких программ, которые играют роль сниффера и которые можно использовать для отслеживания того, что происходит в сети:

• Tcpdump — наиболее старая программа, поставляемая со всеми UNIX.
• Sniffit — имеет возможности фильтрации пакетов и перевода информации в текстовый формат; снабжена графическим интерфейсом. http://sniffit.rug.ac.be/~coder/sniffit/sniffit.html
• Ethereal — анализатор сетевых протоколов. http://ethereal.zing.org/
• Snort — предназначена для слежения за сетью, может определять сканирование портов. http://www.clark.net/~roesch/security.html
• SPY — сниффер, но не бесплатный. Существует бесплатная однопользовательская лицензия на сеть, состоящую не более чем из пяти машин. http://pweb.uunet.de/trillian.of/Spy/

 Не следует забывать, правда, что кроме программного есть еще и аппаратное прослушивание, например, просто подключение еще одного компьютера или просто подключение к кабелю. Любопытно, что если вы используете тонкий эзернет (коаксиальный кабель), то его можно прослушивать не вскрывая.

• AntiSniff — программа, сканирующая сеть на наличие снифферов. Принцип ее действия очень прост: она посылает запрос и по ответу и по времени ответа определяет, обрабатывается он какой-нибудь еще программой или нет. http://www.l0pht.com/antisniff/

Подробный и полезный FAQ по снифферам можно найти по адресу. http://www.robertgraham.com/pubs/sniffing-faq.html.

Еще одним приемом, который может помочь в предупреждении атак, является тестирование системы с помощью программ, эмулирующих атаки, или самих программ, с помощью которых эти атаки осуществляются. Вы как бы проверяете систему в боевых условиях. Если защита на самом деле является первоочередной задачей для данной конкретной машины, то проверка конфигурации системы перед включением в сеть является весьма важным этапом. Предлагаю вашему вниманию некоторые из таких программ.

Программы, которые сканирует систему саму по себе изнутри:

• Tiger — программа, до сих пор находящаяся в разработке. ftp://net.tamu.edu/pub/security/TAMU/
• check.pl — Perl скрипт, проверяющий дерево каталогов и файлы в нем и указывающий на различные сомнительные атрибуты и имена владельцев. http://opop.nols.com/proggie.html

Программы сетевого сканирования, указывающие на легкодоступные сервисы на другой системе (неплохая проверка настроек firewall, например):

• Strobe — старый, но быстрый и все еще эффективный сетевой сканер. Иногда включается в комплект поставки UNIX. ftp://suburbia.net/pub/
• Nmap — программа, использующая новые методы сканирования портов и имеющая много настроек. Позволяет получать параметры операционной системы (название, версию). http://www.insecure.org/nmap/index.html
• Portscanner — небольшой сканер портов, имеющий множество форматов выдачи обработанной информации. http://www.ameth.org/~veilleux/portscan.html
• Queso — не совсем сканер; это программа, предназначенная для определения типа операционной системы на удаленном компьютере. http://www.apostols.org/projectz/queso/

Программы сканирования возможных «прорех» защиты системы, несомненно, являются шагом вперед по сравнению со сканерами портов. Здесь применяется более высокий уровень анализа информации и определяются не сами открытые порты, а те уязвимые места в системе, к которым открыт путь через эти порты. Назову несколько таких программ:

• Nessus — программа для отслеживания атак, основанная на принципе «клиент-сервер». Серверы есть для Linux, FreeBSD, NetBSD и Solaris, а клиенты для Linux и Windows. Помимо сканирования портов и отслеживания атак программа может производить поиск по DNS с целью нахождения компьютеров, связанных со взламываемой машиной. http://www.nessus.org/
• Saint — потомок программы Satan, которая прежде была одной из самых популярных для сбора информации о машинах. Saint использует архитектуру «клиент-сервер», заменяя, правда, клиента Web-программой. Основная цель — сбор информации об уязвимых местах в защите системы. http://www.wwdsi.com/saint/
• Cheops — программа, составляющая карту сетевого IP-окружения с указанием запущенной на компьютерах операционной системы. http://www.marko.net/cheops/
• SARA (Security Auditor’s Research Assistant) — программа, аналогичная Saint. Может сканировать одновременно несколько машин, кроме того выдает результат работы в HTML-формате. http://home.arc.com/sara/
• BASS (Bulk Auditing Security Scanner) — программа, идеология которой основана на том, что Интернет не защищен. Главная задача — сканирование систем на наличие в них «дыр» защиты. http://www.securityfocus.com/data/tools/network/bass-1.0.7.tar.gz

Программой сканирования firewall и проверки правильности его настройки, является Firewalk. С помощью посылки различных пакетов программа стремится вычислить правила, в соответствии с которыми работает firewall. http://www.packetfactory.net/firewalk/

В архиве по адресу http://www.rootshell.com/ собраны известные данные о погрешностях в защите систем и ссылки на дополнения от производителей операционных систем, которые эти погрешности устраняют. Правда, иногда вместо такой ссылки можно увидеть сообщение «Upgrade to the next version», что обидно, особенно если система коммерческая. Такое, например, часто бывает с IBM AIX.

На этом я хотел бы закончить описание вопросов, связанных с безопасностью систем для Интернет- серверов. Именно описание, а не руководство к действию и не подробный справочник. Моей главной целью было дать представление о том, что нужно делать для защиты системы. Вполне вероятно, что в ряде случаев некоторые советы покажутся вам излишними или просто ненужными, а возможно, приведенных ссылок на программы окажется недостаточно. Однако, как мне представляется, основные моменты, связанные с защитой UNIX-систем и сетей, были в той или иной мере отражены. О некоторых частных вопросах, возможно, будет рассказано в следующих номерах журнала. 

КомпьютерПресс 3'2001