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.
), 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.