A bastion machine anti-tampering auditing system and method based on double recording source verification

Abstract

The application discloses a bastion host anti-tampering auditing system and method based on double-record-source verification. The application constructs two independent record sources of a bastion host side log and a target asset side log, establishes session association through Session_ID and SSH connection characteristics mapping, protects key fields by adopting SM4 encryption and SM3-HMAC, and cross-verifyes the command quantity, sequence, content and timestamp of the two-way logs in real time, and alarms immediately when log loss, modification or forgery is found. The application makes the attacker need to break through two sets of systems at the same time and bypass the national secret protection through double-source independent recording, which greatly increases the difficulty of tampering. Through minute-level real-time verification, active monitoring is realized. Through multi-dimensional session association technology, the application ensures the accurate matching of heterogeneous logs, forms a complete auditing evidence chain, and effectively solves the core security problem of single-point tampering of traditional bastion host auditing logs.

Description

Technical Field

[0001] This invention belongs to the field of software system technology, and in particular relates to a bastion host anti-tampering audit system and method based on dual record source verification. Background Technology

[0002] In traditional bastion host systems, users log in to the bastion host system and remotely connect to server assets within the system. The bastion host records all executed commands during the connection process to achieve auditing functionality. However, this auditing function can only prevent the records from being tampered with. If the bastion host administrator enters the system and directly deletes the system logs, the auditors will not be able to know, which poses a significant security risk in practical applications. Summary of the Invention

[0003] In view of this, the present invention aims to overcome the shortcomings of the above-mentioned problems in the prior art and proposes a bastion host anti-tampering audit system and method based on dual record source verification.

[0004] To achieve the above objectives, the technical solution of the present invention is implemented as follows:

[0005] In a first aspect, the present invention provides a bastion host anti-tampering auditing system based on dual record source verification, comprising:

[0006] The bastion host auditing module is used to record remote operation commands initiated by the bastion host, the operation user, the target asset, the timestamp, the internal session number (Session_ID), and the connection characteristics when the bastion host establishes an SSH connection with the target asset; the connection characteristics include the source IP, source port, target IP, target port, and protocol type;

[0007] The target asset log collection module is deployed on the target server or connected to the target server's log system. It is used to collect the actual SSH login events and command execution events that occur on the target asset side, and record the connection characteristics, login users, timestamps, TTYs, PIDs and command contents that can be observed on the asset side.

[0008] The session association module is used to establish a mapping relationship between the Session_ID inside the bastion host and the session information on the asset side based on the connection characteristics recorded on the bastion host side and the connection characteristics collected on the asset side, and to generate or match a unified session association identifier.

[0009] The encryption and integrity protection module is used to encrypt, hash, HMAC, or digitally sign session association identifiers, command records, or log summaries.

[0010] The log auditing system is used to receive logs from both the bastion host side and the target asset side, parse the log content, and establish session mapping relationships.

[0011] The dual-source verification module is used to compare the quantity, order, command content, timestamp, user, target asset, and integrity verification results of two log streams.

[0012] The anomaly detection module is used to identify anomaly types such as missing logs, deleted commands, modified commands, abnormal order, abnormal timestamps, forged logs, and duplicate logs.

[0013] The alarm and evidence retention module is used to generate alarms, save verification results, generate discrepancy reports, and form an audit evidence chain.

[0014] Furthermore, the session association module generates or matches the unified session association identifier in one or more of the following ways:

[0015] Method 1: The bastion host generates a unique Session_ID when a user initiates a remote connection, and binds this Session_ID with the operating user, target asset, source IP, source port, target IP, target port, and login time information;

[0016] Method 2: Calculate the session fingerprint based on the source IP, source port, destination IP, destination port, login username, and login time window, which is used to establish a correlation between the two log streams;

[0017] Method 3: Obtain auxiliary information such as user, process, TTY, and login time through PAM, auditd, shell hook, eBPF, / proc file system, sshd process information or pseudo-terminal identifier on the target asset's operating system side, and use it together with SSH connection characteristics for session matching;

[0018] The priority of using the above methods is as follows: Method 1 is used as the primary association identifier; when the asset side cannot obtain the Session_ID, Method 2 is used for matching; when the network connection information is incomplete, Method 3 is used for supplementary matching; if the acquisition of a certain type of information fails, the downgrade association process is entered; when multiple key fields cannot be matched or the matching confidence is lower than the preset threshold, a "session association anomaly" alarm is generated, and the session is marked as pending manual review.

[0019] Furthermore, the target asset log collection module is implemented based on auditd, PAM, shell hook, eBPF or system log agent, and is used to collect command execution events of users in SSH sessions, and encapsulate command content, execution time, user identifier, process identifier, pseudo terminal identifier and SSH connection characteristic information into asset-side audit logs.

[0020] Furthermore, the encryption and integrity protection module uses the SM4 symmetric encryption algorithm to symmetrically encrypt the session association field in the bastion host log to obtain an encrypted session identifier; it uses SM3-HMAC to calculate the integrity check code for the key fields of the log record. The key fields include one or more of the following: encrypted session identifier, command content or command digest, operating user, target asset, timestamp, and log sequence number; the SM4 encryption key and SM3-HMAC key are uniformly generated and managed by the log auditing system or key management module and are securely distributed to the bastion host in advance, or a periodically rotated session key is used.

[0021] Furthermore, the dual-source verification module performs the following verification steps:

[0022] Compare the number of commands in two logs within the same session to detect if there are any missing logs;

[0023] The execution order of commands is compared to detect any abnormalities.

[0024] The command content is standardized and then compared to check if any command has been modified.

[0025] Compare timestamps to detect any timestamp anomalies;

[0026] The system compares user and target asset information to detect the presence of forged logs.

[0027] Secondly, this invention proposes a bastion host anti-tampering auditing method based on dual record source verification, comprising the following steps:

[0028] Step 1: Session establishment and dual-channel log source initialization:

[0029] Users initiate SSH connections to target assets through the bastion host. The bastion host generates a unique Session_ID and binds the Session_ID to the connection characteristics of this SSH connection.

[0030] Step 2: Operation Execution and Dual-Path Parallel Recording:

[0031] The bastion host records the commands executed by the user and attaches a Session_ID. After encryption and integrity protection, it generates bastion host audit logs and sends them to the log audit system. The captured commands are bound with the characteristics of the current SSH connection to generate asset-side audit logs and send them to the same log audit system.

[0032] Step 3: Log auditing system receives, decrypts, and associates logs.

[0033] The log auditing system receives logs from the bastion host side and asset side, decrypts and verifies the integrity of the bastion host side logs, and establishes a mapping relationship between Session_ID and asset side session information based on the connection characteristics of both sides.

[0034] Step 4: Real-time verification and consistency comparison:

[0035] The number of commands, command order, command content, timestamp, user, and target asset in the two logs of the same session are compared in real time to determine whether there are any anomalies.

[0036] Step 5: Anomaly Alarm:

[0037] When an anomaly is detected during verification, an alarm message and a discrepancy report are generated, and the session is marked for further verification.

[0038] Furthermore, in step 2, when the bastion host generates audit logs, the SM4 algorithm is used to symmetrically encrypt one or more session association fields within the bastion host, including Session_ID, session association identifier, source IP, source port, target IP, target port, logged-in user, and operation time, to obtain the encrypted session identifier Enc_SID; SM3-HMAC is used to calculate the integrity check code for the key fields of the log record; after receiving the log from the bastion host, the log audit system uses the corresponding key to decrypt Enc_SID, recalculates the HMAC check code, and compares it with the HMAC value carried in the log to confirm that the key fields of the log have not been tampered with.

[0039] Furthermore, in step 3, the mapping relationship is established as follows: the log auditing system parses the connection feature information in the asset-side syslog and matches it with the connection feature bound to the Session_ID obtained after decryption on the bastion host side. The matching fields include source IP, source port, target IP, target port, login user, and time window. When the above fields meet the matching conditions, it is confirmed that the asset-side log and the Session_ID on the bastion host side correspond to the same SSH session, and a mapping relationship is established.

[0040] Furthermore, the Session_ID is generated when the bastion host initiates an SSH connection and is used for log association and real-time verification during the session. After the session is disconnected, the Session_ID and its corresponding audit logs, session mapping relationships and verification results are still saved for subsequent audit tracing.

[0041] Furthermore, the command content in the bastion host log is transmitted in plaintext, encrypted, or with only the command digest protected for integrity, depending on the security policy; the connection characteristics of the target asset are written to the asset-side syslog in plaintext, or are anonymized, hashed, or encrypted according to the security policy.

[0042] Compared with existing technologies, the bastion host anti-tampering audit system and method based on dual record source verification described in this invention has the following advantages:

[0043] (1) Effective anti-tampering auditing is achieved: In abnormal scenarios, even if a bastion host administrator with high privileges deletes a record, the tampering behavior will be automatically detected and alerted by the system within 1 minute because there is an independent, real-time log stream on the asset side. Attackers need to simultaneously and accurately tamper with the logs on the bastion host and all related servers without being detected, which is almost impossible in a real environment, thus greatly improving the reliability and credibility of audit logs.

[0044] (2) Ensures the accuracy and traceability of auditing: Through session association technology based on the mapping of Session_ID and SSH connection characteristics within the bastion host, it ensures that logs from two independent sources can be accurately matched, avoiding false or missed associations. Any operation can be traced back to a unique bastion host session and the corresponding execution record on the target asset side, forming a complete chain of audit evidence. This ensures that logs from two independent sources can be accurately matched, avoiding false or missed associations. Any operation can be traced back to a unique SSH session source, forming an irrefutable and complete chain of evidence.

[0045] (3) Enhanced security of data transmission and storage: The session ID on the bastion host side is encrypted using the national cryptographic SM4 algorithm and protected by SM3 HMAC integrity. This means that even if the log transmission is intercepted, attackers cannot obtain the real session ID to forge associations; any tampering with the ciphertext will be detected by HMAC verification. This provides double protection for the confidentiality and integrity of audit data.

[0046] (4) Real-time monitoring and response were achieved: The entire process, from log generation and uploading to verification and alerting, is fully automated and completed within minutes. The security team can detect log anomalies almost in real time and respond quickly to potential security incidents, transforming the previous passive, periodic auditing model into proactive, dynamic, and continuous monitoring. Attached Figure Description

[0047] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0048] Figure 1 This is a schematic diagram of the system framework of the present invention;

[0049] Figure 2 This is a schematic diagram illustrating the mapping process between the internal session identifier and the asset-side connection characteristics of the present invention.

[0050] Figure 3 This is a schematic diagram illustrating the use of national cryptographic algorithms to protect the internal session identifier and key session association fields on the bastion host side according to the present invention. Detailed Implementation

[0051] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0052] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0053] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0054] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0055] refer to Figure 1-3 This invention provides a bastion host anti-tampering auditing system based on dual record source verification, comprising:

[0056] The bastion host auditing module is used to record remote operation commands initiated by the bastion host, the operation user, the target asset, the timestamp, the internal session number (Session_ID), and the connection characteristics when the bastion host establishes an SSH connection with the target asset; the connection characteristics include the source IP, source port, target IP, target port, and protocol type;

[0057] The target asset log collection module is deployed on the target server or connected to the target server's log system. It is used to collect the actual SSH login events and command execution events that occur on the target asset side, and record the connection characteristics, login users, timestamps, TTYs, PIDs and command contents that can be observed on the asset side.

[0058] The session association module is used to establish a mapping relationship between the Session_ID inside the bastion host and the session information on the asset side based on the connection characteristics recorded on the bastion host side and the connection characteristics collected on the asset side, and to generate or match a unified session association identifier.

[0059] The encryption and integrity protection module is used to encrypt, hash, HMAC, or digitally sign session association identifiers, command records, or log summaries.

[0060] The log auditing system is used to receive logs from both the bastion host side and the target asset side, parse the log content, and establish session mapping relationships.

[0061] The dual-source verification module is used to compare the quantity, order, command content, timestamp, user, target asset, and integrity verification results of two log streams.

[0062] The anomaly detection module is used to identify anomaly types such as missing logs, deleted commands, modified commands, abnormal order, abnormal timestamps, forged logs, and duplicate logs.

[0063] The alarm and evidence retention module is used to generate alarms, save verification results, generate discrepancy reports, and form an audit evidence chain.

[0064] As a further solution, this invention does not rely on a single "SSH session ID," but instead generates a unified session association identifier based on multiple SSH connection characteristics. The session association module generates or matches the unified session association identifier in one or more of the following ways:

[0065] Method 1: The bastion host actively generates an internal session ID. This method is suitable for all SSH connection scenarios initiated through the bastion host proxy. The bastion host generates a unique Session_ID when the user initiates a remote connection and binds this Session_ID with information such as the user, target asset, source IP, source port, target IP, target port, and login time. This method offers the highest stability and is the preferred choice.

[0066] Method 2: Generate session association identifiers from SSH connection characteristics. This method is suitable for scenarios where both the bastion host and the asset side can obtain network connection information. For example, it can calculate session fingerprints based on information such as source IP, source port, destination IP, destination port, login username, and login time window, and use this information to establish associations between two log streams.

[0067] Method 3: Obtain auxiliary identifiers from the target asset's operating system side. This method is suitable for scenarios where a command acquisition module is deployed on the asset side. Information such as user, process, TTY, and login time can be obtained through PAM, auditd, shell hook, eBPF, / proc file system, sshd process information, or pseudo-terminal identifiers, and used together with SSH connection characteristics for session matching.

[0068] The usage priority of the above methods is as follows: The internal Session_ID generated by the bastion host is used first as the primary association identifier; when the asset side cannot directly obtain the Session_ID, a session fingerprint is generated using the SSH connection five-tuple, logged-in user, and time window for matching; when network connection information is incomplete, auxiliary information such as process identifier, pseudo-terminal identifier, PAM login record, and auditd record are used for supplementary matching. If the acquisition of a certain type of information fails, the system does not immediately determine that the verification has failed, but instead enters a downgraded association process; when multiple key fields cannot be matched or the matching confidence is lower than a preset threshold, a "session association anomaly" alarm is generated, and the session is marked for manual review.

[0069] The Session_ID is generated when the bastion host initiates an SSH connection. It is used for log association and real-time verification during the session. After the session is disconnected, the Session_ID and its corresponding audit logs, session mapping relationships and verification results are still saved for subsequent audit tracing.

[0070] As a further solution, the target asset log collection module is implemented based on auditd, PAM, shell hook, eBPF or system log agent, and is used to collect command execution events of users in SSH sessions, and encapsulate the command content, execution time, user identifier, process identifier, pseudo terminal identifier and SSH connection characteristic information into asset-side audit logs.

[0071] As a further solution, the encryption and integrity protection module uses the SM4 symmetric encryption algorithm to symmetrically encrypt the session association field in the bastion host side log to obtain an encrypted session identifier; it uses SM3-HMAC to calculate the integrity check code for the key fields of the log record. The key fields include one or more of the following: encrypted session identifier, command content or command digest, operating user, target asset, timestamp, and log sequence number; the SM4 encryption key and SM3-HMAC key are uniformly generated and managed by the log auditing system or key management module and are securely distributed to the bastion host side in advance, or a periodically rotated session key is used.

[0072] As a further solution, the dual-source verification module performs the following verification steps:

[0073] Compare the number of commands in two logs within the same session to detect if there are any missing logs;

[0074] The execution order of commands is compared to detect any abnormalities.

[0075] The command content is standardized and then compared to check if any command has been modified.

[0076] Compare timestamps to detect any timestamp anomalies;

[0077] The system compares user and target asset information to detect the presence of forged logs.

[0078] This invention implements dual verification: firstly, it verifies that key fields in the bastion host logs have not been tampered with through encryption and integrity checks; secondly, it verifies the consistency of log content by comparing session association and command sequences between the two log streams. Simultaneously, the dual log verification is performed in real-time at configurable short intervals (e.g., minutes), enabling timely detection of anomalies such as log inconsistencies and rapid response. The complete audit chain of this invention can be traced back to the SSH connection. Attackers would need to simultaneously and in real-time compromise and tamper with logs in two independent systems—the bastion host and the asset side—and bypass national cryptographic algorithms for encryption and integrity checks, making this extremely difficult and achieving tamper-proof protection.

[0079] Example 2

[0080] This invention proposes a bastion host anti-tampering auditing method based on dual record source verification, comprising the following steps:

[0081] Step 1: Session establishment and dual-channel log source initialization:

[0082] Users initiate SSH connections to target assets through the bastion host. The bastion host generates a unique Session_ID and binds the Session_ID to the connection characteristics of this SSH connection.

[0083] Step 2: Operation Execution and Dual-Path Parallel Recording:

[0084] The bastion host records the commands executed by the user and attaches a Session_ID. After encryption and integrity protection, it generates bastion host audit logs and sends them to the log audit system. The captured commands are bound with the characteristics of the current SSH connection to generate asset-side audit logs and send them to the same log audit system.

[0085] Step 3: Log auditing system receives, decrypts, and associates logs.

[0086] The log auditing system receives logs from the bastion host side and asset side, decrypts and verifies the integrity of the bastion host side logs, and establishes a mapping relationship between Session_ID and asset side session information based on the connection characteristics of both sides.

[0087] Step 4: Real-time verification and consistency comparison:

[0088] The number of commands, command order, command content, timestamp, user, and target asset in the two logs of the same session are compared in real time to determine whether there are any anomalies.

[0089] Step 5: Anomaly Alarm:

[0090] When an anomaly is detected during verification, an alarm message and a discrepancy report are generated, and the session is marked for further verification.

[0091] As a further solution, in step 2, when the bastion host generates audit logs, the SM4 algorithm is used to symmetrically encrypt one or more of the following session association fields within the bastion host: Session_ID, session association identifier, source IP, source port, target IP, target port, logged-in user, and operation time, to obtain the encrypted session identifier Enc_SID; SM3-HMAC is used to calculate the integrity check code for the key fields of the log record; after receiving the log from the bastion host, the log audit system uses the corresponding key to decrypt Enc_SID, recalculates the HMAC check code, and compares it with the HMAC value carried in the log to confirm that the key fields of the log have not been tampered with.

[0092] As a further solution, in step 3, the mapping relationship is established as follows: the log auditing system parses the connection feature information in the asset-side syslog and matches it with the connection feature bound to the Session_ID obtained after decryption on the bastion host side. The matching fields include source IP, source port, target IP, target port, login user, and time window. When the above fields meet the matching conditions, it is confirmed that the asset-side log and the Session_ID on the bastion host side correspond to the same SSH session, and the mapping relationship is established.

[0093] As a further solution, the Session_ID is generated when the bastion host initiates an SSH connection and is used for log association and real-time verification during the session. After the session is disconnected, the Session_ID and its corresponding audit logs, session mapping relationships and verification results are still saved for subsequent audit tracing.

[0094] As a further solution, the command content in the bastion host log is selected to be transmitted in plaintext, encrypted, or only the command digest is protected for integrity according to the security policy; the connection characteristics of the target asset are written to the asset-side syslog in plaintext, or are anonymized, hashed, or encrypted according to the security policy.

[0095] The following example illustrates the specific implementation process of this invention, using the scenario of an operations and maintenance personnel logging into a Linux server through a bastion host and executing operation commands.

[0096] Scene setting:

[0097] Maintenance personnel: Zhang San

[0098] Target asset: A Linux server with IP address 10.0.1.100

[0099] Task: Log in to the server, check the directory, and back up a configuration file.

[0100] Potential risk: "Li Si," who possesses bastion host administrator privileges, may attempt to tamper with or delete Zhang San's records to cover up his misconduct.

[0101] Implementation steps:

[0102] Step 1: Session establishment and dual-channel log source initialization

[0103] Zhang San logs into the bastion host through a web browser, selects the target server 10.0.1.100 in the bastion host system, and initiates an SSH connection.

[0104] The bastion host session management module establishes an SSH connection with the target server. After the connection is established, the bastion host generates a unique Session_ID for internal tracking, such as SID_abc123, and binds this Session_ID to the connection characteristics of this SSH connection. The connection characteristics include information such as source IP, source port, target IP, target port, login username, and login time.

[0105] The target asset side does not require direct access to the bastion host's internal Session_ID. Instead, it obtains the connection characteristics of the same SSH connection through PAM, sshd logs, the SSH_CONNECTION environment variable, the / proc file system, process information, or pseudo-terminal information. The log auditing system establishes a mapping relationship between the bastion host's internal Session_ID and the asset's session information based on the connection characteristics recorded on the bastion host side and those collected on the asset side.

[0106] Therefore, the Session_ID inside the bastion host is the main session identifier used for audit management in this invention; the SSH connection characteristics obtained from the asset side are auxiliary association information used to match this Session_ID. The two are not the same ID, but rather a correspondence is established through connection characteristics and time windows.

[0107] On the asset-side server 10.0.1.100, the sshd process is monitored to capture SSH connections and obtain the same SSH connection information.

[0108] Step 2: Operation Execution and Dual-Path Parallel Recording

[0109] Zhang San executes the following command:

[0110] pwd

[0111] sudo cp / etc / nginx / nginx.conf / etc / nginx / nginx.conf.backup

[0112] The bastion host records these two commands and appends the Session_ID (SID_abc123).

[0113] After encryption using the national cryptographic algorithm, the ciphertext Enc_SID_xyz789 is obtained. At the same time, the HMAC checksum of the entire log record is calculated using the SM3 algorithm.

[0114] After generating audit logs, the bastion host encrypts and protects the integrity of key related fields within the logs. Encrypted objects may include session-related fields such as the bastion host's internal Session_ID, session association identifier, source IP, source port, destination IP, destination port, logged-in user, and operation time. Command content can be transmitted in plaintext, encrypted, or with only the command digest protected according to the security policy.

[0115] In scenarios compliant with national cryptographic standards, the SM4 algorithm is preferred for symmetric encryption of session-related fields to obtain the encrypted session identifier Enc_SID; SM3-HMAC is used to calculate integrity check codes for key fields in log records. Fields involved in HMAC calculation may include Enc_SID, command content or command digest, operating user, target asset, timestamp, log sequence number, etc.

[0116] The SM4 encryption key and SM3-HMAC key are generated and managed uniformly by the log auditing system and distributed to the bastion host side in advance through a secure channel. After receiving the logs from the bastion host side, the log auditing system decrypts the Enc_SID using the corresponding key, recalculates the HMAC checksum, and compares it with the HMAC value carried in the log to confirm that the critical fields of the log have not been tampered with.

[0117] Send the encrypted logs: {"esid":"Enc_SID_xyz789","cmd":"pwd",...} and {"esid":"Enc_SID_xyz789","cmd":"sudo cp...",...} to the log auditing system.

[0118] The asset-side server binds captured commands to the current SSH connection characteristics. These characteristics can be written to the asset-side syslog in plaintext, or they can be anonymized, hashed, or encrypted according to security policies. The asset-side server does not need to be aware of or store the Session_ID generated by the bastion host.

[0119] Here is an example of a formatted syslog log:

[0120] <timestamp>CMD=pwd SESSION_INFO=192.168.1.5_54321_10.0.1.100_22 ...

[0121] Send to the same log auditing system.

[0122] Step 3: Log auditing system receives, decrypts, and associates logs.

[0123] The log auditing system simultaneously receives encrypted logs from the bastion host and plaintext syslog logs from the asset side.

[0124] The auditing system used the key to decrypt Enc_SID_xyz789, successfully restoring the Session_ID: SID_abc123. Verification of the HMAC checksum confirmed that the bastion host logs had not been tampered with.

[0125] The auditing system parses the connection characteristic information in the asset-side syslog and matches it with the connection characteristics bound to the Session_ID obtained after decryption on the bastion host side. Matching fields include source IP (192.168.1.5), source port (54321), destination IP (10.0.1.100), destination port (22), logged-in user (zhangsan), and time window. When the above fields meet the matching conditions, it confirms that the asset-side log corresponds to the same SSH session as the Session_ID on the bastion host side, and establishes a mapping relationship.

[0126] Step 4: Real-time verification and consistency comparison

[0127] The verification module initiates a real-time comparison of session SID_abc123. The real-time verification period is configurable in minutes.

[0128] Sequence comparison: In the log stream, the command sequence is always ["pwd", "sudo cp..."], and the order is completely consistent.

[0129] Content comparison: After standardization (removing extra spaces, etc.), the commands are completely identical.

[0130] Timestamp comparison: The time difference between the two pwd records and the time difference between the two cp records are both within a reasonable threshold (e.g., 2 seconds).

[0131] The verification was successful, confirming that the records are consistent and there are no abnormalities. The results have been stored in the database.

[0132] Step 5: Simulate Abnormal Scenarios

[0133] Suppose that bastion host administrator Li Si tries to cover up the sensitive operation sudo cp for Zhang San, and deletes the second record (sudo cp...) of SID_abc123 in the bastion host backend.

[0134] When the next verification cycle arrives, the verification module checks session SID_abc123.

[0135] Bastion host side log: Only one record ["pwd"] can be viewed.

[0136] Asset-side logs: Two records remain: ["pwd", "sudo cp..."].

[0137] Verification failure and alarm: An inconsistency in the command sequence was detected, and the bastion host side is missing the sudo cp ... record, triggering a real-time alarm in the system at the "high risk" level. The alarm information is sent to the security administrator via email, SMS, etc.: "Alarm: Dual-path log verification of session (SID_abc123) failed. The bastion host record is suspected of being tampered with and the sensitive command 'sudo cp' is missing."

[0138] On the audit system page, the session is marked in red and a detailed comparison report is provided.

[0139] In summary, this invention solves the core security problem of traditional bastion host audit logs being easily tampered with from a single point of failure due to their reliance on a single log source by combining a mechanism of "dual-path recording, Session_ID and SSH connection feature mapping, national cryptographic algorithm protection, and real-time verification," achieving significant technical results.

[0140] First, this invention does not simply encrypt, sign, or prevent deletion of a single log source; instead, it establishes two independent recording sources: the bastion host-side log and the target asset-side log. Even if the bastion host-side log is deleted or modified by a high-privilege administrator, the target asset-side log still retains the actual command execution records, thus enabling the detection of single-point tampering.

[0141] Second, this invention associates two independent logs with the same SSH session through a session association identifier. This session association identifier does not simply rely on a single log field, but is generated or matched by integrating information such as the bastion host's internal Session_ID, SSH connection 5-tuple, logged-in user, login time window, process identifier, and pseudo-terminal identifier. This solves the problem of difficulty in accurately associating two logs from different sources, with different field formats, and with time discrepancies.

[0142] Third, this invention uses encryption and integrity protection to safeguard session association fields and key log fields, making it difficult for attackers to forge verifiable session associations even if they obtain partial log content. Encryption and integrity protection are not used solely for storage protection, but rather serve the dual-path log association and verification process.

[0143] Fourth, this invention sets up a real-time verification mechanism to continuously compare the number of commands, command order, command content, timestamps, users, and target assets of two logs under the same session, and generates alarms and difference reports when missing, modified, forged, or out of order is found, thus transforming traditional post-event auditing into real-time anomaly detection.

[0144] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.< / timestamp>

Claims

1. A bastion host anti-tampering auditing system based on dual record source verification, characterized in that: include: The bastion host auditing module is used to record remote operation commands initiated by the bastion host, the operation user, the target asset, the timestamp, the internal session number (Session_ID), and the connection characteristics when the bastion host establishes an SSH connection with the target asset; the connection characteristics include the source IP, source port, target IP, target port, and protocol type; The target asset log collection module is deployed on the target server or connected to the target server's log system. It is used to collect the actual SSH login events and command execution events that occur on the target asset side, and record the connection characteristics, login users, timestamps, TTYs, PIDs and command contents that can be observed on the asset side. The session association module is used to establish a mapping relationship between the Session_ID inside the bastion host and the session information on the asset side based on the connection characteristics recorded on the bastion host side and the connection characteristics collected on the asset side, and to generate or match a unified session association identifier. The encryption and integrity protection module is used to encrypt, hash, HMAC, or digitally sign session association identifiers, command records, or log summaries. The log auditing system is used to receive logs from both the bastion host side and the target asset side, parse the log content, and establish session mapping relationships. The dual-source verification module is used to compare the quantity, order, command content, timestamp, user, target asset, and integrity verification results of two log streams. The anomaly detection module is used to identify anomaly types such as missing logs, deleted commands, modified commands, abnormal order, abnormal timestamps, forged logs, and duplicate logs. The alarm and evidence retention module is used to generate alarms, save verification results, generate discrepancy reports, and form an audit evidence chain.

2. The bastion host anti-tampering auditing system based on dual record source verification according to claim 1, characterized in that: The session association module generates or matches the unified session association identifier in one or more of the following ways: Method 1: The bastion host generates a unique Session_ID when a user initiates a remote connection, and binds this Session_ID with the operating user, target asset, source IP, source port, target IP, target port, and login time information; Method 2: Calculate the session fingerprint based on the source IP, source port, destination IP, destination port, login username, and login time window, which is used to establish a correlation between the two log streams; Method 3: Obtain auxiliary information such as user, process, TTY, and login time through PAM, auditd, shell hook, eBPF, / proc file system, sshd process information or pseudo-terminal identifier on the target asset's operating system side, and use it together with SSH connection characteristics for session matching; The priority of using the above methods is as follows: Method 1 is used as the primary association identifier; when the asset side cannot obtain the Session_ID, Method 2 is used for matching; when the network connection information is incomplete, Method 3 is used for supplementary matching; if the acquisition of a certain type of information fails, the downgrade association process is entered; when multiple key fields cannot be matched or the matching confidence is lower than the preset threshold, a "session association abnormality" alarm is generated, and the session is marked as pending manual review.

3. The bastion host anti-tampering auditing system based on dual record source verification according to claim 1, characterized in that: The target asset log collection module is implemented based on auditd, PAM, shell hook, eBPF or system log agent. It is used to collect command execution events of users in SSH sessions and encapsulate the command content, execution time, user identifier, process identifier, pseudo terminal identifier and SSH connection characteristic information into asset-side audit logs.

4. The bastion host anti-tampering auditing system based on dual record source verification according to claim 1, characterized in that: The encryption and integrity protection module uses the SM4 symmetric encryption algorithm to symmetrically encrypt the session association fields in the bastion host logs to obtain an encrypted session identifier; it uses SM3-HMAC to calculate integrity check codes for key fields in the log records. The key fields include one or more of the following: encrypted session identifier, command content or command digest, operating user, target asset, timestamp, and log sequence number; the SM4 encryption key and SM3-HMAC key are uniformly generated and managed by the log auditing system or key management module and are securely distributed to the bastion host in advance, or a periodically rotated session key is used.

5. The bastion host anti-tampering auditing system based on dual record source verification according to claim 1, characterized in that: The dual-source verification module performs the following verification steps: Compare the number of commands in two logs within the same session to detect if there are any missing logs; The execution order of commands is compared to detect any abnormalities. The command content is standardized and then compared to check if any command has been modified. Compare the timestamps to detect any timestamp anomalies; The system compares user and target asset information to detect the presence of forged logs.

6. A bastion host anti-tampering auditing method based on dual record source verification, characterized in that: Includes the following steps: Step 1: Session establishment and dual-channel log source initialization: Users initiate SSH connections to target assets through the bastion host. The bastion host generates a unique Session_ID and binds the Session_ID to the connection characteristics of this SSH connection. Step 2: Operation Execution and Dual-Path Parallel Recording: The bastion host records the commands executed by the user and attaches a Session_ID. After encryption and integrity protection, it generates bastion host audit logs and sends them to the log audit system. The captured commands are bound with the characteristics of the current SSH connection to generate asset-side audit logs and send them to the same log audit system. Step 3: Log auditing system receives, decrypts, and associates logs. The log auditing system receives logs from the bastion host side and asset side, decrypts and verifies the integrity of the bastion host side logs, and establishes a mapping relationship between Session_ID and asset side session information based on the connection characteristics of both sides. Step 4: Real-time verification and consistency comparison: The number of commands, command order, command content, timestamp, user, and target asset in the two logs of the same session are compared in real time to determine whether there are any anomalies. Step 5: Anomaly Alarm: When an anomaly is detected during verification, an alarm message and a discrepancy report are generated, and the session is marked for further verification.

7. The bastion host anti-tampering auditing method based on dual record source verification according to claim 6, characterized in that: In step 2, when the bastion host generates audit logs, the SM4 algorithm is used to symmetrically encrypt one or more of the following session association fields within the bastion host: Session_ID, session association identifier, source IP, source port, target IP, target port, logged-in user, and operation time, to obtain the encrypted session identifier Enc_SID. SM3-HMAC is used to calculate the integrity check code for key fields in the log record. After receiving the log from the bastion host, the log audit system decrypts the Enc_SID using the corresponding key and recalculates the HMAC check code, comparing it with the HMAC value carried in the log to confirm that the key fields of the log have not been tampered with.

8. The bastion host anti-tampering auditing method based on dual record source verification according to claim 6, characterized in that: In step 3, the mapping relationship is established as follows: the log auditing system parses the connection feature information in the asset-side syslog and matches it with the connection feature bound to the Session_ID obtained after decryption on the bastion host side. The matching fields include source IP, source port, target IP, target port, login user, and time window. When the above fields meet the matching conditions, it is confirmed that the asset-side log and the Session_ID on the bastion host side correspond to the same SSH session, and the mapping relationship is established.

9. A bastion host anti-tampering auditing method based on dual record source verification according to claim 6, characterized in that: The Session_ID is generated when the bastion host initiates an SSH connection and is used for log association and real-time verification during the session. After the session is disconnected, the Session_ID and its corresponding audit logs, session mapping relationships and verification results are still saved for subsequent audit tracing.

10. A bastion host anti-tampering auditing method based on dual record source verification according to claim 6, characterized in that: The command content in the bastion host log is transmitted in plaintext, encrypted, or with only the command digest protected for integrity, depending on the security policy. The connection characteristics of the target asset are written to the asset's syslog in plaintext, or are anonymized, hashed, or encrypted according to the security policy.

Images