diff --git a/ru_RU.KOI8-R/books/handbook/security/Makefile b/ru_RU.KOI8-R/books/handbook/security/Makefile new file mode 100644 index 0000000000..5df9c11979 --- /dev/null +++ b/ru_RU.KOI8-R/books/handbook/security/Makefile @@ -0,0 +1,17 @@ +# +# Build the Handbook with just the content from this chapter. +# +# $FreeBSD$ +# $FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/handbook/security/Makefile,v 1.1 2001/07/11 16:40:15 phantom Exp $ +# Original revision: 1.1 +# + +CHAPTERS= security/chapter.sgml + +VPATH= .. + +MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} + +DOC_PREFIX?= ${.CURDIR}/../../../.. + +.include "../Makefile" diff --git a/ru_RU.KOI8-R/books/handbook/security/chapter.sgml b/ru_RU.KOI8-R/books/handbook/security/chapter.sgml index 701531abab..fdb227a5d9 100644 --- a/ru_RU.KOI8-R/books/handbook/security/chapter.sgml +++ b/ru_RU.KOI8-R/books/handbook/security/chapter.sgml @@ -1,2747 +1,5597 @@ + + + + Matthew + Dillon + Большая часть этой главы была взята из страницы справочника + security(7) которую написал + + + + Безопасность + безопасность + + + Краткое описание + + Эта глава представляет введение в основные концепции безопасности + системы, некоторые эмпирические правила и более подробно обращается к + отдельным темам, касающимся &os;. Большая часть затрагиваемых тем может + быть применена к безопасности системы и безопасности в интернет вообще. + Интернет больше не то дружественное место, где каждый + хочет быть вам добрым соседом. Защита системы необходима для сохранения + ваших данных, интеллектуальной собственности, времени и всего остального + от хакеров и им подобных. + + FreeBSD предоставляет массу утилит и механизмов для обеспечения + целостности и безопасности системы и сети. + + После прочтения этой главы вы узнаете: + + + + Основные концепции безопасности системы, специфику &os;. + + + + О различных механизмах шифрования в &os;, таких как + DES и MD5. + + + + Как настроить аутентификацию с использованием одноразовых + паролей. + + + + Как настроить KerberosIV в релизах + &os; до 5.0. + + + + Как настроить Kerberos5 в релизах &os; + после 5.0. + + + + Как создать межсетевые экраны с помощью + IPFW. + + + + Как настроить IPsec и создать VPN между + компьютерами на &os;/&windows;. + + + + Как настроить и использовать OpenSSH, + реализацию SSH в &os;. + + + + Как настроить и загрузить модули расширения контроля доступа, + использующие концепцию TrustedBSD MAC. + + + + Что такое ACL и как их использовать. + + + + Как работать с сообщениями безопасности &os;. + + + - Большинство нижеизложенной информации повторяет страницы - &man.security.7; справочника, изначально написанного - &a.dillon;. + Перед чтением этой главы вам потребуется: - - Краткий обзор + + + Понимание основных концепций &os; и интернет. + + - В этой главе мы расскажем об основных сведениях, которые - необходимо знать, затрагивающие общую безопасность системы, о том, как - подбирать хорошие пароли, и о таких вещах как S/Key, OpenSSL, Kerberos - и других. Введение - Несомненно, одна из важнейших задач системного администратора - – обеспечивать безопасность системы. Многопользовательские - системы, такие как BSD UNIX, имеют некоторый базовый набор средств - безопасности, однако обычно этого бывает недостаточно, и, чтобы - построить и поддерживать безопасность системы на должном уровне, - администратору приходится прикладывать некоторые усилия. Безопасность - системы целиком и полностью находится в руках системного - администратора. UNIX системы способны выполнять огромное число - процессов одновременно, и многие из них являются серверами, то есть к - ним можно обращаться извне. Сегодня уже никого не удивишь компьютером - на рабочем столе, а с распространением и повсеместным внедрением в - нашу жизнь сетевых технологий проблемы безопасности становятся - первоочередными. - - Лучше всего строить модель безопасности, основываясь на - уровневом подходе. В двух словах, это означает создание - неких эшелонов, колец защиты, и бдительное - наблюдение за состоянием каждого уровня. Имейте в виду, что слишком - перегруженная система безопасности может скорее - помещать, нежели помочь предотвращению атаки. Например, не стоит - устанавливать schg-флаги (см. &man.chflags.1;) на каждый выполняемый - системный файл, так как это, возможно, и предотвратит - несанкционированные модификации Ваших файлов, но, в то же время, может - лишить Вас легко детектируемых следов пребывания хакера, что ему - только на руку. - - Пречислим ключевые действия, которые имеют непосредственное - отношение к безопасности любой компьютерной системы: + Безопасность это первая и основная функция системного + администратора. Хотя все многопользовательские системы BSD &unix; + уже снабжены некоторой защитой, работа по созданию и поддержке + дополнительных механизмов безопасности, обеспечивающих защищенную работу + пользователей, это одна из самых серьезных задач системного + администратора. Компьютеры безопасны настолько, насколько вы сделаете + их безопасными и требования безопасности всегда находятся в противоречии + с удобством работы пользователей. Системы &unix; способны одновременно + работать с огромным количеством процессов и многие из этих процессов + серверные – это означает, что с ними могут взаимодействовать + внешние программы. Сегодня десктопы заменили мини-компьютеры и + мэйнфрэймы, и поскольку компьютеры в наши дни подключены к сети + интернет, безопасность важна как никогда. + + Наилучшая реализация системы безопасности представима в виде + послойной системы. Вообще говоря все, что нужно сделать, + это создать столько слоев безопасности, сколько необходимо и затем + внимательно следить за вторжениями в систему. Не переусердствуйте в + настройке системы безопасности, иначе она сделает невозможной + обнаружение вторжений, являющееся одним из наиболее важных аспектов + механизма безопасности. Например, нет большого смысла в установке + флага schg (&man.chflags.1;) на каждый исполняемый + файл системы, поскольку хотя таким способом можно временно защитить + исполняемые файлы, это помешает обнаружению факта взлома + системы. + + Безопасность системы также относится к различным формам атак, + имеющих своей целью вызвать крах системы, или сделать систему + недоступной другим способом, но не пытающихся получить доступ к учетной + записи root (break root). + Угрозы безопасности могут быть поделены на несколько категорий: - Атаки типа отказ от обслуживания (D.o.S.). + Отказ в обслуживании (Denial of service, DoS). - Получение пользовательского аккаунта. + Взлом пользовательских учетных записей. - Получение прав суперпользователя (root) через доступные - сервисы. + Взлом учетной записи root через доступные сервисы. - Получение прав суперпользователя (root) через пользовательские - аккаунты. + Взлом учетной записи root через учетные записи + пользователей. - Создание люков (задних дверей, черных - ходов). + Создание backdoor. - При атаке на отказ от обслуживания машина лишается необходимых - ресурсов для выполнения требуемых запросов. Наиболее типичными - атаками этого типа являются механизмы так называемой грубой - силы (brute-force), которые направлены на выведение из строя - отдельных серверов или сети в целом. Иногда для достижения цели - используются обнаруженые ошибки в сетевом стеке, когда даже одного - специальным образом составленного пакета достаточно, чтобы вывести - машину из строя. Обычно ошибки такого рода исправляются путем - прикладывания соответствующих патчей к ядру. Разумно - также тщательно подбирать сетевые опции, чтобы не допустить перегрузки - серверов при работе с очень высоким потоком данных (например, - каким-либо образом ограничивать этот поток). Если же Вашу систему - атакуют методом грубой силы, бороться с этим сложнее. - Например, если машину забрасывают специальным образом - сгенерированными пакетами, то часто бывает, что практически невозможно - остановить атакующего, кроме как полностью отключив компьютер от сети. - Даже в этом случае, хотя Ваша машина не будет затронута, сетевой - трафик будет сильно нарушен. - - Атаки, нацеленные на аккаунты рядовых пользователей распространены - еще больше, чем атаки на отказ от обслуживания. Многие системные - администраторы все еще достаточно часто используют стандартные - сервисы, такие как telnetd, rlogind, rshd и ftpd. Эти демоны, по - умолчанию, не используют шифрование передаваемых по сети данных при - своей работе. В результате, если у Вас достаточно большое число - пользователей системы, весьма вероятно, что кто-нибудь из них - рано или поздно засветит свой пароль. Поэтому - внимательный администратор всегда должен анализировать файлы системных - журналов на предмет попыток зайти на машину - с необычных адресов, и тем более в случае успеха таких попыток. - - Всегда важно помнить, что если атакующий имеет доступ к - пользовательскомуц аккаунт, то потенциально он может получить и права - суперпользователя. Однако, на самом деле, на правильно и умело - сконфигурированной и регулярно проверяемой машине, наличие - пользовательского аккаунта вовсе не означает, что атакующий сможет - сломать ее. Разница между типичным пользовательским - аккаунтом и аккаунтом суперпользователя в том, что во втором случае - атакующий может сделать с системой что угодно, в то же время, без - привилегий суперпользователя, можно лишь модифицировать или удалить - файлы, принадлежащие данному пользователю, или в худшем случае - завесить машину. Случаи, когда атакующий получает - (неавторизованно) пользовательские права, весьма нередки, так как - обычно рядовые пользователи не принимают всех необходимых мер - предосторожности, и часто в задачу системного администратора входит - принятие этих мер. - - Системный администратор всегда должен иметь ввиду, что существует - множество потенциальных путей, которыми атакующих может проникнуть в - систему. Например, он может знать пароль суперпользователя, - воспользоваться ошибкой в программном обеспечении, выполняющимся с - повышеными привилегиями, сетевом или локальном. Если атакующий нашел - способ проникнуть в систему (получить привелегии суперпользователя), - то чаще всего он попытается оставить так называемый люк, - чтобы в следующий раз ему не пришлось проделывать всю грязную работу - заново (и затем убирать за собой). Это дает Вам удобную возможность - обнаружить взломщика (так как ему придется произвести кое-какие - изменения в системе). Если же хакер смог установить люк, это может - губительно сказаться на безопасности Вашей системы, так как сильно - снижаются шансы, что кто-нибудь еще попытаеся взломать ее тем же - способом, что и в первый раз, и, таким образом, дырка в системе - останется открытой. - - Как уже было сказано ранее, лучше всего строить модель безопасности, - основываясь на уровневом подходе. Перечислим основные - моменты: + + DoS атаки + отказ в обслуживании (Denial of Service, DoS) + + + безопасность + DoS атаки + отказ в обслуживании (Denial of Service, DoS) + + Отказ в обслуживании (Denial of Service, DoS) + + Атака отказ в обслуживании отбирает у машины + необходимые ресурсы. Обычно DoS атаки используют грубую силу, чтобы + попытаться обрушить систему или сделать ее недоступной другим способом, + превысив лимиты ее сервисов или сетевого стека. Некоторые DoS атаки + пытаются использовать ошибки в сетевом стеке для обрушения системы одним + пакетом. Эту проблему можно решить только исправив ядро системы. Атаки + зачастую можно предотвратить правильной установкой параметров, + ограничивающих нагрузку на систему в неблагоприятных условиях. С + атаками, использующими грубую силу, бороться сложно. Например, атака с + использованием пакетов с поддельными адресами, которую почти невозможно + остановить, может быстро отключить вашу систему от интернет. Возможно, + она не приведет к отказу системы, но сможет переполнить соединение с + интернет. + + + безопасность + взлом учетных записей + + + Взлом учетной записи пользователя обычно встречается чаще, чем DoS + атаки. Многие системные администраторы все еще используют стандартные + сервисы telnetd, + rlogind и ftpd на + своих серверах. Эти сервисы по умолчанию не работают с зашифрованными + соединениям. В результате при среднем количестве пользователей пароль + одного или нескольких пользователей, входящих в систему через внешнее + соединение (это обычный и наиболее удобный способ входа в систему), + будет перехвачен. Внимательный системный администратор должен + анализировать логи удаленного доступа на предмет подозрительных адресов + пользователей даже в случае успешного входа. + + Кто-то может предположить, что атакующий при наличии доступа к + учетной записи пользователя может взломать учетную запись + root. Однако, реальность такова, что в хорошо + защищенной и поддерживаемой системе доступ к учетной записи пользователя + не обязательно даст атакующему доступ к root. + Разница между доступом к обычной учетной записи и к + root важна, поскольку без доступа к + root атакующий обычно не способен скрыть свои + действия, и в худшем случае сможет лишь испортить файлы пользователя или + вызвать крах системы. Взлом пользовательских учетных записей + встречается очень часто, поскольку пользователи заботятся о безопасности + так, как системные администраторы. + + + безопасность + backdoors + + + Системные администраторы должны помнить, что существует множество + потенциальных способов взлома учетной записи root. + Атакующий может узнать пароль root, найти ошибку в + сервисе, работающем с привилегиями и взломать учетную запись + root через сетевое соединение с этим сервисом, или + узнать об ошибке в suid-root программе, позволяющей атакующему взлом + root с помощью взломанной учетной записи + пользователя. Если атакующий нашел способ взлома + root, ему может не понадобиться установка backdoor. + Многие из обнаруженных и закрытых на сегодняшний день брешей + в системе, позволяющие взлом root, требуют от + атакующего серьезной работы по заметанию следов, поэтому большинство + атакующих устанавливают backdoor. Backdoor предоставляет атакующему + простой способ восстановления доступа к системе с привилегиями + root, но также дает системному администратору + удобный способ обнаружения вторжения. Устранение возможности установки + backdoor возможно повредит безопасности системы, поскольку это + не устранит брешь, позволившую проникнуть в + систему. + + Меры безопасности всегда должны быть реализованы многоуровнево, + и могут быть классифицированы следующим образом: - Обеспечивание безопасности служебных аккаунтов и аккаунта суперпользователя. + Защита root и служебных учетных + записей. - Безопасность серверов, выполняющихся с повышенными привилегиями, и исполнимых файлов, использующих SUID/SGID механизм. + Защита root – работающих под root + сервисов и suid/sgid исполняемых файлов. - Обеспечивание безопасности пользовательских аккаунтов. + Защита учетных записей пользователей. - Защита файлов, содержащих пароли. + Защита файла паролей. - Защита ядра операционной системы, raw устройств и файловых + Защита ядра, raw устройств и файловых систем. - Быстрое обнаружение подозрительных изменений в системе. + Быстрое обнаружение несанкционированных изменений в + системе. Паранойя. - В следующей секции все перечисленные пункты будут рассмотрены в - подробностях. + В следующем разделе этой главы эти темы изложены более + подробно. - Обеспечиваем безопасность FreeBSD + Защита FreeBSD + + безопасность + защита FreeBSD + + + + Команда и протокол + В этом документе мы будет использовать + выделенный упоминая команду или приложение. + Например, мы будем использовать выделение для ssh, поскольку это и + команда и протокол. + - В этой секции мы расскажем об основных методах защиты и - обеспечивания безопасности Вашей системы FreeBSD, которые были - упомянуты в предыдущей секции - этой главы. + В последующем разделе будут рассмотрены методы защиты системы + FreeBSD, упомянутые в предыдущем разделе этой главы. - Защита аккаутнов суперпользователя и служебного - персонала - - В первую очередь нужно обеспечить безопасность - суперпользовательского аккаунта, и уже после принимать аналочичные - меры в отношении прочих привелигированных аккаунтов. Во многих - системах аккаунт суперпользователя защищен паролем. Имейте в виду, - что этот пароль крайне важен, а поэтому нелишним будет относиться к - нему с очень большой осторожностью. Прежде всего, желательно - не использовать его кроме как за консолью, даже применяя команду - &man.su.1;. В частности, удостоверьтесь, что терминалы, перечисленные - в файле /etc/ttys, помечены как insecure - (небезопасные), чтобы запретить прямой доступ посредством команд + Защита учетной записи <username>root</username> и служебных + учетных записей + + su + + + Во-первых, не беспокойтесь о защите служебных учетных записей, + если не защищена учетная запись root. В + большинстве систем у учетной записи root есть + пароль. Использование пароля root + опасно всегда. Это не означает, что вы должны + удалить пароль. Пароль почти всегда необходим для доступа + по консоли. Но это означает, что вы должны сделать невозможным + использование пароля не из консоли или может быть даже с помощью + команды &man.su.1;. Например, убедитесь, что псевдотерминалы + в файле /etc/ttys перечислены с параметром + insecure, что делает невозможным вход на них + под root напрямую с помощью telnet или rlogin. При - использовании других сервисов, таких, например, как - sshd, также следует запретить - непосредсвенный вход в систему с правами суперпользователя. - Проверьте все возможные подступы к системе – сервисы типа - FTP чато оказываются подверженными атакам. Непосредственный - вход в систему с правами суперпользователя следует разрешить - только с консоли. - - Конечно, Вам как системному администратору необходимо иметь - возжожность получить права суперпользователя, поэтому несколько - путей все же есть. Однако, очень важно защитить их использование - дополнительными паролями. Один из способов дать какому-либо - пользователю повышенные привилегии – это перечислить его - в группе wheel (в файле - /etc/group). Пользователь, входящий в эту - группу, может вызвать su для получения прав - суперпользователя. Не следует включать всех членов служебного - персонала в группу wheel, задавая ее как основную - группу пользователя в файле паролей. Вместо этого, нужно включить - их в специальную группу staff, и затем, только - в случае необходимости, некоторых из них включить в группу - wheel, сделав соответсвующую запись в файле - /etc/group. Также возможно, при использовании - методов аутентикации типа kerberos, использовать файл - .k5login для того, чтобы разрешить получение - привилегий супервозователя посредствеом команды &man.ksu.1; без - необходимости включать кого-либо в группу wheel. - Это может оказаться лучшим решением, так как предыдущий метод - позволяет хакеру получить права суперпользователя, если ему удастся - получить доступ к служебному акканту. Тем не менее, все это лучше, - чем ничего. - - Аккаунт суперпользователя можно защитить косвенным путем, - посредством использования альтернативных методов аутентикации и - замены хэшированных паролей служебных аккаунтов на символ - * в файле паролей (/etc/passwd). В этом случае, - даже если взломщик получит этот файл, он не сможет извлечь оттуда - пароли, включая пароль суперпользователя. Сотрудники служебного - персонала будут сходить в систему при помощи защищенного механизма - аутентикации, например, &man.kerberos.1; или &man.ssh.1;, используя - специальную пару ключей (приватный/публичный). При использовании - систем типа kerberos, Вам потребуется обеспечить безопасность - kerberos-серверов и Вашей рабочей станции. При использовании - механизма публичного/приватного ключей, например, при работе с - ssh, Вам необходимо обеспечить - безопасность машины, с которой Вы будете - заходить в систему (обычно это Ваша рабочая станция), но можно также - обеспечить себе дополнительную безопасность, защитив пару ключей - паролем в момент ее генерации (&man.ssh-keygen.1;). Возможность - заменять реальные хэши паролей на символ * в - файле паролей (это особенно важно для аккаунтов служебного - персонала, обладающего повышенными привилегиями по сравнению с - обычными пользователями) также гарантирует, что они будут - пользоваться только безопасными методами аутентикации, которые Вы - предварительно настроили. Это хорошо тем, что закрывает наиболее - часто используемую взломщиками дыру – прослушивание - (сниффинг) сети с менее защищенной машины (на которой - у него уже есть все необходимые привилегии). - - Еще стоит обратить внимание на следующие моменты: если Ваш - основной сервер предоставляет всевозможные сетевые сервисы, то на - Вашей рабочей станции по возможности максимальное число сетевых - служб должно быть отключено (а в идеале – все), и нелишним - будет использование хранителя экрана, защищенного паролем. Конечно, - если у злоумышленника есть физический доступ к машине, то - практически никакие методы защиты не помогут (хотя и могут - значительно увеличить время взлома), однако большинство атак все же - происходят снаружи, по сети, когда у атакующего нет - непосредственного доступа к системе. - - При использовании систем аутентикации типа kerberos, у Вас есть возможность централизованно менять пароли или блокировать доступ пользователей. Это очень полезно при подозрении, что пароль какого-либо (например, администраторского) аккаунта стал известен постороннему лицу – в этом случае можно очень быстро запретить вход на все машины, где был заведен данный пользователь. Представьте себе, насколько труднее и дольше было бы менять пароли на каждой из N машин отдельно! Kerberos предосталяет и другие возможности (принудительная смена пароля по истечении определенного промежутка времени, например). + использовании других средств входа, таких как + sshd, убедитесь что вход под + root напрямую отключен и в них. Сделайте + это, открыв файл /etc/ssh/sshd_config, и + убедившись, что параметр PermitRootLogin + установлен в NO. Проверьте каждый метод доступа + – сервис FTP и ему подобные часто подвержены взлому. Прямой + вход под root должен быть разрешен только с + системной консоли. + + wheel + + + Конечно, как системный администратор вы должны иметь доступ + root, поэтому потребуется открыть несколько + лазеек. Но убедитесь, что для доступа к ним необходим + дополнительный пароль. Одним из способов доступа к + root является добавление соответствующих учетных + записей к группе wheel (в файле + /etc/group). Это позволяет использовать + su для доступа к root. + Вы никогда не должны давать таким учетным записям доступ + к wheel непосредственно, помещая их в группу + wheel в файле паролей. Служебные учетные + записи должны помещаться в группу staff, + а затем добавляться к группе wheel в файле + /etc/group. Только те члены группы staff, + которым действительно нужен доступ к root, + должны быть помещены в группу wheel. + При работе с такими методами аутентификации как Kerberos, возможно также + использование файла .k5login в каталоге + пользователя root для доступа к учетной записи + root с помощью &man.ksu.1; без помещения + кого-либо в группу wheel. Это решение возможно + лучше, поскольку механизм wheel все еще + позволяет взлом root, если злоумышленник + получил копию файла паролей и смог взломать служебную учетную запись. + Хотя использование механизма wheel лучше, + чем работа через root напрямую, это не + обязательно самый безопасный способ. + + Непрямой способ защиты служебных учетных записей и конечно + root это использование альтернативных методов + доступа и замена зашифрованных паролей на символ + *. Используя команду + &man.vipw.8;, замените каждый зашифрованный пароль служебных учетных + записей на этот символ для запрета входа с аутентификацией по паролю. + Эта команда обновит файл /etc/master.passwd и + базу данных пользователей/паролей. + + Служебная учетная запись вроде этой: + + foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + + Должна быть заменена на такую: + + foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + + Это изменение предотвратит обычный вход, поскольку зашифрованный + пароль никогда не совпадет с *. + После этого члены группы staff должны использовать другой механизм + аутентификации, например &man.kerberos.1; или &man.ssh.1; с парой + ключей: публичным и приватным. При использовании такой системы как + Kerberos, потребуется защитить сервер Kerberos и рабочую станцию. + При использовании пары публичного/приватного ключей с ssh, + потребуется защитить компьютер, с которого + происходит вход (обычно это рабочая станция). Дополнительных слой + защиты может быть добавлен путем защиты пары ключей при создании их + с помощью &man.ssh-keygen.1;. Возможность заменить пароли служебных + учетных записей на * гарантирует + также, что вход может быть осуществлен только через защищенные методы + доступа, которые вы настроили. Это принуждает всех членов staff + использовать защищенные, шифрованные соединения для всех входов, + что закрывает большую брешь, используемую многими нарушителями: + перехват паролей с другого, слабо защищенного компьютера. + + Более непрямой механизм безопасности предполагает, что вы входите + с более защищенного сервера на менее защищенный. Например, если + главный сервер работает со всеми сервисами, рабочая станция не должна + работать ни с одним. Для поднятия уровня безопасности до приемлемого + уровня, число запущенных на ней сервисов необходимо сократить до + минимума, вплоть до отключения их всех, кроме того необходимо + использовать защищенный паролем хранитель экрана. Конечно, при + наличии физического доступа к рабочей станции атакующий может взломать + любую систему безопасности. Это определенно проблема, которую вы + должны учитывать, но учтите также тот факт, что большинство взломов + совершаются удаленно, через сеть, людьми, которые не имеют физического + доступа к вашим рабочим станциям или серверам. + KerberosIV + + Использование такой системы как Kerberos дает возможность + заблокировать или изменить пароль в одном месте, что сразу + отразиться на всех компьютерах, где существует служебная учетная + запись. Если эта учетная запись будет взломана, возможность + немедленно изменить пароль на всех компьютерах нельзя недооценивать. + Без этой возможности изменение паролей на N машинах может стать + проблемой. Вы можете также наложить ограничения на смену паролей + с помощью Kerberos: не только установить значения timeout в + Kerberos, но и добавить требование смены пароля пользователем + после определенного периода времени (скажем, раз в месяц). - Безопасность серверов, выполняющихся с повышенными привилегиями, и исполнимых файлов, использующих SUID/SGID механизм - - Осторожный системный администратор конфигурирует систему так, чтобы запущены были только самые необходимые сервисы. Не больше, не меньше. Стоит с особой осторожностью отновиться - tHE prudent sysadmin only runs the servers he needs to, no more, no less. Be aware that third party servers are often the - most bug-prone. For example, running an old version of imapd or - popper is like giving a universal root ticket out to the entire - world. Never run a server that you have not checked out - carefully. Many servers do not need to be run as root. For - example, the ntalk, - comsat, and - finger daemons can be run in special - user sandboxes. A sandbox isn't perfect unless - you go to a large amount of trouble, but the onion approach to - security still stands: If someone is able to break in through - a server running in a sandbox, they still have to break out of the - sandbox. The more layers the attacker must break through, the - lower the likelihood of his success. Root holes have historically - been found in virtually every server ever run as root, including - basic system servers. If you are running a machine through which - people only login via sshd and never - login via telnetd or - rshd or - rlogind, then turn off those - services! - - FreeBSD now defaults to running + Защита работающих под root сервисов и suid/sgid исполняемых + файлов + + + ntalk + + + comsat + + + finger + + + sandboxes + + + sshd + + + telnetd + + + rshd + + + rlogind + + + Предусмотрительный системный администратор запускает только те + сервисы, в которых нуждается, ни больше ни меньше. Учитывайте, что + сервисы сторонних разработчиков наиболее подвержены ошибкам. К примеру, + работа со старыми версиями imapd или + popper это все равно что раздача доступа + root всему миру. Никогда не запускайте + сервисы, которые вы не проверили достаточно внимательно. Многим + сервисам не требуется работа под root. + Например, даемоны ntalk, + comsat, и + finger могут быть запущены в так + называемых песочницах + (sandboxes). Песочница это не идеальное + решение, поскольку вызывает много проблем, но она подходит под + модель послойной безопасности: если кто-то сможет взломать сервис, + работающий в песочнице, ему потребуется взломать еще и саму + песочницу. Чем больше уровней (слоев) потребуется + пройти атакующему, тем меньше вероятность его успеха. Ошибки, + позволяющие получать root доступ, находили фактически во всех + сервисах, запускаемых под root, включая + основные системные сервисы. Если вы обслуживаете машину, на которую + входят только через sshd и никогда не + входят через telnetd, + rshd или + rlogind, отключите эти сервисы! + + В FreeBSD сервисы ntalkd, - comsat, and - finger in a sandbox. Another program - which may be a candidate for running in a sandbox is &man.named.8;. - The default rc.conf includes the arguments - necessary to run namedin a sandbox in a - commented-out form. Depending on whether you are installing a new - system or upgrading an existing system, the special user accounts - used by these sandboxes may not be installed. The prudent - sysadmin would research and implement sandboxes for servers - whenever possible. - - There are a number of other servers that typically do not run - in sandboxes: sendmail, + comsat и + finger теперь по умолчанию работают в + песочнице. Другая программа, которая может быть + кандидатом на запуск в песочнице это + &man.named.8;. /etc/defaults/rc.conf включает + необходимые для запуска named + в песочнице аргументы в закомментированой форме. + В зависимости от того, устанавливаете ли вы новую систему, или + обновляете старую, учетные записи пользователей, используемые + этими песочницами могут не быть созданы. + Предусмотрительный системный администратор должен узнать о + песочницах для сервисов и установить их если есть + возможность. + + sendmail + + + Есть множество других сервисов, которые обычно не работают в + песочницах: sendmail, popper, imapd, ftpd, - and others. There are alternatives to some of these, but - installing them may require more work then you are willing to - perform (the convenience factor strikes again). You may have to - run these servers as root and rely on other mechanisms to detect - break-ins that might occur through them. - - The other big potential root hole in a system are the - suid-root and sgid binaries installed on the system. Most of - these binaries, such as rlogin, reside - in /bin, /sbin, - /usr/bin, or /usr/sbin. - While nothing is 100% safe, the system-default suid and sgid - binaries can be considered reasonably safe. Still, root holes are - occasionally found in these binaries. A root hole was found in - Xlib in 1998 that made - xterm (which is typically suid) - vulnerable. It is better to be safe then sorry and the prudent - sysadmin will restrict suid binaries that only staff should run to - a special group that only staff can access, and get rid of - (chmod 000) any suid binaries that nobody uses. - A server with no display generally does not need an - xterm binary. Sgid binaries can be - almost as dangerous. If an intruder can break an sgid-kmem binary - the intruder might be able to read /dev/kmem - and thus read the crypted password file, potentially compromising - any passworded account. Alternatively an intruder who breaks - group kmem can monitor keystrokes sent through - pty's, including pty's used by users who login through secure - methods. An intruder that breaks the tty group can write to - almost any user's tty. If a user is running a terminal program or - emulator with a keyboard-simulation feature, the intruder can - potentially generate a data stream that causes the user's terminal - to echo a command, which is then run as that user. + и другие. Некоторым из этих сервисов есть альтернативы, + но их установка может потребовать больше работы, чем вы готовы + выполнить (фактор удобства). Вы можете запустить эти сервисы под + root и положиться на другие механизмы обнаружения + вторжений, которые могут пройти через них. + + Другая большая потенциальная root брешь + в системе это suid-root и sgid исполняемые файлы. Большинство + этих исполняемых файлов, таких как rlogin, + установлены в /bin, /sbin, + /usr/bin, или /usr/sbin. + Хотя ничто не может быть безопасно на 100%, находящиеся по умолчанию + в системе suid и sgid исполняемые файлы могут быть признаны + достаточно безопасными. Но root бреши все еще + обнаруживаются в этих исполняемых файлах. root + брешь, обнаруженная в Xlib в 1998 делала + xterm (который обычно suid) подверженным + взлому. Лучше сразу принять меры предосторожности, чем сожалеть + потом. Предусмотрительный системный администратор ограничит права + запуска suid исполняемых файлов, которые должны запускаться + пользователями группы staff, только этой группой, а также запретит + доступ (chmod 000) к тем исполняемым файлам + suid, которые никем не используются. Серверу без монитора обычно + не требуется исполняемый файл xterm. + Исполняемые sgid исполняемые файлы могут быть почти так же опасны. + Если нарушитель сможет взломать sgid-kmem исполняемый файл, он + возможно сможет прочесть /dev/kmem и + таким образом получить файл зашифрованных паролей, что потенциально + делает возможным взлом любой защищенной паролем учетной записи. + Аналогично нарушитель, проникший в группу kmem, + может отслеживать последовательности клавиш, отправленные через + псевдотерминалы, включая псевдотерминалы, используемые через + безопасные соединения. Нарушитель, вошедший в группу + tty может сделать вывод почти на любой + пользовательский терминал. Если пользователь работает с + терминальной программой или эмулятором с возможностью эмуляции + клавиатуры, взломщик может потенциально сгенерировать поток данных, + который заставит терминал пользователя ввести команду, и она будет + запущена с правами этого пользователя. - Securing User Accounts - - User accounts are usually the most difficult to secure. While - you can impose Draconian access restrictions on your staff and - * out their passwords, you may not be able to - do so with any general user accounts you might have. If you do - have sufficient control then you may win out and be able to secure - the user accounts properly. If not, you simply have to be more - vigilant in your monitoring of those accounts. Use of - ssh and kerberos for user accounts is - more problematic due to the extra administration and technical - support required, but still a very good solution compared to a - crypted password file. + Защита учетных записей пользователей + + Учетные записи пользователей обычно сложнее всего защитить. + Вы можете ввести драконовские ограничения доступа к служебным учетным + записям, заменив их пароли на символ + *, но возможно не сможете сделать + то же с обычными учетными записями пользователей. Если есть + такая возможность, вы возможно сможете защитить учетные записи + пользователей соответствующим образом. Если нет, просто + более бдительно отслеживайте эти учетные записи. Использование + ssh и Kerberos для учетных записей пользователей более + проблематично, поскольку требует дополнительной административной + работы и технической поддержки, но все же это решение лучше, + чем файл с шифрованными паролями. - Securing the Password File - - The only sure fire way is to * out as many - passwords as you can and use ssh or - kerberos for access to those accounts. Even though the crypted - password file (/etc/spwd.db) can only be read - by root, it may be possible for an intruder to obtain read access - to that file even if the attacker cannot obtain root-write - access. - - Your security scripts should always check for and report - changes to the password file (see Checking file integrity - below). + Защита файла паролей + + Единственный абсолютно надежный способ это замена на + * максимально возможного количества паролей и + использование ssh или Kerberos для доступа к таким учетным записям. + Хотя файл с шифрованными паролями (/etc/spwd.db) + доступен для чтения только root, возможно, что + нарушитель сможет получить доступ на чтение к этому файлу, даже если + не получит права root на запись. + + Ваши скрипты безопасности должны всегда проверять и составлять + отчет об изменениях файла паролей (обратитесь к разделу Проверка целостности файлов + ниже по тексту). - Securing the Kernel Core, Raw Devices, and - Filesystems - - If an attacker breaks root he can do just about anything, but - there are certain conveniences. For example, most modern kernels - have a packet sniffing device driver built in. Under FreeBSD it - is called the bpf device. An intruder - will commonly attempt to run a packet sniffer on a compromised - machine. You do not need to give the intruder the capability and - most systems should not have the bpf device compiled in. - - But even if you turn off the bpf device, you still have - /dev/mem and /dev/kmem - to worry about. For that matter, the intruder can still write to - raw disk devices. Also, there is another kernel feature called - the module loader, &man.kldload.8;. An enterprising intruder can - use a KLD module to install his own bpf device or other sniffing - device on a running kernel. To avoid these problems you have to - run the kernel at a higher secure level, at least securelevel 1. - The securelevel can be set with a sysctl on - the kern.securelevel variable. Once you have - set the securelevel to 1, write access to raw devices will be - denied and special chflags flags, such as schg, - will be enforced. You must also ensure that the - schg flag is set on critical startup binaries, - directories, and script files – everything that gets run up - to the point where the securelevel is set. This might be overdoing - it, and upgrading the system is much more difficult when you - operate at a higher secure level. You may compromise and run the - system at a higher secure level but not set the - schg flag for every system file and directory - under the sun. Another possibility is to simply mount - / and /usr read-only. - It should be noted that being too draconian in what you attempt to - protect may prevent the all-important detection of an - intrusion. + Защита ядра, raw устройств и файловых + систем + + Если атакующий взломает root, он сможет + сделать практически все, но есть способы усложнить его задачу. + Например, в большинстве современных ядер встроено устройство + перехвата пакетов. В FreeBSD оно называется + bpf. Нарушитель обычно пытается запустить + перехват пакетов на взломанной машине. Вы не должны предоставлять + ему такой возможности, на большинстве систем устройство + bpf не должно быть встроено в ядро. + + + sysctl + + Но даже если вы выключите устройство bpf, + все еще остаются проблемы, связанные с устройствами + /dev/mem и + /dev/kmem. + Нарушитель все еще может писать на дисковые raw устройства. + Есть также другая возможность ядра, загрузка модулей, &man.kldload.8;. + Активный нарушитель может использовать KLD модуль для установки + собственного устройства bpf или другого + перехватывающего устройства на работающее ядро. Для решения этих + проблем запускайте ядро с большим уровнем безопасности, как минимум 1. + Уровень безопасности может быть установлен с помощью + sysctl через переменную + kern.securelevel. После установки уровня + безопасности в 1 доступ на запись в raw устройства будет запрещена и + полностью заработают специальные флаги chflags, + такие как schg. Убедитесь также, что + флаг schg установлен на критически важных + загрузочных исполняемых файлах, каталогах и файлах скриптов – + на всем, что запускается до установке уровня безопасности. + Это требует большого объема работы, и обновление системы на более + высоком уровне безопасности может стать гораздо сложнее. Вы можете + пойти на компромисс и запускать систему на высоком уровне безопасности, + но не устанавливать флаг schg для каждого + существующего системного файла и каталога. Другая возможность + состоит в монтировании / и + /usr только для чтения. Необходимо заметить, + что такие правила слишком жесткие и могут помешать обнаружению + вторжения. - Checking File Integrity: Binaires, Configuration Files, - Etc. - - When it comes right down to it, you can only protect your core - system configuration and control files so much before the - convenience factor rears its ugly head. For example, using - chflags to set the schg bit - on most of the files in / and - /usr is probably counterproductive because - while it may protect the files, it also closes a detection window. - The last layer of your security onion is perhaps the most - important – detection. The rest of your security is pretty - much useless (or, worse, presents you with a false sense of - safety) if you cannot detect potential incursions. Half the job - of the onion is to slow down the attacker rather then stop him in - order to give the detection side of the equation a chance to catch - him in the act. - - The best way to detect an incursion is to look for modified, - missing, or unexpected files. The best way to look for modified - files is from another (often centralized) limited-access system. - Writing your security scripts on the extra-secure limited-access - system makes them mostly invisible to potential hackers, and this - is important. In order to take maximum advantage you generally - have to give the limited-access box significant access to the - other machines in the business, usually either by doing a - read-only NFS export of the other machines to the limited-access - box, or by setting up ssh keypairs to - allow the limit-access box to ssh to - the other machines. Except for its network traffic, NFS is the - least visible method – allowing you to monitor the - filesystems on each client box virtually undetected. If your - limited-access server is connected to the client boxes through a - switch, the NFS method is often the better choice. If your - limited-access server is connected to the client boxes through a - hub or through several layers of routing, the NFS method may be - too insecure (network-wise) and using - ssh may be the better choice even with - the audit-trail tracks that ssh - lays. - - Once you give a limit-access box at least read access to the - client systems it is supposed to monitor, you must write scripts - to do the actual monitoring. Given an NFS mount, you can write - scripts out of simple system utilities such as &man.find.1; and - &man.md5.1;. It is best to physically md5 the client-box files - boxes at least once a day, and to test control files such as those - found in /etc and - /usr/local/etc even more often. When - mismatches are found relative to the base md5 information the - limited-access machine knows is valid, it should scream at a - sysadmin to go check it out. A good security script will also - check for inappropriate suid binaries and for new or deleted files - on system partitions such as / and + Проверка целостности файлов: исполняемые, конфигурационные файлы + и т.д. + + Вы можете защищать только ядро, файлы настройки и управления + системой только до тех пор, пока эта защита не вступит в конфликт + с удобством работы в системе. Например, использование + chflags для установки бита + schg на большинство файлов в / + вероятно может только навредить, поскольку хотя и может защитить + файлы, препятствует обнаружению. Последний слой системы безопасности, + возможно, наиболее важный – обнаружение. Остальные меры + безопасности практически бесполезны (или, что еще хуже, могут дать + вам ложное ощущение безопасности) если вы не обнаружите потенциальное + вторжение. Половина функций системы безопасности направлена на + замедление атакующего, а не на его остановку, для того, чтобы дать + системе обнаружения возможность поймать нарушителя на месте + преступления. + + Лучший способ обнаружения вторжения – отслеживание + измененных, отсутствующих, или неожиданно появившихся файлов. + Для наблюдения за измененными файлами лучше всего использовать + другую (зачастую централизованную) систему с ограниченным + доступом. Добавление написанных вами скриптов к этой дополнительно + защищенной системе с ограниченным доступом делает ее практически + невидимой для потенциальных взломщиков, и это важно. В целях + достижения максимального эффекта вам может потребоваться предоставить + этой системе доступ к другим машинам в сети, обычно с помощью + NFS экспорта только для чтения или сгенерировав пары ключей ssh + для доступа к другим машинам по ssh. Помимо большого объема + сетевого трафика, NFS более скрытый метод – он позволяет + контролировать файловые системы на каждом клиентском компьютере + практически незаметно. Если ваш сервер с ограниченным доступом + подключен к клиентским компьютерам через коммутатор, NFS метод + это зачастую лучший выбор. При соединении через концентратор, или + через несколько маршрутизаторов, NFS метод может стать слишком + небезопасным и использование ssh может стать лучшим выбором даже + несмотря на то, что ssh оставляет следы своей работы. + + Как только у вас появился сервер с ограниченным доступом, + и как минимум доступ на чтение в клиентских системах, потребуется + написать скрипты для выполнения мониторинга. При наличии доступа + по NFS вы можете написать скрипты с помощью простых системных утилит, + таких как &man.find.1; и &man.md5.1;. Лучше всего подсчитывать + md5 файлов на клиентском компьютере как минимум один раз в день, + а файлы, контролирующие запуск из /etc и + /usr/local/etc даже более часто. При + обнаружении расхождений в md5, контролирующий компьютер должен + просигналить системному администратору проверить изменившиеся + файлы. Хороший скрипт безопасности проверит также наличие + несоответствующих исполняемых suid файлов и новых или измененных + файлов в системных разделах / и /usr. - When using ssh rather then NFS, - writing the security script is much more difficult. You - essentially have to scp the scripts to the client box in order to - run them, making them visible, and for safety you also need to - scp the binaries (such as find) that those - scripts use. The ssh daemon on the - client box may already be compromised. All in all, using - ssh may be necessary when running over - unsecure links, but it's also a lot harder to deal with. - - A good security script will also check for changes to user and - staff members access configuration files: + При использовании ssh вместо NFS, написать скрипты безопасности + гораздо сложнее. Вам обязательно потребуется скопировать + (scp) скрипты на клиентский компьютер, + сделать из невидимыми, и для безопасности потребуется также + скопировать исполняемые файлы (такие как find), которые будут + использоваться скриптом. Приложение ssh + на клиентском компьютере может быть уже взломано. В конечном итоге, + без ssh не обойтись при работе через небезопасные соединения, + но его гораздо сложнее использовать. + + Хороший скрипт безопасности проверит также изменения в файлах + настройки, работающих при подключении пользователей и служебных учетных + записей: .rhosts, .shosts, - .ssh/authorized_keys and so forth… - files that might fall outside the purview of the - MD5 check. - - If you have a huge amount of user disk space it may take too - long to run through every file on those partitions. In this case, - setting mount flags to disallow suid binaries and devices on those - partitions is a good idea. The nodev and - nosuid options (see &man.mount.8;) are what you - want to look into. I would scan them anyway at least once a week, - since the object of this layer is to detect a break-in whether or - not the break-in is effective. - - Process accounting (see &man.accton.8;) is a relatively - low-overhead feature of the operating system which I recommend - using as a post-break-in evaluation mechanism. It is especially - useful in tracking down how an intruder has actually broken into - a system, assuming the file is still intact after the break-in - occurs. - - Finally, security scripts should process the log files and the - logs themselves should be generated in as secure a manner as - possible – remote syslog can be very useful. An intruder - tries to cover his tracks, and log files are critical to the - sysadmin trying to track down the time and method of the initial - break-in. One way to keep a permanent record of the log files is - to run the system console to a serial port and collect the - information on a continuing basis through a secure machine - monitoring the consoles. + .ssh/authorized_keys и так далее… + файлы, которые могли не попасть в область проверки + MD5. + + Если для пользователей выделен большой объем дискового + пространства, проверка каждого файла на таких разделах может занять + слишком много времени. В таком случае установка флагов монтирования + для запрета suid исполняемых файлов и устройств на таких разделах + это хорошая идея. Примените параметры &man.mount.8; + nodev и nosuid. Проверяйте + эти разделы в любом случае, хотя бы раз в неделю, поскольку + необходимо обнаруживать попытки взлома, независимо от того, + эффективны они или нет. + + Учет процессов (&man.accton.8;) это относительно несложная + возможность операционной системы, которая может помочь + как механизм обнаружения состоявшихся вторжений. Она особенно + полезна для обнаружения пути проникновения нарушителя в систему, + если файл не был затронут проникновением. + + Наконец, скрипты безопасности должны обработать лог файлы, + которые необходимо создавать настолько защищенным способом, насколько + это возможно – подключение syslog удаленно может быть очень + полезным. Злоумышленник попытается уничтожить следы взлома, + и лог файлы критически важны для системного администратора, + пытающегося отследить время и метод первого проникновения. + Один из надежных способов получения лог файлов является подключение + системной консоли к последовательному порту и постоянный + сбор информации через защищенную машину, отслеживающую + консоли. Паранойя - A little paranoia never hurts. As a rule, a sysadmin can add - any number of security features as long as they do not effect - convenience, and can add security features that do effect - convenience with some added thought. Even more importantly, a - security administrator should mix it up a bit – if you use - recommendations such as those given by this document verbatim, you - give away your methodologies to the prospective hacker who also - has access to this document. + Немного паранойи никогда не повредит. Как правило, системный + администратор может добавлять элементы безопасности в любом + количестве, пока это не влияет на удобство, а также некоторое + количество элементов безопасности, влияющих + на удобство. Что даже более важно, системный администратор должен + немного изменить их – если вы используете рекомендации, например + те, что даны в этом документе, они становятся известны атакующему, + который также имеет доступ к этому документу. + prospective attacker who also has access to this document. - Denial of Service Attacks + Атаки DoS + Отказ в обслуживании (DoS) - This section covers Denial of Service attacks. A DOS attack - is typically a packet attack. While there is not much you can do - about modern spoofed packet attacks that saturate your network, - you can generally limit the damage by ensuring that the attacks - cannot take down your servers. + Этот раздел охватывает DoS атаки. DoS атаки это обычно + пакетные атаки. Хотя против современной атаки с подделкой пакетов, + которая перегружает сеть, мало что можно сделать, вы можете + ограничить повреждения, убедившись, что атака не может + обрушить ваши сервера. - Limiting server forks. + Ограничение количества порождаемых процессов. - Limiting springboard attacks (ICMP response attacks, ping - broadcast, etc.). + Уменьшение последствий springboard атак (ICMP ответ, + широковещательный ping и т.д.). - Kernel Route Cache. + Кэш маршрутизации ядра. - A common DOS attack is against a forking server that attempts - to cause the server to eat processes, file descriptors, and memory - until the machine dies. Inetd (see &man.inetd.8;) has several - options to limit this sort of attack. It should be noted that - while it is possible to prevent a machine from going down it is - not generally possible to prevent a service from being disrupted - by the attack. Read the inetd manual page carefully and pay - specific attention to the , , - and options. Note that spoofed-IP attacks - will circumvent the option to inetd, so - typically a combination of options must be used. Some standalone - servers have self-fork-limitation parameters. - - Sendmail has its - option which tends to work - much better than trying to use sendmail's load limiting options - due to the load lag. You should specify a - MaxDaemonChildren parameter when you start - sendmail high enough to handle your - expected load but no so high that the computer cannot handle that - number of sendmails without falling on - its face. It is also prudent to run sendmail in queued mode - () and to run the daemon - (sendmail -bd) separate from the queue-runs - (sendmail -q15m). If you still want realtime - delivery you can run the queue at a much lower interval, such as - , but be sure to specify a reasonable - MaxDaemonChildren option for that sendmail to - prevent cascade failures. - - Syslogd can be attacked directly - and it is strongly recommended that you use the - option whenever possible, and the option - otherwise. - - You should also be fairly careful with connect-back services - such as tcpwrapper's reverse-identd, - which can be attacked directly. You generally do not want to use - the reverse-ident feature of - tcpwrappers for this reason. - - It is a very good idea to protect internal services from - external access by firewalling them off at your border routers. - The idea here is to prevent saturation attacks from outside your - LAN, not so much to protect internal services from network-based - root compromise. Always configure an exclusive firewall, i.e., - firewall everything except ports A, B, - C, D, and M-Z. This way you can firewall off all of your - low ports except for certain specific services such as - named (if you are primary for a zone), + Обычная DoS атака против порождающего процессы сервера пытается + исчерпать ресурсы сервера по процессам, файловым дескрипторам и + памяти до тех пор, пока машина не подвиснет. У + inetd (обратитесь к &man.inetd.8;) + есть несколько параметров, позволяющих ограничить такие атаки. + Необходимо учесть, что хотя можно предотвратить падение системы, в + общем случае невозможно предотвратить прекращение работы сервиса. + Внимательно прочтите страницу справочника и обратите особое внимание + на параметры , , и + . Учтите, что параметр не + работает в случае атак с использованием поддельных IP пакетов, + поэтому как правило необходимо использование комбинации параметров. + Некоторые standalone сервисы используют собственные параметры, + ограничивающие порождение процессов. + + У Sendmail есть собственный параметр + , которая работает гораздо лучше, + чем параметр sendmail, ограничивающий нагрузку. Вам необходимо задать + параметр запуска sendmail + MaxDaemonChildren достаточно большим, чтобы + обслуживать ожидаемую нагрузку, но так, чтобы компьютер мог обслужить + такое количество приложений sendmail без + падения системы. Хорошей мерой является запуск sendmail в режиме + очереди () и запуск даемона + (sendmail -bd) отдельно от очереди + (sendmail -q15m). Если вы все же хотите + организовать доставку в режиме реального времени, запускайте + очередь с меньшим интервалом , но убедитесь + в правильной установке параметра sendmail + MaxDaemonChildren для предотвращения + ошибок. + + Syslogd может быть атакован + непосредственно, настоятельно рекомендуется использовать параметр + если это возможно и параметр + в остальных случаях. + + Вы также должны быть очень осторожны с сервисами, совершающими + обратное подключение, такими как tcpwrapper + с reverse-identd, который может быть атакован непосредственно. + По этой причине возможность tcpwrappers + reverse-ident обычно не следует использовать. + + Правильным будет запрет доступа к внутренним сервисам из внешней + сети путем соответствующей настройки межсетевого экрана на внешнем + маршрутизаторе. Идея в том, чтобы предотвратить перегрузку сервисов + атаками из внешней сети, а кроме того защитить + root от взлома через сеть. Всегда настраивайте + исключающий межсетевой экран, т.е. закрыть все + кроме портов A, B, C, D, и M-Z. + Этим способом вы можете закрыть все порты нижнего диапазона, + кроме явно указанных, таких как named + (если вы поддерживаете интернет-зону), ntalkd, - sendmail, and other internet-accessible - services. If you try to configure the firewall the other way - – as an inclusive or permissive firewall, there is a good - chance that you will forget to close a couple of - services or that you will add a new internal service and forget - to update the firewall. You can still open up the high-numbered - port range on the firewall to allow permissive-like operation - without compromising your low ports. Also take note that FreeBSD - allows you to control the range of port numbers used for dynamic - binding via the various net.inet.ip.portrange - sysctl's (sysctl -a | fgrep - portrange), which can also ease the complexity of your - firewall's configuration. I usually use a normal first/last range - of 4000 to 5000, and a hiport range of 49152 to 65535, then block - everything under 4000 off in my firewall (except for certain - specific internet-accessible ports, of course). - - Another common DOS attack is called a springboard attack - – to attack a server in a manner that causes the server to - generate responses which then overload the server, the local - network, or some other machine. The most common attack of this - nature is the ICMP ping broadcast attack. - The attacker spoofs ping packets sent to your LAN's broadcast - address with the source IP address set to the actual machine they - wish to attack. If your border routers are not configured to - stomp on ping's to broadcast addresses, your LAN winds up - generating sufficient responses to the spoofed source address to - saturate the victim, especially when the attacker uses the same - trick on several dozen broadcast addresses over several dozen - different networks at once. Broadcast attacks of over a hundred - and twenty megabits have been measured. A second common - springboard attack is against the ICMP error reporting system. - By constructing packets that generate ICMP error responses, an - attacker can saturate a server's incoming network and cause the - server to saturate its outgoing network with ICMP responses. This - type of attack can also crash the server by running it out of - mbuf's, especially if the server cannot drain the ICMP responses - it generates fast enough. The FreeBSD kernel has a new kernel - compile option called ICMP_BANDLIM which limits the effectiveness - of these sorts of attacks. The last major class of springboard - attacks is related to certain internal inetd services such as the - udp echo service. An attacker simply spoofs a UDP packet with the - source address being server A's echo port, and the destination - address being server B's echo port, where server A and B are both - on your LAN. The two servers then bounce this one packet back and - forth between each other. The attacker can overload both servers - and their LANs simply by injecting a few packets in this manner. - Similar problems exist with the internal chargen port. A - competent sysadmin will turn off all of these inetd-internal test - services. - - Spoofed packet attacks may also be used to overload the kernel - route cache. Refer to the net.inet.ip.rtexpire, - rtminexpire, and rtmaxcache - sysctl parameters. A spoofed packet attack - that uses a random source IP will cause the kernel to generate a - temporary cached route in the route table, viewable with - netstat -rna | fgrep W3. These routes - typically timeout in 1600 seconds or so. If the kernel detects - that the cached route table has gotten too big it will dynamically - reduce the rtexpire but will never decrease it to less then - rtminexpire. There are two problems: + sendmail, и других сервисов, доступных + из интернет. Если вы попробуете настроить межсетевой экран другим + способом – включающий, или разрешающий межсетевой экран, есть + большой шанс забыть закрыть пару сервисов, или + добавить новый внутрисетевой сервис и забыть обновить межсетевой + экран. Вы можете открыть диапазон портов с большими номерами + для обычных приложений без угрозы портам нижнего диапазона. + Учтите также, что FreeBSD позволяет вам контролировать диапазоны + портов, используемые для динамической привязки через различные + переменные sysctl + net.inet.ip.portrange (sysctl -a | fgrep + portrange), что позволяет упростить настройку + межсетевого экрана. Например, вы можете использовать обычный + диапазон портов со значениями от 4000 до 5000, и диапазон портов с + большими номерами от 49152 до 65535, а затем заблокировать все до + 4000 порта (конечно оставив доступ из интернет к определенным + портам. + + ICMP_BANDLIM + + Другой распространенный тип DoS атак называется springboard + – сервер атакуется таким образом, что генерируемые ответы + перегружают его, локальную сеть или какие-то другие компьютеры. + Наиболее распространенная атака этого вида это + широковещательная ICMP ping атака. + Атакующий подделывает пакеты ping, подставляя IP адрес машины, которую + он намеревается атаковать, и отправляет их на широковещательный + адрес вашей локальной сети. Если ваш внешний маршрутизатор не + настроен на отбрасывание пакетов ping на широковещательные адреса, + ваша сеть начинает генерировать соответствующие ответы на + поддельный адрес, что приводит к перегрузке хоста-жертвы, особенно + если атакующий использует этот же трюк с множеством + широковещательных адресов в множестве сетей одновременно. + Были зарегистрированы широковещательные атаки свыше ста двадцати + мегабит. Другая распространенная springboard атака направлена на + ICMP систему сообщения об ошибках. Конструируя пакеты, вызывающие + ICMP сообщения об ошибках, атакующий может нагрузить входящее + соединение сервера и вынудить сервер нагрузить исходящее соединение + ICMP ответами. Этот тип атаки может также обрушить сервер, когда + тот исчерпает mbuf, обычно если сервер не может ограничить число + ответов ICMP, когда они генерируются слишком быстро. В ядре + FreeBSD есть новая опция сборки, , + которая ограничивает эффективность этого типа атак. Последний + основной класс springboard атак относится к определенным + внутренним сервисам inetd, таким как + сервис udp echo. Атакующий просто подделывает адрес источника + и адрес назначения UDP пакетов, устанавливая в их качестве + соответственно echo порт сервера A и B, оба этих сервера принадлежат + вашей локальной сети. Эти два сервера начинают перебрасываться + этим пакетом друг с другом. Атакующий может вызвать перегрузку + обеих серверов и их сетей, просто отправив несколько пакетов таким + способом. Аналогичные проблемы существуют с портом + chargen. Компетентный системный + администратор должен отключить эти тестовые сервисы inetd. + + Атаки с поддельными пакетами могут также использоваться для + переполнения кэша маршрутизации ядра. Обратитесь к параметрам + sysctl net.inet.ip.rtexpire, + rtminexpire, и rtmaxcache. + Атака с поддельными пакетами, использующая произвольный IP адрес + источника, заставит ядро сгенерировать временный кэшированный + маршрут в таблице маршрутизации, который можно увидеть с помощью + netstat -rna | fgrep W3. Эти маршруты обычно + удаляются через 1600 секунд или около того. Если ядро определит, + что кэшированная маршрутная таблица стала слишком большой, оно + динамически уменьшит rtexpire, но никогда не + станет делать его меньше чем rtminexpire. + С этим связаны две проблемы: - The kernel does not react quickly enough when a lightly - loaded server is suddenly attacked. + Ядро не отреагирует достаточно быстро, когда легко нагруженный + сервер будет внезапно атакован. - The rtminexpire is not low enough for - the kernel to survive a sustained attack. + Значение rtminexpire недостаточно мало + для поддержки работоспособности в условиях продолжительной + атаки. - - If your servers are connected to the internet via a T3 or - better it may be prudent to manually override both - rtexpire and rtminexpire - via &man.sysctl.8;. Never set either parameter to zero (unless - you want to crash the machine :-). Setting both - parameters to 2 seconds should be sufficient to protect the route - table from attack. + + Если ваши серверы подключены к интернет через линию T3 или + более быструю, предусмотрительно будет изменить оба значения + rtexpire и rtminexpire + с помощью &man.sysctl.8;. Никогда не устанавливайте ни один из этих + параметров в нуль (если только вы не хотите обрушить систему). + Установка обеих параметров в значение 2 секунды должна предотвратить + таблицу маршрутизации от атак. - Access Issues with Kerberos and SSH - - There are a few issues with both kerberos and - ssh that need to be addressed if you - intend to use them. Kerberos V is an excellent authentication - protocol but the kerberized telnet and - rlogin suck rocks. There are bugs that - make them unsuitable for dealing with binary streams. Also, by - default kerberos does not encrypt a session unless you use the - option. ssh - encrypts everything by default. - - ssh works quite well in every - respect except that it forwards encryption keys by default. What - this means is that if you have a secure workstation holding keys - that give you access to the rest of the system, and you - ssh to an unsecure machine, your keys - becomes exposed. The actual keys themselves are not exposed, but - ssh installs a forwarding port for the - duration of your login and if a hacker has broken root on the - unsecure machine he can utilize that port to use your keys to gain - access to any other machine that your keys unlock. - - We recommend that you use ssh in - combination with kerberos whenever possible for staff logins. - ssh can be compiled with kerberos - support. This reduces your reliance on potentially exposable - ssh keys while at the same time - protecting passwords via kerberos. ssh - keys should only be used for automated tasks from secure machines - (something that kerberos is unsuited to). We also recommend that - you either turn off key-forwarding in the - ssh configuration, or that you make use - of the from=IP/DOMAIN option that - ssh allows in its - authorized_keys file to make the key only - useable to entities logging in from specific machines. + Проблемы, связанные с доступом к Kerberos и SSH + ssh + KerberosIV + + При использовании Kerberos и ssh необходимо учесть несколько + возможных проблем. Kerberos V это отличный протокол + аутентификации, но в адаптированных к нему приложениях + telnet и + rlogin есть несколько ошибок, которые + могут сделать их непригодными к работе с бинарными потоками. + К тому же, по умолчанию Kerberos не шифрует сессию, если вы не + используете параметр . + ssh шифрует все по умолчанию. + + ssh работает очень хорошо во всех ситуациях, но пересылает + ключи по умолчанию. Это означает, что если вы работаете с + защищенной рабочей станции, ключи на которой дают доступ к + остальной сети, и заходите по ssh на незащищенный компьютер, + эти ключи могут быть использованы для взлома. Атакующему + не удастся получить сами ключи, но поскольку ssh открывает порт + во время входа в систему, то если на незащищенной машине + взломан root, эти ключи могут быть использованы + для доступа к другим компьютерам, на которых они действуют. + + Мы рекомендуем использовать ssh в комбинации с Kerberos + для служебных учетных записей если это возможно. + ssh может быть собран с поддержкой + Kerberos. Это уменьшает зависимость от потенциально подверженных + взлому ssh ключей, и в то же время защищает пароли через + Kerberos. Ключи ssh должны использоваться только для работы + скриптов на защищенных компьютерах (там, где Kerberos использовать + не получится). Мы также рекомендуем или выключить передачу ключей + в настройках ssh, или использовать параметр + from=IP/DOMAIN, поддерживаемый ssh в файле + authorized_keys, который позволяет использовать + ключи только с определенных компьютеров. - DES, MD5, and Crypt - - Parts rewritten and updated by &a.unfurl;, 21 March - 2000. - - Every user on a UNIX system has a password associated with their - account, obviously these passwords need to be known only to - the user and the actual operating system. In order to keep - these passwords secret, they are encrypted with what is known - as a 'one-way hash', that is, they can only be easily encrypted - but not decrypted. The only way to get the password is by - brute force searching the space of possible passwords. - Unfortunately the only secure way to encrypt passwords when - UNIX came into being was based on DES, the Data Encryption - Standard. This is not such a problem for users that live in - the US, but since the source code for DES cannot be exported - outside the US, FreeBSD had to find a way to both comply with - US law and retain compatibility with all the other UNIX - variants that still use DES. - - The solution was to divide up the encryption libraries - so that US users could install the DES libraries and use - DES but international users still had an encryption method - that could be exported abroad. This is how FreeBSD came to - use MD5 as it's default encryption method. + + + + Bill + Swingle + Частично переписал и обновил + + + + + + DES, MD5, и шифрование + + безопасность + шифрование + + + шифрование + DES + MD5 + + У каждого пользователя &unix; системы есть пароль, связанный с его + учетной записью. Очевидно, что эти пароли должны быть известны только + пользователю и соответствующей операционной системе. Для защиты паролей + они шифруются способом, известным как односторонний хэш, + то есть их можно легко зашифровать, но нельзя расшифровать. Другими + словами, то, что мы сказали чуть раньше было очевидно, но не совсем + верно: операционной системе сам пароль + неизвестен. Ей известен только пароль в + зашифрованной форме. Единственный способ получить + обычный пароль это простой перебор всех возможных + паролей. + + К сожалению, единственный способ шифрования пароля при появлении + &unix; был основан на DES, Data Encryption Standard. Это не было + проблемой для пользователей, живущих в США, но поскольку исходный код + DES нельзя было экспортировать из США, FreeBSD нашла способ одновременно + не нарушать законов США и сохранить совместимость со всеми другими + вариантами &unix;, где все еще использовался DES. + + Решение было в разделении библиотек шифрования, чтобы пользователи + в США могли устанавливать и использовать библиотеки DES, а у остальных + пользователей был метод шифрования, разрешенный к экспорту. Так + FreeBSD пришла к использованию MD5 в качестве метода шифрования по + умолчанию. MD5 считается более безопасным, чем DES, поэтому установка + DES рекомендуется в основном из соображений совместимости. - Recognizing your crypt mechanism - - It is pretty easy to identify which encryption method - FreeBSD is set up to use. Examining the encrypted passwords in - the /etc/master.passwd file is one way. - Passwords encrypted with the MD5 hash are longer than those with - encrypted with the DES hash and also begin with the characters - $1$. DES password strings do not - have any particular identifying characteristics, but they are - shorter than MD5 passwords, and are coded in a 64-character - alphabet which does not include the $ - character, so a relatively short string which does not begin with - a dollar sign is very likely a DES password. - - Identifying which library is being used by the programs on - your system is easy as well. Any program that uses crypt is linked - against libcrypt which for each type of library is a symbolic link - to the appropriate implementation. For example, on a system using - the DES versions: - - &prompt.user; ls -l /usr/lib/libcrypt* -lrwxr-xr-x 1 root wheel 13 Mar 19 06:56 libcrypt.a -> libdescrypt.a -lrwxr-xr-x 1 root wheel 18 Mar 19 06:56 libcrypt.so.2.0 -> libdescrypt.so.2.0 -lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.a - - On a system using the MD5-based libraries, the same links will - be present, but the target will be libscrypt - rather than libdescrypt. + Определения механизма шифрования + + До FreeBSD 4.4 libcrypt.a была + символической ссылкой на библиотеку, используемую для шифрования. + В FreeBSD 4.4 libcrypt.a была изменена + для предоставления настраиваемой библиотеки аутентификации по хэшу + пароля. На данный момент библиотека поддерживает хэши DES, MD5 и + Blowfish. По умолчанию FreeBSD использует для шифрования паролей + MD5. + + Довольно легко определить какой метод шифрования используется + в FreeBSD. Один из способов это проверка файла + /etc/master.passwd. Пароли, зашифрованные в + хэш MD5 длиннее, чем те, что зашифрованы с помощью DES и начинаются + с символов $1$. Пароли, начинающиеся + с символов $2$ зашифрованы с помощью + Blowfish. Пароли, зашифрованные DES не содержат каких-то определенных + идентифицирующих символов, но они короче, чем пароли MD5 и + закодированы в 64-символьном алфавите, не содержащем символа + $, поэтому относительно короткая строка, + не начинающаяся с этого символа это скорее всего DES пароль. + + Формат паролей, используемых для новых паролей, определяется + параметром passwd_format в + /etc/login.conf, которое может принимать значения + des, md5 или + blf. Обратитесь к странице справочника + &man.login.conf.5; за дополнительной информацией о параметрах + login. + - - S/Key - - S/Key is a one-time password scheme based on a one-way hash - function. FreeBSD uses the MD4 hash for compatibility but other - systems have used MD5 and DES-MAC. S/Key has been part of the - FreeBSD base system since version 1.1.5 and is also used on a - growing number of other operating systems. S/Key is a registered - trademark of Bell Communications Research, Inc. - - There are three different sorts of passwords which we will talk - about in the discussion below. The first is your usual UNIX-style or - Kerberos password; we will call this a UNIX password. - The second sort is the one-time password which is generated by the - S/Key key program and accepted by the - keyinit program and the login prompt; we will - call this a one-time password. The final sort of - password is the secret password which you give to the - key program (and sometimes the - keyinit program) which it uses to generate - one-time passwords; we will call it a secret password - or just unqualified password. - - The secret password does not have anything to do with your UNIX - password; they can be the same but this is not reccomended. S/Key - secret passwords are not limted to 8 characters like UNIX passwords, - they can be as long as you like. Passwords of six or seven word - long phrases are fairly common. For the most part, the S/Key system - operates completely independently of the UNIX password - system. - - Besides the password, there are two other pieces of data that - are important to S/Key. One is what is known as the - seed or key and consists of two letters - and five digits. The other is what is called the iteration - count and is a number between 1 and 100. S/Key creates the - one-time password by concatenating the seed and the secret password, - then applying the MD4 hash as many times as specified by the - iteration count and turning the result into six short English words. - These six English words are your one-time password. The - login and su programs keep - track of the last one-time password used, and the user is - authenticated if the hash of the user-provided password is equal to - the previous password. Because a one-way hash is used it is - impossible to generate future one-time passwords if a sucessfully - used password is captured; the interation count is decremented after - each sucessfull login to keep the user and the login program in - sync. When the iteration count gets down to 1 S/Key must be - reinitialized. - - There are four programs involved in the S/Key system which we - will discuss below. The key program accepts an - iteration count, a seed, and a secret password, and generates a - one-time password. The keyinit program is used - to initialized S/Key, and to change passwords, iteration counts, or - seeds; it takes either a secret password, or an iteration count, - seed, and one-time password. The keyinfo program - examines the /etc/skeykeys file and prints out - the invoking user's current iteration count and seed. Finally, the - login and su programs contain - the necessary logic to accept S/Key one-time passwords for - authentication. The login program is also - capable of disallowing the use of UNIX passwords on connections - coming from specified addresses. - - There are four different sorts of operations we will cover. The - first is using the keyinit program over a secure - connection to set up S/Key for the first time, or to change your - password or seed. The second operation is using the - keyinit program over an insecure connection, in - conjunction with the key program over a secure - connection, to do the same. The third is using the - key program to log in over an insecure - connection. The fourth is using the key program - to generate a number of keys which can be written down or printed - out to carry with you when going to some location without secure - connections to anywhere. + + Одноразовые пароли + одноразовые пароли + + безопасность + одноразовые пароли + + + S/Key это схема с одноразовыми паролями, основанная на одностороннем + хэше. FreeBSD использует хэш MD4 для совместимости, но другие системы + используют MD5 и DES-MAC. S/Key была частью базовой системы FreeBSD + начиная с версии 1.1.5 и используется также во все большем числе + операционных систем. S/Key это зарегистрированная торговая марка + Bell Communications Research, Inc. + + Начиная с FreeBSD версии 5.0, S/Key была замещена на функциональный + эквивалент – OPIE (One-time Passwords In Everything). + OPIE по умолчанию использует MD5. + + Есть три различных вида паролей, о которых мы поговорим ниже. + Первый вид это ваш обычный пароль &unix; или пароль Kerberos; мы + будем называть его пароль &unix;. Второй вид это + одноразовый пароль, сгенерированный программой S/Key + key или программой OPIE &man.opiekey.1; и принимаемый + командами keyinit или &man.opiepasswd.1; + и в приглашении login; мы будем называть их одноразовыми + паролями. Последний вид паролей это защищенные пароли, которые + вы передаете программам + key/opiekey (и иногда + программам keyinit/opiepasswd), + и которые эти программы используют для создания одноразовых паролей; + мы будем называть его защищенными паролями или просто + паролями. + + Защищенный пароль не имеет никакого отношения к вашему паролю + &unix;; они могут быть одинаковыми, но это не рекомендуется. + Защищенные пароли S/Key и OPIE не ограничены 8-ю символами, как + старые &unix; паролиВ &os; стандартный пароль + может быть до 128 символов длиной., + они могут быть настолько длинными, насколько вы захотите. Очень часто + используются пароли длиной в шесть или семь символов. По большей части + система S/Key или OPIE работает полностью независимо от системы + паролей &unix;. + + Помимо паролей, есть два других вида данных, важных для S/Key и + OPIE. Первый, известный как seed или + ключ, состоит из двух букв и пяти цифр. Другой, + называемый счетчиком цикла, это номер от 1 до 100. + S/Key создает одноразовый пароль, соединяя ключ и защищенный пароль, + а затем применяя MD4/MD5 столько раз, сколько указано счетчиком цикла и + выдает результат в виде шести коротких слов на английском. Эти шесть + слов на английском и есть ваш одноразовый пароль. Система + аутентификации (как правило PAM) хранит последний использованный + одноразовый пароль, и пользователь аутентифицитуется если хэш вводимого + пользователем пароля совпадает с предыдущим паролем. Поскольку + используется односторонний хэш, невозможно сгенерировать следующий + одноразовый пароль если получен предыдущий; счетчик цикла уменьшается + после каждого успешного входа для поддержки синхронизации пользователя + с программой login. Когда счетчик цикла уменьшается до 1, S/Key и OPIE + должны быть переинициализированы. + + В каждой из обсуждаемых ниже систем задействованы три программы. + Программы key и opiekey + получают счетчик цикла, ключ и защищенный пароль и создают одноразовый + пароль или последовательный список одноразовых паролей. Программы + keyinit и opiepasswd + используются для инициализации S/Key и OPIE соответственно, + и для смены паролей, счетчиков цикла, или ключей; они принимают + защищенный пароль или счетчик цикла, ключ и одноразовый пароль. + Программы keyinfo и opieinfo + проверяют соответствующие файлы (/etc/skeykeys + или /etc/opiekeys) и печатают текущий счетчик + цикла и ключ вызывающего пользователя. + + Мы рассмотрим четыре вида операций. Первая это использование + keyinit или opiepasswd через + защищенное соединение для первоначальной настройки системы одноразовых + паролей, или для изменения пароля или ключа. Вторая операция это + использование в тех же целях keyinit или + opiepasswd через незащищенное соединение, в сочетании + с key или opiekey через защищенное + соединение. Третья это использование + key/opiekey для входа через + незащищенное соединение. Четвертая это использование + key или opiekey для генерации + набора ключей, которые могут быть записаны или распечатаны для + соединения из места, где защищенное соединение недоступно. - Secure connection initialization + Защищенная установка соединения - To initialize S/Key for the first time, change your password, - or change your seed while logged in over a secure connection - (e.g., on the console of a machine or via ssh), use the - keyinit command without any parameters while - logged in as yourself: + Для первоначальной настройки S/Key, измените ваш пароль или + ключ при входе через защищенное соединение (например, с консоли + компьютера или через ssh), используйте + команду keyinit без параметров при входе под + своим именем: &prompt.user; keyinit Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. Enter secret password: Again secret password: ID unfurl s/key is 99 to17757 DEFY CLUB PRO NASH LACE SOFT - At the Enter secret password: prompt you - should enter a password or phrase. Remember, this is not the - password that you will use to login with, this is used to generate - your one-time login keys. The ID line gives the - parameters of your particular S/Key instance; your login name, the - iteration count, and seed. When logging in with S/Key, the system - will remember these parameters and present them back to you so you - do not have to remember them. The last line gives the particular - one-time password which corresponds to those parameters and your - secret password; if you were to re-login immediately, this - one-time password is the one you would use. + Для OPIE, вместо этого используется + opiepasswd: + + &prompt.user; opiepasswd -c +[grimreaper] ~ $ opiepasswd -f -c +Adding unfurl: +Only use this method from the console; NEVER from remote. If you are using +telnet, xterm, or a dial-in, type ^C now or exit with no password. +Then run opiepasswd without the -c parameter. +Using MD5 to compute responses. +Enter new secret pass phrase: +Again new secret pass phrase: +ID unfurl OTP key is 499 to4268 +MOS MALL GOAT ARM AVID COED + + + В приглашениях Enter new secret pass phrase: или + Enter secret password:, введите пароль или фразу. + Запомните, это не тот пароль, с которым вы будете входить, он + используется для генерации одноразовых паролей. Строка + ID содержит информацию для вашего конкретного случая: + имя пользователя, счетчик цикла и ключ. При входе система запомнит + эти параметры и отправит их вам, поэтому их не надо запоминать. В + последней строке находится одноразовый пароль, соответствующий + этим параметрам и секретному паролю; если вы войдете в систему сразу, + используйте этот одноразовый пароль. - Insecure connection initialization - - To initialize S/Key or change your secret password over an - insecure connection, you will need to already have a secure - connection to some place where you can run the - key program; this might be in the form of a - desk accessory on a Macintosh, or a shell prompt on a machine you - trust. You will also need to make up an iteration count (100 is - probably a good value), and you may make up your own seed or use a - randomly-generated one. Over on the insecure connection (to the - machine you are initializing), use the keyinit - -s command: + Незащищенная установка соединения + + Для инициализации или изменения защищенного пароля через + незащищенное соединение, вам потребуется существующее защищенное + соединение куда-то, где вы сможете запустить key + или opiekey; это может быть средство доступа + &macintosh; или shell на компьютере, которому вы доверяете. + Вам потребуется также установить значение счетчика цикла (100 + возможно подойдет), и задать ключ или использовать сгенерированный. + Через незащищенное соединение (к компьютеру, на котором производится + настройка), используйте команду keyinit -s: &prompt.user; keyinit -s Updating unfurl: Old key: to17758 -Reminder you need the 6 english words from the key command. +Reminder you need the 6 English words from the key command. Enter sequence count from 1 to 9999: 100 Enter new key [default to17759]: s/key 100 to 17759 -s/key access password: +s/key access password: +s/key access password:CURE MIKE BANE HIM RACY GORE + + + Для OPIE, используйте opiepasswd: - To accept the default seed (which the + &prompt.user; opiepasswd + +Updating unfurl: +You need the response from an OTP generator. +Old secret pass phrase: + otp-md5 498 to4268 ext + Response: GAME GAG WELT OUT DOWN CHAT +New secret pass phrase: + otp-md5 499 to4269 + Response: LINE PAP MILK NELL BUOY TROY + +ID mark OTP key is 499 gr4269 +LINE PAP MILK NELL BUOY TROY + + + + Чтобы принять ключ по умолчанию нажмите Enter. + Затем, перед вводом пароля доступа введите те же параметры в + вашем защищенном соединении или средстве доступа S/Key: &prompt.user; key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <secret password> CURE MIKE BANE HIM RACY GORE - Now switch back over to the insecure connection, and copy the - one-time password generated by key over to the - keyinit program: + Или для OPIE: - s/key access password:CURE MIKE BANE HIM RACY GORE -ID unfurl s/key is 100 to17759 -CURE MIKE BANE HIM RACY GORE + &prompt.user; opiekey 498 to4268 +Using the MD5 algorithm to compute response. +Reminder: Don't use opiekey from telnet or dial-in sessions. +Enter secret pass phrase: +GAME GAG WELT OUT DOWN CHAT + - The rest of the description from the previous section applies - here as well. + Теперь переключитесь на незащищенное соединение и скопируйте + одноразовый пароль, сгенерированный соответствующей программой. - Generating a single one-time password + Создание одного одноразового пароля - Once you've initialized S/Key, when you login you will be - presented with a prompt like this: + Как только вы настроите S/Key или OPIE, во время входа появится + приглашение вроде этого: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <username> s/key 97 fw13894 Password: - As a side note, the S/Key prompt has a useful feature - (not shown here): if you press return at the password prompt, the - login program will turn echo on, so you can see what you are - typing. This can be extremely useful if you are attempting to - type in an S/Key by hand, such as from a printout. Also, if this - machine were configured to disallow UNIX passwords over a - connection from my machine, the prompt would have also included - the annotation (s/key required), indicating - that only S/Key one-time passwords will be accepted. - - At this point you need to generate your one-time password to - answer this login prompt. This must be done on a trusted system - that you can run the key command on. (There - are versions of the key program from DOS, - Windows and MacOS as well.) The key program - needs both the iteration count and the seed as command line - options. You can cut-and-paste these right from the login prompt - on the machine that you are logging in to. - - On the trusted system: + Или для OPIE: + +&prompt.user; telnet example.com +Trying 10.0.0.1... +Connected to example.com +Escape character is '^]'. + +FreeBSD/i386 (example.com) (ttypa) + +login: <username> +otp-md5 498 gr4269 ext +Password: + + Кроме того, у S/Key и OPIE есть полезная особенность (не + показанная здесь): если вы нажмете Enter + в приглашении на ввод пароля, включится эхо, и вы сможете увидеть + то, что вводите. Это может быть очень полезно, если вы пытаетесь + ввести пароль вручную, например с распечатки. + + MS-DOS + Windows + MacOS + + В этот момент вам потребуется сгенерировать одноразовый пароль, + чтобы ввести его в приглашение. Это должно быть выполнено на + защищенной системе, в которой вы можете запустить + key или opiekey (есть версии + для DOS, &windows; и &macos;). Им требуются значения счетчика цикла + и ключ в качестве параметров командной строки. Вы можете скопировать + и вставить их прямо из приглашения login компьютера, на который + входите. + + В защищенной системе: &prompt.user; key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: WELD LIP ACTS ENDS ME HAAG - Now that you have your one-time password you can continue - logging in: + Для OPIE: + + &prompt.user; opiekey 498 to4268 +Using the MD5 algorithm to compute response. +Reminder: Don't use opiekey from telnet or dial-in sessions. +Enter secret pass phrase: +GAME GAG WELT OUT DOWN CHAT + + Теперь, когда у вас есть одноразовый пароль, можете продолжить + вход в систему: login: <username> s/key 97 fw13894 Password: <return to enable echo> s/key 97 fw13894 Password [echo on]: WELD LIP ACTS ENDS ME HAAG Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... - This is the easiest mechanism if you have - a trusted machine. There is a Java S/Key key - applet, The Java OTP - Calculator, that you can download and run locally on any - Java supporting browser. - Generating multiple one-time passwords + Создание нескольких одноразовых паролей - Sometimes you have have to go places where you do not have - access to a trusted machine or secure connection. In this case, - it is possible to use the key command to - generate a number of one-time passwords before hand to be printed - out and taken with you. For example: + Иногда вы отправляетесь туда, где нет доступа к защищенному + компьютеру или защищенному соединению. В этом случае, можно + использовать команды key и + opiekey для создания нескольких одноразовых + паролей, которые вы сможете распечатать и забрать с собой. + Например: &prompt.user; key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <secret password> 26: SODA RUDE LEA LIND BUDD SILT 27: JILT SPY DUTY GLOW COWL ROT 28: THEM OW COLA RUNT BONG SCOT 29: COT MASH BARR BRIM NAN FLAG 30: CAN KNEE CAST NAME FOLK BILK - The requests five keys in sequence, the - specifies what the last iteration number - should be. Note that these are printed out in - reverse order of eventual use. If you are - really paranoid, you might want to write the results down by hand; - otherwise you can cut-and-paste into lpr. Note - that each line shows both the iteration count and the one-time - password; you may still find it handy to scratch off passwords as - you use them. + Или для OPIE: + + &prompt.user; opiekey -n 5 30 zz99999 +Using the MD5 algorithm to compute response. +Reminder: Don't use opiekey from telnet or dial-in sessions. +Enter secret pass phrase: <secret password> +26: JOAN BORE FOSS DES NAY QUIT +27: LATE BIAS SLAY FOLK MUCH TRIG +28: SALT TIN ANTI LOON NEAL USE +29: RIO ODIN GO BYE FURY TIC +30: GREW JIVE SAN GIRD BOIL PHI + + Параметр запрашивает пять паролей, + указывает значение последнего счетчика цикла. + Обратите внимание, что пароли печатаются в + обратном по сравнению с обычным использованием + порядке. Если вы действительно параноик, перепишите результат + вручную; иначе скопируйте и передайте его lpr. + Обратите внимание, что каждая линия содержит как счетчик цикла, так + и одноразовый пароль; вам может показаться удобным отрывать пароль + после использования. - Restricting use of UNIX passwords - - Restrictions can be placed on the use of UNIX passwords based - on the host name, user name, terminal port, or IP address of a - login session. These restrictions can be found in the - configuration file /etc/skey.access. The - &man.skey.access.5; manual page has more info on the complete - format of the file and also details some security cautions to be - aware of before depending on this file for security. - - If there is no /etc/skey.access file - (this is the FreeBSD default), then all users will be allowed to - use UNIX passwords. If the file exists, however, then all users - will be required to use S/Key unless explicitly permitted to do - otherwise by configuration statements in the - skey.access file. In all cases, UNIX - passwords are permitted on the console. - - Here is a sample configuration file which illustrates the - three most common sorts of configuration statements: - - -permit internet 192.168.0.0 255.255.0.0 + Ограничение использования &unix; паролей + + S/Key может наложить ограничения на использование &unix; паролей + на основе имени хоста, имени пользователя, порта терминала или IP + адреса сессии. Эти ограничения можно найти в файле настройки + /etc/skey.access. Страница справочника + &man.skey.access.5; содержит дополнительную информацию о полном + формате файла а также детали о некоторых предосторожностях, которые + должны быть предприняты перед тем, как положиться в вопросах + безопасности на этот файл. + + Если файла /etc/skey.access нет (это + ситуация по умолчанию в системах FreeBSD 4.X), всем пользователям + будет разрешено входить с паролями &unix;. Если файл существует, + использование S/Key станет обязательно для всех, если только + параметры настройки в файле skey.access не + указывают иначе. В любом случае, пароли &unix; разрешены при входе + с консоли. + + Вот пример файла настройки skey.access, + иллюстрирующий три наиболее распространенных вида параметров + настройки: + + permit internet 192.168.0.0 255.255.0.0 permit user fnord permit port ttyd0 - The first line (permit internet) allows - users whose IP source address (which is vulnerable to spoofing) - matches the specified value and mask, to use UNIX passwords. This - should not be considered a security mechanism, but rather, a means - to remind authorized users that they are using an insecure network - and need to use S/Key for authentication. - - The second line (permit user) allows the - specified username, in this case fnord, to use - UNIX passwords at any time. Generally speaking, this should only - be used for people who are either unable to use the - key program, like those with dumb terminals, or - those who are uneducable. - - The third line (permit port) allows all - users logging in on the specified terminal line to use UNIX - passwords; this would be used for dial-ups. + Первая строка (permit internet) разрешает + пользователям, чей IP адрес (который подвержен подделке) + соответствует заданному значению и маске, входить с использованием + паролей &unix;. Это должно рассматриваться не как механизм + безопасности, а как напоминание пользователям, что они работают через + небезопасное соединение и должны использовать для аутентификации + S/Key. + + Вторая строка (permit user) позволяет + определенным пользователям, в данном случае + fnord, всегда использовать пароли &unix;. + Вообще говоря, это должно использоваться только для тех, кто + не может использовать программу key, например + если они работают с простых терминалов или необучаемы. + + Третья строка (permit port) позволяет всем + пользователям, вошедшим с определенного терминала использовать + пароли &unix;; этот параметр должен использоваться для подключений + по dial-up. + + OPIE может ограничивать использование паролей &unix; на основе IP + адреса как и S/Key. Соответствующий файл называется + /etc/opieaccess, он существует по умолчанию в + FreeBSD 5.0 и более современных системах. Обратитесь к + &man.opieaccess.5; за более подробной информацией об этом файле и о + предосторожностях, которые вы должны предпринять при использовании + этого файла. + + Вот пример файла opieaccess: + + permit 192.168.0.0 255.255.0.0 + + Эта строка позволяет пользователям, чей IP адрес (который + подвержен подделке) соответствует указанному значению и маске, + входить с паролем &unix;. + + Если ни одно из правил в opieaccess не + сработало, поведением по умолчанию является запрет всех не-OPIE + входов. + - - Kerberos - - Contributed by &a.markm; (based on contribution by - &a.md;). - - Kerberos is a network add-on system/protocol that allows users to - authenticate themselves through the services of a secure server. - Services such as remote login, remote copy, secure inter-system file - copying and other high-risk tasks are made considerably safer and more - controllable. - - The following instructions can be used as a guide on how to set up - Kerberos as distributed for FreeBSD. However, you should refer to the - relevant manual pages for a complete description. - - In FreeBSD, the Kerberos is not that from the original 4.4BSD-Lite, - distribution, but eBones, which had been previously ported to FreeBSD - 1.1.5.1, and was sourced from outside the USA/Canada, and is thus - available to system owners outside those countries. - - For those needing to get a legal foreign distribution of this - software, please do not get it from a USA or Canada - site. You will get that site in big trouble! A - legal copy of this is available from ftp.internat.FreeBSD.org, which is in South - Africa and an official FreeBSD mirror site. - + + + + + + + Mark + Murray + Предоставил + + + + + Mark + Dapoz + Оригинальный текст предоставил + + + + + KerberosIV + + Kerberos это сетевая дополнительная система/протокол, которая + делает возможной аутентификацию пользователей через сервисы на защищенном + сервере. Такие сервисы, как удаленный вход, удаленное копирование, + защищенное копирование файлов между системами и другие задачи с + высоким риском становятся допустимо безопасными и более + контролируемыми. + + Последующие инструкции могут использоваться в качестве руководства + по настройке поставляемого с FreeBSD Kerberos. Тем не менее, вам + могут потребоваться страницы справочника полного дистрибутива. + - Creating the initial database - - This is done on the Kerberos server only. First make sure that - you do not have any old Kerberos databases around. You should change - to the directory /etc/kerberosIV and check that - only the following files are present: - + Установка KerberosIV + + MIT + + KerberosIV + установка + + Kerberos это опциональный компонент &os;. Простейший способ + установки этой программы это выбор krb4 или + krb5 из sysinstall + во время первой установки FreeBSD. Будет установлен + eBones (KerberosIV) или Heimdal + (Kerberos5) вариант Kerberos. Включение этих реализаций объясняется + тем, что они разработаны вне США/Канады и доступны вне этих стран, + поскольку на них не влияют ограничения на экспорт криптографического + кода из США. + + Кроме того, реализация MIT Kerberos доступна из коллекции портов + в виде пакета + security/krb5. + + + + Создание базы данных + + Это необходимо сделать только на сервере Kerberos. Во-первых, + убедитесь что не осталось старой базы данных Kerberos. Войдите + в каталог /etc/kerberosIV и убедитесь, что в нем + находятся только эти файлы: + &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms - - If any additional files (such as principal.* - or master_key) exist, then use the - kdb_destroy command to destroy the old Kerberos - database, of if Kerberos is not running, simply delete the extra - files. - - You should now edit the krb.conf and - krb.realms files to define your Kerberos realm. - In this case the realm will be GRONDAR.ZA and the - server is grunt.grondar.za. We edit or create - the krb.conf file: - + + Если присутствуют еще какие-то файлы (такие как + principal.* или master_key), + используйте команду kdb_destroy для удаления старой + базы данных Kerberos, или, если Kerberos не запущен, просто удалите + эти файлы. + + Затем отредактируйте файлы krb.conf и + krb.realms, введя ваши данные. В этом примере + уникальный идентификатор EXAMPLE.COM, сервер + grunt.example.com. Отредактируем или + создадим файл krb.conf: + &prompt.root; cat krb.conf -GRONDAR.ZA -GRONDAR.ZA grunt.grondar.za admin server +EXAMPLE.COM +EXAMPLE.COM grunt.example.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov - - In this case, the other realms do not need to be there. They are - here as an example of how a machine may be made aware of multiple - realms. You may wish to not include them for simplicity. - - The first line names the realm in which this system works. The - other lines contain realm/host entries. The first item on a line is a - realm, and the second is a host in that realm that is acting as a - key distribution centre. The words admin - server following a hosts name means that host also - provides an administrative database server. For further explanation - of these terms, please consult the Kerberos man pages. - - Now we have to add grunt.grondar.za - to the GRONDAR.ZA realm and also add an entry to - put all hosts in the .grondar.za - domain in the GRONDAR.ZA realm. The - krb.realms file would be updated as - follows: - + + В этом примере другие идентификаторы введены для иллюстрации + настройки c несколькими хостами. С целью упрощения + настройки вы можете не включать их. + + Первая строка содержит идентификатор, под которым работает эта + система. Остальные строки связывают идентификаторы с именами хостов. + Сначала указывается идентификатор, затем хост под этим + идентификатором, работающий как центр распространения + ключей. Слова admin server с последующим + именем хоста означают, что этот хост также является сервером + администрирования базы данных. За дальнейшей информацией об этих + терминах обратитесь к страницам справочника по Kerberos. + + Мы добавили grunt.example.com + к идентификатору EXAMPLE.COM и кроме того + сопоставили всем хостам в домене + .example.com идентификатор + EXAMPLE.COM. Файл + krb.realms будет выглядеть так: + &prompt.root; cat krb.realms -grunt.grondar.za GRONDAR.ZA -.grondar.za GRONDAR.ZA +grunt.example.com EXAMPLE.COM +.example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU - - Again, the other realms do not need to be there. They are here as - an example of how a machine may be made aware of multiple realms. You - may wish to remove them to simplify things. - - The first line puts the specific system into - the named realm. The rest of the lines show how to default systems of - a particular subdomain to a named realm. - - Now we are ready to create the database. This only needs to run - on the Kerberos server (or Key Distribution Centre). Issue the - kdb_init command to do this: - + + Как и в предыдущем примере, другие идентификаторы добавлены только + для примера. С целью упрощения настройки вы можете не включать + их. + + В первой строке определенная система + сопоставляется с идентификатором. В остальных строках показано, + сопоставить идентификатору остальные системы определенного + поддомена. + + Теперь мы готовы к созданию базы данных. Потребуется всего лишь + запустить сервер Kerberos (или центр распространения ключей). + Используйте для этого kdb_init: + &prompt.root; kdb_init -Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA +Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. -Enter Kerberos master key: - - Now we have to save the key so that servers on the local machine - can pick it up. Use the kstash command to do - this. - +Введите главный ключ Kerberos: + + Теперь мы должны сохранить ключ, чтобы сервера на локальных + компьютерах могли его взять. Используйте для этого команду + kstash: + &prompt.root; kstash - + Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! - - This saves the encrypted master password in + + Этой командой зашифрованный главный пароль сохранен в /etc/kerberosIV/master_key. - + - Making it all run - - Two principals need to be added to the database for - each system that will be secured with Kerberos. - Their names are kpasswd and rcmd - These two principals are made for each system, with the instance being - the name of the individual system. - - These daemons, kpasswd and - rcmd allow other systems to change Kerberos - passwords and run commands like rcp, - rlogin and rsh. - - Now let's add these entries: - + Запуск Kerberos + + + KerberosIV + первый запуск + + + Для каждой системы, защищаемой Kerberos, в базу данных должны + быть добавлены две записи. Это kpasswd и + rcmd. Они добавляются вместе с именем + системы. + + Эти даемоны, kpasswd и + rcmd позволяют другим системам изменять + пароли Kerberos и запускать такие команды как &man.rcp.1;, + &man.rlogin.1;, &man.rsh.1;. + + Теперь добавим эти записи: + &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit - Creating the server file - - We now have to extract all the instances which define the services - on each machine. For this we use the ext_srvtab - command. This will create a file which must be copied or moved - by secure means to each Kerberos client's - /etc/kerberosIV directory. This file must be present on each server - and client, and is crucial to the operation of Kerberos. - - + Создание файла настройки сервера + + Теперь необходимо создать все записи сервисов, которые были + определены для каждого компьютера. Используем для этого команду + ext_srvtab. Будет создан файл, который должен + быть скопирован или перемещен безопасным способом + в каталог /etc/kerberosIV каждого Kerberos + клиента. Этот файл должен присутствовать на каждом сервере и + клиенте, он необходим для работы Kerberos. + &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... - - Now, this command only generates a temporary file which must be - renamed to srvtab so that all the server can pick - it up. Use the mv command to move it into place on - the original system: - + + Эта команда создаст временный файл, который должен быть + переименован в srvtab, чтобы серверы смогли + обратиться к нему. Используйте команду &man.mv.1; для перемещения + его в исходной системе: + &prompt.root; mv grunt-new-srvtab srvtab - - If the file is for a client system, and the network is not deemed - safe, then copy the - client-new-srvtab to - removable media and transport it by secure physical means. Be sure to - rename it to srvtab in the client's - /etc/kerberosIV directory, and make sure it is - mode 600: - + + Если файл предназначен для клиентской системы, и сеть не + безопасна, скопируйте + client-new-srvtab + на съемный носитель и перенесите файл с его помощью. Убедитесь, что + переименовали его в srvtab в каталоге + /etc/kerberosIV клиента, и что режим доступа к + нему 600: + &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab - + - Populating the database - - We now have to add some user entries into the database. First - let's create an entry for the user jane. Use the - kdb_edit command to do this: - + Пополнение базы данных + + Теперь необходимо добавить в базу данных пользователей. + Во-первых, создадим запись для пользователя jane. + Используйте команду kdb_edit: + &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- enter a secure password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit - Testing it all out - - First we have to start the Kerberos daemons. NOTE that if you - have correctly edited your /etc/rc.conf then this - will happen automatically when you reboot. This is only necessary on - the Kerberos server. Kerberos clients will automatically get what - they need from the /etc/kerberosIV - directory. - + Тестирование всей системы + + Во-первых, запустите даемоны Kerberos. При правильном + редактировании файла /etc/rc.conf они запустятся + автоматически при перезагрузке. Это необходимо только на сервере + Kerberos. Клиенты Kerberos получат все необходимые данные из + каталога /etc/kerberosIV. + &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 -Local realm: GRONDAR.ZA +Local realm: EXAMPLE.COM &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! - - Now we can try using the kinit command to get a - ticket for the id jane that we created - above: - + + Теперь для получения доступа через созданного пользователя + jane используйте kinit: + &prompt.user; kinit jane -MIT Project Athena (grunt.grondar.za) +MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane" Password: - - Try listing the tokens using klist to see if we - really have them: - + + Попробуйте просмотреть имеющиеся данные с помощью + klist: + &prompt.user; klist Ticket file: /tmp/tkt245 -Principal: jane@GRONDAR.ZA +Principal: jane@EXAMPLE.COM Issued Expires Principal -Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA - - Now try changing the password using passwd to - check if the kpasswd daemon can get authorization to the Kerberos - database: - +Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM + + Теперь попробуйте изменить пароль с помощью &man.passwd.1;, + чтобы убедиться, что даемон kpasswd + может получить информацию из базы данных Kerberos: + &prompt.user; passwd -realm GRONDAR.ZA +realm EXAMPLE.COM Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. - Adding <command>su</command> privileges - - Kerberos allows us to give each user who - needs root privileges their own separate - supassword. We could now add an id which is - authorized to su to root. - This is controlled by having an instance of root - associated with a principal. Using kdb_edit we can - create the entry jane.root in the Kerberos - database: - + Включение <command>su</command> + + Kerberos позволяет назначить каждому + пользователю, который нуждается в привилегиях + root, свой собственный + пароль &man.su.1;. Необходимо добавить учетную запись, которой + разрешено получать root доступ через &man.su.1;. + Это делается путем связывания учетной записи root + с пользовательской учетной записью. Создадим в базе данных Kerberos + запись jane.root с помощью + kdb_edit: + &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- enter a SECURE password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit - - Now try getting tokens for it to make sure it works: - + + Теперь проверим работоспособность этой записи: + &prompt.root; kinit jane.root -MIT Project Athena (grunt.grondar.za) +MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root" Password: - - Now we need to add the user to root's .klogin - file: - + + Необходимо добавить пользователя к root + файлу .klogin: + &prompt.root; cat /root/.klogin -jane.root@GRONDAR.ZA - - Now try doing the su: - - &prompt.user; su +jane.root@EXAMPLE.COM + + Теперь попробуйте выполнить &man.su.1;: + + &prompt.user; su Password: - - and take a look at what tokens we have: - - &prompt.root; klist + + и посмотрите на имеющиеся данные: + + &prompt.root; klist Ticket file: /tmp/tkt_root_245 -Principal: jane.root@GRONDAR.ZA +Principal: jane.root@EXAMPLE.COM Issued Expires Principal -May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA +May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM - Using other commands - - In an earlier example, we created a principal called - jane with an instance root. - This was based on a user with the same name as the principal, and this - is a Kerberos default; that a - <principal>.<instance> of the form - <username>.root will allow - that <username> to su to - root if the necessary entries are in the .klogin - file in root's home directory: - + Использование других команд + + В примере выше мы создали запись (principal) + jane с доступом к root + (instance). Она основана на пользователе с таким же именем, как + и идентификатор, что принято Kerberos по умолчанию; + <principal>.<instance> в форме + <username>.root + позволяет использовать &man.su.1; для доступа к + root, если соответствующие записи находятся + в файле .klogin домашнего каталога + root: + &prompt.root; cat /root/.klogin -jane.root@GRONDAR.ZA - - Likewise, if a user has in their own home directory lines of the - form: - +jane.root@EXAMPLE.COM + + Подобно этому, если в файле .klogin + из домашнего каталога пользователя есть строки в форме: + &prompt.user; cat ~/.klogin -jane@GRONDAR.ZA -jack@GRONDAR.ZA - - This allows anyone in the GRONDAR.ZA realm - who has authenticated themselves to jane or - jack (via kinit, see above) - access to rlogin to jane's - account or files on this system (grunt) via - rlogin, rsh or - rcp. - - For example, Jane now logs into another system, using - Kerberos: - +jane@EXAMPLE.COM +jack@EXAMPLE.COM + + это позволит любому с идентификатором + EXAMPLE.COM, кто аутентифицировался как + jane или jack + (с помощью команды kinit, см. выше) + получить доступ к учетной пользователя jane + или файлам этой системы (grunt) через + &man.rlogin.1;, &man.rsh.1; или &man.rcp.1;. + + Например, jane может входить в другую систему + используя Kerberos: + &prompt.user; kinit -MIT Project Athena (grunt.grondar.za) +MIT Project Athena (grunt.example.com) Password: -%prompt.user; rlogin grunt +&prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 - - Or Jack logs into Jane's account on the same machine (Jane having - set up the .klogin file as above, and the person - in charge of Kerberos having set up principal - jack with a null instance: - + + Или jack входит в учетную запись + jane's на этом же компьютере + (файл .klogin jane + настроен как показано выше, и в Kerberos настроена учетная + запись jack): + &prompt.user; kinit &prompt.user; rlogin grunt -l jane -MIT Project Athena (grunt.grondar.za) +MIT Project Athena (grunt.example.com) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 - - - Firewalls - Contributed by &a.gpalmer; and &a.alex;. + + + + + Tillman + Hodgson + Предоставил + + + + + Mark + Murray + Оригинальный материал предоставил + + + + + <application>Kerberos5</application> + + Все релизы &os; после &os;-5.1 включают поддержку только + Kerberos5. Таким образом, + Kerberos5 это единственная включаемая в + поставку версия и его конфигурация похожа на + KerberosIV во многих аспектах. Эта + информация применима только к Kerberos5 + из релизов после &os;-5.0. Пользователи, желающие использовать + пакет KerberosIV, могут установить его из + порта security/krb4. + + Kerberos это дополнительная сетевая + система/протокол, позволяющая пользователям авторизоваться через + защищенные сервисы на защищенном сервере. Такие сервисы как + удаленный вход, удаленное копирование, защищенное копирование файлов + между системами и другие задачи с высоким риском становятся + допустимо безопасными и более контролируемыми. + + Kerberos может быть описана как + прокси система идентификации-проверки. Она также может быть описана + как защищенная внешняя система аутентификации. + Kerberos предоставляет только одну функцию + — защищенную аутентификацию пользователей сети. Он не предоставляет + Он не предоставляет функций авторизации (что разрешено делать + пользователям) или функций аудита (какой пользователь что делает). + После того, как клиент и сервер использовали + Kerberos для идентификации, они могут + зашифровать все соединения для гарантирования собственной безопасности и + целостности данных. + + Следовательно крайне рекомендуется использовать + Kerberos с другими методами безопасности, + предоставляющими сервисы авторизации и аудита. + + Последующие инструкции могут использоваться в качестве руководства + по настройке Kerberos, поставляемого с &os;. + Тем не менее, вам потребуется обратиться к соответствующим страницам + справочника за полным описанием. + + В целях демонстрации установки Kerberos, + будут применены следующие обозначения: + + + + DNS домен (зона) + example.org. + + + + Уникальный идентификатор Kerberos + EXAMPLE.ORG. + + + + + Используйте действующие имена доменов при настройке + Kerberos даже если вы будете использовать + его во внутренней сети. Это позволит избежать проблем с + DNS и гарантирует возможность связи с + Kerberos под другими + идентификаторами. + + + + История + + Kerberos5 + история + + + Kerberos был создан + MIT в качестве решения проблем с безопасностью + сети. Протокол Kerberos использует + стойкую криптографию, так что клиент может идентифицироваться на + сервере (и обратно) через незащищенное сетевое соединение. + + Kerberos это и имя сетевого протокола + аутентификации и общий термин для описания программ, где он + реализован (например, Kerberos telnet). + Текущая версия протокола 5 описана в + RFC 1510. + + Доступно несколько свободных реализаций этого протокола, + работающих на множестве операционных систем. Massachusetts + Institute of Technology (MIT), где + Kerberos был первоначально разработан, + продолжает разрабатывать собственный пакет + Kerberos. Он обычно использовался + в США как криптографический продукт, + и в этом качестве попадал под действие ограничений на экспорт. + MIT Kerberos + доступен в виде порта (security/krb5). Heimdal + Kerberos это другая реализация версии + 5, которая разрабатывалась исключительно вне США + для обхода экспортных ограничений (и поэтому часто включалась в + некоммерческие реализации &unix;). Heimdal + Kerberos доступен в виде порта + (security/heimdal), + его минимальный комплект включен в базовую установку &os;. + + В целях получения наибольшей аудитории, в этих инструкциях + предполагается использование Heimdal включаемого в &os;. + + + + + Настройка Heimdal <acronym>KDC</acronym> + + Kerberos5 + настройка центра распространения ключей + + + Центр распространения ключей (Key Distribution Center, + KDC) это централизованный сервис аутентификации, + предоставляемый Kerberos — + это компьютер, который предоставляет доступ через + Kerberos. KDC + считается доверяемым всеми другими компьютерами с определенным + идентификатором Kerberos и поэтому + к нему предъявляются высокие требования безопасности. + + Имейте ввиду, что хотя работа сервера + Kerberos требует очень немного + вычислительных ресурсов, из соображений безопасности для него + рекомендуется отдельный компьютер, работающий только в качестве + KDC. + + Перед началом настройки KDC, убедитесь что в + файле /etc/rc.conf содержатся правильные + настройки для работы в качестве KDC (вам может + потребоваться изменить пути в соответствии с собственной + системой): + + kerberos5_server_enable="YES" +kadmind5_server_enable="YES" +kerberos_stash="YES" + + + Параметр существует только в + &os; 4.X. + + + Затем приступим к редактированию файла настройки + Kerberos, + /etc/krb5.conf: + + [libdefaults] + default_realm = EXAMPLE.ORG +[realms] + EXAMPLE.ORG = { + kdc = kerberos.example.org + } +[domain_realm] + .example.org = EXAMPLE.ORG + + Обратите внимание что в файле /etc/krb5.conf + подразумевается наличие у KDC полного имени + kerberos.example.org. Вам потребуется + добавить CNAME (синоним) к файлу зоны, если у + KDC другое имя. + + + Для больших сетей с правильно настроенным сервером + BIND DNS пример выше + может быть урезан до: + + [libdefaults] + default_realm = EXAMPLE.ORG + + Со следующими строками, добавленными в файл зоны + example.org: + + _kerberos._udp IN SRV 01 00 88 kerberos.example.org. +_kerberos._tcp IN SRV 01 00 88 kerberos.example.org. +_kpasswd._udp IN SRV 01 00 464 kerberos.example.org. +_kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. +_kerberos IN TXT EXAMPLE.ORG. + + Создадим теперь базу данных Kerberos. + Эта база данных содержит ключи всех основных хостов, зашифрованных + с помощью главного пароля. Вам не требуется помнить этот пароль, + он хранится в файле (/var/heimdal/m-key). + Для создания главного ключа запустите kstash + и введите пароль. + + Как только будет создан главный ключ, вы можете инициализировать + базу данных с помощью программы kadmin с ключом + -l (означающим local). Этот + ключ сообщает kadmin обращаться к файлам базы + данных непосредственно вместо использования сетевого сервиса + kadmind. Это помогает решить проблему + курицы и яйца, когда обращение идет к еще не созданной базе + данных. Как только вы увидите приглашение kadmin, + используйте команду init для создания базы + данных идентификаторов. + + Наконец, оставаясь в приглашении kadmin, + создайте первую запись с помощью команды add. + Оставьте неизменными параметры по умолчанию, вы всегда сможете + изменить их позже с помощью команды modify. + Обратите внимание, что вы всегда можете использовать команду + ? для просмотра доступных параметров. + + Пример создания базы данных показан ниже: + + &prompt.root; kstash +Master key: xxxxxxxx +Verifying password - Master key: xxxxxxxx + +&prompt.root; kadmin -l +kadmin> init EXAMPLE.ORG +Realm max ticket life [unlimited]: +kadmin> add tillman +Max ticket life [unlimited]: +Max renewable life [unlimited]: +Attributes []: +Password: xxxxxxxx +Verifying password - Password: xxxxxxxx + + Теперь пришло время запустить сервисы KDC. + Выполните команды /etc/rc.d/kerberos start и + /etc/rc.d/kadmind start для запуска сервисов. + Ни один из поддерживающих Kerberos + даемонов на этот момент запущен не будет, но у вас должна быть + возможность убедиться в том, что KDC функционирует + путем получения списка доступа для пользователя, которого вы только + что самостоятельно создали из командной строки самого + KDC: + + &prompt.user; k5init tillman +tillman@EXAMPLE.ORG's Password: + +&prompt.user; k5list +Credentials cache: FILE:/tmp/krb5cc_500 + Principal: tillman@EXAMPLE.ORG + + Issued Expires Principal +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG + + + + + Сервер <application>Kerberos</application> с сервисами + Heimdal + + + Kerberos5 + включение сервисов + + + Для начала нам потребуется копия файла настройки + Kerberos, + /etc/krb5.conf. + Просто скопируйте его с KDC на клиентский + компьютер безопасным способом (используя сетевые утилиты, такие + как &man.scp.1;, или физически, с помощью дискеты). + + Затем вам понадобится файл /etc/krb5.keytab. + Это основное различие между сервером, поддерживающим + Kerberos и рабочими станциями — + на сервере должен быть файл keytab. + В этом файле находится центральный ключ сервера, который позволяет + KDC проверять все другие идентификаторы. Он + должен быть помещен на сервер безопасным способом, поскольку + безопасность сервера может быть нарушена, если ключ станет + общедоступен. Это означает, что его передача через незашифрованный + канал, такой как FTP – очень плохая + идея. + + Обычно перенос файла keytab на сервер + производится с помощью программы kadmin. + Это удобно, поскольку вам потребуется также создать запись хоста + (KDC часть krb5.keytab) + с помощью kadmin. + + Обратите внимание, что должны быть уже зарегистрированы в + системе и необходимо наличие прав на использование интерфейса + kadmin в файле kadmind.acl. + Обратитесь к разделу Remote administration в info + страницах Heimdal (info heimdal) за деталями по + составлению списка доступа. Если вы не хотите включать удаленный + доступ kadmin, можете просто подключиться к + KDC через защищенное соединение (локальную + консоль, &man.ssh.1; или Kerberos + &man.telnet.1;) и выполнять администрирование локально с помощью + kadmin -l. + + После добавления файла /etc/krb5.conf, + вы можете использовать kadmin с сервера + Kerberos. Команда + add --random-key позволит вам добавить запись + для сервера, а команда ext позволит перенести + эту запись в собственный keytab файл сервера. Например: + + &prompt.root; kadmin +kadmin> add --random-key host/myserver.example.org +Max ticket life [unlimited]: +Max renewable life [unlimited]: +Attributes []: +kadmin> ext host/myserver.example.org +kadmin> exit + + Обратите внимание, что команда ext + (сокращение от extract) сохраняет полученный ключ в + файле /etc/krb5.keytab по умолчанию. + + Если на KDC не запущен + kadmind (возможно по соображениям безопасности) + и вы не можете получить доступ к kadmin + удаленно, возможно добавление записи хоста + (host/myserver.EXAMPLE.ORG) непосредственно + на KDC с последующим извлечением ее во временный + файл (и перезаписью /etc/krb5.keytab на + KDC) примерно так: + + &prompt.root; kadmin +kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org +kadmin> exit + + Затем вы можете скопировать keytab на сервер защищенным способом + (например, используя scp или дискету). + Убедитесь, что используемое имя keytab не совпадает с именем + по умолчанию во избежание перезаписывания keytab на + KDC. + + Теперь ваш сервер может связываться с KDC + (добавлен файл krb5.conf) и идентифицировать + себя (добавлен файл krb5.keytab). Теперь вы + готовы к включению некоторых сервисов + Kerberos. В этом примере мы включим + сервис telnet, поместив в + /etc/inetd.conf нижеприведенную строку и + перезапустив сервис &man.inetd.8; командой + /etc/rc.d/inetd restart: + + telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user + + Очень важно установить ключ -a (тип + аутентификации) в user. Обратитесь к странице справочника + &man.telnetd.8; за подробной информацией. + + + + + Клиент <application>Kerberos</application> с Heimdal + + + Kerberos5 + настройка клиента + + + Настройка клиентского компьютера почти тривиально проста. + Как только настройка Kerberos закончена, + вам потребуется только файл настройки + Kerberos, + /etc/krb5.conf. Просто скопируйте его + безопасным способом на клиентский компьютер с + KDC. + + Протестируйте клиентский компьютер, попытавшись использовать + kinit, klist, и + kdestroy для получения, отображения и удаления + списка доступа. Соединитесь с Kerberos + севером используя клиент Kerberos, если + соединение не работает и получение доступа является проблемой, + это скорее всего проблема сервера, а не клиента или + KDC. + + При тестировании приложения вроде telnet, + попробуйте использовать программу перехвата пакетов (такую + как &man.tcpdump.1;), чтобы убедиться, что ваш пароль не передается + незашифрованным. Попробуйте использовать telnet + с параметром -x, чтобы зашифровать весь поток + данных (подобно ssh). + + Основные клиентские приложения + Kerberos (традиционно называющиеся + kinit, klist, + kdestroy, и + kpasswd) находятся в базовой установке &os;. + Обратите внимание, что в &os; версий до 5.0 они были переименованы + в k5init, k5list, + k5destroy, k5passwd, и + k5stash (хотя их обычно использовали лишь + однократно). + + Различные неосновные клиентские приложения + Kerberos также устанавливаются по + умолчанию. Здесь проявляется минимальность + базовой установки Heimdal: telnet это + единственное приложение, поддерживающее + Kerberos. + + Порт Heimdal добавляет некоторые отсутствующие клиентские + приложения: поддерживающие + Kerberos версии + ftp, rsh, + rcp, rlogin, и некоторые + другие реже используемые программы. Порт MIT + также содержит полный пакет клиентских приложений + Kerberos. + + + + + Пользовательские файлы настройки: <filename>.k5login</filename> + и <filename>.k5users</filename> + + + Kerberos5 + пользовательские файлы настройки + + + Учетные записи пользователя в + Kerberos (например + tillman@EXAMPLE.ORG) обычно связаны с + локальными учетными записями (например с локальной учетной записью6 + tillman). Клиентские приложения, такие как + telnet, обычно не требуют указания имени + пользователя или учетной записи. + + Тем не менее, время от времени вам может потребоваться дать + доступ к локальной учетной записи кому-то, у кого нет + соответствующей учетной записи Kerberos. + Например, пользователю tillman@EXAMPLE.ORG + может потребоваться доступ к локальной учетной записи + webdevelopers. Другим учетным записям + также может потребоваться доступ к этой локальной учетной + записи. + + Файлы .k5login и + .k5users, помещенные в домашний каталог + пользователя, могут быть использованы подобно действенной + комбинации .hosts и + .rhosts для решения этой проблемы. + Например, файл .k5login + со следующим содержанием: + + tillman@example.org +jdoe@example.org + + помещен в домашний каталог локального пользователя + webdevelopers, то обе упомянутые учетные + записи получат доступ к этой учетной записи без необходимости + наличия общего пароля. + + Рекомендуется прочитать страницу справочника по этим командам. + Обратите внимание, что страница справочника о + ksu содержит информацию по + .k5users. + + + + + Подсказки, советы и решение проблем с + <application>Kerberos</application> + + + Kerberos5 + решение проблем + + + + + При использовании портов как Heimdal так и + MIT Kerberos + убедитесь, что в PATH версии + Kerberos клиентов указаны перед + их версиями в базовой системе. + + + + Синхронизировано ли время? Вы уверены? Если время не + синхронизировано (обычно в пределах пяти минут) аутентификация + завершится неудачно. + + + + MIT и Heimdal успешно взаимодействуют. + За исключением kadmin, протокол для которого + не стандартизован. + + + Если вы изменяете hostname, потребуется также изменить + учетную запись host/ и обновить keytab. + Это также необходимо для специальных записей в keytab, таких + как www/ запись модуля Apache + www/mod_auth_kerb. + + + + Все хосты под общим идентификатором должны разрешаться + DNS (прямое и обратное разрешение), или + как минимум через /etc/hosts. Записи + CNAME будут работать, но записи A и PTR должны быть корректны + и находиться на своем месте. Сообщение об ошибке не всегда + интуитивно понятно: + Kerberos5 refuses authentication because Read req + failed: Key table entry not found. + + + + Некоторые операционные системы, способные работать в качестве + клиентов KDC не устанавливают права + для ksu в setuid root. + Это означает, что ksu не работает, что хорошо + является хорошей идеей для безопасности, но неудобно. Это не + ошибка KDC. + + + + С MIT + Kerberos, если вы хотите продлить + действие доступа до значения большего, чем десять часов по + умолчанию, используйте команду + modify_principal в + kadmin для изменения maxlife доступа к самой + учетной записи и к учетной записи krbtgt. + Затем возможно использование kinit + с параметром -l для запроса доступа с большим + временем действия. + + + + Если вы запускаете перехватчик пакетов на + KDC для разрешения проблем, а затем + запускаете kinit с рабочей станции, то + увидите, что TGT посылается непосредственно + при запуске kinit — даже до того, как + вы введете пароль! Объяснение в том, что сервер + Kerberos свободно распространяет + TGT (Ticket Granting Ticket) на каждый + неавторизованный запрос; однако, каждый TGT + зашифрован ключом, полученным из пароля пользователя. + Следовательно, когда пользователь вводит свой пароль, он не + отправляется на KDC, а используется для + расшифровка TGT, который уже получен + kinit. Если в процессе расшифровки + получается правильный билет с правильным значением времени, + у пользователя есть действующее удостоверение. + Это удостоверение содержит ключ сессии для установления + безопасного соединения с сервером + Kerberos, как и действующий + TGT, зашифрованный ключом сервера + Kerberos. Второй уровень шифрования + недоступен пользователю, но позволяет серверу + Kerberos проверять правильность + каждого TGT. + + + + Вам необходимо поддерживать время синхронизированным на + всех компьютерах внутри одного идентификатора. + NTP прекрасно подходит для этой задачи. + За дополнительной информацией по NTP + обратитесь к . + + + + Если вы хотите установить большое время жизни доступа + (например, неделю), и используете + OpenSSH для соединения с компьютером, + где хранится билет, убедитесь, что параметр + Kerberos + установлен в + no в файле sshd_config, + или билеты будут уничтожены при выходе из сеанса. + + + + Запомните, что время жизни билетов хостов больше. + Если время жизни билета для учетной записи пользователя + составляет неделю, а время жизни учетной записи хоста, к + которому вы подсоединяетесь девять часов, учетная запись хоста + в кэше устареет и кэш билетов будет работать не так, как + ожидается. + + + + При настройке файла krb5.dict на + предотвращение использования определенных плохих паролей + (страница справочника для kadmind кратко + рассказывает об этом), запомните, что это применимо только + к учетным записям, для которых действует политика паролей. + Формат файла krb5.dict прост: одно слово + на строку. Может помочь создание символической ссылки на + /usr/share/dict/words. + + + + + + + Отличия от порта <acronym>MIT</acronym> + + Основное различие между установками MIT и + Heimdal относится к программе kadmin, + которая имеет другой (но эквивалентный) набор команд и + использует другой протокол. Если ваш KDC + работает на MIT, вы не сможете использовать + kadmin для удаленного администрирования + KDC (и наоборот, по этой же причине). + + Опции командной строки клиентов также могут немного отличаться + для одинаковых задач. Рекомендуется следование инструкциям + на MIT Kerberos + веб сайте (). + Будьте внимательны при определении PATH: + порт MIT устанавливается по умолчанию в + /usr/local/, и если в PATH + вначале указаны системные каталоги, вместо приложений + MIT могут быть запущены системные + приложения. + + С портом MIT + security/krb5, предоставляемым + &os;, убедитесь что файл + /usr/local/share/doc/krb5/README.FreeBSD + установлен портом, если вы хотите понять почему вход через + telnetd и klogind + иногда происходит так странно. Наиболее важно, исправление + incorrect permissions on cache file требует + использования бинарного файла login.krb5 + для аутентификации, чтобы права на переданное удостоверение + передавались правильно. + + + + + Преодоление ограничений, обнаруженных в + <application>Kerberos</application> + + + Kerberos5 + ограничения и недостатки + + + + <application>Kerberos</application> это все или ничего + + Каждый сервис, работающий в сети, должен быть модифицирован + для работы с Kerberos (или другим + способом защищен от атак по сети) или удостоверения пользователей + могут быть украдены или использованы повторно. В качестве примера + может быть приведено использование + Kerberos версий + оболочек для удаленной работы (например через + rsh и telnet), при + наличии POP3 сервера, получающего пароли в + незашифрованном виде. + + + + + <application>Kerberos</application> предназначен для + однопользовательских рабочих станций + + В многопользовательской среде + Kerberos менее безопасен. + Это потому, что он хранит билеты в каталоге + /tmp, которая доступна для чтения всем. + Если пользователь работает с несколькими другими пользователями + одновременно на одном компьютере (т.е. в многопользовательской + среде), возможна кража (копирование) билета другим + пользователем. + + Решить проблему можно с помощью параметра командной + строки -c или (предпочтительно) с помощью + переменной окружения KRB5CCNAME, но это делается + редко. Для преодоления ограничения достаточно сохранять билет + в домашнем каталоге пользователя и использовать простые + ограничения на доступ к файлам. + + + + + От KDC зависит вся система + + Архитектура системы такова, что KDC должен + быть максимально защищен, поскольку главный пароль базы данных + содержится в нем. На KDC не должно быть + запущено никаких других сервисов и он должен быть защищен + физически. Опасность велика, поскольку + Kerberos хранит все пароли + зашифрованными одним ключом (главным ключом), + который хранится в файле на KDC. + + Хорошей новостью является то, что кража главного ключа + не станет такой проблемой, как может показаться. Главный ключ + используется только для шифрования базы данных + Kerberos и в качестве seed для + генератора случайных чисел. Поскольку доступ к + KDC защищен, атакующий мало что сможет сделать + с главным ключом. + + Кроме того, если KDC станет недоступен + (возможно по причине атак DoS или проблем в сети) сетевые сервисы + будет невозможно использовать, поскольку аутентификация не + может быть выполнена. + Уменьшить последствия можно при наличии нескольких + KDC (один главный и один или несколько + резервных) и с аккуратно реализованной резервной аутентификацией + (отлично подойдет PAM). + + + + + Недостатки <application>Kerberos</application> + + Kerberos позволяет пользователям, + хостам и сервисам производить аутентификацию друг друга. + В нем нет механизма аутентификации KDC + для пользователей, хостов или сервисов. Это означает, что + поддельный kinit (например) может записывать + все имена пользователей и паролей. Помочь решить проблему может + security/tripwire или + другой инструмент проверки целостности файловой системы. + + + + + + Ресурсы и информация для дальнейшего изучения + + + Kerberos5 + внешние ресурсы + + + + + + Kerberos FAQ + + + + Разработка + системы аутентификации: диалог в четырех сценах + + + + RFC 1510, + Kerberos Network Authentication Service + (V5) + + + + Домашняя страница + MIT + Kerberos + - Firewalls are an area of increasing interest for people who are - connected to the Internet, and are even finding applications on private - networks to provide enhanced security. This section will hopefully - explain what firewalls are, how to use them, and how to use the - facilities provided in the FreeBSD kernel to implement them. + + Домашняя страница + Heimdal Kerberos + + + + + + + + + + + Gary + Palmer + Предоставили + + + Alex + Nash + + + + + Межсетевые экраны + firewall + + безопасность + межсетевые экраны + + + Интерес к межсетевым экранам (брандмауэр, firewall) со стороны людей, + подключенных к интернет, все возрастает и появились даже приложения + для локальной сети, предоставляющие повышенный уровень безопасности. + В этом разделе мы надеемся изложить что такое межсетевые экраны, как + их использовать, и как использовать возможности, предоставляемые + ядром FreeBSD для их реализации. - People often think that having a firewall between your - internal network and the Big Bad Internet will solve all - your security problems. It may help, but a poorly setup firewall - system is more of a security risk than not having one at all. A - firewall can add another layer of security to your systems, but it - cannot stop a really determined cracker from penetrating your internal - network. If you let internal security lapse because you believe your - firewall to be impenetrable, you have just made the crackers job that - much easier. + Люди часто думают, что наличие межсетевого экрана между + внутренней сетью и Большим плохим интернетом решит все + их проблемы безопасности. Это может помочь, но плохо настроенный + межсетевой экран представляет более серьезную угрозу безопасности, + чем его полное отсутствие. Межсетевой экран добавляет еще один + уровень безопасности вашим системам, но не может остановить + проникновение решительно настроенного взломщика в вашу сеть. Если + вы снижаете внутреннюю безопасность системы, поскольку верите в + надежность межсетевого экрана, это существенно упрощает работу + взломщика. - What is a firewall? - - There are currently two distinct types of firewalls in common use - on the Internet today. The first type is more properly called a - packet filtering router, where the kernel on a - multi-homed machine chooses whether to forward or block packets based - on a set of rules. The second type, known as a proxy - server, relies on daemons to provide authentication and to - forward packets, possibly on a multi-homed machine which has kernel - packet forwarding disabled. - - Sometimes sites combine the two types of firewalls, so that only a - certain machine (known as a bastion host) is - allowed to send packets through a packet filtering router onto an - internal network. Proxy services are run on the bastion host, which - are generally more secure than normal authentication - mechanisms. - - FreeBSD comes with a kernel packet filter (known as - IPFW), which is what the rest of this - section will concentrate on. Proxy servers can be built on FreeBSD - from third party software, but there is such a variety of proxy - servers available that it would be impossible to cover them in this - document. - + Что такое межсетевой экран? + + Есть два четко различающихся типа межсетевых экранов, повседневно + используемых в современном интернет. Первый тип правильнее называть + маршрутизатор с фильтрацией пакетов. Этот тип + межсетевого экрана работает на машине, подключенной к нескольким сетям + и применяет к каждому пакету набор правил, определяющий переправлять + ли этот пакет или блокировать. Второй тип, известный как + прокси сервер, реализован в виде даемонов, + выполняющих аутентификацию и пересылку пакетов, возможно на + машине с несколькими сетевыми подключениями, где пересылка + пакетов в ядре отключена. + + Иногда эти два типа межсетевых экранов используются вместе, так + что только определенной машине (известной как защитный + хост (bastion host)) позволено отправлять пакеты через + фильтрующий маршрутизатор во внутреннюю сеть. Прокси сервисы работают + на защитном хосте, что обычно более безопасно, чем обычные механизмы + аутентификации. + + FreeBSD поставляется с встроенным в ядро фильтром пакетом + (известным как IPFW), ему будет посвящена оставшаяся часть раздела. + Прокси серверы могут быть собраны на FreeBSD из программного + обеспечения сторонних разработчиков, но их слишком много и невозможно + описать их в этом разделе. + - Packet filtering routers - - A router is a machine which forwards packets between two or more - networks. A packet filtering router has an extra piece of code in - its kernel which compares each packet to a list of rules before - deciding if it should be forwarded or not. Most modern IP routing - software has packet filtering code within it that defaults to - forwarding all packets. To enable the filters, you need to define a - set of rules for the filtering code so it can decide if the - packet should be allowed to pass or not. - - To decide whether a packet should be passed on, the code looks - through its set of rules for a rule which matches the contents of - this packets headers. Once a match is found, the rule action is - obeyed. The rule action could be to drop the packet, to forward the - packet, or even to send an ICMP message back to the originator. - Only the first match counts, as the rules are searched in order. - Hence, the list of rules can be referred to as a rule - chain. - - The packet matching criteria varies depending on the software - used, but typically you can specify rules which depend on the source - IP address of the packet, the destination IP address, the source - port number, the destination port number (for protocols which - support ports), or even the packet type (UDP, TCP, ICMP, - etc). + Маршрутизаторы с фильтрацией пакетов + + Маршрутизатор это машина, пересылающая пакеты между двумя или + несколькими сетями. Маршрутизатор с фильтрацией пакетов + запрограммирован на сравнение каждого пакета со списком правил + перед тем как решить, пересылать его или нет. Большинство + современного программного обеспечения маршрутизации имеет + возможности фильтрации, и по умолчанию пересылаются все пакеты. + Для включения фильтров, вам потребуется определить набор + правил. + + Для определения того, должен ли быть пропущен пакет, межсетевой + экран ищет в наборе правило, совпадающее с содержимым заголовков + пакета. Как только совпадение найдено, выполняется действие, + присвоенное данному правилу. Действие может заключаться в + отбрасывании пакета, пересылке пакета, или даже в отправлении + ICMP сообщения в адрес источника. Учитывается только первое + совпадение, поскольку правила просматриваются в определенном + порядке. Следовательно, список правил можно назвать + цепочкой правил. + + Критерий отбора пакетов зависит от используемого программного + обеспечения, но обычно вы можете определять правила, зависящие от + IP адреса источника пакета, IP адреса назначения, номера порта + источника пакета, номера порта назначения (для протоколов, + поддерживающих порты), или даже от типа пакета (UDP, TCP, ICMP, + и т.д.). - + - Proxy servers - - Proxy servers are machines which have had the normal system - daemons (telnetd, ftpd, etc) replaced with special servers. These - servers are called proxy servers as they - normally only allow onward connections to be made. This enables you - to run (for example) a proxy telnet server on your firewall host, - and people can telnet in to your firewall from the outside, go - through some authentication mechanism, and then gain access to the - internal network (alternatively, proxy servers can be used for - signals coming from the internal network and heading out). - - Proxy servers are normally more secure than normal servers, and - often have a wider variety of authentication mechanisms available, - including one-shot password systems so that even if - someone manages to discover what password you used, they will not be - able to use it to gain access to your systems as the password - instantly expires. As they do not actually give users access to the - host machine, it becomes a lot more difficult for someone to install - backdoors around your security system. - - Proxy servers often have ways of restricting access further, so - that only certain hosts can gain access to the servers, and often - they can be set up so that you can limit which users can talk to - which destination machine. Again, what facilities are available - depends largely on what proxy software you choose. + Прокси серверы + + Прокси серверы это компьютеры, где обычные системные даемоны + (telnetd, + ftpd, и т.д.) заменены специальными + серверами. Эти серверы называются прокси + серверами, поскольку они обычно работают только с + входящими соединениями. Это позволяет запускать (например) + telnet прокси сервер на межсетевом + экране, и делать возможным вход по telnet + на межсетевой экран, прохождение механизма аутентификации, + и получение доступа к внутренней сети (аналогично, прокси серверы + могут быть использованы для выхода во внешнюю сеть). + + Прокси серверы обычно лучше защищены, чем другие серверы, + и зачастую имеют более широкий набор механизмов аутентификации, + включая системы одноразовых паролей, так что + даже если кто-то узнает, какой пароль вы использовали, он не + сможет использовать его для получения доступа к системе, + поскольку срок действия пароля истекает немедленно после его + первого использования. Поскольку пароль не дает доступа + непосредственно к компьютеру, на котором находится прокси-сервер, + становится гораздо сложнее установить в систему + backdoor. + + Прокси серверы обычно имеют способ дополнительного ограничения + доступа, так что только определенные хосты могут получить доступ + к серверам. Большинство также позволяют администратору указывать, + пользователей и компьютеры, к которым они могут обращаться. + Опять же доступные возможности в основном зависят от используемого + программного обеспечения. - What does IPFW allow me to do? - - IPFW, the software supplied with - FreeBSD, is a packet filtering and accounting system which resides in - the kernel, and has a user-land control utility, - &man.ipfw.8;. Together, they allow you to define and query the - rules currently used by the kernel in its routing decisions. - - There are two related parts to IPFW. - The firewall section allows you to perform packet filtering. There is - also an IP accounting section which allows you to track usage of your - router, based on similar rules to the firewall section. This allows - you to see (for example) how much traffic your router is getting from - a certain machine, or how much WWW (World Wide Web) traffic it is - forwarding. - - As a result of the way that IPFW is - designed, you can use IPFW on non-router - machines to perform packet filtering on incoming and outgoing - connections. This is a special case of the more general use of - IPFW, and the same commands and techniques - should be used in this situation. + Что позволяет делать IPFW? + ipfw + + Программное обеспечение IPFW, поставляемое с + FreeBSD, это система фильтрации и учета пакетов, находящаяся в ядре + и снабженная пользовательской утилитой настройки, &man.ipfw.8;. + Вместе они позволяют определять и просматривать правила, используемые + ядром при маршрутизации. + + IPFW состоит из двух связанных частей. Межсетевой экран + осуществляет фильтрацию пакетов. Часть, занимающаяся учетом + IP пакетов, отслеживает использование маршрутизатора на основе + правил подобных тем, что используются в части межсетевого экрана. + Это позволяет администратору определять, например, объем трафика, + полученного маршрутизатором от определенного компьютера, или объем + пересылаемого WWW трафика. + + Благодаря тому, как реализован IPFW, вы можете использовать + его и на компьютерах, не являющихся маршрутизаторами для фильтрации + входящих и исходящих соединений. Это особый случай более общего + использования IPFW, и в этой ситуации используются те же команды + и техника. - Enabling IPFW on FreeBSD - - As the main part of the IPFW system - lives in the kernel, you will need to add one or more options to your - kernel configuration file, depending on what facilities you want, and - recompile your kernel. See reconfiguring - the kernel for more details on how to recompile your - kernel. - - There are currently three kernel configuration options relevant to + Включение IPFW в FreeBSD + + ipfw + включение + + + Поскольку основная часть системы IPFW находится в ядре, + вам потребуется добавить один или несколько параметров в файл + настройки ядра, в зависимости от требуемых возможностей, и пересобрать + ядро. Обратитесь к главе о пересборке ядра () за подробным описанием этой процедуры. + + + Правилом IPFW по умолчанию является deny ip from any to + any. Если вы не добавите других правил во время загрузки + для разрешения доступа, то заблокируете доступ + к серверу с включенным в ядро межсетевым экраном после перезагрузки. + Мы предлагаем указать firewall_type=open в + файле /etc/rc.conf при первоначальном + добавлении межсетевого экрана, а затем, после тестирования + его работоспособности, отредактировать правила в файле + /etc/rc.firewall. Дополнительной + предосторожностью может быть первоначальная настройка межсетевого + экрана с локальной консоли, вместо входа через + ssh. Кроме того, возможна сборка + ядра с параметрами IPFIREWALL и + IPFIREWALL_DEFAULT_TO_ACCEPT. В этом случае + правило IPFW по умолчанию будет изменено на allow ip from + any to any, что предотвратит возможную блокировку. + + + Существует четыре параметра настройки ядра, относящихся к IPFW: - + options IPFIREWALL - Compiles into the kernel the code for packet - filtering. + Включает в ядро код для фильтрации пакетов. - + options IPFIREWALL_VERBOSE - + - Enables code to allow logging of packets through - &man.syslogd.8;. Without this option, even if you specify - that packets should be logged in the filter rules, nothing will - happen. + Включает протоколирование пакетов через &man.syslogd.8;. + Без этого параметра, даже если вы укажете в правилах фильтрации + протоколировать пакеты, это не сработает. options IPFIREWALL_VERBOSE_LIMIT=10 - + - Limits the number of packets logged through - &man.syslogd.8; on a per entry basis. You may wish to use - this option in hostile environments in which you want to log - firewall activity, but do not want to be open to a denial of - service attack via syslog flooding. - - When a chain entry reaches the packet limit specified, - logging is turned off for that particular entry. To resume - logging, you will need to reset the associated counter using the - &man.ipfw.8; utility: - + Ограничивает число пакетов, протоколируемых каждым правилом + через &man.syslogd.8;. Вы можете использовать этот параметр + если хотите протоколировать работу межсетевого экрана, но не + хотите делать возможной DoS атаку путем переполнения + syslog. + + Когда для одного из правил в цепочке достигается + определенный параметром предел, протоколирование для этого + правила выключается. Для включения протоколирования, + вам потребуется сбросить соответствующий счетчик с помощью + утилиты &man.ipfw.8;: + &prompt.root; ipfw zero 4500 - Where 4500 is the chain entry you wish to continue - logging. + где 4500 это номер правила, для которого вы хотите + возобновить протоколирование. + + + + + options IPFIREWALL_DEFAULT_TO_ACCEPT + + + Изменяет правило по умолчанию с deny на + allow. Это предотвращает возможное блокирование, + если ядро загружено с поддержкой IPFIREWALL, + но межсетевой экран еще не настроен. Этот параметр также + полезен, если вы используете &man.ipfw.8; в качестве средства + от определенных проблем по мере их возникновения. Тем не менее, + используйте параметр с осторожностью, поскольку он открывает + межсетевой экран и изменяет его поведение. - - Previous versions of FreeBSD contained an - IPFIREWALL_ACCT option. This is now obsolete as - the firewall code automatically includes accounting - facilities. + + Предыдущие версии FreeBSD содержали параметр + IPFIREWALL_ACCT. Этот параметр устарел, поскольку + код автоматически включает возможность учета. + - Configuring IPFW - - The configuration of the IPFW software - is done through the &man.ipfw.8; utility. The syntax for this - command looks quite complicated, but it is relatively simple once you - understand its structure. - - There are currently four different command categories used by the - utility: addition/deletion, listing, flushing, and clearing. - Addition/deletion is used to build the rules that control how packets - are accepted, rejected, and logged. Listing is used to examine the - contents of your rule set (otherwise known as the chain) and packet - counters (accounting). Flushing is used to remove all entries from - the chain. Clearing is used to zero out one or more accounting - entries. - + Настройка IPFW + + ipfw + настройка + + + Настройка программного обеспечения IPFW выполняется с помощью + утилиты &man.ipfw.8;. Синтаксис этой команды выглядит очень сложным, + но он становится относительно прост как только вы поймете его + структуру. + + В настоящее время утилита использует четыре различных категории + команд: добавление/удаление (addition/deletion), просмотр (listing), + сброс (flushing) и очистка (clearing). Добавление/удаление + используется для создания правил, определяющих как пакеты принимаются, + отбрасываются и протоколируются. Просмотр используется для + определения содержимого набора правил (называемого еще цепочкой) и + счетчиков пакетов (учет). Сброс используется для удаления всех + правил цепочки. Очистка используется для обнуления одного или + нескольких счетчиков. + - Altering the IPFW rules + Изменение правил IPFW - The syntax for this form of the command is: + Синтаксис этой формы команды такой: ipfw -N - command - index - action + команда + номер + действие log - protocol - addresses - options + протокол + адреса + параметры - There is one valid flag when using this form of the - command: + При использовании этой формы команды доступен один + флаг: -N - Resolve addresses and service names in output. + Разрешение адресов и имен сервисов при отображении. - The command given can be shortened to the - shortest unique form. The valid commands - are: - + Задаваемая команда может быть сокращена + до более короткой уникальной формы. Существующие + команды: + add - Add an entry to the firewall/accounting rule list + Добавление правила к списку фильтрации/учета - + delete - + - Delete an entry from the firewall/accounting rule - list + Удаление правила из списка фильтрации/учета - Previous versions of IPFW used - separate firewall and accounting entries. The present version - provides packet accounting with each firewall entry. - - If an index value is supplied, it used to - place the entry at a specific point in the chain. Otherwise, the - entry is placed at the end of the chain at an index 100 greater than - the last chain entry (this does not include the default policy, rule - 65535, deny). - - The log option causes matching rules to be - output to the system console if the kernel was compiled with - IPFIREWALL_VERBOSE. - - Valid actions are: - + Предыдущие версии IPFW использовали отдельные записи для + фильтрации и учета пакетов. Современные версии учитывают + пакеты для каждого правила. + + Если указано значение номер, оно + используется для помещения правила на определенную позицию в + цепочке. Иначе правило помещается в конец цепочки с номером + на 100 больше, чем у предыдущего правила (сюда не включается + правило по умолчанию с номером 65535). + + С параметром log соответствующие правила + выводят информацию на системную консоль, если ядро собрано с + опцией IPFIREWALL_VERBOSE. + + Существующие действия: + reject - Drop the packet, and send an ICMP host or port unreachable - (as appropriate) packet to the source. + Отбросить пакет и отправить в адрес источникаICMP пакет, + сообщающий о недостижимости хоста или порта. - + allow - + - Pass the packet on as normal. (aliases: - pass and + Пропустить пакет как обычно. (синонимы: + pass, permit, и accept) - + deny - + - Drop the packet. The source is not notified via an - ICMP message (thus it appears that the packet never - arrived at the destination). + Отбросить пакет. Источнику не выдается ICMP сообщение + (как если бы пакет вообще не достиг цели). - + count - + - Update packet counters but do not allow/deny the packet - based on this rule. The search continues with the next chain - entry. + Обновить счетчик пакета, но не применять по отношению к + нему правила allow/deny. Поиск продолжится со следующего + правила в цепочке. - Each action will be recognized by the - shortest unambiguous prefix. - - The protocols which can be specified - are: - + Каждое действие может быть записано в + виде более короткого уникального префикса. + + Могут быть определены следующие + протоколы: + all - Matches any IP packet + Соответствует всем IP пакетам - + icmp - + - Matches ICMP packets + Соответствует ICMP пакетам - + tcp - + - Matches TCP packets + Соответствует TCP пакетам - + udp - + - Matches UDP packets + Соответствует UDP пакетам - The address specification is: + Поле адреса формируется так: - from - address/maskport - to - address/maskport - via interface + источник + адрес/маскапорт + цель + адрес/маскапорт + via интерфейс - - You can only specify port in - conjunction with protocols which support ports - (UDP and TCP). - - The is optional and may specify the IP - address or domain name of a local IP interface, or an interface name - (e.g. ed0) to match only packets coming - through this interface. Interface unit numbers can be specified - with an optional wildcard. For example, ppp* - would match all kernel PPP interfaces. - - The syntax used to specify an - address/mask is: - - address - - or - - address/mask-bits - - or - - address:mask-pattern - - A valid hostname may be specified in place of the IP address. - is a decimal - number representing how many bits in the address mask should be set. - e.g. specifying 192.216.222.1/24 will create a - mask which will allow any address in a class C subnet (in this case, - 192.216.222) to be matched. - is an IP - address which will be logically AND'ed with the address given. The - keyword any may be used to specify any IP - address. - - The port numbers to be blocked are specified as: - + Вы можете указать port только + вместе с протоколами, поддерживающими + порты (UDP и TCP). + + Параметр опционален и может содержать IP + адрес или имя домена локального IP интерфейса, или имя интерфейса + (например ed0), он настраивает правило + на соответствие только тем пакетам, которые проходят через этот + интерфейс. Номера интерфейсов могут быть заменены на опциональную + маску. Например, ppp* будет соответствовать + PPP интерфейсам ядра. + + Синтаксис, используемый для указания + адреса/маски: + + адрес + + или + + адрес/маска-биты + + или + + адрес:маска-шаблон + + + Вместо IP адреса возможно указание существующего имени хоста. + это + десятичный номер, указывающий количество бит, которые должны быть + установлены в маске адреса. Например, + 192.216.222.1/24 создаст маску, + соответствующую всем адресам подсети класса C (в + данном случае, 192.216.222). +A valid hostname may be specified in place of the IP address. + это + IP, который будет логически перемножен с заданным адресом. + Ключевое слово any может использоваться для + обозначения любого IP адреса. + + Номера портов указываются в следующем формате: + - port,port,port… + порт,порт,порт… - to specify either a single port or a list of ports, or - + для указания одного порта или списка портов, или + - port-port + порт-порт - to specify a range of ports. You may also combine a single range - with a list, but the range must always be specified first. - - The options available are: + для указания диапазона портов. Вы можете также комбинировать + указание одного диапазона со списком портов, но диапазон всегда + должен указываться первым. + + Доступные параметры: frag - Matches if the packet is not the first fragment of the - datagram. + Срабатывает, если пакет не является первым пакетом + дейтаграммы. - + in - + - Matches if the packet is on the way in. + Соответствует входящим пакетам. - + out - + - Matches if the packet is on the way out. + Соответствует исходящим пакетам. - + ipoptions spec - + - Matches if the IP header contains the comma separated list - of options specified in spec. The - supported list of IP options are: ssrr - (strict source route), lsrr (loose source - route), rr (record packet route), and - ts (timestamp). The absence of a - particular option may be denoted with a leading + Срабатывает, если заголовок IP содержит перечисленный + через запятую список параметров, указанных в + spec. Поддерживаемые параметры IP: + ssrr (strict source route), + lsrr (loose source route), + rr (record packet route), и + ts (time stamp). Действие отдельных + параметров может быть изменено путем указания префикса !. - + established - + - Matches if the packet is part of an already established - TCP connection (i.e. it has the RST or ACK bits set). You can - optimize the performance of the firewall by placing - established rules early in the - chain. + Срабатывает, если пакет является частью уже установленного + TCP соединения (т.е. если установлены биты RST или ACK). + Вы можете поднять производительность межсетевого экрана, + поместив правило с established близко + к началу цепочки. - + setup - + - Matches if the packet is an attempt to establish a TCP - connection (the SYN bit set is set but the ACK bit is - not). + Соответствует, если пакет является попыткой установки + TCP соединения (установлен бит SYN, а бит ACK не + установлен). - + - tcpflags flags - + tcpflags флаги + - Matches if the TCP header contains the comma separated - list of flags. The supported flags - are fin, syn, + Срабатывает, если заголовок TCP содержит список + перечисленных через запятую флагов. + Поддерживаемые флаги: + fin, syn, rst, psh, - ack, and urg. The - absence of a particular flag may be indicated by a leading - !. + ack, и urg. Действие + правил по отдельным флагам может быть изменено указанием + префикса !. - + - icmptypes types - + icmptypes типы + - Matches if the ICMP type is present in the list - types. The list may be specified - as any combination of ranges and/or individual types separated - by commas. Commonly used ICMP types are: 0 + Срабатывает, если тип пакета ICMP находится в списке + типы. Список может быть указан + в виде любой комбинации диапазонов и/или отдельных типов, + разделенных запятыми. Обычно используемые типы ICMP: + 0 echo reply (ping reply), 3 destination unreachable, 5 redirect, - 8 echo request (ping request), and - 11 time exceeded (used to indicate TTL - expiration as with &man.traceroute.8;). + 8 echo request (ping request), и + 11 time exceeded (используется для + обозначения истечения TTL, как с &man.traceroute.8;). - + - Listing the IPFW rules + Просмотр правил IPFW - The syntax for this form of the command is: + Синтаксис этой формы команды такой: ipfw -a + -c + -d + -e -t -N - l + -S + list - There are three valid flags when using this form of the - command: - + Для этой формы команды существует семь флагов: + -a - While listing, show counter values. This option is the - only way to see accounting counters. + Показывать значения счетчиков. Этот параметр – + единственный путь для просмотра значений счетчиков. + + + + + -c + + + Просмотр правил в компактной форме. + + + + + -d + + + Показывать динамические правила в дополнение к + статическим. - + + + -e + + + Если определен параметр , показывать + также динамические правила с истекшим сроком действия. + + + -t - + - Display the last match times for each chain entry. The - time listing is incompatible with the input syntax used by the - &man.ipfw.8; utility. + Отображать последнее время срабатывание для каждого + правила в цепочке. Этот список несовместим с синтаксисом, + принимаемым &man.ipfw.8;. - + -N - + - Attempt to resolve given addresses and service - names. + Попытаться разрешить заданные адреса и имена + сервисов. + + + + + -S + + + Отображать набор, к которому принадлежит каждое правило. + Если этот флаг не указан, заблокированные правила не будут + отображены. - + - Flushing the IPFW rules + Сброс правил IPFW - The syntax for flushing the chain is: + Синтаксис для сброса правил: ipfw flush - This causes all entries in the firewall chain to be removed - except the fixed default policy enforced by the kernel (index - 65535). Use caution when flushing rules, the default deny policy - will leave your system cut off from the network until allow entries - are added to the chain. + Все правила в цепочке будут удалены, за исключением правила + по умолчанию, устанавливаемого ядром (номер 65535). Будьте + осторожны при сбросе правил; правило, отбрасывающее пакеты по + по умолчанию отключит систему от сети, пока разрешающие правила + не будут добавлены в цепочку. - + - Clearing the IPFW packet counters + Очистка счетчиков пакетов IPFW - The syntax for clearing one or more packet counters is: + Синтаксис для очистки одного или нескольких счетчиков + пакетов: ipfw zero index - When used without an index argument, - all packet counters are cleared. If an - index is supplied, the clearing operation - only affects a specific chain entry. + При использовании без аргумента номер + будут очищены все счетчики пакетов. Если + index указан, операция очистки + применяется только к указанному правилу цепочки. - Example commands for ipfw - - This command will deny all packets from the host evil.crackers.org to the telnet port of the - host nice.people.org by being forwarded - by the router: - - &prompt.root ipfw add deny tcp from evil.crackers.org to nice.people.org 23 - - The next example denies and logs any TCP traffic from the entire - crackers.org network (a class C) to - the nice.people.org machine (any - port). - + Примеры команд для <application>ipfw</application> + + Следующая команда запретит все пакеты с хоста evil.crackers.org на telnet порт хоста + nice.people.org: + + &prompt.root; ipfw add deny tcp from evil.crackers.org to nice.people.org 23 + + Следующий пример запрещает и протоколирует весь TCP трафик из + сети crackers.org (класса C) + к компьютеру nice.people.org + (на любой порт). + &prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org - - If you do not want people sending X sessions to your internal - network (a subnet of a class C), the following command will do the - necessary filtering: - + + Если вы хотите запретить организацию X сессий в вашу сеть + (часть сети класса C), следующая команда осуществит необходимую + фильтрацию: + &prompt.root; ipfw add deny tcp from any to my.org/28 6000 setup - - To see the accounting records: - + + Для просмотра записей учета: + &prompt.root; ipfw -a list - or in the short form - + или в краткой форме + &prompt.root; ipfw -a l - You can also see the last time a chain entry was matched - with: - + Вы можете также просмотреть время последнего срабатывания правил + с помощью команды: + &prompt.root; ipfw -at l - + - Building a packet filtering firewall - + Создание межсетевого экрана с фильтрацией пакетов + - The following suggestions are just that: suggestions. The - requirements of each firewall are different and I cannot tell you - how to build a firewall to meet your particular requirements. + Следующие рекомендации означают только одно: рекомендации. + Требования к каждому межсетевому экрану различаются, и мы не + можем рассказать вам, как создать межсетевой экран, отвечающий + вашим потребностям. - - When initially setting up your firewall, unless you have a test - bench setup where you can configure your firewall host in a controlled - environment, I strongly recommend you use the logging version of the - commands and enable logging in the kernel. This will allow you to - quickly identify problem areas and cure them without too much - disruption. Even after the initial setup phase is complete, I - recommend using the logging for of `deny' as it allows tracing of - possible attacks and also modification of the firewall rules if your - requirements alter. - + + При первоначальной настройке межсетевого экрана, до тестирования + производительности и введения сервера в строй, настоятельно + рекомендуется использовать версии команд с протоколированием и + включить протоколирование в ядре. Это позволит вам быстро выявить + проблемные области и исправить настройку без больших усилий. + Даже после завершения первоначальной настройки рекомендуется + использовать протоколирование для `deny', поскольку это позволяет + отслеживать возможные атаки и изменять правила межсетевого экрана, + если требования к нему изменятся. + - If you use the logging versions of the accept - command, it can generate large amounts of log - data as one log line will be generated for every packet that passes - through the firewall, so large ftp/http transfers, etc, will really - slow the system down. It also increases the latencies on those - packets as it requires more work to be done by the kernel before the - packet can be passed on. syslogd with also start using up a lot - more processor time as it logs all the extra data to disk, and it - could quite easily fill the partition /var/log - is located on. + Если вы используете версию команды accept + с протоколированием, будьте осторожны, поскольку она может + создать большой объем протокольных данных. + Будет произведено протоколирование каждого пакета, проходящего + через межсетевой экран, поэтому большие объемы FTP/http и другого + трафика существенно замедлят систему. Это также увеличит задержку + таких пакетов, поскольку ядру требуется выполнить дополнительную + работу перед тем, как пропустить пакет. + syslogd также будет использовать гораздо + больше времени процессора, поскольку он отправит все дополнительные + данные на диск, и раздел /var/log может быть + быстро заполнен. - - You should enable your firewall from - /etc/rc.conf.local or - /etc/rc.conf. The associated manpage explains - which knobs to fiddle and lists some preset firewall configurations. - If you do not use a preset configuration, ipfw list - will output the current ruleset into a file that you can - pass to rc.conf. If you do not use - /etc/rc.conf.local or - /etc/rc.conf to enable your firewall, - it is important to make sure your firewall is enabled before - any IP interfaces are configured. - - - The next problem is what your firewall should actually - do! This is largely dependent on what access to - your network you want to allow from the outside, and how much access - to the outside world you want to allow from the inside. Some general - rules are: - + + Вам потребуется включить межсетевой экран в + /etc/rc.conf.local или + /etc/rc.conf. Соответствующая страница + справочника разъясняет что именно необходимо сделать и содержит + примеры готовых настроек. Если вы не используете предустановленную + настройку, команда ipfw list может поместить + текущий набор правил в файл, откуда он может быть помещен в + стартовые файлы системы. Если вы не используете + /etc/rc.conf.local или + /etc/rc.conf для включения межсетевого экрана, + важно убедиться в том, что он включается после настройки + интерфейсов. + + Далее необходимо определить, что именно + делает ваш межсетевой экран! Это в основном зависит от того, + насколько широкий доступ вы хотите открыть снаружи к вашей сети. + Вот несколько общих правил: + - Block all incoming access to ports below 1024 for TCP. This is - where most of the security sensitive services are, like finger, - SMTP (mail) and telnet. + Заблокируйте доступ снаружи к портам TCP с номерами ниже 1024. + Здесь расположена большая часть критичных для безопасности + сервисов, таких как finger, SMTP (почта) и telnet. - Block all incoming UDP traffic. There - are very few useful services that travel over UDP, and what useful - traffic there is is normally a security threat (e.g. Suns RPC and - NFS protocols). This has its disadvantages also, since UDP is a - connectionless protocol, denying incoming UDP traffic also blocks - the replies to outgoing UDP traffic. This can cause a problem for - people (on the inside) using external archie (prospero) servers. - If you want to allow access to archie, you'll have to allow - packets coming from ports 191 and 1525 to any internal UDP port - through the firewall. ntp is another service you may consider - allowing through, which comes from port 123. + Заблокируйте весь входящий трафик UDP. + Есть очень немного полезных сервисов, работающих через UDP, + но они обычно представляют угрозу безопасности (например, + Sun RPC и NFS протоколы). У этого способа есть и недостатки, + поскольку протокол UDP не поддерживает соединения, и запрещение + входящих пактов заблокирует также ответы на исходящий UDP трафик. + + Это может стать проблемой для тех, кто использует внешние серверы, + работающие с UDP. Если вы хотите открыть доступ к этим сервисам, + потребуется разрешить входящие пакеты с соответствующих портов. + К примеру, для ntp вам может + потребоваться разрешить пакеты, приходящие с порта 123. - + - Block traffic to port 6000 from the outside. Port 6000 is the - port used for access to X11 servers, and can be a security threat - (especially if people are in the habit of doing xhost - + on their workstations). X11 can actually use a - range of ports starting at 6000, the upper limit being how many X - displays you can run on the machine. The upper limit as defined - by RFC 1700 (Assigned Numbers) is 6063. + Заблокировать весь трафик снаружи к порту 6000. Порт 6000 + используется для доступа к серверам X11, и может быть угрозой + безопасности (особенно если у пользователей есть привычка + выполнять на своих рабочих станциях команду xhost + +). X11 может использовать диапазон портов, + начинающийся с 6000, верхний предел определяется количеством + X дисплеев, которые могут быть запущены на машине. Верхний + предел, определенный RFC 1700 (Assigned Numbers), равен + 6063. - + - Check what ports any internal servers use (e.g. SQL servers, - etc). It is probably a good idea to block those as well, as they - normally fall outside the 1-1024 range specified above. + Проверьте порты, используемые внутренними сервисами + (например, SQL серверами и т.п.). Возможно хорошей идеей является + блокирование и этих портов, поскольку они обычно не попадают в + диапазон 1-1024, указанный выше. + + + + Еще один список для проверки настроек межсетевого экрана доступен + на CERT по адресу + + Как сказано выше, все эти правила всего лишь + руководство. Вы сами сможете решить, какие + правила фильтрации будут использованы в межсетевом экране. Мы не + можем нести НИКАКОЙ ответственности в случае взлома вашей сети, + даже если вы следовали советам, представленным выше. + + + + Накладные расходы и оптимизация IPFW + + Многие пользователи хотят знать, как сильно IPFW нагружает + систему. Ответ в основном зависит от набора правил и скорости + процессора. При небольшом наборе правил для большинства приложений, + работающих в Ethernet ответ незначительно. + Для тех, кому нужен более точный ответ, и предназначен этот + раздел. + + Последующие измерения были выполнены с 2.2.5-STABLE на + 486-66. (Хотя IPFW немного изменился в последующих релизах + FreeBSD, скорость осталась приблизительно той же.) IPFW был + модифицирован для измерения времени, затраченного + ip_fw_chk, с выводом на консоль результата + после каждого 1000–го пакета. + + Были протестированы два набора из 1000 правил. Первый + был составлен для демонстрации плохого набора правил путем повторения + правила: + + &prompt.root; ipfw add deny tcp from any to any 55555 + + Этот набор правил плох, поскольку большая часть правил IPFW + не соответствует проверяемым пакетам (из-за номера порта). + После 999–й итерации этого правила следует + правило allow ip from any to any. + + Второй набор правил был разработан для быстрейшей проверки + каждого правила: + + &prompt.root; ipfw add deny ip from 1.2.3.4 to 1.2.3.4 + + Не совпадающий IP адрес источника в правиле выше приведет к + очень быстрой проверке этих правил. Как и прежде, 1000–е + правило allow ip from any to any. + + Затраты на проверку пакета в первом случае приблизительно + 2.703 мс/пакет, или приблизительно 2.7 микросекунд на + правило. Теоретический предел скорости проверки около + 370 пакетов в секунду. Предполагая подключение через + 10 Mbps Ethernet и размер пакета приблизительно 1500 байт, + получаем только 55.5% использования пропускной способности. + + Во втором случае каждый пакет был проверен приблизительно за + 1.172 мс, или приблизительно 1.2 микросекунд на правило. + Теоретический предел скорости проверки около 853 пакетов в + секунду, что делает возможным полное использование пропускной + способности 10 Mbps Ethernet. + + Чрезмерное количество проверяемых правил и их вид не позволяет + составить картину близкую к обычным условиям — эти правила + были использованы только для получения информации о времени проверки. + Вот несколько рекомендаций, которые необходимо учесть для создания + эффективного набора правил: + + + + Поместите правило established как можно + раньше для обработки большей части TCP трафика. Не помещайте + перед ним правила allow tcp. + + + + Помещайте часто используемые правила ближе к началу набора + чем редко используемые (конечно же, без изменения + действия всего набора). Вы можете определить + наиболее часто используемые правила путем проверки счетчиков + пакетов командой ipfw -a l. - - Another checklist for firewall configuration is available from - CERT at ftp://ftp.cert.org/pub/tech_tips/packet_filtering - - As I said above, these are only guidelines. - You will have to decide what filter rules you want to use on your - firewall yourself. I cannot accept ANY responsibility if someone - breaks into your network, even if you follow the advice given - above. OpenSSL - - As of FreeBSD 4.0, the OpenSSL toolkit is a part of the base - system. OpenSSL - provides a general-purpose cryptography library, as well as the - Secure Sockets Layer v2/v3 (SSLv2/SSLv3) and Transport Layer - Security v1 (TLSv1) network security protocols. - - However, some of the algorithms (specifically, RSA and IDEA) - included in OpenSSL are protected by patents in the USA and - elsewhere, and are not available for unrestricted use (in - particular, IDEA is not available at all in FreeBSD's version of - OpenSSL). As a result, FreeBSD has available two different - versions of the OpenSSL RSA libraries depending on geographical - location (USA/non-USA). + + безопасность + OpenSSL + + OpenSSL + + Начиная с FreeBSD 4.0, OpenSSL является частью базовой системы. + OpenSSL предоставляет + как криптографическую библиотеку общего назначения, так и сетевые + протоколы безопасности Secure Sockets Layer v2/v3 (SSLv2/SSLv3) и + Transport Layer Security v1 (TLSv1). + + Однако, один из алгоритмов (а именно IDEA), включенный в OpenSSL, + защищен патентом в USA и повсеместно, и не доступен для + неограниченного использования. IDEA включен в исходные тексты + FreeBSD, но не собирается по умолчанию. Если вы собираетесь + использовать его, и согласны с положениями лицензии, включите + переменную MAKE_IDEA в + /etc/make.conf и пересоберите исходные тексты + с помощью команды make world. + + На данный момент алгоритм RSA свободно доступен к использованию + в USA и других странах. В прошлом он был защищен патентом. + + + OpenSSL + установка + - Source Code Installations - - OpenSSL is part of the src-crypto and - src-securecvsup collections. See the Obtaining FreeBSD section for more - information about obtaining and updating FreeBSD source - code. + Установка из исходных текстов + + OpenSSL является частью CVSup коллекций + src-crypto и src-secure. + Обратитесь к разделу Получение FreeBSD за дополнительной + информацией о получении и обновлении исходных текстов FreeBSD. + + + + + + + Nik + Clayton + +
nik@FreeBSD.org
+ + Написал + + + + + VPN через IPsec + Создание VPN между двумя сетями, соединенными через интернет, + с использованием шлюзов FreeBSD. - International (Non-USA) Users - - People who are located outside the USA, and who obtain their - crypto sources from internat.FreeBSD.org (the International - Crypto Repository) or an international mirror site, will build a - version of OpenSSL which includes the native OpenSSL - implementation of - RSA, but does not include IDEA, because the latter is restricted - in certain locations elsewhere in the world. In the future a more - flexible geographical identification system may allow building of - IDEA in countries for which it is not restricted. - - Please be aware of any local restrictions on the import, use - and redistribution of cryptography which may exist in your - country. + + + + Hiten M. + Pandya + +
hmp@FreeBSD.org
+ + Написал + + + + + Принципы работы IPsec + + Этот раздел послужит вам руководством по настройке IPsec и его + использованию в среде FreeBSD и µsoft.windows; + 2000/XP, соединяемых безопасным способом. + Для настройки IPsec необходимо ознакомиться с процессом + сборки ядра (). + + IPsec это протокол, расположенный поверх + слоя Internet Protocol (IP). Он позволяет двум или более хостам + связываться защищенным способом (отсюда и название протокола). + Сетевой стек FreeBSD IPsec основан на + реализации KAME, + поддерживающей оба семейства протоколов, IPv4 и IPv6. + + + FreeBSD 5.X содержит аппаратно + поддерживаемый стек IPsec, известный как Fast + IPsec, заимствованный из OpenBSD. Для оптимизации + производительности IPsec он задействует криптографическое + оборудование (когда оно доступно) через подсистему &man.crypto.4;. + Это новая подсистема и она не поддерживает всех возможностей, + доступных в KAME версии IPsec. Для включения IPsec с аппаратной + поддержкой необходимо добавить в файл настройки ядра следующий + параметр: + + +options FAST_IPSEC # new IPsec (cannot define w/ IPSEC) + + + Обратите внимание, что на данный момент невозможно + использовать подсистему Fast IPsec вместе + с KAME реализацией IPsec. Обратитесь к странице справочника + &man.fast.ipsec.4; за дальнейшей информацией. + + + + IPsec состоит из двух субпротоколов: + + + + Encapsulated Security Payload + (ESP), защищающей данные IP пакета от вмешательства + третьей стороны путем шифрования содержимого с помощью + симметричных криптографических алгоритмов (таких как + Blowfish,3DES). + + + Authentication Header (AH), + защищающий заголовок IP пакета от вмешательства третьей стороны + и подделки путем вычисления криптографической контрольной суммы + и хеширования полей заголовка IP пакета защищенной функцией + хеширования. К пакету добавляется дополнительный заголовок + с хешем, позволяющий аутентификацию информации пакета. + + + + ESP и AH могут быть + использованы вместе или по отдельности, в зависимости от + обстоятельств. + + IPsec может быть использован или для непосредственного шифрования + трафика между двумя хостами (транспортный + режим); или для построения виртуальных + туннелей между двумя подсетями, которые могут быть + использованы для защиты соединений между двумя корпоративными + сетями (туннельный режим). Последний обычно + называют виртуальной частной сетью + (Virtual Private Network, VPN). За детальной информацией о + подсистеме IPsec в FreeBSD обратитесь к странице справочника + &man.ipsec.4;. + + Для включения поддержки IPsec в ядре, добавьте следующие + параметры к файлу настройки ядра: + + +options IPSEC #IP security +options IPSEC_ESP #IP security (crypto; define w/ IPSEC) + + + Если желательна поддержка отладки IPsec, должна быть также + добавлена следующая строка: + + +options IPSEC_DEBUG #debug for IP security + - USA Users - - As noted above, RSA is patented in the USA, with terms - preventing general use without an appropriate license. Therefore - the standard OpenSSL RSA code may not be used in the USA, and has been - removed from the version of OpenSSL carried on USA mirror sites. - The RSA patent is due to expire on September 20, 2000, at which - time it is intended to add the full RSA code back to - the USA version of OpenSSL. - - However (and fortunately), the RSA patent holder (RSA Security, has - provided a RSA reference implementation toolkit - (RSAREF) which is available for certain classes of - use, including non-commercial use - (see the RSAREF license for their definition of - non-commercial). - - If you meet the conditions of the RSAREF license and wish to - use it in conjunction with OpenSSL to provide RSA support, you can - install the rsaref port, which is located in - /usr/ports/security/rsaref, or the - rsaref-2.0 package. The OpenSSL library will - then automatically detect and use the RSAREF libraries. Please obtain - legal advice if you are unsure of your compliance with the license - terms. - - The RSAREF implementation is inferior to the - native OpenSSL implementation (it is much slower, - and cannot be used with keys larger than 1024 bits). If you are not - located in the USA then you are doing yourself a disadvantage by - using RSAREF. - - Users who have purchased an appropriate RSA source code - license from RSA Security may use the International version of - OpenSSL described above to obtain native RSA support. - - IDEA code is also removed from the USA version of OpenSSL for - patent reasons. + Проблема + + Не существует стандарта VPN. Они могут быть реализованы + множеством различных технологий, каждая из которых имеет свои + сильные и слабые стороны. Этот материал представляет несколько + сценариев и стратегию реализации VPN для каждого сценария. - Binary Installations - - If your FreeBSD installation was a binary installation (e.g., - installed from the Walnut Creek CDROM, or from a snapshot - downloaded from - ftp.FreeBSD.org) and you selected to - install the crypto collection, then the - sysinstall utility will automatically select - the correct version to install during the installation - process. If the international version was selected but could - not be installed during sysinstall (e.g. you have not - configured network access, and the version must be downloaded - from a FTP site) then you can add the international RSA library - after installation as a package. - - The librsaintl package contains the RSA - code for International (non-USA) users. This is not legal for - use in the USA, but international users should use this version - because the RSA implementation is faster and more flexible. It - is available from ftp.internat.FreeBSD.org and does not - require RSAREF. - - + Сценарий #1: Две сети, подключенных к интернет, работающие как + одна - - IPsec - Contributed by &a.shin;, 5 March - 2000. + С этого сценария начато изучение VPN. Исходные условия + таковы: - IPsec mechanism provides secure communication either for IP - layer and socket layer communication. This section should - explain how to use them. About IPsec implementation, please - refer section 23.5.4. + + + Существует как минимум две сети + + + Внутри обеих сетей используется IP + + + Обе сети соединены через интернет через шлюз, + работающий на FreeBSD. + + + У шлюза каждой из сетей есть как минимум один публичный + IP адрес. + + + Внутренние IP адреса двух сетей могут быть публичными или + приватными, не имеет значения. На шлюзе может работать + NAT, если это необходимо. + + + Внутренние IP адреса двух сетей не должны + пересекаться. Хотя вероятно теоретически возможно + использование комбинации VPN технологии и NAT для настройки + такой конфигурации, эта конфигурация будет кошмарна. + + - The current IPsec implementation supports both transport mode - and tunnel mode. However, tunnel mode comes with some restrictions. - http://www.kame.net/newsletter/ - has more comprehensive examples. + Если две сети, которые вы пытаетесь соединить, используют один + и тот же диапазон приватных адресов (например, обе используют + 192.168.1.x), номера в одной из + сетей необходимо изменить. + + Топология сети может выглядеть примерно так: + + + + + + + +Сеть #1 [ Внутренние хосты ] Приватная сеть, 192.168.1.2-254 + [ Win9x/NT/2K ] + [ UNIX ] + | + | + .---[fxp1]---. Приватный IP, 192.168.1.1 + | FreeBSD | + `---[fxp0]---' Публичный IP, A.B.C.D + | + | + -=-=- Интернет -=-=- + | + | + .---[fxp0]---. Публичный IP, W.X.Y.Z + | FreeBSD | + `---[fxp1]---' Приватный IP, 192.168.2.1 + | + | +Сеть #2 [ Внутренние хосты ] + [ Win9x/NT/2K ] Приватная сеть, 192.168.2.2-254 + [ UNIX ] + + + + Здесь два публичных IP адреса. Для упоминания их в дальнейшем + будут использоваться буквы. Если вы увидите эти буквы, замените + их на свои публичные IP адреса. Также обратите внимание, что + у обеих шлюзов внутренний адрес заканчивается на .1 и диапазоны + приватных адресов двух сетей различны (192.168.1.x и 192.168.2.x соответственно). Все компьютеры + локальных сетей настроены на использование в качестве шлюза по + умолчанию компьютера с адресом, оканчивающимся на + .1. + + С сетевой точки зрения замысел в том, чтобы каждая сеть + видела компьютеры из другой сети так, как если бы они были + непосредственно подключены к тому же самому маршрутизатору — + хотя и немного медленному маршрутизатору, иногда теряющему + пакеты. + + Это означает, что (например) компьютер 192.168.1.20 может запустить + + ping 192.168.2.34 + + и это будет прозрачно работать. Компьютеры с &windows; + должны видеть компьютеры в другой сети, просматривать сетевые + ресурсы, и так далее, точно так же, как и для компьютеров в + локальной сети. + + И все это безопасным способом. Это означает, что трафик + между сетями зашифрован. + + Создание VPN между этими двумя сетями это многошаговый + процесс. Этапы создания VPN таковы: - - Transport mode example with IPv4 - - Let's setup security association to deploy a secure channel - between HOST A (10.2.3.4) and HOST B (10.6.7.8). Here we show a little - complicated example. From HOST A to HOST B, only old AH is used. - From HOST B to HOST A, new AH and new ESP are combined. - - Now we should choose algorithm to be used corresponding to - "AH"/"new AH"/"ESP"/"new ESP". Please refer to the &man.setkey.8; man - page to know algorithm names. Our choice is MD5 for AH, new-HMAC-SHA1 - for new AH, and new-DES-expIV with 8 byte IV for new ESP. - - Key length highly depends on each algorithm. For example, key - length must be equal to 16 bytes for MD5, 20 for new-HMAC-SHA1, - and 8 for new-DES-expIV. Now we choose "MYSECRETMYSECRET", - "KAMEKAMEKAMEKAMEKAME", "PASSWORD", respectively. - - OK, let's assign SPI (Security Parameter Index) for each protocol. - Please note that we need 3 SPIs for this secure channel since three - security headers are produced (one for from HOST A to HOST B, two for - from HOST B to HOST A). Please also note that SPI MUST be greater - than or equal to 256. We choose, 1000, 2000, and 3000, respectively. - + + + Создание виртуального сетевого подключения + между двумя сетями через интернет. Тестирование подключения с + помощью таких инструментов как &man.ping.8;, чтобы убедиться, что + оно работает. + - + + Применение политики безопасности чтобы убедиться, что трафик + между двумя сетями прозрачно шифруется и расшифровывается если + необходимо. Тестирование с помощью таких инструментов как + &man.tcpdump.1;, чтобы убедиться, что трафик шифруется. + + + + Настройка дополнительных программ на шлюзах FreeBSD, + чтобы компьютеры &windows; из одной сети видели компьютеры + в другой через VPN. + + - (1) - HOST A ------> HOST B + + Шаг 1: Создание и тестирование <quote>виртуального</quote> + сетевого подключения - (1)PROTO=AH - ALG=MD5(RFC1826) - KEY=MYSECRETMYSECRET - SPI=1000 + Предположим, что вы работаете на шлюзе сети #1 (с публичным + адресом A.B.C.D, приватным + адресом 192.168.1.1) и запускаете + ping 192.168.2.1, т.е. на приватный адрес + машины с IP адресом W.X.Y.Z. + Что должно произойти, чтобы это сработало? - (2.1) - HOST A <------ HOST B - <------ - (2.2) + + + Шлюз должен знать, как достичь 192.168.2.1. Другими словами, у него + должен быть маршрут к 192.168.2.1. + + + Приватные IP адреса, такие как диапазон 192.168.x не адресуются в + интернет. Каждый пакет, отправляемый на + 192.168.2.1 должен быть + завернут в другой пакет. Исходным адресом пакета + должен быть A.B.C.D, + а адресом назначения W.X.Y.Z. + Этот процесс называется + инкапсуляцией. + + + Как только этот пакет достигнет W.X.Y.Z, необходимо будет + разинкапсулировать его и доставить к 192.168.2.1. + + + + Как вы можете увидеть, это требует туннеля + между двумя сетями. Два конца туннеля + это IP адреса A.B.C.D и + W.X.Y.Z. Туннель используется для + передачи трафика с приватными IP адресами через интернет. + + В FreeBSD этот туннель создается с помощью устройства generic + interface, или gif. Как вы можете + догадаться, интерфейс gif на каждом хосте + должен быть настроен с четырьмя IP адресами; два для публичных + IP адресов и два для приватных IP адресов. + + В ядро обеих компьютеров FreeBSD должна быть встроена + поддержка устройства gif. Вы можете сделать это, добавив + строку: + + pseudo-device gif + + к файлу настройки ядра на обеих компьютерах, с последующей + компиляцией, установкой и перезагрузкой. + + Настройка туннеля это двухшаговый процесс. Во-первых, + необходимо задать сведения о внешнем (или публичном) IP адресе + с помощью &man.gifconfig.8;. Затем о приватном IP адресе + с помощью &man.ifconfig.8;. + + На шлюзе сети #1 для настройки туннеля вам потребуется запустить + следующие две команды. + + gifconfig gif0 A.B.C.D W.X.Y.Z +ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff + + + На другом шлюзе подобные команды, но с IP адресами в обратном + порядке. + + gifconfig gif0 W.X.Y.Z A.B.C.D +ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff + + + Затем вы можете запустить: - (2.1) - PROTO=AH - ALG=new-HMAC-SHA1(new AH) - KEY=KAMEKAMEKAMEKAMEKAME - SPI=2000 + gifconfig gif0 - (2.2) - PROTO=ESP - ALG=new-DES-expIV(new ESP) - IV length = 8 - KEY=PASSWORD - SPI=3000 + для просмотра настройки. Например, на шлюзе сети #1 + вы увидите: + &prompt.root; gifconfig gif0 +gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280 +inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff +physical address inet A.B.C.D --> W.X.Y.Z - Now, let's setup security association. Execute &man.setkey.8; - on both HOST A and B: + Как вы можете видеть, был создан туннель между физическими + адресами A.B.C.D и + W.X.Y.Z, для тунеллирования разрешен + трафик между 192.168.1.1 и 192.168.2.1. + + Это также добавляет запись к таблице маршрутизации на обеих + машинах, вы можете проверить запись командой netstat + -rn. Вот вывод этой команды на шлюзе сети #1. + + &prompt.root; netstat -rn +Routing tables + +Internet: +Destination Gateway Flags Refs Use Netif Expire +... +192.168.2.1 192.168.1.1 UH 0 0 gif0 +... + - + Как показывает значение поля Flags, это маршрут + к хосту, что означает, что каждый шлюз знает, как достичь другого + шлюза, но не знает как достичь остальной части соответствующей сети. + Эта проблема будет быстро решена. -&prompt.root; setkey -c -add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; -add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; -add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; -^D + Вероятно, на обеих машинах запущен межсетевой экран. VPN + должен обходить его. Вы можете разрешить весь трафик между + двумя сетями, или включить правила, защищающие каждый конец + соединения от другого. - + Это сильно упрощает тестирование настройки межсетевого экрана, + если вы разрешаете весь трафик через VPN. Вы всегда можете + Вы всегда можете усилить защиту позже. Если вы используете + на шлюзах &man.ipfw.8;, команда вроде этой - Actually, IPsec communication doesn't process until security policy - entries will be defined. In this case, you must setup each host. + ipfw add 1 allow ip from any to any via gif0 - + разрешит весь трафик между двумя концами VPN без влияния на + другие правила межсетевого экрана. Очевидно, вам потребуется + запустить эту команду на обеих шлюзах. -At A: + Этого достаточно для включения ping с одного шлюза на другой. + На 192.168.1.1, вы сможете + запустить -&prompt.root; setkey -c -spdadd 10.2.3.4 10.6.7.8 any -P out ipsec - ah/transport/10.2.3.4-10.6.7.8/require ; -^D + ping 192.168.2.1 -At B: + и получить ответ, и аналогично на другом шлюзе. -&prompt.root; setkey -c -spdadd 10.6.7.8 10.2.3.4 any -P out ipsec - esp/transport/10.6.7.8-10.2.3.4/require ; -spdadd 10.6.7.8 10.2.3.4 any -P out ipsec - ah/transport/10.6.7.8-10.2.3.4/require ; -^D + Однако, машины в другой сети пока недоступны. Это из-за + маршрутизации — хотя шлюзы знают, как связаться друг с + другом, они не знают, как связаться с сетью за другим шлюзом. + Для решения этой проблемы вы должны добавить статический маршрут + на каждом шлюзе. Команда на первом шлюзе будет выглядеть так: - HOST A --------------------------------------> HOST E - 10.2.3.4 10.6.7.8 - | | - ========== old AH keyed-md5 ==========> + route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 + - <========= new AH hmac-sha1 =========== - <========= new ESP des-cbc ============ + Она говорит Для достижения хостов в сети + 192.168.2.0, отправляйте пакеты + хосту 192.168.2.1. Вам + потребуется запустить похожую команду на другом шлюзе, но с + адресами 192.168.1.x. - - + IP трафик с хостов в одной сети теперь может достичь хосты в + другой сети. - - Transport mode example with IPv6 + Теперь создано две трети VPN между двумя сетями, поскольку + это виртуальная (virtual) сеть (network). + Она еще не приватная (private). Вы можете протестировать ее + с помощью &man.ping.8; и &man.tcpdump.1;. Войдите на шлюз и + запустите - Another example using IPv6. + tcpdump dst host 192.168.2.1 - ESP transport mode is recommended for TCP port number 110 between - Host-A and Host-B. + В другой сессии на этом же хосте запустите - + ping 192.168.2.1 - ============ ESP ============ - | | - Host-A Host-B - fec0::10 -------------------- fec0::11 + Вы увидите примерно такие строки: - + +16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request +16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply +16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request +16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply +16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request +16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply + + + Как вы видите, ICMP сообщения пересылаются вперед и назад + незашифрованными. Если вы использовали с &man.tcpdump.1; параметр + для получения большего объема данных пакета, + то увидите больше информации. + + Конечно же это неприемлемо. В следующем разделе мы обсудим + защиту соединения между двумя сетями, так что весь трафик будет + автоматически шифроваться. + + + Резюме: + + Настройте оба ядра с pseudo-device + gif. + + + Отредактируйте /etc/rc.conf на шлюзе + #1 и добавьте следующие строки (подставляя IP адреса где + необходимо). + gifconfig_gif0="A.B.C.D W.X.Y.Z" +ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff" +static_routes="vpn" +route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00" + + - Encryption algorithm is blowfish-cbc whose key is "kamekame", and - authentication algorithm is hmac-sha1 whose key is "this is the test - key". Configuration at Host-A: + + Отредактируйте скрипт межсетевого экрана + (/etc/rc.firewall, или подобный) на обеих + хостах и добавьте - + ipfw add 1 allow ip from any to any via gif0 + + + Выполните соответствующие изменения в + /etc/rc.conf на шлюзе #2, + меняя порядок IP адресов. + + + - &prompt.root; setkey -c <<EOF - spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec - esp/transport/fec0::10-fec0::11/use ; - spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec - esp/transport/fec0::11-fec0::10/use ; - add fec0::10 fec0::11 esp 0x10001 - -m transport - -E blowfish-cbc "kamekame" - -A hmac-sha1 "this is the test key" ; - add fec0::11 fec0::10 esp 0x10002 - -m transport - -E blowfish-cbc "kamekame" - -A hmac-sha1 "this is the test key" ; - EOF + + Шаг 2: Защита соединения - + Для защиты соединения мы будем использовать IPsec. IPsec + предоставляет хостам механизм определения ключа для шифрования + и для последующего использования этого ключа для шифрования + данных между двумя хостами. - and at Host-B: + Здесь будут рассмотрены два аспекта настройки. - - &prompt.root; setkey -c <<EOF - spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec - esp/transport/fec0::11-fec0::10/use ; - spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec - esp/transport/fec0::10-fec0::11/use ; - add fec0::10 fec0::11 esp 0x10001 -m transport - -E blowfish-cbc "kamekame" - -A hmac-sha1 "this is the test key" ; - add fec0::11 fec0::10 esp 0x10002 -m transport - -E blowfish-cbc "kamekame" - -A hmac-sha1 "this is the test key" ; - EOF + + + У хостов должен быть способ согласования используемого + алгоритма шифрования. Как только хосты договорятся об этом, + можно говорить об установленном между ними + безопасном соединении. + + + Должен быть механизм определения, какой трафик необходимо + шифровать. Конечно, вам не требуется шифровать весь исходящий + трафик — достаточно шифровать только трафик, идущий + через VPN. Правила, определяющие то, какой трафик необходимо + шифровать, называются политикой безопасности. + + - + Безопасное соединение и политика безопасности поддерживаются + ядром, и могут быть изменены программами пользователя. Однако + перед тем, как вы сможете сделать это, необходимо настроить + поддержку протоколов IPsec и Encapsulated Security Payload (ESP) в + ядре. Это делается добавлением в настройку ядра параметров: + + options IPSEC +options IPSEC_ESP + + + с последующим перекомпилированием, переустановкой и + перезагрузкой. Как и прежде вам потребуется сделать это с ядрами на + обеих шлюзах. + + При настройке параметров безопасности (security associations) + у вас есть два варианта. Вы можете настроить их вручную для обеих + хостов, задав алгоритм шифрования, ключи для шифрования и так далее, + или использовать даемоны, реализующие Internet Key Exchange protocol + (IKE), который сделает это за вас. + + Рекомендуется последнее. Помимо прочего, этот способ более + прост. + + Редактирование и отображение политики безопасности выполняется + с помощью &man.setkey.8;. По аналогии, setkey + используется для настройки таблиц политики безопасности ядра так же, + как &man.route.8; используется для настройки таблиц маршрутизации + ядра. setkey также может отображать текущие + параметры безопасности, и продолжая аналогию дальше, это + соответствует netstat -r. + + Существует множество даемонов для управления параметрами + безопасности в FreeBSD. Здесь будет описано использование одного из + них, racoon. racoon находится в категории security/ коллекции портов + FreeBSD и устанавливается обычным способом. + + racoon должен работать на обеих шлюзах. На каждом из хостов + он настраивается с IP адресом другого конца VPN, и секретным + ключом (по вашему выбору, должен быть одним и тем же на обеих + шлюзах). + + Эти два даемона подключаются друг к другу, подтверждают, что они + именно те, за кого себя выдают (используя секретный ключ, заданный + вами). Затем даемоны генерируют новый секретный ключ и используют + его для шифрования трафика через VPN. Они периодически изменяют + этот ключ, так что даже если атакующий сломает один из ключей + (что теоретически почти невозможно) это не даст ему слишком много + — он сломал ключ, который два даемона уже сменили на + другой. + + Настройки racoon сохраняются в + ${PREFIX}/etc/racoon. Этот файл не требует + слишком больших изменений. Другим компонентом настройки + racoon, который потребуется изменить, является предварительный + ключ. + + В настройке по умолчанию racoon ищет его в файле + ${PREFIX}/etc/racoon/psk.txt. Необходимо + отметить, что предварительный ключ не + используется для шифрования трафика через VPN соединение + это просто маркер, позволяющий управляющим ключами даемонам + доверять друг другу. + + psk.txt содержит строку для каждого + удаленного сервера, с которым происходит соединение. В этом примере + два сервера, каждый файл psk.txt будет + содержать одну строку (каждый конец VPN общается только с другим + концом. + + На шлюзе #1 эта строка будет выглядеть примерно так: + + W.X.Y.Z secret + + То есть публичный IP адрес удаленной + стороны, пробел и текстовая строка, секретная фраза. + + + На шлюзе #2 строка будет выглядеть примерно так: + + A.B.C.D secret + + То есть публичный IP адрес удаленной стороны и та же + секретная фраза. Перед запуском racoon режим доступа к файлу + psk.txt должен быть установлен в + 0600 (т.е. запись и чтение только для + root). + + Вы должны запустить racoon на обеих шлюзах. Вам также + потребуется добавить правила для включения IKE трафика, + передающегося по UDP через порт ISAKMP (Internet Security Association + Key Management Protocol). Опять же, они должны быть + расположены насколько возможно ближе к началу набора правил. + + ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp +ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp + + + Как только racoon будет запущен, вы можете попробовать + выполнить ping с одного шлюза на другой. Соединение все еще не + зашифровано, но racoon установит параметры безопасности между + двумя хостами — это может занять время и вы можете заметить + небольшую задержку перед началом ответа команды ping. + + Как только параметры безопасности установлены, вы можете + просмотреть их используя &man.setkey.8;. Запустите + + setkey -D + + на любом из хостов для просмотра информации о параметрах + безопасности. + + Это одна сторона проблемы. Другая сторона это настройка + политики безопасности. + + Для создания разумной политики безопасности давайте вспомним, + что уже было настроено. Это рассмотрение относится к обеим + концам соединения. + + Каждый отправляемый IP пакет имеет заголовок, содержащий информацию + о пакете. Заголовок включает IP адреса источника и назначения. + Как мы уже знаем, приватные IP адреса, такие как 192.168.x.y, не могут появиться в + интернет. Они должны быть сначала включены внутрь другого + пакета. В этом пакете приватные IP адреса источника и назначения + заменяются публичными IP адресами. + + То есть исходящий пакет, который выглядит примерно так: + + + + + + + + + .----------------------------. + | Src: 192.168.1.1 | + | Dst: 192.168.2.1 | + | <другие данные заголовка> | + +----------------------------+ + | <данные пакета> | + `----------------------------' + + + + будет инкапсулирован в другой пакет, выглядящий примерно + так: + + + + + + + + + .--------------------------------. + | Src: A.B.C.D | + | Dst: W.X.Y.Z | + | <другие данные заголовка> | + +--------------------------------+ + | .----------------------------. | + | | Src: 192.168.1.1 | | + | | Dst: 192.168.2.1 | | + | | <другие данные заголовка> | | + | +----------------------------+ | + | | <данные пакета> | | + | `----------------------------' | + `--------------------------------' + + + + Этой инкапсуляцией занимается устройство + gif. Как вы можете видеть, теперь + у пакета есть реальный IP адрес, исходный пакет был включен + в этот пакет в виде данных, которые передаются через + интернет. + + Конечно, мы хотим зашифровать весь трафик между VPN. + Вы можете сформулировать это на словах так: + + Если пакет отправляется с A.B.C.D, и предназначен для W.X.Y.Z, зашифровать его, используя + необходимые параметры безопасности. + + Если пакет отправляется с W.X.Y.Z, и предназначен для A.B.C.D, расшифровать его, используя + необходимые параметры безопасности. + + Это похоже на желаемое, но не совсем то. Если вы сделаете + это, весь трафик от и к W.X.Y.Z, + даже если он не является частью VPN, будет зашифрован. Правильная + политика такова: + + Если пакет отправляется с A.B.C.D, в нем инкапсулирован другой пакет + и адрес назначения W.X.Y.Z, + зашифровать его, используя необходимые параметры + безопасности. + + Если пакет отправляется с W.X.Y.Z, в нем инкапсулирован другой пакет + и адрес назначения A.B.C.D, + зашифровать его, используя необходимые параметры + безопасности. + + Тонкое, но необходимое различие. + + Политика безопасности также устанавливается с использованием + &man.setkey.8;. В &man.setkey.8; предусмотрен язык определения + политики &man.setkey.8;. Вы можете или ввести инструкции + по настройке со стандартного ввода, или использовать параметр + для задания файла, содержащего эти + инструкции. + + Настройка на шлюзе #1 (где есть публичный IP адрес + A.B.C.D) для включения шифрования + всего предназначенного W.X.Y.Z + трафика: - Note the direction of SP. + +spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; + + + Поместите эти команды в файл (например, + /etc/ipsec.conf) и запустите + + &prompt.root; setkey -f /etc/ipsec.conf + + указывает &man.setkey.8; добавить + правило к базе данных политики безопасности. Остальная часть + строки указывает какие пакеты будут соответствовать политике. + A.B.C.D/32 и W.X.Y.Z/32 это IP адреса и сетевые маски, + определяющие сети или хосты, к которым будет применяться данная + политика. В данном случае мы хотим применить их к трафику между + этими двумя хостами. Параметр сообщает + ядру, что эта политика должна применяться только к пакетам, + инкапсулирующим другие пакеты. Параметр + сообщает, что эта политика применяется к исходящим пакетам, и + – то, что пакеты будут + зашифрованы. + + Оставшаяся часть строки определяет, как эти пакеты будут + зашифрованы. Будет использоваться протокол , + а параметр показывает, что пакет в дальнейшем + будет инкапсулирован в IPsec пакет. Повторное использование + A.B.C.D и W.X.Y.Z предназначено для выбора + используемых параметров безопасности, и наконец параметр + разрешает шифрование пакетов, попадающих + под это правило. + + Это правило соответствует только исходящим пакетам. Вам + потребуется похожее правило, соответствующее входящим пакетам. + + spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; + + Обратите внимание, что вместо используется + и IP адреса переставлены. + + Другому шлюзу (с публичным IP адресом + W.X.Y.Z) потребуются похожие + правила. + + spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; + spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; + + Наконец, вам потребуется добавить правила к межсетевому экрану + для включения прохождения пакетов ESP и IPENCAP в обе стороны. + На обеих хостах потребуется добавить следующие правила: + + ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z +ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D +ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z +ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D + + + Поскольку правила симметричны, можно использовать их без + изменения на обеих хостах + + Исходящие пакеты теперь будут выглядеть примерно так: + + + + + + + + + .------------------------------. --------------------------. + | Src: A.B.C.D | | + | Dst: W.X.Y.Z | | + | <other header info> | | Encrypted + +------------------------------+ | packet. + | .--------------------------. | -------------. | contents + | | Src: A.B.C.D | | | | are + | | Dst: W.X.Y.Z | | | | completely + | | <other header info> | | | |- secure + | +--------------------------+ | | Encap'd | from third + | | .----------------------. | | -. | packet | party + | | | Src: 192.168.1.1 | | | | Original |- with real | snooping + | | | Dst: 192.168.2.1 | | | | packet, | IP addr | + | | | <other header info> | | | |- private | | + | | +----------------------+ | | | IP addr | | + | | | <packet data> | | | | | | + | | `----------------------' | | -' | | + | `--------------------------' | -------------' | + `------------------------------' --------------------------' + + + + + Когда эти пакеты будут получены на удаленном конце VPN + соединения, они будут расшифрованы (используя параметры + безопасности, о которых договорился racoon). Затем они будут + переданы интерфейсу gif, который + развернет второй слой, оставив пакет с внутренними + адресами, который сможет попасть во внутреннюю сеть. + + Вы можете проверить безопасность тем же &man.ping.8;, который + использовался ранее. Сначала войдите на шлюз A.B.C.D и запустите: + + tcpdump dst host 192.168.2.1 + + В другой сессии на том же хосте запустите + + ping 192.168.2.1 + + В этот момент вы должны увидеть примерно это: + + XXX tcpdump output + + Теперь, как видите, &man.tcpdump.1; показывает ESP пакеты. Если + вы попытаетесь просмотреть их с параметром , + то вероятно увидите нечто непонятное, поскольку применяется + шифрование. + + Поздравляем. Вы только что настроили VPN между двумя удаленными + сетями. + + + Резюме + + Настройте оба ядра с: + + options IPSEC +options IPSEC_ESP + + + + Установите security/racoon. Отредактируйте + ${PREFIX}/etc/racoon/psk.txt на обеих + шлюзах, добавив запись для каждого IP адреса удаленного хоста + и секретный ключ, который будет известен им обеим. Убедитесь, + что режим доступа к файлу 0600. + + + Добавьте к + /etc/rc.conf на каждом хосте следующие + строки: + + ipsec_enable="YES" +ipsec_file="/etc/ipsec.conf" + + + + Создайте /etc/ipsec.conf на каждом + хосте с необходимыми строками spdadd. На шлюзе #1 он будет + таким: + + +spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec + esp/tunnel/A.B.C.D-W.X.Y.Z/require; +spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec + esp/tunnel/W.X.Y.Z-A.B.C.D/require; + + + А на шлюзе #2 таким: + + +spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec + esp/tunnel/W.X.Y.Z-A.B.C.D/require; +spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec + esp/tunnel/A.B.C.D-W.X.Y.Z/require; + + + + Добавьте правила к межсетевым экранам обеих хостов для + включения IKE, ESP и IPENCAP трафика: + + +ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp +ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp +ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z +ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D +ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z +ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D + + + + + Двух приведенных шагов должно быть достаточно для настройки + и включения VPN. Машины в каждой сети смогут обращаться друг к + другу по IP адресам, и весь трафик через соединение будет + автоматически надежно зашифрован. + + + + + + + + Chern + Lee + Предоставил + + + + + + OpenSSH + OpenSSH + + безопасность + OpenSSH + + + OpenSSH это набор сетевых инструментов, + используемых для защищенного доступа к удаленным компьютерам. + Он может быть использован в качестве непосредственной замены + rlogin, rsh, + rcp и telnet. + Кроме того, любые другие TCP/IP соединения могут быть безопасно + тунеллированы/перенаправлены через SSH. + OpenSSH шифрует весь трафик, эффективно + предотвращая кражу данных, перехват соединения и другие сетевые + атаки. + + OpenSSH поддерживается проектом + OpenBSD, он основан на SSH v1.2.12 со всеми последними исправлениями + и обновлениями, совместим с протоколами SSH версий 1 и 2. + OpenSSH включен в базовую систему + начиная с FreeBSD 4.0. - Tunnel mode example with IPv4 + Преимущества использования OpenSSH + + Обычно при использовании &man.telnet.1; или &man.rlogin.1; + данные пересылаются по сети в незашифрованной форме. Перехватчик + пакетов в любой точке сети между клиентом и сервером может + похитить информацию о пользователе/пароле или данные, передаваемые + через соединение. Для предотвращения этого + OpenSSH предлагает различные методы + шифрования. + - Tunnel mode between two security gateways + + Включение sshd + + OpenSSH + включение + - Security protocol is old AH tunnel mode, i.e. specified by - RFC1826, with keyed-md5 whose key is "this is the test" as - authentication algorithm. + Убедитесь, что добавили в файл rc.conf + следующую строку: - + sshd_enable="YES" - ======= AH ======= - | | - Network-A Gateway-A Gateway-B Network-B - 10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24 + При следующей загрузке системы запущен &man.sshd.8;, даемон для + OpenSSH. Вы можете также запустить + sshd непосредственно, набрав в + командной строке sshd. - + + SSH клиент + + OpenSSH + клиент + + + Утилита &man.ssh.1; работает подобно &man.rlogin.1;. + + &prompt.root; ssh user@example.com +Host key not found from the list of known hosts. +Are you sure you want to continue connecting (yes/no)? yes +Host 'example.com' added to the list of known hosts. +user@example.com's password: ******* + + Вход продолжится так же, как если бы сессия была инициирована + с использованием rlogin или + telnet. SSH использует систему опознавательных + ключей для проверки подлинности сервера при подключении клиента. + Пользователю предлагается yes только при первом + подключении. Дальнейшие попытки входа предваряются проверкой + сохраненного ключа сервера. SSH клиент сообщит вам, если сохраненный + ключ будет отличаться от только что полученного. Ключи серверов + сохраняются в ~/.ssh/known_hosts, или в + ~/.ssh/known_hosts2 для SSH v2. + + По умолчанию, сервер OpenSSH настроен + для приема соединений SSH v1 и SSH v2. Клиент может выбирать между + этими двумя протоколами. Версия 2 безопаснее своего + предшественника. + + Команде &man.ssh.1; можно указать использование определенной + версии протокола, запустив ее с параметром + или для версии 1 или 2 соответственно. + - Configuration at Gateway-A: + + Безопасное копирование + + OpenSSH + безопасное копирование + + scp + + Команда &man.scp.1; работает подобно &man.rcp.1;; она копирует + файл с удаленного компьютера, но делает это безопасным + способом. + + &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT +user@example.com's password: ******* +COPYRIGHT 100% |*****************************| 4735 +00:00 +&prompt.root; + + Поскольку в предыдущем примере ключ сервера уже был сохранен, + в этом примере он проверяется при использовании &man.scp.1;. + + Параметры, передаваемые &man.scp.1;, похожи на параметры + &man.cp.1;, с файлом или файлами в качестве первого аргумента и + приемником копирования во втором. Поскольку файлы файлы передаются + по сети через SSH, один или более аргументов принимают форму + . - + - &prompt.root; setkey -c <<EOF - spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec - ah/tunnel/172.16.0.1-172.16.0.2/require ; - spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec - ah/tunnel/172.16.0.2-172.16.0.1/require ; - add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any - -A keyed-md5 "this is the test" ; - add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any - -A keyed-md5 "this is the test" ; + + Настройка + + OpenSSH + настройка + + + Системные файлы настройки для даемона и клиента + OpenSSH расположены в каталоге + /etc/ssh. + + Файл ssh_config используется для настройки + клиента, а sshd_config для даемона. + + Кроме того, параметры + (по умолчанию /usr/sbin/sshd), и + rc.conf + дают дополнительные возможности настройки. + - EOF + + ssh-keygen + + Вместо использования паролей, с помощью &man.ssh-keygen.1; + пользователи могут аутентифицироваться ключами RSA: + + &prompt.user; ssh-keygen -t rsa1 +Initializing random number generator... +Generating p: .++ (distance 66) +Generating q: ..............................++ (distance 498) +Computing the keys... +Key generation complete. +Enter file in which to save the key (/home/user/.ssh/identity): +Enter passphrase: +Enter the same passphrase again: +Your identification has been saved in /home/user/.ssh/identity. +... + + &man.ssh-keygen.1; создаст пару публичного и приватного + ключей, используемых для аутентификации. Приватный ключ сохраняется + в ~/.ssh/identity, а публичный в + ~/.ssh/identity.pub. Для включения + аутентификации по ключам публичный ключ должен + быть помещен в ~/.ssh/authorized_keys + на удаленном компьютере. + + Это позволяет соединяться с удаленным компьютером с помощью + RSA аутентификации вместо паролей. + + Параметр приведет к созданию RSA + ключей, используемых SSH протоколом версии 1. Если вы хотите + использовать RSA ключи с SSH протоколом версии 2, используйте + команду ssh-keygen -t rsa. + + Если при генерации ключей был использован пароль, каждый раз + для при использовании приватного ключа он будет запрашиваться + у пользователя. + + DSA ключ для SSH протокола версии 2 может быть создан в тех же + целях командой ssh-keygen -t dsa. Эта команда + создаст публичный/приватный ключи DSA для использования только + с SSH протоколом версии 2. Публичный ключ сохраняется в + ~/.ssh/id_dsa.pub, а приватный ключ в + ~/.ssh/id_dsa. + + Публичный ключ DSA также должен быть помещен в каталог + ~/.ssh/authorized_keys на удаленном + компьютере. + + Утилиты &man.ssh-agent.1; и &man.ssh-add.1; используются + для управления множеством защищенных паролем приватных + ключей. + + Параметры и имена файлов могут различаться для разных + версий OpenSSH, установленных в системе, + для решения проблем обратитесь к странице справочника + &man.ssh-keygen.1;. + - + + SSH тунеллирование + + OpenSSH + тунеллирование + - If port number field is omitted such above then "[any]" is - employed. `-m' specifies the mode of SA to be used. "-m any" means - wild-card of mode of security protocol. You can use this SA for both - tunnel and transport mode. + OpenSSH поддерживает возможность + создания туннеля для пропуска соединения по другому протоколу + через защищенную сессию. - and at Gateway-B: + Следующая команда указывает &man.ssh.1; создать туннель для + telnet: - + &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com +&prompt.user; - &prompt.root; setkey -c <<EOF - spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec - ah/tunnel/172.16.0.2-172.16.0.1/require ; - spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec - ah/tunnel/172.16.0.1-172.16.0.2/require ; - add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any - -A keyed-md5 "this is the test" ; - add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any - -A keyed-md5 "this is the test" ; + Команда ssh используется со следующими + параметрами: - EOF + + + - + + Указывает ssh использовать версию + 2 протокола (не используйте этот параметр, если работаете + со старыми SSH серверами). + + - Making SA bundle between two security gateways + + - AH transport mode and ESP tunnel mode is required between - Gateway-A and Gateway-B. In this case, ESP tunnel mode is applied first, - and AH transport mode is next. + + Означает использование в не-командном режиме, только для + тунеллирования. Если этот параметр опущен, + ssh запустит обычную сессию. + + - + + - ========== AH ========= - | ======= ESP ===== | - | | | | - Network-A Gateway-A Gateway-B Network-B - fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64 + + Указывает ssh запускаться в фоновом + режиме. + + - - + + - - Tunnel mode example with IPv6 + + Означает локальный туннель в стиле + localport:remotehost:remoteport. + + - Encryption algorithm is 3des-cbc, and authentication algorithm - for ESP is hmac-sha1. Authentication algorithm for AH is hmac-md5. - Configuration at Gateway-A: + + - + + Удаленный сервер SSH. + + + - &prompt.root; setkey -c <<EOF - spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec - esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require - ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ; - spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec - esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require - ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ; - add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel - -E 3des-cbc "kamekame12341234kame1234" - -A hmac-sha1 "this is the test key" ; - add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport - -A hmac-md5 "this is the test" ; - add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel - -E 3des-cbc "kamekame12341234kame1234" - -A hmac-sha1 "this is the test key" ; - add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport - -A hmac-md5 "this is the test" ; - - EOF - + Туннель SSH создается путем создания прослушивающего сокета + на определенном порту localhost. Затем все + принятые на локальном хосту/порту соединения переправляются на + через SSH на определенный удаленный хост и порт. - Making SAs with the different end + В этом примере, порт 5023 на + localhost перенаправляется на порт + 23 на localhost + удаленного компьютера. Поскольку 23 + это порт telnet, будет создано защищенное + соединение telnet через туннель + SSH. - ESP tunnel mode is required between Host-A and Gateway-A. Encryption - algorithm is cast128-cbc, and authentication algorithm for ESP is - hmac-sha1. ESP transport mode is recommended between Host-A and Host-B. - Encryption algorithm is rc5-cbc, and authentication algorithm for ESP is - hmac-md5. + Этот метод можно использовать для любого числа небезопасных + протоколов, таких как SMTP, POP3, FTP, и так далее. - + + Использование SSH для создания защищенного туннеля на + SMTP - ================== ESP ================= - | ======= ESP ======= | - | | | | - Host-A Gateway-A Host-B - fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2 + &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com +user@mailserver.example.com's password: ***** +&prompt.user; telnet localhost 5025 +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +220 mailserver.example.com ESMTP - + Этот метод можно использовать вместе с &man.ssh-keygen.1; + и дополнительными пользовательскими учетными записями для + создания более удобного автоматического SSH тунеллирования. + Ключи могут быть использованы вместо паролей, и туннели + могут запускаться от отдельных пользователей. + - Configuration at Host-A: + + Практические примеры SSH тунеллирования + + + Защищенный доступ к серверу POP3 + + На работе находится SSH сервер, принимающий соединения + снаружи. В этой же офисной сети находится почтовый сервер, + поддерживающий протокол POP3. Сеть или сетевое соединение + между вашим домом и офисом могут быть или не быть полностью + доверяемыми. По этой причине вам потребуется проверять + почту через защищенное соединение. Решение состоит в создании + SSH соединения к офисному серверу SSH и тунеллирование + через него к почтовому серверу. + + &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com +user@ssh-server.example.com's password: ****** + + Когда туннель включен и работает, вы можете настроить + почтовый клиент для отправки запросов POP3 на + localhost, порт 2110. Соединение будет + безопасно переправлено через туннель на + mail.example.com. + + + + Прохождение через Драконовский Брандмауэр + + Некоторые сетевые администраторы устанавливают + на межсетевых экранах (брандмауэрах) драконовские правила, + фильтруя не только входящие соединения, но и исходящие. + Вам может быть разрешен доступ к удаленным компьютерам только + по портам 22 и 80, для SSH и просмотра сайтов. + + Вам может потребоваться доступ к другому (возможно, не + относящемуся к работе) сервису, такому как Ogg Vorbis + для прослушивания музыки. Если этот сервер Ogg Vorbis + выдает поток не с портов 22 или 80, вы не сможете получить + к нему доступ. + + Решение состоит в создании SSH соединения с компьютером + вне межсетевого экрана и использование его для тунеллирования + сервера Ogg Vorbis. + + &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org +user@unfirewalled-system.example.org's password: ******* + + Клиентскую программу теперь можно настроить на + localhost порт 8888, который будет перенаправлен + на music.example.com порт 8000, успешно + обойдя межсетевой экран. + + + - + + Для дальнейшего чтения - &prompt.root; setkey -c <<EOF - spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec - esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use - esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ; - spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec - esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use - esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ; - add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001 - -m transport - -E cast128-cbc "12341234" - -A hmac-sha1 "this is the test key" ; - add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002 - -E rc5-cbc "kamekame" - -A hmac-md5 "this is the test" ; - add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003 - -m transport - -E cast128-cbc "12341234" - -A hmac-sha1 "this is the test key" ; - add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004 - -E rc5-cbc "kamekame" - -A hmac-md5 "this is the test" ; - - EOF + OpenSSH + &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; + &man.ssh-agent.1; &man.ssh-add.1; + &man.sshd.8; &man.sftp-server.8; + + - + + + + + Robert + Watson + Спонсировали DARPA и Network Associates Laboratories. + Предоставил + + + + + MAC + + Принудительный контроль доступа (MAC) + + FreeBSD 5.0 включает новую систему (framework) безопасности уровня + ядра, TrustedBSD MAC Framework. Система MAC позволяет применять + расширения безопасности при компилировании, загрузке и выполнении, + она может быть использована для поддержки принудительного контроля + доступа (Mandatory Access Control, MAC), а также + специфических модулей безопасности. + Система MAC на данный момент считается экспериментальной, и без + внимательного изучения не должна использоваться в реальных задачах. + Ожидается, что MAC будет лучше подходить для широкого использования + начиная с FreeBSD 5.2. + + При включении в ядро система MAC использует модули безопасности для + усиления существующей модели безопасности ядра, ограничивая доступ к + системным сервисам и объектам. Например, модуль + &man.mac.bsdextended.4; усиливает контроль доступа к файловой системе, + позволяя администраторам задавать набор правил подобный тому, который + используется для межсетевого экрана, ограничивая доступ к объектам + файловой системы на основе id пользователя и его принадлежности к + группам. Некоторые модули требуют мало или вообще не требуют + настройки, например &man.mac.seeotheruids.4;, в то время как другие + требуют тотальной маркировки объектов и большого объема настройки, + например &man.mac.biba.4; и &man.mac.mls.4;. + + Для включения системы MAC Framework в ядро системы вы должны + добавить в файл настройки ядра следующую строку: + + options MAC + + Модули политики безопасности, поставляемые с базовой системой, + могут быть загружены с помощью &man.kldload.8; или при загрузке + через &man.loader.8;. Они также могут быть непосредственно встроены + в ядро с помощью приведенных ниже параметров, если использование + модулей нежелательно. + + Различные политики MAC могут быть настроены разными способами; + зачастую модули политики MAC экспортируют параметры настройки через + &man.sysctl.8; MIB, используя пространство имен + security.mac. Политики безопасности, относящиеся + к файловой системе или другим меткам могут требовать действий по + присвоению начальных меток системным объектам или создания файла + настройки политики безопасности. За информацией по настройке и + использованию каждого модуля политики обращайтесь к его справочной + странице. + + Существует множество инструментов для настройки системы MAC + и меток, поддерживаемых различными политиками безопасности. + Были созданы расширения для входа в систему и управления доступом + (&man.setusercontext.3;), поддерживающие присвоение пользователям + метки с помощью &man.login.conf.5;. Кроме того, были сделаны + изменения в &man.su.1;, &man.ps.1;, &man.ls.1;, и &man.ifconfig.8; + для проверки и установки меток на процессы, файлы и интерфейсы. + Были добавлены несколько новых инструментов для управления + метками объектов, включая &man.getfmac.8;, &man.setfmac.8; и + &man.setfsmac.8; для управления метками файлов, а также + &man.getpmac.8; и &man.setpmac.8;. + + Ниже представлен список модулей политики безопасности, поставляемых + с FreeBSD 5.0. + + + Политика целостности Biba (mac_biba) + + Политика целостности Biba + + Поставщик: TrustedBSD Project + Имя модуля: mac_biba.ko + Параметр ядра: MAC_BIBA + + TCB + + + Политика целостности Biba (Biba Integrity Policy, + &man.mac.biba.4;) создана для иерархического и не иерархического + присвоения всем системным объектам уровня доступа и применение + политики контроля за потоками информации для предотвращения + повреждения субъектов с высоким уровнем доступа и данных + субъектами с низким уровнем доступа. Целостность достигается + предотвращением чтения объектов с низким уровнем доступа + (зачастую файлов) субъектами с высоким уровнем доступа (обычно + процессами), и предотвращение записи в объекты с высоким уровнем + доступа субъектами с низким уровнем доступа. Эта политика + безопасности часто используется в коммерческих доверяемых + системах для обеспечения высокого уровня защиты + Trusted Code Base (TCB). Вследствие необходимости + тотального маркирования, политика целостности Biba должна быть + встроена в ядро или загружена при старте системы. + + + Брандмауэрная политика файловой системы (mac_bsdextended) + + Брандмауэрная политика файловой системы + + Поставщик: TrustedBSD Project + Имя модуля: mac_bsdextended.ko + Параметр ядра: MAC_BSDEXTENDED + File System Firewall Policy (брандмауэрная политика файловой + системы, &man.mac.bsdextended.4;) это расширение системы + контроля доступа файловой системы BSD, позволяющая администратору + определять набор брандмауэр-подобных правил для ограничения доступа + к объектам файловой системы, принадлежащим пользователям и группам. + Правила, управляемые &man.ugidfw.8;, могут ограничить доступ к + файлам и каталогам на основе uid и gid процесса, пытающегося получить + доступ, владельца и группы цели, на которую направлена попытка + доступа. Все правила ограничивающие, так что они могут быть + помещены в любом порядке. Эта политика не требует предварительной + настройки или маркировки и может подходить для многопользовательской + среды, где требуется принудительное ограничение на обмен данных + между пользователями. Необходимо соблюдать осторожность при + ограничения доступа к файлам, принадлежащим суперпользователю или + другим системным пользователям, поскольку множество полезных программ + и каталогов принадлежат этим пользователям. Как и сетевым + брандмауэром, неправильное применение правил брандмауэра файловой + системы может привести систему в неработоспособное состояние. + Новые инструменты для управления набором правил легко могут быть + написаны с использованием библиотеки &man.libugidfw.3;. + + + Политика <quote>тишины</quote> интерфейса (mac_ifoff) + + Политика тишины интерфейса + + Поставщик: TrustedBSD Project + Имя модуля: mac_ifoff.ko + Параметр ядра: MAC_IFOFF + Политика тишины интерфейса (Interface silencing + policy, &man.mac.ifoff.4;) запрещает использование сетевых + интерфейсов во время загрузки, пока они не будут явно включены, + предотвращая ответ сетевого стека на входящие пакеты. + Эта политика подходит, если требуется мониторинг пакетов, без + генерации трафика. + + + Low-Watermark Mandatory Access Control (LOMAC) + (mac_lomac) + + MAC + Low-Watermark + + + LOMAC + + Поставщик: Network Associates Laboratories + Имя модуля: mac_lomac.ko + Параметр ядра: MAC_LOMAC + Подобно политике целостности Biba, политика LOMAC + (&man.mac.lomac.4;) основывается на тотальной маркировке + всех системных объектов метками уровня доступа. В отличие + от Biba, LOMAC разрешает субъектам с высоким уровнем доступа + читать из объектов с низким уровнем доступа, но уровень + доступа субъекта понижается для предотвращения последующей + записи в объекты с высоким уровнем доступа. Эта политика + может применяться для обеспечения совместимости, поскольку + требует меньшей начальной настройки, чем Biba. Однако, как + и в случае Biba, она основана на тотальной маркировке объектов + и следовательно должна быть встроена в ядро или загружена + при старте системы. + + + + Многоуровневая политика безопасности (MLS) (mac_mls) + + Многоуровневая политика безопасности + + + MAC + Multi-Level + + + Поставщик: TrustedBSD Project + Имя модуля: mac_mls.ko + Параметр ядра: MAC_MLS + Многоуровневая безопасность (Multi-Level Security, + MLS, &man.mac.mls.4;) предназначена для + иерархической и не-иерархической метки всех системных + объектов с важными данными и жесткого ограничения передачи + информации для предотвращения утечки конфиденциальной информации. + Логическое соединение политики целостности Biba и + MLS зачастую поставляется в коммерческих + доверяемых операционных системах для обеспечения безопасности + данных в многопользовательской среде. + + Как и с Biba, происходит тотальное маркирование объектов, + следовательно необходимо встраивание в ядро или загрузка модуля + при старте системы. Как и с Biba, может потребоваться обширная + начальная настройка. + + + Шаблон политики MAC (mac_none) + + Шаблон политики MAC + + Поставщик: TrustedBSD Project + Имя модуля: mac_none.ko + Параметр ядра: MAC_NONE + Отсутствие политики безопасности (None policy, &man.mac.none.4;) + предоставляет пример политики безопасности для разработчиков, + реализуя все необходимое, но не меняя политику контроля доступа + системы. Запуск этой политики в реальных задачах не принесет + существенных преимуществ. + + + Политика разделения процессов (mac_partition) + + Политика разделения процессов + + Поставщик: TrustedBSD Project + Имя модуля: mac_partition.ko + Параметр ядра: MAC_PARTITION + Политика разделения процессов, (Partition policy, + &man.mac.partition.4;) предназначена для простого разграничения + видимости процессов, путем присвоения процессам меток, + определяющих, в каком из разделов системы они находятся. + При отсутствии меток все процессы могут просматриваться с + помощью стандартных инструментов мониторинга; если идентификатор + раздела существует, видны только процессы в том же разделе. + Эта политика может быть встроена в ядро, загружена при старте + системы или в любое другое время. + + + Просмотр других uid (mac_seeotheruids) + + Просмотр других uid + + Поставщик: TrustedBSD Project + Имя модуля: mac_seeotheruids.ko + Параметр ядра: MAC_SEEOTHERUIDS + Просмотр других uid (See Other Uids policy, + &man.mac.seeotheruids.4;) реализует модель видимости процессов, + похожую на mac_partition, но основывается на правах процессов, + а не на метках разделов. Политика может быть настроена для + исключения определенных пользователей и групп, включая разрешение + просмотра всех процессов операторам системы без специальных + привилегий. Политика может быть встроена в ядро, загружена при + запуске системы или в любое другое время. + + + политика для тестирования системы MAC (mac_test) + + политика для тестирования системы MAC + + Поставщик: TrustedBSD Project + Имя модуля: mac_test.ko + Параметр ядра: MAC_TEST + Политика для тестирования (Test policy, + &man.mac.test.4;) реализует регрессивное тестирование + среды для системы MAC, и завершится с ошибкой, если + внутренняя проверка правильности меток системы MAC не пройдет. + Этот модуль может использоваться для обнаружения ошибок + в маркировке системных объектов. Политика может быть встроена + в ядро, загружена при старте системы или в любое другое + время. + + + + + + + + Tom + Rhodes + Предоставил + + + + + ACL + + Списки контроля доступа файловой системы (ACL) + + В дополнение к другим расширениям файловой системы, таким как + снимки (snapshots), FreeBSD 5.0 и более поздние версии системы + предлагают защиту с помощью списков контроля доступа файловой системы + (File System Access Control Lists, ACLs). + + Списки контроля доступа расширяют стандартную модель прав &unix; + высоко совместимым (&posix;.1e) способом. Эта возможность позволяет + администратору получить преимущество от использования более + интеллектуальной модели безопасности. + + Для включения поддержки ACL в файловой + системе UFS, следующая строка: + + options UFS_ACL + + должна быть добавлена в файл настройки ядра. Если параметр не + добавлен, при попытке монтирования систем, поддерживающих + ACL, появится предупреждающее сообщение. + Этот параметр включен в ядро GENERIC. + ACL основывается на дополнительных атрибутах, + встроенных в файловую систему. Дополнительные атрибуты + поддерживаются по умолчанию следующим поколением файловых систем + &unix;, UFS2. + + Для включения дополнительных атрибутов в + UFS1 требуется больше усилий по сравнению с + UFS2. Производительность дополнительных + атрибутов в UFS2 также существенно выше. + По этим причинам для работы с списками контроля доступа + предпочтительно использование UFS2 + + ACL включаются во время монтирования флагом + , который добавляется к + /etc/fstab. Этот флаг также можно сделать + постоянным с помощью &man.tunefs.8;, изменив флаг + ACL в заголовке файловой системы. Вообще говоря, + использование флага в суперблоке предпочтительно по нескольким + причинам: + + + + Постоянный ACL флаг не может быть изменен + путем перемонтирования системы (&man.mount.8; ), + а только через &man.umount.8; и &man.mount.8;. Это означает, + что ACL нельзя включить на корневой файловой + системе после загрузки. Это также означает, что вы не можете + изменить флаг на используемой файловой системе. + + + + Установка флага в суперблоке приводит к постоянному монтированию + файловой системы с включенным ACL, даже если + нет записи в fstab или при смене порядка + устройств. Это предотвращает случайное монтирование файловой + системы без ACL, которое может повлечь за + собой проблемы с безопасностью. + + + + Мы можем изменить поведение ACL для + включения флага без полного перемонтирования, но считаем, что + желательно исключить случайное монтирование без + ACL, поскольку вы можете попасть в неприятную + ситуацию, если включите ACL, затем выключите + их, затем опять включите без сброса расширенных атрибутов. + Обычно, как только вы включили ACL в файловой + системе, они не должны быть выключены, поскольку получающаяся + защита файлов может быть не совместима с той, что применяется + пользователями системы, и повторное включение ACL + может подключить предыдущие списки контроля доступа к файлам, + права на которые изменены, что приведет к непредсказуемому + поведению. + + Файловые системы с включенными ACLs показывают + знак + при просмотре прав на файлы. + Например: + + drwx------ 2 robert robert 512 Dec 27 11:54 private +drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 +drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 +drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 +drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html + + Здесь мы видим, что каталоги directory1, + directory2, и directory3 + используют преимущества ACL. Каталог + public_html их не использует. + + + Использование <acronym>ACL</acronym> + + ACL файловой системы можно просмотреть + с помощью утилиты &man.getfacl.1;. Например, для просмотра + настроек ACL файла + test, может использоваться команда: + + &prompt.user; getfacl test + #file:test + #owner:1001 + #group:1001 + user::rw- + group::r-- + other::r-- + + Для изменения ACL этого файла, + вызовите утилиту &man.setfacl.1;. Выполните: + + &prompt.user; setfacl -k test + + Параметр удалит все установленные + на данный момент ACL из файла или файловой + системы. Более предпочтительный метод это использование + параметра , который оставит необходимые + для работы ACL поля. + + &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test + + В вышеприведенной команде параметр + использован для изменения записей ACL + по умолчанию. Поскольку предустановленных записей не было (они были + удалены предыдущей командой), эта команда восстановит параметры + по умолчанию и задаст приведенные параметры. Имейте ввиду, + при добавлении пользователя или группы, которых нет в системе, + на stdout будет выведена ошибка + Invalid argument. + + + + + + + + Tom + Rhodes + Предоставил + + + + + Сообщения безопасности FreeBSD + + Сообщения безопасности &os; + + Как многие и высококачественные операционные системы, &os; + публикует Сообщения безопасности (Security + Advisories). Эти сообщения обычно отправляются по почте + в списки рассылки, посвященные безопасности и публикуются + в списке проблем только после выхода исправлений к соответствующим + релизам. В этом разделе разъясняется, что такое сообщения безопасности, + как их читать и какие меры принимать для исправления системы. + + + Как выглядит сообщение? + + Сообщение безопасности &os; выглядит подобно сообщению ниже, + взятому из списка рассылки &a.security-notifications.name;. + + ============================================================================= +&os;-SA-XX:XX.UTIL Security Advisory + The &os; Project + +Topic: denial of service due to some problem + +Category: core +Module: sys +Announced: 2003-09-23 +Credits: Person@EMAIL-ADDRESS +Affects: All releases of &os; + &os; 4-STABLE prior to the correction date +Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) + 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) + 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) + 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) + 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) + 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) + 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) + 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) + 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) +&os; only: NO + +For general information regarding FreeBSD Security Advisories, +including descriptions of the fields above, security branches, and the +following sections, please visit +http://www.freebsd.org/security/. + +I. Background + + +II. Problem Description + + +III. Impact + + +IV. Workaround + + +V. Solution + + +VI. Correction details + + +VII. References + + + + + Поле Topic показывает в чем именно + заключается проблема. Это обычно введение в сообщение + безопасности, упоминающее утилиту, в которой возникла + ошибка. + + + + Поле Category относится к затронутой части + системы и может быть выбрана из core, + contrib, или ports. + Категория core означает, что + уязвимость затрагивает основной компонент операционной системы + &os;. Категория contrib означает, что + уязвимость затрагивает программы, предоставленные проекту + &os;, например sendmail. Наконец, + категория ports означает, что уязвимость + затрагивает программное обеспечение, доступное из коллекции + портов. + + + + Поле Module указывает на местоположение + компонента, например sys. В этом примере + мы видим, что затронут модуль sys, + следовательно, эта уязвимость относится к компоненту, + используемому в ядре. + + + + Поле Announced отражает дату публикации + сообщения безопасности, или его анонсирования. Это означает, + что команда обеспечения безопасности убедилась, что проблема + существует и что патч помещен в репозиторий исходных текстов + &os;. + + + + Поле Credits упоминает частное лицо или + организацию, обнаружившую уязвимость и сообщившую о ней. + + + + Поле Affects дает информацию о релизах + &os;, к которым относится данная уязвимость. Для базовой + системы, просмотр вывода команды ident + для файлов, затронутых уязвимостью, поможет определить + ревизию. Номер версии портов приведен после имени порта + в каталоге /var/db/pkg. Если система + не синхронизируется с CVS репозиторием + &os; и не пересобирается ежедневно, высок шанс, что + она затронута уязвимостью. + + + + Поле Corrected показывает дату, время, + смещение во времени и релиз, в котором исправлена ошибка. + + + + Поле &os; only показывает, существует + ли эта уязвимость только в &os;, или затрагивает и другие + системы. + + + + Поле Background дает информацию именно + о той утилите, для которой выпущено сообщение. Как правило + информация о том, зачем утилита присутствует в &os;, для + чего она используется, и немного информации о том, как + появилась эта утилита. + + + + Поле Problem Description дает более + глубокие разъяснения возникшей проблемы. Оно может включать + информацию об ошибочном коде, или даже о том, как утилита + может быть использована для создания бреши в системе + безопасности. + + + + Поле Impact описывает тип воздействия, + который проблема может оказать на систему. Это может быть + все, что угодно, от атаки на отказ в обслуживании до + получения пользователями дополнительных привилегий, или + даже получения атакующим прав суперпользователя. + + + + Поле Workaround предлагает тем, + системным администраторам, которые не могут обновить систему, + обходной путь решения проблемы. Он может пригодиться при + недостатке времени, отсутствии подключения к сети или по + массе других причин. В любом случае, к безопасности нельзя + относиться несерьезно, и необходимо либо применить указанный + обходной путь, либо исправить систему. + + + + Поле Solution предлагает инструкции по + исправлению затронутой системы. Это пошаговое руководство, + протестированный метод восстановления безопасности системы. + + + + Поле Correction Details показывает + ветвь CVS (имя релиза с точками, замененными + на символы подчеркивания). Здесь также показан номер ревизии + каждого файла из каждой ветви. + + + + Поле References обычно упоминает + другие источники информации. Это могут быть веб страницы, + книги, списки рассылки и группы новостей. + + -