SSH logins, Windows logons and scanning

Three security views read the logs the agents already collect. SSH logins come from auth.log or the SSH journal. Windows logons come from the Security event log. Scanning comes from nginx or Apache access logs. Failed attempts and scanners are kept as a salted hash and a country, never as an address. That is enough to follow one scanner through the table, and too little to identify anybody. Successful SSH logins are the exception: they show the address, so that you can recognise your own.

Your own machine is never judged as an attacker. Loopback, private ranges (10.x, 192.168.x, 172.16–31.x) and link-local addresses are left out of all three. A proxy that appears as 127.0.0.1 in its own access log once made a monitoring product report its own operator as a burglar.

SSH logins

Switch on auth.log, or the SSH unit, as a log source. It is always among the Worth switching on suggestions. The page then shows:

• who got in: successful logins over the last 30 days, with address, country, region and reverse DNS name;
• where logins came from, on a map;
• when they happened;
• which accounts were tried.

Your own logins show as signed in, in green, not as an alarm. Only a success after failures is flagged.

A login counts as usual when an earlier login came from the same network. That means the same /24 for IPv4 or /64 for IPv6, or the same provider's dynamic pool within a /16. The first login ever seen becomes the baseline. When the agent first starts, the last eight days of logs are read in as that baseline.

Ticket	When	Severity
Login from a new place	A successful login from a place, country or connection not seen before	Critical, and it says what to do if it was not you
Guessing from one source	One source with 10 or more failures across at least 3 accounts, or 5 non-existent ones, within 10 minutes	Warning, serious from 100 failures
Guessing from many sources	Several guessing sources on one machine, or 15 or more sources with 50 or more failures	Warning
A password worked after guessing	The guessing pattern followed by a success	Critical for a password, serious for a key

The thresholds ask for breadth, not volume. Someone who mistypes their own password four times and then gets in is not an attack. A detector that called it one would be switched off within a day. A key login after guessing is milder, because a key cannot be guessed.

Windows logons

The Windows agent reads Security log events 4625 (failed) and 4624 (succeeded) as structured fields. It works on a Windows in any language. RDP is told apart from other logon types. Every 30 minutes the agent checks that the Security log is readable and that logon auditing is on. The page shows where logons came from, when, and who logged on and how.

The tickets follow the same rules as SSH: guessing from one source, guessing from many, and a logon that succeeded after failures, which is critical. One more ticket covers a single account failing again and again with a wrong password. That is usually a service still using an old password, not an attacker.

Scanning

Anything on the internet is scanned all day for /.env, /.git/config, admin panels and backups. The scanning view reads the collected access logs and answers four questions: where from, when, who, and where it lands (which site and which machine).

A refused probe and an answered one are always kept apart. A thousand 404s for /.env is weather. A 200 means the server handed out something that should not exist. A single-page app answers 200 to everything, because its router runs in the browser. So the size of the answer is compared with what the site serves for its ordinary pages. A probe that got the app's normal page is the shell of the app, not a leak.

• Being scanned: one source asking for at least 8 different probe paths in 12 or more requests within 10 minutes opens a warning.
• Served a secret to a scan: opens a critical ticket only after your install has fetched that path itself and confirmed a secret by its content: a private key, a git config, cloud credentials, an .env file or a database dump. An unconfirmed answer is a serious ticket. Verdicts are re-checked every six hours.

The Problems page keeps scanning tickets apart from the rest, so they do not bury everything else.

The dashboard's own door

Sign-ins to Obscenter itself are recorded separately, in the sign-in book, with a brake on repeated failures and blocks. See The sign-in book.