We will be updating our Managed A-Z Termination rates and codes on February 10th 2012 for Platinum, Gold and Silver decks. Links to the rate files are below.

In our recent survey you told us that whilst our extensive breakouts mean our decks offer excellent value for actual traffic, customers making route selections manually rather than through an LCR may miss the benefits our breakouts offer. To overcome this our automated pricing system ‘Sabre’ has been modified to benchmark competitor rates in the Gold deck. Where Simwood already offers better value for a destination we continue to do so but where a competitor has superior pricing, we will now either match or beat it where we can. Whilst for the majority of destinations our rates are unaffected by benchmarking, for others such as UK Mobile you will notice some keen reductions. We hope this results in your human LCRs putting Simwood first in route where we are not already.

We would also remind you about our genuine special offer for US termination on our Gold deck. US landline and Mobile are now available at astonishingly low rates ($0.004/£0.0025/€0.003) on the Gold deck due to our significant relationships in the USA.

Platinum A-Z:  GBP USD EUR
Gold A-Z:  GBP USD EUR
Silver A-Z: USD

USA codes excluded from the above files are: USA Mobile
Direct and transit routes

We had the pleasure of joining in a discussion this week on VoIP User Conference (VUC) regarding our IP Reputation service with ThreatSTOP, our Darknet research and specifically our SIP Honeypot research. Also discussed was IP Reputation as part of our security solution.

Click below to listen or to subscribe to VUC as a podcast see iTunes (UK link).

Download: VUC with Simwood & ThreatSTOP
Listen:

To discuss any of the services mentioned, please contact us.

We’re delighted to present a second customer Case Study.

SureVoIP are an Aberdeen based ITSP making use of Simwood A-Z termination.

	SureVoIP case study

We have today enabled our latest OFCOM allocations of over 238,000 new DDIs and non-geographic numbers. The additions include the UK Nationwide 03 number range which are billed to callers as geographic calls, multiple new 0844 ranges and extensive DDI ranges.

These are available immediately through the portal or API as both Standard and Gold numbers. You can search for specific number sequences or even locate and configure blocks of up 100 consecutive numbers.

As previously, non-geographic ranges such as 0844 are available at no cost and DDIs will be billed within one of our wholesale packages. 03 UK Nationwide numbers will be treated as DDIs for billing purposes.

We’re delighted to present the first in a series of customer Case Studies.

Fluency Communications are a Scottish ISP making use of a wide selection of Simwood services. Here they comment on:

• - VPLS
• - Co-location
• - IP Transit

Fluency Communications case study

We’re continuously investing in our IP network to ensure that it is the best it can be. We’re determined that anyone doing VoIP business wants to be on or behind the Simwood network because of the direct benefit to their business. So, today we’re delighted to announce we’ve joined LINX (London Internet Exchange).

As we’ve mentioned before, peering is where traffic between two ISP networks travels directly between them rather than over another network. This minimises the opportunity for disruption, ensuring high performance. We already peer privately with many networks and have been members of other peering exchanges such as LONAP and Edge-IX (formerly ManAP) for some years now. As a result we peer with anyone who’s anyone in the voice space and approximately 80% of our traffic flows directly to peers, a figure which is amongst the highest in the industry.

LINX is one of the largest peering exchanges on the planet and passes over 1Tb per second of traffic at peak in addition to approximately 648Gb per second privately. Approximately 83% of the Internet routing table is potentially available through peering on LINX and being a member enables us to increase our peering further, especially with non-UK networks, and ultimately to pass yet more of our traffic directly to the destination network.

For redundancy LINX operate two completely separate peering networks. Simwood is present on both of them and we’re peering both IPv4 and IPv6 on both.

We’re delighted to offer a special rate for IP Transit orders placed before September 30th 2011. Enjoy a 100Mb port on our voice-optimised network in Telehouse East for a fixed rate of just £300 per month*. Ports in Scolocate or Synergy House Manchester are available for £450 per month*, but again, flat rate with no charge for traffic.

In all cases our full IPv4 and/or IPv6 routing table will be available including over 100 peers in London and Manchester and quality international routing from multiple sites. Our network is entirely Brocade based with our elegantly simple uncontended national MPLS ring delivering superb performance. Customers in all sites enjoy local routing rather than simply remote access to London.

Delivery is available by BGP for customers running their own AS, or as fixed transit for those requiring IP addressing. We can also assist with a PI/AS application for those who would like to operate their own AS without becoming a full local RIPE registry.

Please contact us to order or for GigE or 10GigE port requirements.

* Set-up charge of £500, VAT, and cabling not included. Subject to 12 month contract.

When we introduced our Darknet a few weeks ago we commented how shocking the level of traffic it was receiving it was. Keep in mind, the Darknet comprises IP addresses which we have not issued to customers. They exist mathematically but have never been issued, are not in use and therefore should receive no traffic whatsoever. We concluded then that the vast majority of the traffic it was receiving was nefarious.

Darknet events

Our Darknet sees hundreds of thousands of intrusion attempts per day. It equates broadly to 700-1000 per Internet connected IP address per day. This is a baseline, IP addresses which are actually in use (such as our honeypots) see far far more as they also receive targeted traffic. We believe your IP addresses will be seeing a similar level of traffic.

As we highlighted before, much of this traffic is targeting very few ports and a decent firewall will offer a measure of protection providing the port targeted is not open. But what if it is? What about, for example, the recently found Apache vulnerability which could affect your web server on port 80? You cannot close port 80 to everyone if you want your website on-line so we need to consider alternatives.

There’s a few options:

• - Patch service. Naturally, regular penetration testing and patching will keep your public facing systems more protected from known issues.
• - Hide service. Customers using our DDoS Security Service to protect websites benefit from a high performance web cache in front of their real web farm. This intercepts and handles all requests, improving performance dramatically but also offering protection through topology hiding.
• - Protect service. You could deploy an IDS to monitor the ‘content’ of traffic. We greatly favour intrusion prevention over detection and customers behind our DDoS Security Service benefit from this – our IPS will detect and block packet anomalies such as those used in the Apache vulnerability.
• - Block bad traffic. Whilst all relevant solutions all of the above are re-active. It would be far better if you could examine the ‘intent’ of traffic entering the network as well as the ‘content’. Any firewall will enable block-lists to drop traffic from certain addresses; but what addresses? Let’s look at that now.

Our Darknet sees 16,000-20,000 IP addresses per day and as we now have a decent history of data we wanted to analyse their uniqueness. Let’s face it, if it is the same 20,000 every day, or substantially so, then anyone could maintain their own black list and they don’t need us.

The results are actually quite shocking. 81% of IP addresses hitting the Darknet are new and unique that day and 4% are unique to the time of that event. Just 2% are two days old and it tails off from there. So had we simply blocked bad the source addresses we saw yesterday, then the chances are we’d be deriving very little protection. Worse still, consider that today’s bad address could have been re-allocated to a different and innocent host tomorrow, particularly in the case of DSL networks with dynamic address allocation.

Age of source IP addresses hitting the Darknet

So does that mean there’s no basis to IP Reputation? Well no, because it isn’t simply a list of bad addresses!

If we analyse the same data again looking at source country rather than source IP address, we’ll see that 100% of offenders have been in the database the entire time so there is definitely a behavioural element to bad-ness. For a business predominantly doing business in one location, blocking traffic from certain parts of the world would have merit. In fact, our IP Reputation service enables customers to block specific countries with a single click. Blocking all countries where bad traffic had originated would be too blunt though.

IP Reputation aims to fill in the grey area between the specificity of a single IP address and the generality of blocking by country to enable the maximum level of protection, whilst avoiding false positives. Let’s re-run the data again but this time lets look at it at a network (AS) level. This time we see that just 20% of networks are new in the last day, and a similar proportion have been in the database the entire time. Getting better.

Darknet age of source networks

Blocking networks as a whole is appropriate in some cases, albeit few.  It would be inappropriate to block an entire network because of one or two bad IP addresses, but what if we see attacks every day from different IP addresses in the same subnet? If that subnet can be identified then traffic from it can reasonably assumed to be bad.

If you were to analyses our IP Reputation output, you would find a large number of individual addresses, and even entire networks where they have been determined to be entirely bad. In the most part though you’d find blocks of addresses between the two where the bad-ness extends to sub-allocations of IP addresses which are collectively being used for nefarious purposes whilst avoiding those being used innocently.

Of course, subscribers to the IP Reputation service aren’t only seeing the output of our Darknets and Honeypots. Simwood is just one of  the sources of data being submitted to ThreatSTOP. ThreatSTOP analyse and cross-reference multiple sources of data, including removing spoofed addresses, to arrive at a continuously updated list of address ranges which your firewall can be confident in blocking.

ThreatSTOP is delivered by DNS and can be integrated with almost any firewall. It is available for a simple annual subscription. It is also included in our DDoS Security Solution. Please contact us for a quote.

Our SIP honeypot sprung last night on hackers out of Palestine. On the face of it their attack was very typical – OPTIONS request, dictionary REGISTER scan followed by a number of INVITEs once they had identified a succesful user name and password. Typically too their IP address (one with no adverse history) was submitted to ThreatSTOP so IP Reputation customers could be protected from attacks from the same source very quickly.

SIP honeypot events September 2nd 2011

However, our attention was also drawn to traffic from one of our friendly UK competitors. Initially we suspected foul play (sorry guys!) until we discovered we were initiating the traffic to them and on investigation this traffic was tied back to the Palestinian intrusion.

We’ve used a pretty much default installation for our Honeypots in order to catch attacks targeting the same, and on closer inspection we’ve caught a style of attack we have not seen before. These guys are very clever it seems and the methodology used enables an attacker to leverage an open ENUM service to turn equipment performing ENUM lookups into a SIP relay. By default even with no gateways/trunks configured most of the common open source gateway solutions make ENUM lookups by default and are vulnerable to this.

In this case our attackers passed a call to an international toll-free number, an ENUM lookup was made and a result returned from Freenum. That result contained URIs at two other providers, one wholesale, one retail, both of whom had injected records into FreeNum for the completion of such calls.

This got us thinking that theoretically this could be used to make an INVITE to any URI from the account on the compromised box even if URI dialling is disabled. This could have multiple consequences:

• - Calls ‘from’ the compromised box to an authenticated route would be billed as originating from that box. This is more easily done with the user name and password they have obtained by direct INVITEs however.
• - The compromised account may not be permitted to make chargeable calls in the dial-plan but using ENUM this can be circumvented. This might have interesting knock-on implications for many types of fraud monitoring which consider the ENUM routed call to be free.
• - The compromised box can trivially be used as a relay to route to other compromised boxes, or initiate attacks and appear as the perpetrator.

Tjardick set about putting our theory to the test and indeed with a compromised account on a box performing the default ENUM lookups, was able to make both chargeable calls and dial URIs via the compromised box.

Freenum allocates registrants a short code which refers to their entity. This enables a number to be assembled of the form <any_number>*<my_freenum_id>. An ENUM lookup for this number will return a record containing available URIs. There’s nothing unusual here but as this all hangs under <my_freenum_id> one has complete control what those records are and they can easily be of the form sip:<dial_this_number>@<any_sip_provider>. Records can be changed on the Freenum website or users can even have delegated DNS and make changes locally. We could dial 1*<my_freenum_id> and change that FreeNum side to return <dial_another_number>@<any_sip_provider> or simply set up some wildcard matching such that 1*<my_freenum_id> routes to provider X, and 2*<my_freenum_id> routes to provider Y.

As the compromised box is dialling a ‘number’ any restriction on URI dialling doesn’t apply and since the call follows a positive ENUM hit it might be assumed to be settlement free for fraud monitoring purposes. This requires a compromised registration and to actually place calls chargeable to the compromised network would require a hit on the provider authenticating traffic from that source, but it is possible. With a single Freenum account an attacker can quickly try multiple third party providers using pre-configured patterns.

We consider the biggest risk here is that the box is used to route to other relays or conduct attacks, implicating the compromised equipment, hiding the true source and all remotely controlled through configuration of the ENUM records.

We recommend turning off the default ENUM look-ups or certainly making them conscious and part of considered dial-plan logic. You could also force INVITEs resulting from ENUM lookups out over a dedicated interface which has no gateways configured on it although this will still enable the relay to used against third parties.

In conclusion we consider this validates the idea that monitoring cost reports or the other home-grown methods of fraud control in use by providers are inadequate and too late in the cycle. Stopping traffic getting to equipment through the use of IP Reputation helps prevent intrusion in the first place and in this case the attacker’s IP address was blocked from production equipment and customers before they began passing actual INVITEs to the Honeypot.

Last week we introduced you to our Darknet which is doing an excellent job in identifying sources and types of general dirty traffic on the Internet to feed into our Security Services. Honeypots are another critical component.

What is a Honeypot?

A Honeypot is a system configured to look and behave like a production service, in this case a SIP proxy, for the purposes of capturing data on attempted security intrusions, their perpetrators and methods. They are also typically made easier to compromise than production equipment in order to focus attention.

Our SIP Honeypots

Our Honeypots sit amongst our production gateways and proxies and look identical to an attacker. Genuine customers configured correctly will never come into contact with them but anyone scanning the Simwood Network for SIP vulnerabilities will. They are configured to be compromised with very easy to guess passwords and when compromised will appear to complete any attempted calls. At every stage all network traffic is captured and any audio passed is recorded, both for the purposes of law enforcement and analysis.

A major motivation for us moving into the security space was the level of dictionary REGISTER attempts we saw against production SIP equipment – 10-20 events per day each of several thousand user/password combinations per production machine. They were pretty easy to notice.

In analysing Honeypot traffic we have firstly ignored traffic from mal-configured customers – whilst only a handful of addresses are involved, these substantially skew the results so have been removed. Further, we’re looking at a Honeypot which sits behind our IP Reputation and DDoS stack. Together these have all but eliminated the dictionary REGISTER attempts on the production network by blocking known offenders before they enter the network. The primary goal of the Honeypot is to identify new potential offenders and feed the data into the other systems to prevent mischief in the future. Finally, we’re interested only in SIP traffic here – general dirty noise is left to the Darknet to observe.

Findings

Darknet events over 24 hours

In contrast to the Darknet where we were amazed at the scale of bad traffic (see above), the first lesson from the Honeypots is that the devil is in the detail. Stripping out all the known offenders and noise we’re left with a fairly unspectactular level of traffic but one which makes interesting reading. Below is a snapshot of our real-time map of sources for the last 24 hours – you’ll note there’s relatively few.

Honeypot SIP events after filtering noise

Generally speaking these all originate from dedicated server / VPS providers who we’ll refrain from naming and shaming just yet. Mostly a single IP address is involved but in some cases we’ve seen over recent weeks a few are involved, all generally on the same subnet from the same provider for the same ‘attack’. As dedicated servers require contracts, payments and configuration we generally expect these IP addresses to hang around a little bit longer than the average botnet participant for example.

The other observation is that this traffic would be all but undetectable on a production system. We used to think the REGISTER scans were the attempted intrusion but it is apparent that these are some way through the process and the brute-force types mentioned above are the exception.

Typically a scan will start with a single OPTIONS request – just one! That is a single request which appears to determine the succession of the attack. On equipment which does not respond the scanner moves on and that one request is all we hear of them. On equipment which does respond we’ll subsequently see one of two things, often both –  REGISTER attempts and INVITEs. Generally these are at a low level and suggest two different kinds of attacker, the former using a scanner such as SIPVicious, the latter involving more human intervention through eyeBeam or similar. In both cases these can be several hours after the successful OPTIONS request.

We’ll be monitoring at both the IP level and the telephony level and reporting going forwards. Meanwhile the key takeaway here is that SIP based attacks are not all brute force and obvious. They start with an imperceptible level of traffic but that is sufficient for the Honeypot to capture them and feed the findings through to our IP Reputation solution to protect our customers and ourselves from subsequent mis-behaviour.