SIP атака на * за натом ?

[Ferrum]

Расскажи как этого добился (как сканировал), интересно как стандартный линуксовый iptables и NAT себя поведут.

[Rom1kz]

Расскажи как этого добился (как сканировал), интересно как стандартный линуксовый iptables и NAT себя поведут.

ничего сложного
необходимо чтоб * находящийся в приватной сети создал НАТ трасляцию на роутере с порта сигнализации SIP (UDP 5060 по умолчанию)
после этого смотрим с какого порта роутер выводит эту трасляцию в мир и сканим этот порт снаружи
./svmap.py -p1040 x.x.x.x
если точно не знаешь порта, то сканеру можно задать диапазон -p1024-65536
в случае если НАТ реализован по типу full cone nat (как на cisco), то будет создана динамическая трансляция с новым внешним адресом
елси у вас [port] restricted cone nat или симметричный нат, то такого не произойдет

если сменить нат или его реализацию невозможно, то выхода 2:
1. рубить фаерволом ненужный траф
2. юзать на * TCP протокол SIP сигнализации для внешних пиров

[Zavr2008]

Upd: Еще я у себя на Микротике зарядил L7 фильтр на неудачников, ломящихся по SIP со своими REGISTER и INVITE в поисках наживы.

Присоединюсь к просьбе.
/ip firewall export compact

Сорри, только сейчас увидел(

Код: Выделить всё

/ip firewall layer7-protocol
add comment="SIP incoming invites" name=sip-register regexp="^(invite|register) sip[x09-x0d -~]*sip/[0-2].[0-9]"

/ip firewall mangle
add action=add-src-to-address-list address-list=SIP-in address-list-timeout=15m chain=prerouting dst-port=5060 in-interface=ether1-gateway layer7-protocol=sip-register limit=10,5 protocol=udp

/ip firewall filter
add action=drop chain=forward dst-port=5060 protocol=udp src-address-list=SIP-in

[SolarW]

Крррррасота!!!
Сижу, любуюсь, за час уже наловилось рыбки.
Только тайм-аут увеличил с 15 минут до одного часа.

sip_scan_01.png (7.39 КБ) 9953 просмотра

Большое спасибо, применю на всех подшефных инсталляциях.

[SolarW]

Не совсем красота...
Пришлось убрать это правило, народ стал жаловаться на отпавшие удаленные телефоны.
Надо более тщательно продумать количество запросов для анализа и какие тайм-ауты на телефонах ставить...

[Merk]

Не совсем красота...
Пришлось убрать это правило, народ стал жаловаться на отпавшие удаленные телефоны.

Подтверждаю. С проблемой столкнулся юзер, у которого установлен Yealink SIP-T21P. Установлено, что данный аппарат постоянно шлет некие пакеты к астериску (просматривается в графике предложенного правила mangle), на которые срабатывает блок в микротике. Пакеты эти он шлет даже в состоянии покоя.

У другого юзера установлен D-Link DPH-150S, с ним все нормально, такой проблемы нет.

Может кто знает, что нужно отключить в настройках Yealink, чтобы он "успокоился"?

[awsswa]

да что угодно может слать - OPTIONS скорее всего для поддержки NAT - можно выключить

[ded]

НЕ совсем.
OPTIONS для поддержки NAT - это механизм поддержки трансляции со стороны Астериска, который инициирует эти пакеты,
А тут наоборот, Yealink SIP-T21P инициирует, так что возможно это опция nat keepalive, для тех же целей, но со стороны клиента.

[SolarW]

Тут вопрос в том, что приведенное правило для микротика "возбуждается" только от SIP REGISTER / INVITE запросов... Так что OPTIONS тут точно ни о чем.
Я вот сейчас не помню - телефон когда пытается позвонить должен INVITE слать?

[ded]

Да.