За кулисами Linux Kernel Archives

Проект Linux Kernel Archives, наверное, лучше всего известен своим веб-сайтом, расположенным по адресу kernel.org. Здесь всегда можно найти самый свежий релиз ядра, патчи производства самых известных Linux-хакеров, а также зеркала других популярных свободных и open-source-проектов. Множество людей со всего мира с удовольствием обращаются к этому ресурсу, не сильно задумываясь о том, сколько усилий было положено на его создание и поддержку.

В одном из недавних сообщений Linux Kernel Mailing List Питер Энвин немного рассказал об изменениях, произошедших в инфраструктуре, обслуживающей kernel.org.

Hewlett-Packard проспонсировала приобретение новых 4-процессорных серверов (на основе Opteron), каждый из которых обладает 24 гигабайтами оперативной памяти и 10 терабайтами дискового пространства. Компания Internet System Consortium Inc. предоставила доступ к сети – две независимых площадки с гигабитным подключением. Это PAIX в Пало-Альто и e200paul в Сан-Франциско. Питер Энвин, Натан Ларедо и Крис Кук в свою очередь, как всегда, предоставили проекту собственное время и знания. KernelTrap побеседовал с Питером Энвином на темы, связанные с историей Linux Kernel Archives.

начало

Питер Энвин работает с Linux Kernel Archives практически с самого начала существования этого проекта. Когда Линус Торвальдс покупал свой первый компьютер, на котором он и начинал создавать Linux, в одиночку потянуть такую покупку сразу он не мог. Кстати говоря, для своего времени это была мощная тачка: PC с 4Mb RAM и 33 MGz процессором. В результате он заплатил часть из необходимых для этого $3500 сразу, а оставшееся должен был выплатить за три года. Где-то через год, когда ядро Linux начало постепенно становиться на ноги и сформировалось первое сообщество пользователей, Питер организовал онлайновую кампанию по сбору средств. Собрав почти $3000, удалось полностью погасить кредит Линуса. После того, как Линус окончил Хельсинкский университет, Питер пригласил его в Калифорнию поработать на Transmeta, где сам Питер уже был благополучно трудоустроен. В результате это событие стало датой рождения Linux Kernel Archives. «Я начал заниматься kernel.org с момента его возникновения в 1997-м» - поясняет Питер.

Вначале архив проживал на обычном PC, который работал под Linux и был подключен к интернету посредством трансметовского T1. Данная машина служила Линусу локальным сервером. Доменное имя «kernel.org» было выбрано, потому что к этому времени все имена типа «linux.домен» уже были заняты. Сразу было решено не использовать домен Transmeta, чтобы не создавать ложное впечатление о том, что Linux якобы принадлежит этой компании. «Kernel.org был чем-то вроде запасного варианта, которым мы, в итоге, и воспользовались. Этот выбор себя вполне оправдал, поскольку сегодня это имя уже сильно срослось с проектом» - рассказывает Питер.

второе поколение

Исходный PC был заменен в 1998-м машиной с двумя PII-350, которую предоставила VA Linux Systems (теперь – VA Software). В это же время компания Globix предоставила площадку для сервера и 100 мегабитный линк в центре обработки данных в Санта Клара. Через несколько лет сайт проекта стал уверенно потреблять такое количество трафика, что, как выразился Питер, отношения явно стали натянутыми. В 2000-м, когда для
телекоммуникационной индустрии настали тяжелые деньки, Globix решила затянуть пояса потуже. Как результат, квартирантов-линуксоидов убедительно попросили убираться на все четыре стороны.

третье поколение

В этот неприятный период с нашими героями связался Пол Викси из ISC Incorporated и предложил место на принадлежащей ISC площадке в PAIX (Пало- Альто). «Для нас это была настоящая мечта», говорит Питер, «Мы могли разделить 100-mbit канал всего с несколькими бэкбонами. Я связался по e- mail с Полом Викси и попытался разузнать, что именно ISC сможет предложить для kernel.org. Пол продемонстрировал впечатляющий список проектов, которым они уже предоставили хостинг, и пояснил, что ISC, являясь общественной организацией, часто занимается поддержкой подобных проектов. Поскольку деятельность Linux Kernel Archives близка к задачам этой организации, мы способны помочь друг другу в решении собственных задач». Как говорил потом Пол, «С Питером очень приятно работать, а kernel.org стал одним из самых крупных проектов, с которыми мы сотрудничаем. Мы рады, что наша компания ассоциируется с этим проектом. ISC полагает, что такая деятельность оказывает влияние на всю индустрию». Пол Викси также отдельно поблагодарил своего друга Дэрила Джонса (SMRN), который оказывает финансовую поддержку kernel.org в Сан-Франциско.

В 2001-м Hewlett-Packard впервые помогла проекту Linux Kernel Archives техникой. Это был ProLiant DL380G2 (Dual Pentium III 1.1 GHz). «У этой машины было шесть гигабайт RAM и терабайт на дисках. Нам тогда такая мощность казалось избыточной. Однако ISC вскоре расширила канал для kernel.org до гигабита, то есть это было больше, чем сервер мог реально обслужить. После приличной работы по настройке системы мы смогли освоить 600 мегабит. Это ограничение обусловлено тем, что для большего количества данных 6 гигабайт памяти уже было недостаточно, поэтому приходилось задействовать диски, производительность которых и ограничивала потолок производительности всей системы в целом» - рассказал Питер.

Обслуживание HTTP и FTP не требовало больших процессорных ресурсов, однако со временем объемы rsync-трафика, с которым работал сервер, продолжали расти, а такой трафик чувствителен именно к процессору. «Мы постепенно приближались к тому моменту, когда нам уже хватало канала, но процессор начинал захлебываться» - пояснил Питер. Средняя загрузка процессора росла, периодами достигая полной.

четвертое поколение

Становилось ясно, что без нового апгрейда проекту придется туго. Питер начал обдумывать подготовку просьбы к Hewlet-Packard о новом оборудовании. Однако он не успел предпринять эти шаги – Hewlett-Packard его опередила. С Питером связались представители корпорации. Их предложения можно вкратце передать примерно так «Парни, мы тут заметили, что у вас в последнее время наклевываются проблемы в работе проекта, скажите, что вам надо для полного счастья?». Питер попросил о технической поддержке.

За последующие две недели был составлен список оборудования, которое Питер хотел бы видеть в распоряжении kernel.org и вскоре начались поставки. Питер по этому поводу заметил: «Hewlett-Packard обслужила нас по самому высшему разряду. Они были просто великолепны!».

Мэтт Таггард, представляющий лабораторию R&D из состава хьюллет-паккардовской Open Source & Linux Organization, отмечает, что HP – большая корпорация и помощь для kernel.org приходила от различных ее подразделений. «В Hewlett-Packard достаточное количество людей, понимающих роль kernel.org и ту пользу – как прямую, так и косвенную, которую этот проект приносит клиентам корпорации. В этот раз поддержка пришла от нашей лаборатории (Hewlett-Packard Open Source and Linux Operation R&D Lab), но ранее она оказывалась и другими подразделениями, например Industry Standard Server Division (это те парни, которые делают ProLiant’ы). IT-подразделения Hewlett-Packard тоже используют Linux и часто прибегают к услугам kernel.org, поэтому поддержка проекта для них более чем полезна».

Когда речь зашла о причинах, по которым Hewlett-Packard помогает kernel.org, Мэтт пояснил, что когда у компании есть такая возможность, она всегда старается поддерживать свободные и open-source проекты. Объясняется это просто. Возьмем, к примеру, ситуацию, когда компании надо быстро распространить какое-либо исправление для программного обеспечения к своему оборудованию. Для этого проще работать на уровне kernel.org, а не пытаться распространять исправления самостоятельно, поскольку не факт, что получится охватить всех клиентов. Предоставить kernel.org нужное оборудование в данном случае выгоднее, чем прилагать немалые усилия по созданию собственной системы.

У Питера было два главных требования к новому оборудованию: 64-разрядные процессоры и два одинаковых сервера для удобства их обслуживания и исключения простоев. Новые серверы, которые предоставила Hewlett-Packard – это четырехпроцессорные ProLiant DL585, оснащенные 2-ядерными Opteron, 24Gb RAM и 10Tb дискового пространства в массивах MSA-30. Новые машины, по словам Питера, способны держать практически все часто запрашиваемые файлы в оперативной памяти – именно это было причиной, по которой он просил именно 24Gb памяти.

Один сервер проекта находится в Сан-Франциско, второй – в PAIX (Пало-Альто). Начиная с 9 апреля 2005 года, новые серверы действуют в рабочем режиме. Каждый из них способен обработать гигабитный трафик, хотя проверить это утверждение на практике пока еще не удалось. Загрузка CPU, как и ожидалось, упала до весьма малых значений.

Каждый сервер размещен на собственной площадке и подключен к Интернету посредством гигабитного оптоволоконного канала. В сообщении рассылки Linux Kernel Mailing List Питер подвел итог проделанной работе: «Теперь мы ожидаем от kernel.org гораздо большей производительности. Огромное спасибо Hewlett-Packard за новое оборудование и спасибо ISC за то, что они дали нам возможность учетверить занимаемое нами пространство (от 5U до 2 по 10U). Мы постараемся отработать эти авансы :)».

программное обеспечение

Серверы, обеспечивающие работу Linux Kernel Archives, всегда использовали только ядро Linux. В самом начале это было vanilla, снабженное самыми современными функциональными возможностями, которые предоставляли максимальную производительность. В последние несколько лет проект стал использовать ядра от вендоров. В настоящее время сервера работают под Fedora Core и используют ядро 2.6 от RedHat. «Все дело в обновлениях – такие ядра легче поддерживать в актуальном состоянии. Мы будем использовать такие ядра и дальше, если только они будут предлагать все критичные для нас возможности» - пояснил Питер. Linux Kernel Archives применяет ядро 2.6 начиная с 24 мая 2004 года.

Веб-страницы обслуживает Apache, обновленный до версии 2 в начале декабря 2004 года. FTP работает с помощью пакета vsftpd, который 26 мая 2004 года заменил в этой роли proftpd. «Мы не пытаемся оригинальничать, поскольку чересчур хитрые комбинации потом не так просто поддерживать» - поясняет Питер. «Единственный нестандартный момент – это noatime-монтирование файловой системы. Это означает, что при операциях чтения атрибут atime (access time) файлов не изменяется. Результат – почти вдвое сниженная нагрузка. Кроме этого, везде, где это только возможно, используется системный вызов sendfile. Он обычно значит, что мы берем некий файл и отправляем его на конкретный TCP-сокет. Это 99 с копейками процентов того, чем мы тут занимаемся, таким образом, применение sendfile для нас очень важно».

зеркала

Системой зеркал Linux Kernel Archives занимается Киз Кук. Как рассказывает Питер, данная система была создана в тот период, когда kernel.org использовал канал Transmeta, который частенько оказывался перегруженным. Несколько сайтов с хорошими каналами предложили свою помощь. В результате, система зеркал вскоре была оформлена. Каждый такой сайт соблюдает основные правила проекта, а ссылки на них предоставляет kernel.org. Как говорит Питер, «С нами работает чуть больше сотни сайтов и это число остается практически неизменным, хотя сами сайты в списке, само собой, могут меняться». Когда kernel.org использовал один сервер, в периоды его обслуживания зеркала испытывали повышенную нагрузку. В современной конфигурации ограничения по каналу и процессорной мощности сняты, что позволило Питеру заметить, что если вдруг система зеркал внезапно исчезнет, то на работе проекта это никак не отразится. С другой стороны, система зеркал весьма полезна для пользователей за пределами Северной Америки.

другие сервисы

Kernel.org предлагает и ряд дополнительных сервисов. Например, Linux Kernel Mailing List работает на сервере с именем vger. Как бы то ни было, эта машина физически никак не относится к Linux Kernel Archives. Питер поясняет, что первоначально в Финляндии существовала рассылка Linux Activist. Через некоторое время на смену этому проекту пришел Linux Kernel Mailing List, который работал с помощью Majordomo. Его администрировал Дэвид Миллер (Университет Рутгера). Когда Дэвид перешел на работу в RedHat, сервер переехал вместе с ним. Не всем понравилось, что Linux Kernel Mailing List теперь находился в домене redhat.com. Чтобы разобраться с этой ситуацией, Питер предложил: «Если людям это понравится, пусть будет vger.kernel.org – нам не трудно сделать именно так». В итоге, в то время как сам сервер физически находится у RedHat, он является частью домена kernel.org. «Мы судим по его функциональному назначению, а не по его местоположению» - поясняет Питер.

Bugzilla.kernel.org – еще один пример сервера домена kernel.org, который находится на внешней площадке. В данном случае сервер поддерживает OSDL. Питер объясняет это следующим образом: «Так вышло благодаря предложению Линуса Торвальдса и общей договоренности разработчиков ядра – мы решили включить его в домен kernel.org».

трафик

Нормальная загрузка канала kernel.org составляет порядка 150-200 мегабит в секунду. Это в периоды, когда, по выражению Питера, не происходит ничего экстраординарного. «К нашему счастью, тестовые релизы нас совершенно не касаются» - добавляет он. Данная ремарка относится к –prc и –rc ядрам, спрос на которые не оказывает влияние на работу серверов и не сказывается на требованиях к каналу.

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

«Что действительно влияет на загрузку канала, так это релиз какого-нибудь дистрибутива, зеркало которого мы держим у себя». Это, например, относится к Fedora. «Ядро – это что-то порядка нескольких десятков мегабайт, в то время, как Fedora – это несколько гигабайт».

Отвечая на вопрос о просмотрах логов доступа к серверам, Питер объяснил, что, несмотря на то, что они периодически получают подобные предложения от различных заинтересованных лиц, они никогда не предоставляют таких сведений из соображений безопасности своих пользователей. «Мы разрешаем доступ к логам только для тех людей, которые тесно участвуют в работе над Linux. Это люди, которых мы хорошо знаем». Вопрос о доступе к логам в анонимном режиме поднимался, однако сейчас это не является первоочередной задачей. «Мы это обсуждали, однако решение данной задачи в основном упирается в недостаток времени».

доска почета

В настоящее время «штат» kernel.org состоит из трех человек – все они занимаются проектом на добровольной основе в свое личное время. Это Питер Энвин, Натан Ларедо и Киз Кук. Питер работает в Orion Multisystems, в проекте же отвечает за общую архитектуру, поддержку доступа разработчиков для загрузки патчей, а также за связи с общественностью. Натан также является сотрудником Orion Multisystems, в kernel.org занимается системным и серверным ПО, а также веб-страницами. Постоянное место работы Киза – OSDL. Повседневная администраторская работа выполняется тем, кто возьмется за нее первым.
Когда Линуса Торвальдса спросили о Linux Kernel Archives, он ответил, что счастлив положиться в этой работе на команду проекта kernel.org. «Мне практически не пришлось даже пальцем о палец ударить для поддержки kernel.org, которая ведется просто великолепно. Это просто замечательно во- первых для меня – я далеко не трудоголик, - а во-вторых - для kernel.org, поскольку когда дело доходит до системного администрирования, я настоящий дилетант. Единственное, что я могу сказать, это спасибо вам, парни, за ваш труд! Спасибо Питеру и всем вовлеченным в работу людям!». Ходили разговоры о необходимости создания постоянного наемного штата, который бы занимался поддержкой kernel.org. Однако в силу различных причин этого так и не произошло. Как поясняет Питер, тогда пришлось бы искать постоянного спонсора, который бы за все это платил. Найти такого спонсора реально, однако такие поиски сами по себе требуют чересчур много времени и усилий. Есть и другие причины. По словам Питера, «Работать с Hewlett- Packard и ISC действительно приятно. На эти задачи у нас уходит не так много времени. В то же время они очень внимательны к нашим нуждам, но это внимание, тем не менее, не перерастает в навязчивость».

Официально сайт kernel.org принадлежит некоммерческой организации Kernel Dot Org Organization Inc., которая была основана в 2001 году. Тем не менее, whois сообщает, что доменное имя принадлежит Transmeta Corporation. Питер в настоящее время работает с Transmeta по вопросу перерегистрации имени. Изначально все эти события происходили еще в 2001-м, однако дело затормозилось из-за некоторых шероховатостей с Transmeta, кроме того, эта проблема не входит в число первоочередных задач проекта, что и обусловило в итоге такую задержку.

Идея некоммерческой организации возникла по той причине, что потребляемый kernel.org трафик весьма значителен и, следовательно, дорог. Как поясняет Питер, «Если мне скажут, что наш трафик стоит порядка миллиона долларов в год, то я не удивлюсь. Это внушительная сумма и если нам вдруг придется искать другого ISP, то потенциальный спонсор должен быть готов потратить такие деньги. Сейчас мы работаем с ISC и нам бы хотелось продлить наше сотрудничество как можно дольше. У нас действительно великолепные отношения».

KernelTrap.org, перевод Алексея Кутовенко.
Опубликовано: "Сетевые решения"
Оригинал:  http://www.linuxsit.com/2283.html

Один день из жизни IRC-канала #apache или как заставить сервер работать быстрее

Эта статья – часть цикла публикаций, основанных на обсуждениях, ведущихся на IRC-канале #apache.
Для справки: #apache – это IRC-канал, действующий в сети irc.freenode.net. Если вы желаете подключиться к нему, вам потребуется установить IRC-клиент (например, XChat, MIRC или bitchx).
Желаете узнать, как ускорить работу вашего web-сайта? Советы Рича помогут вам повысить производительность своего сервера.

для затравки

Я написал этот материал во время OSCON. Сейчас утро, пятница. Я должен был сдать статью в четверг вечером. Поэтому благодарю редактора /* впервые текст был опубликован на ONLamp.com – прим. ред. СР */ за понимание и, перефразируя Дугласа Адамса, приведу парочку мудрых слов от fajita:
<DrBacchus>fajita: сроки
<fajita>Самое замечательное качество всех сроков – это тот свист, с которым они пролетают мимо нас.
Итак, сегодня мы обсуждаем довольно типичный вопрос, который возникает по несколько раз на неделе:

<Quixote>Как заставить мой сервер работать быстрее?

Как вы догадываетесь, ответы могут быть самыми разными. Они зависят в первую очередь от контента, который вы держите на своем веб-сервере и тех настроек сервера, которые вы уже делали самостоятельно. Таким образом, подойти к решению данного вопроса можно с разных сторон. В связи с этим, вначале озвучу факт, который может вас определенным образом заинтересовать: на сайте Apache есть документ, некоторым образом связанный с освещением данной проблемы. Его можно найти по адресуhttp://httpd.apache.org/docs-2.0/misc/perf-tuning.html.Поэтому мы начнем с другого вопроса:

<Quixote>Как мне измерить производительность сервера?
<DrBacchus>fajita: Бенчмарками
<fajita>Некоторые доступные варианты – ab, flood, jmeter, daiquiri, siege

Измерение производительности – скользкое дело, поскольку измерить именно то, что надо, удается весьма редко. Обычно требуется узнать, как система будет вести себя в реальной ситуации. Большая часть измерительных инструментов пытается имитировать (в определенной степени) именно такой сценарий, но это всегда получается в определенном приближении, и полученные данные никогда полностью не совпадают с реальностью. Как только вы поймете, что результаты измерений и проза жизни – вещи разные, эти инструменты станут полезными в ходе работы над ускорением вашего сервера.
Предложенные fajita программы распространяются свободно и обладают различным уровнем функциональности. Я не собираюсь посвящать данную статью рассказу о них, мы будем рассматривать только ab, поскольку он поставляется вместе с Apache и представляет собой удобную стартовую позицию для измерений производительности.
Познакомиться с другими пакетами вы можете, обратившись к следующим ресурсам:
- Flood -http://httpd.apache.org/test/flood/.
- JMeter -http://jakarta.apache.org/jmeter/index.html.
- Daiquiri -http://www.omniti.com/~jesus/projects/daiquiri.README.
- Siege -http://joedog.org/siege/.
Итак, давайте немного поговорим об использовании ab.
Ab – это простой инструмент измерения производительности. Не впадайте в заблуждение насчет того, что он пытается каким-либо образом симулировать реальную ситуацию. Тем не менее, он полезен для экспериментального фиксирования разницы в производительности при изменении настроек сервера. Ab многократно запрашивает URL, а затем сообщает некоторую статистику о транзакции.

ab -n 1000 -c 10 >http://localhost/index.html

А вот часть результата выполнения этой команды:

Concurrency Level: 10
Time taken for tests: 2.303 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 253260 bytes
HTML transferred: 12060 bytes
Requests per second: 434.22 [#/sec] (mean)
Time per request: 23.03 [ms] (mean)
Time per request: 2.30 [ms] (mean, across all concurrent requests)
Transfer rate: 109.97 [Kbytes/sec] received

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

DNS

Избегайте обращений к DNS когда это только возможно. Это тормоз, который вам не подвластен. DNS-преобразования требуют ровно столько времени, сколько они требуют. Следовательно, вам необходимо запретить Apache их использование.
Мы можем повлиять на данную ситуацию в двух точках: при контроле доступа и при записи логов.
Если для контроля доступа, основанном на адресе клиента, вы используете в своем конфигурационном файле директивы allow from или deny from, старайтесь использовать не имя хоста, а IP-адрес клиента, которого вы желаете пропустить (или отвадить). Когда вы используете имя хоста, Apache приходится запрашивать DNS для того, чтобы выяснить, пришел ли запрос от обозначенного хоста.
В конфигурационном файле присутствует директива HostNameLookups. Если она установлена в Off (по умолчанию), Apache будет помещать IP-адрес клиента в лог. Если она установлена в On, то в лог пойдет имя хоста.
Не делайте этого.
Если вы заставите Apache обращаться к DNS при каждом запросе клиента, производительность сервера неизбежно упадет. Кроме того, Apache будет запускать большее количество дочерних процессов, поскольку его процессы будут тратить время на обращение к DNS.

файлы .htaccess

Если говорить кратко - вы должны избегать использования файлов .htaccess насколько это только возможно. Их применение ведет к очень большим потерям в производительности. Для этого есть несколько причин.
Во-первых, Apache вынужден обращаться к файлам .htaccess каждый раз, когда поступает запрос к каталогу ресурса. Файлы .htaccess не кэшируются и вносимые в них изменения вступают в силу немедленно. Следовательно, Apache необходимо каждый раз проверять этот файл, что означает его открытие, чтение и парсинг при каждом запросе.
И это еще не все! Поскольку файлы .htaccess применяются и к подкаталогам, Apache придется тоже их проверить. Если есть еще один уровень вложения – то проверить и его, и так далее, до тех пор, пока не будет достигнут тот уровень, где заканчиваются полномочия .htaccess.
Что это означает? А то, что каждый запрос к определенному каталогу генерирует 2, 3, 4 и т.д. запроса на доступ к файловой системе. Даже если в этих каталогах нет файлов .htaccess, Apache все равно будет их там искать.
Мораль проста: установка AllowOverride None везде, где только можно. Если использование .htaccess все-таки необходимо, активируйте эту функцию только для конкретных каталогов. Еще лучше будет поместить соответствующие директивы в httpd.conf.
Да, есть случаи, когда файлы .htaccess полезны. Я только полагаю, что они встречаются не так часто, как считают некоторые товарищи.

Content Negotiation

Content Negotiation – это возможность использования настроек браузера клиента для предоставления ему определенной языковой версии ресурса (если есть несколько таких вариантов). Это прекрасная возможность, однако, в плане требуемых ресурсов производительности она обходится довольно дорого. Не включайте ее, если она вам не нужна. На практике это означает удаление директивы MultiViews из раздела Options вашего конфигурационного файла.

другие ресурсы

Приведенный список мер, само собой, не является абсолютно полным. Много интересных сведений можно почерпнуть в ходе изучения документации на веб-сайте Apache. Смотритеhttp://httpd.apache.org/docs/misc/perf-tuning.htmlдля Apache 1.3 иhttp://httpd.apache.org/docs-2.0/misc/perf-tuning.htmlв случае Apache 2.0.
Однако наибольшее количество ошибок совершается в рассмотренных нами ситуациях, поэтому данная статья – хороший начальный пункт для начала дальнейшего поиска.
Другие вещи, требующие вашего внимания – это mod_deflate и mod_file_cache.
Если вы пользуетесь Apache 1.3, то вам потребуются соответствующие аналоги: mod_gzip и mod_mmap_static.
Если вы применяете CGI-программы, написанные на Perl, то вам следует уделить внимание mod_perl (perl.apache.org).
Ну и, конечно, обращайтесь на #apache c дополнительными вопросами.

Rich Bowen, перевод Алексея Кутовенко.
Опубликовано: "Сетевые решения"
Оригинал:  http://onlamp.com/pub/a/apache/2004/02/26/apacheckbk.html

Впечатления от работы с ipfilter под GNU/Linux

Большую часть десятилетия пользователи BSD, OpenBSD, NetBSD, Solaris и IRIX для построения межсетевых экранов и защиты индивидуальных систем от сетевых атак использовали программу ipfilter, написанную Дэрреном Ридом (Darren Reed). Теперь, после релиза ipfilter 4.1.1, GNU/Linux появилась в списке поддерживаемых платформ.
Несмотря на то, что GNU/Linux уже на протяжении определенного времени располагает собственными встроенными технологиями фильтрации пакетов (iptables и ipchains), возможность использования ipfilter под GNU/Linux может заинтересовать администраторов, работающих в неоднородной среде с большим количеством систем и желающих привести технологию фильтрации пакетов к единому стандарту. Повсеместное использование ipfilter определенно будет более простым решением, чем применение iptables на системах с GNU/Linux, ipfw под FreeBSD, pf для OpenBSD и ipfilter для систем Solaris.
Имея многолетний опыт использования ipfilter в частной и профессиональной деятельности, я был весьма рад возможности получить в свое распоряжение код последней версии ipfilter и посмотреть, чем конкретно он может быть полезен системе с установленной GNU/Linux. К сожалению, это было легче сказать, чем сделать.
Код сам по себе легко можно получить на веб-сайте ipfilter.
Мои главные претензии к ipfilter относятся к разбросанной документации и наличию временного лага между выходом последнего релиза и появлением соответствующей документации. Например, INSTALL-файл содержит следующий текст: «Linux is no longer supported». Даже если вы можете примириться с недостатками документации, далее вас будут ожидать некоторые более интересные вещи.
Поскольку FreeBSD 4.x изначально содержит ipfilter, его компилирование из исходников – это не то, к чему привыкли многие пользователи этой системы. Если они используют stable-ветвь, они периодически получают обновления к ipfilter, когда обновляют свои операционные системы.
Те же, кто желает обновиться до последней версии ipfilter между обновлениями операционной системы, может выбрать самостоятельную загрузку и установку ipfilter из исходных кодов. Данный процесс обычно выглядит примерно так: распаковка кода, переход в каталог с исходным кодом, легкая доработка изделия напильником путем правки по различным причинам некоторых файлов, make freebsd4 и make install-bsd. Само собой, это порядком утрированно - так сказать, высокоуровневый обзор процесса, но смысл вам должен быть ясен.
Компилирование ipfilter под GNU/Linux – пока непростая задача. Рид компилировал и тестировал ipfilter под Red Hat 9, поэтому вам, скорее всего проще будет тестировать программу именно на этой платформе. Я использую SuSe 8.2 Pro, и я испытал определенные сложности при компиляции и установке программы.
Вне зависимости от используемой вами платформы, вам придется править высокоуровневый Makefile в дистрибутиве ipfilter. Первое, что необходимо сделать – это проверить переменную LINUXKERNEL. Скорее всего, вам потребуется изменить значение этой переменной и указать местоположение исходного кода ядра вашей системы. Вам также может понадобится добавить флаг -O2 в конец строки CFLAGS, что должно определенным образом оптимизировать код – это может быть полезно, если вы планируете серьезно загрузить ваш ipfilter работой, прокачивая через него большие объемы данных. Для тестовых задач я решил не проводить оптимизацию.
Продолжая работу с Makefile, вы можете активизировать в программе так называемый «режим наивысшей производительности» (state top capability). Это позволит вам просматривать встроенные таблицы состояния в формате, подобном используемому в команде GNU/Linux top(1). Это прекрасная возможность, которая позволяет просматривать таблицы состояния практически в режиме реального времени. Для включения этой возможности вам надо проинсталлировать ncurses. Раскомментируйте строки STATETOP_CFLAGS, STATETOP_INC, STATETOP_LIB и внесите изменения, соответствующие вашей системе.
Наконец, вам необходимо решить: желаете ли вы, чтобы программа по умолчанию пропускала или блокировала проходящие через нее пакеты. Изначально пакет сконфигурирован на пропуск пакетов. Для изменения этой политики (чтобы пакеты по умолчанию блокировались), измените строку POLICY на:

POLICY=-DIPF_DEFAULT_PASS=FR_BLOCK

После того, как вы внесете все правки в Makefile, следует изменить еще два файла. Ipfilter - это фильтр пакетов с контекстной проверкой. Это значит, что вся контекстная информация должна где-то храниться. Ipfilter использует для хранения этой информации таблицу состояния (state table).
Максимальный размер таблицы состояния устанавливается при компиляции в файле ip_state.h. По умолчанию таблица состояния имеет размер, подходящий для использования в домашних условиях или в небольшой локальной сети. Для защиты более чем 20-30 хостов с помощью контекстных правил вам потребуется увеличить размер таблицы. Это делается для того, чтобы избежать остановки выполнения программы после полного заполнения таблицы. Если вы планируете построить межсетевой экран с помощью ipfilter для защиты сотен и сотен хостов, вам также надо изменить файл ip_hat.h для увеличения размера таблицы NAT. Поскольку я тестировал ipfilter с использованием небольшого количества компьютеров, я решил оставить в обоих файлах значения по умолчанию.
Вкратце описанный здесь процесс сборки/инсталляции ipfilter предполагает наличие файла ipfboot, находящегося в подкаталоге Linux/. Так или иначе, этот файл не был включен в дистрибутив, и я написал его самостоятельно. Файл ipfboot – это простой chkconfig-совместимый shell-скрипт, который запускает и останавливает сервис. Если вы загрузили готовый файл или изготовили собственный, не забудьте поместить его в подкаталог Linux/, где находится распакованный код, иначе компиляция закончится неудачей. Затем мне некоторое время пришлось править код и build-файлы.
Когда все это будет сделано, вы готовы к компиляции программы. Используйте следующую последовательность команд:

make linux
make install-linux

Вы можете получить предупреждение об использовании GNU-версии make. Не обращайте на него внимания и продолжайте. Если все прошло, как планировалось, вы сможете отыскать в своей базе данных RPM установленный пакет ipfilter.
Итак, вы получили установленную программу: что дальше? Дальше потребуется написать некоторый набор правил. Большинство правил ipfilter выглядит примерно так:

pass in quick on eth0 proto tcp from any to 172.19.3.3/32 port = 80 flags S/SA keep state keep frags
block in quick on eth0 proto tcp/udp from any to any port = 137
pass out on eth0 proto tcp/udp from 172.19.3.3/32 to any keep state keep frags
pass out quick on eth0 proto icmp from 172.19.3.3/32 to any keep state keep frags
Приведенные правила весьма бесхитростны. Первая строка разрешает входящий TCP-трафик к IP-адресу 172.19.3.3, порт 80 на адаптере Ethernet eth0. Оно отслеживает состояние соединения (keep state), но создает запись состояния только в том случае, если в пакете установлены корректные флаги S/SA. Мы также отслеживаем фрагменты (keep frags) пакетов, которые из-за своего размера были разбиты на части по пути к нам. Мы теперь отслеживаем состояние соединения, поэтому, когда пакеты идут к конечному пользователю (или серверу) или от него, эти пакеты не проходят проверку правилами, если они соответствуют ожиданиям таблицы состояния. Проверка пакетов прекращается, как видно выше из примера, как только они совпадут с правилом.
Вторая строка блокирует входящий TCP/UDP-трафик, приходящий откуда угодно, порт 137. Это может быть полезным для защиты Windows-систем или просто для предотвращения засорения ваших логов большим количеством NBT-пакетов.
Третья строка разрешает исходящий TCP/UDP-трафик от 172.19.3.3. В этом случае состояние также сохраняется, что означает, что исходные пакеты определены как часть этого состояния соединения, не проходящего через набор правил.
Четвертая строка разрешает исходящий ICMP-трафик. Некоторые ребята забывают, что ICMP – это протокол, отличный от TCP и UDP и что они должны явно разрешить его прохождение через межсетевой экран, если они желают его использовать.
Очевидно то, что приведенный набор правил не является полным или наилучшим. Некоторые онлайновые ресурсы разбирают процесс составления правил куда более подробно, чем я собираюсь сделать здесь. Дабы избежать ненужного дублирования великолепных работ, я попрошу вас обратиться к первоисточникам, если вы заинтересованы в составлении собственного набора правил ipfilter.
Используя свой опыт работы с ipfilter, я решил создать небольшой специальный набор правил для того, чтобы немного протестировать работу пакета. К сожалению, через несколько секунд после запуска ядро моей системы выдало ошибку. Это мне не понравилось, и я попробовал еще раз, на этот раз с runlevel 3. Еще один сбой ядра.
Несколько новых экспериментов и новых перезагрузок выявили, что использование возможностей keep state режима ipfilter гарантирует появление неприятностей с ядром. Поэтому я переписал свой тестовый набор правил, удалив из него все контекстные правила. Теперь ipfilter должен был действовать как простой фильтр пакетов. Это решило проблему, и система опять стала устойчивой.
Некоторые проведенные тесты показали, что действующий ipfilter оказывает незначительное воздействие на скорость работы сети. Копирование файла размером около 450 Mb с помощью scp практически не повлияло на скорость сети, но вызвало некоторое увеличение загрузки CPU. Ipfilter не оказал никакого влияния на работу NFS как в случае входящих сетевых запросов, так и Web- и DNS-сервисов.
Теперь, располагая стабильной системой, я был готов опробовать работу ipfilter с NAT. Я поставил систему с работающей FreeBSD за фаерволл, построенный на основе ipfilter для GNU/Linux и настроил правильную адресацию. Затем я написал свои правила для NAT.
Большинство правил ipfilter для NAT обычно сохраняются в /etc/ipnat.conf. Мой тестовый набор правил выглядел примерно так:

map eth0 192.168.1.0/24 -> 172.19.3.3/32 portmap tcp/udp auto
map eth0 192.168.1.0/24 -> 172.19.3.3/32

Директива map – это то, что устанавливает соединение в пуле NAT. В этом случае я даю ipfilter команду переписывать все соединения от сети 192.168.1.0/24 таким образом, что они как будто бы исходят от 172.19.3.3, если пакеты уходят через eth0. Директива portmap tcp/udp говорит ipfilter, что он может переписать значение исходящего порта на какое-либо выбранное ipfilter значение (auto) для TCP- и UDP- пакетов.
Директива, не включающая опцию преобразования номеров портов, работает со всеми протоколами, не являющимися TCP или UDP. Эти протоколы будут включать ICMP, GRE и подобные.
Я испытываю определенную слабость к движку ipfilter для NAT, поскольку в прошлом использовал его для выполнения некоторых нестандартных манипуляций, связанных с перенаправлением или переписыванием пакетов.
Мне очень хотелось иметь возможность добавить GNU/Linux к тем платформам, на которых я мог бы делать вещи-которые-не-рекомендуется-делать-с-NAT ;). Написав свой небольшой тестовый набор правил, а также отконфигурировав и настроив несколько систем, я загрузил набор правил для NAT и запустил несколько тестов.
К сожалению, функционирование NAT, похоже, было нарушено ipfilter, действующим под GNU/Linux. Несмотря на то, что сама по себе система межсетевого экрана могла получить доступ к различным сетевым ресурсам, любые запросы, которые проходили через систему NAT были проигнорированы целевыми серверами. Например, если я выполнял на GNU/Linux-фаерволле команду

host www.gnu.org

я получал IP-адрес веб-сервера GNU. Точно такая же команда, но выполненная на системе, находящейся за GNU/Linux-фаерволлом, приводила к DNS-таймауту.
Используя tcpdump можно было увидеть, что пакеты покидают GNU/Linux-фаерволл и достигают различных целевых серверов. Однако не было видно, чтобы какой-либо ответ поступал с целевых серверов или достигал GNU/Linux-фаерволла. Это привело меня к убеждению, что использование механизма работы с NAT в ipfilter для GNU/Linux приводит к незначительному искажению пакетов. Испорченные пакеты затем, вероятно, отбрасываются целевыми серверами.
Подведем итог: если вы не можете использовать ipfilter как средство контекстной проверки пакетов и не можете работать с NAT, то к чему же вы можете его приспособить? Допустим, вы можете запускать программу под ядром 2.4.20. Это похоже на анекдот, однако я наглядно убедился, что запуск ipfilter под 2.4.25 делает платформу даже менее стабильной, чем такая операция под 2.4.20. Я не испытывал программу совместно с ядром 2.6 и не имею сведений о таких попытках других людей. Тем не менее, испытав трудности с работой программы под 2.4.20, я бы не поставил на то, что ядро версии 2.6 должно стать ответом на проблемы со стабильностью.
Если говорить о текущем моменте, то люди, тестирующие ipfilter под GNU/Linux должны быть теми, кто ищет единый фаерволл, который может быть развернут на значительном количестве UNIX или UNIX-подобных платформ. Когда программа пройдет некоторую доводку, эти ребята могут приступить к стандартизации их программного обеспечения для построения фаерволлов.
Те же, кому необходим готовый к работе с Internet межсетевой экран для GNU/Linux, лучше присмотреться к другим программным пакетам до той поры, когда ipfilter еще немного дозреет для использования на этой платформе. Возможности ipfilter для GNU/Linux пока более чем скромны, в силу чего я не могу рекомендовать его для использования в реальной рабочей обстановке.
Как бы то ни было, не теряйте ipfilter из вида. Программа уверенно развивается и когда пакет будет немного лучше работать с GNU/Linux, он имеет все шансы стать серьезной альтернативой iptables и другим межсетевым экранам, доступным для GNU/Linux.

David Bogen, перевод Алексея Кутовенко.
Опубликовано: "Сетевые решения"
Оригинал:  http://www.linuxjournal.com/node/7595/print

Защитите свою корпоративную сеть от Kazaa

Система Kazaa обладает способностью коварно обходить фаерволлы, однако она недостаточно хитра…
Kazaa является одним из наиболее популярных используемых сейчас приложений для обмена файлами. Такие одноранговые технологии известны как peer-to-peer или P2P и позволяют пользователям искать и загружать друг у друга файлы. Основное применение, по-видимому, Kazaa находит в нарушении законов о защите авторских прав путем обмена аудиофайлами.
Собственный сетевой протокол Kazaa, известный под названием FastTrack был лицензирован разработчиками некоторых других подобных программ, в том числе iMesh и Grokster. Также доступна “очищенная” версия Kazaa, называемая KazaaLite. Существует достаточное количество других P2P-программ, но семейство FastTrack остается намного более популярным, одновременно являясь наиболее трудным объектом для блокировки фаерволлами типа линуксового iptables.
Многие сетевые менеджеры хотели бы заблокировать на своих межсетевых экранах P2P-трафик из-за создаваемой им высокой нагрузки на каналы, последствиям для безопасности, вызванными неконтролируемым обменом файлами, а также возможными судебными исками со стороны владельцев авторских прав. Это не так просто, как может показаться. Поиск в Internet информации о блокировании FastTrack-трафика с помощью iptables дал результаты типа «заблокировать 1241-й порт», «запретить в приказном порядке и сурово наказывать негодяев-нарушителей», или же «это невозможно». Блокировка порта 1214 срабатывала с ранними версиями FastTrack, но не действует на современные. Здесь требуется нечто более утонченное. Несмотря на то, что фаерволлы, построенные на базе прокси-сервисов, способны блокировать трафик FastTrack, прозрачные межсетевые экраны, например основанные на iptables, испытывают трудности, требующие решения.
Данная статья представляет новый open-source проект под названием P2Pwall, в рамках которого разрабатывается программное обеспечение, призванное предотвратить контакты P2P-клиентов из вашей сети с партнерами вне нее. Его компонент ftwall блокирует FastTrack-трафик. Будут написаны другие компоненты, предназначенные для контроля над иными P2P протоколами, и мы приглашаем вас принять в этом участие в качестве разработчиков. Данное программное обеспечение прошло тестирование со следующими FastTrack-клиентами: Kazaa 2.1.1, Kazaa 2.5, KazaaLite 2.0.2, iMesh 4.1 (build 132) и Grokster 1.7.

борьба фаерволлов с FastTrack

Современные дистрибутивы Linux включают файрвольный код ядра Netfilter и управляющие утилиты типа iptables. Данные компоненты работают совместно и позволяют применять Linux-системы в качестве простых, но эффективных фаерволлов, однако сетевой протокол FastTrack ставит перед ними ряд нетривиальных проблем:
•он не использует фиксированные номера портов;
•он не ограничен перебором небольшого количества партнеров. Он держит в кэше две сотни адресов и при своем запуске пытается соединиться со всеми. Этот список регулярно обновляется и уникален для каждой машины;
•поиск партнеров децентрализован;
•в ключевых частях протокола используется мощное шифрование.
Традиционно межсетевые экраны используют одну из двух философий. Первая – строгая, подразумевает блокировку всех портов, кроме некоторых необходимых. Вторая – либеральная и асимметричная, практически не ограничивает исходящие соединения, одновременно блокируя почти все входящие. В обоих случаях гибкий в использовании портов FastTrack отыскивает и использует законно открытые порты. Он даже может воспользоваться 80-м портом. Для блокировки FastTrack потребуется «строгая» парадигма вместе с прокси на 80-м порту, однако такой подход чересчур жесткий для сетей, в которых желательно сохранить «либеральную» парадигму, одновременно заблокировав P2P-трафик.

программа ftwall проекта P2Pwall

Проект P2Pwall призван решить эти проблемы путем предоставления набора инструментов и документации, способной сделать фильтрацию P2P-трафика реальностью. Фильтр для FastTrack под названием ftwall – это первый инструмент такого типа и доступен для загрузки p2pwall.sourceforge.net. Распространяется он на условиях GPL. Ftwall взаимодействует с iptables посредством target’а QUEUE. Он анализирует проходящие фаерволл пакеты и, основываясь на понимании характеристик протокола FastTrack, определяет, должны ли они быть пропущены или отвергнуты. Его задача – попытаться предотвратить как проникновение трафика FastTrack внутрь сети, так и попытки выйти за ее пределы.
Предназначение ftwall – блокировка внешних FastTrack соединений только при условии, что входящие уже заблокированы с помощью iptables. Многие фаерволлы уже используют полную блокировку входящих соединений с ограниченным числом разрешенных серверных соединений. Тем не менее, если FastTrack-клиент, находящийся внутри сети соединяется с партнером, находящимся за ее пределами, ответ от внешнего партнера может дойти, поскольку это будет трафик установленного соединения. Таким образом, если мы сможем положиться на штатный фаерволл в части блокировки входящих и на ftwall для исходящих соединений, то мы получим решение проблемы. В любом случае нам потребуются оба компонента.
Установка и конфигурирование ftwall заключается в загрузке исходных кодов, их компилировании и написании небольшого количества правил iptables. Сложности могут возникнуть в случае опционального улучшения логики программы, что потребует наличия в ядре модуля ip_string. Данный модуль все еще остается экспериментальным и поэтому не включается во многие дистрибутивы Linux. Если вы захотите его использовать, вам, возможно, придется добавлять его самостоятельно. Дополнительная информация по этому вопросу доступна на веб-сайте P2Pwall.

iptables и target QUEUE

Когда в качестве target’a правила iptables определено QUEUE, любой пакет, подпадающий под это правило, ставится в очередь для сбора данных приложением, например ftwall. Затем программа может отбросить пакеты или переправить их к Netfilter для дальнейшей проверки и перенаправления. Типичное правило для осуществления этого механизма выглядит примерно так:

iptables-A FORWARD -p tcp -i eth0 -dport 123 -syn -j QUEUE

Согласно этому правилу все SYN-пакеты из (внешней) сети, поступающие с eth0 и предназначенные для порта 123 на удаленном хосте сначала направляются к программе. Программа читает пакеты и возвращает свой вердикт с использованием библиотеки libpq и модуля ip_queue.
QUEUE является стандартной частью пакета iptables, поставляемого с наиболее популярными дистрибутивами. Для того, чтобы удостовериться, что этот target доступен на вашей системе, выполните команду insmod ip_queue и убедитесь, что у вас не появляется сообщение об ошибке. Подробности можно узнать в Netfilter FAQ по адресуhttp://www.netfilter.org/documentation /FAQ/netfilter-faq-4.html.

как работает ftwall

Описание работы ftwall необходимо вести параллельно с частичным разъяснением логики соединений FastTrack.
FastTrack соединяется с партнерами, используя три различных подхода: поток UDP-пакетов, параллельные TCP-соединения и более традиционную модель TCP-взаимодействия. Программа переключается между этими режимами, если считает, что ее пытаются блокировать. Ftwall старается удерживать работу клиентов в первом режиме настолько долго, насколько это будет возможно, поскольку этот режим наиболее просто определяется и позволяет построить список адресов партнеров.
При своем запуске клиент отсылает через межсетевой экран большое количество UDP-пакетов, которые могут быть распознаны по их длине и содержанию. Netfilter ставит их в очередь на обработку ftwall (Рис.1). Затем ftwall записывает адреса отправителя и назначения пакетов и подменяет ответ клиенту, чем предотвращает его вывод о том, что эти UDP-пакеты блокируются фаерволлом. В результате несколько увеличивается время работы клиента в первом режиме.

Рис. 1. Открытие соединения по UDP.

Правило iptables для формирования такой очереди (подразумевается, что eth0 - это интерфейс внутренней сети) выглядит так:

iptables -A FORWARD -p udp -i eth0 -j QUEUE

Когда FastTrack получает подмененный ответ, он пытается использовать UDP для запроса некоторой дополнительной информации и затем предпринимает попытку установить TCP-соединение с тем же адресом. Эти UDP- и TCP-пакеты пересылаются ftwall, который теперь знает, что адрес назначения имеет отношение к FastTrack и, соответственно, удаляет их (Рис.2). Другие, не принадлежащие FastTrack, UDP- и TCP SYN-пакеты возвращаются к Netfilter для дальнейшей проверки и перенаправления по назначению.

Рис.2 Другие UDP- и TCP SYN-пакеты.

Правило постановки SYN-пакетов в очередь к ftwall таково:

iptables -A FORWARD -p tcp -i eth0 --syn -j QUEUE

Клиент на протяжении некоторого времени повторяет эту последовательность UDP и SYN-пакетов – обычно (но не всегда) до тех пор, пока все известные адреса не будут испробованы хотя бы по одному разу. Это означает, что все эти адреса теперь также известны ftwall как заслуживающие отфильтровывания.
Через некоторое время клиент изменяет курс и переключается на параллельное TCP-соединение с мощным шифрованием данных. Ftwall продолжает блокировать соединения с адресами, взятыми на заметку в первой фазе. Для любых других адресов уликой, идентифицирующей их как соединения FastTrack, будет большое количество SYN-пакетов, наблюдаемых за короткий промежуток времени. Если ftwall для проведения блокировки будет полагаться исключительно на UDP-пакеты, то он потерпит неудачу, особенно если клиент в ходе первой фазы не перебрал все известные ему адреса. Решение этой проблемы – «часовая ловушка».
В этом новом режиме клиент чередует попытки TCP-соединения с адресами, уже известными ftwall, с другими, которые еще не были обнаружены (если таковые были). Ftwall сохраняет временную отметку, когда были испробованы самые последние известные адреса и блокирует все TCP-соединения от того же IP-адреса на конфигурируемый промежуток времени после этого. Каждый SYN-пакет, отправленный на известный адрес сбрасывает таймер. При условии, что эти соединения предпринимаются достаточно часто, ftwall продолжает их блокировку.
Такая логика имеет побочный эффект, заключающийся в том, что все TCP-соединения от непослушной рабочей станции, в том числе доступ к веб- и FTP-сайтам, блокируется на протяжении всего времени, когда на ней запущен FastTrack. Это может быть обосновано как допустимая мера, поскольку пользователь рабочей станции нарушает организационные правила. Как только клиентское приложение закрывается, таймер перестает обновляться и, как только он отработает свое время, TCP-соединения вновь будут разрешены. В конфигурации по умолчанию это займет две минуты.
После того, как FastTrack некоторое время проработает в этом режиме, он приходит к заключению, что параллельный способ попытки соединения вызывает проблемы и переключается в третий режим. Теперь он снижает интенсивность попыток соединения и использует более традиционный подход – пробует адреса по одному с таймаутом в несколько секунд для каждой попытки. Этот новый подход делает бесполезной с таким трудом выстроенную нами логику и клиент, в конечном счете, прорывается сквозь защиту. Это может потребовать более часа времени, но клиенты, не открывшие ранее все известные адреса, вполне могут рассчитывать в этой фазе на реальный шанс установления соединения. Как только хотя бы одно соединение будет установлено, загружается новый набор адресов, и мы оказываемся в положении ничуть не лучше того, в котором мы бы очутились, вообще не блокируя соединения в первой фазе.
Для победы над этим третьим режимом ftwall требуется больше информации, которая позволила бы определить, что FastTrack все еще используется. Один из способов - еще немного подмен. Время от времени ftwall посылает клиенту UDP-пакет, являющийся копией пакета, который сам клиент использует для открытия связи с партнером. Если FastTrack-приложение выполняется на рабочей станции, оно отвечает пакетом, который может быть легко распознан, что вызовет сброс таймера. Сравнительно небольшое количество и размер таких пробных пакетов означает минимальную нагрузку на сеть.

Рис. 3. UDP-проба статуса FastTrack.

Поскольку эти пакеты не перенаправляются на публичный адрес, а предназначены для самого фаерволла, для направления его к ftwall требуется правило iptables в цепочке INPUT. При этом используется такое правило:

iptables -A INPUT -p udp -i eth0 -j QUEUE

Это надолго удерживает клиента в оффлайне, но несколько неэффективно. Если мы выберем правильное значение таймера, отправляя эти UDP-пакеты, когда срок их существования истек ровно наполовину – этого будет достаточно для того, чтобы поддерживать такое значение таймера, которое будет удерживать клиента заблокированным.
Последний кусочек головоломки – это дополнительная подстраховка, которая, теоретически не требуется. Описанная выше логика зависит от набора распознаваемых UDP-пакетов, которые предоставляют ftwall необходимую ему информацию, однако нам стоит подумать: что случится, если эти UDP-пакеты не будут доставлены – например, если пользователь отключит передачу UDP, используя фаерволл на своей рабочей станции? В таком случае у нас нет ничего, что могло бы использоваться для определения адресов партнеров, с которыми устанавливается контакт.
Несмотря на это у нас еще остается одна возможность: проверка всех TCP-пакетов в попытке заметить фактическую передачу файлов. Использование шифрования в FastTrack ограничено подтверждением установления связи и поисками. Разделенные файлы передаются с использованием простого текстового HTTP. Заголовки HTTP-запроса включают некоторые поля, идентифицирующие пользователя FastTrack, протокол и адрес главного узла – то есть узла, предоставляющего индексную информацию. Если эти пакеты будут поставлены в очередь на проверку ftwall, это позволит выделить те, которые будут похожи на начало загрузки файла через FastTrack. Из данных, содержащихся в заголовках HTTP ftwall выделяет IP-адрес назначения и адрес главного узла и добавляет их к своему списку блокируемых адресов. Одновременно он добавляет адрес клиента к списку тех, к кому применяется политика «часовой ловушки».

обзор инсталляции

Процесс установки ftwall подробнейшим образом описан во включенном в комплект файле INSTALL, а также на веб-сайте проекта, однако давайте кратко познакомимся с основными шагами:
•загрузите исходные коды с p2pwall.sourceforge.net и распакуйте их;
•установите библиотеку libpq, если она еще не установлена. На некоторых системах, включая Red Hat 7.x и 8, это означает получение исходников и компиляцию iptables;
•скомпилируйте и установите ftwall с помощью make и make install;
•добавьте запись в каталог загрузчика для запуска ftwall;
•убедитесь, что вам доступен механизм QUEUE и добавьте его, если это не так. Большинство современных Linux-систем им уже располагают, в противном случае его можно добавить пропатчиванием и пересборкой ядра;
•создайте правила iptables в цепочках INPUT и FORWARD;
•если вы хотите задействовать опцию проверки заголовков HTTP на предмет загрузок файлов, добавьте строковый модуль к ядру и iptables. Это потребует патча и пересборки ядра;
•перезагрузитесь.

Заключение

С запущенным на межсетевом экране ftwall трафику FastTrack блокируется доступ к Internet. При условии, что ваш фаерволл также блокирует входящие соединения, ваша сеть стала «Kazaa-непробиваемой». Клиенты FastTrack в рамках вашей сети все еще остаются способными взаимодействовать между собой, но обмен файлами с внешними партнерами предотвращен.
Этот подход ограничен тем, что фокусируется исключительно на FastTrack; однако проект P2Pwall стремится расширить свою деятельность и на другие P2P-протоколы. Если вы желаете каким-либо образом принять участие в проекте, пожалуйста, пишите мне наchris@lowth.com.
Ftwall работает с FastTrack-клиентами, доступными на момент его написания. Не исключено, что протокол FastTrack в будущем претерпит изменения. В этом случае ftwall также будет нуждаться в доработке.

Chris Lowth, перевод Алексея Кутовенко.
Опубликовано: "Сетевые решения" 
Оригинал: http://nnc3.com/lj/LJ/LJ114/6945.html

Windows Services for Unix: /home, sweet /home...

Windows Services for UNIX (SFU) – это одна из попыток в сфере организации взаимодействия UNIX/Linux/Windows. SFU был призван облегчить совместную работу Windows- и UNIX-систем в части аутентификации и совместного использования ресурсов, а также облегчения переноса UNIX-приложений на Windows-серверы. Это стоило, вроде бы 99$ за клиента, но теперь предлагается бесплатно. Хотя «бесплатность» эта относительна, в чем вы убедитесь, ознакомившись с системными требованиями.
SFU состоит из установленной в качестве собственной подсистемы Windows среды Interix. Она поставляется с оболочками C, Korn и обычным набором GNU’шных утилит. В поставку также включены «древние» сервисы telnet и sendmail. Интеграция каталогов и файловых систем осуществляется через NFS (Network Filesystem) и NIS (Network Information Services). Другие оболочки и программы, например, bash, SSH и Apache доступны на веб-сайте Interop Systems.
В данной статье рассматриваются основы работы SFU, за что спасибо соавтору - Shuying Wang, способствовавшему отделению реальности от гипотез.

системные требования

SFU 3.5 работает только под Windows 2000/XP Professional и 2000/2003 Server. На сервере должен быть установлен NIS и включена поддержка Active Directory. Если у вас уже есть все эти вещи, SFU может стать полезным инструментом. Если нет, то вам предстоят существенные вложения в лицензии для сервера и клиентов (объясните, пожалуйста, с какой радости пользователи должны платить за клиентские лицензии доступа? Вы уже заплатили за сервер и за лицензии настольных Windows, а ведь обслуживание пользователей – это ключевая идея работы сервера, разве не так?).
Вашим пользователям Windows 95/98/ME крупно не повезло: SFU у них работать не будет. Windows 95/98/ME используют файловые системы FAT16/FAT32, не поддерживающие контроль доступа, который есть в NTFS и файловых системах UNIX. Кстати говоря, и в UNIX, и в Linux поддерживается широкий спектр прекрасных файловых систем и вы можете использовать любую, которая вам нравится без замены всей операционной системы целиком.
Вам потребуется порядка 20-360 мегабайт дискового пространства - это зависит от того, что вы желаете установить, и 16 мегабайт дополнительной оперативной памяти. Кроме этого – я не выдумываю – Internet Explorer. Да, это требование для установки SFU. Secure Computing, знаете ли…

координируем сервисы и пользователей
Давайте заглянем внутрь SFU. Сервис User Name Mapping – это главный инструмент, связывающий ваши Windows- и UNIX-сервисы. Это то, что позволяет пользователям получать доступ к Windows- или UNIX-ресурсам без миграции существующих пользователей NIS на Windows или пользователей Windows на NIS.
Все NFS-компоненты SFU используют сервис User Name Mapping. Он устанавливает двустороннее - «один к одному» и «один ко многим» - соответствие между UID/GID UNIX и идентификаторами групп и пользователей Windows (SID). Схема «один ко многим» позволяет установить соответствие одному идентификатору Windows несколько идентификаторов UNIX Обратного механизма нет, вы не сможете сопоставить несколько идентификаторов Windows одному идентификатору UNIX.
Администрирование сервиса User Name Mapping производится с помощью графического интерфейса или инструмента командной строкиmapadmin.По умолчанию User Name Mapping приравнивает пользователей домена Windows к пользователям UNIX с теми же именами. Администратор также может избрать схему, при которой сопоставляются пользователи с различными именами для Windows и UNIX.

совместное использование файлов и ресурсов

SFU поддерживает UNIX NFS версий 2 и 3. SFU поставляется с NFS-клиентом, сервером и шлюзом. Шлюз позволяет системам, не располагающим NFS-клиентом, получать доступ к совместным ресурсам NFS. Построенный на Windows сервер NFS поддерживает только экспорт NFS из CDFS (Compact Disc Filesystem) и NTFS (NT Filesystem). Это означает, что открывать доступ для Windows вы сможете только к компакт-дискам или файловой системе Windows NTFS, поскольку это единственная файловая система для Windows, предлагающая какой-то заслуживающий упоминания контроль целостности данных и доступа.
Предлагаются инструменты администрирования как с графическим интерфейсом, так и основанные на использовании командной строки. Закладка NFS Sharing становится доступной посредством GUI через правый щелчок по каталогу в Windows Explorer. Утилита командной строкиnfsshareдает возможность скриптового управления как из Windows-, так и UNIX-оболочек.
Для пользователя доступ к ресурсам NFS выглядит так же, как и доступ к совместным ресурсам Windows. Пользователь перемещается по сети NFS, используя Windows Explorer. Пользователь может получить доступ к ресурсам NFS как сопоставляя им буквенное обозначение диска, так и используя имена Universal Naming Convention (UNC), которые выглядят как пути UNIX, только с обратными слэшами: \server-name\share-name\directory\filename. Доступ к ресурсам NFS может быть также получен с использованием команд net или mount. Пользователи, которые располагают аккаунтами и для Windows, и для UNIX, получают одинаковые привилегии вне зависимости от того, получают они доступ к файлам с помощью NFS-клиента для UNIX или же через NFS-клиент для Windows.
Шлюз для NFS также использует сервис User Name Mapping для установления соответствия параметров доступа учетных записей Windows и GID/UID операционной системы UNIX перед перенаправлением запроса на доступ к файлу на NFS-сервер. Каждый запрос пользователя, проходящий через шлюз, надлежащим образом идентифицируется, затем имена пользователей Windows конвертируются в соответствующих пользователей UNIX перед перенаправлением на NFS-сервер. Этот процесс необходим для уверенности в том, что пользователи, получающие доступ к NFS-серверам либо напрямую с машины, располагающей клиентом для NFS, либо опосредованно, через шлюз для NFS, получат его в одинаковом объеме.
Поскольку доступ к шлюзу для совместного использования NFS предоставляется сетью, основанной на Windows, эти запросы подтверждаются проверкой прав доступа Windows, а затем посредством User Name Mapping переводятся в соответствующие пары UID/SID UNIX.

интеграция с Active Directory

Сервер NIS хранит объекты в Active Directory, который интегрирует пользователей, группы и хосты UNIX в их Windows-эквиваленты. Таким образом, администрирование пользователей и групп UNIX производится точно таким же способом, как и пользователей/групп Windows. Данными NIS можно управлять, в том числе используя такой интегрированный инструмент Active Directory, как Users and Computers. Плюс, любые пользователи, одновременно принадлежащие и к UNIX и к Windows-сетям, могут получить уникальное представление в Active Directory.
SFU включает двустороннюю (Windows-to-UNIX и UNIX-to-Windows) синхронизацию паролей, которая поддерживает локальную и доменную синхронизацию аккаунтов Windows.
Доменная синхронизация аккаунтов требует инсталляции Password Synchronization на контроллерах домена с установленной Windows 2000 или Windows 2003 Server. Запросы на изменение пароля посылаются только тем компьютерам или пользователям, которые выбраны администратором. Синхронизация по схеме UNIX-to-Windows контролируется файлом ssod.conf. Настройка синхронизации Windows-to-UNIX производится с помощью встроенного инструмента SFU Administration.
Вы можете избежать всей этой синхронизационной возни, внедрив единую регистрацию – переведя ваших пользователей UNIX NIS в Active Directory и отключив ваши серверы UNIX NIS. Microsoft предлагает для этого некоторые скрипты на Korn shell, однако будьте уверены, что вам скорее всего все равно придется вручную вносить в них многочисленные изменения. Файловые разрешения в UNIX и Windows работают по-разному. Кроме того, в UNIX регистр имеет значение, а в Windows – нет, поэтому работа с именами файлов и пользователей способна превратиться в форменный регистровый кошмар. Да еще пользователи, которые имеют несколько аккаунтов, способны доставить вам немало «приятных» минут.
Добавление SFU к сети, построенной на Windows, может стать именно тем решением, которое нужно вам для интеграции ваших UNIX-пользователей и ресурсов. В любом случае не рассчитывайте, что все заработает как по волшебству – вам потребуется знание UNIX для того, чтобы заставить это работать правильно и избежать широких брешей в безопасности. Посетите сайт Windows Services for UNIX (http://www.microsoft.com/windows/sfu/default.asp) – там вы найдете документацию и мануалы.

Carla Schroder, перевод Алексея Кутовенко.
Опубликовано: "Сетевые решения"
Оригинал:  http://www.enterprisenetworkingplanet.com/netos/article.php/3380991/Windows-Services-for-Unix-Theres-No-Place-Like-home.htm

Шифрование разделов с помощью dm-crypt и ядра серии 2.6

В феврале 2004 года Эндрю Мортеном (Andrew Morten) было объявлено о постепенном переходе от cryptoloop к более перспективному пакету - dm-crypt (http://www.saout.de/misc/dm-crypt/).Несмотря на то, что данное заявление вызвало определенное недоумение, dm-crypt был включен в стабильную ветвь ядра 2.6.4. Данная статья содержит описание процесса создания зашифрованных разделов средствами dm-crypt.
Dm-crypt предоставляет возможности шифрования для Device-mapper, который позволяет создавать новые разделы или логические диски, указывая область секторов на существующих устройствах. Данная область секторов определяется с помощью соответствующей таблицы. Dm-crypt может быть использован для прозрачного шифрования устройства с применением нового cryptoAPI ядра 2.6.
Изначально в cryptoloop для шифрования применялось устройство loopback. Dm-crypt является более изящной реализацией и предлагает значительно большую гибкость в работе. По мнению Фрувиса Клеменса (Fruwirth Clemens), поддерживающего cryptoloop, dm-crypt предпочтительнее по целому ряду причин, среди которых он называет следующие:
- dm-crypt не страшны ошибки loop.c (которых довольно много – сказывается отсутствие должной поддержки);
- dm-crypt не зависит от инструментов пространства пользователя (util-linux);
- dm-crypt использует mempool, что означает завидный уровень стабильности по сравнению с cryptoloop.
Несмотря на использование сильных криптоалгоритмов, cryptoloop представляется довольно нестойким решением, уязвимым к определенным типам атак. Слабые стороны cryptoloop подробно обсуждались на LVN.net (http://lwn.net/Articles/67216/).
Dm-crypt также использует сильные криптоалгоритмы, отличаясь улучшенным уровнем их реализации.

установка dm-crypt

Перед шифрованием любых важных данных с помощью dm-crypt, убедитесь, что у вас есть их актуальные резервные копии.
Непосредственно установка начинается с загрузки требуемых файлов. Вам потребуется свежее ядро. Подойдут версии 2.6.4 и более новые. Я рекомендую использовать хотя бы 2.6.5, поскольку на некоторых системах с ядром 2.6.4 наблюдались определенные проблемы при работе с dm-crypt. Кроме ядра загрузите Device-mapper сhttp://sources.redhat.com/dm/,а также, по желанию, hashalot (http://www.paranoiacs.org/~sluskyb/hacks/hashalot/)и скрипт установки cryptsetup.sh (http://www.saout.de/misc/dm-crypt/cryptsetup.sh).
Сконфигурируйте свое ядро, добавив к нему поддержку Device-mapper и dm-crypt, которые можно найти в Multi-device support (RAID and LVM) под обозначениями Device Mapper Support и Crypt Target Support. Вам также потребуется включить желаемый шифр в разделе Cryptographic Options.
Если вы сконфигурировали Device-mapper в качестве модуля, то, как только вы установите и загрузите новое ядро, вам потребуется активировать его с помощью modprobe dm-mod. Модуль dm-crypt при необходимости будет загружаться ядром. Добавьте команды modprobe в стартовый скрипт для всех нужных вам криптомодулей.
Device-mapper использует каталог /dev/mapper и устройство /dev/mapper/control. Для их создания запустите скрипт scripts/devmap_mknod.sh из комплекта Device-mapper. В случае успеха скрипт выдает номера (major и minor) нового узла, или же, в случае неудачи, просто завершает свою работу.
Теперь скомпилируйте и установите пакет Device-mapper. Распакуйте файлы и выполните обычную процедуру ./configure, make, make install. Это установит необходимые библиотеки и утилиту dmsetup в /sbin. Для создания и удаления устройств, получения информации о них и перезагрузки таблиц мы использовали dmsetup.
В результате выполнения комманды

dmsetup create <name>

создается устройство <name> в /dev/mapper/control. Затем dmsetup должен получить таблицу от stdin. Как вариант, вы можете предложить ему третьим параметром команды файл, содержащий требуемые данные. Таблица приобретает такой вид:

<start sector> <sector count> <target type> <arguments>
Таблица dm-crypt получает вид:

0 <sector count> crypt <sector format> <key> <IV offset> <real device> <sector offset>

Параметры <sector format> и <key> - это используемый шифр (например, AES) и ключ (в виде шестнадцатеричного числа), используемые для шифрования устройства. Вы можете просмотреть доступные шифры в checking /proc/crypto или загрузив соответствующий модуль с помощью modprobe. Значение <IV offset> обычно равно 0, за исключением особых случаев. <real device> - это предназначенное для шифрования устройство, которое также может быть обозначено как /dev/xxxx или номером в виде major:minor, <sector offset> - это указание начала зашифрованных данных на реальном устройстве.
Если это выглядит несколько непонятно, не волнуйтесь. Скрипт cryptsetup.sh делает процесс куда менее хлопотным. Для создания ключа скрипт использует hexdump и hashalot. Вы также можете обойтись без hashalot и воспользоваться опцией –h plain.
Разместите скрипт cryptsetup.sh в $PATH и не забудьте сделать его исполняемым. Если вы планируете использовать hashalot, установите его (./configure, make, make install).
Для шифрования устройства Cryptsetup.sh вызывает dmsetup с указанными вами опциями. Приведенный ниже пример настроит /dev/hdb2 для использования /dev/mapper/cryptvol1.
Первым делом отмонтируйте устройство и убедитесь в том, что файловая система не имеет ошибок, для чего запустите fsck:

umount /dev/hdb2
fsck /dev/hdb2

Теперь создайте устройство dm-crypt:

cryptsetup.sh -c aes -h ripemd160 -y -b `blockdev --getsize
/dev/hdb2` create cryptvol1 /dev/hdb2

Вам потребуется задать идентификационную фразу, которую вы затем будете использовать. В результате данных операций вы получите из /dev/hdb2 зашифрованное устройство /dev/mapper/cryptvol1, при этом будет использован алгоритм шифрования AES и hashalot, который сгенерирует ключ на основе вашей идентификационной фразы. Если вы не используете hashalot, используйте здесь опцию –h plain. Полный список опций cryptsetup можно просмотреть, выполнив cryptsetup.sh -- help.
Теперь все готово для копирования данных на новое устройство:

dd if=/dev/hdb2 of=/dev/mapper/cryptvol1 bs=4k

Перед выполнением этой команды внимательно проверьте ее правильность, поскольку она перепишет на указанном устройстве все данные. Когда команда будет выполнена, проверьте новое устройство на ошибки с помощью fsck. Если все пройдет гладко, вы можете примонтировать новое устройство

mount /dev/mapper/cryptvol1 /data

(подразумевается, что обычно вы монтируете раздел /dev/hdb2 в /data).
В случае необходимости вы сможете произвести обратное конвертирование от зашифрованного к незашифрованному состоянию, скопировав ваши данные на обычное устройство. Если вам потребуется изменить какую-либо опцию, например, зашифровать данные еще раз или поменять идентификационную фразу, вы можете перемещать данные между соответствующими устройствами. В настоящее время ведется работа над утилитой, которая позволит производить это «на лету».
Устройства, которые больше не нужны, могут быть удалены с помощью команды

dmsetup remove <name>

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

if [ -b /dev/mapper/cryptvol1 ] ; then
/usr/local/sbin/cryptsetup.sh remove cryptvol1
fi
/usr/local/sbin/cryptsetup.sh -c aes -h ripemd160 -b `blockdev --getsize /dev/hdb2` create cryptvol1 /dev/hdb2
/sbin/mount /dev/mapper/cryptvol1 /data

резюме
 Dm-crypt – это решение, которое действительно внушает доверие. Он предлагает большую гибкость в работе по сравнению с cryptoloop за счет использования Device-mapper. Уже сегодня dm-crypt обладает функциональными возможностями, сравнимыми с характеристиками cryptoloop, и его функциональность со временем будет расширяться. Несмотря на то, что полное исключение cryptoloop в ближайшем будущем из ядра представляется маловероятным, вам определенно следует обратить внимание на dm-crypt в том случае, если вы планируете использовать зашифрованную файловую систему.

Mike Peters, перевод Алексея Кутовенко.
Опубликовано: "Сетевые решения"
Оригинал:  http://archive09.linux.com/feature/36596

Sentry CD – свежий взгляд на фаерволл

Если вас вдруг посетило желание построить фаерволл на основе Linux, то совсем не обязательно связываться с большими дистрибутивами, в комплект которых не включена разве что пилочка для ногтей. Если вы не боитесь ручной работы и стремитесь получить полный контроль над своей системой, то вам следует познакомиться с Sentry Firewall CD (SFCD).

Обитает он по адресу www.sentryfirewall.com. Это гибко конфигурируемый загрузочный CD, который демонстрирует, если можно так выразиться, минималистический подход к построению фаерволла.

Системные требования SFCD также минимальны: процессор от 486-го, BIOS с возможностью загрузки с компакта, 32 мегабайта RAM (64Мб, если вы планируете запускать фаерволл/маршрутизатор/сервер DNS). Если ваша матчасть соответствует этим поистине зверским требованиям, смело отправляйтесь на веб-сайт SFCD, качайте ISO-шку посвежее и загоняйте ее на CD.

У вас есть возможность использовать для Sentry Firewall CD как собственные конфигурационные файлы (в том числе обычные для Linux-систем resolve.conf и hostname), так и инициализационные скрипты самого SFCD. Если концепция специфических скриптов вас не вдохновляет, расслабьтесь – Sentry Firewall CD основан на Slackware, известном своими простыми как сапог скриптами.

Ключевой для работы SFCD файл – это sentry.conf. Читая этот файл, SFCD получает сведения о местонахождении других конфигурационных файлов. Полный список этих файлов можно посмотреть в примере sfcd.conf, который находится на CD в каталоге SENTRY/scripts/cd-config. Еще лучше будет посмотреть этот файл перед записью диска. Для этого примонтируйте ISO-образ:

mount -o loop -t iso9660

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

dd if=SENTRY/images/ext2-144.img of=/dev/fd0

Теперь вы можете отредактировать содержимое дискеты, исходя из особенностей вашей среды. Редактирование конфигов Sentry Firewall CD – не такая уж сложная штука, как это может показаться на первый взгляд.
Второй способ – просто загрузитесь с CD и отредактируйте конфигурационные файлы. Сохраненные версии будут находиться в RAM. Чтобы записать их на дискету, используйте входящую в комплект SFCD программу /sbin/mkconfig. Эта утилита представляет собой мастер, который даст пошаговые инструкции по созданию собственного файла sentry.conf.

Никто не заставляет вас хранить конфигурационные файлы именно на дискете. Флэшка, жесткий диск и т.п. – подойдет что угодно. SFCD будет искать sentry.conf в следующем порядке: FDD – HDD – USB. Все остальные конфигурационные файлы могут быть взяты из сети по HTTP, HTTPS, FTP, SFTP или SCP. Для SFTP и SCP потребуются пароли. Возможность загрузки настроечных файлов по сети будет очень кстати, если физический доступ к фаерволлу затруднен.

Вот пример записи sfcd.conf, которая вызывает resolv.conf с помощью SCP:

resolv.conf = scp://:@192.168.1.1/configdirectory/resolve.conf

Допускается использование защищенного паролем HTTP-каталога – просто укажите имя пользователя и пароль.

так где же фаерволл?

Вам, наверное, интересно: когда же автор соблаговолит рассказать про обещанный фаерволл? Sentry Firewall CD загружает собственный фаерволл, используя файл rc.firewall. Если у вас уже есть рабочий файрволл на основе iptables, то вы можете просто скопировать содержимое его скрипта в названный файл.

Если вы планируете настраивать фаерволл с нуля, то в этом благородном деянии вам помогут некоторые встроенные инструменты Sentry CD. В каталоге /SENTRY/scripts/firewall можно найти неплохую подборку готовых скриптов на разные случаи жизни. По сути, это обычные скрипты iptables, которые вы можете отредактировать, исходя из собственных реалий. Кроме этого, на CD присутствуют написанные на PHP генераторы скриптов.

В состав SFCD также включен Webmin, который по умолчанию деактивирован. Если вы установите в файле sentry.conf значение start webmin enable, то вы сможете сгенерировать скрипты с помощью модулей Linux Firewall или Shorewall Firewall.

Sentry CD содержит массу популярных сетевых программ, среди которых apache, bind, nmap, sendmail, squid и snort. Местоположение их конфигурационных файлов прописывается в sentry.conf. Как и файлы самого SFCD, они также могут храниться на доступном сетевом ресурсе. Еще одна интересная фишка Sentry Firewall CD – возможность создания собственных CD.

Изготовить компакт с функциональностью SFCD и собственными конфигурационными файлами несложно. Просто скопируйте весь CD в каталог на своем винчестере и отредактируйте файлы, для которых вы сочтете это необходимым. Затем внесите правки в скрипт SENTRY/scripts/MK-CD/mkiso.sh и измените путь в параметре root_dir на ведущий к вашему каталогу, в который вы скопировали CD. Теперь запустите скрипт создания собственного файла sentry.iso. Записывайте болванку и наслаждайтесь результатом.

Если вы желаете использовать другое ядро, то вам потребуется изменить образ RAMDISK, который находится в каталоге isolinux. Модификация RAMDISK усложняет процесс создания собственного CD, однако возможности по подгонке продукта к вашим потребностям в данном случае становятся просто безграничными. Вы можете примонтировать и отредактировать файл initrd.img.gz или же использовать находящийся в каталоге MK-CD скрипт mkrootdisk.sh. Если вы решите поиграть с ядром таким образом, вначале обязательно почитайте в FAQ раздел RAMDISK.

Как видите, Sentry Firewall CD – это не просто фаерволл на CD. Это гибкий дистрибутив, который вы можете настроить под свои индивидуальные потребности.

Paul Virievich, перевод Алексея Кутовенко.
Опубликовано: "Сетевые решения"
Оригинал: http://www.faqs.org/docs/Linux-HOWTO/Sentry-Firewall-CD-HOWTO.html

Использование PHP в администрировании

Мои отношения с PHP с момента появления PHP3 были двойственными. Я воспринимал его как простой инструмент для решения несложных веб-задач без предварительных упражнений по установке сервера Java или перекомпиляции CGI-скриптов для разных платформ. PHP был (да и остается) простым в изучении и быстрым в развертывании решением, которое уже долгое время вполне соответствует моим запросам.

В один прекрасный день на PHP Website (www.php.net) появилось сообщение о чем-то, называемом “CLI SAPI”. Эта конструкция позволяла использовать парсер PHP без генерирования HTML и не требовала наличия Apache для доставки кода. Вместо этого CLI SAPI, грубо говоря, разрешает открыть файл, определить в нужной строке путь к PHP-парсеру – и вперед к победе. Очень похоже на Perl, Python или bash.

Поначалу я не очень-то доверял подобной технологии. Я использовал PHP для всех своих веб-проектов, одновременно решая администраторские задачи с помощью Perl. Внезапно прекрасные горизонты подернулись тучами...

Однажды я с увлечением потратил кучу времени на составление Perl-скрипта для одной машины только для того, чтобы потом обнаружить, что на ней не установлены требуемые модули Perl. Более того, их инсталляция рисковала доставить массу неприятных проблем – у меня уже был подобный опыт. Но делать было нечего, и я попытался. Через некоторое время CPAN начал ругаться, и вот тут-то я обратил внимание на то, что на этой машине уже установлен PHP, да еще со всеми необходимыми мне дополнениями. Через десять минут мой многострадальный скрипт уже прекрасно работал на PHP.

а нужен ли нам еще один скриптовый язык?

Положа руку на сердце – не нужен. Однако если он уже появился, то в некоторых случаях вполне может быть полезен. Если какой-нибудь
свежеиспеченный язык предлагает ровно такие же возможности, как и уже имеющийся – не вижу причин все бросать и бежать осваивать новинку. С другой стороны, возможность использовать PHP для решения задач администрирования может быть полезной для веб-разработчиков, которые в этом случае смогут отработать свои скрипты на локальной машине без развертывания на ней полномасштабного тестового веб-сервера. Наконец, люди, знакомые с PHP, теперь смогут применять свои навыки и для администрирования своей техники. При другом раскладе им для этого понадобилось бы дополнительно изучать Perl или еще что-нибудь в этом духе, а если надо всего-то переименовать десяток-другой каких-нибудь mp3-шек – то это не самый рациональный путь.

Итак, несмотря на то, что нам, по большому счету, не нужен еще один скриптовый язык, для тех, кто уже разбирается в PHP и не горит желанием тратить свое время на изучение других языков, рассматриваемая технология может стать очень удобным инструментом.
Далее мы рассмотрим несколько простых примеров, которые продемонстрируют использование PHP в новой ипостаси.

первый простой пример

Этот и все последующие примеры максимально упрощены – их смысл состоит в простом показе того, что это работает и работает очень просто. Первый пример – это, собственно тот скрипт, который заставил меня заняться всеми этими исследованиями.

Я составлял скрипт для LDAP и не смог использовать модуль Net::LDAP (его, как вы помните, просто не было на машине). Решить такую задачу с помощью CPAN или Perl – не проблема, однако у меня был только PHP и я использовал именно его. Данный код не повторяет написанный тогда реальный скрипт, но принцип его работы аналогичен.

#!/usr/bin/php -q


$conn=ldap_connect("ldap.linuxlaboratory.org")
or die("Connect failed\n");

$bind = ldap_bind($conn)
or die("Bind failed\n");

$answer = ldap_search($conn, "dc=linuxlaboratory,dc=org", "(sn=Jones)");
$output = ldap_get_entries($conn, $answer);

echo $output["count"]." entries returned\n";

for ($i=0; $i<count($output); $i++) {
if(!isset($output[$i])) break;
echo $output[$i]["dn"]."\n";
}
?>

Если вам уже доводилось работать с PHP, то вы не найдете в этом скрипте ничего сверхъестественного. Я не определял никаких пользовательских функций, все было настроено в инсталлированном PHP. В моем случае это была установка из RPM. На мой взгляд, данный способ удобен, поскольку если я хочу добавить немного LDAP-функциональности, то под Fedora мне достаточно просто выполнить "yum install php-ldap", и все в порядке. SuSe и Mandrake действуют в том же духе. Уверен, что и дебиановский apt-get сработает не хуже.

Первое, что вы, наверное, уже заметили – это аргумент “-q”. Он дает парсеру команду не генерировать HTML-заголовки и вообще не выводить HTML. Второй момент – теги, расположенные до и после секций кода (). Это те же теги, которые используются для выделения PHP-кода в HTML- странице. В данном случае мы отделяем ими код PHP от вывода простого текста. Если вам понадобится вывести на экран большое количество текста, то использовать echo не нужно. Просто закройте секцию PHP, напишите свой текст, а потом откройте новую секцию PHP тегомСкрипт производит простой поиск пользователей с фамилией (sn) “Jones” по указанному ему каталогу LDAP. Массив результатов сохраняется в переменной $output. Внимательный читатель заметит, что $output [“count”] должна быть где-то заранее определена. Функция ldap_get_entries определяет ее в качестве первого ключа в массиве результатов, поскольку у атрибутов LDAP может быть больше одного значения. Вы также можете посмотреть на то, что твориться в массиве без данного ключа, используя для этого функцию count(). Для поиска ошибок можно применить и функцию print_r($arrayname), которая сделает дамп содержимого массива для последующего просмотра. Вот результат работы рассмотренного нами скрипта:

1 entries returned
cn=Brian K Jones (jonesy@linuxlaboratory.org),dc=linuxlaboratory,dc=org

Ну что же, PHP-код дал результат, который вполне можно было ожидать от скрипта на Perl или работы в командной строке.

еще один пример

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

#!/usr/bin/php -q


snmp_set_valueretrieval(SNMP_VALUE_PLAIN);
$openports = snmpwalk("localhost", "public", ".1.3.6.1.2.1.6.13.1.3");

foreach($openports as $port)
{
if($port< 1024)
{
$service = getservbyport($port, "tcp");
echo "Port $port: $service\n";
}
}
?>

Здесь работает секретное оружие, о котором знают далеко не все PHP-программисты. Первая строка скрипта вызывает функцию snmp_set_valueretrieval() с заранее определенной константой в качестве аргумента. Без этой строки для того, чтобы пропарсить вывод данных net- snmp, вам бы пришлось написать еще три строчки кода. Но у нас такая строка есть, поэтому вы можете быть уверены в том, что возвращено (и передано getservbyport()) будет только одно значение – значение атрибута в запросе, а не "INTEGER: значение", которое создаст проблемы для getservbyport(), которая ожидает номер порта в форме простого числа.

Вот результат работы этого скрипта, который я назвал “holes.php”:

Port 22: ssh
Port 80: http
Port 199: smux
Port 53: domain
Port 953: rndc
Port 53: domain
Вполне возможно, что такую задачу можно решить и более изящным способом, но приведенный код потребовал на свое написание не более трех минут работы. К чему действительно можно придраться – так это к тому, что скрипт не указывает, с каким интерфейсом он работает – как видите, 53-й порт (DNS) показан дважды (первый – для loopback, а второй – для eth0). Если работать как надо, то надо бы вернуться к данным SNMP и проверить там индекс по какому-нибудь нужному значению. Если работать абы как, то можно конечно вызвать функцию array_unique(), которая выкинет из массива все лишнее, но ведь мы же будем работать на совесть!

заключение

Мне довольно непросто определить аудиторию данной статьи. Хардкорные сисадмины, наверное, сочтут святотатством предложение использовать для администрирования что-либо кроме командной строки или Perl. Веб-программисты, особенно с неважными условиями работы, скорее всего, воспримут это как способ дополнить свои анкеты упоминанием навыков администрирования. Потом придут Python-программисты и скажут, что все это можно сделать двумя строками хорошего Python’а. Здесь есть, что обсудить!

Brian Jones, перевод Алексея Кутовенко.
Опубликовано в "Сетевых решениях"
Оригинал: ссылка на страницы Google Книги

FaceTime IM Auditor: как обезопасить технологию IM на предприятии

Несомненно, предприятия, выбравшие использование технологий мгновенных сообщений (instant messaging, IM) встретились с массой сложных проблем, связанных с общей безопасностью и неприкосновенностью личной информации. Игнорирование технологии здесь не поможет, так как быстро растущее количество сотрудников уже использует IM. Именно здесь в игру вступает IM Auditor от FaceTime Communications.
Серверное программное обеспечение масштаба предприятия отслеживает, архивирует и анализирует IM-трафик, одновременно укрепляя безопасность IM, при этом соответствуя узаконенным требованиям (например, HIPAA и SEC), предъявляемым к сохранению IM. Продукт отличается всесторонним и хорошо организованным набором инструментов управления. С удовольствием отметим, что IM Auditor поддерживает наиболее популярные и часто используемые пользователями IM-клиенты.
FaceTime следует типичной бизнес-модели для программных пакетов масштаба предприятия и приближает к ней свои решения для IM. IM Director представляет собой базовую технологию, не смотря на то, что другие продукты, использующие данную технологию, не требуют обязательного наличия IM Director. IM Director функционирует внутри файрволла и берет на себя ответственность за порталы и приложения для совместной работы. IM Auditor базируется на технологиях IM Director и также действует внутри файрволла. Его участок работы – мониторинг и запись использования IM (в основном – переговоров) с целью соответствия требованиям по безопасности и архивированию. Третий продукт, IM Guardian работает вне файрволла (обычно в DMZ) и предназначен для защиты сетевых и IM-приложений. Среди остальных модулей комплекта можно назвать IM Call Center и IM Presence Manager.

Предусмотрительная инсталляция

Установка IM Auditor несложна, однако его конфигурирование требует предварительного планирования. Предоставляемая FaceTime документация довольно хороша, она акцентирует внимание на разборе доступных опций, рассмотрении возможных неполадок, а также освещает работу в кластерных и распределенных конфигурациях.
IMAuditor инсталлируется на серверы, управляемые Windows 2000 или 2003, требует наличия MSMQ (Microsoft Message Queuing) и базы данных (поддерживается работа с MS SQL Server 2000 или Oracle 9i).
Поскольку для IM-среды предприятий в первую очередь жизненно важна производительность, IM Auditor должен быть установлен на выделенной машине (отдельной от сервера IM и базы данных). У IM Auditor есть два режима работы. Рекомендуется его использование в качестве прокси-сервера (то есть клиенты используют адрес этого сервера). В альтернативном режиме для перенаправления сообщений общедоступной сети к IM Auditor используется DNS.
В качестве прокси-сервера IM Auditor использует SOCKS для IM-трафика в рамках общедоступной сети и SIP для трафика от Microsoft Live Communications Server. Мы работали с SOCKS-соединениями, используя инсталляцию с помощью мастера. Данный процесс прошел весьма гладко. Осечка с созданием нашего собственного соединения с базой данных (используя MS SQL Server 2000, мы не подсчитали заранее точный размер базы данных и были немало удивлены большими затратами пространства на архивирование сообщений) высветила важность предварительного планирования.
IM Auditor также может быть сконфигурирован для прямой трассировки сообщений от IM-сервера (то есть Microsoft Exchange и Reuters Messaging) с использованием коннектора от Face Time.
Если быть кратким, то в установке IM Auditor нет ничего неожиданного.

Надежное администрирование

Модуль администрирования IM Auditor основан на веб-технологиях и предлагает набор инструментов для конфигурирования сервера, текущего мониторинга и управления пользователями, и является одним из лучших среди известных нам в аспектах наполнения, формата и пользовательского интерфейса.
Мы нашли IM Auditor исключительно мощным средством управления пользователями (имеется в виду импорт, группировка и распределение полномочий). Информация о пользователе может быть внесена как вручную, в том числе самим пользователем в ходе регистрации, так и через импорт информации из внешних источников (в первую очередь LDAP-совместимых сетевых каталогов, а также текстовых файлов). IM Auditor предоставляет необходимые инструменты, способные справится с управлением тысячами пользователей (и их контактами) и при этом не требующие тысяч рабочих часов на администрирование.

Поддержка пользователей

Одно из преимуществ примененного в IM Auditor подхода состоит в том, что пользователи могут продолжать использовать свои любимые IM-клиенты (например, продукты AOL, MSN, Yahoo и ICQ). Последняя версия IM Auditor полностью поддерживает большинство дополнительных возможностей IM, например видео, аудио и прикрепление файлов. Заметим, что поддержка какой-либо определенной функции зависит от типа клиентской/общедоступной сети.
Еще одно новшество рассматриваемой версии – это spim (IM-спам) фильтр, представляющий собой образчик простоты: на любое послание, поступившее не от IM Auditor или сотрудника/пользователя (а также людей из его списка контактов) автоматически запрашивается ответ. Если ответа не последует, послание отвергается. Несмотря на то, что у нас не было возможности специально провести испытания в стрессовом режиме, мы не получали спам на протяжении всего времени тестирования – так что концепция представляется надежной.

Практическая сторона дела

Наиболее важное качество продукта типа IM Auditor – это способность отслеживать, архивировать и анализировать IM-трафик. В реальном времени IM Auditor отслеживает ограниченный объем трафика и способен блокировать «запрещенные фразы», такие как сквернословие или деловые эвфемизмы. Затем IM Auditor может генерировать e-mail сообщения, предупреждающие о проблемах с IM-трафиком или запрещенными фразами.
Две ключевые функции – управление запрещенными фразами и проверка IM-переговоров -- обеспечиваются использованием в IM Auditor ролевых политик. Например, группы «Обозреватели», «Инспектора Групп» и «Сотрудники» могут разделять объем работы (и некоторую ответственность). Каждая роль имеет свои ограничения в отношении того, что может быть просмотрено и что ей позволено сделать. Например, пользователи, отнесенные к группе «Сотрудники», могут просматривать свои расшифровки, но не могут их править. IM Auditor прелагает более чем достаточный набор инструментов поиска, фильтрации и аннотирования просматриваемых сообщений.
Возможности IM Auditor в части генерации отчетов довольно гибки и включают статистику по использованию IM наиболее активными пользователями, данные по группам и загруженности сети на различных временных промежутках и в разных условиях. Некоторые отчеты содержат сгенерированные графики. По ежедневным и еженедельным IM-переговорам могут быть построены сводки, которые могут быть легко переданы по e-mail к корпоративному ПО мониторинга почты.

ЗА:пакет разработан для комплексного и ответственного применения в среде предприятия, устойчив к сбоям. В пакет входят превосходные инструменты внесения данных и управления пользователями и их контактами.
ПРОТИВ:недостатки Linux- или Unix-версии могут причинить неудобства в некоторых корпоративных условиях.

Nelson King, перевод Алексея Кутовенко
Опубликовано в "Сетевых решениях"
Оригинал: http://www.enterprisenetworkingplanet.com/netos/article.php/3360981/FaceTime-Makes-IM-as-Safe-as-Talking-FacetoFace.htm