DEV Community: johnettagaweraks

An Authelia Portal Is Useful Only When Its Access Rules Are Tested

johnettagaweraks — Thu, 29 Oct 2026 23:41:15 +0000

An Authelia Portal Is Useful Only When Its Access Rules Are Tested

Authelia provides authentication and authorization in front of applications through a web portal and forwarded authentication. A portal login page can appear on a public hostname while the applications behind it are protected by separate access-control rules. That makes the portal itself a less useful indicator of exposure than the route policy behind it.

ZoomEye count-only queries on 2026-10-30 returned zero matches for app="Authelia" and 11,776 for title="Authelia" between 06:41 and 06:42 China Standard Time. The title may include documentation, login pages, or reverse-proxy error pages. The result does not show which applications are protected, which users can authenticate, or whether a rule permits an unauthenticated route.

Keep proxy trust inside the identity path

Authelia's forwarded-auth flow checks request metadata and a session cookie. A reverse proxy passes the identity or authorization result to the application. If any client can reach the application directly, or can set the headers normally added by the proxy, the application may accept an unauthenticated request. Strip client-supplied proxy headers at the edge and firewall the application port so only the proxy can reach it.

The access-control rule should specify the domain, path, and policy. A broad bypass rule for health checks or static assets can accidentally cover an administrative path if the path matching is broader than intended. Test exact paths, prefixes, URL-encoded paths, trailing slashes, and case variations. A redirect from an unauthenticated request should not reveal a protected page body before the redirect completes.

Use a policy that matches the operation. A portal that requires a password for one route and a passkey for another should have those rules in the same reviewed configuration. The source documentation describes rules that can require different authentication levels for different resources. Map groups to resources explicitly and avoid a default that permits everything when no rule matches.

Review session and identity-provider revocation

Authelia stores sessions and can act as an identity provider. A user who is removed from a group may retain an existing session until it expires or is revoked. Test group removal and identity-provider logout with a protected application. If the application caches its own authorization result, confirm that the cache has a bounded lifetime or a revocation path.

OIDC bearer-token use is different from a browser cookie. The token must be accepted only where the client and scope were intended. Review token audience, issuer, and lifetime. A bearer token that is accepted by the wrong proxy path can turn a narrow integration into a broad access grant. Do not accept a token merely because its signature is valid.

Passwords and passkeys need recovery rules. A recovery path that bypasses the second factor may be the weakest link. Restrict who can reset an account and require an out-of-band identity check. Record recovery actions, and alert on repeated failures or a reset immediately followed by access to sensitive routes.

Test from the application side

For an owned title match, confirm the portal URL and deployment owner, then test a protected application directly and through the proxy. Send a request with a forged Remote-User, Remote-Groups, or equivalent header. It should fail when it bypasses the proxy. Repeat with a valid session and a removed user. Confirm that the application rejects an expired session even if the portal still renders.

Check the portal domain for an exposed API or configuration endpoint. A login page does not justify exposing the full management interface. Put administrator endpoints on a separate network or require a stronger policy, and review logs for the source address and authenticated identity.

The 11,776 title matches are not a vulnerability count. Authelia's security value comes from the coupling between the identity portal, the trusted proxy, and the application route. Test that coupling with concrete requests instead of treating the presence of a portal as proof that every route is protected.

Query and scope

The standalone SDK used sub_type=all, page 1, and page size 1. app="Authelia" returned zero and title="Authelia" returned 11,776. Collection ran from 2026-10-29 22:41:49 to 22:41:52 UTC.

References

Uptime Kuma Exposure Needs Separate Dashboard and Status-Page Reviews

johnettagaweraks — Thu, 29 Oct 2026 20:20:56 +0000

Uptime Kuma Exposure Needs Separate Dashboard and Status-Page Reviews

Uptime Kuma provides monitoring dashboards, public status pages, and metrics access. Those surfaces have different intended audiences. A status page may be designed to be public, while the administrative dashboard and monitoring API need stronger protection. Counting the product without separating these paths can lead to the wrong exposure decision.

The project's API documentation describes Socket.IO communication after authentication for interactive use. It also documents a Prometheus metrics endpoint whose authentication depends on server settings and API-key configuration [1]. The API-keys documentation says that after the first API key is added, basic authentication is permanently disabled for the protected endpoints [2]. An operator should record which method is active, which endpoints it protects, and whether a public status page shares the same hostname or reverse proxy.

On 2026-10-29 at 19:45 UTC, ZoomEye returned 579,925 matches for app="Uptime Kuma" and 74,489 for title="Uptime Kuma". Both queries used sub_type=all, page 1, and pagesize=1; the matched totals came from the SDK response [3]. The application query is preserved in the search link [4]. The application count is much larger in this observation. That does not prove that 579,925 public dashboards exist. Application fingerprints can cover assets with shared components, and a match does not establish the exposed route, authentication setting, or version.

The separate counts are still useful because they expose a large difference. Start with a bounded validation sample and confirm the response and route. Determine whether the observed service is the dashboard, a status page, a metrics endpoint, or an application page that contains the product name. Record the public hostname and path for each surface. A reverse proxy may expose /status publicly while protecting /dashboard and /metrics, or the opposite.

Inventory should include the dashboard endpoint, status-page slugs, monitor groups, API-key state, metrics exposure, notification integrations, and the database location. Review who can create monitors, read check results, change notification credentials, and export data. Status pages can reveal internal service names, hostnames, and maintenance schedules. That may be intentional for customers, but it is still an information disclosure decision.

A negative test should request the dashboard and metrics endpoint without credentials from an external network. Then request a public status page and confirm that only the intended content is visible. Test basic authentication versus API-key behavior on the metrics route. Submit a revoked key and confirm rejection. Review whether the status page leaks administrative links, monitor notes, or internal addresses.

Protect the administrative dashboard with a restricted network or an authenticated proxy. Require MFA at the identity layer where available. Store notification and integration secrets outside public repositories, rotate them when an administrator leaves, and review webhook destinations. Back up the Uptime Kuma data directory and database carefully because it contains monitor configuration and potentially sensitive notification settings.

Monitor login failures, API-key creation and deletion, monitor changes, notification configuration, and exposure changes at the reverse proxy. A public status page is not an incident by itself. The review should establish which data is visible, who approved that visibility, and whether the dashboard and metrics layer remain protected.

ZoomEye gives the team a broad external measurement and a way to compare changes. It cannot distinguish the dashboard from a public status page. The useful conclusion combines the query with route evidence, authentication testing, and a data-exposure decision for each surface.

References

Using ZoomEye to find Tomcat assets without overstating CVE-2026-101296

johnettagaweraks — Thu, 29 Oct 2026 17:01:07 +0000

Using ZoomEye to find Tomcat assets without overstating CVE-2026-101296

A useful internet search begins with a narrow question. For CVE-2026-101296, that question is not how many vulnerable systems exist worldwide. It is whether an Apache Tomcat deployment is missing from the organization's asset inventory and needs a configuration review.

ZoomEye returned 585,159 matches for app="Apache Tomcat" on October 29, 2026. A separate query for vul.cve="CVE-2026-101296" returned zero. The first number describes a product fingerprint population. The second describes the indexed matches for a CVE field. Neither is a vulnerable-host count.

Why the product query is broad

Apache identifies affected Tomcat ranges across 11.0, 10.1, 9.0, 8.5 and 7.0. A product fingerprint can include fixed releases, unsupported releases and servers that do not use JNDIRealm at all. It can also include multiple services associated with one host.

The vulnerable configuration is more specific: JNDIRealm must be in the authentication path and a non-GSSAPI SASL mechanism must be configured. ZoomEye's product result cannot see that internal configuration. Treating every product match as affected would overstate both the exposure and the required remediation population.

The zero CVE filter has a similar boundary. It means the filter produced no indexed matches at the time of the query. It does not prove that no system is affected or that the CVE is absent from internal inventories. Coverage, indexing and query timing all affect the result.

What the count can support

The product population is useful for discovery. An organization can compare public matches with DNS, cloud accounts, certificate records and application ownership. A Tomcat address without a known owner or deployment record deserves investigation.

The result can also provide a broad baseline before an exercise. If a future measurement finds new public endpoints, the change may reflect new deployments, changed indexing or shifts between addresses. It does not by itself show that those endpoints run a vulnerable version.

Keep the exact dork, asset type, query time and count with the decision. For this round, the Search observation was app="Apache Tomcat", subtype all, status ok, count 585,159. The Filter observation was vul.cve="CVE-2026-101296", subtype all, status ok, count 0.

Build a stronger internal inventory

Start with the service catalog. List every Tomcat runtime, its owner, environment, branch, application and authentication method. Include embedded deployments where a product package or application packages Tomcat inside another server. Those instances may not appear in a host-level package list.

For each deployment, record whether JNDIRealm is used for user credential validation and which SASL mechanism is configured. This is the configuration evidence that converts a broad product asset into a candidate for the vulnerability. Store configuration references rather than passwords.

Reconcile the internal list with external observations. Mark unexplained public addresses for validation. Do not mark an unmatched internal asset as safe because it did not appear in ZoomEye; a non-public service can still be vulnerable and important.

Keep discovery separate from confirmation

An external result can answer whether a service appears to be Apache Tomcat. A wrong-password authentication test answers whether the deployed authentication path rejects invalid credentials. A directory audit log supports that result. These are different evidence levels.

A practical workflow records them in sequence:

External match identifies a possible Tomcat service.
Ownership and DNS data identify the responsible application.
Version inspection confirms the release family.
JNDIRealm configuration review confirms the vulnerable authentication condition.
A negative-password test confirms the fixed behavior.

Only the later steps support a statement that a specific asset was affected or repaired.

Measure progress without inventing a rate

A program can track the number of Tomcat assets with a known owner, the number with a recorded release, the number using JNDIRealm and the number whose wrong-password test passes. Those ratios use an internal denominator that the team can explain.

The public ZoomEye count does not provide that denominator. It also does not say how many matches belong to the organization. Use it to find gaps in discovery and to prompt owner validation.

References

Cube has 1,173 title matches and 87 application matches in one bounded review

johnettagaweraks — Thu, 29 Oct 2026 13:41:31 +0000

Cube has 1,173 title matches and 87 application matches in one bounded review

A semantic layer can look like a database endpoint, an API used by a dashboard, or a product management page. Its product fingerprints reflect those interfaces imperfectly. On 2026-10-28 at 22:48 UTC, a bounded ZoomEye SDK probe used the global all scope, page 1, and page size 1. The query app="Cube" returned 87. The query title="Cube.js" returned 1,173.

The application result is the closer product-specific lead. The title result is broader and may include pages that mention the framework without serving a Cube API. A team should preserve both counts and select the app measurement as its primary discovery query, while recording the title comparison as background. Neither number demonstrates that an API accepts anonymous queries.

Cube's security material describes token-based access and a security context used for data-access decisions. External identity systems can supply claims, and the semantic layer can enforce policy before a query reaches the underlying database. The useful follow-up is therefore to identify the API endpoint, the issuer and audience expected by that deployment, and the database identity used for serving.

Ask whether the matched host is a publicly documented demo, an internal analytics service, or a production application. A demo may intentionally expose sample data. A production endpoint needs a reviewed public boundary even if its model contains no sensitive dimensions. Check token validation, tenant context, row or measure restrictions, cache separation, and database grants as one chain.

Do not run ad hoc SQL against an unowned Cube service to see what happens. An owner can test the intended policy with a controlled tenant and a negative case for another tenant. The evidence should show a rejected request before the database returns data, not a generic error that hides where authorization failed.

The query sizes also suggest a useful ownership strategy. A smaller app list can be assigned first. The larger title list can be kept as a research queue for identifying new product fingerprints or public demos. As fingerprints and responses change, the team can narrow the list rather than treating all 1,173 pages as equivalent.

ZoomEye supplies discovery and prioritization. The security decision depends on tokens, claims, data policies, and the database account behind the semantic layer. The app and title numbers help a team choose where to look, not what conclusion to publish.

References

Linux audit records need a tamper-resistant destination

johnettagaweraks — Thu, 29 Oct 2026 10:20:53 +0000

Linux audit records need a tamper-resistant destination

Linux auditd can record privilege changes, authentication events, process execution, file access, and policy changes. The records are valuable only if an attacker cannot edit the same local log and the operations team can retrieve it after a host is isolated. Remote forwarding is a practical first step, but it is not a complete chain of custody.

Red Hat's audit documentation describes audit events and daemon behavior, while the remote-logging guidance covers sending auditd records to another server. The architectural decision is where to place that server, how to authenticate the sender, and how long to retain the evidence.

Separate collection from custody

The audited host should not be the only place where its evidence lives. An attacker with root access can stop the audit daemon, modify local policy, or remove a log file unless the platform provides additional protections. Forward records to a destination that has independent access control and a different failure domain. Restrict who can alter the receiver's configuration and stored files.

Encrypt transport and authenticate the source. A plaintext UDP path can be lost, forged, or replayed without leaving an obvious mark. Use a mutually authenticated transport supported by the audit forwarding stack, or send through a well-managed log pipeline that adds a source identity. Preserve the original event fields. Parsing them into a normalized store is useful, but the raw record should remain available for investigation.

Keep host clocks synchronized and record the time source. An event with a correct local timestamp is still hard to place if the host clock was wrong. Use authenticated network time for critical systems where possible, and monitor the offset. When receiving events from many hosts, retain both the event time and the receiver's ingestion time.

Plan for policy changes

Audit rules should be managed as configuration and change controlled. Include rules for changes to audit policy, log forwarding, authentication, privilege escalation, and critical data paths. Alert on attempts to stop or reconfigure the audit daemon, and make those alerts fan out to the central receiver.

Test retention and recovery. Define how long records must remain available, how access is audited, and whether the receiver can restore data after corruption. A remote collector with a seven-day retention period may be useful for detection but insufficient for an incident that is discovered after three weeks. Different retention tiers can preserve the raw record longer than the searchable index.

Review the source of time and identity for each event. A local username is not necessarily a human identity, and a process ID can be reused. Correlate audit events with session records, SSH logs, container metadata, and cloud control-plane logs where applicable. The central record is stronger when it can connect what happened on the host to who initiated the session.

The goal is not to make tampering impossible on every host. The goal is to make tampering visible and to keep a copy outside the host's control. That requires transport security, independent receivers, retention, and a tested response path.

References

Reading the Signals in Security

johnettagaweraks — Thu, 29 Oct 2026 09:01:06 +0000

Cybersecurity often starts with small signals: a change in attacker behavior, a newly exposed weakness, or a detail in the way a tool is being used. I research threat intelligence and vulnerabilities to understand what those signals may mean for defenders.

Here, I’ll share research notes, security tooling, and practical lessons from the field, along with occasional deeper dives. I hope these posts help you spot useful patterns and think through ways to strengthen your defenses.