forum.opennet.ru - "sip fraud-prevention cisco cme" (5)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"sip fraud-prevention cisco cme"

Форум Маршрутизаторы CISCO и др. оборудование. (VoIP)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"sip fraud-prevention cisco cme"	+/–
Сообщение от Aleks305 (ok) on 09-Сен-14, 17:18
Друзья,подскажите, как могли взломать cisco cme c публичным ip. Сейчас следующий конфиг был залит относительно SIP: voice service voip ip address trusted list ipv4 178.16.26.122 255.255.255.255 ipv4 144.76.42.108 255.255.255.255 ipv4 176.9.145.115 255.255.255.255 ipv4 5.9.108.25 255.255.255.255 ipv4 78.46.95.118 255.255.255.255 ipv4 89.249.23.194 255.255.255.255 ipv4 178.16.26.124 255.255.255.255 ipv4 176.9.85.133 255.255.255.255 ipv4 46.4.53.86 255.255.255.255 ipv4 5.9.84.165 255.255.255.255 ipv4 78.16.26.122 255.255.255.255 ipv4 77.235.62.222 255.255.255.255 ipv4 81.88.86.11 255.255.255.255 ipv4 192.168.1.50 255.255.255.255 ipv4 217.150.198.44 255.255.255.255 ipv4 178.63.96.3 255.255.255.255 ipv4 178.63.96.28 255.255.255.255 ipv4 192.168.11.0 255.255.255.0 ipv4 192.168.173.0 255.255.255.0 allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip supplementary-service h450.12 no supplementary-service sip moved-temporarily fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none sip bind media source-interface Loopback1 registrar server ! voice class codec 1 codec preference 1 g711ulaw codec preference 2 g729r8 codec preference 3 g711alaw ! voice class codec 2 codec preference 1 g711alaw codec preference 2 g729r8 ! voice class sip-profiles 10 request INVITE sip-header From modify "\"(.)\" <sip:(.)@(.)>" "\"\" <sip:чччч@92.63.x.x>" ! voice class sip-profiles 20 request INVITE sip-header From modify "\"(.)\" <sip:(.)@(.)>" "\"\" <sip:ччччч@77.41.x.x>" ! ! voice register global mode cme source-address 192.168.179.1 port 5060 max-dn 10 max-pool 5 authenticate register tftp-path flash: create profile sync 0883653009339013 ! voice register dn 1 number 150 no-reg ! voice register dn 2 number 151 no-reg ! voice register dn 3 number 152 no-reg ! voice register dn 4 number 153 no-reg ! voice register pool 1 registration-timer max 720 min 660 id mac 0005.9A3C.7800 session-transport tcp number 1 dn 1 voice-class codec 1 ! voice register pool 2 registration-timer max 720 min 660 id mac 3694.2585.3255 session-transport tcp type CiscoMobile-iOS number 1 dn 2 voice-class codec 1 ! voice register pool 3 registration-timer max 720 min 660 id mac A098.0501.0C4F session-transport tcp number 1 dn 3 voice-class codec 1 Также был подключен E1, через него основная маршрутизация. Ограничений в виде ACL не было на внешнем, публичном интерфейсе. Провайдер E1 сказал, что были попытки звонков в Африку, ну и заблокировал временно нас. Подскажите, кто сталкивался почему не сработал fraud-prevention, где ошибка в конфиге? не понимаю, как вообще смогли делать звонки без регистрации. Спасибо.
Ответить \| Правка \| Cообщить модератору

Оглавление

sip fraud-prevention cisco cme, mdenisov, 18:45 , 09-Сен-14, (1)

sip fraud-prevention cisco cme, Aleks305, 21:14 , 09-Сен-14, (2)

sip fraud-prevention cisco cme, mdenisov, 09:03 , 10-Сен-14, (4)

sip fraud-prevention cisco cme, Aleks305, 10:48 , 10-Сен-14, (5)

sip fraud-prevention cisco cme, Aleks305, 22:07 , 09-Сен-14, (3)

Сообщения по теме [Сортировка по времени | RSS]

1. "sip fraud-prevention cisco cme" +/–

Сообщение от mdenisov (ok) on 09-Сен-14, 18:45

Во-первых посмотрите аккаунтинг - как именно слили.
Насколько я помню функционал CME не использует механизм ip address trusted list, т. е. SCCP устройству можно прописать правильный mac и CME его пустит. На SIP я этого не проверял.
Кроме того можно впрямую слить трафик на адрес шлюза если на source адрес существует dial-peer с соответствующим session target'ом. Причем этот пир не обязан отматчиться как входящий. В этом случае trusted list не анализируется.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "sip fraud-prevention cisco cme" +/–

Сообщение от Aleks305 (ok) on 09-Сен-14, 21:14

> Во-первых посмотрите аккаунтинг - как именно слили.
> Насколько я помню функционал CME не использует механизм ip address trusted list,
> т. е. SCCP устройству можно прописать правильный mac и CME его
> пустит. На SIP я этого не проверял.
> Кроме того можно впрямую слить трафик на адрес шлюза если на source
> адрес существует dial-peer с соответствующим session target'ом. Причем этот пир не
> обязан отматчиться как входящий. В этом случае trusted list не анализируется.
спасибо за отклик столь быстрый.
Взлом был еще где-то 20 августа, меня не было в тот момент.тогда просто перекрыли доступ по SIP. Сейчас приехал, начал разбираться.В cdr за то число, которые в локальный файл сохраняется не могу понять, что откуда.Похоже, что через SIP судя по этим записям:
1408568954,173578,0,2,"72E506B 27E511E4 AD2BCAF0 16E99558","","","*01:08:54.946 Moscow Thu Aug 21 2014","","*01:09:14.446 Moscow Thu Aug 21 2014","*01:09:14.446 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"1101","1101","810972595358613","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:810972595358613","ton:0,npi:0,pi:0,si:0,#:1101","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:08:54.946","1101","810972595358613",0,19291,72E506B 27E511E4 AD2BCAF0 16E99558,2A60A,"","","","","","","","","",""
1408568998,173586,0,2,"2D32FB39 27E511E4 AD38CAF0 16E99558","","","*01:09:58.730 Moscow Thu Aug 21 2014","","*01:09:58.930 Moscow Thu Aug 21 2014","*01:09:58.930 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"2000000","2000000","9810972598783507","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:9810972598783507","ton:0,npi:0,pi:0,si:0,#:2000000","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:09:58.730","2000000","9810972598783507",0,19293,2D32FB39 27E511E4 AD38CAF0 16E99558,2A612,"","","","","","","","","",""
1408569414,173648,0,2,"24A317A9 27E611E4 AD59CAF0 16E99558","","","*01:16:53.860 Moscow Thu Aug 21 2014","","*01:16:54.110 Moscow Thu Aug 21 2014","*01:16:54.110 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"2000000","2000000","0810972598783507","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:0810972598783507","ton:0,npi:0,pi:0,si:0,#:2000000","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:16:53.862","2000000","0810972598783507",0,19294,24A317A9 27E611E4 AD59CAF0 16E99558,2A650,"","","","","","","","","",""
1408569549,173664,0,2,"69FC646A 27E611E4 AD65CAF0 16E99558","","","*01:18:50.206 Moscow Thu Aug 21 2014","","*01:19:09.706 Moscow Thu Aug 21 2014","*01:19:09.706 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"100","100","888011447937420608","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:888011447937420608","ton:0,npi:0,pi:0,si:0,#:100","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:18:50.206","100","888011447937420608",0,19295,69FC646A 27E611E4 AD65CAF0 16E99558,2A660,"","","","","","","","","",""
1408569778,173698,0,2,"FE21CC87 27E611E4 AD79CAF0 16E99558","","","*01:22:58.754 Moscow Thu Aug 21 2014","","*01:22:58.994 Moscow Thu Aug 21 2014","*01:22:58.994 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"5666","5666","9810972597459073","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:9810972597459073","ton:0,npi:0,pi:0,si:0,#:5666","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:22:58.758","5666","9810972597459073",0,19296,FE21CC87 27E611E4 AD79CAF0 16E99558,2A682,"","","","","","","","","",""
По поводу слива трафика, не совсем понял, как это делается.
Активные dial-peer, которые были на момент взлома:
dial-peer voice 100 pots
translation-profile outgoing outgoing-e1
destination-pattern 98..........
port 0/0/0:15
forward-digits all
dial-peer voice 110 pots
translation-profile incoming incoming-e1
incoming called-number <внешний номер>
direct-inward-dial
dial-peer voice 101 pots
translation-profile outgoing outgoing-e1
destination-pattern 9.T
port 0/0/0:15
forward-digits all
Что примечательно, что взлом произошел после подключения e1. До этого месяца полтора-два работало все через SIP-провайдера и вроде бы проблем никаких не было.
Я уж думаю, может нас через e1 ломанули.
Вот здесь описывается, кстати.
http://www.anticisco.ru/forum/viewtopic.php?t=2826
Жду детализацию от провайдера e1, пока не получил.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "sip fraud-prevention cisco cme" +/–

Сообщение от mdenisov (ok) on 10-Сен-14, 09:03

Чо это за CDR'ы? Где там ANI, DNIS и с какого адреса трафик шел? Может быть там и номера пиров есть?
Нужны voip'ные пиры, pots не интересно, очень маловероятно чтобы оператор занимался такой ерундой.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "sip fraud-prevention cisco cme" +/–

Сообщение от Aleks305 (ok) on 10-Сен-14, 10:48

> Чо это за CDR'ы? Где там ANI, DNIS и с какого адреса
> трафик шел? Может быть там и номера пиров есть?
> Нужны voip'ные пиры, pots не интересно, очень маловероятно чтобы оператор занимался такой
> ерундой.
На момент взлома был доступен только входящий voip диал-пир.
dial-peer voice 3 voip
translation-profile incoming incoming
incoming called-number 141756
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte
no vad
voice translation-rule 1040
rule 1 /^.*$/ /21/
voice translation-profile incoming
translate called 1040
Остальные были выключены:
dial-peer voice 4 voip
description MEZHGOROD
translation-profile outgoing outgoing-mezhdunarod
shutdown
destination-pattern 9375.........
session protocol sipv2
session target sip-server
voice-class codec 2
no voice-class sip outbound-proxy
voice-class sip profiles 20
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte sip-notify
no vad
dial-peer voice 5 voip
translation-profile outgoing outgoing-mezhdunarod
shutdown
destination-pattern 9.T
session protocol sipv2
session target sip-server
voice-class codec 2
no voice-class sip outbound-proxy
voice-class sip profiles 20
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte sip-notify
no vad
dial-peer voice 1 voip
description TO-RUSSIA
paramspace callsetup after-hours-exempt FALSE
shutdown
session protocol sipv2
session target ipv4:192.168.1.50:5060
session transport udp
voice-class codec 1
no voice-class sip bandwidth video
voice-class sip profiles 20
no voice-class sip anat
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
ip qos dscp cs3 signaling
dial-peer voice 6 voip
description TO-RUSSIA-NEW
translation-profile outgoing outgoing
shutdown
destination-pattern 98..........
session protocol sipv2
session target sip-server
voice-class codec 2
no voice-class sip outbound-proxy
voice-class sip profiles 20
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay rtp-nte sip-notify
no vad

Вот записи:
,0,"",0,0,0,0,"100","100","10950048587314419",""
"answer",0,"",0,0,0,0,"100","100","10970048587314419"
"answer",0,"",0,0,0,0,"652","652","810441904899510",
652 или 100 - таких внутренних номеров вообще нет.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

3. "sip fraud-prevention cisco cme" +/–

Сообщение от Aleks305 (ok) on 09-Сен-14, 22:07

> Во-первых посмотрите аккаунтинг - как именно слили.
> Насколько я помню функционал CME не использует механизм ip address trusted list,
> т. е. SCCP устройству можно прописать правильный mac и CME его
> пустит. На SIP я этого не проверял.
> Кроме того можно впрямую слить трафик на адрес шлюза если на source
> адрес существует dial-peer с соответствующим session target'ом. Причем этот пир не
> обязан отматчиться как входящий. В этом случае trusted list не анализируется.
Похоже все-таки через SIP - сейчас логи чистые с адекватными номерами и активностью.Как же найти, где был косяк в настройке, как без аутентификации звонили.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "sip fraud-prevention cisco cme"	+/–
Сообщение от mdenisov (ok) on 09-Сен-14, 18:45
Во-первых посмотрите аккаунтинг - как именно слили. Насколько я помню функционал CME не использует механизм ip address trusted list, т. е. SCCP устройству можно прописать правильный mac и CME его пустит. На SIP я этого не проверял. Кроме того можно впрямую слить трафик на адрес шлюза если на source адрес существует dial-peer с соответствующим session target'ом. Причем этот пир не обязан отматчиться как входящий. В этом случае trusted list не анализируется.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "sip fraud-prevention cisco cme"	+/–
	Сообщение от Aleks305 (ok) on 09-Сен-14, 21:14
	> Во-первых посмотрите аккаунтинг - как именно слили. > Насколько я помню функционал CME не использует механизм ip address trusted list, > т. е. SCCP устройству можно прописать правильный mac и CME его > пустит. На SIP я этого не проверял. > Кроме того можно впрямую слить трафик на адрес шлюза если на source > адрес существует dial-peer с соответствующим session target'ом. Причем этот пир не > обязан отматчиться как входящий. В этом случае trusted list не анализируется. спасибо за отклик столь быстрый. Взлом был еще где-то 20 августа, меня не было в тот момент.тогда просто перекрыли доступ по SIP. Сейчас приехал, начал разбираться.В cdr за то число, которые в локальный файл сохраняется не могу понять, что откуда.Похоже, что через SIP судя по этим записям: 1408568954,173578,0,2,"72E506B 27E511E4 AD2BCAF0 16E99558","","","01:08:54.946 Moscow Thu Aug 21 2014","","01:09:14.446 Moscow Thu Aug 21 2014","01:09:14.446 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"1101","1101","810972595358613","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:810972595358613","ton:0,npi:0,pi:0,si:0,#:1101","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:08:54.946","1101","810972595358613",0,19291,72E506B 27E511E4 AD2BCAF0 16E99558,2A60A,"","","","","","","","","","" 1408568998,173586,0,2,"2D32FB39 27E511E4 AD38CAF0 16E99558","","","01:09:58.730 Moscow Thu Aug 21 2014","","01:09:58.930 Moscow Thu Aug 21 2014","01:09:58.930 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"2000000","2000000","9810972598783507","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:9810972598783507","ton:0,npi:0,pi:0,si:0,#:2000000","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:09:58.730","2000000","9810972598783507",0,19293,2D32FB39 27E511E4 AD38CAF0 16E99558,2A612,"","","","","","","","","","" 1408569414,173648,0,2,"24A317A9 27E611E4 AD59CAF0 16E99558","","","01:16:53.860 Moscow Thu Aug 21 2014","","01:16:54.110 Moscow Thu Aug 21 2014","01:16:54.110 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"2000000","2000000","0810972598783507","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:0810972598783507","ton:0,npi:0,pi:0,si:0,#:2000000","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:16:53.862","2000000","0810972598783507",0,19294,24A317A9 27E611E4 AD59CAF0 16E99558,2A650,"","","","","","","","","","" 1408569549,173664,0,2,"69FC646A 27E611E4 AD65CAF0 16E99558","","","01:18:50.206 Moscow Thu Aug 21 2014","","01:19:09.706 Moscow Thu Aug 21 2014","01:19:09.706 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"100","100","888011447937420608","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:888011447937420608","ton:0,npi:0,pi:0,si:0,#:100","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:18:50.206","100","888011447937420608",0,19295,69FC646A 27E611E4 AD65CAF0 16E99558,2A660,"","","","","","","","","","" 1408569778,173698,0,2,"FE21CC87 27E611E4 AD79CAF0 16E99558","","","01:22:58.754 Moscow Thu Aug 21 2014","","01:22:58.994 Moscow Thu Aug 21 2014","*01:22:58.994 Moscow Thu Aug 21 2014","","","answer",0,"",0,0,0,0,"5666","5666","9810972597459073","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",0,"","1.1.228.3.31.0","0","0.0.0.0","","","","","","","","","","","","","","","","","","","","","","ton:0,npi:0,#:9810972597459073","ton:0,npi:0,pi:0,si:0,#:5666","","","","","","","","","","count:1","","Unknown","","","sipv2","","","TWC","08/21/2014 01:22:58.758","5666","9810972597459073",0,19296,FE21CC87 27E611E4 AD79CAF0 16E99558,2A682,"","","","","","","","","","" По поводу слива трафика, не совсем понял, как это делается. Активные dial-peer, которые были на момент взлома: dial-peer voice 100 pots translation-profile outgoing outgoing-e1 destination-pattern 98.......... port 0/0/0:15 forward-digits all dial-peer voice 110 pots translation-profile incoming incoming-e1 incoming called-number <внешний номер> direct-inward-dial dial-peer voice 101 pots translation-profile outgoing outgoing-e1 destination-pattern 9.T port 0/0/0:15 forward-digits all Что примечательно, что взлом произошел после подключения e1. До этого месяца полтора-два работало все через SIP-провайдера и вроде бы проблем никаких не было. Я уж думаю, может нас через e1 ломанули. Вот здесь описывается, кстати. http://www.anticisco.ru/forum/viewtopic.php?t=2826 Жду детализацию от провайдера e1, пока не получил.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	4. "sip fraud-prevention cisco cme"	+/–
	Сообщение от mdenisov (ok) on 10-Сен-14, 09:03
	Чо это за CDR'ы? Где там ANI, DNIS и с какого адреса трафик шел? Может быть там и номера пиров есть? Нужны voip'ные пиры, pots не интересно, очень маловероятно чтобы оператор занимался такой ерундой.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "sip fraud-prevention cisco cme"	+/–
	Сообщение от Aleks305 (ok) on 10-Сен-14, 10:48
	> Чо это за CDR'ы? Где там ANI, DNIS и с какого адреса > трафик шел? Может быть там и номера пиров есть? > Нужны voip'ные пиры, pots не интересно, очень маловероятно чтобы оператор занимался такой > ерундой. На момент взлома был доступен только входящий voip диал-пир. dial-peer voice 3 voip translation-profile incoming incoming incoming called-number 141756 voice-class codec 1 voice-class sip bind control source-interface GigabitEthernet0/0 voice-class sip bind media source-interface GigabitEthernet0/0 dtmf-relay rtp-nte no vad voice translation-rule 1040 rule 1 /^.*$/ /21/ voice translation-profile incoming translate called 1040 Остальные были выключены: dial-peer voice 4 voip description MEZHGOROD translation-profile outgoing outgoing-mezhdunarod shutdown destination-pattern 9375......... session protocol sipv2 session target sip-server voice-class codec 2 no voice-class sip outbound-proxy voice-class sip profiles 20 voice-class sip bind control source-interface GigabitEthernet0/0 voice-class sip bind media source-interface GigabitEthernet0/0 dtmf-relay rtp-nte sip-notify no vad dial-peer voice 5 voip translation-profile outgoing outgoing-mezhdunarod shutdown destination-pattern 9.T session protocol sipv2 session target sip-server voice-class codec 2 no voice-class sip outbound-proxy voice-class sip profiles 20 voice-class sip bind control source-interface GigabitEthernet0/0 voice-class sip bind media source-interface GigabitEthernet0/0 dtmf-relay rtp-nte sip-notify no vad dial-peer voice 1 voip description TO-RUSSIA paramspace callsetup after-hours-exempt FALSE shutdown session protocol sipv2 session target ipv4:192.168.1.50:5060 session transport udp voice-class codec 1 no voice-class sip bandwidth video voice-class sip profiles 20 no voice-class sip anat voice-class sip bind control source-interface GigabitEthernet0/0 voice-class sip bind media source-interface GigabitEthernet0/0 ip qos dscp cs3 signaling dial-peer voice 6 voip description TO-RUSSIA-NEW translation-profile outgoing outgoing shutdown destination-pattern 98.......... session protocol sipv2 session target sip-server voice-class codec 2 no voice-class sip outbound-proxy voice-class sip profiles 20 voice-class sip bind control source-interface GigabitEthernet0/0 voice-class sip bind media source-interface GigabitEthernet0/0 dtmf-relay rtp-nte sip-notify no vad Вот записи: ,0,"",0,0,0,0,"100","100","10950048587314419","" "answer",0,"",0,0,0,0,"100","100","10970048587314419" "answer",0,"",0,0,0,0,"652","652","810441904899510", 652 или 100 - таких внутренних номеров вообще нет.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	3. "sip fraud-prevention cisco cme"	+/–
	Сообщение от Aleks305 (ok) on 09-Сен-14, 22:07
	> Во-первых посмотрите аккаунтинг - как именно слили. > Насколько я помню функционал CME не использует механизм ip address trusted list, > т. е. SCCP устройству можно прописать правильный mac и CME его > пустит. На SIP я этого не проверял. > Кроме того можно впрямую слить трафик на адрес шлюза если на source > адрес существует dial-peer с соответствующим session target'ом. Причем этот пир не > обязан отматчиться как входящий. В этом случае trusted list не анализируется. Похоже все-таки через SIP - сейчас логи чистые с адекватными номерами и активностью.Как же найти, где был косяк в настройке, как без аутентификации звонили.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору