I've not personally dug into the log locations of the application that aren't presented via the GUI. Nor have I bothered to confirm if 3CX uses fail2ban itself or their own sauce.
My personal take on this: At that point, by the time the log entry says "IP blocked" they've already triggered their 3 strikes and are blocked for a few days. Most nasties are just drive-by harassment, and with the SIP credentials not containing the extension number it's effectively impossible to brute force if you're interrupting them. There are easier targets such as bare-naked Asterisk systems on the Internet, they'll get bored of being banned and move on. I don't even have the emails sent to me when IP is blocked because there's no further action to take so it's just noise.
Food for thought about hardening, aside from the obvious of "securing the box" you need to look at the attack surface you're presenting to the WAN and you'll need to craft a custom solution for this like sending syslog off-machine and doing log parsing. Which might break upon updating the application/OS from the GUI.
You could put an IDS/IPS solution in front of your 3CX instance, but you'd only be able to look for nasties like attacks against SSH (which shouldn't be public anyway), SIP and HTTPS. But it's only going to log things it knows to look for, which would be blocked anyway.
Aside from this being a lot of my own personal takes, I'd need to know what kind of goals you're looking to achieve outside of simply answering "what does it log?"
