Hi,
You can go ahead and delete all my posts.
Thank you,
Daniel Friedman
Trixton LTD.
Hi,
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.