Feature Request: More security-related info sent to console/logged by the network portal

Brief summary of issue / Description of requested feature:

As mentioned in #1375 , failed login attempts and temporary account lock-outs are not sent to console or logged, nor are connections that never reach the login authentication point.

Reasons for adding feature:

Security in the form of malicious activity detection/documentation, and getting a better idea of who/how many connections never result in any login attempt, failed or otherwise.

Error output / Expected result of feature

Similar to the entry for a successful login: 2417-04-30T06:33:20+0000 [AMPProtocol,0,127.0.0.1] [..] Logged in: Golem(player 17) 8.282.39.12 (1 session(s) total) Perhaps something like: 2417-04-30T06:33:20+0000 [AMPProtocol,0,127.0.0.1] [..] Failed to log in: Golem(player 17) 8.282.39.12 (1 session(s) total) and 2417-04-30T06:33:20+0000 [AMPProtocol,0,127.0.0.1] [..] Connection established with 8.282.39.12 (1 session(s) from that address total)

Finally, something similar for a temporary account lockout on multiple login failures: 2417-04-30T06:33:20+0000 [AMPProtocol,0,127.0.0.1] [..] Locked out: Golem(player 17) 8.282.39.12 (5 failed login attempts total in last 2 minutes)

Extra information, such as Evennia revision/repo/branch, operating system and ideas for how to solve / implement:

master/devel branch as appropriate, though this doesn’t seem like a major change.

<bountysource-plugin>

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource. </bountysource-plugin>

[whitenoiseoss]

This is a feature that should be present, but I would add some additional thoughts:

• Last good login address, last bad login address, number of unsuccessful attempts since last login, timestamp of last unsuccessful login, and timestamp of last successful login should all be database fields to monitor the “current” state. If this is cause for alarm, automated or otherwise, logs should be consulted for a historical account.
• The logs being in CSV is a poor choice. Logs like this should be in a syslog format so they are easily scannable by humans. Syslog is also a very standard format for such information, so there are plenty of libraries in Python and third-party services for parsing things from a Syslog format for automated analysis. These logs could be managed automatically with log rotation.
• Not using a database for historical accounts is for the following reason: Without code to automatically prune said database, this database after running through tests and over years would eventually need to be pruned and this is an administrative overhead that most users of Evennia are not prepared for. It is a reality of production software and services, but that should not be carried over into Evennia due to the difference in community.

As in most things with Evennia, within reason, features should be designed around the lowest level of technical understanding that we could put them at while still being useful. If more advanced users want more advanced behavior, that should be up to them to introduce. For example, with a syslog-formatted log file of security events, one could create a dashboard with Kibana and Logstash and even have automated alerts.

[Griatch]

I think this is implemented. We are still missing a per-account IP store as suggested in #1375.