Telephony Fraud – Further Analysis

Following yesterday’s post, I’ve decided to take another set of data – this time following the start of the year, with a specific data profile. What is the profile? I will describe:

  1. The honeypot server in this case was a publically accessible Kamailio server
  2. The honeypot changed its location and IP every 48 hours, over a period of 2 weeks
  3. The honeypot was always located in the same Amazon AWS region – in this case N.California
  4. All calls were replied to with a 200 OK, followed by a playback from an Asterisk server

In this specific case, I wasn’t really interested in the attempted numbers, I was more interested to figure out where attacks are coming from. The results were fairly surprising:

The above table shows a list of attacking IP numbers, the number of attempts from each IP number – and the origin country. For some weird reason, 97% of potential attacks originated in Western Europe. In past years, most of the attempts were located in Eastern European countries and the Far-East, but now this is Mainland Europe (Germany, France, Great Britain).

Can we extrapolate from it a viable security recommendation? absolutely not, it doesn’t mean anything specific – but it could mean one of the following:

  1. The number of hijacked PBX systems in mainland Europe is growing?
  2. The number of hijacked Generic services in mainland Europe is growing?
  3. European VoIP PBX integrators are doing a lousy job at securing their PBX systems?
  4. European VPS providers pay less attention to security matters?

If you pay attention to the attempts originating in France, you would notice a highly similar IP range – down right to the final Class-C network, that is no coincidence, that is negligence.

Now, let’s dig deeper into France and see where they are attempting to dial:

So, on the face of it, these guys are trying to call the US. I wonder what are these numbers for?

Ok, that’s verizon… let’s dig deeper…

Global Crossing? that is interesting… What else is in there???


So, all these attempts go to Landlines – which means, these attempts are being dialed most probably into another hijacked system – in order to validate success of finding a newly hijacked system.

Well, if you can give me a different explanation – I’m all open for it. Also, if any of the above carriers are reading this, I suggest you investigate these numbers.



We are all probably taking crazy pills!

Recently, I can’t but escape the feeling that a great portion of the high tech industry is taking crazy pills, as part of its morning diet. Seriously, if we are not taking crazy pills, you can’t explain the overload of Legacy Tech that is rapidly making a comeback – under a new name and flag. Yes, buzz-words were always a thing of this industry, but seriously, don’t you feel this is getting a little over-done lately?

What am I talking about? Well, let’s take a look at some recent buzz-words and go through them:

IoT – Internet of Things

If you lookup the term in Google, you will surely find the following on Wikipedia:

The Internet of Things (IoT) is the network of physical objects—devices, 
vehicles, buildings and other items—embedded with electronics, software, 
sensors, and network connectivity that enables these objects to collect 
and exchange data. The IoT allows objects to be sensed and controlled 
remotely across existing network infrastructure, creating opportunities 
for more direct integration of the physical world into computer-based 
systems, and resulting in improved efficiency, accuracy and economic 
benefit; when IoT is augmented with sensors and actuators, 
the technology becomes an instance of the more general class of 
cyber-physical systems, which also encompasses technologies such as smart 
grids, smart homes, intelligent transportation and smart cities. Each thing 
is uniquely identifiable through its embedded computing system but is able 
to interoperate within the existing Internet infrastructure. Experts estimate 
that the IoT will consist of almost 50 billion objects by 2020.
<sup id="cite_ref-9" class="reference"></sup>

Cool – isn’t it? Well, the Internet of Things existed far before the term was invented. It simply looked a little different. We had devices with SIM cards or devices with some other form of interaction technology – and we didn’t use IP, we used something else. But the minute it used IP, it got the name “Internet of Things”, simply due to the relation to the IP protocol. Almost 10 years ago, an Asterisk based plant irrigation project was shown on the web. Is that IoT? maybe not, but the overall result is similar. Actually, it is exactly the same, 10 years before IoT – but if you can’t see that it is the same, you are taking crazy pills.

Contextual/Task Oriented Chat Bots

Oh my god – when people showed me slack for the first time, I really didn’t understand why they are so excited about it. To me it looked mostly like a glorified mash-up between IRC, EggDrop and fancy Pseudo-Agile management system.

Chat bots that do stuff? really? In 2001 I worked at a company where I had to monitor and
control a set of servers, interconnected with 6 different SMS connections to various carriers. In order to get this stuff working and also get it working from my mobile phone, I used a combination of Nagios, Kannel, EggDrop and IRC. I used the IRC server as my command and control interface, EggDrop carried commands from the IRC server over to the Kannel Server and the Nagios servers, to run remote tasks and test various elements.

In 1999, I consulted a company that was called eNow (back then, ChatScan). They were scanning thousands of IRC channels to Internet trend analysis. Now, think about it, we scanned these IRC channels using EggDrop. Simple, TCL based, IRC Bots that would roam the IRC networks in search of interesting things.

If you are wondering what EggDrop is, check out:

Over Virtualising

Can someone please explain me the following scenario: You lease a cloud based, small foot print server from any of the cloud companies, you then run Docker it and create additional virtual machines on the VM instance.

Dude, might as well just have your own server with Proxmox, KVM or some other virtualisation container. I just don’t get it, the fact that you can do something, doesn’t always mean that this is what it is meant for.

The following video just shows this is the funniest way ever:




Hyper Engagement – Enabled!

So, it has now been 2 months, since I started my own little social experiment. Early November, I decided to silence down all my mobile device notifications and mute any “distracting interaction” I could find. No, I didn’t silence off my mobile phone completely – it will just make it useless, but I didn’t make it as less intrusive as possible.

So, about 3 weeks ago I decided that it’s high time, to put my trusty Lenovo X1 Carbon Touch to its final resting place. I was contemplating what notebook should I get. My gut feeling told me: “Time for another Lenovo”. But, somewhere in the back of my head was this ever annoying question: “Is a Mac truly better?”. So, in a spur of the moment, I decided to buy a Mac. Because I am what you would define as a power user, I decided to get the most bang out of eace one of my spent dollars.

So, now I’m closing a month with my Mac and combined with my “Hyper – Not!” regime, I started a fairly lengthy road of re-getting used to using a Mac. Have to admit, El-Crapitan has its quirks. Who am I kidding, compared to previous versions, El-Crapitan is somewhat annoying. However, after getting used to its little quirks and kinks, when you combine the Good of the Mac and “Hyper -Not!” – I managed to reach at least a 40% increase in my productivity.

Time that used to be spent on waiting for things to launch properly and setting up on my Lenovo, just cut by almost 70%. Issues of the machine halting on me or requiring a reboot – gone. Issues that required me to go into Task Manager and seek a process to kill – gone!

In other words, I spend far less time on BS and more time on actual work that needs to be done. Previously, I was able to focus on 2 projects – tops. Today, I’m able to focus on 5 different projects and be involved with 2 more. Is it purely to moving to a Mac? I doubt it. Is it purely related to my “Hyper – Not!” regime, i doubt it as well. It must be a combination of the two. How long will I be able to keep this up? donno, I’ll keep you all updated on my findings.


Don’t Replicate – Federate

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.

Federating Asterisk – truth or myth?

During this years’ Asterisk Developers’ Conference, one of the subjects I’ve raised an issue for Asterisk is: “Federating Multiple Asterisk Instances”. Now, for the seasoned Asterisk user/developer, the answer would be simple – use Kamailio/OpenSIPS for that scalability, and use Asterisk as a Media Gateway or application server.

But I ask the following: “What if we could federate Asterisk without the need for an external component? What if we could federate Asterisk in such a way where our users aren’t event aware of the federation process, and it’s fully autonomous? What would actually be required in order to do that?”

I’m normally confronted with these questions on a day to day basis, looking at the problem from different angles – thinking to myself: “Ok, I know the normal box here – but where are the outer limits? what can I do to make it more robust on one hand, without truly making a mess out of it.”

A federated database is defined as: “A federated database system is a type of meta-database management system (DBMS), which transparently maps multiple autonomous database systems into a single federated database. The constituent databases are interconnected via a computer network and may be geographically decentralized. Since the constituent database systems remain autonomous, a federated database system is a contrastable alternative to the (sometimes daunting) task of merging several disparate databases. A federated database, or virtual database, is a composite of all constituent databases in a federated database system. There is no actual data integration in the constituent disparate databases as a result of data federation.” –

So, we would like to virtually create a “map-reduce” functionality for Asterisk? can we truly create a map-reduce’ish functionality for Asterisk? should it be internal? should it be external?

In order to accomplish this, we are required to create a federator – a device capable of handling the information regarding each users, device, trunk, provider and other wise SIP/IAX2 entity connected to our system. The federator for all practical purposes is a data store, be it a key-value store, a database, a shared memory environment or some other form of data distribution layer.

Here are some key issues that true federation may be required to tackle:

  1. Geo-Position Agnostic – A truly federated system should render services identically across the board, regardless of where the user is located.
  2. Services Agnostic – A truly federated system doesn’t care if the user is connected to an Asterisk server version 12 or 13, it should behave identically.
  3. Version Agnostic – A truly federated infrastructure can leverage older version and even other software, without changing the underlying federation layer.
  4. Predictable Scalability – A truly federated infrastructure will allow for growth to be planned linearly, with discrete measure methods.

So, you want a tip on how to start federating your systems? here’s step number 1 – there is no central registry, there is no SIP proxy, there is only the cloud and the services it renders. Start thinking from this point and see where you go.