TCP/IP存在脆弱性
IP层的主要曲线是缺乏有效的安全认证和保密机制，其中最主要的因素就是IP地址问题。TCP/IP协议用IP地址来作为网络节点的惟一标识，许多TCP/IP服务，包括Berkeley中的R命令、NFS、X Window等都是基于IP地址对用户进行认证和授权。当前TCP/IP网络的安全机制主要是基于IP地址的包过滤（Packet Filtering）和认证(Authentication)技术，它的有效性体现在可以根据IP包中的源IP地址判断数据的真实性和安全性。然而IP地址存在许多问题，协议的最大缺点就是缺乏对IP地址的保护，缺乏对IP包中源IP地址真实性的认证机制与保密措施。这也就是引起整个TCP/IP协议不安全的根本所在。
由于UDP是基于IP协议之上的，TCP分段和UDP协议数据包是封装在IP包中在网络上传输的，因此同样面临IP层所遇到的安全威胁。现在人们一直在想办法解决，却仍然无法避免的就是根据TCP连接建立时“三次握手”机制的攻击（如图1）。这些攻击总结起来包括：
源地址欺骗（Source Address Spoofing）或IP欺骗（IP Spoofing）；
源路由选择欺骗（Source Routing Spoofing）；
路由选择信息协议攻击（RIP Attacks）；
鉴别攻击（Authentication Attacks）；
TCP序列号欺骗（TCP Sequence number spoofing）；
TCP/IP协议数据流采用明文传输；
TCP序列号轰炸攻击（TCP SYN Flooding Attack），简称SYN攻击；
易欺骗性（Ease of spoofing）。
图1
比如网管员都熟悉的因特网控制信息协议（ICMP），它是TCP/IP协议组的一个基本网络管理工具，在帮助网络管理人员排除网络故障中立下了汗马功劳，同时ICMP攻击却十分猖狂。最明显的是ICMP重定向报文，它被网关用来为主机提供好的路由，却不能被用来给主机的路由表进行主动的变化。如果入侵者已经攻破一个对目标主机来说可利用的次要网关，而不是基本网关，入侵者就可以通过有危险的次要网关给信任主机设置一个错误的路由。多数的服务主机在TCP重定向报文上不实行有效检查，这种攻击的影响和基于RIP的攻击相似。
另外，ICMP也可以被用来进行拒绝服务攻击（如图2）。个别的报文如目标不可达或者超时，就可以用来重置目前的连接，如果入侵者知道TCP 连接的本地及远端的端口号，将生成该连接的ICMP 报文。有时这样的信息可以通过NETSTAT服务来实现。一个更普遍的拒绝服务攻击是发送伪造的子网掩码回应报文。无论主机是否查询，它们都将接受该报文，一个错误的报文就可能阻塞目标主机的所有连接。
图2
应用服务不容乐观
１． 文件传输协议
FTP经久不衰的原因在于它可以在互联网上进行与平台无关的数据传输，它基于一个客户机/服务器架构。FTP 将通过两个信道（端口）传输，一个传输数据（TCP 端口 20），另一个传输控制信息（TCP 端口 21）。在控制信道之上，双方（客户机和服务器）交换用于发起数据传输的命令。一个 FTP 连接包含4个步骤：用户鉴权→建立控制信道→建立数据信道→关闭连接。FTP 的连接控制使用 TCP （Transmission Control Protocol, 传输控制协议），它保障了数据的可靠传输。因此，FTP 在数据传输中不需要关心分组丢失和数据错误检测。
匿名FTP作为互联网上广泛应用的服务，安全等级的低下受到了黑客的频繁光顾。匿名FTP 是真的匿名，并没有记录谁请求了什么信息，谁下载了什么文件，上传了什么东西（有可能是木马）。FTP存在着致命的安全缺陷，FTP使用标准的用户名和口令作为身份验证，缺乏有效的访问权限的控制机制，而其口令和密码的传输也都是明文的方式。
２． Web服务
Web服务器位于宿主基础结构的前端，它与Internet直接相连，负责接收来自客户端的请求，创建动态Web页并响应请求数据。最初WWW服务只提供静态的HTML页面，为改变人们对网络互动请求的愿望，开始引入了CGI程序，CGI程序让主页活动起来。CGI程序可以接收用户的输入信息，一般用户是通过表格把输入信息传给CGI程序的，然后CGI程序可以根据用户的要求进行一些处理，一般情况下会生成一个HTML文件，并传回给用户。很多CGI程序都存在安全漏洞，很容易被黑客利用做一些非法的事情。现在很多人在编写CGI程序时，可能对CGI软件包中的安全漏洞并不了解，而且大多数情况下不会重新编写程序的所有部分，只是对其加以适当的修改，这样很多CGI程序就不可避免的具有相同的安全漏洞。很多SQL Server 开发人员并没有在代码编写开始的时候就从安全防护基础开始，这样就无法确保您开发的代码的安全性，其结果就造成了无法将应用程序的运行控制在所需的最低权限之内。
如果Web 服务需要输出敏感的、受限的数据，或者需要提供受限的服务，则它需要对调用方进行身份验证。如果客户访问都是在一个可信的域中，我们就完全可以放心使用，但在实际应用中是不可能实现的。所以，系统级的身份验证也就无法实现，至少在现阶段无法实现。例如：可以使用IIS为基本身份验证配置Web服务的虚拟目录。通过这种方式，使用者必须配置代理，并提供用户名和密码形式的凭据。然后在每次Web服务通过代理请求的时候由代理传递它们。这些凭据是以明文形式传递的，所以应该只在SSL中使用基本身份验证（如图3），但很少有管理员这样做。
图3
另外，Web服务本身不提供容错机制。如果Web服务采用了软件冗余技术，就可以保证一个版本出错，另一个版本就很少有机会出现相同的错误。代码的重复利用不能保证错误的完全避免，因此在某个模块发生某个物理故障时，其他模块也就完全瘫痪。
随着Java Applet、ActiveX、Cookie等技术的大量应用，当用户使用浏览器查看、编辑网络内容时，采用了这些技术的应用程序会自动下载并在客户机上运行，如果这些程序被恶意使用，就可能窃取、改变或删除客户机上的信息。对于恶意程序的侵害，用户很难实时判断程序性质，因此，在获得高度交互的Web服务时，如何抵御这些安全威胁绝非简单的客户端设置就可以解决的。
提高网络可信度
前面我们已经提到了IPv4存在的弊端，很多安全防范技术被忽略了，它不可避免地被新一代技术IPv6取代。IPsec安全协议就是事后发展的一种协议（如图4），而NAT(网络地址转换，Network Address Translation)解决了IP地址短缺的问题，却增加了安全风险，使真正的端到端的安全应用难以实现。端到端安全性的两个基本组件——鉴权和加密都是IPv6协议的集成组件；而在IPv4中，它们只是附加组件，因此，采用IPv6安全性会更加简便、一致。
图4
在现在的网络环境中，尤其是园区网当中，由于不存在NAT地址转换的问题，所以IPSec具备允许部署可信计算基础架构的基本特征。IPSec数据包验证能够确保整个IP报头、下一层协议（例如TCP、UPD或ICMP）报头以及数据包有效负载的数据完整性。
另外，针对数据包的单向Hash算法用以提供校验和。通信发起方计算校验和并在发送之前将其附加到数据包中；响应方则在收到数据包后为其计算校验和。如果响应方所计算出的校验和与数据包中附带的校验和完全匹配，则证明数据包在传输过程中未被修改。校验和的单向计算特性意味着其取值无法在传输过程中进行修改，这也就保证了端到端的数据传输过程的可信程度。
