6. Вопросы безопасности и туннелирования
В этом разделе рассматриваются вопросы безопасности, возникающие в связи с введением дифференцированного обслуживания, прежде всего, потенциальные атаки на службы (DoS) и потенциальные возможности несанкционированного обслуживания трафика (параграф 6.1). В дополнение к этому рассматривается дифференцированное обслуживание в присутствии IPsec (параграф 6.2) и требования к аудиту (параграф 6.3). Рассматриваются вопросы, связанные с использованием туннелей (как IPsec, так и иных).
6.1 Несанкционированное обслуживание и атаки на службы
Основной задачей дифференциации обслуживания является обеспечение возможности предоставления потокам трафика разного уровня сервиса в одной сетевой инфраструктуре. Для достижения результата могут использоваться различные методы управления ресурсами, но конечный результат должен заключаться в том, что обслуживание одних пакетов будет отличаться от обслуживания других (например, будет лучше). Отображение сетевого трафика на соответствующий режим, приводящий к иному (лучше или хуже) обслуживанию, задается, прежде всего, значением поля DS и, следовательно, злоумышленник может добиться улучшения обслуживания путем изменения поля DS для отображения трафика на режим, используемый для обеспечения лучшего обслуживания, или вставки пакетов с соответствующим значением поля DS. С учетом ограниченности ресурсов такой обман может служить для организации атак на службы, когда изменение или вставка пакетов ведет к исчерпанию ресурсов, доступных для пересылки других потоков трафика. Защита от таких «краж» и DoS-атак включает средства кондиционирования трафика на граничных узлах DS в сочетании с обеспечением защиты и целостности сетевой инфраструктуры домена DS.
Как описано в разделе 2, входные узлы DS должны кондиционировать весь трафик, входящий в домен DS, для обеспечения приемлемости имеющихся в пакетах кодов DS. Это означает, что коды должны соответствовать применимым TCA и принятой в домене политике обслуживания. Следовательно, входные узлы являются первой линией защиты от атак на службы, основанных на изменении кодов DS, поскольку успех такой атаки ведет к нарушению соответствующих TCA и принятой в домене политики обслуживания. Важно понимать, что любой, генерирующий трафик, узел домена DS является входным узлом для этого трафика и узел должен гарантировать допустимость всех кодов DS в порожденном этим узлом трафике.
Как политика обслуживания в домене, так и TCA могут требовать смены на входных узлах кода DS для некоторых пакетов (например, входной маршрутизатор может устанавливать для пользовательского трафика код DS в соответствии с подходящим SLA). Входные узлы должны кондиционировать весь остальной входящий трафик для обеспечения приемлемости кодов DS; пакеты с неприемлемыми кодами должны отбрасываться или значение кода DS должно меняться на приемлемое до пересылки пакета. Например, входной узел, получая трафик от домена, для которого нет соглашения об улучшенном обслуживании, может сбрасывать код DS в значение, принятое для Default PHB [RFC2474]. Для разрешения использования некоторых кодов DS (например, соответствующих улучшенному обслуживанию) может потребоваться идентификация трафика, которая может быть выполнена техническими (например, IPsec) и/или иными (например, подключение входного канала к единственному заказчику) средствами.
Междоменное соглашение может снижать или сводить к нулю требования по кондиционированию входящего трафика, частично или полностью перенеся ответственность за приемлемые значения кодов DS во входящем трафике на нисходящий домен. В таких случаях входной узел домена может сохранять (избыточную) проверку кондиционирования для снижения зависимости от восходящего домена (например, такая проверка может предотвращать распространение DoS-атак, связанных с дифференцированным обслуживанием через границу домена). Если при такой проверке наблюдается нарушение условий со стороны восходящего домена, результат проверки следует записывать в системный журнал с указанием даты и времени приема пакета, IP-адресов отправителя и получателя, а также кода DS. На практике следует учитывать ограниченность такого контроля и затрату ресурсов на его реализацию.
Внутренние узлы домена DS могут опираться на значение поля DS для связывания трафика с дифференцированным обслуживанием и режимов, используемых для реализации улучшенного сервиса. Любой узел, выполняющий такое связывание, зависит от корректности работы домена DS по предотвращению приема трафика с неприемлемыми кодами DS. В соответствии с требованиями жизнеспособности получение пакетов с недопустимыми кодами DS не должно вызывать отказов (сбоев в работе) на узлах сети. Внутренние узлы не несут ответственности за исполнение политики обслуживания (или отдельных SLA) и, следовательно, от них не требуется проверять коды DS перед их использованием. Внутренние узлы могут выполнять некоторые проверки кондиционирования трафика по кодам DS (например, проверку кодов DS, которые никогда не используются на заданном канале) для повышения уровня безопасности и отказоустойчивости (например, устойчивость к атакам, связанным с изменением кодов DS, — краже услуг). При отрицательном результате проверки следует генерировать запись в системном журнале в указанием даты и времени, IP-адресов отправителя и получателя, а также кода DS. На практике следует учитывать ограниченность такого контроля и затрату ресурсов на его реализацию.
Любой канал, для которого невозможно обеспечить адекватную защиту от изменения кодов DS или внедрения несанкционированного трафика, следует трактовать, как граничный канал (и, следовательно, весь входящий через этот канал трафик должен обрабатываться как на входном узле домена). Определение «адекватной защиты» задается локальной политикой безопасности и может включать определение рисков и последствий, связанных с изменением кодов DS, которые не перекрываются дополнительными мерами по обеспечению безопасности для данного канала. Уровень защиты канала можно дополнительно повысить за счет контроля доступа на физическом уровне и/или программными средствами (типа организации туннелей), обеспечивающими целостность пакетов.