Seeing calls in CDR that do not appear in /var/log/asterisk/full*

[f1systems (United States)]

I have call ids that I cannot grep from full* logs. There are numerous of these calls and none of the call IDs come up when grepping them from full*

[lgaetz (Lorne Gaetz)]

Possibly this issue

Bug in Asterisk Logfiles Module ver 15.0.4

Last week a security update was published for the Asterisk Logfiles module to resolve a cross site scripting vulnerability, version 15.0.4. Many (perhaps most) systems would have received the update and installed it automatically in the early morning of August 19. In addition to the XSS fix, there were improvements in logfiles browsing as well as updates on the way the logfiles are managed. Version 15.0.4 has a new bug that changed the default settings for the full log and console such that log…

[f1systems (United States)]

I don’t see where that applies though I made sure all updates were installed. I see a completed call in the CDR from 30 minutes ago and the only message in the log is “No headers had been previously added to this session.”

[f1systems (United States)]

I have resolved my problem though did not “fix” the issue. I did not find anything in the knowledge base or forums regarding this and would still like an answer.

[Stewart1 (Stewart)]

@f1systems

… and the only message in the log is …

Your posts are very vague. Do you mean that’s the only message in the log file for the past 30 minutes? Or that’s the only message with a particular call ID? Or, something else?

Do calls between extensions get properly logged? Outgoing calls? Incoming calls?

[f1systems (United States)]

Sorry, the later. This is the only item in the log with the Call ID. And there are many calls but no log entries. Some of the calls are answered but all are very short connects. All are to one area code in Iowa.

[Stewart1 (Stewart)]

These are likely fraudulent calls to high cost (rural) providers where the attacker gets a piece of the action. Look up the area code / exchange at
https://www.telcodata.us/search-area-code-exchange-detail

Possibly, the calls were made via an unsecured transfer mechanism and not logged correctly due to a bug. Look at the complete log, from one minute before through one minute after a problematic call. Also, search the log for the problematic numbers.

Or, your system was hacked into and SIP credentials were stolen. The CDR should show the extension the call was made from. Search the log for registrations of that extension.

[TheWebMachine]

I think we identified an issue where running fwconsole ma downloadinstall logfiles --edge was potentially insufficient to fix the logging issue; it’s possible the reversion of the bug only exists in a single version of the logfiles module (and it has since transitioned from edge to standard repo). Try running this, instead, to get logs working correctly again:

fwconsole ma downloadinstall --tag 15.0.7 logfiles
fwconsole restart (had a couple systems still not logging after just a reload, but restart got it going)

@Stewart1 is likely right about the source of the calls, however…moreso along the lines of “unsecured transfer mechanism” than “SIP credentials were stolen.” These types of attempts against internet accessible PBXes happen ALL the time. Asterisk and fail2ban do a pretty good job of blocking them from getting in.