Review direct logins

A finding groups the direct logins that need one decision. This page covers reading a finding, the answers people give about their own logins, recording a disposition, and keeping expected access from alerting again. For what opens a finding, see External access.

The review queue

External access opens on the Review queue tab. Show switches between Open (the default), Disposed and All, the search box matches the account, the source or the server, and a date range narrows the list. Open findings come first, newest first.

Each row shows Finding, Source, Class, Review, Logins and Last received. A standing entry’s weekly finding is listed by its account and the number of logins and servers that week.

An empty queue means every direct login so far has a decision. It does not mean nobody logged in directly: a server that is not covered reports nothing. Check coverage on the Summary tab.

Read a finding

A finding opens on the same headline as the alert that led to it, followed by its login count and last login, which update as new logins join. The sections below answer the reviewer’s questions in order:

• Was this allowed?: the class and, for an unexpected login, Why nothing matched: no standing entry names the account on this server, none allows it from this source, or the source is a hostname or unknown and so cannot match an entry. A standing entry’s weekly finding shows the entry and the week instead.
• Who was it?: OS account, Account type, Bound to, Member status and Claims.
• Was there a reason to go direct?: whether the server’s Alpamon was disconnected around the login, with the gaps, and who held a work session on the server within an hour of it.
• Is this normal for this account?: how often this account has logged in directly from this source within the new-source window.
• Disposition: the decision, or the one already recorded.
• Technical details, collapsed: Event ID, Service, TTY, PID, PPID, Logged in (host) and Received.

A finding reported late carries Reported late and shows both the time the server reported and the time Alpacon received it.

Removed members

When the account is bound to a member who has since been removed from the workspace, the finding says so, with the removal date when Alpacon has one. It never names the removed member. A claimant or reviewer who has left the workspace is shown as A former member. The finding gives the next step for an old key: Open a Websh session and remove the key or lock the account.

Claims

A claim is a person’s own answer about one login. Reviewers can decide without one, but a claim usually settles who it was.

The “Was this you?” and “Was this your automation?” notifications, and the link in a reviewer alert, open the claim view for that login. It shows only the server, the OS account, the host-reported time and the source. Answering needs no review role.

From the claim view, an Application maintainer or a reviewer can also choose Request standing entry. The request takes the login’s account, server and source.

• Every answer needs a reason, and each person answers once per finding.
• You can replace your That was me or That was my automation with Not me once. You can’t change Not me back.
• After the finding is disposed of, only Not me can still be recorded.
• A claim is Self-reported. It never closes the finding or changes its class. The finding shows each claimant and whether they are the account’s Bound member.

Record a disposition

The reviewer and admin roles record dispositions. Everyone else who can read the finding sees the note A reviewer records the disposition.

1. Open the finding and go to Disposition.
2. Pick a Decision and a Reason.
3. Add a Rationale (required when the reason is Other) and, if there is one, an Incident reference.
4. Click Submit.

When someone answered That was me with an incident reference, the latest one is already filled in.

A recorded disposition can’t be edited or deleted. It keeps the reviewer, the time and the logins it covered, and it deletes no login. Once a finding is disposed of, the next login from the same server, OS account and source opens a new finding.

If new logins, claims or standing-entry requests arrive while you are deciding, the page tells you before it records anything. Check the sections above, click I’ve checked it, and submit again.

A standing entry’s week

A standing entry’s weekly finding can be decided once the week has ended. Until then it shows the note This week’s logins can be reviewed after the week ends.

• Allowed with Entry affirmed: the entry allowed what it should.
• Violation with Entry narrowed: the entry allowed too much. Narrow it in the allowed direct access list.

Either decision also takes Other with a rationale. Not a real finding doesn’t apply to a standing entry’s week.

Dispose of several findings at once

When many findings share one cause, such as the first week’s existing patterns, decide them together:

1. In the review queue, select the findings. A batch holds up to 50 findings of one kind (unexpected logins, or standing entries’ weeks), and unexpected findings must be unexpected for the same reason. A finding that can’t join the selection says why, for example Unexpected for another reason or This week has not ended.
2. Click Dispose of selected, then pick one decision and reason for all of them.
3. Click Review targets. Scroll through the whole list of findings; confirming turns on once you reach its end.
4. Click Confirm batch.

Each finding gets its own disposition and is checked on its own. The result lists each finding’s outcome: a finding that changed after you read it, was disposed of by someone else, or is no longer there is left as it is, and you can open it to decide it separately.

Stop it happening again: standing entries

A standing entry tells Alpacon that a direct login is expected, for example a nightly backup job that connects over SSH. Logins that match an entry alert nobody and are reviewed once a week together.

From a finding, under Stop it happening again:

• Allow as standing entry (security_admin and admin) adds the entry at once, prefilled from the finding. Saving asks for MFA verification.
• Request standing entry (reviewer) sends the entry to the policy owners as a request, prefilled from the finding. A request sends no notification; it waits on Server access policies.

An entry has these fields:

• OS account: the account on the server.
• Applies to: SSH from a network or Console or su.
• Source network, for SSH only: an address or a CIDR range, /8 or narrower for IPv4 and /32 or narrower for IPv6. A single address is /32 for IPv4 or /128 for IPv6.
• Servers: specific servers or one server group.
• Reason: why this access is needed.

An entry has no expiry; it stays until someone removes it. Only a login from an IP address, or a console or su login, can become an entry: a source reported as a hostname, or an SSH login with no source address, can’t be matched by a network.

The allowed direct access list

Standing entries and the requests for them live on Server access policies (Policies → Server access), below the Direct-login detection card:

• Allowed direct access lists each entry with its account, what it applies to, its servers or group, its reason and This week. Policy owners use Add standing entry, Edit standing entry and Remove standing entry. After an entry is removed, the logins it allowed alert as unexpected; its past weekly findings stay.
• Standing-entry requests lists requests from reviewers and Application maintainers. A policy owner chooses Grant or Decline (with a reason). A grant can narrow the request, to a smaller network or fewer servers, but never widen it.

The security_admin and admin roles see Policies → Server access in the sidebar. Reviewers and auditors can read the list and the requests but change nothing. The page isn’t in their sidebar, so they open it from a link to it. Changes need a person signed in to the console with MFA verification. API tokens and service tokens can read the list but can’t change it.

On a server’s page

The server’s page shows the same records where an operator looks for them:

• The Access tab opens with the server’s direct-login coverage. Each OS account below it shows Last direct login and Open findings, and an account bound to a removed member is flagged with the removal date and the next step: Open a Websh session on this server and remove the key or lock the account.
• The Activity tab lists direct logins in the same timeline as work sessions, marked Outside Alpacon. Users with a review role also see each login’s source, class and decision, with a link to its finding. Anyone else who can open the server sees the time and the OS account.

Alpacon doesn’t remove keys or lock accounts on the server for you. Make that change in a Websh session, then record it in the disposition.

Related docs

• External access
• Direct-login coverage
• Summary and evidence