Hello. recently I see ddos on one interface and FS module callcenter is working irregularly. tcpdump shows this: 17:17:42.410306 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 364) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 336 E..l..@.0...2.% MY.".....XW.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-3646224729;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 360911671 Max-Forwards: 70 17:17:42.415504 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 365) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 337 E..m..@.0...2.% MY.".....Y,.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-1538287390;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 3912185912 Max-Forwards: 70 17:17:42.420997 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 365) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 337 E..m..@.0...2.% MY.".....Y7.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-3729326239;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 2188845586 Max-Forwards: 70 17:17:42.425886 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 365) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 337 E..m..@.0...2.% MY.".....Y3.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-2208974380;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 4149361432 Max-Forwards: 70 17:17:42.431126 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 364) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 336 E..l..@.0...2.% MY.".....X..REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-725880732;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 1466795680 Max-Forwards: 70 17:17:42.436476 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 365) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 337 E..m..@.0...2.% MY.".....Y6.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-3259665948;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 3328716097 Max-Forwards: 70 17:17:42.441541 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 364) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 336 E..l..@.0...2.% MY.".....XT.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-2487219966;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 684380132 Max-Forwards: 70 In iptables I have this: 1637 597K DROP all -- * * 50.30.37.10 0.0.0.0/0 0 0 DROP all -- * * 62.75.212.215 0.0.0.0/0 So packets form that IP are not dropped. How is that? Does FS has a bag? -- Mimiko desu.
This is sipvicious, its a brute force scanner... See http://wiki.freeswitch.org/wiki/Fail2ban on how to setup Fail2ban with FreeSWITCH to defeat this attack On 10/14/13 9:28 AM, "Mimiko" <vbvbrj@gmail.com> wrote:
Hello.
recently I see ddos on one interface and FS module callcenter is working irregularly. tcpdump shows this:
17:17:42.410306 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 364) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 336 E..l..@.0...2.% MY.".....XW.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-3646224729;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 360911671 Max-Forwards: 70
17:17:42.415504 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 365) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 337 E..m..@.0...2.% MY.".....Y,.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-1538287390;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 3912185912 Max-Forwards: 70
17:17:42.420997 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 365) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 337 E..m..@.0...2.% MY.".....Y7.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-3729326239;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 2188845586 Max-Forwards: 70
17:17:42.425886 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 365) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 337 E..m..@.0...2.% MY.".....Y3.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-2208974380;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 4149361432 Max-Forwards: 70
17:17:42.431126 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 364) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 336 E..l..@.0...2.% MY.".....X..REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-725880732;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 1466795680 Max-Forwards: 70
17:17:42.436476 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 365) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 337 E..m..@.0...2.% MY.".....Y6.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-3259665948;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 3328716097 Max-Forwards: 70
17:17:42.441541 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 364) 50.30.37.10.5064 > A.B.C.D.5060: [udp sum ok] UDP, length 336 E..l..@.0...2.% MY.".....XT.REGISTER sip:A.B.C.D SIP/2.0 Via: SIP/2.0/UDP 62.75.212.215:5064;branch=z9hG4bK-2487219966;rport Content-Length: 0 From: "6796" <sip:6796@A.B.C.D> Accept: application/sdp User-Agent: friendly-scanner To: "6796" <sip:6796@A.B.C.D> Contact: sip:123@1.1.1.1 CSeq: 1 REGISTER Call-ID: 684380132 Max-Forwards: 70
In iptables I have this: 1637 597K DROP all -- * * 50.30.37.10 0.0.0.0/0 0 0 DROP all -- * * 62.75.212.215 0.0.0.0/0
So packets form that IP are not dropped. How is that? Does FS has a bag?
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
On 14.10.2013 17:54, Ken Rice wrote:
This is sipvicious, its a brute force scanner... See http://wiki.freeswitch.org/wiki/Fail2ban on how to setup Fail2ban with FreeSWITCH to defeat this attack
Ken thank you. I am planning to set up Fail2ban. But for now need to drop any packet from offending IP. -- Mimiko desu.
Google around a little... You can drop any packet with friendly-scanner in it with iptables as a way to defeat the attack also On 10/14/13 9:57 AM, "Mimiko" <vbvbrj@gmail.com> wrote:
On 14.10.2013 17:54, Ken Rice wrote:
This is sipvicious, its a brute force scanner... See http://wiki.freeswitch.org/wiki/Fail2ban on how to setup Fail2ban with FreeSWITCH to defeat this attack
Ken thank you. I am planning to set up Fail2ban. But for now need to drop any packet from offending IP.
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
On 14.10.2013 18:05, Ken Rice wrote:
You can drop any packet with friendly-scanner in it with iptables as a way to defeat the attack also
I use this command: iptables -I INPUT -j DROP -p udp –dport 5060 -m string –string “friendly-scanner” –algo bm and my iptables looks like this: Chain INPUT (policy DROP 27 packets, 8596 bytes) pkts bytes target prot opt in out source destination 2482 905K DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 STRING match "friendly-scanner" ALGO name bm TO 65535 0 0 DROP all -- * * 50.7.251.123 0.0.0.0/0 0 0 DROP all -- * * 199.241.187.214 0.0.0.0/0 0 0 DROP all -- * * 85.25.199.142 0.0.0.0/0 0 0 DROP all -- * * 50.30.37.10 0.0.0.0/0 0 0 DROP all -- * * 62.75.212.215 0.0.0.0/0 But this does not help. -- Mimiko desu.
Remember unless it gets blocked upstream the packet will still hit your firewall/server. Not FreeSWITCH sure, but it'll still consume some resources to receive, identify and block it. The scanner does not care that you're not responding, it'll continue to send anyway. On 14 October 2013 15:57, Mimiko <vbvbrj@gmail.com> wrote:
On 14.10.2013 17:54, Ken Rice wrote:
This is sipvicious, its a brute force scanner... See http://wiki.freeswitch.org/wiki/Fail2ban on how to setup Fail2ban with FreeSWITCH to defeat this attack
Ken thank you. I am planning to set up Fail2ban. But for now need to drop any packet from offending IP.
-- Mimiko desu.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
What happens to traffic levels if it does get in? i.e. would it be a more effective countermeasure to let it in, but have it not be able to actually do anything? (honeypot/dummy accounts) -- Nathan On 10/14/2013 11:59 AM, Steven Ayre wrote:
Remember unless it gets blocked upstream the packet will still hit your firewall/server. Not FreeSWITCH sure, but it'll still consume some resources to receive, identify and block it. The scanner does not care that you're not responding, it'll continue to send anyway.
On 14 October 2013 15:57, Mimiko <vbvbrj@gmail.com <mailto:vbvbrj@gmail.com>> wrote:
On 14.10.2013 17:54, Ken Rice wrote: > This is sipvicious, its a brute force scanner... See > http://wiki.freeswitch.org/wiki/Fail2ban on how to setup Fail2ban with > FreeSWITCH to defeat this attack
Ken thank you. I am planning to set up Fail2ban. But for now need to drop any packet from offending IP.
-- Mimiko desu.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
On 14.10.2013 19:59, Steven Ayre wrote:
Remember unless it gets blocked upstream the packet will still hit your firewall/server. Not FreeSWITCH sure, but it'll still consume some resources to receive, identify and block it. The scanner does not care that you're not responding, it'll continue to send anyway.
Yep. Now I called internet provider to inform about the attack and them to block that IP because we have monthly limit on this provider. -- Mimiko desu.
The amount of traffic isnt that much... The real load on the system is the sip server trying to auth all those attempts.. On 10/14/13 12:17 PM, "Mimiko" <vbvbrj@gmail.com> wrote:
On 14.10.2013 19:59, Steven Ayre wrote:
Remember unless it gets blocked upstream the packet will still hit your firewall/server. Not FreeSWITCH sure, but it'll still consume some resources to receive, identify and block it. The scanner does not care that you're not responding, it'll continue to send anyway.
Yep. Now I called internet provider to inform about the attack and them to block that IP because we have monthly limit on this provider.
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
Yeah, that's my point - does the load decrease if it "gets in", or does it just continue brute forcing? -- Nathan On 10/14/2013 12:25 PM, Ken Rice wrote:
The amount of traffic isnt that much... The real load on the system is the sip server trying to auth all those attempts..
On 10/14/13 12:17 PM, "Mimiko" <vbvbrj@gmail.com> wrote:
On 14.10.2013 19:59, Steven Ayre wrote:
Remember unless it gets blocked upstream the packet will still hit your firewall/server. Not FreeSWITCH sure, but it'll still consume some resources to receive, identify and block it. The scanner does not care that you're not responding, it'll continue to send anyway.
Yep. Now I called internet provider to inform about the attack and them to block that IP because we have monthly limit on this provider.
-- ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
Wouldnt be possible to have some IDS countermeasure and attack mitigation directly build in FS? For example Snort have more than 100 signatures for SIP attacks, but Snort is resource intensive and also cant inspect encrypted traffic. Thank you S pozdravem / Best regards, Martin Čmelík Sent from
On 14. 10. 2013, at 18:59, Steven Ayre <steveayre@gmail.com> wrote:
Remember unless it gets blocked upstream the packet will still hit your firewall/server. Not FreeSWITCH sure, but it'll still consume some resources to receive, identify and block it. The scanner does not care that you're not responding, it'll continue to send anyway.
On 14 October 2013 15:57, Mimiko <vbvbrj@gmail.com> wrote: On 14.10.2013 17:54, Ken Rice wrote:
This is sipvicious, its a brute force scanner... See http://wiki.freeswitch.org/wiki/Fail2ban on how to setup Fail2ban with FreeSWITCH to defeat this attack
Ken thank you. I am planning to set up Fail2ban. But for now need to drop any packet from offending IP.
-- Mimiko desu.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
There are counter attacks for sipvicious, the author has intentionally left ways to counter strike... This is something that fail2ban and others are out there for... Building them into freeswitch itself would create even more overhead and probably couldn’t do as good of a job as a purpose build IDS On 10/14/13 12:21 PM, "Martin Cmelik" <martin.cmelik@gmail.com> wrote:
Wouldnt be possible to have some IDS countermeasure and attack mitigation directly build in FS? For example Snort have more than 100 signatures for SIP attacks, but Snort is resource intensive and also cant inspect encrypted traffic.
Thank you
S pozdravem / Best regards, Martin Čmelík
Sent from
On 14. 10. 2013, at 18:59, Steven Ayre <steveayre@gmail.com> wrote:
Remember unless it gets blocked upstream the packet will still hit your firewall/server. Not FreeSWITCH sure, but it'll still consume some resources to receive, identify and block it. The scanner does not care that you're not responding, it'll continue to send anyway.
On 14 October 2013 15:57, Mimiko <vbvbrj@gmail.com> wrote:
On 14.10.2013 17:54, Ken Rice wrote:
This is sipvicious, its a brute force scanner... See http://wiki.freeswitch.org/wiki/Fail2ban on how to setup Fail2ban with FreeSWITCH to defeat this attack
Ken thank you. I am planning to set up Fail2ban. But for now need to drop any packet from offending IP.
-- Mimiko desu.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
On 14.10.2013 20:55, Ken Rice wrote:
There are counter attacks for sipvicious, the author has intentionally left ways to counter strike... This is something that fail2ban and others are out there for... Building them into freeswitch itself would create even more overhead and probably couldn’t do as good of a job as a purpose build IDS
Fail2ban must be apart from FS, as it can be used to monitor other services hosted on same machine. Even SSH server. Although the attacker's IP was blocked I still see in logs: Where is sofia/internal_A.B.C.D/100@A.B.C.D appears? 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [NOTICE] switch_channel.c:1034 New Channel sofia/internal_A.B.C.D/100@A.B.C.D [35a84dc8-0a11-449a-9a81-aa0a6ad75ab6] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [DEBUG] switch_core_session.c:1010 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [DEBUG] switch_core_session.c:1010 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [DEBUG] switch_core_state_machine.c:418 (sofia/internal_A.B.C.D/100@A.B.C.D) Running State Change CS_NEW 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [DEBUG] switch_core_state_machine.c:436 (sofia/internal_A.B.C.D/100@A.B.C.D) State NEW 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.810383 [DEBUG] switch_core_session.c:1010 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 2013-10-14 20:48:51.810383 [DEBUG] sofia.c:1787 detaching session 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [WARNING] switch_core_state_machine.c:517 9ed841f1-b75d-4462-b8c4-100b976d3567 sofia/internal_A.B.C.D/100@A.B.C.D Abandoned 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [NOTICE] switch_core_state_machine.c:520 Hangup sofia/internal_A.B.C.D/100@A.B.C.D [CS_NEW] [WRONG_CALL_STATE] 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_channel.c:3139 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [KILL] 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_session.c:1345 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:418 (sofia/internal_A.B.C.D/100@A.B.C.D) Running State Change CS_HANGUP 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:681 (sofia/internal_A.B.C.D/100@A.B.C.D) State HANGUP 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] mod_sofia.c:465 Channel sofia/internal_A.B.C.D/100@A.B.C.D hanging up, cause: WRONG_CALL_STATE 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:48 sofia/internal_A.B.C.D/100@A.B.C.D Standard HANGUP, cause: WRONG_CALL_STATE 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:681 (sofia/internal_A.B.C.D/100@A.B.C.D) State HANGUP going to sleep 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:694 (sofia/internal_A.B.C.D/100@A.B.C.D) Callstate Change DOWN -> HANGUP 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:449 (sofia/internal_A.B.C.D/100@A.B.C.D) State Change CS_HANGUP -> CS_REPORTING 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_session.c:1345 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:418 (sofia/internal_A.B.C.D/100@A.B.C.D) Running State Change CS_REPORTING 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:766 (sofia/internal_A.B.C.D/100@A.B.C.D) State REPORTING 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:92 sofia/internal_A.B.C.D/100@A.B.C.D Standard REPORTING, cause: WRONG_CALL_STATE 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:766 (sofia/internal_A.B.C.D/100@A.B.C.D) State REPORTING going to sleep 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:443 (sofia/internal_A.B.C.D/100@A.B.C.D) State Change CS_REPORTING -> CS_DESTROY 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_session.c:1345 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_session.c:1553 Session 85 (sofia/internal_A.B.C.D/100@A.B.C.D) Locked, Waiting on external entities 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [NOTICE] switch_core_session.c:1571 Session 85 (sofia/internal_A.B.C.D/100@A.B.C.D) Ended 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [NOTICE] switch_core_session.c:1575 Close Channel sofia/internal_A.B.C.D/100@A.B.C.D [CS_DESTROY] 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:568 (sofia/internal_A.B.C.D/100@A.B.C.D) Callstate Change HANGUP -> DOWN 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:571 (sofia/internal_A.B.C.D/100@A.B.C.D) Running State Change CS_DESTROY 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:581 (sofia/internal_A.B.C.D/100@A.B.C.D) State DESTROY 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] mod_sofia.c:375 sofia/internal_A.B.C.D/100@A.B.C.D SOFIA DESTROY 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:99 sofia/internal_A.B.C.D/100@A.B.C.D Standard DESTROY 9ed841f1-b75d-4462-b8c4-100b976d3567 2013-10-14 20:48:56.370468 [DEBUG] switch_core_state_machine.c:581 (sofia/internal_A.B.C.D/100@A.B.C.D) State DESTROY going to sleep 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [WARNING] switch_core_state_machine.c:517 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 sofia/internal_A.B.C.D/100@A.B.C.D Abandoned 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [NOTICE] switch_core_state_machine.c:520 Hangup sofia/internal_A.B.C.D/100@A.B.C.D [CS_NEW] [WRONG_CALL_STATE] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_channel.c:3139 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [KILL] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_session.c:1345 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:418 (sofia/internal_A.B.C.D/100@A.B.C.D) Running State Change CS_HANGUP 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:681 (sofia/internal_A.B.C.D/100@A.B.C.D) State HANGUP 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] mod_sofia.c:465 Channel sofia/internal_A.B.C.D/100@A.B.C.D hanging up, cause: WRONG_CALL_STATE 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:48 sofia/internal_A.B.C.D/100@A.B.C.D Standard HANGUP, cause: WRONG_CALL_STATE 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:681 (sofia/internal_A.B.C.D/100@A.B.C.D) State HANGUP going to sleep 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:694 (sofia/internal_A.B.C.D/100@A.B.C.D) Callstate Change DOWN -> HANGUP 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:449 (sofia/internal_A.B.C.D/100@A.B.C.D) State Change CS_HANGUP -> CS_REPORTING 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_session.c:1345 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:418 (sofia/internal_A.B.C.D/100@A.B.C.D) Running State Change CS_REPORTING 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:766 (sofia/internal_A.B.C.D/100@A.B.C.D) State REPORTING 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:92 sofia/internal_A.B.C.D/100@A.B.C.D Standard REPORTING, cause: WRONG_CALL_STATE 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:766 (sofia/internal_A.B.C.D/100@A.B.C.D) State REPORTING going to sleep 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:443 (sofia/internal_A.B.C.D/100@A.B.C.D) State Change CS_REPORTING -> CS_DESTROY 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_session.c:1345 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_session.c:1553 Session 86 (sofia/internal_A.B.C.D/100@A.B.C.D) Locked, Waiting on external entities 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [NOTICE] switch_core_session.c:1571 Session 86 (sofia/internal_A.B.C.D/100@A.B.C.D) Ended 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [NOTICE] switch_core_session.c:1575 Close Channel sofia/internal_A.B.C.D/100@A.B.C.D [CS_DESTROY] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:568 (sofia/internal_A.B.C.D/100@A.B.C.D) Callstate Change HANGUP -> DOWN 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:571 (sofia/internal_A.B.C.D/100@A.B.C.D) Running State Change CS_DESTROY 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:581 (sofia/internal_A.B.C.D/100@A.B.C.D) State DESTROY 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] mod_sofia.c:375 sofia/internal_A.B.C.D/100@A.B.C.D SOFIA DESTROY 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:99 sofia/internal_A.B.C.D/100@A.B.C.D Standard DESTROY 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:49:01.830470 [DEBUG] switch_core_state_machine.c:581 (sofia/internal_A.B.C.D/100@A.B.C.D) State DESTROY going to sleep -- Mimiko desu.
On 14.10.2013 21:05, Mimiko wrote:
35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [NOTICE] switch_channel.c:1034 New Channel sofia/internal_A.B.C.D/100@A.B.C.D [35a84dc8-0a11-449a-9a81-aa0a6ad75ab6] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [DEBUG] switch_core_session.c:1010 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [DEBUG] switch_core_session.c:1010 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK] 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [DEBUG] switch_core_state_machine.c:418 (sofia/internal_A.B.C.D/100@A.B.C.D) Running State Change CS_NEW 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.690475 [DEBUG] switch_core_state_machine.c:436 (sofia/internal_A.B.C.D/100@A.B.C.D) State NEW 35a84dc8-0a11-449a-9a81-aa0a6ad75ab6 2013-10-14 20:48:51.810383 [DEBUG] switch_core_session.c:1010 Send signal sofia/internal_A.B.C.D/100@A.B.C.D [BREAK]
I did found that this logs were due to an attacker trying to hack the system and setting bad invite packets with 19 mins interval. Its hard to detect and block such attacks, event for Fail2ban, because the log does not contain remote IP from which the packet came. It were great for FS to log IP not only for authentication failures, but also for calls. -- Mimiko desu.
participants (5)
-
Ken Rice
-
Martin Cmelik
-
Mimiko
-
Nathan Neulinger
-
Steven Ayre