The typical client-server approach is commonly used to administer remote systems. On the target system, a service runs, either giving a remote view of locally available administration tools (e.g., remote terminal, remote desktop) or implementing a back-end for the execution of sophisticated instructions received through a matching front-end (e.g.: web-based administration interfaces). The service typically exposes only one access point, which is an easy target for attacks such as DoS or brute-force authentication attempts.
Limiting the impact of these attacks is difficult; often, one or more reactive or proactive approaches are used, as detailed by Brießy below. Account lock-out and connection throttling are examples of access limitation solutions that react to suspicious behaviour (such as unsuccessful login attempts or unusually high traffic) that could be a sign of an ongoing attack. However, by doing so, they put both the genuine administrator and the attacker at risk of losing access to the system. Instead, pre-authentication protocols such as port-knocking and Cryptographically Constantly Changing Port Opening (C3PO) address the problem of hiding the administration port from all but the legitimate administrator; the server recognizes a sequence of specially crafted packets sent by the administrator, and the administrator receives a response from the server.
The administration service differs significantly from the other services often offered by the same host. While the latter needs to be visible to a wide range of people, the former is only for the official system administrator. By fully modifying the access model, this peculiarity can be used to safeguard the sensitive administration service from harmful exploitation. The purpose of this study is to come up with a novel way for the system administrator and the remote administration interface to communicate. The inherent vulnerability of the traditional scheme is addressed by reversing the client-server relationship; an administration engine replaces the traditional service, originating connections to an intermediate system rather than listening for connections in the proposed solution, which was previously outlined in.
The immediate benefit of this design choice is that there is nothing on the remote host to attack. The addition of a new system to the security chain, on the other hand, must be carefully examined to prevent introducing unforeseen attack routes and making the system less resistant than it was before. A platform based on the meeting of the server and its administrator on an intermediate system, we say, is expedient in terms of security, availability, usability, and future extension if properly designed and implemented. The design guidelines for the proposed system are outlined in the next section, as well as the architecture that results. Then we’ll talk about the security risks that arise as a result of the derivation.
Finally, based on both the current theoretical analysis and preliminary experimental results, we draw conclusions.