How To Stop Random from-sip-external Attempts

His first trace is NOT from the time conditions polling.
[first was added after original post to clear any confusion with the second trace provided of the time conditions maintenance]

You are correct that those traces you first posted are from an outside attempt trying to get to your server. They have NOTHING to do with the time condition polling. The context that is being hit is from-sip-external which is where anonymous calls are sent and the setting of allow anonymous just controls whether those calls are sent to the ‘from-pstn’ part of the dialplan or wether they are played an ss-no-service message. All of that is configured in the sip settings module. However, if you did tell it to not allow guests, then it should not even be getting to the dialplan. You should confirm that configuration and if necessary, review the auto-generated sip configuration files to make sure the setting is being applied. It could be a bug if not, but first double check.

You should also be turning on the firewall since you have no firewall as it will give significanlty additional protection by throttling those attempts and eventually blocking them.

None the less, check if the guest setting is really applying because if it is not, then you should report a bug.

Thank you for pointing that out, I thought it looked like attacks to me but since my log showed all of the time condition polling I assumed that Daniel was correct. I’ve always had wicked time conditions and never seen this behavior before but I was running an ancient version of FPBX so my V13 naivety was showing through.

I’ll report a bug (I just reported another one on an unrelated issue) on this because guest setting IS applied.

can you go into the file, I think it’s sip_general_additional.conf and put that in the bug report to confirm that the guest setting is setup so we can determine if something isn’t being set there, as that’s what we’ll probably otherwise ask you for when the bug is reviewed.

I have posted the issue already but I’ll update it to include the contents of the file.

As for the firewall, I’ve been reading a bit of hit and miss on that and - frankly - am a bit afraid to turn it on. Aside from that it does mention in the initial screens that if you are already firewalled or cannot put your server in the DMZ that you shouldn’t turn it on. Am I incorrect on this?

In your case you aren’t firewalled. Also, it doesn’t hurt to put the firewall on even if you have another firewall.

There have been some bugs in as far as the firewall is new, we’ve been flushing them out. In your case, since you’re on a hosted system you should have access to the console through some sort of VPS console if I’m not mistaken. That means if you make a mistake, or if we make a mistake (that would never happen :smile: ), then you can get in to the console and turn off iptables to get back in. As it stands right now, since you’re on a hosted system, you don’t have any firewall, unless I missunderstood.

Only my assumption that a publicly available PBX server on a hosted provider is sitting behind SOME kind of firewall :). I’ll turn it on and cross my fingers.

This could be coincidental but after enabling the firewall. the scheduler.php is taking 100% of my CPU (my CPU generally runs about 3-8% on this computer with phone calls active). I turned off the FW and no difference on the CPU utilization.

I killed the process and it has not returned.

I assume this is likely my backup, but it just ran yesterday and is set for monthly so I don’t know why it would try to run again.

scheduler.php is a part of dashboard that runs every couple of minutes to get a snapshot of your system state.

I find it pretty unlikely that it would have anythign to do with firewall. But, I’ve never seen it spin on 100% CPU usage though 8-(

Probably not, like I said it’s likely coincidental, but wanted to make sure I noted it. It was running at 100% for about 5 minutes before I finally killed it and it hasn’t come back to jack my CPU up again so it may have simply been a fluke.

1 Like

Daniel, I appreciate your continued input :). I have not done anything with the polling, obviously I started looking at the other things that p_lindheimer pointed out. Since fixing the issue with the guest access not applying to the configuration file and enabling the firewall I have not received a single from-sip-external log in my entry (about 12 hours now), where I was getting hundreds throughout the day. Of course that could still change as the day progresses but so far it’s looking very clean.

I didn’t want to change the polling of my conditions until I understood if turning that off would have an adverse impact on them, now that I know that it seems the impact is low I’ll try that because it really does clog up my CLI if I’m trying to debug any call issues.


Keep me posted if you will need my help.

Thank you,

Daniel Friedman
Trixton LTD.

This statement is not entirely true :). I’m new to version 13 and this was a new migration to a new PBX hosted provider. I’ve been running FreePBX since version 1 and while I don’t have your experience in it I am not a total neophyte. The one I came from was 2.x because my previous system was Asterisk 1.6 and it couldn’t go much further and after failed attempts at in-place upgrades I decided to go with a FreePBX 13 preconfigured distro. That being said, most of what I do with the system is GUI based with a little bit of “tweaking config files”, so I don’t claim to be an expert by any means but I am capable for most of the day to day stuff.

I think, you missed this (emphasis mine).
Meaning, Philippe meant the very first (less verbose) log dump, probably.
The verbosity of second dump probably prevented any of the Congestion msgs to be caught within the log buffer… see the differences in timestamps (~3 minutes in less-verbose, under 1s in more-verbose).
Nobody’s perfect :wink:



You can trust my judgement that I did not missed anything @el_es. First you need to reduce the log amount and then it is easier to see who is attacking you. You can wink as much as you want, I know that I am right and he is wrong.

Thank you,

Daniel Friedman
Trixton LTD.

Some post have been flagged and removed as “off-topic” from this thread. I think other posts should be as well. This post is not about “your feelings” it is about the users issue. If you have nothing constructive to say related to his issue please move on.


You can go ahead and delete all my posts.

Thank you,

Daniel Friedman
Trixton LTD.

In second dump the OP just did /not/ paste any of the Congestion msgs.
First dump has them every 3 minutes.
The second is a thick soup of events logged across 3 minutes.

(EOT from me).

There appears to have been some heated discussions (and personal attacks) which I believe the Op’s have removed so as to keep this thread to the point. As such though, let me make sure to be clear about a few points that I made and some comments that @danielf has made.

First, concerning the original traces, a sampling follows:

2015-11-17 18:00:16	1447801216.30614	1101	Congestion	s [from-sip-external]	ANSWERED	00:12	
2015-11-17 18:00:00	1447801200.30600	100268	Congestion	s [from-sip-external]	ANSWERED	00:12	

These traces result from an inbound SIP INVITE coming into the PBX that can not be matched up with any of the systems ‘trunks’ and as such, they are delivered to the “from-sip-external” context which is a FreePBX provided context used in conjuction with Allowing/DIsallowing “Anonymous” SIP calls. This is an Asterisk setting that tells Asterisk which context to send calls to if it can’t match it against a configured “trunk.” This can also be changed in the SIP Settings module but is usually not recommended. Also, calls are only sent here IF the PBX is configured to allow “Guests.” The fact that it was coming here meant that either @eagle had not properly set this OR there is a bug and although set in the GUI, “we” were not setting it in Asterisk. (Or … Asterisk wasn’t operating properly, OR something had changed in Asterisk on his version that we had not properly addressed).

In either case, the calls were being directed to the ‘Anonymous’ (from-sip-external) context and from what it appears in the non-detailed trace, anonymous calls were being rejected which, if verbosity had been turned up, you would see an ss-no-service message being played as early media followed by congestion being transmitted in the dialplan.

These calls could be coming from a legiitmate SIP provider as a result of a ‘mis-configured’ trunk. Mis-configured is used in very loose terms here, it simply means that the calls are not originating from the IP address provided in the “host=blah” part of the configuration and thus can’t be matched to a valid SIP “trunk” which would otherwise direct the call to the appropriate context, usually from-pstn or from-trunk. More likely, the calls are probes from scripts out in the internet trying to hack the system. Given the low frequency they are coming in, they could be part of an “early recon” in a staged attack as has been seen as hackers get progressively more sophisticated. (This, as opposed to a brute force barage of many attempts in a short amount of time trying different dial combinations attempting to pass through fraudulent calls.)

Now concerning the time conditions maintenance script, @danielf indicated in an above post:

And I indicated he was wrong. I interpreted his answer stating “It is not an attack” to refer to the original post since I believe that is what this topic is about. If he was implying that the dialplan being generated from the timeconditions maintenace script was not an attack, he is very much correct about that but I interpret his answer very much how I expect @eagle may have interpreted it or anyone else reading this thread.

I agree with @danielf that the maintenance dialplan running every minute can be very distracting especially when debugging and looking through traces, and he is completely correct that there is no harm done in disabling that feature and it is helpful when you spend a lot of time in the CLI looking for issues. (That’s why I put that disabling feature in years ago).

I will clarify what that time condtions maintenance script does so as to define ‘harmless’ for anyone reading this and deciding if you want to do it. Part of the time conditions features is the ability to have a BLF (phone button LED) associated with a particular time condition so that you know the current state of the time condition. Every single call that runs through a time condition will update the state of that BLF based on the current time of day. So for example, let’s assume you “close” at 5:00PM. In the absence of any calls coming in and in the absence of that script, at 5:10PM the BLF will not have changed. If you look over at your phone’s light, it will appear as if you are still “open.” As soon as a call comes in, the timecondition will in fact properly direct the call to the ‘closed’ condition and at that same time, it will light up the LED so that your phone reflects the current state. As such, everything will operate properly, but the LED will show stale information until a call comes through. The maintenance script simply runs through the dialplan of all the time conditions that have BLF state information associated with them (hints) and makes sure that all the hints get updated so that the BLFs are relatively accurate. If you have a large volume of inbound calls coming in through your timeconditions all the time, there is no need for the maintenance script. Or, if you don’t care about the LED showing stale information, you also don’t need it. Bottom line, it has no affect on the proper callflow operation of your system.

Thank you for all the help Phillipe, my issue seems to be resolved and I have a good technique for cleaning up my CLI when I have to debug an issue.

Configure iptables so that it only allows in packets that are related to outbound packets or that are from known, trusted IP addresses.