ServerGuard Security — a ServerGuard security module designed for automatic detection and restriction of mass attempts to guess credentials over SSH.
The module runs directly on the Linux server and operates in the background. Management and configuration are performed through ServerGuard.
The main task of Security:
to detect a suspicious series of failed SSH authentication attempts and automatically restrict the source of such attempts.
1. What ServerGuard Security protects against
SSH is one of the main methods of remote administration of Linux servers.
If a server is accessible from the Internet, attackers can automatically send a large number of login attempts, for example:
username: root
password: 123456
username: admin
password: password
username: ubuntu
password: qwerty
...Such attacks are called brute-force attacks.
ServerGuard Security is designed for automatic detection of such attempts.
Instead of the administrator manually reviewing SSH logs, the system constantly analyzes authentication events and responds to suspicious activity.
2. How protection works
Simplified diagram:
SSH
|
v
Authentication
|
v
System security logs
|
v
ServerGuard Security
|
v
Analysis of login attempts
|
v
Source identification
|
v
Rule check
|
v
Counting failed
attempts
|
v
Threshold exceeded?
/ \
NO YES
| |
v v
Continue Restrict
sourceThus, ServerGuard does not try to block every user after the first mistake.
The system is designed specifically to detect series of suspicious attempts.
3. Why a single incorrect attempt is not considered an attack
An ordinary user may make a mistake when entering a password.
For example:
Attempt 1 → error
Attempt 2 → error
Attempt 3 → successful loginThe mere fact that several errors exist does not yet mean that the server is under attack.
Therefore Security uses a configurable threshold.
For example, if the administrator has set:
5 failed attemptsthe system may consider reaching this number as grounds for automatically restricting the source.
The specific values depend on the server configuration.
4. Attack source control
Security associates failed authorization attempts with the connection source.
This allows different addresses to be handled independently.
For example:
IP A → 2 failed attempts
IP B → 1 failed attempt
IP C → 5 failed attemptsWhen the configured threshold is reached, the action is applied to the corresponding source.
This avoids blocking the entire server because of the activity of a single address.
5. Automatic blocking
After the configured threshold is reached, ServerGuard can pass the information to the Linux firewall mechanism.
As a result, the attack source receives a restriction on further connections.
Simplified:
Suspicious activity
|
v
Threshold reached
|
v
Firewall
|
v
Source blockedThus, ServerGuard does not merely notify the administrator:
«The server is receiving many login attempts».
It can automatically apply a protective action.
6. Temporary and permanent blocking
Depending on the administrator's configuration, blocking may have a different nature.
Temporary blocking
The source is restricted for a certain period.
After the period ends, the restriction may be lifted automatically.
Diagram:
Attack
↓
Detection
↓
Blocking
↓
Waiting
↓
UnblockingPermanent blocking
The source remains blocked until the administrator or the system performs the corresponding action.
The choice of mode depends on the server's security policy.
7. Whitelist
ServerGuard supports a list of trusted sources.
The administrator can specify addresses that should not be subject to automatic blocking.
This may be useful for:
- administrative networks;
- trusted servers;
- monitoring systems;
- automated services;
- other known connection sources.
When configuring the whitelist, the addresses being added must be carefully verified.
If an unwanted source is accidentally added to the trusted list, the automatic protection will not be able to apply the usual blocking rule to it.
8. Operation in the background
Security does not require ServerGuard to be constantly open on the user's computer.
After installation, the protective component runs directly on the Linux server as a system background process.
This means:
Windows ServerGuard
|
| management
v
Linux Server
|
v
Security
|
v
runs independentlyThe Windows application is used to manage the module, view its status, and perform administrative operations.
The attack detection mechanism itself runs on the server.
9. Operation after server reboot
Security integrates with the Linux system manager.
This allows the protective component to be started automatically after a server reboot.
General process:
Linux Server Restart
|
v
System initialization
|
v
ServerGuard Security
|
v
Protection activeTherefore the administrator does not need to manually start the protective script after every reboot.
10. What happens during an attack
Let us consider a hypothetical example.
Suppose a single source begins sending a large number of failed SSH authentication attempts.
The system detects events:
Failed attempt
↓
Failed attempt
↓
Failed attempt
↓
...Security tracks the number of such events.
After the configured threshold is reached:
Threshold reached
↓
Security action
↓
Firewall restrictionFurther connections from this source are restricted by firewall means.
11. What the administrator gets
ServerGuard allows the administrator to monitor the state of the protective mechanism.
Depending on the ServerGuard version, the following may be available:
- Security status;
- system service status;
- information about events;
- protection settings;
- list of blocked addresses;
- statistics;
- blocking management;
- updating the protective component.
This allows basic operations to be performed through ServerGuard instead of manually managing individual Linux commands.
12. Security architecture
Separation of responsibilities is used inside ServerGuard.
In simplified form, the architecture looks like this:
SERVERGUARD
|
v
Windows Application
|
SSH management
|
v
Linux Server
|
+-----------+-----------+
| |
v v
Security System Service
| |
+-----------+-----------+
|
v
Security Engine
|
v
SSH Authentication
Events
|
v
Event Analysis
|
v
Attempt Tracking
|
v
Security Decision
|
v
FirewallThis separation allows the management interface to be decoupled from the protection mechanism running directly on the server.
13. Why protection runs on Linux and not only in Windows
ServerGuard is a tool for managing Linux servers.
Therefore attack detection is performed directly on the protected server.
This has an important advantage:
User's Windows computer
|
| may be turned off
|
XAt the same time:
Linux Server
|
v
Security
|
v
keeps runningThat is, the operation of the protective mechanism should not depend on whether the Windows client is currently open.
14. Protection is multi-layered
Security is only one of the components of ServerGuard.
The overall system can combine several independent mechanisms:
ServerGuard
|
+-----------------+-----------------+
| | |
v v v
SSH Security File Integrity SSH Keys
| | |
v v v
Brute-force FileGuard Key Guard
protection
|
v
FirewallThis means that ServerGuard should not be viewed as a single mechanism that tries to solve all security problems.
Each component performs its own task.
15. Security is not an antivirus
It is important to correctly understand the purpose of the module.
Security is intended primarily to protect SSH from automated attempts to guess access.
It is not:
- a full-fledged antivirus;
- a universal malware scanner;
- a full-fledged SIEM;
- a complete IDS/IPS system;
- a system for analyzing all network traffic;
- a replacement for a firewall;
- a replacement for backups;
- a replacement for a system administrator.
Security solves a more specific task:
detection of suspicious activity during SSH authentication and automatic restriction of the source.
16. What Security cannot guarantee
No brute-force protection system should be regarded as an absolute guarantee of security.
For example, Security does not automatically solve the following problems:
- a stolen password;
- a stolen SSH key;
- a vulnerability in the SSH server itself;
- a vulnerable web application;
- malicious software;
- compromise of an account;
- a vulnerability in the operating system;
- configuration errors;
- social engineering.
Therefore Security is one of the layers of protection, not the only protection for the server.
17. Why ServerGuard uses several mechanisms
Server security cannot be built around a single rule.
For example:
SSH protection
+
Firewall
+
SSH hardening
+
SSH Key monitoring
+
File integrity monitoring
+
Security monitoringprovide more comprehensive control.
If one technology is responsible for detecting a certain type of event, another can be responsible for limiting the consequences.
That is why ServerGuard consists of separate specialized modules.
18. What happens to the data
Security uses service data to store information about its operation.
This data may be used for:
- the current protection status;
- counters;
- statistics;
- event history;
- information about blocks;
- module settings.
The operational data is located on the Linux server.
This allows the protective component to continue operating independently of the Windows interface.
19. Updating Security
ServerGuard supports updating the protective component.
During an update, the system must first prepare the new version, perform the necessary checks, and only then replace the working component.
Backup of the previous version is also provided for.
General principle:
Current version
|
+----> Backup
|
v
New version
|
v
Check
|
v
Installation
|
v
Restart of protection
|
v
Status checkThis approach reduces the likelihood that a corrupted or incorrect file will immediately replace the working component.
20. Automatic recovery of operation
The protective component is started as a Linux system service.
The system manager can monitor the process state and restart it after an unexpected termination, if this is provided for by the server configuration.
This increases the resilience of the protection to individual process failures.
21. Security of ServerGuard itself
ServerGuard uses elevated system privileges to perform some protective operations.
This is necessary because managing the system firewall and some system services requires administrative privileges.
Therefore it is important:
- to use ServerGuard only on servers you manage;
- to protect administrator credentials;
- to use strong authentication;
- not to give server access to unknown users;
- to update the operating system regularly;
- to monitor installed components.
ServerGuard is an administration and security tool, so it must be used with the appropriate administrative rights and responsibility.
22. Can an attacker bypass the protection by knowing how it works?
Knowledge of the system's operating principle should not by itself be considered a mechanism on which security depends.
ServerGuard should not count on the attacker:
«does not know that Security is installed on the server».
For example, a user may know that ServerGuard monitors SSH authentication.
This does not negate the mechanism itself:
The attacker knows about the protection
|
v
Tries to attack SSH
|
v
Security receives the event
|
v
Analysis
|
v
Protective actionTherefore ServerGuard's public documentation can openly explain the purpose and operating principle of the modules.
At the same time, internal implementation details that the user does not need do not have to be published.
23. What the user should know
It is important for the user to understand:
ServerGuard Security:
- monitors SSH authentication;
- detects a large number of failed attempts;
- associates events with connection sources;
- takes configured exceptions into account;
- can automatically apply a firewall block;
- supports various blocking modes;
- runs on the Linux server itself;
- starts as a system component;
- can operate independently of an open Windows client;
- is part of ServerGuard's multi-layered protection.
24. What does not have to be disclosed in user documentation
The internal implementation of ServerGuard contains additional technical details.
They are intended primarily for developers and administrators.
These include:
- internal application file paths;
- names of update temporary files;
- source code structure;
- internal Python functions;
- structure of internal JSON objects;
- sequence of internal calls;
- parser implementation details;
- internal process management mechanisms;
- internal APIs;
- service variables;
- update implementation details;
- specific internal operating system commands.
Such information may be located in a separate Developer Documentation.
25. User and developer documentation
It is advisable to divide ServerGuard into two levels of documentation.
Public Documentation
For users:
What it protects against
How it works
Which events are detected
What a block means
How to manage protection
What limitations existDeveloper Documentation
For developers:
Source code
Architecture
Python modules
C++ modules
systemd
file structure
data formats
API
updates
internal algorithms
diagnosticsThis approach makes it possible to be transparent with users while not overloading them with internal implementation details.
26. Relationship with other ServerGuard modules
Security does not exist in isolation.
In the ServerGuard ecosystem, other components can perform additional tasks.
For example:
SERVERGUARD
|
+--------------+--------------+
| | |
v v v
Security FileGuard SSH Key Guard
| | |
v v v
SSH attacks File changes Key changes
| | |
+--------------+--------------+
|
v
Security EventsEach module specializes in its own category of events.
27. Example for an ordinary user
Let us imagine that the server is on the Internet.
An unknown source begins sending a large number of SSH requests.
Without automated protection, the administrator would have to monitor the log themselves and decide on blocking.
With ServerGuard, the process is automated:
Login attempts
↓
Activity detection
↓
Counting
↓
Rule triggered
↓
Firewall restriction
↓
Source restrictedAt the same time, the administrator can continue working with the server through an allowed source.
28. Why ServerGuard does not simply block SSH entirely
Completely disabling SSH is not always possible.
SSH is used by administrators for:
- remote management;
- server maintenance;
- software updates;
- diagnostics;
- backup administration.
Therefore the task of Security is not simply to disable SSH.
The task is to preserve the ability to administer while automatically responding to suspicious activity.
29. Recommendations for safe use
To improve the overall security of the server, it is recommended to use Security together with other protection tools.
In particular:
- use strong passwords;
- use SSH keys where possible;
- disable unnecessary authentication methods;
- update Linux regularly;
- restrict administrative access;
- use a firewall;
- monitor SSH configuration;
- monitor SSH keys;
- use FileGuard or other integrity monitoring tools;
- regularly review security logs;
- create backups of important data.
ServerGuard is designed to combine some of these tasks in a single management system.
30. Limitations
Security is specifically oriented toward SSH brute-force.
Therefore it cannot be regarded as protection against all possible attacks.
For example, if an attacker has already obtained valid credentials, the mere presence of brute-force protection does not mean that their access will automatically be blocked.
For this reason, server security must be built on several layers.
31. The main idea of ServerGuard Security
In brief:
SSH
|
v
Authentication
|
v
Security monitoring
|
v
Suspicious activity
|
v
Attempt tracking
|
v
Security threshold
|
v
Firewall protection
|
v
Source restrictedSecurity turns the detection of suspicious SSH activity into an automated process.
32. Briefly for the user
ServerGuard Security is automatic protection of a Linux server from SSH brute-force attacks.
It:
- tracks SSH authentication attempts;
- detects a suspicious number of failed attempts;
- analyzes connection sources;
- uses configured rules and exceptions;
- can automatically restrict suspicious sources through the firewall;
- runs on the Linux server in the background;
- starts automatically together with the system;
- is managed through ServerGuard;
- is part of ServerGuard's multi-layered security architecture.
33. Important note
ServerGuard Security is one of the layers of protection, not a guarantee of absolute security.
No automatic blocking system is capable of eliminating all possible threats.
Server security also depends on:
- SSH configuration;
- the quality of passwords and keys;
- the state of the operating system;
- installed applications;
- network configuration;
- user rights;
- timely updates;
- other protection tools.
ServerGuard is designed to automate the detection of and response to a certain class of threats and to combine this protection with other security mechanisms.
34. ServerGuard Security in the overall architecture
SERVERGUARD
|
v
Windows Management
|
|
SSH
|
v
+-------------------+
| Linux Server |
+-------------------+
|
+------------+------------+
| | |
v v v
Security FileGuard SSH Key Guard
| | |
v v v
SSH attacks File changes Key changes
| | |
+------------+------------+
|
v
Security Events
|
+------+------+
| |
v v
ServerGuard Notifications
Client35. Summary
ServerGuard Security is designed to automate one of the common tasks of Linux administration — protecting SSH from mass attempts to guess access.
Instead of manually and constantly reviewing logs, the system:
- receives information about SSH events;
- analyzes authentication attempts;
- tracks source activity;
- applies the configured rules;
- passes the decision to the firewall if necessary;
- restricts the suspicious source;
- continues to operate in the background.
At the same time, Security is only one of the components of ServerGuard.
Together with FileGuard, SSH Key Guard, SSH Hardening, monitoring, and other modules, it forms a multi-layered system of protection and management for the Linux server.
The main idea of ServerGuard:
not just to notify the administrator about a problem, but to automate the detection of and response to certain types of threats while preserving the ability for the administrator to stay in control.
The documentation describes the purpose and operating principle of Security at the user level. Internal implementation details belong to the developers' technical documentation.