计算机的安全性通常包括两个部分:认证和访问控制。认证包括对有效用户身份的确认和识别。而访问控制则致力于避免对数据文件和系统资源的有害篡改。举例来说,在一个孤立、集中、单用户系统中(例如一台计算机),通过锁上存放该计算机的房间并将磁盘锁起来就能够实现安全性,只有拥有房间和磁盘钥匙的用户才能访问系统资源和文件——这就同时实现了认证和访问控制。因此,安全性实际上就相当于锁住计算机和房间的钥匙。
分布式系统的安全比集中式系统复杂得多,因为安全涉及整个系统,所以有关安全的任何设计缺陷都可能导致所有的安全措施无效。分布式系统是由各个子系统组成的,子系统之间也需要做身份识别;各子系统都是通过网络进行连接的,它们之间的安全通信也是需要保障的。
由于安全是一个复杂的话题,并不是本书所要阐述的重点,所以本书只会涉及分布式系统安全方面的基本知识。
计算机系统中的安全性与可靠性密切相关。非正式地说,一个可靠的计算机系统是一个我们有理由信任其所提供的服务的系统。可靠性包括可用性、可信赖性、安全性和可维护性。如果我们要信任一个计算机系统,则还应该考虑机密性和完整性。考虑计算机系统中安全的另一种角度是我们试图保护该系统所提供的服务和数据不受到安全威胁,这类安全威胁包括4种。
窃听: 指一个未经授权的用户获得了对一项服务或数据的访问权限。窃听的一个典型实例是两人之间的通信被其他人偷听。窃听还发生在非法复制数据时。
中断: 指服务或数据变得难以获得、不能使用、被破坏等情况。从这个意义上说,服务拒绝攻击是一种安全威胁,它被归为中断类,一些人正是通过它恶意地使其他人不能访问服务。
修改: 包括对数据未经授权的改变或篡改一项服务以使其不再遵循其原始规范。修改的实例包括窃听,然后改变传输的数据,篡改数据库条目,以及改变一个程序使其秘密记录其用户的活动。
伪造: 指产生通常不存在的附加数据或活动的情况。例如,一个入侵者可能尝试向密码文件或数据库中添加数据,同样,有时可能通过重放先前发送过的消息来侵入一个系统。
仅仅声明系统应该能够保护其自身免受任何可能的安全威胁并不是实际建立一个安全系统的方式。首先需要的是一个安全需求的描述,也就是一个策略。安全策略准确地描述了系统中的实体能够采取的行为及禁止采取的行动。实体包括用户、服务、数据、机器等。制定安全策略之后,就可以集中考虑安全机制,策略通过该机制来实施。重要的机制包括:
加密;
身份验证;
授权;
审计。
加密将数据转换为一些攻击者不能理解的形式。身份验证用于检验用户、客户、服务器等所声明的身份。对一个客户进行身份验证之后,有必要检查是否授予客户执行该请求操作的权限。审计工具用于追踪各个客户的访问内容和访问方式。
加密 包括使用密钥对数据进行编码,从而使偷听者无法方便地阅读这些数据。经过加密的数据称为 密文 ,原始的数据称为 明文 。从密文到明文的转换过程称为解密。
图1-18描述了Alice和Bob通过Caesar密码方式进行通信的过程,这里的Alice和Bob常用来表示密码通信的双方。
图1-18 Caesar密码通信过程
Caesar密码又叫循环移位密码,它的加密方法就是将明文中的每个字母用字母表中该字母后的第R个字母来替换,从而达到加密的目的。
它的加密过程可以表示为下面的函数:
E(m)=(m+k)mod n
其中,m为明文字母在字母表中的位置数;n为字母表中的字母个数;k为密钥;E(m)为密文字母在字母表中对应的位置数。例如,对于明文字母 H,其在字母表中的位置数为 8,则按照上式计算出来的密文为 L,计算过程如下:
E(8)=(8+4)mod 26 = 12
在上面的例子中,每个字母用其后面的第三个字母代替。
下面是一个用C语言实现的Caesar密码程序:
评估一种加密算法的安全性常用的方法是判断该算法是否是计算安全的。如果利用可用资源进行系统分析后无法攻破系统,那么这种加密算法就是计算安全的。目前有两种常用的加密类型:私钥加密和公钥加密。除了加密整条消息,两种加密类型都可以用来对一个文档进行数字签名。当一个密钥越长时,密码被破解的难度就会越大,系统也就越安全。当然,密钥越长,本身加解密的成本也就越高。
对称加密:加密和解密算法都使用相同密钥的加密算法。具体如下:
E(p,k)=C ;D(C,k)=p
其中
E = 加密算法;
D = 解密算法;
p = 明文(原始数据);
k = 加密密钥;
C = 密文。
由于在加密和解密数据时使用同一个密钥,因此这个密钥必须保密,这样的加密称为对称密钥算法,或单密钥算法,或常规加密。很显然,对称算法的安全性依赖于密钥,泄露密钥就意味着任何人都可以对他们发送或接收的消息解密,所以密钥的保密性对通信的安全性至关重要。
对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。
对称加密算法的不足之处是,交易双方都使用同样的钥匙,安全性得不到保证。此外,每对用户每次使用对称加密算法时,都需要使用其他人不知道的唯一钥匙,这会使得发收信双方所拥有的钥匙数量呈几何级数增长,密钥管理成为用户的负担。对称加密算法在分布式网络系统上使用较为困难,主要是因为密钥管理困难,使用成本较高。与公开密钥加密算法比起来,对称加密算法能够提供加密和认证却缺乏签名功能,使用范围较小。
常见的对称加密算法有DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等。
在通过网络发送数据的过程中,有两种对文档进行数字签名的基本方法。这里我们讨论第一种方法,利用私钥加密法。数字签名也称为 消息摘要 (Message Digest)或 数字摘要 (Digital Digest),它是一个对应唯一消息或文本的固定长度的值,它由一个单向Hash加密函数对消息进行作用而产生。如果消息在途中改变了,则接收者通过对收到的消息新产生的摘要与原摘要进行比较,就可以知道消息是否被改变了。因此消息摘要保证了消息的完整性。消息摘要采用单向Hash函数将需加密的明文“摘要”成一串128bit的密文,这一串密文也称为 数字指纹 (Finger Print),它有固定的长度,且不同的明文摘要成密文,其结果总是不同的,而同样的明文其摘要必定一致。这样这串摘要便可成为验证明文是否是“真身”的“指纹”了。有两种方法可以利用共享的私钥来计算摘要。最简单、快捷的方法是计算消息的哈希值,然后通过私钥对这个数值进行加密,再把消息和已加密的摘要一起发送。接收者可以再次计算消息摘要,对摘要进行加密,并与接收到的加密摘要进行比较。如果这两个加密摘要相同,就说明该文档没有被改动。第二种方法是将私钥应用到消息上,然后计算哈希值。
计算公式为:
D(M,K)
其中
D 是摘要函数;
M 是消息;
K 是共享的私钥。
然后可以发布或分发这个文档。由于第三方并不知道私钥,而计算正确的摘要值恰恰需要它,因此消息摘要能够避免对摘要值自身的伪造。在这两种情况下,只有那些了解密钥的用户才能验证其完整性,所有欺骗性的文档都可以很容易地被检验出来。
消息摘要算法有MD2、MD4、MD5、SHA-1、SHA-256、RIPEMD128、RIPEMD160等。
非对称加密(也称为公钥加密)由两个密钥组成,包括公开密钥(public key,简称公钥)和私有密钥(private key,简称私钥)。如果信息使用公钥进行加密,那么使用对应的私钥可以解密这些信息,过程如下:
E(p,ku)=C ; D(C,kr)=p
其中
E = 加密算法;
D = 解密算法;
p = 明文(原始数据);
ku = 公钥;
kr = 私钥;
C = 密文。
如果信息使用私钥进行加密,那么使用对应的公钥可以解密这些信息,过程如下:
E(p,kr)=C ; D(C,ku)=p
其中
E = 加密算法;
D = 解密算法;
p = 明文(原始数据);
ku = 公钥;
kr = 私钥;
C = 密文。
不能使用加密所用的密钥来解密一个消息。而且,由一个密钥计算出另一个密钥从数学上来说是很困难的。私钥只有用户本人知道,并因此得名。公钥并不保密,可以通过公共列表服务获得,通常公钥是使用X.509实现的。公钥加密的想法最早是由Diffie和Hellman于1976年提出的。
非对称加密与对称加密相比,安全性更好。对称加密的通信双方使用相同的密钥,如果一方的密钥遭泄露,那么整个通信就会被破解。而非对称加密使用一对密钥,一个用来加密,另一个用来解密,而且公钥是公开的,密钥是自己保存的,不需要像对称加密那样在通信之前先同步秘钥。
非对称加密的缺点是加密和解密花费时间长、速度慢,只适合对少量数据进行加密。
在非对称加密中使用的主要算法有 RSA、Elgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法)等。
用于数字签名的公钥加密使用RSA算法。在这种方法中,发送者利用私钥通过摘要函数对整个数据文件(代价昂贵)或文件的签名进行加密。私钥匹配最主要的优点就是不存在密钥分发问题。这种方法假定你信任发布公钥的来源,然后接收者可以利用公钥来解密签名或文件,并验证它的来源和/或内容。由于公钥密码学的复杂性,只有正确的公钥才能够解密信息或摘要。最后,如果你要将消息发送给拥有已知公钥的用户,那么就可以使用接收者的公钥来加密消息或摘要,这样只有接收者才能够通过他们自己的私钥来验证其中的内容。
SSL(Secure Sockets Layer,安全套接字层)是在网络上应用最广泛的加密协议实现。SSL结合加密过程来提供网络的安全通信。
SSL提供了一个安全的增强标准TCP/IP套接字用于网络通信协议。如表1-1所示,在标准TCP/IP 协议栈的传输层和应用层之间添加了完全套接字层。SSL 的应用程序中最常用的是Hypertext Transfer Protocol(HTTP,超文本传输协议),它是互联网网页协议。其他应用程序,如Net News Transfer Protocol(NNTP,网络新闻传输协议)、Telnet、 Lightweight Directory Access Protocol(LDAP,轻量级目录访问协议)、Interactive Message Access Protocol(IMAP,互动信息访问协议)和File Transfer Protocol(FTP,文件传输协议),也可以使用SSL。
注: 目前还没有标准的安全的FTP。
表1-1 增强标准的TCP/IP层与协议
SSL 最初是由网景公司在1994年创立的,现在已经演变为一个标准。由国际标准组织Internet Engineering Task Force(IETF)进行管理。之后IETF更名SSL为Transport Layer Security (TLS,传输层安全),并在1999年1月发布了第一个规范,版本为1.0。TLS 1.0对于SSL的最新版本3.0版本是一个小的升级,两者差异非常微小。TLS 1.1是在2006年4月发布的,TLS 1.2在2008年8月发布。
SSL 通过握手过程在客户端和服务器之间协商会话参数并建立会话。会话包含的主要参数有会话ID、对方的证书、加密套件(密钥交换算法、数据加密算法和MAC算法等)及主密钥(master secret)。通过SSL会话传输的数据,都将采用该会话的主密钥和加密套件进行加密、计算MAC等。
在不同的情况下,SSL的握手过程存在差异。下面将分别描述以下三种握手过程:
只验证服务器的SSL握手过程;
验证服务器和客户端的SSL握手过程;
恢复原有会话的SSL握手过程。
只验证服务器的SSL握手过程如图1-19所示。
图1-19 只验证服务器的SSL握手过程
如图1-19所示,在只需要验证SSL服务器身份、不需要验证SSL客户端身份时,SSL的握手过程如下。
(1)SSL客户端通过Client Hello消息将它支持的SSL版本、加密算法、密钥交换算法、MAC算法等信息发送给SSL服务器。
(2)SSL服务器确定本次通信采用的SSL版本和加密套件,并通过Server Hello消息通知SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话,则SSL服务器会为本次会话分配会话ID,并通过Server Hello消息发送给SSL客户端。
(3)SSL服务器将携带自己公钥信息的数字证书通过Certificate消息发送给SSL客户端。
(4)SSL服务器发送Server Hello Done消息,通知SSL客户端版本和加密套件协商结束,开始进行密钥交换。
(5)SSL客户端验证SSL服务器的证书合法后,利用证书中的公钥加密SSL客户端随机生成的premaster secret,并通过Client Key Exchange消息发送给SSL服务器。
(6)SSL客户端发送Change Cipher Spec消息,通知SSL服务器后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
(7)SSL客户端计算已交互的握手消息(除Change Cipher Spec消息外所有已交互的消息)的Hash值,利用协商好的密钥和加密套件处理Hash值(计算并添加MAC值、加密等),并通过 Finished 消息发送给 SSL 服务器。SSL 服务器利用同样的方法计算已交互的握手消息的Hash值,并与Finished消息的解密结果比较,如果二者相同,且MAC值验证成功,则证明密钥和加密套件协商成功。
(8)同样,SSL服务器发送Change Cipher Spec消息,通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
(9)SSL 服务器计算已交互的握手消息的 Hash 值,利用协商好的密钥和加密套件处理Hash值(计算并添加MAC值、加密等),并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值,并与Finished消息的解密结果比较,如果二者相同,且MAC值验证成功,则证明密钥和加密套件协商成功。
SSL客户端接收到SSL服务器发送的Finished消息后,如果解密成功,则可以判断SSL服务器是数字证书的拥有者,即SSL服务器身份验证成功,因为只有拥有私钥的SSL服务器才能从Client Key Exchange消息中解密得到premaster secret,从而间接地实现SSL客户端对SSL服务器的身份验证。
验证服务器和客户端的SSL握手过程如图1-20所示。
图1-20 验证服务器和客户端的SSL握手过程
SSL 客户端的身份验证是可选的,由 SSL 服务器决定是否验证 SSL 客户端的身份。如图1-20中(4)、(6)、(8)部分所示,如果SSL服务器验证SSL客户端身份,则SSL服务器和SSL客户端除了交互“只验证服务器的SSL握手过程”中的消息协商密钥和加密套件,还需要进行以下操作。
(1)SSL服务器发送Certificate Request消息,请求SSL客户端将其证书发送给SSL服务器。
(2)SSL客户端通过Certificate消息将携带自己公钥的证书发送给SSL服务器。SSL服务器验证该证书的合法性。
(3)SSL客户端计算已交互的握手消息、主密钥的Hash值,利用自己的私钥对其进行加密,并通过Certificate Verify消息发送给SSL服务器。
(4)SSL服务器计算已交互的握手消息、主密钥的Hash值,利用SSL客户端证书中的公钥解密Certificate Verify消息,并将解密结果与计算出的Hash值比较。如果二者相同,则SSL客户端身份验证成功。
恢复原有会话的SSL握手过程如图1-21所示。
图1-21 恢复原有会话的SSL握手过程
在协商会话参数、建立会话的过程中,需要使用非对称密钥算法来加密密钥、验证通信对端的身份,计算量较大,占用了大量的系统资源。为了简化SSL握手过程,SSL允许重用已经协商过的会话,具体过程如下。
(1)SSL客户端发送Client Hello消息,消息中的会话ID设置为计划重用的会话ID。
(2)SSL服务器如果允许重用该会话,则通过在Server Hello消息中设置相同的会话ID来应答。这样,SSL客户端和SSL服务器就可以利用原有会话的密钥和加密套件,不必重新协商。
(3)SSL客户端发送Change Cipher Spec消息,通知SSL服务器后续报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
(4)SSL客户端计算已交互的握手消息的Hash值,利用原有会话的密钥和加密套件处理Hash值,并通过Finished消息发送给SSL服务器,以便SSL服务器判断密钥和加密套件是否正确。
(5)同样,SSL服务器发送Change Cipher Spec消息,通知SSL客户端后续报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
(6)SSL服务器计算已交互的握手消息的Hash值,利用原有会话的密钥和加密套件处理Hash值,并通过Finished消息发送给SSL客户端,以便SSL客户端判断密钥和加密套件是否正确。
HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)是基于SSL安全连接的HTTP。HTTPS通过SSL提供的数据加密、身份验证和消息完整性验证等安全机制,为Web访问提供安全性保证,广泛应用于网上银行、电子商务等领域。近年来,在主要互联网公司和浏览器开发商的推动之下,HTTPS正在被加速普及,HTTP正在被加速淘汰。不加密的HTTP连接是不安全的,你和目标服务器之间的任何中间人都能读取和操纵传输的数据,比如ISP可以在你点击的网页上插入广告,你很可能根本不知道看到的广告是否是网站发布的。中间人能够注入的代码不仅有看起来无害的广告,他们还可能注入具有恶意目的的代码。2015年,百度联盟广告的脚本被中间人修改,加入代码对两个网站发动了DDoS攻击。这次攻击被称为网络大炮,网络大炮让普通的网民在不知情的状态下变成了DDoS攻击者,而唯一能阻止大炮的方法是加密流量。
由于Tomcat是市场占有率最高的Java开源Servelet容器,下面介绍如何在Tomcat中配置SSL/TLS以支持HTTPS。
生成密钥和证书
Tomcat目前只能操作JKS、PKCS11、PKCS12格式的密钥存储库。JKS是Java标准的“Java密钥存储库”格式,是通过keytool命令行工具创建的。该工具包含在JDK中。PKCS12格式是一种互联网标准,可以通过OpenSSL和Microsoft的Key-Manager来操纵。
创建一个keystore文件来保存服务器的私有密钥和自签名证书。
在Windows下执行:
"%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA
在UNIX下执行:
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
执行命令后,首先会提示你提供keystore的密码。Tomcat默认的密码是changeit(全部字母都小写),当然你可以指定一个自定义密码(如果你愿意)。同样,你也需要将这个自定义密码在server.xml配置文件内进行指定,稍后再详述。
接下来会提示关于证书的一般信息,比如组织、联系人名称等。当用户试图在你的应用中访问一个安全页面时,该信息会显示给用户,所以一定要确保所提供的信息与用户所期望看到的内容一致。
最后,还需要输入密钥密码(key password),这个密码是这一证书(而不是存储在同一密码存储库文件中的其他证书)的专有密码。keytool会提示,如果按下回车键,则自动使用密码存储库 keystore 的密码。当然,除了这个密码,也可以自定义密码。如果选择自定义密码,那么不要忘了在server.xml配置文件中指定这一密码。
下面是详细步骤:
如果操作全部正常,则会创建一个新的JKS密码存储库,该密码库包含一个自签名的证书。
该命令将在用户的主目录下创建一个新文件:.keystore。
要想指定一个不同的位置或文件名,可以在上述的keytool命令上添加-keystore参数,后面加上到达keystore文件的完整路径名,还需要把这个新位置指定到server.xml配置文件上(见后文介绍)。
Windows:
UNIX:
修改配置
取消对Tomcat安装目录下/conf/server.xml中“SSL HTTP/1.1 Connector”一项的注释状态,并指定keystore的路径和密码:
Tomcat指定8443端口为HTTPS访问端口。如果要隐藏端口号,则要把Tomcat的HTTPS端口设为443。
若想把所有 HTTP 请求都转到 HTTPS 上,则可以修改 Tomcat 的 conf 下的 web.xml,在<welcome-file-list> </welcome-file-list>节点下方添加如下代码:
其中,<url-pattern>是配置文件过滤策略,比如只对.jsp 的请求自动转化为 HTTPS,配置如下:
在<url-pattern>中可以配置你希望自动转化的请求路径/*、login.html、login.jsp等。
虽然SSL协议的意图是尽可能提供安全且高效的连接,但从性能的角度考虑,加密与解密是非常耗费计算资源的,因此将整个Web应用都运行在SSL协议下是完全没有必要的,开发者需要挑选需要安全连接的页面。对于一个相当繁忙的网站来说,通常只会在特定页面上使用SSL协议,也就是可能交换敏感信息的页面,比如登录页面、个人信息页面、购物车结账页面(可能会输入信用卡信息)等。应用中的任何一个页面都可以通过加密套接字来请求访问,只需将页面地址的前缀http:换成https:即可。
SSL VPN是以SSL为基础的VPN技术,利用SSL提供的安全机制,为用户远程访问公司内部网络提供安全保证。与复杂的IPSec VPN相比,SSL通过简单易用的方法实现了信息远程连通。任何安装浏览器的机器都可以使用SSL VPN,这是因为SSL内嵌在浏览器中,它不需要像传统IPSec VPN一样必须为每一台客户机安装客户端软件。SSL VPN通过在远程接入用户和SSL VPN网关之间建立SSL安全连接,允许用户通过各种Web浏览器,各种网络接入方式,在任何地方远程访问企业网络资源,并保证企业网络的安全,保护企业内部信息不被窃取。
一般而言,SSL VPN必须满足最基本的两个要求:
使用SSL协议进行认证和加密。没有采用SSL协议的VPN产品自然不能称为SSL VPN,其安全性也需要进一步考证。
直接使用浏览器完成操作,无须安装独立的客户端。即使使用了 SSL 协议,但仍然需要分发和安装独立VPN客户端(如Open VPN)的不能称为SSL VPN,否则就失去了SSL VPN易于部署、免维护的优点。
SSL VPN的典型组网模式如图1-22所示。
图1-22 SSL VPN的典型组网模式
访问控制是指按用户身份及其所归属的某项定义组来限制用户对某些信息项的访问,或限制对某些控制功能的使用的一种技术。
访问控制的功能:
防止非法的主体进入受保护的网络资源;
允许合法用户访问受保护的网络资源;
防止合法的用户对受保护的网络资源进行非授权的访问。
防火墙指的是一个由软件和硬件设备组合而成、在内部网络和外部网络之间、专用网与公共网之间的构造的保护屏障。这是一种获取安全性的形象说法,它是计算机硬件和软件的结合,使Internet与Intranet之间建立起一个安全网关(Security Gateway),从而保护内部网免受非法用户的侵入。防火墙主要由服务访问规则、验证工具、包过滤和应用网关4部分组成,防火墙就是一个位于计算机和它所连接的网络之间的软件或硬件。该计算机流入和流出的所有网络通信和数据包均要经过此防火墙。
防火墙具备以下特性:
内部网络和外部网络之间的所有网络数据流都必须经过防火墙;
只有符合安全策略的数据流才能通过防火墙;
防火墙自身应具有非常强的抗攻击免疫力;
应用层防火墙具备更细致的防护能力;
数据库防火墙具有针对数据库恶意攻击的阻断能力。
堡垒机,即在一个特定的网络环境下,为了保障网络和数据不受来自外部和内部用户的入侵和破坏,运用各种技术手段实时收集和监控网络环境中每一个组成部分的系统状态、安全事件、网络活动,以便集中报警、记录、分析、处理的一种技术手段。
从功能上讲,它综合了核心系统运维和安全审计管控两大主干功能;从技术实现上讲,通过切断终端计算机对网络和服务器资源的直接访问,采用协议代理的方式,接管了终端计算机对网络和服务器的访问。形象地说,终端计算机对目标的访问,都要经过运维安全审计的翻译。打一个比方,运维安全审计扮演着看门者的角色,所有对网络设备和服务器的请求都要从这扇大门经过。因此运维安全审计能够拦截非法访问和恶意攻击,阻断不合法命令,过滤所有对目标设备的非法访问行为,并对内部人员的误操作和非法操作进行审计监控,以便事后责任追踪。
安全审计作为企业信息安全建设不可缺少的组成部分,逐渐受到用户的关注,是企业安全体系中的重要环节。同时,安全审计是事前预防、事中预警的有效风险控制手段,也是事后追溯的可靠证据来源。
DoS(Denial of Service,拒绝服务)攻击是指通过向服务器发送大量垃圾信息或干扰信息的方式,使服务器无法向正常用户提供服务的现象。对付一个或多个资源的DoS往往比较容易,而要对付DDoS(Distributed Denial of Service,分布式拒绝服务)则困难得多。
DDoS攻击主要分为两类。
带宽耗竭的攻击: 向某个机器发送大量的消息,使正常的消息很难到达接收者。
资源耗竭的攻击: 使接收者把资源消耗在无用的消息上。
UDP洪水攻击是指攻击者利用简单的TCP/IP服务,如Chargen和Echo来传送毫无用处的占满带宽的数据。通过伪造与某一主机的Chargen服务之间的一次UDP连接,回复地址指向开着Echo服务的一台主机,这样就在两台主机之间生成很多无用数据流,这些无用数据流会导致带宽的服务攻击。
SYN Flood是当前最流行的DoS与DDoS的方式之一,这是一种利用TCP缺陷,发送大量伪造的TCP连接请求,使被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式。
常见的防止DDoS的方式:
TCP首包丢弃方案 。利用TCP的重传机制识别正常用户和攻击报文。当防御设备接到一个IP的SYN报文后,简单比对该IP是否存在于白名单中,存在则转发到后端。如果不存在于白名单中,则检查是否是该IP在一定时间段内的首次SYN报文,如果不是则检查是否重传报文,是重传则转发并加入白名单,不是则丢弃并加入黑名单。如果是首次SYN报文,则丢弃并等待一段时间以接收该IP的SYN重传报文,等待超时则判定为攻击报文并加入黑名单。
缓存 。尽量由设备的缓存直接返回结果来保护后端业务。大型的互联网企业会有庞大的CDN节点缓存内容。
重发 。可以是直接丢弃DNS报文导致UDP层面的请求重发,也可以是返回特殊响应强制要求客户端使用TCP重发DNS查询请求。
判断博文内容 。在一个TCP连接中,HTTP报文太少和报文太多都是不正常的,过少可能是慢速连接攻击,过多可能是使用HTTP 1.1进行的HTTP Flood攻击。
开发者需要在软件和设备中实现访问控制功能,常见的访问控制的模型有三种。
自主访问控制(Discretionary Access Control,DAC)模型: 不同的管理方式形成不同的访问控制方式。一种方式是由客体的属主对自己的客体进行管理,由属主自己决定是否将自己客体的访问权或部分访问权授予其他主体,这种控制方式是自主的,我们把它称为自主访问控制。在自主访问控制下,一个用户可以自主选择哪些用户可以共享他的文件。Linux系统中有两种自主访问控制策略,一种是9位权限码(User-Group-Other),另一种是访问控制列表ACL(Access Control List)。
强制访问控制(Mandatory Access Control,MAC)模型: 用于将系统中的信息分密级和类进行管理,以保证每个用户只能访问到那些被标明可以由他访问的信息的一种访问约束机制。通俗地讲,在强制访问控制下,用户(或其他主体)与文件(或其他客体)都被标记了固定的安全属性(如安全级、访问权限等),在每次访问发生时,系统检测安全属性以便确定一个用户是否有权访问该文件。其中多级安全(MultiLevel Secure,MLS)就是一种强制访问控制策略。
基于角色的访问控制模型(Role Based Access Control,RBAC)模型: 管理员定义一系列角色(role)并把它们赋予主体。系统进程和普通用户可能有不同的角色。设置对象为某个类型,主体具有相应的角色就可以访问它。这样就把管理员从定义每个用户的许可权限的烦琐工作中解放出来了。RBAC有时被称为基于规则的、基于角色的访问控制(Rule-Based Role-Based Access Control,RB-RBAC)。它包含了根据主体的属性和策略定义的规则动态地赋予主体角色的机制。例如,你是一个网络中的主体,你想访问另一个网络中的对象,这个网络定义好了访问列表的路由器的另一端,路由器根据你的网络地址或协议,赋予你某个角色,决定了你是否被授权访问。