| Каталог документации / Раздел "Безопасность" | (Архив | Для печати) |
| ||
|
Мэт Картин (Matt Curtin)
Маркус Ранум (Marcus J. Ranum)
cmcurtin@interhack.net
mjr@nfr.com
Дата: 01.12.2000, 19:48:21
Версия: 10.0
Перевод с английского: © В. Кравчук, 20.08.2001 (http://ln.com.ua/~openxs/)
Версия перевода: 1.0
Этот документ также доступен на английском в формате HTML, Postscript и PDF.
| Оригинальный термин | Перевод |
| address spoofing | подмена адресов |
| application gateway | шлюз приложений |
| bastion host | бастионный (опорный) хост |
| choke router | дроссельный маршрутизатор |
| data-driven attack | атака на базе данных |
| denial-of-service attack | атака на службы |
| Dual Homed Gateway | шлюз с двумя адресами |
| encryption | шифрование |
| FAQ | (ЧаВО) сборник часто задаваемых вопросов |
| firewall | брандмауэр, межсетевой экран |
| forwarder | переадресатор |
| host-to-host authentication | взаимная аутентификация хостов |
| network firewall | сетевой брандмауэр |
| packet filtering | фильтрование пакетов |
| proxy server | промежуточный сервер |
| redirect bomb | бомба перенаправления |
| screened host firewall | брандмауэр с экранированным хостом |
| screening router | экранирующий маршрутизатор |
| service | служба |
| single point of failure | уязвимая точка |
| source routing | внутренняя маршрутизация |
| source-routed packet | пакет с внутренней маршрутизацией |
| three-way handshake | трехходовое согласование |
| virtual private network | виртуальная приватная сеть |
Часть этих терминов разъяснена в Приложении Б.
ЧаВО по брандмауэрам продолжает формироваться. Составители приветствуют дополнения и комментарии к содержанию этого документа. Комментарии посылайте по адресу firewalls-faq@interhack.net. Прежде чем слать сообщения, прочтите разделы 1.2 и 1.3, и убедитесь, что именно этот документ вам нужно изучать.
Брандмауэры прошли серьезный путь развития с момента начала составления этого документа. Из высокоспециализированных систем, администрируемых создателями, они перешли в разряд товара массового спроса. Брандмауэры поддерживаются уже не только специалистам по разработке и реализации систем защиты, -- их устанавливают дома и обычные пользователи, обеспокоенные своей безопасностью.
Этот документ мы составляли для разработчиков и администраторов компьютерных систем. Мы постарались быть лояльными и к новичкам, но предполагаем наличие определенного технического образования. Если оказалось, что вы не понимаете этот документ, но все равно хотите побольше узнать о брандмауэрах, вполне возможно, вам нужна сначала определенная подготовка в области компьютерных сетей. Мы приводим ссылки, которые оказались нам полезными; возможно, вам они тоже помогут.
Учтите, что этот сборник ЧаВО стал результатом общения с множеством людей с разной технической подготовкой на множестве открытых форумов. Адрес firewall-faq -- не справочная служба. Если вы используете приложение, утверждающее, что оно не работает из-за брандмауэра, и вам кажется, что от брандмауэра лучше избавиться, пожалуйста, не шлите нам сообщения с вопросами, как это сделать.
Если вы хотите узнать, как "обойти" брандмауэр, поскольку не можете работать с тем или иным приложением, не шлите нам письма с просьбами о помощи. Мы не можем вам помочь. Честно.
Кто же может вам помочь? Хороший вопрос. Это зависит от конкретной проблемы, но пару рекомендаций можно дать. Если все они не помогут, пожалуйста, не просите у нас порекомендовать что-то еще. Мы не знаем, что.
Проблему может решить:
Версию на английском языке можно найти на сайтах:
Она также ежемесячно посылается в дискуссионные группы:
Версии, посланные в дискуссионные группы, архивируется там же, где и остальные статьи. К сожалению, версии в виде статей из архивов Usenet страдают от отсутствия симпатичных картинок и полезных гиперссылок, имеющихся в Web-версии документа.
Ряд переводов на другие языки сделан. (Если вы перевели документ и этот перевод здесь не упомянут, напишите нам, чтобы мы могли обновить основную версию документа.)
Многие специалисты присылали ценные предложения и вдумчивые комментарии. Мы благодарны всем нашим соавторам. Некоторых хочется поблагодарить лично. Спасибо Кэйнанену Веса (Keinanen Vesa), Аллену Лейбовицу (Allen Leibowitz), Бренту Чэпмену (Brent Chapman), Брайану Бойлу (Brian Boyle), Клайду Уильямсону (D. Clyde Williamson), Полю Робертсону (Paul D. Robertson), Ричарду Рейнеру (Richard Reiner), Умберто Ортису Зуазаге (Humberto Ortiz Zuazaga) и Теодору Хоупу (Theodore Hope).
Copyright © 1995-1996, 1998 Marcus J. Ranum. Copyright © 1998-2000 Matt Curtin. Все права защищены. Этот документ можно использовать, воспроизводить и распространять в неизменном виде, при условии сохранения этой информации об авторских правах и составителях. Также явно разрешается переводить весь текст в целом с оригинальной англоязычной версии на другие языки. Переводчики могут добавлять свои имена в раздел "Соавторы".
Прежде чем детально разбираться с брандмауэрами, важно понять основные принципы, на базе которых они работают.
Брандмауэр (межсетевой экран) -- это система или группа систем, реализующих правила управления доступом между двумя сетями. Фактические средства, с помощью которых это достигается, весьма различны, но в принципе брандмауэр можно рассматривать как пару механизмов: один для блокирования передачи информации, а другой, -- для пропуска информации. Некоторые брандмауэры уделяют больше внимания блокировке передачи информации, другие -- ее пропуску. Вероятно главное, что нужно знать о брандмауэрах, это что они реализуют правила управления доступом. Если не вполне понятно, какого рода доступ необходимо обеспечить или запретить, брандмауэр вам ничем не поможет. Также важно понимать, что конфигурация брандмауэра, как механизма обеспечения выполнения определенных правил, определяет правила для всех систем, которые он защищает. Поэтому на администраторов брандмауэров, управляющих доступом к большому количеству хостов, возлагается большая ответственность.
Internet, как и любое сообщество, страдает от идиотов, получающих удовольствие от электронной разновидности похабной писанины на стенах, поджигания почтовых ящиков или гудения автомобильными сигналами во дворах. Многие пытаются сделать с помощью сети Internet что-то полезное, у других есть важные или конфиденциальные данные, требующие защиты. Обычно задача брандмауэра -- оградить сеть от идиотов, не мешая при этом пользователям выполнять свою работу.
Многие традиционные компании и центры обработки данных разработали правила и принципы компьютерной безопасности, которым надо следовать. Если правила работы компании указывают, как необходимо защищать данные, брандмауэр становится особенно важным, становясь частью корпоративной системы безопасности. Зачастую при подключении большой компании к сети Internet самым трудным является не обоснование того, что это выгодно или полезно, а объяснение руководству, что это вполне безопасно. Брандмауэр не только обеспечивает реальную защиту, -- он часто играет существенную роль гаранта безопасности для руководства.
Наконец, брандмауэр может служить корпоративным "посланником" ("лицом") в Internet. Многие компании используют системы брандмауэров для предоставления широкой общественности информации о продукции и услугах компании, в качестве хранилища файлов для загрузки, источника исправленных версий программ и т.д. Некоторые из этих систем стали важной составляющей спектра услуг сети Internet (например, UUnet.uu.net, whitehouse.gov, gatekeeper.dec.com), что положительно сказалось на имидже их организаторов.
Некоторые брандмауэры пропускают только сообщения электронной почты, тем самым защищая сеть от любых атак, кроме атак на почтовую службу. Другие брандмауэры обеспечивают менее строгую защиту и блокируют лишь службы, определенно угрожающие безопасности.
Обычно брандмауэры конфигурируются для защиты от неавторизованной интерактивной регистрации из "внешнего" мира. Именно это, больше, чем все остальное, помогает предотвратить проникновение вандалов в машины вашей сети. Более развитые брандмауэры блокируют передачу информации извне в защищаемую сеть, разрешая при этом внутренним пользователям свободно взаимодействовать с внешним миром. При правильной настройке брандмауэр может защитить от любого типа сетевой атаки.
Брандмауэры также важны, поскольку позволяют создать единую "уязвимую точку" ("choke point"), где можно организовать защиту и аудит. В отличие от ситуации, когда компьютерная система атакуется извне путем дозвона по модему, брандмауэр может служить эффективным средством "прослушивания" и регистрации подключений. Брандмауэры обеспечивают важные функции журнализации и аудита; часто они позволяют администраторам получать отчеты о типах и объемах переданной через них информации, о количестве попыток взлома и т.п.
Важно, что создание такой "уязвимой точки" может служить в сети той же цели, что и ворота с охраной возле здания фирмы. Тем самым, при изменении "зон" или уровней защищенности имеет смысл создавать такую "проходную". Редко когда в здании фирмы есть только ворота для выезда транспорта и нет дежурного или охранников, проверяющих пропуска у входящих. Если в офисе есть различные уровни доступа, логичным будет и создание нескольких уровней защиты в офисной сети.
Брандмауэр не может защитить от атак, которые выполняются не через него. Многие подключенные к Internet корпорации очень опасаются утечки конфиденциальных данных через этот канал. К несчастью для них, магнитную ленту использовать для передачи данных ничуть не сложнее. Руководство многих организаций, напуганное подключением к Internet, не вполне представляет, как защищать доступ к модемам по коммутируемым линиям. Смешно устанавливать стальную дверь двухметровой толщины в деревянном доме, но многие организации покупают дорогие брандмауэры и игнорирую другие многочисленные лазейки в корпоративную сеть. Чтобы брандмауэр выполнял свои функции, он должен быть часть согласованной общей системы защиты в организации. Правила брандмауэра должны быть реалистичными и отражать уровень защиты всей сети в целом. Например, для систем с совершенно секретными или конфиденциальными данными брандмауэр вообще не нужен -- их просто не надо подключать к Internet, или же надо изолировать системы с действительно секретными данными от остальной части корпоративной сети.
Брандмауэр практически не может защитить вас и от саботажников или идиотов внутри сети. Хотя агент, занимающийся промышленным шпионажем, может передавать информацию через ваш брандмауэр, он точно так же может предавать ее по телефону, по факсу или на дискете. Дискеты -- куда более вероятные каналы утечки информации из компании, чем брандмауэр! Брандмауэры также не могут защитить от глупости. Пользователи, предоставляющие важную информацию по телефону, -- хорошая цель для обработки психологически подготовленным злоумышленником. Он может взломать сеть, полностью обойдя брандмауэр, если сможет найти "полезного" сотрудника в организации, которого сможет обманом заставить дать доступ к модемному пулу. Прежде чем решить, что в вашей организации такой проблемы не существует, спросите себя, насколько сложно представителю организации-партнера получить доступ в сеть, или будет ли трудно пользователю, забывшему пароль, добиться его сброса. Если сотрудники справочной службы считают, что им звонят только из вашего офиса, у вас определенно есть проблема.
Наконец, брандмауэры не могут защитить от передачи по большинству прикладных протоколов команд подставным ("троянским") или плохо написанным клиентским программам. Брандмауэр -- не панацея, и его наличие не отменяет необходимости контролировать программное обеспечение в локальных сетях или обеспечивать защиту хостов и серверов. Передать "плохие" вещи по протоколам HTTP, SMTP и другим очень просто, и это можно легко продемонстрировать. Защита -- это не то, что можно "сделать и забыть".
Брандмауэры не могут обеспечить хорошую защиту от вирусов и им подобных программ. Имеется слишком много способов кодирования двоичных файлов для передачи по сетям, а также слишком много различных аппаратных архитектур и вирусов, чтобы можно было пытаться выявить их все. Другими словами, брандмауэр не может заменить соблюдение принципов защиты вашими пользователями. В общем случае, брандмауэр не может защитить от атаки на базе данных, когда программа в виде данных посылается или копируется на внутренний хост, где затем выполняется. Такого рода атаки в прошлом выполнялись на различные версии программ sendmail, ghostscript и почтовых агентов, типа OutLook, поддерживающих языки сценариев.
Организации, серьезно обеспокоенные проблемой вирусов, должны применять специальные меры для контроля распространения вирусов в масштабе всей организации. Вместо того, чтобы пытаться оградить сеть от вирусов с помощью брандмауэра, проверьте, что каждое уязвимое рабочее место оснащено программами сканирования вирусов, запускаемыми при перезагрузке машины. Оснащение сети программами сканирования вирусов защитит ее от вирусов, полученных с дискет, через модемы и по сети Internet. Попытка заблокировать вирусы на брандмауэре защитит только от попадания вирусов из Internet, а подавляющее большинство вирусов переносится как раз на дискетах.
Тем не менее, все больше поставщиков брандмауэров предлагают брандмауэры "выявляющие вирусы". Они будут полезны только наивным пользователям, обменивающимся выполняемыми программами для платформы Windows-Intel или документами с потенциально разрушительными макросами. Есть много решений на базе брандмауэра для проблем типа червя "ILOVEYOU" и других подобных атак, но они реализуют слишком упрощенные подходы, пытаясь ограничить ущерб от действий настолько глупых, что они вообще не должны выполняться. Не полагайтесь на то, что эти средства защитят вас хоть сколько-нибудь от атакующих.
Мощный брандмауэр не заменяет чувствительного программного обеспечения, знающего природу обрабатываемых данных -- ненадежных и поступивших из не обладающего доверием источника, -- и обрабатывающего их соответствующим образом. Не думайте, что вы в безопасности, раз "все" используют некую почтовую программу, произведенную гигантской транснациональной компанией. На самом деле, неверно, что "все" используют какую бы то ни было почтовую программу, а компании, специализирующиеся на преобразовании разработанных другими технологий в "простую для использования" форму, не разбираясь в их сути, с большей вероятность будут создавать программы, которые можно будет обмануть.
Некоторые считают именно так. Прежде чем делать такие серьезные прогнозы, однако, стоит разобраться, что же такое IPSEC и что он делает. После этого можно будет решить, сможет ли IPSEC решить проблемы, которые сейчас пытаются решить с помощью брандмауэров.
IPSEC (IP SECurity -- защита IP) -- это набор стандартов, разработанных Internet Engineering Task Force (IETF). Есть несколько документов, совместно определяющих, что же такое "IPSEC" [4]. IPSEC решает две проблемы, от которых многие годы страдает стек протоколов IP: взаимная аутентификация хостов (позволяющая хостам знать, что они взаимодействуют именно с теми хостами, с которыми предполагают) и шифрование (которое не позволит атакующим следить за информацией, передаваемой между машинами).
Обратите внимание, что ни одна из этих проблем не относится к тем, для решения которых создавались брандмауэры. Хотя брандмауэры могут помочь снизить некоторые из рисков при работе в Internet без аутентификации или шифрования, на самом деле речь идет о двух классах проблем: целостность и конфиденциальность информации, передаваемой между хостами, и ограничения на виды подключений, допустимых между различными сетями. Первый класс проблем решает IPSEC, а второй -- брандмауэры.
Это означает, что решение одного класса проблем не избавляет от необходимости решать проблемы другого класса, но сочетание брандмауэра и хостов, поддерживающих IPSEC, дает ряд интересных возможностей. В частности, это универсальные виртуальные приватные сети (VPNs), улучшенное фильтрование пакетов (за счет фильтрования по признаку наличия в пакетах заголовка аутентификации IPSEC), и брандмауэры уровня приложений, которые смогут точнее проверять хосты, используя заголовок аутентификации IPSEC вместо "принятия на веру" указанного IP-адреса.
Есть несколько хороших книг о брандмауэрах. Вот наиболее известные:
Информация по связанным темам представлена в книгах:
Перед счастливчиком, отвечающим за проектирование, реализацию, установку брандмауэра или за создание соответствующего технического задания, встает ряд базовых проектных проблем.
Первое, и наиболее важное, решение связано с принятой в компании или организации политикой в отношении работы системы: устанавливается ли брандмауэр, чтобы явно запретить все службы, кроме существенных для работы с сетью Internet, или же он устанавливается для обеспечения "упорядоченного" и безопасного доступа с возможностью контроля и аудита? Между этими двумя подходами есть несколько уровней параноидальности; окончательное назначение создаваемого брандмауэра -- результат скорее политического, чем инженерного решения.
Вторая проблема: какой уровень мониторинга, избыточности и контроля необходим? Определив допустимый уровень риска (т.е. степень своей паранойи) при решении первой проблемы, можно сформировать список требований к тому, что должно отслеживаться, разрешаться и запрещаться. Другими словами, начинать надо с определения общих целей, а затем выполнить анализ потребностей с учетом возможных рисков, составив список почти всегда противоречивых требований, определяющих, что же, собственно, предполагается создать.
Третья проблема -- финансовая. Мы можем оценить ее здесь лишь приблизительно, но важно попытаться численно оценить стоимость покупки или реализации для каждого из предлагаемых решений. Например, стоимость полнофункционального брандмауэра может составлять от нуля в простейшем случае до 100000 $ для развитых коммерческих систем. Бесплатный вариант, состоящий в специальном конфигурировании Cisco или другого подобного маршрутизатора, потребует только определенного времени от специалистов и несколько чашек кофе. Реализация мощного брандмауэра с нуля может потребовать нескольких человеко- месяцев, что выльется в 30000 $ зарплаты и прочих поощрений персоналу. Учитывать также надо и дополнительные расходы на поддержку системы. Создавать свое специализированное решение -- хорошая идея, если только это оно не потребует постоянного (и дорогостоящего) внимания. Другими словами, важно оценивать брандмауэры не только с учетом первоначальной стоимости, но учитывать и эксплуатационные расходы, например, на их поддержку.
Необходимо принять пару чисто технических решений с учетом того, что для любых практических целей речь пойдет о статической службе маршрутизации информации, размещаемой между маршрутизатором поставщика сетевых услуг и вашей внутренней сетью. Служба маршрутизации информации может реализовываться на уровне протокола IP с помощью, например, правил экранирования на маршрутизаторе, или на уровне приложений с помощью промежуточных шлюзов и служб.
Надо решить, размещать ли общедоступную машину с урезанной конфигурацией во внешней сети для обеспечения работы промежуточных служб telnet, FTP, news и т.д. или же настроить экранирующий маршрутизатор в качестве фильтра, разрешающего взаимодействие с одной или несколькими внутренними машинами. Достоинства и недостатки есть у обоих подходов. Так, промежуточный сервер обеспечивает более высокий уровень аудита и потенциальную защиту за счет повышения затрат на конфигурирование и снижения уровня обслуживания (поскольку надо разрабатывать промежуточный сервер для каждой требуемой службы). Старое противоречие между простой использования и защитой снова упорно нас преследует.
Концептуально. есть два типа брандмауэров:
Они не так уж различны, как может показаться, и последние технологии доводят различие до того, что уже непонятно, что же "лучше" и что "хуже". Как всегда, необходимо тщательно выбирать тип в соответствии с требованиями.
Различие состоит в том, какие механизмы брандмауэр использует для передачи информации из одной зоны защиты в другую. Сетевая модель International Standards Organization (ISO) Open Systems Interconnect (OSI) определяет семь уровней, каждый из которых обеспечивает службы, от которых зависят более высокие уровни. Это (от нижнего к верхнему) уровни физический (physical), передачи данных (data link), сетевой (network), транспортный (transport), сеансовый (session), презентационный (presentation) и прикладной (application).
Важно понимать, что чем на более низком уровне работает механизм перенаправления, тем меньше проверок может выполнить брандмауэр. В общем случае, низкоуровневые брандмауэры работают быстрее, но их проще обойти, заставив совершить ошибку.
Эти брандмауэры обычно принимают решения на основе адресов отправителя и места назначения и номеров портов (более детальная информация о портах представлена в Приложении В) в отдельных IP-пакетах. Простой маршрутизатор -- вот "традиционный" брандмауэр сетевого уровня, поскольку он не может делать особо сложных выводов о том, какой службе фактически предназначен пакет или откуда он в действительности пришел. Современные брандмауэры сетевого уровня стали существенно сложнее и поддерживают внутреннюю информацию о состоянии проходящих через них подключений, содержимом некоторых из потоков данных и т.п. Одно из важных отличий многих брандмауэров сетевого уровня состоит в том, что они передают информацию непосредственно через себя, поэтому для их использования необходимо иметь официально выделенный пул IP-адресов или использовать пул "приватных" Internet-адресов [3]. Брандмауэры сетевого уровня обычно работают очень быстро и весьма прозрачно для пользователей.
На рис. 1 представлен брандмауэр сетевого уровня, который называется "брандмауэр с экранированным хостом" ("screened host firewall"). При такой схеме доступ к единственному хосту и с него управляется с помощью маршрутизатора, работающего на сетевом уровне. Единственный хост является бастионным -- хорошо защищенным и безопасным укреплением, способным (предположительно) устоять при атаке.
Пример брандмауэра сетевого уровня: на рис. 2 представлен брандмауэр сетевого уровня, который называется "брандмауэр с экранированной подсетью" ("screened subnet firewall"). В этом случае доступ к целой сети и из нее управляется с помощью маршрутизатора, работающего на сетевом уровне. Такая схема аналогична экранированному хосту, но, фактически, представляет собой сеть из экранированных хостов.
Обычно они представляют собой хосты, на которых работают промежуточные серверы, не разрешающие передавать информацию между сетями напрямую, а также обеспечивающие расширенную регистрацию и аудит проходящей через них информации. Поскольку промежуточные программы работают на брандмауэре, на них можно выполнять детальную регистрацию и управление доступом. Брандмауэры прикладного уровня можно использовать для преобразования сетевых адресов, поскольку информация поступает с одной "стороны", а выходит с другой, пройдя через приложение, эффективно скрывающее происхождение начального подключения. Наличие промежуточного приложения на пути передачи информации в некоторых случаях может снижать производительность и делать брандмауэр менее прозрачным. Ранние брандмауэры прикладного уровня, в частности, построенные на основе набора инструментальных средств TIS firewall toolkit, не слишком прозрачны для пользователей, которых необходимо дополнительно обучать. Современные брандмауэры прикладного уровня зачастую полностью прозрачны. Брандмауэры прикладного уровня обычно предоставляют более детальные отчеты для аудита и реализуют более консервативные модели защиты, чем брандмауэры сетевого уровня.
Пример брандмауэра прикладного уровня: На рис. 3 представлен брандмауэр прикладного уровня, который называют "шлюзом с двумя адресами". Шлюз с двумя адресами -- это серьезно защищенный хост, на котором работает промежуточное программное обеспечение. У него есть два сетевых интерфейса, по одному для каждой сети, и передача любой информации между ними блокируется.
Будущее брандмауэров лежит где-то между брандмауэрами сетевого и прикладного уровня. Вероятно, брандмауэры сетевого уровня будут все больше "осведомлены" о проходящей через них информации, а брандмауэры прикладного уровня будут становиться все более "низкоуровневыми" и прозрачными. Конечным результатом будет быстрая система экранирования пакетов, регистрирующая и проверяющая данные при прохождении. Все чаще брандмауэры (сетевого и прикладного уровня) будут включать возможности шифрования, чтобы защищать данные, передаваемые между ними через Internet. Брандмауэры с двусторонним шифрованием могут пригодиться организациям с несколькими точками подключения к сети Internet, позволяя использовать ее в качестве "приватной магистрали" без опасений в отношении перехвата данных или паролей.
Промежуточный сервер (который иногда еще называют шлюзом приложений или переадресатором) -- это приложение, передающее информацию между защищенной сетью и Internet. Промежуточные серверы часто используются вместо управления передачей информации на базе маршрутизаторов для предотвращения непосредственного сквозного обмена информацией между сетями. Многие промежуточные серверы содержат дополнительные средства регистрации или поддержки аутентификации пользователей. Поскольку промежуточные серверы должны "понимать" используемый прикладной протокол, они могут также реализовать специфические средства защиты этого протокола (например, промежуточный FTP-сервер можно сконфигурировать так, чтобы разрешать загрузку, но запрещать выгрузку информации).
Промежуточные серверы зависят от приложений. Чтобы поддержать новый протокол через промежуточный сервер, необходимо соответствующий сервер разработать. Один из популярных наборов промежуточных серверов, -- TIS Internet Firewall Toolkit ("FWTK") -- включает промежуточные серверы для протоколов Telnet, rlogin, FTP, X-Window, HTTP/Web и NNTP. SOCKS -- это универсальная промежуточная система, которую можно скомпилировать и включить в клиентское приложение для обеспечения возможности работать через брандмауэр. Она проста в использовании, но не поддерживает добавление дополнительной аутентификации или специфической журнализации для протоколов. Подробнее о системе SOCKS см. на сайте http://www.socks.nec.com/.
Среди разработанных в университете Texas AMU средств защиты есть программы, реализующие экранирующие маршрутизаторы. Еще один набор программ экранирующего маршрутизатора для ПК, Karlbridge, доступен по адресу ftp://ftp.net.ohio-state.edu/pub/kbridge/. Версия пакета "screend" для экранирования на уровне ядра, разработанная в Digital Equipment Corporation, доступна для систем, основанных на BSD. Имеется множество средств экранирования пакетов на уровне ядра, в том числе ipf, ipfw, и ipfwadm. Они обычно включаются в различные свободно распространяемые версии Unix, такие как FreeBSD, OpenBSD, NetBSD и Linux. Эти же средства могут быть доступны и для коммерческих реализаций Unix. Если не полениться, вполне можно создать безопасный и полнофункциональный брандмауэр, потратив немного времени и денег на оборудование.
Мы рассмотрим пример для пакета ipfwadm на Linux, но принципы (и даже большая часть командных строк) подойдут и для других интерфейсов экранирования пакетов на уровне ядра на системах Unix с "открытым кодом".
Правила пакета ipfwadm делятся на четыре основных категории:
Пакет ipfwadm поддерживает также возможности маскирования (-M). Подробнее о ключах и опциях пакета ipfwadm см. на соответствующей странице справочного руководства.
Пусть в организации используется приватная сеть класса C (см. RFC 1918) с адресом 192.168.1.0. Поставщик услуг Internet выделил адрес 201.123.102.32 для внешнего интерфейса шлюза и адрес 201.123.102.33 для внешнего почтового сервера. В организации приняты следующие правила:
Следующий блок команд можно поместить в файл загрузки системы (например, rc.local во многих Unix-системах).
ipfwadm -F -f ipfwadm -F -p deny ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 25 ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53 ipfwadm -F -i m -b -P udp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53 ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0 /sbin/route add -host 201.123.102.33 gw 192.168.1.2
ipfwadm -F (forward - перенаправление) -i (входящая) m (маскирование) -b (двунаправленное) -P (протокол)[протокол] -S (источник)[подсеть/маска] [исходные порты] -D (цель) [подсеть/маска][порт]
На рис. 4 представлена одна из возможных конфигураций, использующих Cisco в качестве фильтрующего маршрутизатора. Это пример, показывающий реализацию конкретного набора правил. Вне всякого сомнения, правила в вашей организации будут другими.
В этом примере компания имеет сетевой адрес класса C, 195.55.55.0. Сеть компании подключена к Internet через провайдера (поставщика услуг Internet). Принятые в компании правила разрешают доступ к службам Internet любому, так что все исходящие подключения принимаются. Все входящие подключения проходят через "почтовый хост". Для внешнего мира поддерживаются только почтовая служба и DNS.
В этой конфигурации проверяются только входящие пакеты, поступающие из Internet. Правила проверяются последовательно и проверка прекращается, когда будет найдено первое совпадение. В конце списка правил доступа идет неявное правило запрещения, запрещающее все. Ниже представлен список правил доступа по IP для Cisco IOS v. 10.3 и более поздних версий.
no ip source-route ! interface ethernet 0 ip address 195.55.55.1 no ip directed-broadcast ! interface serial 0 no ip directed-broadcast ip access-group 101 in ! access-list 101 deny ip 127.0.0.0 0.255.255.255 any access-list 101 deny ip 10.0.0.0 0.255.255.255 any access-list 101 deny ip 172.16.0.0 0.15.255.255 any access-list 101 deny ip 192.168.0.0 0.0.255.255 any access-list 101 deny ip any 0.0.0.255 255.255.255.0 access-list 101 deny ip any 0.0.0.0 255.255.255.0 ! access-list 101 deny ip 195.55.55.0 0.0.0.255 access-list 101 permit tcp any any established ! access-list 101 permit tcp any host 195.55.55.10 eq smtp access-list 101 permit tcp any host 195.55.55.10 eq dns access-list 101 permit udp any host 192.55.55.10 eq dns ! access-list 101 deny tcp any any range 6000 6003 access-list 101 deny tcp any any range 2000 2003 access-list 101 deny tcp any any eq 2049 access-list 101 deny udp any any eq 2049 ! access-list 101 permit tcp any 20 any gt 1024 ! access-list 101 permit icmp any any ! snmp-server community FOOBAR RO 2 line vty 0 4 access-class 2 in access-list 2 permit 195.55.55.0 0.0.0.255
Используйте версию Cisco ОС не ниже 9.21, чтобы можно было фильтровать входящие пакеты и проверять, не подменен ли адрес. Еще лучшее использовать версию 10.3, в которой есть ряд дополнительных возможностей (например, фильтрование по исходному порту) и улучшений в синтаксисе фильтров.
Способов усиления защиты остается немного. Заблокируйте все входящие TCP-подключения и предложите пользователям использовать пассивные FTP-клиенты. Можно также блокировать исходящие сообщения ICMP echo-reply и destination-unreachable, чтобы спрятать свою сеть и предотвратить использование сканеров сети. На сайте Cisco.com был когда-то архив примеров построения брандмауэров на базе маршрутизаторов Cisco, но сейчас он, по-видимому, в сети недоступен. По поводу списков контроля доступа Cisco имеется ряд материалов, в частности, по адресу ftp://ftp.cisco.com/pub/mibs/app_notes/access-lists.
Важно понимать, какие ресурсы являются критичными для выбранной архитектуры брандмауэра, чтобы учитывать при планировании объемов услуг, настройке производительности и т.д., что именно и в какой степени надо делать для получения желаемого результата.
Критичными для брандмауэра могут быть разные ресурсы, в зависимости от типов информации, передаваемых через систему. Некоторые думают, что смогут автоматически увеличивать пропускную способность брандмауэра, перенося его на компьютер с более быстрым процессором или процессором другой архитектуры, что не всегда верно. Потенциально это может привести к значительным денежным затратам, абсолютно не решающим проблему или не дающим ожидаемой масштабируемости решения.
В загруженной системе особенно важна память. Необходимо иметь достаточно оперативной памяти, чтобы вместить каждый экземпляр каждой программы, необходимой для решения возложенных на машину задач. В противном случае начнется откачка страниц и производительность не будет расти. Незначительное использование области подкачки обычно не проблема, но если область подкачки системы быстро заполняется, пришло время расширять оперативную память. Систему с интенсивной откачкой страниц часто относительно несложно заблокировать с помощью атаки на службы или сильно затормозить простой перегрузкой обращениями. Вот почему бывают задержки с получением электронной почты...
Помимо требований к памяти, важно понимать, что различные службы используют разные ресурсы системы. Поэтому конфигурация системы должна соответствовать предполагаемому назначению. Процессор с тактовой частотой 2 ГГц не сильно поможет, если система обслуживает электронную почту и дискуссионные группы, имея единственный IDE-диск, подключенный к контроллеру ISA.
| Служба | Критический ресурс |
| Электронная почта | Дисковый ввод/вывод |
| Сервер дискуссионных групп | Дисковый ввод/вывод |
| Web-сервер | Производительность подсистемы сокетов ОС хоста |
| Маршрутизация IP-пакетов | Производительность подсистемы сокетов ОС хоста |
| Web-кэш | Производительность подсистемы сокетов ОС хоста, дисковый ввод/вывод |
"DMZ" (ДМЗ) -- сокращение от "demilitarized zone" (демилитаризованная зона). В контексте брандмауэров этот термин означает часть сети, не входящую непосредственно ни во внутреннюю сеть, ни в Internet. Обычно это область между маршрутизатором, обеспечивающим доступ в Internet, и бастионным хостом, хотя так можно называть область между любыми двумя компонентами архитектуры защиты, обеспечивающими выполнение правил доступа.
ДМЗ можно создать, установив списки контроля доступа на маршрутизаторе, обеспечивающем выход в Internet. Это позволяет минимально открыть хосты локальной сети, разрешая доступ из Internet только к определенным и контролируемым службам на этих хостах. Многие коммерческие брандмауэры просто создают на бастионном хосте третий сетевой интерфейс и называют его DMZ. Суть в том, что соответствующая сеть не является ни "внешней", ни "внутренней".
Например, Web-сервер, работающий на платформе NT, может быть уязвим для многих атак на службы RPC, NetBIOS и SMB. Эти службы не нужны для работы Web-сервера, поэтому блокирование подключений по протоколу TCP к портам 135, 137, 138 и 139 на этом хосте уменьшит его уязвимость для атаки на службы. Фактически, если заблокировать передачу на этот хост информации по любым протоколам, кроме HTTP, атакующему останется для атаки только одна служба.
Этот пример иллюстрирует важный принцип: никогда не давайте атакующим больше точек доступа, чем абсолютно необходимо для поддержки служб, предлагаемых для общего доступа.
Типичный для атакующих подход состоит во взломе уязвимого для атаки хоста и использовании доверительных отношений между уязвимым хостом и другими, более интересными, целями.
При поддержке нескольких служб с разными уровнями защищенности может пригодиться разделение ДМЗ на несколько "зон защиты". Это можно сделать, создав несколько различных сетей в пределах ДМЗ. Например, маршрутизатор, обеспечивающий доступ извне, может передавать информацию по двум сетевым интерфейсам ethernet, защищенным списками контроля доступа и, тем самым, входящим в ДМЗ.
В одной из сетей можно собрать хосты, реализующие потребности организации в подключении к Internet. Вероятно, они будут пересылать электронную почту, информацию дискуссионных групп и поддерживать службу DNS. В другой сети могут находиться Web-серверы и другие хосты, обеспечивающие работу служб, предназначенных для пользователей Internet.
Во многих организациях службы для пользователей Internet защищаются менее серьезно и с большей вероятностью могут допускать небезопасные действия. (Например, в случае Web-сервера, неавторизованные и не пользующиеся доверием пользователи могут запускать CGI- или другие выполняемые программы. Это может быть необходимо для работы Web-сервера, но несет ряд угроз, которые необходимо учитывать. Вероятно, эти службы окажутся слишком рискованными, чтобы запускать их на бастионном хосте, взлом которого может привести к полному отказу механизмов защиты.)
Помещая хосты с похожими уровнями риска вместе в отдельные сети в ДМЗ, можно уменьшить вред от взлома сайта. Если кто-нибудь взломает Web-сервер, воспользовавшись какой-то ошибкой в программе, то не сможет использовать его как стартовую площадку для взлома приватной сети, если Web-серверы располагаются в локальной сети отдельно от бастионных хостов и нет никаких доверительных отношений между Web-сервером и бастионным хостом.
Вспомним теперь, что речь идет о сетях ethernet. Если кто-нибудь взломает Web-сервер, а бастионный хост находится в том же сегменте ethernet, взломщик может установить на Web-сервере анализатор протокола и просматривать информацию, передаваемую бастионному хосту и отправляемую с него. В результате можно получить данные, необходимые для взлома бастионного хоста и получения доступа к внутренней сети.
Разделение служб не только по хостам, но и по сетям, и ограничение уровня доверия между хостами этих сетей позволяет существенно уменьшить вероятность того, что взлом одного хоста можно будет использовать для взлома другого. В частности, в рассмотренном примере взлом Web-сервера никак не поможет атакующему взломать бастионный хост.
Помещая хосты в разные сети, можно также улучшить масштабируемость выбранной архитектуры. Чем меньше машин используют один канал передачи данных, тем большую пропускную способность сможет обеспечить каждая из них.
Архитектура, безопасность которой основана на одном механизме, имеет уязвимую точку. В программном обеспечении, работающем на бастионных хостах, есть ошибки. В приложениях есть ошибки. В управляющих программах маршрутизаторов тоже есть ошибки. Имеет смысл использовать все эти компоненты при создании безопасной сети, причем так, чтобы они дублировали функции друг друга.
Если брандмауэр реализует архитектуру экранированной подсети, то имеется два маршрутизатора, фильтрующих пакеты, и бастионный хост. (См. вопрос 3.2 в этом разделе.) Маршрутизатор, реализующий связь с Internet, не позволит пакетам из Internet свободно проходить в приватную сеть. Однако, если не устанавливать это же правило с помощью других механизмов на бастионном хосте и/или дроссельном маршрутизаторе, то для проникновения достаточно будет взломать или вызвать сбой всего одного компонента архитектуры. Если же подобное, "избыточное" правило будет задано на бастионном хосте и еще раз на дроссельном маршрутизаторе, атакующему придется проходить через три механизма.
Более того, если бастионному хосту или дроссельному маршрутизатору придется применять это правило для блокирования доступа извне к внутренней сети, он может подавать тот или иной сигнал тревоги, поскольку понятно, что кто-то пробрался через внешний маршрутизатор.
Для брандмауэров, призванных обеспечить безопасность, а не возможность подключения, имеет смысл по умолчанию заблокировать все и открывать только необходимые службы, принимая решение в каждом случае отдельно.
Если заблокировать все, кроме конкретного набора служб, работа существенно упрощается.
Вместо того, чтобы беспокоиться обо всех проблемах защиты всех имеющихся программ и
служб, необходимо беспокоиться обо всех проблемах защиты конкретного
набора служб и программ. :-)
Прежде чем включать службу, необходимо рассмотреть ряд вопросов:
При рассмотрении этих вопросов учитывайте следующее:
Несколько лет назад кому-то пришло в голову, что не мешало бы блокировать "плохие" Web-сайты, т.е. содержащие материалы, "нецелесообразные" с точки зрения Компании. Эта идея становилась все популярнее, но при рассмотрении реализации такого рода контроля на брандмауэре необходимо учесть ряд соображений.
Запомните простое правило, что нельзя решить общественные проблемы с помощью технических подходов. Если есть проблема в том, что некто зашел на "нецелесообразный" Web-сайт, то лишь потому, что кто-то другой это заметил или потому, что производительность его труда оказалась ниже ожидавшейся. В обоих случаях это забота отдела кадров, а не администратора брандмауэра.
Обычно маршрут, по которому пакет проходит от отправителя до места назначения определяется промежуточными маршрутизаторами. Сам пакет содержит информацию только о том, куда ему необходимо попасть (адрес места назначения) и ничего не говорит о том, как бы ему хотелось туда добираться.
У отправителя пакета есть дополнительный способ включения в пакет информации о маршруте, по которому пакет должен проходить до места назначения; отсюда и название "внутренняя маршрутизация". Для брандмауэра внутренняя маршрутизация -- существенная проблема, поскольку атакующий может генерировать пакеты, утверждающие, что они поступили с системы, "внутренней" по отношению к брандмауэру. В общем случае, такого рода пакеты не попадают на брандмауэр по соответствующим маршрутам, но при использовании внутренней маршрутизации все маршрутизаторы между машиной атакующего и целевой машиной будут возвращать пакеты по маршруту, обратному указанному в пакете. Реализовать такую атаку весьма просто, поэтому создатели брандмауэров не должны считать ее маловероятной.
На практике внутренняя маршрутизация используется очень редко. Фактически, обычно основным законным ее использованием является отладка проблем в сети или направление пакетов по конкретным линиям связи, чтобы предотвратить перегрузку каналов в особых случаях. При построении брандмауэра внутренняя маршрутизация должна где-то блокироваться. Большинство коммерческих маршрутизаторов включают возможность явно блокировать внутреннюю маршрутизацию, а многие версии ОС Unix, которые могут использоваться для построения бастионных хостов брандмауэров, также позволяют запрещать или игнорировать пакеты с внутренней маршрутизацией.
Пакет перенаправления протокола ICMP (ICMP Redirect) требует от принимающей системы изменить часть своей таблицы маршрутизации. Он вполне законно используется маршрутизаторами для информирования хостов о том, что они используют не оптимальный или недействующий маршрут к определенному месту назначения, т.е. хост посылает пакет не тому маршрутизатору. "Не тот" маршрутизатор посылает такому хосту пакет перенаправления ICMP, сообщающий хосту, каким должен быть правильный маршрут. Если удастся подделать пакеты перенаправления ICMP и если целевой хост их не игнорирует, то можно изменить таблицы маршрутизации на хосте и, возможно, обойти защиту хоста, направляя пакеты по пути, не предполагавшемуся администратором сети. Перенаправления ICMP также могут использоваться для организации атак на службы, когда хосту посылается маршрут, не позволяющий подключиться, или хосту посылается пакет недоступности сети (ICMP Network Unreachable), утверждающий, что он больше не может обращаться к определенной сети.
Многие создатели брандмауэров экранируют пакеты ICMP, не пропуская их в сети, поскольку это ограничивает возможности извне проверять хосты или изменять их таблицы маршрутизации.
Прежде чем решить полностью заблокировать пакеты ICMP, надо знать, как протокол TCP выполняет "определение максимального размера пакета для пути" ("Path MTU Discovery"), чтобы не разорвать связь с другими сайтами. Если нельзя безопасно заблокировать протокол ICMP повсеместно, можно разрешить передачу избранных типов пакетом ICMP через определенные устройства маршрутизации. Если протокол ICMP не блокируется, проверьте, что маршрутизаторы и хосты, по крайней мере, не отвечают на широковещательные пакеты ping.
Атака на службу -- это когда некто решает вывести из строя вашу сеть или брандмауэр, разрушая, взламывая, заглушая или забрасывая запросами. Проблема атак на службы в Internet состоит в том, что их невозможно предотвратить. Причина этого связана с распределенной природой сети: каждый узел сети связан с другими сетями, которые, в свою очередь, связаны с третьими и т.д. Администратор брандмауэра или поставщик услуг Internet контролирует лишь некоторые из локальных компонентов сети в пределах достижимости. Атакующий всегда может разрушить подключение "выше" того места, где жертва может что-то контролировать. Другими словами, если некто хочет отключить сеть, это можно сделать, отключив сеть непосредственно или отключив сети, к которым она подключена и т.д. до бесконечности. Имеется множество способов сорвать работу сетевых служб, от сложных до простейших, грубой силой. Если предполагается использовать сеть Internet для службы, принципиально важной для работы или критичной по времени предоставления услуг, необходимо готовить позицию для отступления на случай отключения или повреждения сети.
Службу UDP echo (эхо-ответ) семейства протоколов TCP/IP тривиально можно
использовать для того, чтобы пара серверов переполнила сегмент сети эхо-пакетами.
Имеет смысл закомментировать неиспользуемые записи в файле /etc/inetd.conf
Unix-хостов, и добавить no ip small-servers на маршрутизаторах
Cisco или аналогичном оборудовании.
Каждый сайт немного отличается от всех остальных тем, какие именно атаки с наибольшей вероятностью могут быть на него направлены. Но есть и ряд постоянно повторяющихся схем.
Это когда спаммер (spammer -- человек или программная система, рассылающая нежелательные, например, рекламные, сообщения) создает несколько тысяч копий сообщения и рассылает их по огромному списку адресов электронной почты. Поскольку эти списки велики, чтобы ускорить работу, многие спаммеры просто посылают всю подобную почту на сервер SMTP, который и позаботится о ее фактической доставке.
Конечно, все возвращенные сообщения, возмущения, письма с угрозами и плохая репутация будут связаны с сайтом, использованным для пересылки. С этим связаны вполне конкретные материальные потери, в частности, выплаты тем, кто будет заниматься уборкой всего полученного в результате мусора.
На сайте Transport Security Initiative системы предотвращения незаконного использования электронной почты (Mail Abuse Prevention System) представлено подробное описание проблемы и способы конфигурирования практически всех существующих почтовых программ для защиты от этой атаки.
Различные версии Web-серверов, почтовых серверов и другого программного обеспечения сетевых служб Internet содержат ошибки, позволяющие удаленным пользователям (подключающимся через Internet) выполнять различные несанкционированные действия, от получения полного контроля над машиной до нарушения работы соответствующего приложения, практически со всеми промежуточными вариантами.
Вероятность событий подобного рода можно снизить, запуская только необходимые службы, следя за обновлениями соответствующих программ и используя продукты, успешно эксплуатируемые уже некоторое время.
Эти ошибки тоже обычно инициируются удаленными пользователями. Операционные системы, сравнительно недавно поддерживающие сетевое взаимодействие по протоколу IP, обычно более проблематичны в этом отношении, поскольку у авторов более зрелых операционных систем было время найти и устранить свои ошибки. Атакующий зачастую может вызывать постоянные перезагрузки, поломки или невозможность работать в сети целевого оборудования, либо заменять файлы на машине.
В данном случае может помочь поддержка лишь минимально необходимого набора служб операционной системы. Кроме того, наличие фильтра пакетов перед операционной системой может снизить ее уязвимость для многих типов подобных атак.
И, конечно же, существенно поможет выбор стабильной операционной системы. При выборе операционной системы не верьте утверждению, что "чем дороже, тем лучше". Свободно распространяемые операционные системы зачастую более надежны, чем их коммерческие конкуренты.
Вполне реален ответ "нет". На каждом сайте есть свои правила в отношении того, что нужно, а что -- нет, но важно помнить, что одной из профессиональных обязанностей администратора шлюза является обучение. Пользователи хотят потокового видео, бесед в реальном времени и возможности предоставлять внешним клиентам услуги, требующие взаимодействия с реально действующими базами данных во внутренней сети.
Это не означает, что хоть какую-то из этих возможностей можно предоставить, не создавая для организации большей угрозы, чем предполагаемая "выгода" от их реализации. Большинство пользователей не собираются подвергать риску организацию, в которой работают. Они просто читают рекламные объявления, видят призывы и им тоже хочется все это попробовать. Важно разобраться, что же представляет собой то, что они на самом деле хотят делать, и помочь им понять, как достичь реальной цели более безопасным способом.
Вашу позицию не всегда поймут и вам могут даже давать указания делать что-то поразительно глупое, типа "просто откройте порты с такого-то по такой-то". Если происходит именно так, не переживайте. Разумно будет просто сохранить всю переписку по этому поводу, чтобы когда 12-летний любитель командной строки взломает сайт, вы смогли хотя бы доказать свою непричастность к этому безобразию.
Это можно сделать тремя способами.
SSL -- это протокол, обеспечивающий безопасные подключения через Internet. Обычно протокол SSL используется для защиты информации, передаваемой по HTTP. Но поверх SSL могут работать и другие протоколы (например, telnet).
Пропуск пакетов SSL через брандмауэр можно организовать точно так же, как и пропуск пакетов HTTP, если SSL, как обычно, используется для защиты HTTP. Единственное различие состоит в том, что вместо программы, пересылающей пакеты HTTP, потребуется программа, обеспечивающая туннелирование SSL. Эта возможность имеется в большинстве кэширующих Web-серверов.
Подробнее об SSL можно узнать на сайте Netscape.
Некоторые организации хотят скрыть имена DNS от внешнего мира. Многие эксперты считают, что скрывать имена DNS не стоит, но если принятые правила сайта/организации предписывают скрывать доменные имена, то есть реальный способ сделать это. Еще одной причиной скрывать доменные имена может быть нестандартная схема адресации во внутренней сети. В этом случае не остается выбора -- надо эти адреса скрывать. Но не обманывайте себя, считая, что если ваши имена DNS скрыты, то это существенно замедлит взлом брандмауэра атакующим. Информацию о том, что находится в сети, очень легко получить собственно с сетевого уровня. Если хотите, вот вам интересный пример этого: выполните ping по широковещательному адресу подсети в своей локальной сети, а затем выполните команду "arp -a". Учтите также, что сокрытие имен в службе DNS не решает проблему имен хостов, "просачивающихся" в заголовках сообщений электронной почты, статьях в дискуссионные группы и т.п.
Описываемый способ -- один из многих, и подходит для организаций, желающих срыть имена своих хостов от пользователей Internet. Успех этого подхода обеспечен тем, что клиенты DNS на машине не обязаны взаимодействовать с сервером DNS на той же машине. Другими словами, даже при наличии на машине сервера DNS, вполне можно (а, зачастую, и имеет смысл) перенаправить запросы клиентов DNS с этой машины серверу DNS на другой машине.
Сначала устанавливается сервер DNS на бастионном хосте, с которым сможет общаться внешний мир. Этот сервер устанавливается так, что объявляет себя авторитетным для ваших доменов. Фактически, это сервер знает только то, что вы хотите поведать внешнему миру: имена и адреса шлюзов, шаблонные записи MX и т.п. Это "общедоступный" сервер.
Затем, устанавливается сервер DNS на внутренней машине. Этот сервер также объявляет себя авторитетным для ваших доменов, но, в отличие от общедоступного, говорит правду. Это будет "обычный" сервер имен, на котором устанавливаются все "обычные" записи DNS. Сервер надо настроить так, чтобы он пересылал запросы, которые не может разрешить, общедоступному серверу (например, с помощью строки "forwarders" в файле /etc/named.boot на Unix-машине).
Наконец, все клиенты DNS, включая работающих на машине с общедоступным сервером, необходимо настроить (в файле /etc/resolv.conf на Unix-машине, например) так, чтобы они использовали внутренний сервер имен. В этом-то все и дело.
Запрос внутреннего клиента о внутреннем хосте попадает на внутренний сервер, который и возвращает ответ; запрос внутреннего клиента о внешнем хосте попадает на внутренний сервер, который запрашивает общедоступный, в свою очередь, запрашивающий Internet, а ответ перенаправляется обратно. Запросы клиента на общедоступном сервере обрабатываются точно так же. Однако, внешний клиент, запрашивающий внутренний хост, получает "ограниченный" ответ от общедоступного сервера.
Этот подход предполагает наличие между этими двумя серверами имен брандмауэра, фильтрующего пакеты и позволяющего им взаимодействовать по протоколу DNS, но ограничивающего взаимодействие по DNS других хостов.
Еще один полезный при таком подходе фокус, -- использовать шаблонные записи PTR в доменах IN-ADDR.ARPA. В результате, поиск имени по адресу для любого из ваших не общедоступных хостов будет возвращать что-то типа "unknown.YOUR.DOMAIN", а не ошибку. Этого достаточно для анонимных FTP-сайтов, вроде ftp.uu.net, требующих наличия имен для машин, с которыми они взаимодействуют. Этого может оказаться недостаточно при взаимодействии с сайтами, выполняющими перекрестную проверку имен DNS, когда имя хоста сопоставляется с адресом и наоборот.
В общем случае, работа по протоколу FTP через брандмауэр обеспечивается либо с помощью промежуточного сервера, такого как ftp-gw из набора инструментальных средств Firewall Toolkit, либо путем разрешения входящих подключений к ограниченному диапазону портов и ограничения входящих подключений с помощью экранирующих правил типа "только установленные подключения". Затем FTP-клиент изменяется так, чтобы связывать порт данных с одним из портов в сконфигурированном диапазоне. Для этого надо иметь возможность изменять клиентские приложения FTP на внутренних хостах.
В некоторых случаях, если необходимо поддерживать только загрузку по FTP, можно объявить протокол FTP "мертвым" и предложить пользователям вместо этого загружать файлы через Web. Пользовательский интерфейс, определенно, красивее, да и устраняется неприятная проблема порта для обратного вызова. Если выбран подход FTP-через-Web, пользователи не смогут выгружать файлы по FTP, что может представлять проблему, в зависимости от стоящих перед ними задач.
Другой подход состоит в использовании опции "PASV" протокола FTP, показывающей, что удаленный FTP-сервер должен позволить клиенту инициировать подключения. Подход на базе PASV предполагает, что FTP-сервер на удаленной системе поддерживает такой режим работы. (См. "Firewall-Friendly FTP" в [1].)
В некоторых организациях предпочитают создавать версии клиентских программ FTP, скомпонованные с библиотекой SOCKS.
Протокол Telnet обычно поддерживается либо с помощью промежуточного сервера, такого как tn-gw из набора инструментальных средств Firewall Toolkit, либо путем конфигурирования маршрутизатора так, чтобы он разрешал исходящие подключения с применением экранирующих правил типа "только установленные подключения". Можно использовать как отдельные промежуточные серверы, так и сервер SOCKS с измененными клиентами.
Многие администраторы брандмауэров разрешают подключения к порту finger только с пользующихся доверием машин, которые могут выдавать запросы finger вида finger пользователь@хост.домен@брандмауэр. Этот подход работает только со стандартными Unix-версиями программы finger. Управление доступом к службам и ограничение их доступности только для определенных машин выполняется с помощью либо tcp_wrappers, либо программы netacl из набора инструментальных средств Firewall Toolkit. Этот подход работает не для всех систем, поскольку некоторые серверы finger не разрешают поиск по запросам вида пользователь@хост@хост.
Многие сайты блокируют входящие запросы finger по ряду причин, важнейшей из которых являются прежние ошибки защиты в сервере finger (Internet-червь Морриса сделал эти ошибки знаменитыми) и риск раскрытия важной или конфиденциальной информации при выдаче информации о пользователе программой finger. Однако, в общем случае, если ваши пользователи привыкли помещать важную или конфиденциальную информацию в общедоступные файлы (their .plan files), то у вас куда более серьезная проблема защиты, чем решаемые с помощью брандмауэра.
Большинство администраторов брандмауэров предпочитают поддерживать службы gopher и archie не напрямую, а через промежуточный Web-сервер. Промежуточный сервер, такой как http-gw из набора инструментальных средств Firewall Toolkit, преобразуют запросы gopher/gopher+ в HTML и наоборот. Для поддержки archie и других запросов многие сайты предлагают использовать имеющиеся в Internet серверы Web-to-archie, такие как ArchiePlex. Тенденция Web представить все имеющееся в Internet как Web-службу, -- благо и проклятие сети одновременно.
Постоянно появляется много новых служб. Часто они спроектированы неудачно или без учета защиты, а их разработчики любезно сообщат вам, что если вы хотите их использовать, необходимо пропускать пакеты на порт xxx через маршрутизатор. К сожалению, не все могут это сделать, поэтому множество интересных новых игрушек трудно использовать тем, кто работает из-за брандмауэров. Программы типа RealAudio, требующие непосредственного доступа по UDP, являются особенно вопиющими примерами. При возникновении одной из подобных проблем не забудьте узнать как можно больше об угрозах для защиты, которые может представлять соответствующая служба, прежде чем просто разрешить прохождение ее пакетов. Вполне возможно, служба не несет никаких угроз защите. Но точно так же возможно, что в ней есть не выявленные дыры, через которые можно проехать на грузовике.
Оконная система X Window System очень полезна, но, к сожалению, имеет ряд существенных недостатков с точки зрения защиты. Удаленные системы, которые смогут получить или сымитировать доступ к X-дисплею рабочей станции, могут отслеживать все нажатия пользователя на клавиши, загружать копии содержимого окон и т.д.
Хотя делались попытки устранить эти проблемы (например, MIT "Magic Cookie"), но по-прежнему атакующий сравнительно просто может взаимодействовать с X-дисплеем пользователя. Большинство брандмауэров блокирует все пакеты X. Некоторые разрешают работать с X через промежуточные серверы типа DEC CRL X proxy (FTP crl.dec.com). Набор инструментальных средств Firewall Toolkit включает промежуточный X-сервер, x-gw, который пользователь может вызывать через промежуточный сервер Telnet для создания виртуального X-сервера на брандмауэре. При поступлении запросов на подключение по X-протоколу к виртуальному X-серверу пользователю выдается всплывающее окно, где необходимо подтвердить или запретить подключение. Хотя это слегка не эстетично, но вполне согласуется с остальными особенностями оконной системы X.
Компания RealNetworks предоставляет определенную информацию о том, как обеспечить работу RealAudio через брандмауэр. Было бы неразумно делать любые изменения в правилах брандмауэра не понимая, что же в точности эти изменения дают и какие новые угрозы они создают.
Лучший способ для этого -- разрешить очень ограниченное взаимодействие между Web-сервером и сервером баз данных по специфическому протоколу, поддерживающему только тот уровень функциональности, который предполагается использовать. Разрешение выполнять произвольные SQL-операторы или предоставление любой другой возможности для атакующего выполнять непредусмотренные запросы -- обычно не лучшая идея.
Предположим, атакующий сможет взломать Web-сервер и выполнять запросы точно так же, как и Web-сервер. Имеется ли механизм для извлечения секретной информации, не нужной Web-серверу, например, информации о кредитных карточках? Может ли атакующий выполнить SQL-запрос и получить всю вашу конфиденциальную базу данных?
Приложения "электронной коммерции", как и все прочие, лучше с самого начала проектировать с учетом защиты, а не "добавлять" защиту постфактум. Критически оцените выбранную архитектуру, рассмотрите ее с точки зрения атакующего. Предположим, что атакующий знает все об архитектуре. Теперь спросите себя, что надо сделать, чтобы украсть данные, выполнить несанкционированные изменения или сделать что-либо другое, чего бы вам не хотелось допустить. Может оказаться, что защиту можно существенно усилить, не уменьшая функциональность, за счет всего нескольких проектных и реализационных решений.
Вот несколько идей, как решать эту задачу:
Если принятые на сайте правила работы брандмауэра настолько свободны, что вы можете пойти на риск и согласиться с тем, что некто воспользуется уязвимым местом этого Web-сервера и получит частичный или полный доступ к базе данных, то практически ничто не мешает именно так и сделать.
Однако во многих организациях специалисты, отвечающие за подключение Web-интерфейса к базе данных, просто не имеют достаточных полномочий, чтобы брать на себя такую ответственность. Более того, если база данных содержит информацию о людях, может оказаться, что вы нарушаете ряд законов, не предприняв все разумные меры предосторожности для предотвращения несанкционированного использования системы.
В общем случае, это не лучшая идея. В ответе на вопрос 5.11 можно найти ряд идей о других способах достижения той же цели.
Многоадресная IP-передача (IP multicast) -- это способ передачи IP-пакетов с одного хоста нескольким хостам без использования широковещательной передачи; т.е. вместо получения пакетов каждым хостом, их получат только желающие, и для этого каждому не потребуется поддерживать отдельное соединение с сервером. Одноадресная передача (IP unicast), -- это когда один хост взаимодействует с другим, многоадресная (multicast), -- когда один хост взаимодействует с подмножеством хостов, а широковещательная (broadcast), -- когда один хост взаимодействует со всеми хостами в подсети.
Общедоступная сеть Internet имеет многоадресную информационную магистраль (multicast backbone -- "Mbone"), которую пользователи могут применять для многоадресного обмена информацией. Обычно Mbone используется для потоков данных телеконференций и других подобных взаимодействий. Подключение чьей-либо сети к магистрали Mbone потребует от провайдера верхнего уровня маршрутизировать многоадресные пакеты в и из этой сети. Кроме того, такая внутренняя сеть должна поддерживать многоадресную маршрутизацию (multicast routing).
Роль брандмауэра при многоадресной маршрутизации концептуально не отличается от ее роли при маршрутизации других пакетов. Т.е. необходимо задать правила, определяющие, какие многоадресные группы допустимы и недопустимы, а затем должна быть придумана система, разрешающая передачу информации в соответствии с правилами. Подробное описание того, как это сделать, выходит за рамки этого документа. К счастью, рабочий документ RFC 2588 [2] освещает эту тему значительно подробнее. Если только используемая система брандмауэра не поддерживает средства избирательного многоадресного перенаправления и у вас нет возможности добавить такие средства самостоятельно, может оказаться, что организовать перенаправление многоадресных пакетов в соответствии с принятыми правилами защиты настолько сложно, что этим не стоит заниматься.
Эта тема кажется нам слишком щепетильной, чтобы рассматривать ее в этом документе, но независимо поддерживаемый список (никаких гарантий и рекомендаций) можно найти в сети.
Это приложение начнется со сравнительно "простого" уровня, так что если даже начальные сведения покажутся вам детскими и самоочевидными, вы, вероятно, сможете почерпнуть нечто полезное из дальнейшего текста.
"Порт" - это "виртуальный слот" в стеке протоколов TCP и UDP, используемый для организации подключения между двумя хостами, а также между уровнем TCP/UDP и фактическими приложениями, работающими на хостах.
Порты нумеруются целыми числами в диапазоне 0-65535, причем диапазон 0-1023 считается "зарезервированным" или "привилегированным", а остаток (диапазон 1024-65535) - "динамическим" или "непривилегированным".
Порты можно использовать двумя основными способами:
Динамические порты также могут использоваться как порты для "прослушивания" в некоторых приложениях, в частности, в FTP.
Порты с номерами 0-1023 почти всегда - серверные. Порты в диапазоне 1024-65535 обычно - динамические (т.е. открываются динамически при подключении к серверному порту). Однако, любой порт может использоваться как серверный и любой порт может использоваться как порт для "исходящих" пакетов.
Итак, обобщая, при простом подключении происходит следующее:
Имеется несколько списков, определяющих "зарезервированные" и "широко известные" порты, а также "обычно используемые" порты, и лучший из них можно получить по адресу ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. Те, кто для поиска описания назначения портов обращается к рабочему документу RFC 1700, -- ПЕРЕСТАНЬТЕ ЭТО ДЕЛАТЬ. Он страшно устарел, и завтра он менее старым не станет. Теперь относительно надежности подобной информации: эти списки ни в коей мере не являются критерием истины в отношении назначения портов.
Перефразирую вышесказанное: НЕТ СПОСОБА НАДЕЖНО ОПРЕДЕЛИТЬ НАЗНАЧЕНИЕ ПОРТОВ ПРОСТО ПРОСМАТРИВАЯ ТОТ ИЛИ ИНОЙ СПИСОК.
Пусть вы выполнили на машине команду "netstat -a", и порты 1025 и 1030 показаны как LISTEN. Что они делают?
Итак, давайте посмотрим на список выделенных номеров портов.
blackjack 1025/tcp network blackjack
iad1 1030/tcp BBN IAD
Подождите, что же происходит? Что: рабочая станция подсмотрела номер кредитной карточки и решила поиграть в очко с неким сервером в internet? И что это за программа была установлена BBN?
В этот момент НЕ НАДО начинать паниковать и посылать сообщения в списки рассылки по брандмауэрам. Фактически, этот вопрос задавался раз десять за последние полгода, и каждый раз на него отвечали. Но даже ЭТО не мешает людям задавать тот же вопрос вновь.
Если вы задаете такой вопрос, скорее всего, вы работаете на машине под управлением Windows. Порты, которые вы видите (скорее всего), -- два прослушивающих порта, которую подсистема RPC открывает при запуске.
Это пример того, как динамически выделяемые порты могут использоваться серверными процессами. Приложения, использующие механизм RPC, в дальнейшем подключаются к порту 135 ("сопоставитель портов" -- `portmapper -- netbios) с запросом, где можно найти ту или иную службу RPC, и получают ответ, что соответствующая служба может быть найдена на порту 1025.
Откуда мы это знаем, ведь "списка", описывающего эти порты, нет? Это просто: опыт ничем не заменишь. Сильно помогает и использование средств поиска по спискам рассылки.
Раз нельзя понять, что делает тот или иной порт, просто изучая список, как же это сделать?
Старый проверенный способ сделать это - останавливать каждую службу/демон,
работающую на машине, выполнять команду netstat -a и смотреть,
какие порты открыты. Прослушивающих портов не должно быть очень много.
Затем начинаем включать все службы снова, по одной, и обращаем внимание на новые порты,
появляющиеся в результатах выполнения netstat.
Другой способ, требующий больше интеллектуальных усилий, -- просто подключаться с помощью
программы telnet к портам и смотреть, что получается в ответ. Если ответа нет,
попытайтесь ввести произвольный набор символов и несколько раз нажать клавишу Enter,
наблюдая, не будет ли какого-нибудь ответа. Если получаете двоичный "мусор"
или просто не получаете ничего, значит, такой подход вам, очевидно, не поможет. :-)
Однако это позволит определить только используемые прослушивающие порты. Ничего нельзя будет узнать о динамически открываемых портах, которые могут открываться в дальнейшем соответствующими приложениями.
Есть несколько приложений, которые могут помочь определить используемые порты.
В системах Unix есть хорошая утилита lsof, часто входящая в
базовый дистрибутив. Она показывает номера всех открытых портов и имена приложений,
их использующих. Это означает, что она может показать множество локально открытых файлов,
а также сокетов TCP/IP. Читайте справочное руководство. :-)
В системах Windows в составе базового дистрибутива нет ничего, что может помочь в решении данной задачи. (Что тут удивительного?) Есть утилита "Inzider", устанавливающаяся на уровне сокетов Windows и динамически запоминающая, какие порты открывают процессы. Недостаток этого подхода состоит в том, что он не позволяет определить, какие порты были открыты перед запуском программы inzider, но это лучшее, что можно получить в Windows (насколько я знаю). http://ntsecurity.nu/toolbox/inzider/.
КО ВСЕМ.
Нет, подождите, НЕТ ТАКИХ ПОРТОВ.
Ой, нет, уффф... Я слышал, что все порты, начиная с 1024, безопасны, поскольку они являются исключительно динамическими??
Нет. Действительно. НЕЛЬЗЯ сказать, какие порты безопасны, основываясь только на номерах, поскольку номер - это просто номер. Нельзя организовать атаку через 16-битовый номер.
Безопасность "порта" зависит от приложения, с которым происходит взаимодействие через этот порт.
Типичное ошибочное представление состоит в том, что обращения к портам 25 (SMTP) и 80 (HTTP) можно безопасно пропускать через брандмауэр. Это НЕПРАВИЛЬНО. То, что все так делают, еще не значит, что это безопасно.
Повторяю, безопасность порта зависит от приложения, с которым происходит взаимодействие через этот порт.
Если используется хорошо написанный Web-сервер, изначально проектировавшийся с учетом защиты, вы, вероятно, достаточно обоснованно можете считать безопасным разрешение доступа к нему внешних пользователей через порт 80. В противном случае, так считать НЕЛЬЗЯ.
Проблема здесь возникает не на уровне сети. Суть в том, как приложение обрабатывает получаемые данные. Эти данные могут быть получены через порт 80, порт 666, по последовательной линии, на дискете или в виде телеграммы азбукой Морзе. Если приложение не безопасно, не имеет значения, как к нему попадают данные. Реальная опасность таится в данных приложения.
Если вас интересует безопасность используемого приложения, подпишитесь на рассылки bugtraq или попытайтесь изучить их архивы.
Эта проблема в большей степени связана с защитой приложения, а не с защитой брандмауэра. Можно утверждать, что брандмауэр должен останавливать все возможные атаки, но с учетом количества новых сетевых протоколов, спроектированных БЕЗ учета защиты, и сетевых приложений, также разрабатывавшихся без учета защиты, брандмауэр просто не может защитить от всех атак, управляемых данными.
Или: "Почему необходимо открывать все порты, начиная с 1024, для FTP-сервера?".
С точки зрения использования сети протокол FTP во многом отличается от других приложений.
Он поддерживает один прослушиваемый порт, порт 21, к которому подключаются пользователи. Он только позволяет пользователям зарегистрироваться и установить ДРУГОЕ подключение для выполнения фактической передачи данных. Это второе подключение обычно выполняется через порт с номером, начиная с 1024.
Сервер FTP имеет два режима работы, "активный" (обычный) и "пассивный". Эти слова характеризуют поведение сервера.
В активном режиме клиент (5.6.7.8) подключается к порту 21 на сервере (1.2.3.4) и регистрируется. Когда требуется передача файлов, клиент выделяет динамический порт с номером большим или равным 1024, информирует сервер о том, какой порт открыт, а затем сервер открывает новое подключение к этому порту. Это "активная" роль сервера: он активно устанавливает новые подключения к клиентам.
В пассивном режиме, подключение к порту 21 выполняется аналогично. Когда требуется передача файлов, СЕРВЕР выделяет динамический порт с номером, начиная с 1024, информирует клиента о том, какой порт открыт, а затем КЛИЕНТ открывает новое подключение к этому порту. Это "пассивная" роль сервера: он ждет установки клиентом второго подключения (для передачи данных).
Если брандмауэр не проверяет данные, передаваемые по управляющему подключению FTP, он не узнает, что необходимо динамически открывать новые порты с номерами, начиная с 1024.
Примечание: традиционное поведение FTP-серверов в активном режиме - устанавливать сеанс передачи данных С порта 20 на динамический порт клиента. FTP-серверы постепенно отходят от такого поведения, поскольку в Unix-системах чтобы иметь возможность выделять порты с номерами менее 1024 необходимо работать от имени пользователя "root". Работать же от имени пользователя "root" не очень хорошо с точки зрения защиты, поскольку при выявлении ошибки в программном обеспечении атакующий сможет получить полный контроль над машиной. То же верно и для работы от имени пользователей "Administrator" или "SYSTEM" ("LocalSystem") на NT-машинах, хотя под NT проблемы привилегированных портов нет.
Подводя итоги, если ваш брандмауэр понимает протокол FTP, он сможет разобраться с подключениями для передачи данных самостоятельно, и вам не придется заботиться о портах с номерами, большими 1024.
Если же НЕТ, вам придется решить четыре проблемы:
Повторю еще раз, если брандмауэр понимает протокол FTP, ни одной из этих четырех проблем не возникает. Пусть все делает брандмауэр.
Какой режим использовать, зависит от клиента; при открытие нового подключения стандартный режим - активный.
Большинство FTP-клиентов первоначально сконфигурированы для использования активного режима, но предлагают опцию для использования "пассивного" ("PASV") режима. Исключением является только клиент командной строки в Windows, работающий только в активном режиме.
Web-браузеры обычно при подключении по FTP используют пассивный режим, за одним странным исключением: MSIE 5 будет использовать активный режим FTP при подключении по FTP в режиме просмотра файлов ("File Explorer") и пассивный режим при подключении по FTP в режиме Web-страницы ("Web Page"). Особых причин для такого поведения нет; мне кажется, что кто-то в Рэдмонде, ничего не знающий о протоколе FTP, просто решил, что "Конечно, надо использовать активный режим при работе в режиме просмотра файлов, поскольку он выглядит более активным, чем Web-страница". Решайте сами.
Судя по журналам брандмауэра, мой Web-сервер пытается подключиться с порта 80 к портам с номерами, большими 1024 на внешних серверах. Что происходит?!
Если регистрируются отброшенные пакеты с порта 80 Web-сервера (или с порта 25 почтового сервера) на непривилегированные порты внешних серверов, это обычно НЕ ОЗНАЧАЕТ, что ваш Web-сервер пытается подключиться куда бы то ни было.
Они появляются в результате того, что брандмауэр отключает подключение как простаивающее, и сервер пытается повторно передать старые ответы клиенту (или закрыть подключение).
Подключения по TCP всегда требуют передачи пакетов в ОБОИХ направлениях.
Если просмотреть флаги TCP в отброшенных пакетах, то окажется, что установлен флаг ACK, но не флаг SYN, тем самым, это, фактически, не организация нового подключения, а ответ на ранее установленное подключение.
См. раздел 9 ниже, где подробно объясняется, что происходит при организации (и закрытии) подключения по протоколу TCP.
Протокол TCP поддерживает 6 "флагов", которые могут быть установлены (ON) или сброшены (OFF). Вот эти флаги:
Рассмотрим пример, когда клиент работает на хосте 5.6.7.8 и получил динамический порт 1049. Сервер работает на порту 80 хоста 1.2.3.4.
Клиент начинает попытку подключения:
5.6.7.8:1049 -> 1.2.3.4:80 SYN=ON
Сервер получает этот пакет и понимает, что кто-то хочет организовать новое подключение. Посылается ответ:
1.2.3.4:80 -> 5.6.7.8:1049 SYN=ON ACK=ON
Клиент получает ответ и информирует сервер, что ответ получен:
5.6.7.8:1049 -> 1.2.3.4:80 ACK=ON
Теперь подключение открыто. Это называется трехходовым согласованием (three-way handshake). Его назначение - удостоверить ОБА хоста, что между ними установлено действующее подключение.
В сети Internet, ненадежной и переполненной, необходимы средства, компенсирующие потерю пакетов.
Если клиент посылает начальный пакет SYN и не получает пакет с флагами SYN+ACK в течение нескольких секунд, он посылает пакет SYN повторно.
Если сервер посылает пакет SYN+ACK и не получает пакет с флагом ACK в течение нескольких секунд, он посылает пакет SYN+ACK повторно.
Именно последнее является причиной, по которой атаки путем переполнения SYN-пакетами так хорошо работают. Если посылать пакеты SYN от множества различных портов, это потребует существенных ресурсов сервера. Если также отказаться отвечать на полученные в ответ пакеты SYN+ACK, сервер будет долго СОХРАНЯТЬ эти подключения, повторно посылая пакеты SYN+ACK. Некоторые серверы перестают принимать новые подключения при наличии достаточного количества формирующихся, вот почему атаки путем переполнения SYN-пакетами (SYN flooding) работают.
Все пакеты, передаваемые в обоих направлениях после трехходового согласования, будут иметь установленный бит ACK. Фильтры пакетов, не поддерживающие информацию о состоянии, используют эту особенность в так называемых фильтрах "установленных подключений". Они будут пропускать только пакеты с установленным битом ACK. При этом в определенном направлении не смогут проходить пакеты, способные организовать новое подключение. Обычно не разрешают открывать новые подключения с внешних хостов на внутренние, требуя установленного бита ACK во входящих пакетах.
Когда приходит время закрывать подключение, это можно сделать двумя способами. С помощью флага FIN или с помощью флага RST. При использовании флагов FIN обе стороны подключения должны послать пакеты с установленными флагами FIN, чтобы показать, что они собираются закрыть подключение, а затем послать подтверждения на эти FIN-пакеты, показывающие, что они поняли намерение противоположной стороны подключения закрыть его. При посылке пакетов RST подключение закрывается принудительно и вы не получаете информации о том, поняла ли противоположная сторона ваше требование о закрытии подключения и получила ли она на самом деле все посланные ей данные.
Закрытие подключения с помощью FIN-пакетов также может привести к ситуации отказа служб, поскольку стек TCP должен сравнительно надолго запоминать закрытые подключения на случай, когда другая сторона не получила одного из FIN-пакетов.
Если открыть и закрыть достаточно много подключений, в конечном итоге можно получить "закрытые" подключения во всех имеющихся слотах, описывающих подключения. В этом случае вы не сможете динамически выделять новые подключения, ибо все возможные уже использованы. Различные операционные системы по-разному реагируют на эту ситуацию.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |