О документе
Рабочая группа по сетям T. Killalea
Запрос на комментарии: 3013 neart.org
BCP: 46 Ноябрь 2000
Категория: Лучшая современная практика
Рекомендуемые службы и процедуры безопасности для интернет-провайдеров
1 Введение
Цель этого документа — изложить ожидания инженерного сообщества,
представленного IETF, в отношении безопасности от интернет-провайдеров
(ISPs). Этот документ адресован ISPs.
Информируя ISPs о том, на что это сообщество надеется и чего от них
ожидает, сообщество надеется побудить ISPs заблаговременно сделать
безопасность не только приоритетом, но и предметом, которым они с
гордостью будут указывать при продаже своих услуг.
Ни при каких обстоятельствах данный документ не предназначен для
предписывания деловой практики.
В данном документе мы определяем ISPs как организации, занимающиеся
предоставлением подключения к Интернету или иных интернет-услуг,
включая, но не ограничиваясь ими, услуги веб-хостинга, поставщиков
контента и услуги электронной почты. Мы не включаем в наше определение
ISP организации, предоставляющие такие услуги для собственных целей.
Этот документ предлагается как набор рекомендаций ISPs относительно
того, какие меры безопасности и управления атаками следует поддерживать,
а также как совет пользователям относительно того, чего им следует
ожидать от высококачественного поставщика услуг. Сам по себе он ни в
каком смысле не является нормативным. Со временем он, вероятно,
устареет и могут возникнуть другие ожидания. Однако он представляет
собой снимок рекомендаций группы специалистов в данной области на
определённый момент развития Интернета и его технологий.
1.1 Соглашения, используемые в данном документе
Ключевые слова «REQUIRED», «MUST», «MUST NOT», «SHOULD», «SHOULD NOT»
и «MAY» в данном документе следует толковать так, как описано в «Key
words for use in RFCs to Indicate Requirement Levels» [RFC2119].
2 Коммуникация
Наиболее существенные ожидания сообщества в отношении безопасности,
предъявляемые к ISPs, связаны с доступностью каналов связи для работы
с инцидентами безопасности.
2.1 Контактная информация
ISPs СЛЕДУЕТ (SHOULD) соблюдать [RFC2142], который определяет почтовый
ящик SECURITY для вопросов сетевой безопасности, ABUSE для вопросов,
связанных с недопустимым поведением в публичной среде, и NOC для
вопросов, связанных с сетевой инфраструктурой. В нём также перечислены
дополнительные почтовые ящики, определённые для приёма запросов и
сообщений, относящихся к конкретным услугам.
ISPs могут рассмотреть возможность использования общих URL для
расширенной информации по указанным выше вопросам (например,
http://www.ISP-name-here.net/security/).
Кроме того, ISPs обязаны обеспечивать, чтобы их контактная информация
в Whois, в реестрах маршрутизации [RFC1786] или в любом другом
хранилище была полной, точной и доступной.
2.2 Обмен информацией
ISPs СЛЕДУЕТ (SHOULD) иметь чёткие политики и процедуры обмена
информацией об инциденте безопасности со своими заказчиками, другими
ISPs, группами реагирования на инциденты, правоохранительными органами,
прессой и широкой общественностью.
ISPs следует иметь действующие процессы для обработки инцидентов
безопасности, пересекающих границы между ними и другими ISPs.
2.3 Защищённые каналы
ISPs СЛЕДУЕТ (SHOULD) быть способны осуществлять такую коммуникацию по
защищённому каналу. Однако следует отметить, что в некоторых
юрисдикциях защищённые каналы могут быть не разрешены.
2.4 Уведомление об уязвимостях и сообщение об инцидентах
ISPs СЛЕДУЕТ (SHOULD) заблаговременно уведомлять заказчиков об
уязвимостях безопасности в предоставляемых ими услугах. Кроме того,
по мере обнаружения новых уязвимостей в системах и программном
обеспечении им следует указывать, подвержены ли их услуги этим рискам.
Когда происходят инциденты безопасности, затрагивающие компоненты
инфраструктуры ISP, ISP следует незамедлительно сообщать своим
заказчикам:
- кто координирует реагирование на инцидент;
- об уязвимости;
- как была затронута услуга;
- что делается для реагирования на инцидент;
- могли ли быть скомпрометированы данные заказчика;
- что делается для устранения уязвимости;
- ожидаемый график реагирования, если его можно предсказать.
Многие ISPs установили процедуры уведомления заказчиков о сбоях и
ухудшении качества услуг. ISP разумно использовать эти каналы для
сообщений об инцидентах, связанных с безопасностью. В таких случаях
контактное лицо заказчика по вопросам безопасности может не быть тем
лицом, которое получает уведомление. Вместо этого сообщение получит
обычное контактное лицо. Заказчикам следует знать об этом и обеспечить
надлежащую маршрутизацию таких уведомлений.
2.5 Реагирование на инциденты и группы реагирования на инциденты
компьютерной безопасности (CSIRTs)
Группа реагирования на инциденты компьютерной безопасности (CSIRT) —
это группа, которая выполняет, координирует и поддерживает реагирование
на инциденты безопасности, затрагивающие площадки в пределах
определённой области обслуживания. Ожидания интернет-сообщества в
отношении CSIRTs описаны в «Expectations for Computer Security
Incident Response» [RFC2350].
Независимо от того, имеет ли ISP CSIRT, у него должен быть широко
объявленный способ принимать и обрабатывать сообщения об инцидентах от
своих заказчиков. Кроме того, ему следует чётко документировать свои
возможности реагирования на сообщённые инциденты и указывать, имеется
ли CSIRT, область обслуживания которой включала бы заказчика и которой
можно было бы сообщать об инцидентах.
Некоторые ISPs имеют CSIRTs. Однако не следует предполагать, что как
заказчики подключения ISP, так и площадка, подвергающаяся атаке со
стороны заказчика этого ISP, могут автоматически воспользоваться
услугами CSIRT ISP. CSIRTs ISP часто предоставляются как услуга за
дополнительную плату, причём группа определяет своей областью
обслуживания только тех, кто специально подписался на услуги
реагирования на инциденты (и, возможно, оплачивает их).
Поэтому ISPs важно публиковать сведения о том, какие ресурсы
реагирования на инциденты и безопасности они предоставляют заказчикам,
чтобы заказчики могли определить свою цепочку эскалации реагирования
на инциденты ДО возникновения инцидента.
Заказчикам следует выяснить, есть ли у их ISP CSIRT, и если есть, каковы
мандат, политики и услуги этой группы. Эту информацию лучше всего
представлять с использованием шаблона CSIRT, приведённого в Приложении D
документа «Expectations for Computer Security Incident Response»
[RFC2350].
3 Политика допустимого использования
Каждому ISP СЛЕДУЕТ (SHOULD) иметь Политику допустимого использования
(AUP).
Когда ISP заключает с заказчиком договор о предоставлении подключения
к Интернету, этот договор следует регулировать AUP. AUP следует
пересматривать при каждом продлении договора, и, кроме того, ISP следует
заблаговременно уведомлять заказчиков при обновлении политик.
AUP должна чётко определять, что заказчики должны и не должны делать на
различных компонентах системы или сети, включая тип трафика, разрешённый
в сетях. AUP следует быть настолько явной, насколько возможно, чтобы
избежать неоднозначности или недопонимания. Например, AUP может
запрещать IP spoofing.
3.1 Объявление политики
Помимо доведения своей AUP до заказчиков, ISPs следует публиковать свою
политику в общедоступном месте, например на своём веб-сайте, чтобы
сообщество знало, что ISP считает допустимым, и могло знать, каких
действий ожидать при недопустимом поведении.
3.2 Санкции
AUP должна ясно указывать, какие санкции будут применяться при
недопустимом поведении.
3.3 Защита данных
Во многих юрисдикциях действует законодательство о защите данных. Там,
где такое законодательство применяется, ISPs следует рассматривать
хранимые ими персональные данные и, при необходимости, регистрироваться
в качестве контролёров данных (Data Controllers), а также быть готовы
использовать данные только в соответствии с условиями законодательства.
Учитывая глобальную природу Интернета, ISPs, расположенным там, где
такого законодательства нет, следует как минимум ознакомиться с идеей
защиты данных, прочитав типичный Закон о защите данных (например,
[DPR1998]).
4 Сетевая инфраструктура
ISPs несут ответственность за управление сетевой инфраструктурой
Интернета таким образом, чтобы она была:
- в разумной степени устойчива к известным уязвимостям безопасности;
- не могла быть легко захвачена злоумышленниками для использования
в последующих атаках.
4.1 Ведение данных реестров
ISPs обычно отвечают за ведение данных, хранящихся в глобальных
хранилищах, таких как Internet Routing Registry (IRR) и базы данных
APNIC, ARIN и RIPE. Обновление этих данных должно быть возможно только
с использованием строгой аутентификации.
ISPs следует публично регистрировать адресное пространство, которое они
назначают своим заказчикам, чтобы для делегированного пространства была
доступна более конкретная контактная информация.
4.2 Инфраструктура маршрутизации
Возможность ISP маршрутизировать трафик к правильному назначению может
зависеть от политики маршрутизации, настроенной в реестрах маршрутизации
[RFC1786]. Если это так и если реестр это поддерживает, им следует
обеспечивать, чтобы поддерживаемая ими информация реестра могла
обновляться только с использованием строгой аутентификации и чтобы
полномочия на внесение обновлений были надлежащим образом ограничены.
Следует также проявлять должную осторожность при определении, чьим
объявлениям маршрутизации вы оказываете большее доверие, когда к месту
назначения доступны варианты маршрутов. В прошлом подложные объявления
приводили к тому, что трафик попадал в «чёрную дыру» или, что хуже,
перехватывался.
Аутентификацию BGP [RFC2385] СЛЕДУЕТ (SHOULD) использовать с соседями
по маршрутизации.
4.3 Входная фильтрация по адресу источника
Направление такой фильтрации — от периферийной площадки (заказчика) к
Интернету.
Злоумышленники часто скрывают свои следы, используя подделанные адреса источника. Чтобы отвлечь внимание от собственного узла, они обычно выбирают адрес источника невиновного удалённого узла либо адреса, выделенные для частных Internet [RFC1918]. Кроме того, подделанные адреса источника часто используются в атаках на основе спуфинга, чтобы воспользоваться отношением доверия между хостами.
Чтобы сократить число атак, основанных на подделанных адресах источника, ISP следует выполнить следующее. На пограничном маршрутизаторе, соединяющем ISP с каждым клиентом, им следует проактивно фильтровать весь трафик, поступающий от клиента, если его адрес источника не является одним из адресов, выделенных этому клиенту. Более подробное обсуждение этой темы приведено в [RFC2827].
Существуют (редкие) обстоятельства, при которых входная фильтрация в настоящее время невозможна, например на крупных маршрутизаторах агрегации, которые не могут принять дополнительную нагрузку от применения пакетных фильтров. Кроме того, такая фильтрация может создавать трудности для мобильных пользователей. Поэтому, хотя применение этого метода для предотвращения спуфинга настоятельно рекомендуется, оно не всегда может быть осуществимо.
В этих редких случаях, когда входная фильтрация на интерфейсе между клиентом и ISP невозможна, клиента следует побуждать внедрить входную фильтрацию в своих сетях. В общем случае фильтрацию следует выполнять как можно ближе к фактическим хостам.
4.4 Исходящая фильтрация по адресу источника
Направление такой фильтрации — из Internet к граничному узлу (клиенту).
Сегодня в Internet широко применяются многие приложения, которые предоставляют доверие другим хостам, основываясь только на IP-адресе (например, команды Berkeley 'r'). Они подвержены IP-спуфингу, как описано в [CA-95.01.IP.spoofing]. Кроме того, существуют уязвимости, зависящие от неправомерного использования предположительно локальных адресов, например 'land', описанная в [CA-97.28.Teardrop_Land].
Чтобы уменьшить подверженность своих клиентов атакам, основанным на подделанных адресах источника, ISP следует выполнить следующее. На пограничном маршрутизаторе, соединяющем ISP с каждым клиентом, им следует проактивно фильтровать весь трафик, направляемый клиенту, если его адрес источника относится к любому из адресов, выделенных этому клиенту.
Обстоятельства, описанные в 4.3, при которых входная фильтрация неосуществима, аналогично применимы к исходящей фильтрации.
4.5 Фильтрация маршрутов
Чрезмерные обновления маршрутизации могут быть использованы злоумышленником как базовая нагрузка, на которой строится атака типа отказ в обслуживании. Как минимум они приведут к ухудшению производительности.
ISP следует фильтровать получаемые ими объявления маршрутов, например игнорировать маршруты к адресам, выделенным для частных Internet, избегать ложных маршрутов, а также реализовать «BGP Route Flap Dampening» [RFC2439] и политику агрегации.
ISP следует реализовать методы, уменьшающие риск создания чрезмерной нагрузки на маршрутизацию в других частях сети. К ним относятся «намертво закреплённые» маршруты, агрессивная агрегация и подавление колебаний маршрутов; все они уменьшают влияние на других, когда внутренняя маршрутизация изменяется способом, не имеющим к ним отношения.
4.6 Направленная широковещательная рассылка
Протокол IP допускает направленную широковещательную рассылку: отправку пакета через сеть для последующей широковещательной рассылки в конкретной подсети. У этой возможности существует очень мало практических применений, однако её используют несколько различных атак безопасности (прежде всего атаки типа отказ в обслуживании, использующие эффект умножения пакетов при широковещательной рассылке). Поэтому маршрутизаторы, подключённые к широковещательной среде, НЕ ДОЛЖНЫ (MUST NOT) быть настроены так, чтобы разрешать направленные широковещательные рассылки в эту среду [RFC2644].
5 Системная инфраструктура
Способ, которым ISP управляет своими системами, критически важен для безопасности и надёжности его сети. Нарушение безопасности его систем в минимальном случае может привести к ухудшению производительности или функциональности, но может привести к потере данных или риску перехвата трафика (и тем самым — к атакам «человек посередине»).
Широко признано, что строить защищённые системы проще, если разные службы (такие как почта, новости и веб-хостинг) размещены на отдельных системах.
5.1 Управление системами
Доступ ко всем системам, выполняющим критические функции ISP, таким как почта, новости и веб-хостинг, следует ограничить так, чтобы он был доступен только администраторам этих служб. Такой доступ следует предоставлять только после строгой аутентификации и осуществлять по зашифрованному каналу. Извне сетей систем ISP следует обеспечивать доступность только к портам, на которых прослушивают эти службы.
ISP следует быть в курсе более защищённых методов предоставления служб по мере их появления (например, IMAP/POP AUTHorize Extension for Simple Challenge/Response, [RFC2195]).
5.2 Отсутствие систем в транзитных сетях
Системы не следует подключать к сегментам транзитной сети.
5.3 Открытый почтовый ретранслятор
ISP следует предпринимать активные меры, чтобы не допустить использования своей почтовой инфраструктуры «спамерами» для внедрения нежелательной массовой электронной почты (UBE) при сокрытии личности отправителя [RFC2505]. Хотя не все превентивные меры подходят для каждого узла, следует применять наиболее эффективные методы, подходящие для данного узла.
ISP также следует настоятельно побуждать своих клиентов предпринимать необходимые меры для предотвращения такой деятельности в их собственных системах.
5.4 Передача сообщений
Передачу сообщений следует аутентифицировать с использованием расширения службы AUTH SMTP, описанного в «SMTP Service Extension for Authentication» [RFC2554].
SMTP AUTH предпочтительнее ограничений на передачу сообщений, основанных на IP-адресе, поскольку он предоставляет клиентам ISP гибкость: они могут передавать почту, даже когда не подключены через сеть ISP (например, находясь на работе); он более устойчив к спуфингу; кроме того, его можно обновлять до более новых механизмов аутентификации по мере их появления.
Кроме того, для облегчения применения политики безопасности настоятельно рекомендуется передавать сообщения через порт MAIL SUBMIT (587), как рассматривается в «Message Submission» [RFC2476], а не через порт SMTP (25). Таким образом, порт SMTP (25) можно ограничить только локальной доставкой.
Причина состоит в возможности различать входящую локальную доставку и ретрансляцию (то есть разрешать клиентам отправлять электронную почту через службу SMTP ISP произвольным получателям в Internet). Неаутентифицированный SMTP следует разрешать только для локальной доставки.
По мере того как всё больше почтовых клиентов поддерживают как SMTP AUTH, так и порт передачи сообщений (либо явно, либо путём настройки порта SMTP), ISP могут счесть полезным требовать, чтобы клиенты передавали сообщения, используя одновременно порт передачи и SMTP AUTH; при этом на порту 25 разрешая только входящую почту.
Эти меры (SMTP AUTH и порт передачи) не только защищают ISP от использования в качестве точки внедрения UBE через ретранслятор третьей стороны, но и помогают отслеживать подотчётность за передачу сообщений в случае, когда клиент отправляет UBE.
6 Ссылки
[CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal
Connections",
ftp://info.cert.org/pub/cert_advisories/
[CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks",
ftp://info.cert.org/pub/cert_advisories/
[DPR1998] The UK "Data Protection Act 1998 (c. 29)",
http://www.hmso.gov.uk/acts/acts1998/
19980029.htm
[RFC1786] Bates, T., Gerich, E., Joncheray, L.,
Jouanigot, J., Karrenberg, D., Terpstra, M.
and J. Yu, "Representation of IP Routing
Policies in a Routing Registry (ripe-81++)",
RFC 1786, March 1995.
[RFC1834] Gargano, J. and K. Weiss, "Whois and Network
Information Lookup Service", RFC 1834,
August 1995.
[RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P. and
C. Weider, "Architecture of the WHOIS++
service", RFC 1835, August 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D.,
de Groot, G. J. and E. Lear, "Address
Allocation for Private Internets", BCP 5,
RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC
2119, March 1997.
[RFC2142] Crocker, D., "Mailbox Names for Common
Services, Roles and Functions", RFC 2142,
May 1997.
[RFC2195] Klensin, J., Catoe, R. and P. Krumviede,
"IMAP/POP AUTHorize Extension for Simple
Challenge/Response", RFC 2195, September
1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8,
RFC 2196, September 1997.
[RFC2350] Brownlee, N. and E. Guttman, "Expectations
for Computer Security Incident Response",
BCP 21, RFC 2350, June 1998.
[RFC2385] Heffernan, A., "Protection of BGP Sessions
via the TCP MD5 Signature Option", RFC 2385,
August 1998.
[RFC2439] Chandra R., Govindan R. and C. Villamizar,
"BGP Route Flap Damping", RFC 2439, November
1998.
[RFC2476] Gellens R. and J. Klensin, "Message
Submission", RFC 2476, December 1998.
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for
SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC2554] Myers, J., "SMTP Service Extension for
Authentication", RFC 2554, March 1999.
[RFC2644] Senie, D., "Changing the Default for
Directed Broadcasts in Routers", BCP 34, RFC
2644, August 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress
Filtering: Defeating Denial of Service
Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000.
7 Благодарности
Я с благодарностью отмечаю конструктивные замечания, полученные от Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, Michael A. Patton, Don Stikvoort и Bill Woodcock.
8 Соображения безопасности
Весь этот документ посвящён вопросам безопасности.
9 Адрес автора
Tom Killalea
Lisi/n na Bro/n
Be/al A/tha na Muice
Co. Mhaigh Eo
IRELAND
Phone: +1 206 266-2196
EMail: tomk@neart.org
10 Полное заявление об авторских правах
Copyright (C) The Internet Society (2000). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, которые комментируют или иным образом поясняют его либо содействуют его реализации, могут подготавливаться, копироваться, публиковаться и распространяться полностью или частично без каких-либо ограничений при условии, что приведённое выше уведомление об авторских правах и этот абзац включены во все такие копии и производные работы. Однако сам этот документ не может каким-либо образом изменяться, например путём удаления уведомления об авторских правах или ссылок на Internet Society либо другие организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet, в которых должны соблюдаться процедуры в отношении авторских прав, определённые процессом разработки стандартов Internet, либо когда это требуется для перевода документа на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны Internet Society или его правопреемниками либо лицами, которым были переданы права.
Этот документ и содержащаяся в нём информация предоставляются по принципу «КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.