CN115834164A - Method and system for preventing bill attack in Kerberos authentication - Google Patents

Abstract

The invention relates to the field of access authentication, in particular to a method and a system for preventing bill attack in Kerberos authentication. The method mainly comprises the following steps: when the KDC issues the bill, recording the client characteristics of the application bill and the bill characteristics issued by the KDC, wherein the bill comprises TGT and ST; and acquiring the client characteristics and the bill characteristics in the message, inquiring whether the bill characteristics corresponding to the client are consistent with the bill characteristics issued by the KDC, and judging the type of the attack according to the inquiry result or carrying out corresponding forwarding. The method provided by the invention can accurately and effectively detect and prevent silver bill attack and gold bill attack in Kerberos authentication.

Description

Method and system for preventing bill attack in Kerberos authentication

Technical Field

The invention relates to the field of access authentication, in particular to a method and a system for preventing bill attack in Kerberos authentication.

Background

Kerberos authentication is an authentication mode based on bills, and silver bill attacks and gold bill attacks exist in different authentication processes. In order to secure communications, protection against ticket attacks is required.

The current defense measures generally taken to prevent silver bill attacks include:

(1) The master key of the Application Server is ensured not to be leaked as much as possible;

(2) Starting PAC-Application Server to send ST to KDC, and using KDC to verify whether ST is valid;

(3) Abnormal Kerberos activity is detected or monitored.

The defense measures generally adopted at present for preventing the gold bill from attacking include:

(1) The login behavior of a KDC administrator is limited so as to ensure that the master key of the KDC is not leaked as much as possible;

(2) Periodically changing a master key of the KDC;

(3) The KDC password is changed twice quickly, so that any existing gold bill is invalid;

(4) Abnormal Kerberos activity is detected or monitored.

Analyzing the prior art for preventing the bill attack in Kerberos authentication, the following problems mainly exist:

(1) The method of ensuring that the master key is not leaked as far as possible cannot be realized;

(2) Means such as regularly modifying the main key cannot be used once and for all;

(3) The Kerberos authentication protocol is modified, and the compatibility of the mode of enhancing the safety of the Kerberos authentication protocol by changing the original flow or algorithm of the protocol is poor;

(4) There are also some methods of detection or monitoring that have the ability to detect attacks, but cannot prevent them.

In view of this, how to overcome the defects in the prior art and solve the defects of the existing bill attack defense mode in Kerberos authentication is a problem to be solved in the technical field.

Disclosure of Invention

In view of the above deficiencies or needs in the art, the present invention addresses some of the deficiencies of existing ticket attack defense approaches in Kerberos authentication.

The embodiment of the invention adopts the following technical scheme:

in a first aspect, the present invention provides a method for preventing a ticket attack in Kerberos authentication, specifically: when the KDC issues the bill, recording the client characteristics of the application bill and the bill characteristics issued by the KDC, wherein the bill comprises TGT and ST; and acquiring the client characteristics and the bill characteristics in the message, inquiring whether the bill characteristics corresponding to the client are consistent with the bill characteristics issued by the KDC, and judging the type of the attack according to the inquiry result or carrying out corresponding forwarding.

Preferably, the recording of the client characteristics of the application ticket and the ticket characteristics issued by the KDC specifically includes: for TGT, the Client characteristics comprise a Kerberos domain and a Kerberos Client identifier, and the bill characteristics are the TGT acquired by the Kerberos Client from KDC; for ST, the Client characteristics comprise a Kerberos domain and an identification of an Application Server which the Kerberos Client needs to access, and the bill characteristics are the ST which the Kerberos Client applies for from the KDC and is needed for accessing the Application Server.

Preferably, the recording of the client characteristics of the application ticket and the ticket characteristics issued by the KDC further includes: for the TGT, note characteristics that have been encrypted using the KDC's master key are recorded; for ST, the ticket features that have been encrypted using the master key of the Application Server are recorded.

Preferably, the recording of the client characteristics of the application mark ticket and the ticket characteristics issued by the KDC further includes: when the client applies for the bill for the first time, adding the client characteristics and the bill characteristics issued by the KDC into the record; and when the client does not apply for the bill for the first time, updating the bill characteristic corresponding to the client characteristic by using the bill characteristic issued by the KDC.

Preferably, the method further comprises the following steps: and analyzing the client characteristics in the message, inquiring whether the record contains the corresponding client characteristics, and indicating that the client applies for the bill for the first time when the record does not contain the client characteristics in the message.

Preferably, the querying whether the bill feature corresponding to the client is consistent with the bill feature issued by the KDC specifically includes: analyzing the client characteristics and the bill characteristics in the message, inquiring the bill characteristics corresponding to the same client characteristics in the record, comparing the bill characteristics in the message with the inquired bill characteristics, and judging whether the bill characteristics are consistent or not.

Preferably, the determining the type of the attack according to the query result specifically includes: when the TGT in the message is inconsistent with the TGT in the record, the gold bill attack suspicion exists in the message; and when the ST in the message is inconsistent with the ST in the record, the suspicion of silver bill attack exists in the message.

On the other hand, the invention provides a system for preventing bill attack in Kerberos authentication, which specifically comprises the following steps: the system comprises a client, a first detection device, a second detection device, a KDC and an application server, and specifically comprises the following steps: the client is connected with the IP network through first detection equipment, the application server is connected with the IP network through second detection equipment, and the KDC is connected with the IP network; the first detection device processes the interactive message between the client and the IP network according to the method for preventing the bill attack in the Kerberos authentication provided by any one of claims 1 to 7, and prevents the bill attack initiated by the client; the second detection device receives the method for preventing the bill attack in the Kerberos authentication provided by any one of claims 1 to 7, processes the interactive message between the server and the IP network, and prevents the bill attack initiated by the server.

Preferably, the method further comprises the following steps: setting a port of a first detection device for connecting a client and a port for connecting an IP network AS an untrusted port, setting a port of a second device for connecting a service end AS an untrusted port, setting a port of the second device for connecting the IP network AS a trusted port, and analyzing client characteristics and bill characteristics of a message for KRB _ AS _ REP, KRB _ TGS _ REQ, KRB _ TGS _ REP and KRB _ AP _ REQ messages received from the untrusted port and KRB _ AS _ REP, KRB _ TGS _ REQ and KRB _ TGS _ REP messages received from the trusted port, and comparing the client characteristics and the bill characteristics with the recorded characteristics to prevent bill attacks; and directly forwarding the KRB _ AP _ REQ message received from the trust port without processing.

Preferably, the first detection device and the second detection device respectively include a receiving module, an analysis module, a processing module, and a sending module, wherein: the receiving module is used for receiving Kerberos protocol messages; the analysis module is used for analyzing the Kerberos protocol message received by the receiving module and delivering an analysis result to the processing module for processing; the processing module is used for checking or storing the content of the Kerberos protocol message analyzed by the analysis module and judging whether the message needs to be discarded or forwarded: a sending module, configured to forward the received Kerberos protocol packet

Compared with the prior art, the embodiment of the invention has the beneficial effects that: and recording the issued TGT and ST bills, comparing the bills used by the access end with the recorded bills during authentication, and judging whether bill forgery or other attacks exist. The method provided by the invention can accurately and effectively detect and prevent silver bill attack and gold bill attack in Kerberos authentication.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the embodiments of the present invention will be briefly described below. It is obvious that the drawings described below are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

FIG. 1 is a schematic diagram of a typical network for Kerberos authentication;

fig. 2 is a flowchart of a method for preventing a ticket attack in Kerberos authentication according to an embodiment of the present invention;

fig. 3 is a flowchart of a method for preventing a ticket attack in Kerberos authentication according to an embodiment of the present invention;

fig. 4 is a flowchart of a method for preventing a ticket attack in Kerberos authentication according to an embodiment of the present invention;

fig. 5 is a schematic diagram of an architecture of a device for preventing a ticket attack in Kerberos authentication according to an embodiment of the present invention;

fig. 6 is a schematic diagram of functional modules in a device for preventing a ticket attack in Kerberos authentication according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

The present invention is a system structure of a specific function system, so the functional logic relationship of each structural module is mainly explained in the specific embodiment, and the specific software and hardware implementation is not limited.

In addition, the technical features involved in the embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other. The invention will be described in detail below with reference to the figures and examples.

Kerberos authentication is an authentication mode based on Tickets (Tickets), if a Client (Kerberos Client) needs to access an Application Server (Application Server), a corresponding Ticket-service Ticket (Server Tickets, abbreviated as ST) needs to be obtained, but an authorization Ticket (Ticket grading, abbreviated as TGT) needs to be obtained first to obtain ST, and both TGT and ST are responsible for distribution by a Key distribution Center (Key distribution Center, abbreviated as KDC).

The complete Kerberos authentication process is divided into three phases:

(1) Authentication Service Exchange (AS Exchange for short): and the KRB _ AS _ REQ message is sent to the KDC by the Kerberos Client to apply for TGT, and the KRB _ AS _ REP message is replied after the KDC passes verification to carry the TGT distributed to the Kerberos Client.

(2) A Ticket Granting Service Exchange (TGS Exchange for short): and the KRB _ TGS _ REQ message is sent to the KDC by the Kerberos Client through the TGT obtained in the last stage to apply for the ST for accessing the Application Server, and the KRB _ TGS _ REP message returned after the verification of the KDC passes carries the ST distributed to the Kerberos Client.

(3) Client Server Exchange (Client/Server Exchange, CS Exchange for short): the Kerberos Client sends a KRB _ AP _ REQ message to the Application Server to submit the ST obtained in the last stage for authentication, and the Application Server replies the KRB _ AP _ REP message after verification passes.

In the CS Exchange phase, after receiving the ST sent by the Kerberos Client, the Application Server decrypts the ST by using the own master key, thereby obtaining the session key. The authentication code is then decrypted using the session key, thereby verifying the identity of the Kerberos Client. That is to say that the Application Server itself does not know what the session key is, it is obtained by decrypting the ST, so the core of this process credential lies in decrypting the master key of the Application Server used by the ST, if the Kerberos Client knows the master key of the Application Server, the ST can be forged. A ticket counterfeited in this way is called a silver ticket. The method of illegally passing the authentication Server through the method is called silver bill attack.

In the TGS Exchange stage, after receiving the TGT, the KDC decrypts the TGT by using the own master key to obtain a session key, and then decrypts the authentication code by using the session key for verification. That is, the KDC itself does not know what the session key is, it is derived by decrypting the TGT, so the core of this process credential is the KDC's master key used to decrypt the TGT, which can be forged if the Kerberos Client knows it. A ticket counterfeited in this way is called a gold ticket. Since Kerberos Client counterfeits a TGT that can be approved by a KDC, it can apply for an ST for any Application Server. The ST of the Application Server is illegally applied to the KDC through the mode, and therefore the gold bill attack is called through the mode of authentication of the Application Server.

Silver bill attack and gold bill attack can enable an attacker to have illegal access authority, and bring non-negligible influence on the increasingly serious network security problem.

Example 1:

a typical networking schematic diagram of Kerberos authentication is shown in FIG. 1, and includes a first device near a Kerberos Client end and a second device near an Application Server end. The first device and the second device are both devices with network communication functions, including but not limited to routers, switches and the like, and are mainly used for providing the Kerberos Client and the Application Server with the capability of accessing the IP network.

The normal Kerberos authentication scene is that when a Kerberos Client wants to access a certain Application Server, an ST for accessing the Application Server must be obtained first, then the Kerberos Client needs to obtain a TGT after authentication of a KDC, then the TGT is used for applying for accessing the ST of the Application Server, and finally the applied ST is used for obtaining the access right through authentication of the Application Server.

The first scenario of the bill attack is that if the Kerberos Client acquires the master key of a certain Application Server, a silver bill attack can be launched, that is, the authentication of the Application Server can be passed without interacting with the KDC, so that the access right of the Application Server is illegally obtained. Similarly, if the Kerberos Client acquires the master key of the KDC, a gold ticket attack can be launched, that is, the ST of any Application Server can be acquired by skipping the first authentication stage (AS Exchange), so that any Application Server can be illegally accessed.

The second scenario of the bill attack is that a certain Application Server may also serve as an attacker to launch a silver bill attack or a gold bill attack with the Client identity, and illegally acquire the right to access other Application servers.

As shown in fig. 2, the method for preventing a ticket attack in Kerberos authentication provided in the embodiment of the present invention includes the following specific steps.

Step 101: when the KDC issues the bill, the client characteristics of the application bill and the bill characteristics issued by the KDC are recorded.

In this embodiment, when issuing a ticket, the KDC synchronously records the issued ticket and the client-side characteristics of the application ticket, so as to facilitate subsequent comparison and determination. To be able to defend against both white and gold ticket attacks, it is necessary to record both TGT and ST tickets.

When the client applies for the bill for the first time, the client and the bill are not recorded. At this time, the client characteristics and the ticket characteristics issued by the KDC need to be added to the record. The client side is prevented from disguising attacks by recording the client side characteristics, and the bill forgery attacks are prevented by recording the bill characteristics.

When the client does not apply for the bill for the first time, the client characteristics are stored in the record, and the bill characteristics corresponding to the client characteristics are updated by using the bill characteristics issued by the KDC, so that malicious users are prevented from using the invalid bill for authentication.

After the client applies for the bill for the first time, the client characteristics are reserved in the record, and whether the client applies for the bill or not can be judged by comparing the client characteristics in the authentication message with the client characteristics in the record. Specifically, the client characteristics in the message are analyzed, whether the record contains the corresponding client characteristics is inquired, and when the record does not contain the client characteristics in the message, the client is indicated to apply for the bill for the first time.

In the specific implementation process, the data sheet can be used for completing the recording of the bill characteristics.

(1) A first data table: and the KRB _ AS _ MONITOR table is used for recording the TGT information acquired by the Kerberos Client from the KDC. The data table has three fields:

a first field: realm. Represents a Kerberos domain;

a second field: cname. Representing the identification of the Kerberos Client, namely the Client characteristic of the application bill.

A third field: tgt. Represents the TGT obtained by Kerberos Client from KDC.

(2) A second data table: and the KRB _ TGS _ MONITOR table is used for recording ST information applied by Kerberos Client from KDC. The data table has three fields:

a first field: realm (r) is added. Represents a Kerberos domain;

a second field: a name. The identification of the Application Server which the Kerberos Client needs to access is represented;

a third field: st. Represents the ST required by Kerberos Client to apply from KDC to access Application Server.

Furthermore, in order to further prevent the bill features from being stolen, the contents of the TGT and ST acquired from the message are encrypted ciphertexts, and the ciphertexts are directly stored in the record. The first data table records the bill characteristics encrypted by using the master key of the KDC, and the second data table records the bill characteristics encrypted by using the master key of the Application Server. In practical implementation scenarios, other secure encryption methods may be used for encryption. Step 102: and acquiring the client characteristics and the bill characteristics in the message, inquiring whether the bill characteristics corresponding to the client are consistent with the bill characteristics issued by the KDC, and judging the type of the attack according to the inquiry result or carrying out corresponding forwarding.

The authentication message of the client includes the client characteristics of the application ticket and the ticket applied by the client. When authentication is carried out, the client characteristics and the bill characteristics in the message are analyzed, the bill characteristics corresponding to the same client characteristics in the record are inquired, the bill characteristics in the message are compared with the inquired bill characteristics, and whether the bill characteristics are consistent or not is judged. If the record does not contain the corresponding client characteristics, the client does not apply for the bill on the KDC, and related attacks of client forgery may exist; if the bill characteristics in the record are inconsistent with the client characteristics, the bill is not issued by the KDC, and attacks related to bill counterfeiting may exist.

After the steps 101 to 102 provided in this embodiment, the client and the ticket forgery type attack are avoided by recording the client characteristics and the ticket characteristics when the KDC issues the ticket and performing secondary comparison when performing ticket authentication.

In a practical implementation scenario, for TGT and ST tickets,

as shown in fig. 3, for TGT tickets, the following steps can be used to accomplish the recording and comparison of client characteristics and ticket characteristics.

Step 201: the Client characteristics comprise a Kerberos domain and a Kerberos Client identifier, and the bill characteristics are TGTs acquired by the Kerberos Client from the KDC.

And setting a port of the first device connected with the Kerberos Client and a port connected with the IP network AS an untrusted port, and analyzing partial contents of messages to be detected or stored for KRB _ AS _ REP, KRB _ TGS _ REQ, KRB _ TGS _ REP and KRB _ AP _ REQ messages received from the untrusted port.

And receiving the KRB _ AS _ REQ message, and directly forwarding without processing.

Receiving a KRB _ AS _ REP message sent by a KDC, analyzing the contents of three fields of a Kerberos domain, a Client identifier and a TGT from the message, then using the contents of the two fields of the analyzed Kerberos domain and the Client identifier to query in a first data table, and if a first table item can be queried, replacing the content of a third field of the first table item with the content of the analyzed TGT field; otherwise, a new entry is added in the first data table, the content of the first field of the entry is the content of the analyzed Kerberos field, the content of the second field of the entry is the content of the analyzed Client identification field, and the content of the third field of the entry is the content of the analyzed TGT field. And finally forwarding the KRB _ AS _ REP message to a Kerberos Client.

Step 202: and when the TGT in the message is inconsistent with the TGT in the record, the gold bill attack suspicion exists in the message.

Receiving a KRB _ TGS _ REQ message sent by a Kerberos Client, analyzing the contents of two fields of a Kerberos domain and a TGT from the message, then using the contents of the two fields to query in a first data table, and if the contents of the two fields can be queried to record, forwarding the message to an IP network; otherwise, the result shows that the Kerberos Client does not pass through AS Exchange, attempts to forge TGT directly, and has the suspicion of gold bill attack, so the message is discarded.

Receiving a KRB _ TGS _ REP message sent by a KDC, analyzing the contents of three fields of a Kerberos domain, an Application Server identifier and an ST from the message, then using the contents of the two fields of the analyzed Kerberos domain and the Application Server identifier to query in a second data table, and if a first table entry can be queried, replacing the content of a third field of the first table entry with the content of the analyzed ST field; otherwise, a new entry is added in the second data table, the content of the first field of the entry is the content of the analyzed Kerberos field, the content of the second field of the entry is the content of the analyzed Application Server identification field, and the content of the third field of the entry is the content of the analyzed ST field. And finally forwarding the KRB _ TGS _ REP message to a Kerberos Client.

Receiving a KRB _ AP _ REQ message sent by a Kerberos Client, analyzing the contents of three fields of a Kerberos domain, an Application Server identifier and ST from the message, then using the contents of the three fields to inquire in a second data table, if the contents of the three fields can inquire records, forwarding the message to an IP network, otherwise, the Kerberos Client does not pass through AS Exchange and TGS Exchange, trying to forge ST directly, and having the suspicion of silver bill attack, thus discarding the message.

And receiving the KRB _ AP _ REP message, and directly forwarding without processing.

Steps 201-202 may be applied to the first device in fig. 1, which is capable of addressing a first scenario of a ticket attack.

As shown in fig. 4, for ST tickets, the recording and comparison of client characteristics and ticket characteristics can be accomplished using the following steps.

Step 301: the Client characteristics comprise a Kerberos domain and an identification of an Application Server which the Kerberos Client needs to access, and the bill characteristics are the ST which the Kerberos Client applies from the KDC and is needed by accessing the Application Server.

Setting a port of the second equipment connected with the Application Server AS an untrusted port, and analyzing partial contents of messages of KRB _ AS _ REP, KRB _ TGS _ REQ, KRB _ TGS _ REP and KRB _ AP _ REQ messages received from the untrusted port for detection or storage; setting a port of the second device connected with the IP network AS a trusted port, and analyzing partial contents of messages for KRB _ AS _ REP, KRB _ TGS _ REQ and KRB _ TGS _ REP messages received from the trusted port for detection or storage; and directly forwarding the KRB _ AP _ REQ message received from the trust port without processing.

And receiving the KRB _ AS _ REQ message, and directly forwarding without processing.

Receiving a KRB _ AS _ REP message sent by a KDC, analyzing the contents of three fields of a Kerberos domain, a Client identifier and a TGT from the message, then using the contents of the two fields of the analyzed Kerberos domain and the Client identifier to query in a first data table, and if a first table item can be queried, replacing the content of a third field of the first table item with the content of the analyzed TGT field; otherwise, a new entry is added in the first data table, the content of the first field of the entry is the content of the analyzed Kerberos field, the content of the second field of the entry is the content of the analyzed Client identification field, and the content of the third field of the entry is the content of the analyzed TGT field. And finally forwarding the KRB _ AS _ REP message.

Step 302: and when the ST in the message is inconsistent with the ST in the record, the suspicion of silver bill attack exists in the message.

Receiving a KRB _ TGS _ REQ message, analyzing the contents of two fields of a Kerberos domain and a TGT from the message, then using the contents of the two fields to query in a first data table, and if the contents of the two fields can be queried to record, forwarding the message to an IP network; otherwise, the attacker does not go through AS Exchange and tries to forge TGT directly, so that the gold bill attack suspicion exists, and the message is discarded.

Receiving a KRB _ TGS _ REP message sent by a KDC, analyzing the contents of three fields of a Kerberos domain, an Application Server identifier and an ST from the message, then using the contents of the two fields of the analyzed Kerberos domain and the Application Server identifier to query in a second data table, and if a first table entry can be queried, replacing the content of a third field of the first table entry with the content of the analyzed ST field; otherwise, a new entry is added in the second data table, the content of the first field of the entry is the content of the analyzed Kerberos field, the content of the second field of the entry is the content of the analyzed Application Server identification field, and the content of the third field of the entry is the content of the analyzed ST field. And finally, forwarding the KRB _ TGS _ REP message.

Receiving a KRB _ AP _ REQ message, if the KRB _ AP _ REQ message comes from an untrusted port, analyzing the contents of three fields of a Kerberos domain, an Application Server identifier and an ST from the message, then using the contents of the three fields to inquire in a second data table, if the contents of the three fields can inquire a record, forwarding the message to an IP network, otherwise, indicating that an attacker does not pass through AS Exchange and TGS Exchange, trying to forge the ST directly, and having the suspicion of silver bill attack, thus discarding the message; and if the KRB _ AP _ REQ message is sent to the trusted port, directly forwarding the KRB _ AP _ REQ message.

And receiving the KRB _ AP _ REP message, and directly forwarding without processing.

Steps 301-302 may be applied to the second device in fig. 1, capable of addressing a second scenario of a ticket attack.

The method for preventing the bill attack in the Kerberos authentication provided by the embodiment can detect the silver bill attack and the gold bill attack without changing the Kerberos authentication protocol, and can prevent the adverse effect possibly caused by the attack by discarding the message and the like under the condition that the possible attack exists. The method provided by the implementation can not change the Kerberos authentication protocol and the interaction process of normal authentication, is safer and more reliable compared with the traditional defense means, and does not need to rely on means which cannot be used for ever, such as password modification and the like, to ensure the system safety. Meanwhile, the method provided by the invention can monitor the Kerberos authentication process in real time, and the detection and the attack prevention are carried out in real time, so that the timeliness is higher.

Example 2:

based on the method for preventing the bill attack in the Kerberos authentication provided in embodiment 1, specific defense processes against various attacks in some practical application scenarios are provided in this embodiment.

This embodiment describes the technical solution in embodiment 1 in detail based on the networking schematic diagram shown in fig. 1. The first equipment is connected with a Kerberos Client 1 through a port 1, the first equipment is connected with an IP network through a port 2, and the port 1 and the port 2 are set as non-trusted ports; the second device is connected with the IP network through a port 3, the second device is connected with the Application Server 1 through a port 4, the second device is connected with the Application Server 2 through a port 5, the port 4 and the port 5 are set as non-trust ports, and the port 3 is set as a trust port.

(1) Application scenario one

Kerberos Client 1 illegally obtains the master key of KDC, and forges TGT to try to launch gold bill attack. In this application scenario, the method of embodiment 1 may complete the identification and defense of attacks through the following steps.

Step 1, kerberos Client 1 sends KRB _ TGS _ REQ message by using forged TGT;

step 2, after receiving a KRB _ TGS _ REQ message sent by a Kerberos Client 1, the first device analyzes the contents of two fields of a Kerberos domain and a TGT;

step 3, querying in a first data table by using the contents of the two fields of the Kerberos domain and the TGT analyzed in the step 2, wherein no record can be queried in the first data table because the TGT used by the Kerberos Client 1 is not applied by AS Exchange;

and 4, the first equipment judges that the KRB _ TGS _ REQ message sent by the Kerberos Client 1 has gold bill attack suspicion, and selects to discard the message.

(2) Application scenario two

Kerberos Client 1 illegally obtains the master key of Application Server 1, and fake ST tries to launch silver bill attack. In this application scenario, the method of embodiment 1 may complete the identification and defense against attacks through the following steps.

Step 1, kerberos Client 1 sends KRB _ AP _ REQ message by using forged ST;

step 2, after receiving a KRB _ AP _ REQ message sent by a Kerberos Client 1, the first equipment analyzes the contents of three fields of a Kerberos domain, an Application Server identifier and an ST;

step 3, the contents of three fields of the Kerberos domain, the Application Server identifier and the ST analyzed in the step 2 are used for inquiring in a second data table, and because the ST used by the Kerberos Client 1 is not applied by AS Exchange and TGS Exchange, no record can be inquired in the second data table;

and 4, the first equipment judges that the KRB _ AP _ REQ message sent by the Kerberos Client 1 has silver bill attack suspicion, and selects to discard the message.

(3) Application scenario three

Kerberos Client 1 applies for authentication of Application Server 1 to the KDC using a standard Kerberos authentication procedure. In this application scenario, the method of embodiment 1 may complete the identification and defense against attacks through the following steps.

Step 1, kerberos Client 1 sends KRB _ AS _ REQ message application TGT to KDC, and first equipment directly forwards the KRB _ AS _ REQ message to an IP network;

step 2, after receiving a KRB _ AS _ REP message replied to Kerberos Client 1 by a KDC, the first equipment analyzes the contents of three fields of a Kerberos domain, a Client identifier and a TGT; the contents of the three fields are used for inquiring in a first data table, if the Kerberos Client 1 is authenticated by applying for the first time, records cannot be inquired in the first data table, so that an entry is newly added in the first data table, the contents of the first field of the entry are the contents of the analyzed Kerberos field, the contents of the second field of the entry are the contents of the analyzed Client identification field, and the contents of the third field of the entry are the contents of the analyzed TGT field; if the Kerberos Client 1 does not apply for authentication of the Application Server 1 for the first time, the first table entry can be queried in the first data table, and therefore the third field content of the first table entry is replaced by the content of the TGT field. Then, the first device forwards the KRB _ AS _ REP message to a Kerberos Client 1;

step 3, after receiving the KRB _ AS _ REP message, the Kerberos Client 1 sends a KRB _ TGS _ REQ message to the KDC to apply for accessing the ST of the Application Server 1, after receiving the KRB _ TGS _ REQ message, the first device analyzes the contents of two fields of a Kerberos domain and a TGT, and then uses the contents of the two fields to query in a first data table, and since the corresponding table entries are stored in the step 2, records can be queried, so that the KRB _ TGS _ REQ message is forwarded to the IP network;

step 4, after receiving a KRB _ TGS _ REP message replied to Kerberos Client 1 by a KDC, the first equipment analyzes the contents of three fields of a Kerberos domain, an Application Server identifier and an ST; querying in a second data table by using the contents of the three fields, and if the Kerberos Client 1 is the authentication of the Application Server 1 which is applied for the first time, querying in the second data table to obtain no record, so that an entry is newly added in the second data table, the content of the first field of the entry is the content of the Kerberos field, the content of the second field of the entry is the content of the Application Server identification field, and the content of the third field of the entry is the content of the ST field; if the Kerberos Client 1 does not apply for authentication of the Application Server 1 for the first time, the first table entry can be inquired in the second data table, and therefore the third field content of the first table entry is replaced by the ST field content. Then, the first device forwards the KRB _ TGS _ REP message to Kerberos Client 1;

step 5, after receiving the KRB _ TGS _ REP message, the Kerberos Client 1 sends a KRB _ AP _ REQ message to the Application Server 1 to apply for the verification of the Application Server 1, after receiving the KRB _ AP _ REQ message, the first device analyzes the content of a Kerberos domain, the identification of the Application Server and the ST three fields, and then uses the content of the three fields to inquire in a second data table, and as the corresponding table entries are stored in the step 4, the KRB _ AP _ REQ message can be inquired to a record, so that the KRB _ AP _ REQ message is forwarded to the IP network;

and 6, after receiving the KRB _ AP _ REQ forwarded by the IP network from the port 3, the second equipment judges that the message is from the trusted port, so that the message is directly forwarded to the Application Server 1, and finally the Application Server 1 verifies the identity of the Kerberos Client 1 successfully.

(4) Application scenario four

The Application Server 2 illegally obtains the master key of KDC, and forges TGT to try to launch gold bill attack. In this application scenario, the method of embodiment 1 may complete the identification and defense against attacks through the following steps.

Step 1, the application Server 2 uses the forged TGT to send KRB _ TGS _ REQ message;

step 2, after the second device receives the KRB _ TGS _ REQ message sent by the Application Server 2 from the port 5, because the port 5 is an untrusted port, the contents of two fields of a Kerberos domain and a TGT are analyzed;

step 3, the contents of two fields of Kerberos domain and TGT analyzed in the step 2 are used for inquiring in the first data table, and AS the TGT used by the Application Server 2 is not applied by AS Exchange, no record can be inquired in the first data table;

and 4, the second equipment judges that the KRB _ TGS _ REQ message sent by the Application Server 2 has gold bill attack suspicion, and selects to discard the message.

(5) Application scenario five

The Application Server 2 illegally obtains the master key of the Application Server 1, and forges ST to try to launch silver bill attack. In this application scenario, the method of embodiment 1 may complete the identification and defense against attacks through the following steps.

Step 1, an application Server 2 sends a KRB _ AP _ REQ message by using a forged ST;

step 2, after receiving the KRB _ AP _ REQ message sent by the Application Server 2 from the port 5, the second equipment analyzes the contents of a Kerberos domain, an identifier of the Application Server and an ST field;

step 3, the contents of the Kerberos domain, the Application Server identifier and the ST three fields analyzed in the step 2 are used for inquiring in a second data table, and the ST used by the Application Server 2 is not applied by AS Exchange and TGS Exchange, so that no record can be inquired in the second data table;

and 4, the second equipment judges that the KRB _ AP _ REQ message sent by the Application Server 2 has silver bill attack suspicion, and selects to discard the message.

(6) Application scenario six

The Application Server 2 applies for authentication of the Application Server 1 to the KDC using a standard Kerberos authentication procedure. In this application scenario, the method of embodiment 1 may complete the identification and defense of attacks through the following steps.

Step 1, an application Server 2 sends a KRB _ AS _ REQ message to a KDC to apply for TGT, and a second device directly forwards the KRB _ AS _ REQ message to an IP network;

step 2, after receiving a KRB _ AS _ REP message replied to the Application Server 2 by the KDC, the second equipment analyzes the contents of three fields of a Kerberos domain, a Client identifier and a TGT; the contents of the three fields are used for inquiring in a first data table, if the Application Server 2 applies for authentication of the Application Server 1 for the first time, no record can be inquired in the first data table, so that an entry is newly added in the first data table, the contents of the first field of the entry are the contents of the analyzed Kerberos field, the contents of the second field of the entry are the contents of the analyzed Client identification field, and the contents of the third field of the entry are the contents of the analyzed TGT field; if the Application Server 2 does not apply for the authentication of the Application Server 1 for the first time, the first entry can be queried in the first data table, so the third field content of the first entry is replaced by the content of the TGT field. Then, the second device forwards the KRB _ AS _ REP message to the Application Server 2;

step 3, after receiving the KRB _ AS _ REP message, the Application Server 2 sends a KRB _ TGS _ REQ message to the KDC to apply for accessing the ST of the Application Server 1, and after receiving the KRB _ TGS _ REQ message, the second equipment analyzes the contents of two fields of a Kerberos domain and a TGT, and then uses the contents of the two fields to inquire in a first data table, and because the corresponding table entry is stored in the step 2, the record can be inquired, so that the KRB _ TGS _ REQ message is forwarded to the IP network;

step 4, after receiving a KRB _ TGS _ REP message replied to the Application Server 2 by the KDC, the second equipment analyzes the contents of a Kerberos domain, an identifier of the Application Server and an ST field; the contents of the three fields are used for inquiring in a second data table, if the Application Server 2 is the authentication of the first Application Server 1, the record cannot be inquired in the second data table, so that an entry is newly added in the second data table, the content of the first field of the entry is the content of a Kerberos field, the content of the second field of the entry is the content of an identification field of the Application Server, and the content of the third field of the entry is the content of an ST field; if the Application Server 2 does not apply for the authentication of the Application Server 1 for the first time, the first entry can be looked up in the second data table, so the third field content of the first entry is replaced by the ST field content. Then, the second device forwards the KRB _ TGS _ REP message to the Application Server 2;

step 5, after receiving the KRB _ TGS _ REP message, the Application Server 2 sends a KRB _ AP _ REQ message to the Application Server 1 to apply for the verification of the Application Server 1, after receiving the KRB _ AP _ REQ message from the port 5, the second device judges that the message comes from an untrusted port, so that the contents of a Kerberos domain, an identification of the Application Server and ST three fields are analyzed, and then the contents of the three fields are used for inquiring in a second data table, and as the corresponding table entries are already stored in the step 4, the KRB _ AP _ REQ message can be inquired to a record, so that the KRB _ AP _ REQ message is forwarded to the Application Server 1. And finally, the Application Server 1 verifies the identity of the Application Server 2 successfully.

It can be seen from the above examples that the method for preventing a ticket attack in Kerberos authentication provided in embodiment 1 can identify a ticket attack in various actual scenes, and perform corresponding processing, thereby defending against a silver ticket attack and a gold ticket attack which may exist, and timely and effectively preventing loss caused by the attack.

Example 3:

on the basis of the method for preventing the bill attack in the Kerberos authentication provided in the embodiments 1 to 2, the invention also provides a system for preventing the bill attack in the Kerberos authentication, which can be used for realizing the method.

Fig. 5 is a schematic diagram of a device architecture according to an embodiment of the present invention. The system comprises a client, a first detection device, a second detection device, a KDC and an application server. Kerberos authentication is used between the client and the application server for access verification, KDC issues bills, and the KDC and the application server authenticate the client. The first detection device and the second detection device originally only provide a network access function for the client and the application server, but do not have an authentication function.

The client is connected with the IP network through the first detection device, the application server is connected with the IP network through the second detection device, and the KDC is connected with the IP network. The first detection device and the second detection device are both devices with network communication functions, including but not limited to routers, switches and the like, and mainly function to provide the capability of accessing the IP network for the client and the application server.

The first detection device processes the interactive message between the client and the IP network according to the method for preventing a ticket attack in Kerberos authentication provided in embodiment 1, and prevents a ticket attack initiated by the client. Namely, the ticket authentication and attack prevention related to the first scenario in embodiment 1 and embodiment 2 are handled.

The second detection device receives the packet exchanged between the server and the IP network according to the method for preventing a ticket attack in Kerberos authentication provided in embodiment 1, and prevents a ticket attack initiated by the server. Namely, the ticket authentication and attack prevention related to the second scenario in embodiment 1 and embodiment 2 are handled.

In practical implementation, in order to reduce data processing amount and improve processing efficiency, a port which is not attacked in network connection may be used as a trusted port, a port which may be attacked may be used as an untrusted port, different ports and packets are classified, and only the port and packet which may be attacked are processed. Specifically, the method comprises the following steps: setting a port of the first detection device connected with the client and a port connected with the IP network as non-trusted ports, setting a port of the second device connected with the service end as a non-trusted port, and setting a port of the second device connected with the IP network as a trusted port. For KRB _ AS _ REP, KRB _ TGS _ REQ, KRB _ TGS _ REP and KRB _ AP _ REQ messages received from the untrusted port and KRB _ AS _ REP, KRB _ TGS _ REQ and KRB _ TGS _ REP messages received from the trusted port, analyzing client-side characteristics and bill characteristics of the messages, and comparing the client-side characteristics and the bill characteristics with the recorded characteristics to prevent bill attacks; and directly forwarding the KRB _ AP _ REQ message received from the trust port without processing.

In order to complete the functions of receiving, analyzing, judging attack, forwarding, etc. of the packet in the method of embodiment 1, the first detection device and the second detection device also need to include a plurality of functional modules. As shown in fig. 6, the device includes a receiving module, a parsing module, a processing module and a sending module.

The receiving module is used for receiving Kerberos protocol messages.

And the analysis module is used for analyzing the Kerberos protocol message received by the receiving module and delivering an analysis result to the processing module for processing.

And the processing module is used for checking or storing the content of the Kerberos protocol message analyzed by the analysis module and judging whether the message needs to be discarded or forwarded.

And the sending module is used for forwarding the received Kerberos protocol message.

In a specific implementation scenario, the first detection device and the second detection device may complete the method provided in embodiment 1 by executing functions of each module.

The module is applied to the first detection device and can solve the first scene of bill attack.

(1) A receiving module, configured to receive a Kerberos protocol packet:

for KRB _ AS _ REP, KRB _ TGS _ REQ, KRB _ TGS _ REP and KRB _ AP _ REQ messages, the messages are sent to an analysis module for processing;

and directly handing KRB _ AS _ REQ and KRB _ AP _ REP messages to a sending module for processing.

(2) The analysis module is used for analyzing the Kerberos protocol message received by the receiving module and delivering an analysis result to the processing module for processing:

for a KRB _ AS _ REP message, the contents of three fields of a Kerberos domain, a Client identifier and a TGT need to be analyzed;

for a KRB _ TGS _ REQ message, the contents of two fields of a Kerberos domain and a TGT are required to be analyzed;

for a KRB _ TGS _ REP or KRB _ AP _ REQ message, the contents of three fields of a Kerberos domain, an Application Server identifier and an ST need to be analyzed.

(3) The processing module is used for checking or storing the content of the Kerberos protocol message analyzed by the analysis module and judging whether the message needs to be discarded or sent:

for the contents of three fields of a Kerberos field, a Client identifier and a TGT in a KRB _ AS _ REP message, querying in a first data table by using the contents of the two fields of the Kerberos field and the Client identifier, and if a first entry can be queried, replacing the content of a third field of the first entry with the content of the TGT field; otherwise, a table entry is newly added in the first data table, the content of a first field of the table entry is the content of a Kerberos field, the content of a second field of the table entry is the content of a Client identification field, and the content of a third field of the table entry is the content of a TGT field;

querying the contents of two fields of a Kerberos domain and a TGT in the KRB _ TGS _ REQ message in a first data table by using the contents, marking that the KRB _ TGS _ REQ message has gold bill attack suspicion if the query is not recorded, and discarding the KRB _ TGS _ REQ message;

for the contents of three fields of a Kerberos field, an Application Server identifier and an ST in a KRB _ TGS _ REP message, the contents of two fields of the Kerberos field and the Application Server identifier are used for inquiring in a second data table, and if a first table entry can be inquired, the content of a third field of the first table entry is replaced by the content of the ST field; otherwise, a new entry is added in the second data table, the content of the first field of the entry is the content of the Kerberos field, the content of the second field of the entry is the content of the Application Server identification field, and the content of the third field of the entry is the content of the ST field;

and for the contents of three fields of a Kerberos domain, an Application Server identifier and an ST in the KRB _ AP _ REQ message, using the KRB _ AP _ REQ message to query in a second data table, marking the KRB _ AP _ REQ message as suspected of silver bill attack if the query is not recorded, and discarding the KRB _ AP _ REQ message.

(4) A sending module, configured to forward the received Kerberos protocol packet:

directly forwarding KRB _ AS _ REQ and KRB _ AP _ REP messages;

for KRB _ AS _ REP and KRB _ TGS _ REP messages, the messages are forwarded after being successfully processed by the processing module;

for the KRB _ TGS _ REQ message, if the KRB _ TGS _ REQ message is not marked as the suspicion of gold bill attack by the processing module, the KRB _ TGS _ REQ message is forwarded;

and for the KRB _ AP _ REQ message, if the KRB _ AP _ REQ message is not marked as the suspicion of silver bill attack by the processing module, the KRB _ AP _ REQ message is forwarded.

The module is applied to the second detection device and can solve the first scene of bill attack.

(1) A receiving module, configured to receive a Kerberos protocol packet:

for KRB _ AS _ REP, KRB _ TGS _ REQ and KRB _ TGS _ REP messages, the messages are delivered to an analysis module for processing;

for KRB _ AP _ REQ messages, if the messages come from the untrusted port, the messages are sent to an analysis module for processing, and if the messages come from the trusted port, the messages are directly sent to a sending module for processing;

and directly handing KRB _ AS _ REQ and KRB _ AP _ REP messages to a sending module for processing.

(2) And the analysis module has the same function as the analysis module of the first detection device.

(3) And the processing module has the same function as the processing module of the first detection device.

(4) And the sending module has the same function as the sending module of the first detection device.

As can be seen from the above description, the present embodiment provides a system. The method for preventing a ticket attack in Kerberos authentication provided in embodiment 1 can be implemented.

The system provided by the embodiment does not need to use additional hardware equipment or deploy an additional software platform, and the main body participating in authentication does not sense the existence of the system. And the deployment and installation are also simpler, additional equipment and network connection are not needed to be added, only the access layer equipment close to the Kerberos Client and the Application Server is needed to be deployed or replaced, and the convergence layer and the core layer are not affected.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents and improvements made within the spirit and principle of the present invention are intended to be included within the scope of the present invention.

Claims (10)

1. A method for preventing bill attack in Kerberos authentication is characterized in that:

when the KDC issues the bill, recording the client characteristics of the application bill and the bill characteristics issued by the KDC, wherein the bill comprises TGT and ST;

and acquiring the client characteristics and the bill characteristics in the message, inquiring whether the bill characteristics corresponding to the client are consistent with the bill characteristics issued by the KDC, and judging the type of the attack according to the inquiry result or carrying out corresponding forwarding.

2. The method for preventing bill attack in Kerberos authentication according to claim 1, wherein the recording of the client characteristics of the application bill and the bill characteristics issued by the KDC specifically comprises:

for TGT, the Client characteristics comprise a Kerberos domain and a Kerberos Client identifier, and the bill characteristics are the TGT acquired by the Kerberos Client from KDC;

for ST, the Client characteristics comprise a Kerberos domain and an identification of an Application Server which the Kerberos Client needs to access, and the bill characteristics are the ST which the Kerberos Client applies for from the KDC and is needed for accessing the Application Server.

3. The method for preventing bill attack in Kerberos authentication as claimed in claim 1, wherein the recording of the client characteristics of the application bill and the bill characteristics issued by the KDC further comprises:

for TGT, recording the bill characteristics which are encrypted by using the master key of KDC;

for ST, the ticket features that have been encrypted using the master key of the Application Server are recorded.

4. The method for preventing bill attack in Kerberos authentication as claimed in claim 1, wherein the recording of the client characteristics of the application ticket and the ticket characteristics issued by the KDC further comprises:

when the client applies for the bill for the first time, adding the client characteristics and the bill characteristics issued by the KDC into the record;

and when the client does not apply for the bill for the first time, updating the bill characteristic corresponding to the client characteristic by using the bill characteristic issued by the KDC.

5. The method for preventing the bill attack in Kerberos authentication according to claim 4, further comprising:

analyzing the client characteristics in the message, inquiring whether the record contains the corresponding client characteristics, and indicating that the client applies for the bill for the first time when the record does not contain the client characteristics in the message.

6. The method for preventing bill attack in Kerberos authentication according to claim 1, wherein the querying whether the bill feature corresponding to the client is consistent with the bill feature issued by the KDC specifically comprises:

analyzing the client characteristics and the bill characteristics in the message, inquiring the bill characteristics corresponding to the same client characteristics in the record, comparing the bill characteristics in the message with the inquired bill characteristics, and judging whether the bill characteristics are consistent or not.

7. The method for preventing bill attack in Kerberos authentication according to claim 1, wherein the judging the type of attack according to the query result specifically comprises:

when the TGT in the message is inconsistent with the TGT in the record, the gold bill attack suspicion exists in the message;

and when the ST in the message is inconsistent with the ST in the record, the suspicion of silver bill attack exists in the message.

8. The system for preventing bill attack in Kerberos authentication is characterized by comprising a client, a first detection device, a second detection device, a KDC and an application server, and specifically comprises the following steps:

the client is connected with the IP network through first detection equipment, the application server is connected with the IP network through second detection equipment, and the KDC is connected with the IP network;

the first detection device processes the interactive message between the client and the IP network according to the method for preventing the bill attack in the Kerberos authentication provided by any one of claims 1 to 7, and prevents the bill attack initiated by the client;

the second detection device receives the method for preventing the bill attack in the Kerberos authentication provided by any one of claims 1 to 7, processes the interactive message between the server and the IP network, and prevents the bill attack initiated by the server.

9. The system for preventing ticket attacks in Kerberos authentication of claim 8, further comprising:

setting a port of the first detection device connected with the client and a port connected with the IP network as non-trusted ports, setting a port of the second device connected with the service end as a non-trusted port, setting a port of the second device connected with the IP network as a trusted port,

for KRB _ AS _ REP, KRB _ TGS _ REQ, KRB _ TGS _ REP and KRB _ AP _ REQ messages received from the untrusted port and KRB _ AS _ REP, KRB _ TGS _ REQ and KRB _ TGS _ REP messages received from the trusted port, analyzing client-side characteristics and bill characteristics of the messages, and comparing the client-side characteristics and the bill characteristics with the recorded characteristics to prevent bill attacks;

and directly forwarding the KRB _ AP _ REQ message received from the trust port without processing.

10. The system for preventing bill attack in Kerberos authentication as recited in claim 8, wherein the first detection device and the second detection device respectively comprise a receiving module, a parsing module, a processing module and a sending module, wherein:

the receiving module is used for receiving Kerberos protocol messages;

the analysis module is used for analyzing the Kerberos protocol message received by the receiving module and delivering an analysis result to the processing module for processing;

the processing module is used for checking or storing the content of the Kerberos protocol message analyzed by the analysis module and judging whether the message needs to be discarded or forwarded:

and the sending module is used for forwarding the received Kerberos protocol message.

Images