Aegis — Source library
Public documentation snapshot: 2026-09-08
Catch attacks on your server without locking yourself out.
Host intrusion detection and measured response for one Internet-facing Linux server. Watches by default; blocks only when you say.
Catch attacks on your server without locking yourself out.
Built for: The solo developer or founder who runs one Internet-facing Linux server for a product, store, or client app and has no security team behind them. · The small IT shop or managed-service tech who looks after a handful of client servers one at a time and needs evidence they can hand to the client. · Anyone who has been locked out of their own server by an over-eager blocking tool once and does not intend to let it happen again. · Operators of isolated or air-gapped servers that cannot pull packages from the Internet and must install from a single verified file.
Aegis exists because of this.
You run one server that faces the Internet. Maybe it hosts your product, your store, or a client's app. Every hour, something is knocking: password guesses against your remote-login service, scanners walking your web paths looking for an admin panel or an old plugin, port sweeps from addresses you have never seen. You know you should be watching. You also know that if you install the wrong tool, the first thing it will block is you. That is the real fear with automatic blocking. An aggressive rule fires while you are deploying from a coffee shop, and now the only person with the keys is standing outside. Most tools treat that as an edge case. For someone who runs their own server it is the whole risk: there is no security team to page, no second admin to let you back in, and a provider recovery console you may never have tested. The other extreme is to install nothing and hope the logs are there when you need them. Then something changes on the box, a new listener, a new user, a scheduled job you did not write, and you find out weeks later, if at all. You want to know the moment it happens, with evidence you can read, and you want the option to push back without betting your own access on it.
Aegis exists because of this.
Fails into monitoring, never into a lockout. The shipped state cannot block; five explicit checks and a recorded enable command stand between you and enforcement, and your admin networks are rechecked before every action.
Aegis exists because of this.
Detection and response are separated. Trusted sources stay fully visible in their own bounded evidence lane; they simply cannot accrue a block. Most tools either watch you or ignore you.
Aegis exists because of this.
Every block is scoped, time-limited, capped, and reversible, written only into a dedicated rule set Aegis owns. Your base firewall and other tools' rules are never edited.
Aegis exists because of this.
The server agent carries no third-party runtime code and installs offline, so the release you verified is the release that runs, including on isolated servers.
Aegis exists because of this.
Least privilege by construction: the main agent holds no elevated capability at all, and each of the three helpers that touches the firewall or a sensor holds exactly one narrow permission.
Aegis exists because of this.
Evidence that can be verified later: authenticated source records, chained integrity epochs with exportable receipts, and a tamper-evident forensic journal.
Aegis exists because of this.
The design record says plainly what Aegis is not (not a web application firewall, full endpoint detection, intrusion prevention system, log archive, or traffic-flood shield) and names the open gaps, so you can plan around it instead of discovering the edges in an incident.
How Aegis works, start to finish.
Aegis is a security agent that runs continuously on one Linux server you own. It reads what the server already produces: firewall drop records, remote-login authentication logs, your web server's request log, and a live picture of listeners, users, scheduled jobs, privileged files, and outbound connections. It turns that raw evidence into named, explainable findings. A port sweep, a burst of failed sign-in attempts, a path-traversal probe, a new privileged binary: each becomes a structured event with a severity, a source when there is one, the evidence that triggered it, and what Aegis did or deliberately did not do about it. Out of the box it only watches. Installing it starts nothing. Starting it with the shipped settings cannot block a single address. Before Aegis is allowed to act you must pass five separate checks: turn enforcement on, type an exact confirmation phrase, confirm you have verified your own admin access, list the networks you administer from, and name your management port. Miss any one and it stays in monitor mode. Even after that, the addresses you listed are checked again before every single block, and the rules Aegis writes live in their own isolated rule set that it alone owns. It never edits your base firewall, your provider firewall, or anything another tool set up. When you do let it act, the response is measured. First blocks are short. Repeat offenders get longer ones, up to a ceiling you set, and repeat history decays over time. Every block expires on its own and is lifted automatically. There is a cap on how many blocks can be active and how many actions can happen per minute, with a reserved slice held back for confirmed critical threats so ordinary noise can never crowd out a real emergency. If anything looks wrong, one confirmed command removes every rule Aegis wrote and nothing else, and a plain stop file does the same if the command line is unavailable. Previous releases stay on disk so you can roll back. Everything Aegis learns is kept as durable, bounded history on the server and shown in a read-only dashboard reachable only from the machine itself or through the remote session you already trust. Alerts go to your logs, an optional webhook, or email, with duplicates collapsed so a noisy night does not become a thousand messages. Local structured logging is mandatory and cannot be switched off. Trusted sources you list are still observed and still generate evidence; they just can never be blocked, so you keep visibility into your own automation without giving it a free pass. Optional layers go further when you are ready, each shipped switched off: authenticated source records that stop a forged forwarded-address header from misdirecting a block, chained integrity baselines that let you prove your server's critical-file state was not quietly rewound, bounded packet and system-call sensors, a certificate-checked access door for administrators whose address changes, and privacy-safe correlation between several of your own servers. The server agent installs offline from a single verified release, pulls nothing from the Internet, and carries no third-party runtime code of its own, which is why it also works on isolated servers. It runs as an unprivileged process; the three small helpers that touch the firewall or the optional sensors each hold exactly one narrow permission and nothing more. A separate read-only Android companion lets the owner check status and the active-block list from a phone over a pinned, direct connection to their own server, with no relay through us. Aegis runs today on our own Internet-facing server in monitor-only mode, which is exactly the posture we recommend you start with.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
Watches first. Blocks only when you say.
Installing Aegis starts nothing, and the shipped settings cannot block anyone. Five separate checks must all be true before it may act: enforcement on, an exact confirmation phrase, a statement that you verified your own access, your admin networks listed, and your management port named. Turning it on is a deliberate, recorded command, not a settings edit that takes effect by accident. Start with one category set to block and leave the rest on alert-only.
It will not automatically ban an admin network you listed.
The networks you list as your own are protected at four independent points: the response policy, the rule renderer, the privileged helper that actually applies a change, and the order of the rules themselves, where your networks are matched before any block set. Aegis rechecks that list before every action and refuses outright to build an enforcement table with an empty admin list. Your traffic is still watched and still produces evidence, so a compromised admin laptop does not get a free pass; it simply cannot trigger an automatic block against you.
Sees scans, floods, and slow probing.
Aegis spots vertical port scans, horizontal sweeps across hosts, long-window low-and-slow scans, hits on ports you do not serve, abnormal per-source connection rates, and half-open connection floods, using your firewall's drop records and a sample of live sockets. Findings carry the counts and windows that triggered them, so you can tune thresholds against your real traffic instead of guessing.
Sign-in brute force without the false alarms.
Bursts and steady streams of failed or invalid-user remote logins are detected from your authentication log. Ordinary connection-closed and disconnect noise that happens before authentication is explicitly excluded, so an alert means someone is actually guessing rather than a client hanging up. When enforcement is on, a guessing source is blocked for a bounded time and released automatically.
Web and application probes, named and explained.
From your web server's request log Aegis recognizes path traversal, SQL and NoSQL injection attempts, cross-site scripting probes, admin and sensitive-path guessing, known scanner signatures, GraphQL reconnaissance, cloud-metadata targeting, error and rate bursts, and requests that decode differently at different layers. Findings never store the raw request, path, query, or token, and encoding-difference findings are alert-only by design so an unusual client cannot get itself banned.
Knows when something changed on the box.
New listening ports, new local users, new or altered scheduled jobs, new or changed privileged files, hash changes to the critical files you name, and outbound connections to destinations outside your expected set each raise a finding. A separate critical alert fires if anything on the host reaches a cloud-credential metadata endpoint. This host-change layer is on by default and is the after-the-breach visibility most single-server setups do not have.
Measured, reversible response.
First blocks are short; repeats escalate through fixed stages to a ceiling you choose, and repeat history decays over time. Every block expires on its own. Hard caps limit how many blocks can be active and how many actions can happen per minute, with a reserved slice that only confirmed critical findings or you, the operator, can use. Blocks are written only into a dedicated rule set Aegis owns, so your base firewall and any other tool's rules are never touched.
One command undoes everything.
A single command with its own exact confirmation phrase removes every rule Aegis wrote and nothing else, and holds new blocks off until you explicitly re-enable them. If the command line is unavailable, creating one stop file does the same and survives until reboot on purpose. Earlier releases stay on disk and a pre-upgrade backup is taken before each install, so rolling back is a documented procedure rather than an emergency improvisation.
Evidence you can read, alerts you can live with.
Every finding is a structured event with an ID, time, severity, category, exact source where one applies, bounded evidence, and the action or skip reason. Duplicates within a window are counted, not repeated, and a summary tells you what was suppressed. Structured local logging is mandatory and cannot be disabled; a webhook and email are optional additions. A sink going down never stops collection and never changes what Aegis will do.
A forged forwarded-address header cannot misdirect a block.
Behind a proxy or content-delivery network, the address in a plain log may be the proxy, a header value, or text someone altered. Aegis's optional authenticated source record binds the real connection peer and any proxy-reported client to the service that saw them, with freshness and sequence checks. Only a directly observed source can be blocked; a proxy-reported client stays evidence-only, so you neither ban your own delivery network nor a spoofed innocent. It ships switched off.
Prove your baseline was not rewound.
When you enable integrity baselines, nothing is trusted automatically, not even a first scan or an upgrade. You review a bounded candidate, create a short-lived plan bound to that exact candidate, and commit that plan before a new chained epoch is accepted. Receipts can be exported and kept elsewhere; later verification against a surviving receipt detects if the local record was rolled back. This ships disabled and unenrolled.
Deeper sensors, only if you turn them on.
Bounded packet metadata on one interface and system-call behavior (execution bursts, reverse-shell patterns, cross-process injection, privilege changes) are available as opt-in sensors, both shipped off. Each runs in its own helper holding exactly one narrow permission, keeps only capped in-memory state, never stores raw packets or a full syscall transcript, and cannot grant the main process any new power if it fails.
Get in from anywhere without opening the door to everyone.
Access Gate gives an administrator whose address changes a short, exact-port lease to reach the management port after a direct certificate check. The lease renews while you work and expires on its own. It does not replace your existing key-based login, is deliberately not allowed to sit behind a proxy, and ships disabled with the service stopped, no listener open, and no certificate issued until you stage it yourself.
Installs offline. Nothing to download, nothing to trust but the release.
The server agent is one verified release file with an installer that refuses to start any service, and it carries no third-party runtime code of its own. Releases are immutable and named by their content hash, and the installer checks your kernel and firewall support before touching anything. Isolated and air-gapped servers are a first-class case, not an afterthought.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Surfaces and status.
Status as of 2026-09-02. Release 3.7.0 is complete, built from exact source bytes, hashed, and running on ASL's own Internet-facing server since 2026-08-13 in monitor-only mode, reconciled against source and backups on 2026-08-18 per. Release artifacts, an offline installer, and full operator documentation exist. What does not exist is any external user: there is no public download page, no published pricing, no self-serve signup, and the repository records no customer install. The blocking path has never been exercised on a production host, and the read-only dashboard is reachable only from the machine itself. The Android companion 1.0.1 was accepted on two devices on 2026-08-23 but sits on a private internal Google Play track with one tester, its store listing saved as a draft, and external review blocked because there is no reviewer-accessible server. On the dated evidence this is an internal product that is ready to be installed for a first customer, not one customers are using today.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with Aegis.
ASL Scan
Scan finds the weaknesses on your server and web app before an attacker does; Aegis watches the server afterwards and tells you when someone is probing exactly those paths. The two are built to be read together: Aegis's scanner-signature detector already recognizes Scan's own audit and hypothesis-scanner identifiers in your logs alongside the common public scanners.
Network Sentinel
Sentinel watches the devices inside your home or office network; Aegis watches the one server you expose to the Internet. Together they cover both sides of the line.
Recent progress.
This product ships often. The most recent verified changes, newest first.
Recent progress.
2026-08-13 three ordered hardening releases (3.5.0, 3.6.0, 3.7.0) were installed on ASL's own server in one guarded sequence, each with a root-only pre-upgrade backup; 3.7.0 adds anchored integrity baselines with chained epochs, exportable receipts, and rollback detection.
Recent progress.
2026-08-18 the release record was reconciled against the source repository, three release mirrors, and the live host, and the server's operations documentation was brought under version control.
Recent progress.
2026-08-22 a native Android owner companion was built and accepted with live read-only status and active-block calls.
Recent progress.
2026-08-23 Android 1.0.1 was signed, accepted on two devices, and placed on a private internal distribution track; that is the most recent change in the repository. Nothing has landed since, and the posture on our own server remains monitor-only with enforcement, Access Gate, and integrity enrollment all deliberately off.
Recent progress.
Pricing for Aegis is quoted after a short conversation about your situation, because the right scope differs from one team to the next. There is no charge for that conversation.
Will it lock me out of my own server?
That is the one outcome Aegis is built to prevent. It ships unable to block anything. To let it act you must turn enforcement on, type an exact confirmation phrase, state that you verified your own access, list the networks you administer from, and name your management port; miss any one and it stays in monitor mode. Once on, your listed networks are rechecked before every block at four independent points, and Aegis refuses to build an enforcement table at all if that list is empty. Blocks expire on their own, and one confirmed command removes every rule Aegis wrote. Two honest caveats: the protection covers the networks you actually listed, in both address families, and we have not yet exercised the blocking path on a production host. Keep your provider console open the first time you enable it.
We already have fail2ban and a provider firewall. Why add this?
Keep them. Aegis never edits your base firewall, your provider firewall, or another tool's rules, and it coexists with what you run. What it adds is the layer those tools do not have: correlation across firewall drops, sign-in logs, your web logs, and the host itself (new listeners, users, scheduled jobs, privileged files, outbound connections), plus explainable evidence, capped and reversible responses, and a refusal to block the admin networks you listed. If your current tool has ever banned you, that last part alone is the reason people look at this.
What does it cost?
Pricing is not published. Aegis is an internal product today: the release is complete and runs on our own server, but there is no public download, no signup, and no price list, and we have not yet installed it for an outside customer. If it fits what you run, talk to us and we will scope a first install and quote it for your server count, including whether you want us to do the setup and first tuning pass.
Is it actually ready, or is this a science project?
The 3.7.0 release passed 639 automated tests with zero failures and 13 expected platform skips, was built from exact source bytes, and has been running on our own Internet-facing server since 2026-08-13 with a verified backup taken before install. Six ordered hardening releases each carry their own threat model, migration, and rollback record. What is not done, and we would rather say it than have you find out: no outside customer has installed it, the blocking path has never run in production because we keep our own server monitor-only, there is no public download or published pricing, and five containment gaps are listed openly on this page. It is finished software with no user base yet.
Does any of my data leave my server?
No. Aegis runs entirely on your machine, installs offline, and phones home to no one. Findings stay in bounded history on the server; alerts go only to the webhook or email address you configure. The one feature that can make an outbound request is the optional reputation-feed refresh, which is off by default and only contacts sources you name and pin yourself. The optional Android companion connects straight from your phone to your server with a pinned host key and does not relay through us. Even the optional cross-server correlation exchanges only bounded summaries between servers you own, never raw source addresses.
What happens if we stop using it?
You run the uninstaller, which removes only what Aegis installed and only Aegis's own firewall rules; your base firewall is untouched because Aegis never edited it. Your history and configuration are preserved by default and removed only if you explicitly ask for both purge flags, so the evidence you collected remains yours. There is no subscription lock, no external service that goes dark, and no dependency your server was pulling from us.
How hard is the install and what does migration look like?
There is nothing to migrate from; Aegis sits beside what you already run. Install is a single verified release file and an offline installer that starts nothing. You then fill in one documented settings file (your management port, your admin networks in both address families, the listeners and users you expect), start it in monitor mode, and watch it through a normal week of deployments, backups, and customer traffic before deciding what, if anything, to let it block. We can do that first pass with you, and given how new this is for outside servers, we would want to.
Can I check on it from my phone?
Yes, with the read-only Android companion. It connects directly from your phone to your server with a pinned host key using a key you import; the profile and key are stored encrypted on the device and nothing is sent to us. It runs exactly two read-only commands and deliberately has no block, unblock, reload, or configuration action. It is on a private internal distribution track for owners we work with, with its store listing unpublished, so it is not something you can download today.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
What should I know before I rely on it?
Runs on one Debian- or Ubuntu-family Linux server per install with a modern kernel; it is not for Windows servers, shared hosting, or containers as such (it sees the host, not container namespaces).
What should I know before I rely on it?
Ships monitor-only on purpose. Blocking requires you to pass five checks and run a deliberate enable command; expect to spend time in monitor mode tuning thresholds against your real traffic first.
What should I know before I rely on it?
We have not exercised the blocking path on a production host. Our own server has run monitor-only since install with the emergency stop in place and zero automatic responses issued, so enforcement is backed by automated tests and design review rather than by production use. Your first enable will be genuinely first.
What should I know before I rely on it?
It is not a web application firewall, full endpoint detection product, general intrusion prevention system, malware or vulnerability scanner, log archive, or traffic-flood shield. It acts after traffic has arrived and cannot recover a saturated link.
What should I know before I rely on it?
It cannot see inside encrypted traffic or request bodies; web findings come from what your web server logs. A finding means an attempt was observed, not that an exploit succeeded.
What should I know before I rely on it?
Web-layer detection expects the standard combined request-log format produced by the reference reverse proxy. A different web server or a customized log format needs its own parser before those findings work.
What should I know before I rely on it?
Protection against banning yourself covers exactly the networks you list, and each address family separately: an admin list with only IPv4 entries will not protect an IPv6 management path. List both.
What should I know before I rely on it?
A hostile administrator-level user or compromised kernel can disable or forge an on-host agent. Against that threat you still need remote log shipping and an independent recovery console.
What should I know before I rely on it?
Our own evaluation against our own attack-simulation catalog is a self-run review, not an outside audit, and no live target was scanned. It names five open containment gaps: preventing a destructive write before it commits, in-line availability mitigation, tracing a callback to its originating request and process, evicting planted persistence within a window, and terminating a session-like beacon.
What should I know before I rely on it?
Behind a proxy, delivery network, or carrier address translation many users share one address; conservative response settings and correct trusted-proxy configuration are on you.
Catch attacks on your server without locking yourself out.
Prefer email? contact@autosecurelogin.com