Эта атака известна также как IP spoofing
В контексте VoIP этой атакой пользуются следующим образом.
Атакующий находит ISP, который не проверяет IP адрес источника пакета на принадлежность хосту, который генерирует пакет.
Это дает возможность атакующему сгенерировать IP пакет в сеть с любым IP адресом источника.
Атакующий пробует использовать IP адреса хорошо известных VoIP компаний.
Поскольку между VoIP компаниями много соединений с авторизацией только по IP адресу, атакующему удается подобрать такой IP адрес, который проходят авторизацию у вас.
Эти вызовы у вас проходят авторизацию по подставленному IP адресу источника, который добавлен у вас как ваш реальный партнер, и маршрутизируются на терминаторов.
Поскольку обратные пакеты на оригинатора доставляются по IP адресу на реального обладателя данного адреса, а не на злоумышленника с подставленным IP адресом, ваш реальный партнер будет видеть странную картину - получение 183 Progress, 180 Ringing и 200 OK в ответ на звонки, которые он никогда на вас не отправлял.
Собственно, таким образом мы и замечали данную атаку несколько раз - по уведомлению от партнера про странную активность.
Вероятней всего, ваш реальный партнер ничего не будет отвечать на такие пакеты, и Smartswitch будет пытаться повторно доставить 200 OK используя механизм Retransmit.
В конечном итоге такой звонок будет отбит по Retransmit timeouts со стороны Smartswitch, поскольку ему так и не удастся доставить 200 OK вашему реальному партнеру, однако драгоценные секунды звонка могут стать отвеченными и попасть в счет, который выставит вам терминатор и который вы выставите вашему реальному партнеру.
В свою очередь, ваш партнер может отказаться их оплачивать, мотивируя тем, что он вообще не направлял на вас эти звонки.
И это будет правда, хотя у вас в CDR будет записан IP адрес вашего партнера.
Ввиду специфики атаки, ей подвержен только прокол SIP по UDP с использованием авторизации только по IP адресу.
Переключение на протокол SIP по TCP, SIP по TLS, H323 или IAX2 нивелирует эту угрозу, поскольку эти протоколы используют TCP и злоумышленнику даже не удастся выполнить подключение.
SIP по TLS будет наиболее защищенным способом, поскольку процесс соединения также вовлекает обмен и проверку SSL сертификатов.
Для SIP по UDP поможет добавление пароля.
Для SIP по UDP Smartswitch использует Fail2Ban для минимизации потерь от такого типа атаки.
Fail2Ban руководствуется следующей логикой - блокировать IP адреса, по которым часто происходят Retransmit timeouts, по подозрению в IP spoofing.
Обратите внимание, что в моменты блокировки мы не будем принимать звонки и от реального партнера-оригинатора, посколько мы никак не можем отличать звонки, сгенерированные реальным партнером, от звонков, сгенерированных злоумышленником - мы видим их приходящими с одного и того же IP адреса.