Tcp ограничивает количество соединений после того, пока инициатор не получил syn-ack.

Система злоумышленника может передавать серию пакетов SYN (как правило, с поддельных IP-адресов), пока жертва не достигнет предела полуоткрытых соединений. Результатом является невозможность приема какие-либо новые входящие соединения. Атакующий может послать много фиктивных SYN в течение отведенного таймаута.

Эта форма атаки DoS, известна как SYN-flood (затопление, flood).

В SCTP предусмотрена защита от этой атаки DoS с помощью нового алгоритма (4 шага) с использованием HMAC. [7]. Такой механизм обеспечивает защиту так же от угрозы повтора.

1 этап. Инициатор установления соединения А выделяет ресурсы для установления ассоциации с P и отправляет ему команду INIT создания ассоциации (сеанса связи).

2 этап. P отвечает командой подтверждение создания ассоциации (INIT-ACK), которая содержит: время генерации команды, истечение срока ее действия и другие параметры; HMAC этих данных.

3 этап. А отправляет команду завершение создания ассоциации (COOKIE ECHO), содержащую копию принятой команды INIT-ACK и дополнительно (опция) данные пользователя. А устанавливает состояние “ ассоциация установлена”.

4 этап. Если в результате проверки HMAC фрагмент принятой команды COOKIE-ECHO (завершение создания ассоциации) правильный, то P выделяет ресурсы для ассоциации и отправляет командуINIT-ACK, дополнительно (опция) содержащую данные пользователя. P устанавливает состояние “ ассоциация установлена”.

Если в приведенном примере А отправил команду UNIT c ложным IP-адресом, то P отправил бы команду подтверждения создания ассоциации INIT-ACK по этому ложному адресу. Так как P не выделяет ресурсы для ассоциации, до правильного приема HMAC, то возможности создания атаки DoS ограничены. Приведенный четырех этапный механизм защиты уменьшает уязвимость от атак DoS, но не исключает их. В работе [7] приводятся примеры необходимости дополнительных мер защиты при использовании этого алгоритма.

 

Механизмы шифрования, аутентификации и целостности данных в SCTP. В системе сигнализации SIP при использовании транспортного протокола TCP принято пошаговое (между смежными устройствами SIP-T с уровнем SCTP) шифрование сообщений из конца в конец (end-to-end). Причиной пошагового является необходимость при установлении соединений изменения в промежуточных устройствах некоторых маршрутных данных (например, “Request URI”, “Rout”, “Via”) [8]. При этом используются стандартные протоколы TLS и IPSec. Использование этих протоколов позволяет не только шифровать сообщения, но и обеспечивать целостность сообщений и аутентификацию.

При этом не учитывается уязвимость безопасности функций множественной адресации и многопоточности протокола SCTP. Использование протоколов IPSec и TLS для защиты от этих угроз ИБ разработаны соответствующие стандарты RFC 3554 и RFC 3436. Например, для использования IPSec предусмотрено создание нескольких защищенных связей SA (Security Association) при множественной адресации. Для двух многоадресных хостов с n и м IP-адресами для создания SCTP ассоциации должно быть установлено 2 * n * м защищенных связей.SA. Для решения этой проблемы в стандарте RFC 3554 предусмотрены изменения протокола обмена ключами IKE (Internet Key Exchange). В работах [9,10] в качестве недостатков использования протокола IPSec для SCTP (SCTP over IPsec) отмечаются две причины: сложность алгоритма и снижение производительности из-за дополнительных полей заголовков в случае сегментирования длинных сообщений. Сложность алгоритма вызвана невозможностью дифференцированного обеспечения безопасности разных приложений. Механизм безопасности выполняет функции ИБ одновременно для всех сообщений одной ассоциации.

В работе [9] в качестве основного недостатка использования протокола TLS для SCTP отмечается невозможность зашифровать фрагмент управляющей команды и общий заголовок пакета. Причиной этому является то, что TLS расположен над транспортным протоколом SCTP (TLS over SCTP) и не знает поля, данные которых надо шифровать. Учитывая ограниченность возможностей протоколов IPSec и TLS, в работе [9] предлагается протокол безопасности S-SCTP (Security SCTP). Механизм шифрования встроен в сам протокол SCTP и выполняет эту функцию безопасности после установления сессии. В основу этого протокола положен принцип, при котором ассоциация имеет одну общую сессию безопасности для всех данных в случае использования многопоточности и для всех данных в случае множественной адресации. Для этого механизм безопасности вставлен между верхним функциональным блоком SCTP, который группирует фрагменты SCTP в пакеты SCTP и нижним функциональным блоком, который выделяет пути в сети, выбирая адреса назначения. На рис.1 показан принцип работы протокола безопасности S-SCTP при взаимодействии оконечного SCTP узла A и оконечного SCTP узла B.

 

Рис. 1. Принцип работы протокола безопасности S-SCTP

Здесь введены обозначения:

 

S1,S2,S3 – потоки сообщений соответственно приложений Appl1, Appl2, и Appl3.

IP-A1, IP-A2 - IP-адреса оконечного узла A и соответствующие им интерфейсы NI,

IP-B1, IP-B2 - IP-адреса оконечного узла B и соответствующие им интерфейсы NI.

Обратите внимание на то, что поток сообщений приложения 2 не подлежит обеспечению информационной безопасности.

Протокол S-SCTP обеспечивает конфиденциальность, аутентификацию и целостность сообщений. Поэтому он использует те же стандарты шифрования и HMAC, какие применяют протоколы IPSec и TLS.