Who would believe, in the age of Skype, Whatsapp and Facebook – telephony fraud, one of the most lucrative and cleanest form of theft – is still going strong. Applications of the social nature are believed to be harming the world wide carrier market – and carrier are surely complaining to regulators – and for a legitimate reason. But having said that, looking at some alarming fraud attempt statistics, thing will show you a fairly different story.

So, analysing fraud is one of my things, I enjoy dropping honeypots around the world, let them live for a few days and then collect my data. My rig is fairly simplistic:

  1. A have a Homer (www.sipcapture.org) server to capture all my traffic
  2. A have an amazon AWS cloudformation script that launches up instances of Asterisk, FreeSwitch and Kamailio
  3. All instances are pre-configured to report anything back to Homer
  4. Upon receiving a call – it will be rejected with a 403

Why is this a good honeypot scheme? simple – it gives the remote bot a response from the server, making it keep on hitting it with different combinations. In order to make the analysis juicy, I’ve decided to concentrate on the time period between 24.12.2016 till 25.12.2016 – in other words, Christmas.

I have to admit, the results were fairly surprising:

  1. A total of 2000 attacks were registered on the honeypot server
  2. The 2 dominant fraud destinations were: The palestinian authority and the UK
  3. All attacks originated from only 5 distinct IP numbers

Are you wondering what the actual numbers are? Here is the summary:

Row Labels Grand Total
441224928354 19         19
441873770007       204   204
76264259990     1     1
17786514103         2 2
972592315527   1774       1774
Grand Total 19 1774 1 204 2 2000

As you can see, the number 972592315527 was dailed 1774 from a single IP – I can only assume this is a botnet of some sort, but the mix of IP numbers intrigued me. So, a fast analysis revealed the following:

Amsterdam? I wonder if it’s a coffee shop or something. The thing that also intrigued me was the phone number, why would the bot continue hitting the same mobile phone number? I couldn’t find any documentation of this number anywhere. Also, the 97259 prefix automatically suggests a mobile number in the PA, so my only conclusion would be that this is a bot looking for a “IPRN” loop hole – which is again fraudulent.

So, if this what happens in 48 hours – you can imagine what happens over a month or a year.


The above post contains only partial information, from a specific server on a network of worldwide deployed honeypots. The information provided as-is and you may extrapolate or hypothesize what it means – as you see fit. I have only raised some points of discussion and interest.

Should you wish to join the lively discussion on HackerNews, please follow this link: https://news.ycombinator.com/item?id=13354693 for further discussion.




A dear friend, the CEO of fone.do, Mr. Moshe Meir had written a blog post on the fone.do blog. The title is: “Is there a future for Asterisk?

I have a different take on the thing. I think that Moshe is simply asking the wrong question. He should be asking “What is the role of Asterisk in your future?”.

I know Moshe personally, and I’m shocked by the short sighting of his question. Asterisk was born, initially as a PBX – it has evolved to much more than that. Last year, in my presentation, I showed a slide of a large elephant, with various blind people feeling it around – trying to ascertain what an elephant is. Asterisk is that elephant, it will be what you want it to be. You want it to be a PBX, so be it. You want it to be a Video gateway, so be it. You want it to be a services control point for your OTT application, so be it. You decide!

As technologists and visionaries, it is our job to look ahead into the future and think: “What is the next step? where will we be in 5 years from now, in 7 years from now?” – that is called visionary, pioneering, disrupting and most importantly, exceptional. You want to know what the future of Asterisk will be? look at what you need, that is where it will go. Was always the case, and will always be the case.

Yes, I use Kamailio, OpenSIPS, FreeSwitch and other tools. Yes, I’ve used OpenRTC, EasyRTC, Kurento and others. Yes, we still use them and YES – WE USE ASTERISK, and we will most probably keep using Asterisk for our needs – where it fits the best and assumes the task to the best of its ability. This is why every year we come to Astricon, this is why every year we join the DevCon, this is why every year we make it our business to keep track of whats going on in the core. Moshe, you are forgetting, we are not drivers, we are mechanics – we build and fix things. Tony Stark in Iron Man 3 says: “I’m a mechanic” later on the child replies “You’re a mechanic, fix it” – here’s my challenge to you – “FIX IT!” – make it better, make it stronger, make it into the thing you love and want.

One more thing Moshe, and this is something for you to think about – when you write a blog post, on a blog that has no way of allowing its readers to comment or participate in any form, you should not write opinion posts. Opinions are meant for people who can interact and respond.

** EDIT: You can comment to this post via facebook, at: http://on.fb.me/1QQQ18Q

For many years, the question of high availability had always circled the same old subject of replication – how do we replicate data across nodes? how do we replicate the configuration to stay unified across nodes? Is active-active truly better than active-passive? and most importantly, what happens beyond the two node scenario?

Since the inception of the Linux-HA project (and I do believe it’s been around for years now – over 15 years), it has been the pivotal tool for creating Linux based high-availability clusters. Heartbeat, Stonith and Mon will take care of floating the IP numbers and services across – no biggy there, making sure the data is consistent across the board, that’s something completely different. Recently, one of the better known Asterisk Commercial offerings had launched an Asterisk-HA solution – it’s been long due – it’s just a shame it’s a commercial offering without an Open Source derivative, after all, it is Open Source based (I hope).

However, being a high availability solution on one hand, doesn’t mean you are truly a clustered solution – it is an active-passive solution, with a major caveat (at least as I see it), that if your data sync fails for some reason, you end up with a split-brain issue – and your entire solution is now made moot. Don’t get me wrong here, I think that for now, the solution is the next best thing to sliced bread, simply because there is no other solution out there. However, the fact this is the only solution, doesn’t make it the right solution.

What does federating mean in this respect? it means that data doesn’t need to be replicated across the board, it is automatically trickled across the network, making sure all nodes in the network have clear visibility for it. If a node fails inside the cluster, client automatically redirect themselves to a new node, no need for floating IP numbers. Call routing is automatically determined upon request and are never preset for the entire platform. And most importantly, the amount of data traversed between the nodes is as minimal as possible, preventing excessive usage of network resources and I/O.

What would it mean to federate the configuration of a PBX system? first of all, make sure each unit is capable of working on its own, information should be trickled across the nodes via two methodologies: A multicast/broadcast mechanism (for local LAN connected nodes) and a Published/Subscriber relation (for externally connected nodes). When a change is made to any of the systems, that change is then replicated to all the systems. The configuration is never fully transmitted between nodes (apart from a new node joining the cluster). Routing decisions are dynamically made across the network, they are not predetermined or preconfigured. There is no need to keep the cluster nodes in perfect physical alignment, mixing hardware specifications should be considered the norm. External devices should be able to “speak” to the cluster, without being aware of its existence.

Once we achieve all of the above, we’ll truly get to a point where we’ve clustered Asterisk (or another open source project) the right way.