How to know if someone entered your server without permission?

Published on 2026-10-17 by frfrand

Señales de intrusión en Linux, cambios sospechosos, registros que revisar y qué hacer sin destruir evidencias.

Your website is still running, the domain opens, and no one complained. Does that prove your server is secure? Not necessarily. Some intrusions disrupt everything; others try to go unnoticed.

Knowing if someone entered without permission consists of looking for signs, contrasting them, and determining what happened. There is no single command that guarantees the system was never compromised.

What are the most common signs?

One of the first clues is unrecognized access. For example, an administrative session started from an unexpected location or at a time when no one on the team was working.

Another clue is new users or changed permissions. If an account appears that your team did not create, or an application obtains permissions it did not need, it deserves a review.

Unknown processes consuming CPU, strange outbound connections, new scheduled tasks, files modified without reason, or security alerts from the provider may also appear.

But be careful: each of those signs has legitimate explanations. A CPU spike can be a backup. Access from another IP can be someone using a VPN. What matters is investigating, not assuming.

Where to start on Linux?

If you have a suspicion, the first thing is to avoid impulsive changes. Before restarting or deleting files, gather information about what happened and when.

On a system with proper permissions, you can start with questions like these:

• Who should have administrative access?
• Were users, SSH keys, or scheduled tasks created recently?
• Which applications and processes should be active?
• Are there connections or network destinations that the service does not need?
• Do the logs show repeated authentication failures or unexpected logins?

On Ubuntu, authentication logs may appear in system files or in the journal, depending on the configuration. Tools like journalctl and last can help reconstruct activity, but they are not definitive proof. An attacker with elevated privileges could have manipulated local logs.

A simple example

Imagine a VPS running a website and a database. Suddenly, the processor stays at 100% during the early morning hours and an unknown process appears with a name the team does not recognize.

That does not automatically mean there is an attacker. First, compare the process with recent deployments, scheduled tasks, and installed software. If there is no valid explanation, investigate its origin and connections.

If you also find an unknown SSH key added to a privileged account, the level of suspicion increases significantly. Combined signs are usually more useful than a single anomaly.

What do I do if I think the server is compromised?

The priority is to contain the risk without destroying evidence. Depending on the impact, it may be necessary to isolate the machine from certain accesses, preserve logs, and capture useful information before removing processes.

In a company, the appropriate thing is to activate an incident response plan or seek specialized help. Changing passwords from a possibly compromised machine or restoring without investigating can leave the problem active.

After that, credentials, tokens, service keys, other related systems, and possible leaks must be reviewed. A reliable recovery may require rebuilding the machine from a clean image and restoring verified data, not simply deleting a suspicious file.

How to reduce the possibility of it happening again?

Apply updates, limit privileges and access, use strong authentication, review exposed services, and maintain tested backups. It is also advisable to centralize important logs outside the machine itself so that an intrusion does not easily erase them.

How does it relate to ArduMaker?

Managed VPSs on ArduMaker also run processes, accounts, and services that are worth supervising. The panel can facilitate operations, but it does not replace good practices regarding access, review, and incident response.

In one sentence: to know if someone entered your server, you need to compare actual activity with what should be happening. It is not about looking for a red screen saying "hacked," but about investigating evidence and acting in an orderly manner.

Reference: CISA Ransomware Response Guide.