- sip fraud-prevention cisco cme, mdenisov, 18:45 , 09-Сен-14 (1)
Во-первых посмотрите аккаунтинг - как именно слили. Насколько я помню функционал CME не использует механизм ip address trusted list, т. е. SCCP устройству можно прописать правильный mac и CME его пустит. На SIP я этого не проверял. Кроме того можно впрямую слить трафик на адрес шлюза если на source адрес существует dial-peer с соответствующим session target'ом. Причем этот пир не обязан отматчиться как входящий. В этом случае trusted list не анализируется.
- sip fraud-prevention cisco cme, Aleks305, 21:14 , 09-Сен-14 (2)
> Во-первых посмотрите аккаунтинг - как именно слили. > Насколько я помню функционал 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, пока не получил.
- sip fraud-prevention cisco cme, mdenisov, 09:03 , 10-Сен-14 (4)
Чо это за CDR'ы? Где там ANI, DNIS и с какого адреса трафик шел? Может быть там и номера пиров есть? Нужны voip'ные пиры, pots не интересно, очень маловероятно чтобы оператор занимался такой ерундой.
- sip fraud-prevention cisco cme, Aleks305, 10:48 , 10-Сен-14 (5)
> Чо это за 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 - таких внутренних номеров вообще нет.
- sip fraud-prevention cisco cme, Aleks305, 22:07 , 09-Сен-14 (3)
> Во-первых посмотрите аккаунтинг - как именно слили. > Насколько я помню функционал CME не использует механизм ip address trusted list, > т. е. SCCP устройству можно прописать правильный mac и CME его > пустит. На SIP я этого не проверял. > Кроме того можно впрямую слить трафик на адрес шлюза если на source > адрес существует dial-peer с соответствующим session target'ом. Причем этот пир не > обязан отматчиться как входящий. В этом случае trusted list не анализируется. Похоже все-таки через SIP - сейчас логи чистые с адекватными номерами и активностью.Как же найти, где был косяк в настройке, как без аутентификации звонили.
|