LayerOne Aegis is where you see the DDoS protection included with every server, and review your servers' network activity and potential security issues. It brings together measured traffic, detected services, open ports, vulnerability information where available, and DDoS activity in your client area.
Aegis's dashboards and alerts are optional: you can hide them in Aegis preferences. LayerOne's underlying security monitoring and included DDoS protection continue when you do so.
Open Aegis
After deploying an instance, sign in to your client area and select Aegis in the main navigation, or open Aegis directly.
- DDoS protection: starts with a status line (how many servers are protected, active attacks, and the last incident), then the traffic rate, packet rate and top services. Choose a server to focus on one, or use All servers. Chart times are Eastern (ET).
- Attack activity: review recorded DDoS incidents for your account.
- Services and ports: review your servers, their public IPs, open ports, detected services, when each was last scanned, and any known vulnerabilities.
- Aegis preferences: choose how you receive attack alerts, and whether Aegis shows in your account.
Firewall groups live under Networking, and both sidebars link to each other.
Observations depend on available sensors and scan results. A newly deployed instance may appear before its first results arrive. Scanning concerns eligible public IPs; it does not provide an inventory of services inside a private network.
Allow the scanner IP to participate
If you want to participate in the vulnerability tracker, allow LayerOne's scanner IP address through the firewalls protecting your instance. The scanner needs to reach the services you want assessed. If a firewall or security tool blocks it, results may be incomplete or unavailable.
- After deploying your instance, check Aegis for the scanner IP information associated with it.
- Use the address explicitly identified as the scanner/source IP. The public IP listed for your instance is the scan destination, not the scanner address.
- Add an inbound rule for that exact source address in your
cloud firewall or attached Firewall Group,
and in the firewall inside your VPS. Permit the TCP or UDP services you want
assessed. For a single IPv4 source, use a
/32when a CIDR is required. - Check any additional security tools that might block the scanner, then review the next available scan results in Aegis.
Cannot find the scanner IP?
Open a support ticket and we will provide the correct scanner IP address to allow. Include your instance name and public IP. Use this option if the address is not visible on the Aegis page after deployment, or if you are unsure which address belongs to the scanner.
Keep your firewall enabled and limit the exception to the confirmed scanner address. Allowing the scanner does not require opening the same services to everyone. Do not use an address copied from an example or an unrelated scan in your logs. LayerOne scanning can appear as connection attempts or port-scan events in your security logs; ask support if you need help identifying them.
How port scanning works
Port scanning checks which TCP and UDP ports respond on your instance's public IPs. A service probe may also identify the application, product, and version behind an open port. This helps you notice an unexpectedly exposed database, administration interface, or other service.
Scheduled port scans run hourly from the host's public network interface. A port's reachability from this location can differ from its reachability from another network, especially when you restrict access by source IP.
An open port means the scanner observed a reachable service. It is not automatically a vulnerability: a public website is expected to expose its web service. If a service is unfamiliar, confirm what is listening inside the VPS and whether it needs public access. Restrict or stop services you do not need.
Service identification is evidence from a probe, not a complete list of installed software. A row labelled only with a port number does not confirm which application is running. Per-port traffic is not measured; application traffic is shown separately.
Vulnerability scanning and the tracker
Vulnerability scanning adds context to the open-port results. Where assessment is available, Aegis uses the identified service and version to surface potential matches to known vulnerabilities from NIST's National Vulnerability Database (NVD). A CVE identifier names a publicly catalogued vulnerability; severity helps you decide what to investigate first.
Treat findings as prompts to review the affected service. A version match does not prove that your particular installation is exploitable: configuration, vendor fixes, and patches backported without changing the advertised version can affect whether a finding applies. An unidentified service may be impossible to assess from the available evidence.
For a finding you need to investigate:
- Confirm the instance, IP, port, service, and observation time.
- Read the vulnerability details and the software vendor's guidance. Check the version and patch status actually installed on your VPS.
- Apply the appropriate update or configuration change. Restrict public access to the affected service if it does not need to be exposed.
- Review fresh scan and assessment results after making changes. Older findings describe older observations and may remain visible until results update.
Aegis does not install patches, change your firewall rules, or remove vulnerable software for you. No findings is not a guarantee that a server is secure, and an open-port scan alone is not a completed vulnerability assessment.
Understand incomplete or old results
Check the observation time and coverage before drawing conclusions:
- Partial or failed port scans: some checks did not complete. A firewall, unavailable service, or unresponsive UDP port can leave reachability unknown.
- Retained or stale ports: an earlier open-port observation can remain after an incomplete attempt. Its original time matters; an omitted port is not proof that it closed.
- Pending, unavailable, or unable-to-assess vulnerability results: the service has not been successfully assessed. These states are not a clean bill of health.
- Missing traffic: gaps mean observations are unavailable, not necessarily that the server had no traffic. The traffic time-window selector does not make an old port scan fresh.
The application view describes observed network traffic rather than every installed application. Its byte totals are not your billed bandwidth usage. An application stays listed for 24 hours after its last observed outbound traffic on the same IP and application port, including replies. New outbound traffic restarts that timer; inbound traffic and port scans do not. Application totals cover the last 24 hours independently of the dashboard's chart range.
Hide or show Aegis
- Open Aegis → Preferences.
- Under Show Aegis in your account, select Hide Aegis dashboards and alerts, then confirm.
This setting applies to every server in your account. Hiding Aegis hides its dashboards, services and ports, and attack activity, pauses DDoS and vulnerability alerts, and cancels any scans you queued. Your saved alert preferences and retained observations are preserved, subject to normal retention.
Disabling Aegis does not stop underlying security monitoring or turn off LayerOne's DDoS protection. The setting controls the customer views and alerts; it is not a request to stop infrastructure scanning.
To return, open Aegis preferences and select Show Aegis again. If you only want fewer DDoS notifications, change the attack alerts on the same page instead. In-app alerts are on by default; email alerts are opt-in. You can also choose which attacks alert you (by severity) and, once email alerts are on, whether to get an email when an attack ends.
How Aegis fits into your security
Use Aegis to spot unfamiliar activity and investigate it. Traffic visibility does not automatically identify or block an intrusion. LayerOne's included L3/L4 DDoS mitigation is a separate layer of protection; you still manage operating-system updates, application security, credentials, and firewall rules.
For missing scanner details, persistent scan failures, or help understanding a finding, open a ticket. Include the instance name, public IP, affected port or CVE if available, and the time and status of the result you are reviewing. Never include your VPS password or API keys.