|
Интернет и безопасность
Оформил: DeeCo Автор: Алексей Кошелев ВведениеЗащита серверных приложений 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: #0This will overwrite / etc / issue at every boot.So, make any changes you #0want 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 #0номер порта, который может быть не только 22 ListenAddress 0.0.0.0 #0какие адреса обслуживает демон HostKey / etc / ssh / ssh_host_key #0файл кодов клиентов RandomSeed / etc / ssh / ssh_random_seed #0файл случайных чисел, используемых при генерации кодов ServerKeyBits 768 #0длина кода в битах LoginGraceTime 300 #0время ввода имени и пароля KeyRegenerationInterval 3600 #0частота регенерации кодов PermitRootLogin no #0может или нет пользователь root входить через ssh IgnoreRhosts yes #0игнорировать или нет информацию из файла пользователя.rhosts StrictModes yes #0строгий режим, блокирующий пользовательские огрехи, например ввод пароля 5 раз #0или случайное нажатие enter QuietMode no #0yes— чтобы не писать log - файл вообще и no— в противном случае X11Forwarding no #0передавать информацию X - сервера по ssh - каналу FascistLogging no #0степень полноты log - файлов PrintMotd yes #0выдавать на экран некоторую фразу дня KeepAlive yes #0поддерживать связь, обеспечивая стандартное разъединение SyslogFacility DAEMON #0кто отвечает за создание log - файлов RhostsAuthentication no #0допускать проверку пользователя через rhosts RhostsRSAAuthentication no #0достаточна или нет проверка через rhosts или / etc / hosts.equiv #0по умолчанию это установлено в yes RSAAuthentication yes #0использовать только проверку RSA PasswordAuthentication yes #0использовать пользователям свои обычные пароли или нет PermitEmptyPasswords no #0допускать пользователей без пароля или нет Также есть некоторые полезные установки, в частности: AllowGroups, DenyGroups, AllowUsers, DenyUsers, AllowHosts, DenyHosts, IdleTimeout time(время, по истечении которого связь будет прервана в случае неактивности). Как следует из вышесказанного, в целом у ssh такое количество настроек, что вы можете точно прописать, кто и как может входить в систему. Но это касается сервера, а пользователи сети должны запускать ssh-клиенты. В отличие от telnet, который есть в Windows, ssh в стандартной поставке отсутствует. В Linux этой проблемы нет— клиент там тоже есть. Важно отметить, что ssh-демон имеется и в первой и во второй версиях. Неприятно, конечно, что нет обратной совместимости, но я уверен, что вы как администратор будете снабжать пользователей теми клиентами, которые смогут общаться с сервером. Вот некоторые ssh-клиенты для Windows:
О терминальном доступе необходимо упомянуть и в связи с программами типа 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 является основным файлом конфигурации и задает основные параметры работы самой почты. Вот его примерный вид с пояснениями (точнее, те компоненты, которые скорее всего придется отредактировать):
#0имя машины
myhostname = mail.example.org
#0домен
mydomain = example.org
#0от имени какого адреса вы отправляете письма
myorigin = $ mydomain
#0на каких интерфейсах работать программе
inet_interfaces = all
#0файл виртуальных имен
virtual_maps = hash: / etc / postfix / virtual
#0файл замен имен
alias_maps = hash: / etc / postfix / aliases
#0директория, в которую нужно складывать почту, когда ее получает пользователь
home_mailbox = Maildir /
#0где хранить почту
mail_spool_directory = / var
/ spool / mail
#0команда изъятия почты
mailbox_command = / usr / sbin / scanmails
#0файл с указанием адресов, почта с которых и на которые должна проходить
#0беспрепятственно
relay_domains = / etc / postfix / relaydomains
#0локальные машины
mynetworks = 10.0.0.0 / 24, 127.0.0.0 / 8
#0что выводить, если пользователи подсоединяются к 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 прописать, например:
то вы явно укажете, что сервер имеет доступ только к директории /WWW, куда и нужно поместить весь материал сайта (или сайтов), чью работу обеспечивает сервер. Если вы хотите быть уверенным, что никто не изменит прав доступа, включив, например, в какую-либо директорию файл .htaccess, то в srm.conf следует вписать: order allow,deny deny from all С точки зрения безопасности говорить подробнее о других настройках не имеет смысла, тем более что установка и минимальная конфигурация сервера 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), но и проверку на предмет неизменности тех или иных файлов (например, системных). Существует ряд программ, выполняющих эти функции:
Можно также рассказать о программах, выполняющих функции резервного копирования, но, по моему мнению, это не имеет непосредственного отношения к безопасности системы, к тому же различные стандартные средства входят в поставки UNIX. К безопасности имеет отношение только то, что резервные копии делать необходимо, но об этом уже было сказано выше. А теперь выясним, что делать для предупреждения сетевых атак. Конечно, нужно на шлюз установить firewall. Так или иначе, но защита на уровне пакетов необходима. Если firewall каким-либо способом обойден, то необходимы следующие программы:
Трудно однозначно ответить на вопрос, что и как следует делать при сетевых атаках. Здесь очень многое зависит от специфики как конкретной сети, так и той организации, в которой она находится. Даже при атаке одного и того же вида в одном случае вы захотите вначале спасти данные, а во втором— заблокировать источник атаки, то есть все зависит от приоритетов. Весьма сложную проблему атаки представляют в тех организациях, где остановка работы сети недопустима. Там вам придется проводить все операции online, по возможности сохраняя связь с внешним миром. Довольно много зависит и от характера атаки. Одно дело взлом ради взлома, а другое— целенаправленное похищение секретных данных. Может быть, правда, и более изощренный вариант, когда атака проводится с целью отвлечения администратора от более изощренного и продуманного взлома, проводимого параллельно. Но не думайте, что атака может прийти только снаружи. Она вполне может начаться изнутри. Вполне возможный сценарий— запуск троянского коня на Windows-компьютере внутренней сети. Очевидно, что такое можно сделать, просто послав письмо по почте. Теперь давайте чуть подробнее остановимся на программах-снифферах (sniffer). Вообще sniff означает вынюхивать. Поэтому снифферами называют программы, которые тем или иным способом прослушивают сеть и всю проходящую по ней информацию. Наглядный пример— это пароль, идущий открытым текстом от внутреннего компьютера к серверу. Поскольку пакеты ходят по всей сети до тех пор, пока не найдут получателя, установка сниффера хотя бы на одном компьютере внутренней сети (например, при помощи письма, как было упомянуто выше) является удобным инструментом для внешнего взломщика. В большинстве случаев снифферы весьма пассивны, что делает трудным их детектирование. Ниже приведен перечень нескольких программ, которые играют роль сниффера и которые можно использовать для отслеживания того, что происходит в сети:
Не следует забывать, правда, что кроме программного есть еще и аппаратное прослушивание, например, просто подключение еще одного компьютера или просто подключение к кабелю. Любопытно, что если вы используете тонкий эзернет (коаксиальный кабель), то его можно прослушивать не вскрывая.
Подробный и полезный FAQ по снифферам можно найти по адресу. http://www.robertgraham.com/pubs/sniffing-faq.html. Еще одним приемом, который может помочь в предупреждении атак, является тестирование системы с помощью программ, эмулирующих атаки, или самих программ, с помощью которых эти атаки осуществляются. Вы как бы проверяете систему в боевых условиях. Если защита на самом деле является первоочередной задачей для данной конкретной машины, то проверка конфигурации системы перед включением в сеть является весьма важным этапом. Предлагаю вашему вниманию некоторые из таких программ. Программы, которые сканирует систему саму по себе изнутри:
Программы сетевого сканирования, указывающие на легкодоступные сервисы на другой системе (неплохая проверка настроек firewall, например):
Программы сканирования возможных “прорех” защиты системы, несомненно, являются шагом вперед по сравнению со сканерами портов. Здесь применяется более высокий уровень анализа информации и определяются не сами открытые порты, а те уязвимые места в системе, к которым открыт путь через эти порты. Назову несколько таких программ:
Программой сканирования firewall и проверки правильности его настройки, является Firewalk. С помощью посылки различных пакетов программа стремится вычислить правила, в соответствии с которыми работает firewall. http://www.packetfactory.net/firewalk/ В архиве по адресу http://www.rootshell.com/ собраны известные данные о погрешностях в защите систем и ссылки на дополнения от производителей операционных систем, которые эти погрешности устраняют. Правда, иногда вместо такой ссылки можно увидеть сообщение “Upgrade to the next version”, что обидно, особенно если система коммерческая. Такое, например, часто бывает с IBM AIX. На этом я хотел бы закончить описание вопросов, связанных с безопасностью систем для Интернет- серверов. Именно описание, а не руководство к действию и не подробный справочник. Моей главной целью было дать представление о том, что нужно делать для защиты системы. Вполне вероятно, что в ряде случаев некоторые советы покажутся вам излишними или просто ненужными, а возможно, приведенных ссылок на программы окажется недостаточно. Однако, как мне представляется, основные моменты, связанные с защитой UNIX-систем и сетей, были в той или иной мере отражены. О некоторых частных вопросах, возможно, будет рассказано в следующих номерах журнала. |
Автор проекта: USU Software
Вы можете выкупить этот проект.