Log source IP on failed OPER, SASL, and NickServ IDENTIFY attempts

[johnnyxmas]

Summary

None of the three authentication-failure paths logged anything usable by external tools like fail2ban:

• Failed OPER attempts were logged (category opers), but without any IP or session identifier on the line — a log-watching tool has no way to know who to act on.
• Failed SASL authentication (PLAIN, IRCv3 bearer token, and any future mechanism routed through sendAuthErrorResponse) logged nothing server-side at all — only a client-facing numeric reply.
• Failed NickServ IDENTIFY likewise logged nothing server-side.

This adds "from IP", <address> (OPER) or a session ID + IP (SASL/IDENTIFY, matching the existing successful-login log format in sendSuccessfulAccountAuth/handlers.go:148) to each. No behavior change from the client's perspective — this only adds server-side log detail.

Ran into this concretely trying to set up fail2ban for a small community server: with stock logging there was nothing to filter on for two of the three failure types, and the third had no IP to ban.

Test plan

• go build, go vet ./irc/..., gofmt -l clean
• go test ./irc/... passes
• Deployed to a live production server (patched build of v2.19.0) and verified end-to-end: triggered real failed OPER/SASL/IDENTIFY attempts, confirmed each produces a single log line with the correct source IP, wired up a fail2ban jail against it, triggered an actual ban (6th failed OPER attempt got refused at the network level), and confirmed unban restores access

[slingamn]

These are throttled implicitly through the following mechanisms:

1. ip-limits limits concurrent connections / connection cycling
2. oper-throttle, imposed per connection
3. login-throttling, imposed per connection

but I can see a potential rationale for more aggressive enforcement. However, we may want to be cautious about increasing IP address logging (historically we separated IPs out into a separate log category, connect-ip, so they could be excluded from disk logs).

For opers, I recommend setting a very strong password (e.g. 128 bits of entropy) to render brute force attacks ineffective, but that still leaves user passwords.

[johnnyxmas]

Friendly context: I'm a security professional with 15+ years of experience in the field and understand the Principle of Data Minimization.

This is explicitly requested in order to enable external tooling (fail2ban, IDS, etc) to be able to manage this at a pre-Ergo level, as well as provide CTI telemetry.

IP address is something Opers would be able to see anyway, and cloaking is something even novice users know how to do (by way of oceans of YouTube VPN ads) if they really want this information hidden. Is there some other reason for discarding the information here that I'm not considering? Can you go into the details of the cautiousness around IP logging? Why was it removed?

[slingamn]

I think it's mostly legal reasons --- IRC operators might not want to be subpoenaed for IP addresses or other PII. (In a typical Ergo deployment, chat history is only retained for 1 week, but anything logged to files or the systemd journal will be retained for longer.)

[johnnyxmas]

Easy enough to make optional and off by default?