Categories
Asterisk Support Knowledge Base Security

Catching the IP of anonymous callers on Asterisk servers

Hi just sharing a simple bit of dialplan to catch anon callers ip addresses when using freepbx and Anonymous callers is set to yes, which is needed for some suppliers.

Normally I would say lock your firewall to only known IPs, but in some cases this isn’t possible

Im sure if you have a Asterisk server with a public IP you will have seen calls on the console screen where the call is to a destination but the callers are exten@yourserver . Well this little bit of dialplan at the end of you default sip context should catch them and log them with the ip of the originating server

In extensions_custom.conf add the dialplan below

[catchall]
exten => s,1,Noop(Dead calls rising)
exten => s,n,Set(uri=${SIPCHANINFO(uri)})
exten => s,n,Verbose(3,Unknown call from ${uri} to ${EXTEN})
exten => s,n,System(echo "[${STRFTIME(${EPOCH},,%b %d %H:%M:%S)}] SECURITY[] Unknown Call from ${CALLERIDNUM} to ${FROM_DID} IPdetails ${uri}" >> /var/log/asterisk/sipsec.log)
exten => s,n,Hangup()

Then in Custom Destinations add a destination as  catchall,s,1

so you now get in your logs

[May 1 00:11:06] SECURITY[] Unknown Call from  to 900441516014742 IPdetails sip:101@37.75.209.113:21896

 I hope this is some help to you, It allows other scripts to pick up this address and add it to your firewall.
Categories
System Status

DNS issues affecting calls and routing

On 21-10-2016 there had been a widespread DDOS attack initially in the USA. This has affected service of some of our key voice and DNS service suppliers.

We monitor many sites and run monitoring ourselves and receive status updates from suppliers.

Below are some of the recent ones and some sites reporting the issue

http://www.diario4v.com/tendencias/2016/10/21/ataque-hacker-afecta-twitter-amazon-spotify-reddit-11816.html (you will need to translate)

http://money.cnn.com/2016/10/21/technology/ddos-attack-popular-sites/

https://www.dynstatus.com/incidents/nlr4yrr162t8

Update
Dyn Managed DNS advanced service monitoring is currently experiencing issues. Customers may notice incorrect probe alerts on their advanced DNS services. Our engineers continue to monitor and investigate the issue.

Customers with questions or concerns are encouraged to reach out to our Technical Support Team.
Posted 4 minutes ago. Oct 21, 2016 - 18:23 UTC
Update
Our engineers continue to investigate and mitigate several attacks aimed against the Dyn Managed DNS infrastructure.
Posted 34 minutes ago. Oct 21, 2016 - 17:53 UTC
Update
This DDoS attack may also be impacting Dyn Managed DNS advanced services with possible delays in monitoring. Our Engineers are continuing to work on mitigating this issue.
Posted about 2 hours ago. Oct 21, 2016 - 16:48 UTC
Investigating
As of 15:52 UTC, we have begun monitoring and mitigating a DDoS attack against our Dyn Managed DNS infrastructure. Our Engineers are continuing to work on mitigating this issue.
Posted about 2 hours ago. Oct 21, 2016 - 16:06 UTC

Gradwell:

Our upstream supplier is investigating a DNS issue, which is believed to be causing the problem.

Magrethea

We are now able to confirm that two nodes on our network where impacted by DNS issues between 17:13 and 17:45 today. As many of you will be aware there have been some major DOS attacks today which impacted a number of key sites at this time so we are attributing this issue to that attack.

We will continue to monitor and apologise for the inconvenience this outage has caused our customers.

As can be seen this is out of our control and is affecting many users worldwide.

Categories
System Status

Hetzner Router fault Core23

Router fault Core23
Type: fault message
Categories: network
Start: September 15, 2016 09:00:00 EDT
End: Unknown
Description: Currently a disturbance on the router Core23 exists. Our engineers are working hard on the analysis of causes and resolve the
problem. Please be patient. Once new information is received, we will inform you on this website. We apologize for the inconvenience. Thank you for your understanding.
Affected: RZ17, RZ19, RZ20, RZ21

update: September 15, 2016 10:00:00 EDT
The problem is currently solved. Core23 is routed empty for further analysis of the underlying problem.
Categories
System Status

Hetzner Router fault RZ19 (ex9k1.rz19 and ex9k2.rz19)

Type: fault message
Categories: network
Start: September 13, 2016 16:40:00 EDT
End: September 15, 2016 08:17:00 EDT
Description: Currently, a fault has occurred on the router and ex9k1.rz19 ex9k2.rz19. Our engineers are working hard on the analysis of causes and resolve the
problem. Please be patient. Once new information is received, we will inform you on this website. We apologize for the inconvenience. Thank you for your understanding.

update: September 13, 2016 17:05:00 EDT
It seems that this problem is caused by a fault line card to an upstream router. The problem could be remedied. We will continue to discuss behavior of the router accurately observing and this incident with the manufacturer.

update: September 15, 2016 08:17:00 EDT
Apparently the problem occurred again. We have the affected hardware now replaced precautionary. We apologize for the inconvenience. Thank you for your understanding.
Categories
Blog Knowledge Base System Status

Telehouse outage 21st July 2016

Again today at 8am we started to see alarms coming in from customer sites. The effect seemed more widespread today with Zen inially posting they had issues and some ITSPs posting that they also had issues.

The outage appeared to have started at around ‘7am'(we saw first alarm at 8am , with at least one network at Telehouse North falling over due to a reported loss of power. The situation had mostly been resolved by around 11am, though are still seeing some flapping of services.

Like Wednesday’s outage, it appears that BT has a significant amount of networking equipment at Telehouse North. The has affected an unknown number of BT and Plusnet broadband subscribers, plus other smaller ISPs and services such as Zen Internet that make significant use of BT’s backhaul network.

We can confirm though we have slowly seen all customer alarms clearing. As many customers are aware that we operate a 24×7 monitoring platform so saw this issue start and checked that there was nothing we could do in most cases but also contacted key customers to warn them that they might be issues.
Therefore, any issues that Customers have experienced this morning when connecting to services using BT connectivity (including quality issues) should now be resolved. In the event that issues are still occurring, please reboot equipment on the BT line such as Firewalls or Routers and retest. Nagios monitor screen

If you have any questions whatsoever please do not hesitate to contact us, Also if you are a
Asterisk / Freepbx reseller or user and would like affordable monitoring please get in touch as we provide Asterisk Monitoring from £25 per year.

 

UPDATE ON 20th July issue

Tt looks like a power failure at Telecity Harbour Exchange, where BT and some other ISPs join the LINX peer exchange, is at least partially to blame for the major outage on Wednesday morning.

Service disruption as a result of the Telecity outage lasted for about an hour, from just before 8am until 9:15am, when full connectivity was restored.

LINX said in a statement:

This morning between 07:55 BS and 08:17 BST, one of the datacentres that houses equipment for The London Internet Exchange (LINX) experienced a partial power outage. This affected only one of a number of Internet peering nodes that LINX operates at the facility, and service was fully restored on the LINX network at 09:15 BST.

Several reports claim that this outage affected British Telecom and their services at LINX. While several networks connected to LINX were indeed affected, BT was not one of them. LINX provide two fully redundant platforms to offer better resilience to the UK’s Internet infrastructure, the second platform was not affected by this power outage.

 

 

Categories
Blog Knowledge Base

BT outage on 20th July 2016

BT have confirmed that their recent outage has been ‘resolved and services restored’.

We can also confirm this as we have slowly seen all customer alarms clearing. As many customers are aware that we operate a 24×7 monitoring platform so saw this issue start and checked that there was nothing we could do in most cases but also contacted key customers to warn them that they might be issues.
Therefore, any issues that Customers have experienced this morning when connecting to services using BT connectivity (including quality issues) should now be resolved. In the event that issues are still occurring, please reboot equipment on the BT line such as Firewalls or Routers and retest. Nagios monitor screen

If you have any questions whatsoever please do not hesitate to contact us, Also if you are a
Asterisk / Freepbx reseller or user and would like affordable monitoring please get in touch as we provide Asterisk Monitoring from £25 per year.

Categories
Blog

Mobile roaming, Brexit, and unintended consequences

Click here to view the original on Bruegel By J Scott Marcus  

The intermediate and long-term consequences of the UK “Brexit” referendum of 23 June 2016 are numerous and far-reaching. There has been much discussion of the impact on financial services, but very little to date on the likely implications for telecommunications regulation.

The impacts of Brexit on mobile roaming are by no means large in overall economic terms, but they provide an example of the breadth of ripple effects that can be expected after the UK referendum result, and also of the degree to which the end results are difficult to predict with certainty.

The overall approach to regulation of telecommunications within the UK will not necessarily change much. The Regulatory Framework for Electronic Communications (RFEC) that the European Union enacted in 2002 was largely based on procompetitive UK ideas in the first place.

Certain international aspects are, however, likely to change. The most obvious examples are (1) the relationship of the UK and its national regulatory authority (NRA) Ofcom to its European counterparts; (2) the wholesale payments that UK network operators make to their European counterparts for interconnection; and (3) wholesale and retail arrangements between the UK and the European Union. Our focus here is on roaming.

If the UK were to become a member of the European Economic Area (EEA) (comprised of all EU Member States plus Norway, Liechtenstein, and Iceland), the applicability of the European regulatory framework  for electronic communications would be clear.

Joining the EEA could be expected to oblige the UK to accept most of the burdens of EU membership (including freedom of movement), with fewer of the privileges than the UK currently enjoys. In the discussion that follows, we assume that a UK membership in the EEA will not happen, but it cannot be categorically ruled out.

The UK might still selectively conclude bilateral agreements with the EU (and also with its member states). The implications for telecommunications regulation would depend on exactly which agreements were concluded.

Since Switzerland is in precisely this position (having rejected membership in the EEA in a referendum in 1992), it is perhaps useful to draw a few comparisons.

The Swiss choose to voluntarily participate in the EU’s Board of European Regulators of Electronic Communications (BEREC). In this role, they also participate voluntarily in BEREC’s collection of statistics on international mobile roaming; however, they are not subject to the various EU Roaming Regulations, and consequently do not benefit from them.

The prices that consumers pay for roaming reflect wholesale international payments between the mobile network operators, since the actual service has to be provided in the visited country. Among EU/EEA members, these payments at wholesale level are subject to price caps. Since Switzerland is neither an EU nor an EEA member, Swiss mobile operators are not entitled to the benefits of these price caps. If the EU were to offer these advantageous wholesale arrangements to a third country such as Switzerland or the UK in the absence of a comprehensive free trade agreement, it would likely raise WTO concerns.

Since the higher prices that Swiss mobile operators pay are a real cost, their retail prices are also higher than for mobile network operators in EU/EEA countries, as is visible in the figure below. The high price of roaming in the EU has been a constant source of irritation for Swiss consumers, and has frequently been featured in the Swiss press. One can argue that their retail prices in Switzerland are elevated more than the wholesale charges would strictly require; be that as it may, it is clear that the prices of Swiss mobile network operators cannot be the same as those of mobile network operators in EU/EEA countries.

As long as Swiss mobile network operators (MNOs) pay more at wholesale level for roaming in the EU/EEA than MNOs in EU/EEA Member States, retail prices in Switzerland for EU/EEA roaming can be expected to remain higher than those in EU/EEA Member States. It appears that the UK will shortly find itself in the same position.

[1]  Average retail price per MB of roaming data

JSM-28-6-Fig1

The EU is expecting to migrate over the next year to so-called Roam Like at Home (RLAH) arrangements over the next year, where international roaming prices will be the same as domestic prices. If this indeed comes into play, roaming prices will be even lower than they are today; however, the basic linkages between wholesale charges and retail prices will remain.

To the extent that UK mobile network operators such as Vodafone and O2 (Telefónica) have international affiliates, they have some ability to internalise these wholesale costs. It is nonetheless the case that no MNO covers all EU/EEA Member States; moreover, the ability of MNOs to steer traffic onto their preferred network in the Visited Country is good, but not perfect. The cost of the roaming service will in the end be somewhat higher for UK mobile network operators than for EU/EEA mobile network operators.

Taking all of this into account, it is a safe bet that UK residents with UK mobile subscriptions will pay more for use of the mobile services when roaming in EU/EEA countries than will EU/EEA residents.

[1] Based on both prepaid and postpaid usage in Q2 2015.


 

Categories
Blog

Sangoma’s Commitment to Open Source software

In January of 2015, the FreePBX project became part of the Sangoma family. Being a commercial entity charged with maintaining an open source project can be a challenging endeavor at times. Furthermore, the fact that major open source projects are normally in the care of commercial organizations is usually not given much thought.

Before Sangoma, FreePBX was overseen by Schmooze Com Inc., before that Bandwidth and before that Coalescent Systems Inc. These companies have all done their parts to ensure the survival of the FreePBX project. Sangoma has been dedicated to the open source community, including FreePBX, for many years. In the last year, the FreePBX project has seen great strides, including the release of FreePBX 13 with accelerated development and bug fixes.

Sangoma has also empowered FreePBX with new open source features such as: synchronizing Active Directory with user manager, a complete rewrite of Sound Recordings, the overhaul of the FreePBX interface, playback of recordings in your browser, the addition of the firewall module, sound languages module and so much more.

More recently they have kicked off development on FreePBX 14, Their next major release. One of the major new open sourced features they are bringing to the table is a calendaring system which will become a replacement for many of the scheduling components you use today, like Time Conditions. But They’ll be able to talk more about that in a few weeks.

FreePBX has historically been funded through professional training, professional support services, and commercial modules. These commercial modules tend to enhance the already provided open source functionality. These modules usually require special development or maintenance considerations, so they become paid modules. Over time, they constantly review our collection of commercial modules to see if any meet the requirements to become open sourced.

Thus, they have decided to release several of these commercial modules under the AGPLv3 as open sourced. Some of these modules have been unmaintained for a few years and will be put into the contributed repository to allow community members to build off of the code and revive or enhance the functions for the open source community.

They have also thrown in a few actively maintained modules such as XMPP, RESTapi and Text-To-Speech Engines that will allow broader use and community contributions. Moving forward these modules will still be maintained by Sangoma. In the coming months, They hope to have some great new features regarding RESTapi.

It is  hoped that the release of this code will inspire users to take FreePBX to the next level!

 

Categories
IPPBXs Sangoma

The FreePBX Appliance

Introducing the FreePBX appliance! The FreePBX appliance is a purpose-built, high-performance PBX solution. Designed and rigorously tested for optimal performance, this is the only officially supported hardware solution for FreePBX. The appliance comes preloaded with the FreePBX Distro and includes a one-year warranty!

appliances-header

Featuring the FreePBX Distro, this appliance is an ideal fit for businesses looking to get more from a PBX. With millions of deployments throughout the world, FreePBX is relied upon daily by everyone from enterprises to startups. Leveraging the power of FreePBX has enabled businesses to grow while keeping communication expenses minimal. The FreePBX Distro has made deploying, configuring and using a PBX system easier than ever! With an easy-to-use GUI (Graphical User Interface), getting started is a breeze!

Current Models and System capacity:

The full datasheet can be downloaded from here

Categories
Knowledge Base Technical

Fortigate issues such as one way audio on Call Pickup With Hosted Asterisk and other problems.

We have noted that with some Fortigate routers and firewalls come with SIP helpers enabled by default.

The customer may initially not think that there is any issue and inbound and outbound calls work as expected, But we had noted on one customer site that when they did a call pickup on another phone that was ringing in the office they would not be able to hear the caller. The caller could hear them and if they put the call on and off hold they could speak normally.

On further  investigation with wireshark we noted that the RTP port changed when the pickup took place. We tested this on other sites not using the Fortigate hardware and did not have this issue.

Below are listed the commands to clear the SIP helper settings from the Fortigate hardware.

  1. Open the Fortigate CLI from the dashboard.
  2. Enter the following commands in FortiGate’s CLI:
    • config system settings
    • set sip-helper disable
    • set sip-nat-trace disable
    • reboot the device
  3. Reopen CLI and enter the following commands – do not enter the text after //:
    • config system session-helper
    • show    //locate the SIP entry, usually 12, but can vary.
    • delete 12     //or the number that you identified from the previous command.
  4. Disable RTP processing as follows:
    • config voip profile
    • edit default
    • config sip
    • set rtp disable
  5. And finally:
    • config system settings
    • set default-voip-alg-mode kernel-helper based
    • End

on a fortigate 200D the following is the method to use

Step 1) Removing the session helper.

Run the following commands:

config system session-helper
  show

Amongst the displayed settings will be one similar to the following example:

    edit 13
        set name sip
        set protocol 17
        set port 5060

In this example the next commands would be:

delete 13
end
Step 2) Change the default –voip –alg-mode.

Run the following commands:

config system settings
set default-voip-alg-mode kernel-helper based
end
Step 3) Either clear sessions or reboot to make sure changes take effect

a) To clear sessions

The command to clear sessions applies to ALL sessions unless a filter is applied, and therefore will interrupt traffic.

diagnose system session clear

Taken from

http://kb.fortinet.com/kb/documentLink.do?externalID=FD36405