CN106101079A - 一种实现签名加密的方法和*** - Google Patents
一种实现签名加密的方法和*** Download PDFInfo
- Publication number
- CN106101079A CN106101079A CN201610377866.3A CN201610377866A CN106101079A CN 106101079 A CN106101079 A CN 106101079A CN 201610377866 A CN201610377866 A CN 201610377866A CN 106101079 A CN106101079 A CN 106101079A
- Authority
- CN
- China
- Prior art keywords
- service request
- rule
- new
- client
- malicious attack
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
一种实现签名的方法和***,包括:若第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值,则根据第一预设时间内接收到的业务请求判断出当前是否存在恶意攻击,若存在恶意攻击,则根据预设的生成规则生成新的加密信息;当接收到来自客户端的业务请求时,根据新的加密信息对业务请求进行加密验证。通过本发明实施例的方案,在检测到当前存在恶意攻击时,生成新的加密信息来避免继续受到恶意攻击,从而减少了服务端宕机的可能性。
Description
技术领域
本文涉及但不限于互联网技术,尤指一种实现签名加密的方法和***。
背景技术
当前互联网处于蓬勃发展阶段,热门应用不断涌现,吸纳了众多网民流量,从而给应用生产者带来了丰厚的经济效益。火爆的应用不仅吸引了网民的眼球,同样也会带来一些不怀好意的目光,那就是网络恶意破坏者——黑客。
出于对应用保护的目的,应用生产者会采取一些策略来抵挡来自黑客的恶意攻击,最常见的就是在客户端对超文本传送协议(HTTP,Hypertext Transfer Protocol)请求进行静态签名加密,即客户端按照预设规则和预先设置的公钥生成签名,并对生成的签名进行加密后发送给服务端,然后在服务端对加密后的签名进行解密,匹配自身按照预设规则和预先设置的公钥生成的签名和解密得到的签名,如果匹配,则对HTTP请求进行业务处理,如果不匹配,则丢弃HTTP请求。
上述静态签名加密方法能够在一定程度上抵御恶意攻击,保障服务端正常运行。但是一旦静态签名加密的预设规则和公钥被黑客破解获得,则黑客可以随意对服务端进行“泛洪”式网络攻击,超额的攻击请求可以在短时间内让服务端出现高负载,轻则无法继续向其他普通用户提供正常服务,重则直接将服务端拖垮宕机。
发明内容
为了解决上述问题,本发明实施例提出了一种实现签名加密的方法和***,能够减少服务端宕机的可能性。
为了达到上述目的,本发明实施例提出了一种实现签名加密的方法,包括:
若第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值,则根据第一预设时间内接收到的业务请求判断出当前是否存在恶意攻击,若存在恶意攻击,则根据预设的生成规则生成新的加密信息;
当接收到来自客户端的业务请求时,根据新的加密信息对业务请求进行加密验证。
可选的,所述根据第一预设时间内接收到的业务请求判断出当前存在恶意攻击后,还包括:
将所述存在恶意攻击的客户端信息保存至预设的黑名单中。
可选的,所述接收到来自客户端的业务请求后,根据新的加密信息对业务请求进行加密验证之前还包括:
判断出发送所述业务请求的客户端不存在所述黑名单中。
可选的,所述新的加密信息包括新的公钥、新的用于生成签名的规则和新的加密规则;
其中,所述新的公钥的长度不限;
所述新的用于生成签名的规则包括:每一个业务参数的排列规则、业务参数的排序规则和当前时间戳生成规则。
可选的,该方法还包括:
当接收到所述客户端发送的获取请求时,将所述新的加密信息发送给所述客户端。
本发明实施例还提出了一种实现签名加密的***,包括:
判断单元,用于当第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值时,根据第一预设时间内接收到的业务请求判断出当前是否存在恶意攻击;
生成单元,用于当存在恶意攻击时,根据预设的生成规则生成新的加密信息;
验证单元,用于当接收到来自客户端的业务请求时,根据新的加密信息对业务请求进行加密验证。
可选的,还包括:
处理单元,用于将所述存在恶意攻击的客户端信息保存至预设的黑名单中。
可选的,所述验证单元具体用于:
当接收到来自客户端的业务请求,判断出发送所述业务请求的客户端不存在所述黑名单中时,根据新的加密信息对业务请求进行加密验证。
可选的,所述新的加密信息包括新的公钥、新的用于生成签名的规则和新的加密规则;
其中,所述新的公钥的长度不限;
所述新的用于生成签名的规则包括:每一个业务参数的排列规则、业务参数的排序规则和当前时间戳生成规则。
可选的,所述处理单元还用于:
当接收到所述客户端发送的获取请求时,将所述新的加密信息发送给所述客户端。
与相关技术相比,本发明实施例包括:判断出第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值,根据第一预设时间内接收到的业务请求判断出当前是否存在恶意攻击,若存在恶意攻击,则根据预设的生成规则生成新的加密信息;当接收到来自客户端的业务请求时,根据新的加密信息对业务请求进行加密验证。通过本发明实施例的方案,在检测到当前存在恶意攻击时,生成新的加密信息来避免继续受到恶意攻击,从而减少了服务端宕机的可能性。
附图说明
下面对本发明实施例中的附图进行说明,实施例中的附图是用于对本发明的进一步理解,与说明书一起用于解释本发明,并不构成对本发明保护范围的限制。
图1为实现本发明实施例的可选通信***的示意图;
图2为本发明第一实施例实现签名的方法的流程图;
图3为本发明第二实施例实现签名的方法的流程图;
图4为本发明第三实施例实现签名的方法的流程图;
图5为本发明第四实施例实现签名的方法的流程图;
图6为本发明第五施例实现签名的方法的流程图;
图7为本发明第六实施例实现签名的方法的流程图;
图8为本发明第七实施例服务端的结构组成示意图;
图9为本发明第八实施例客户端的结构组成示意图;
图10为本发明第九实施例实现签名的***的结构组成示意图。
本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
为了便于本领域技术人员的理解,下面结合附图对本发明作进一步的描述,并不能用来限制本发明的保护范围。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的各种方式可以相互组合。
应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
如图1所示的通信***,一个或多个服务器为多个终端提供服务,为多个终端处理业务。
基于上述通信***,提出本发明方法各个实施例。
如图2所示,本发明第一实施例提出一种实现签名加密的方法,包括:
步骤300、若第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值,则服务端根据第一预设时间内接收到的业务请求判断出当前是否存在恶意攻击,若存在恶意攻击,则根据预设的生成规则生成新的加密信息。
本步骤中,第一预设阈值小于服务端最多所能够处理的业务请求的数量。
本步骤中,根据第一预设时间内接收到的业务请求判断出当前存在恶意攻击包括:
判断出第一预设时间内接收到的业务请求中,源互联网协议(IP,InternetProtocol)地址或访问参数相同的业务请求的数量大于或等于第二预设阈值。
其中,第一预设阈值大于或等于第二预设阈值。
本步骤中,新的加密信息包括新的公钥、新的用于生成签名的规则和新的加密规则。
其中,可以随机生成新的公钥、新的用于生成签名的规则和新的加密规则。
其中,新的公钥的长度不作限定,长度越长,安全性越高,长度越短,安全性越低。
其中,用于生成签名的规则包括:每一个业务参数的排列规则、业务参数的排序规则和当前时间戳生成规则。
其中,每一个业务参数的排列规则可以是正向排列,也可以是逆向排列。例如,对于业务参数姓名name=jack,正向排列时为name=jack,逆向排列时为jack=name。
其中,业务参数的排序规则可以是升序、或降序、或其他的顺序。
例如,业务参数包括姓名name=jack和年龄age=5,按照升序排列时为age=5name=jack或5=agejack=name;按照降序排列时为name=jackage=5或jack=name5=age。
其中,当前时间戳生成规则可以是从精确到秒的当前时间(11位数字)中获取1~11位数字。
这样,由于签名包括:所有业务参数组成的字符串、当前时间戳和公钥,因此,根据每一个业务参数的排列规则、业务参数的排序规则和当前时间戳生成规则就能够生成签名。
例如,业务参数包括姓名name=jack和年龄age=5,当前时间戳取11位数字(如1441555200),公钥为Hello时,签名为age=5name=jack1441555200hello。
本步骤中,加密规则可以是消息摘要算法第五版(md5,Message DigestAlgorithm 5)、或base64、或sha、或hmac等。
步骤301、当服务端接收到来自客户端的业务请求时,服务端根据新的加密信息对业务请求进行加密验证。
本步骤中,服务端根据新的加密信息对业务请求进行加密验证包括:
服务端根据新的公钥和新的用于生成签名的规则生成签名;根据新的加密规则对业务请求中的签名进行解密,将生成的签名和解密得到的签名进行匹配。
在服务端生成签名时,从业务请求中获取业务参数和当前时间戳。
可选的,该方法还包括:
当加密验证不通过时,服务端向客户端返回加密验证失败的消息。
本步骤中,当生成的签名和解密得到的签名相同时,加密验证通过;当生成的签名和解密得到的签名不相同时,加密验证不通过。
可选的,该方法还包括:
服务端接收到来自客户端的获取请求,将新的加密信息发送给客户端。
通过本发明实施例的方案,在检测到当前存在恶意攻击时,生成新的加密信息来避免继续受到恶意攻击,从而减少了服务端宕机的可能性。
可选的,根据第一预设时间内接收到的业务请求判断出当前存在恶意攻击后,还包括:
服务端保存存在恶意攻击的客户端。
可选的,服务端接收到来自客户端的业务请求后,根据新的加密信息对业务请求进行加密验证之前还包括:
服务端在保存的存在恶意攻击的客户端中查找不到发送业务请求的客户端。
可选的,当加密验证通过时,服务端进行业务处理。
可选的,该方法还包括:
服务端在第二预设时间后删除保存的存在恶意攻击的客户端。
可选的,可以将存在恶意攻击的客户端保存到黑名单中,在第二预设时间(例如一天)后将存在恶意攻击的客户端从黑名单中删除,也就是说当客户端被列入黑名单后,在第二预设时间内将无法再次进行业务请求,也就无法在第二预设时间内再次进行恶意攻击,从而减少了服务端宕机的可能性。
可选的,该方法还包括:
服务端在保存的存在恶意攻击的客户端中查找到发送业务请求的客户端,丢弃业务请求。
参照图3,本发明第二实施例还提出了一种实现签名加密的方法,包括:
步骤400、客户端根据预先设置的加密信息向服务端发送业务请求。包括:
客户端根据预先设置的公钥和用于生成签名的规则生成签名,根据加密规则对生成的签名进行加密,将加密后的签名包含在业务请求中发送给服务端。
本步骤中,业务请求包括业务参数、当前时间戳和加密后的签名。
例如,对于上述签名age=5name=jack1441555200hello,采用MD5加密算法对生成的签名进行加密得到加密后的签名256f2ae7155d3018c30e84b265d7686c,那么业务请求中包括age=5&name=jack&time=1441555200&signature=256f2ae7155d3018c30e84b265d7686c。
可选的,该方法还包括:
步骤401、客户端接收到来自服务端的加密验证失败的消息,向服务端发送获取请求。
步骤402、客户端接收到来自服务端的新的加密信息,根据新的加密信息向服务端发送业务请求。
上述方法中,服务端可以是一个服务器,也可以是多个服务器。
当服务端为多个服务器时,不同服务器之间通过消息交互实现信息的获取。
例如,当服务端包括Nginx分发鉴权服务器、分析服务器和生成服务器时,参见图4,本发明第三实施例还提出了一种实现签名加密的方法,包括:
步骤500、Nginx分发鉴权服务器判断出第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值,将第一预设时间内接收到的业务请求发送给分析服务器。
步骤501、分析服务器根据第一预设时间内接收到的业务请求判断当前是否存在恶意攻击,若存在恶意攻击,则将存在恶意攻击的消息发送给Nginx分发鉴权服务器,并向生成服务器发送通知消息。
步骤502、生成服务器接收到通知消息,生成新的加密信息;Nginx分发鉴权服务器接收到存在恶意攻击的消息,向生成服务器发送获取消息,保存接收到的来自生成服务器的新的加密信息。
步骤503、当Nginx分发鉴权服务器接收到来自客户端的业务请求时,Nginx分发鉴权服务器根据新的加密信息对业务请求进行加密验证。
可选的,该方法还包括:
当加密验证不通过时,Nginx分发鉴权服务器向客户端返回加密验证失败的消息。
可选的,该方法还包括:
生成服务器接收到来自客户端的获取请求,将新的加密信息发送给客户端。
可选的,存在恶意攻击的消息包括存在恶意攻击的客户端;
Nginx分发鉴权服务器接收到存在恶意攻击的消息后,还包括:
Nginx分发鉴权服务器保存存在恶意攻击的消息中的存在恶意攻击的客户端;相应的,
Nginx分发鉴权服务器接收到来自客户端的业务请求后,根据新的加密信息对业务请求进行加密验证之前还包括:
Nginx分发鉴权服务器在保存的存在恶意攻击的客户端中查找不到发送业务请求的客户端。
可选的,当加密验证通过时,Nginx分发鉴权服务器将业务请求发送给业务处理器进行业务处理。
可选的,该方法还包括:
Nginx分发鉴权服务器在第二预设时间后删除保存的存在恶意攻击的客户端。
可选的,可以将存在恶意攻击的客户端保存到黑名单中,在第二预设时间(例如一天)后将存在恶意攻击的客户端从黑名单中删除,也就是说当客户端被列入黑名单后,在第二预设时间内将无法再次进行业务请求,也就无法在第二预设时间内再次进行恶意攻击,从而减少了服务端宕机的可能性。
可选的,该方法还包括:
Nginx分发鉴权服务器在保存的存在恶意攻击的客户端中查找到发送业务请求的客户端,丢弃业务请求。
参见图5,本发明第四实施例还提出了一种实现签名加密的方法,包括:
步骤600、客户端根据预先设置的加密信息向Nginx分发鉴权服务器发送业务请求。
步骤601、客户端接收到来自Nginx分发鉴权服务器的加密验证失败的消息,向生成服务器发送获取请求。
步骤602、客户端接收到来自生成服务器的新的加密信息,根据新的加密信息向Nginx分发鉴权服务器发送业务请求。
又如,当服务端包括Nginx分发鉴权服务器、分析服务器、公钥生成服务器和规则生成服务器时,参见图6,本发明第五实施例还提出了一种实现签名加密的方法,包括:
步骤700、Nginx分发鉴权服务器判断出第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值,将第一预设时间内接收到的业务请求发送给分析服务器。
步骤701、分析服务器根据第一预设时间内接收到的业务请求判断当前是否存在恶意攻击,若存在恶意攻击,则将存在恶意攻击的消息发送给Nginx分发鉴权服务器,并向公钥生成服务器和规则生成服务器发送通知消息。
步骤702、公钥生成服务器接收到通知消息,生成新的公钥;规则生成服务器接收到通知消息,生成新的用于生成签名的规则和新的加密规则;Nginx分发鉴权服务器接收到存在恶意攻击的消息,向公钥生成服务器和规则生成服务器发送获取消息,保存接收到的来自公钥生成服务器的新的公钥、老子规则生成服务器的新的用于生成签名的规则和新的加密规则。
步骤703、当Nginx分发鉴权服务器接收到来自客户端的业务请求时,Nginx分发鉴权服务器根据新的公钥、新的用于生成签名的规则和新的加密规则对业务请求进行加密验证。
步骤704、当加密验证不通过时,Nginx分发鉴权服务器向客户端返回加密验证失败的消息。
步骤705、公钥生成服务器接收到来自客户端的获取请求,将新的公钥发送给客户端;规则生成服务器接收到来自客户端的获取请求,将新的用于生成签名的规则和新的加密规则发送给客户端。
可选的,存在恶意攻击的消息包括存在恶意攻击的客户端;
Nginx分发鉴权服务器接收到存在恶意攻击的消息后,还包括:
Nginx分发鉴权服务器保存存在恶意攻击的消息中的存在恶意攻击的客户端;相应的,
Nginx分发鉴权服务器接收到来自客户端的业务请求后,根据新的公钥、新的用于生成签名的规则和新的加密规则对业务请求进行加密验证之前还包括:
Nginx分发鉴权服务器在保存的存在恶意攻击的客户端中查找不到发送业务请求的客户端。
可选的,当加密验证通过时,Nginx分发鉴权服务器将业务请求发送给业务处理器进行业务处理。
可选的,该方法还包括:
Nginx分发鉴权服务器在第二预设时间后删除保存的存在恶意攻击的客户端。
可选的,可以将存在恶意攻击的客户端保存到黑名单中,在第二预设时间(例如一天)后将存在恶意攻击的客户端从黑名单中删除,也就是说当客户端被列入黑名单后,在第二预设时间内将无法再次进行业务请求,也就无法在第二预设时间内再次进行恶意攻击,从而减少了服务端宕机的可能性。
可选的,该方法还包括:
Nginx分发鉴权服务器在保存的存在恶意攻击的客户端中查找到发送业务请求的客户端,丢弃业务请求。
参见图7,本发明第六实施例还提出了一种实现签名加密的方法,包括:
步骤800、客户端根据预先设置的公钥、用于生成签名的规则和加密规则向Nginx分发鉴权服务器发送业务请求。
步骤801、客户端接收到来自Nginx分发鉴权服务器的加密验证失败的消息,向公钥生成服务器和规则生成服务器发送获取请求。
步骤802、客户端接收到来自公钥生成服务器的新的公钥、来自规则生成服务器的新的用于生成签名的规则和新的加密规则,根据新的公钥、新的用于生成签名的规则和新的加密规则向Nginx分发鉴权服务器发送业务请求。
参见图8,本发明第七实施例还提出了一种服务端,包括以下至少一个模块:
处理模块,用于判断出第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值,将第一预设时间内接收到的业务请求发送给分析模块;接收到存在恶意攻击的消息,向公钥生成模块和规则生成模块发送获取请求,保存接收到的来自公钥生成模块的新的公钥,以及接收到的来自规则生成模块的新的用于生成签名的规则和新的加密规则;当接收到来自客户端的业务请求时,根据新的公钥、新的用于生成签名的规则和新的加密规则对业务请求进行加密验证;当加密验证不通过时,向客户端返回加密验证失败的消息;
分析模块,用于接收到第一预设时间内接收到的业务请求,根据第一预设时间内接收到的业务请求判断出当前存在恶意攻击,向处理模块发送存在恶意攻击的消息,并向公钥生成模块和规则生成模块发送通知消息;
公钥生成模块,用于接收到通知消息,生成新的公钥;接收到来自处理模块的获取请求,向处理模块发送新的公钥;接收到来自客户端的获取请求,向客户端发送新的公钥;
规则生成模块,用于接收到通知消息,生成新的用于生成签名的规则和新的加密规则;接收到来自处理模块的获取请求,向处理模块发送新的用于生成签名的规则和新的加密规则;接收到来自客户端的获取请求,向客户端发送新的用于生成签名的规则和新的加密规则。
可选的,处理模块具体用于:
判断出第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值,将第一预设时间内接收到的业务请求发送给分析模块;接收到存在恶意攻击的消息,保存存在恶意攻击的消息中的存在恶意攻击的客户端,并向公钥生成模块和规则生成模块发送获取请求,保存接收到的来自公钥生成模块的新的公钥,以及接收到的来自规则生成模块的新的用于生成签名的规则和新的加密规则;当接收到来自客户端的业务请求时,在保存的存在恶意攻击的客户端中查找不到发送业务请求的客户端,根据新的公钥、新的用于生成签名的规则和新的加密规则对业务请求进行加密验证;当加密验证不通过时,向客户端返回加密验证失败的消息;
分析模块具体用于:
接收到第一预设时间内接收到的业务请求,根据第一预设时间内接收到的业务请求判断出当前存在恶意攻击,向处理模块发送包含存在恶意攻击的客户端的存在恶意攻击的消息,并向公钥生成模块和规则生成模块发送通知消息。
可选的,处理模块还用于:
在保存的存在恶意攻击的客户端中查找到发送业务请求的客户端,丢弃业务请求。
可选的,处理模块还用于:
在第二预设时间后删除保存的存在恶意攻击的客户端。
可选的,处理模设置在Nginx分发鉴权服务器,分析模块设置在分析服务器;或处理模块和分析模块设置在Nginx分发鉴权服务器;
公钥生成模块和规则生成模块设置在生成服务器;或公钥生成模块设置在公钥生成服务器,规则生成模块设置在规则生成服务器。
参见图9,本发明第八实施例还提出了一种客户端,包括:
发送模块,用于根据预先设置的公钥、用于生成签名的规则和加密规则向服务端发送业务请求;在接收模块接收到加密验证失败的消息时,向服务端发送获取请求;在接收模块接收到新的公钥、新的用于生成签名规则和新的加密规则时,根据新的公钥、新的用于生成签名的规则和新的加密规则向服务端发送业务请求;
接收模块,用于接收到来自服务端的加密验证失败的消息;接收到来自服务端的新的公钥、新的用于生成签名的规则和新的加密规则。
可选的,发送模块具体用于:
根据预先设置的公钥、用于生成签名的规则和加密规则向Nginx分发鉴权服务器发送业务请求;在接收模块接收到加密验证失败的消息时,向生成服务器发送获取请求;在接收模块接收到新的公钥、新的用于生成签名规则和新的加密规则时,根据新的公钥、新的用于生成签名的规则和新的加密规则向Nginx分发鉴权服务器发送业务请求;
接收模块具体用于:
接收到来自Nginx分发鉴权服务器的加密验证失败的消息;接收到来自生成服务器的新的公钥、新的用于生成签名的规则和新的加密规则。
可选的,发送模块具体用于:
根据预先设置的公钥、用于生成签名的规则和加密规则向Nginx分发鉴权服务器发送业务请求;在接收模块接收到加密验证失败的消息时,向生成服务器发送获取请求;在接收模块接收到新的公钥、新的用于生成签名规则和新的加密规则时,根据新的公钥、新的用于生成签名的规则和新的加密规则向Nginx分发鉴权服务器发送业务请求;
接收模块具体用于:
接收到来自Nginx分发鉴权服务器的加密验证失败的消息;接收到来自公钥生成服务器的新的公钥,接收到来自规则生成服务器的新的用于生成签名的规则和新的加密规则。
其中,发送模块和接收模块可以设置在图1中的移动通信模块112中。
参见图10,本发明第九实施例还提出了一种实现签名加密的***,包括:
判断单元,用于当第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值时,根据第一预设时间内接收到的业务请求判断出当前是否存在恶意攻击;
生成单元,用于当存在恶意攻击时,根据预设的生成规则生成新的加密信息;
验证单元,用于当接收到来自客户端的业务请求时,根据新的加密信息对业务请求进行加密验证。
可选的,所述***还包括:
处理单元,用于将所述存在恶意攻击的客户端信息保存至预设的黑名单中。
可选的,所述验证单元具体用于:
当接收到来自客户端的业务请求时,判断出发送所述业务请求的客户端不存在所述黑名单中,根据新的加密信息对业务请求进行加密验证。
可选的,所述新的加密信息包括新的公钥、新的用于生成签名的规则和新的加密规则;
其中,所述新的公钥的长度不限;
所述新的用于生成签名的规则包括:每一个业务参数的排列规则、业务参数的排序规则和当前时间戳生成规则。
可选的,处理单元还用于:
当接收到所述客户端发送的获取请求时,将所述新的加密信息发送给所述客户端。
需要说明的是,本实施例中的判断单元、生成单元、验证单元、处理单元可分别对应于图2-图7的签名加密的方法中,具体功能不再赘述。
可以位于一个服务器上,也可以位于多个服务器上,本发明实施例并不以此为限。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。
Claims (10)
1.一种实现签名加密的方法,其特征在于,包括:
若第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值,则根据第一预设时间内接收到的业务请求判断出当前是否存在恶意攻击,若存在恶意攻击,则根据预设的生成规则生成新的加密信息;
当接收到来自客户端的业务请求时,根据新的加密信息对业务请求进行加密验证。
2.根据权利要求1所述的方法,其特征在于,所述根据第一预设时间内接收到的业务请求判断出当前存在恶意攻击后,还包括:
将所述存在恶意攻击的客户端信息保存至预设的黑名单中。
3.根据权利要求2所述的方法,其特征在于,所述接收到来自客户端的业务请求后,根据新的加密信息对业务请求进行加密验证之前还包括:
判断出发送所述业务请求的客户端不存在所述黑名单中。
4.根据权利要求1所述的方法,其特征在于,所述新的加密信息包括新的公钥、新的用于生成签名的规则和新的加密规则;
其中,所述新的公钥的长度不限;
所述新的用于生成签名的规则包括:每一个业务参数的排列规则、业务参数的排序规则和当前时间戳生成规则。
5.根据权利要求1所述的方法,其特征在于,该方法还包括:
当接收到所述客户端发送的获取请求时,将所述新的加密信息发送给所述客户端。
6.一种实现签名加密的***,其特征在于,包括:
判断单元,用于当第一预设时间内接收到的业务请求的数量大于或等于第一预设阈值时,根据第一预设时间内接收到的业务请求判断出当前是否存在恶意攻击;
生成单元,用于当存在恶意攻击时,根据预设的生成规则生成新的加密信息;
验证单元,用于当接收到来自客户端的业务请求时,根据新的加密信息对业务请求进行加密验证。
7.根据权利要求6所述的***,其特征在于,还包括:
处理单元,用于将所述存在恶意攻击的客户端信息保存至预设的黑名单中。
8.根据权利要求7所述的***,其特征在于,所述验证单元具体用于:
当接收到来自客户端的业务请求,判断出发送所述业务请求的客户端不存在所述黑名单中时,根据新的加密信息对业务请求进行加密验证。
9.根据权利要求6所述的***,其特征在于,所述新的加密信息包括新的公钥、新的用于生成签名的规则和新的加密规则;
其中,所述新的公钥的长度不限;
所述新的用于生成签名的规则包括:每一个业务参数的排列规则、业务参数的排序规则和当前时间戳生成规则。
10.根据权利要求6所述的***,其特征在于,所述处理单元还用于:
当接收到所述客户端发送的获取请求时,将所述新的加密信息发送给所述客户端。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610377866.3A CN106101079A (zh) | 2016-05-31 | 2016-05-31 | 一种实现签名加密的方法和*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610377866.3A CN106101079A (zh) | 2016-05-31 | 2016-05-31 | 一种实现签名加密的方法和*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN106101079A true CN106101079A (zh) | 2016-11-09 |
Family
ID=57230910
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610377866.3A Pending CN106101079A (zh) | 2016-05-31 | 2016-05-31 | 一种实现签名加密的方法和*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106101079A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108880912A (zh) * | 2018-07-18 | 2018-11-23 | 北京力尊信通科技股份有限公司 | 一种it运维控制***及方法 |
CN108900308A (zh) * | 2018-07-06 | 2018-11-27 | 中国电力财务有限公司 | 一种身份认证方法、装置及*** |
CN108932428A (zh) * | 2017-05-25 | 2018-12-04 | 腾讯科技(深圳)有限公司 | 一种勒索软件的处理方法、装置、设备及可读存储介质 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101404575A (zh) * | 2008-11-06 | 2009-04-08 | 阿里巴巴集团控股有限公司 | 一种更新签名算法的方法和*** |
CN102118392A (zh) * | 2011-01-18 | 2011-07-06 | 南京朗睿软件科技有限公司 | 数据传输的加密/解密方法及*** |
CN103209072A (zh) * | 2013-04-27 | 2013-07-17 | 杭州华三通信技术有限公司 | 一种MACsec密钥更新方法及设备 |
CN103384242A (zh) * | 2013-03-15 | 2013-11-06 | 中标软件有限公司 | 基于Nginx代理服务器的入侵检测方法及*** |
CN103491060A (zh) * | 2012-06-13 | 2014-01-01 | 北京新媒传信科技有限公司 | 一种防御Web攻击的方法、装置、及*** |
CN104065657A (zh) * | 2014-06-26 | 2014-09-24 | 北京思特奇信息技术股份有限公司 | 一种基于ip访问的动态控制用户行为的方法及*** |
CN104811449A (zh) * | 2015-04-21 | 2015-07-29 | 深信服网络科技(深圳)有限公司 | 检测撞库攻击方法及*** |
-
2016
- 2016-05-31 CN CN201610377866.3A patent/CN106101079A/zh active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101404575A (zh) * | 2008-11-06 | 2009-04-08 | 阿里巴巴集团控股有限公司 | 一种更新签名算法的方法和*** |
CN102118392A (zh) * | 2011-01-18 | 2011-07-06 | 南京朗睿软件科技有限公司 | 数据传输的加密/解密方法及*** |
CN103491060A (zh) * | 2012-06-13 | 2014-01-01 | 北京新媒传信科技有限公司 | 一种防御Web攻击的方法、装置、及*** |
CN103384242A (zh) * | 2013-03-15 | 2013-11-06 | 中标软件有限公司 | 基于Nginx代理服务器的入侵检测方法及*** |
CN103209072A (zh) * | 2013-04-27 | 2013-07-17 | 杭州华三通信技术有限公司 | 一种MACsec密钥更新方法及设备 |
CN104065657A (zh) * | 2014-06-26 | 2014-09-24 | 北京思特奇信息技术股份有限公司 | 一种基于ip访问的动态控制用户行为的方法及*** |
CN104811449A (zh) * | 2015-04-21 | 2015-07-29 | 深信服网络科技(深圳)有限公司 | 检测撞库攻击方法及*** |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108932428A (zh) * | 2017-05-25 | 2018-12-04 | 腾讯科技(深圳)有限公司 | 一种勒索软件的处理方法、装置、设备及可读存储介质 |
CN108900308A (zh) * | 2018-07-06 | 2018-11-27 | 中国电力财务有限公司 | 一种身份认证方法、装置及*** |
CN108900308B (zh) * | 2018-07-06 | 2021-09-17 | 中国电力财务有限公司 | 一种身份认证方法、装置及*** |
CN108880912A (zh) * | 2018-07-18 | 2018-11-23 | 北京力尊信通科技股份有限公司 | 一种it运维控制***及方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11019383B2 (en) | Internet anti-attack method and authentication server | |
CN104954386B (zh) | 一种网络反劫持方法及装置 | |
CN102572815B (zh) | 一种对终端应用请求的处理方法、***及装置 | |
CN109309685B (zh) | 信息传输方法和装置 | |
CN109714370B (zh) | 一种基于http协议端云安全通信的实现方法 | |
CN104917765A (zh) | 一种防范攻击的方法和设备 | |
CN108111497A (zh) | 摄像机与服务器相互认证方法和装置 | |
CN109688098A (zh) | 数据的安全通信方法、装置、设备及计算机可读存储介质 | |
CN107508822A (zh) | 访问控制方法及装置 | |
CN109729000B (zh) | 一种即时通信方法及装置 | |
CN112217833B (zh) | 一种安全套接字协议卸载方法、装置、存储介质及电子设备 | |
Wu et al. | The weakness of integrity protection for LTE | |
US10630665B2 (en) | Authenticating messages | |
CN106101079A (zh) | 一种实现签名加密的方法和*** | |
Saxena et al. | SecureSMS: A secure SMS protocol for VAS and other applications | |
US20080126455A1 (en) | Methods of protecting management frames exchanged between two wireless equipments, and of receiving and transmitting such frames, computer programs, and data media containing said computer programs | |
CN104967527A (zh) | 通信记录的恢复方法、装置及服务器 | |
Barbera et al. | Cdroid: Towards a cloud-integrated mobile operating system | |
CN107770183B (zh) | 一种数据传输方法与装置 | |
CN106537962B (zh) | 无线网络配置、接入和访问方法、装置及设备 | |
US20230036527A1 (en) | Ssl proxy whitelisting | |
CN105939315A (zh) | 一种http攻击防护方法及装置 | |
Mankowski et al. | TLS→ Post-Quantum TLS: Inspecting the TLS landscape for PQC adoption on Android | |
CA3160532A1 (en) | Method for detecting anomalies in ssl and/or tls communications, corresponding device, and computer program product | |
Buenrostro et al. | Evaluating usability of permissioned blockchain for internet-of-battlefield things security |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20161109 |