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 without showing its address. 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 would otherwise make the install report its own operator as an attacker.

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.

Successful logins are kept for 180 days, with their address, so that the usual places can be learnt; after that they are deleted.

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.

Your application's own sign-in

The same question is asked of the sign-in endpoints of the services the in-process agent watches: POST requests to a route such as /login, /api/auth/login, /users/sign_in, /oauth/token or /wp-login.php. It needs the caller's source, which only the in-process agent records, so it does not cover a site that only nginx measures. A service behind a proxy must receive X-Real-IP; without it every visitor looks like one local address, and that address is not judged.

Ticket	When	Severity
Password guessing	From one source within 15 minutes: 10 or more refused attempts (400, 401, 403, 422), or 10 or more attempts inside one minute, which is faster than a person types. Or 10 or more sources with 30 refusals, when refusals are most of that route's traffic	Warning; serious from 100 attempts, or when one answer differed and its meaning cannot be told
A sign-in worked after guessing	At least 10 refusals (401, 403, 422) from one source, then a 2xx from the same route, or a redirect to a page that is not a sign-in page	Critical

A 404 or 405 is not a password attempt but a probe. Neither is a body larger than 2 KB, nor an XML body, except on xmlrpc.php. Both are left to the scanning view. The size, the type and a redirect's target are known only when keep request and response headers on server traces is switched on in Settings. Without it they are not held against anybody, and a redirect after refusals counts as an answer that cannot be told. Many applications give the same answer to a right and a wrong password, for example a redirect to /. When the answer cannot say whether an attempt worked, the ticket says so. It is not raised as a break-in on a guess.

The ticket names the service, the endpoint, the number of attempts and how fast they came, the sources' countries, and how often the same sources tried over the last week. Usernames are read from the request samples, when the service is sampled: only fields named like a username (username, email, login and similar) are read, and an email address is shown shortened. Password and other secret fields are not read into the ticket. It also suggests what to do: limit attempts per address, lock or slow an account after repeated failures or add a CAPTCHA, change weak passwords, and turn on two-factor sign-in. When the requests went straight to the application's port, past the web server, it says that too.

One ticket per attacker. Each source has its own ticket; three or more sources at once on one service, or a many-source run on one route, share one. The ticket stays open while the same source keeps coming back within seven days, and its counts grow: attempts, days, first and last seen. It closes after seven days without an attempt, so you hear about one attacker at most once a week, unless it gets worse.

Who is told. Every organisation has a built-in notification rule, Security attacks, under Settings → Notifications → Policies. It sends these tickets from warning up to everybody in the organisation who can see the ticket, and to the organisation's channels, even where a channel's own threshold is critical. The same applies to a sign-in that worked after guessing over SSH or Windows, to an SSH login from a new place, and to a scan that a server answered with something that should not exist. It sends once when the ticket opens, and again only if the ticket becomes critical. SSH and RDP guessing on their own, and scans that were refused, are not included, because on a public machine they happen every hour. Errors and other tickets keep their usual thresholds. An organisation's administrator can turn the rule off.

Where they come from. The Web sign-in door on the Server security page shows these sources on a map and in a table: address, country and region, reverse DNS name, the page they tried, attempts, first and last seen, and the ticket. By default a visitor's address is kept only as a country and a salted hash. A source classified as guessing passwords at a sign-in page is the exception: its address is kept with the ticket for 30 days after its last attempt, so that you can block it. The address of any other request to a sign-in page is held in memory for up to half an hour, for this check only.

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.