防火墙毕业论文
世界上的防火墙至少会说两个字:是或者不是，直接说就是接受或者拒绝。最简单的防火墙是以太网桥。但是几乎没有人会认为这种原始的防火墙能有多大用处。大多数防火墙使用各种技术和标准。这些防火墙有多种形式:有些取代了系统上已经配备的TCP/IP协议栈；有些在现有的协议栈上构建自己的软件模块；有些只是一个独立的操作系统。还有一些面向应用程序的防火墙只为特定类型的网络连接(如SMTP或HTTP协议)提供保护。还有一些基于硬件的防火墙产品，其实应该归类为安全路由器。以上这些产品都可以称之为防火墙，因为它们的工作方式都是一样的:分析进出防火墙的数据包，决定是让其通过还是扔到一边。
所有防火墙都有IP地址过滤功能。此任务是检查IP报头，并根据其IP源地址和目的地址做出释放/丢弃决定。看下图。两个网段之间有防火墙。防火墙的一端有一台UNIX计算机，另一个网段有一台PC客户端。
当PC客户端向UNIX计算机发送telnet请求时，PC的telnet客户端生成一个TCP数据包，并将其发送到本地协议栈进行发送。接下来，协议栈将这个TCP包“插入”到一个IP包中，然后通过PC的TCP/IP栈定义的路径发送给UNIX计算机。在本例中，IP数据包必须穿过PC和UNIX计算机之间的防火墙才能到达UNIX计算机。
现在我们“命令”(用技术术语来说，就是配置)防火墙拒绝所有发送到UNIX计算机的数据包。完成这项工作后，“心”更好的防火墙会通知客户端程序！由于发送到目的地的IP数据无法转发，因此只有与UNIX计算机位于同一网段的用户才能访问UNIX计算机。
另一种情况，你可以命令防火墙给那台可怜的PC找茬，别人的包过了就不行了。这是防火墙最基本的功能:根据IP地址进行转发判断。但是，这一招到了大场面就玩不了了。由于黑客可以使用IP地址欺骗技术，伪装成合法地址的计算机可以穿越信任该地址的防火墙。然而，基于地址的转发决策机制仍然是最基本和最必要的。还有一点需要注意的是，不要使用DNS主机名来构建过滤表。伪造DNS比欺骗IP地址要容易得多。
服务器TCP/UDP端口过滤
仅通过地址过滤数据是不可行的。另一个原因是目标主机上运行着许多通信服务。例如，我们不希望用户通过telnet连接到系统，但这并不意味着我们必须禁止他们同时使用SMTP/POP邮件服务器，不是吗？所以，除了地址，我们还需要过滤服务器的TCP/ UDP端口。
例如，默认的telnet服务连接端口号是23。如果我们不允许PC客户端与UNIX电脑建立telnet连接(此时我们认为是服务器)，那么我们只需要命令防火墙检查发送到UNIX服务器的数据包，过滤掉目标端口号为23的数据包。这样的话，是不是可以把IP地址和目标服务器的TCP/UDP端口结合起来作为过滤标准，实现一个相当可靠的防火墙呢？不，没那么简单。
客户端也有TCP/UDP端口。
TCP/IP是一种端到端协议，每个网络节点都有一个唯一的地址。网络节点的应用层也是如此。应用层的每个应用和服务都有自己对应的“地址”，即端口号。只有当地址和端口可用时，我们才能在客户端和服务器的各种应用程序之间建立有效的通信。例如，telnet服务器监听端口23上的入站连接。同时telnet客户端也有端口号，不然客户端的IP栈怎么知道一个数据包属于哪个应用？
由于历史原因，几乎所有的TCP/IP客户端都使用随机分配的大于1023的端口号。只有UNIX计算机上的root用户可以访问1024以下的端口，这些端口仍然保留给服务器上的服务。因此，除非我们让所有端口号大于1023的数据包进入网络，否则各种网络连接都无法正常工作。
这对防火墙来说很麻烦。如果所有入站端口都被阻止，则所有客户端都不能使用网络资源。因为服务器响应外部连接请求发送的入站数据包(即进入防火墙)无法通过防火墙的入站过滤。反过来，开放所有高于1023的端口是否可行？不完全是。因为很多服务使用大于1023的端口，比如X client，基于RPC的NFS服务以及众多非UNIX的IP产品(NetWare/IP)。那么如果所有符合1023端口标准的数据包都被允许进入网络，网络就能说是安全的吗？就连这些客户端程序也不敢说自己足够安全。
双向过滤
好吧，我们换个角度想。我们给防火墙下命令:已知服务的数据包可以进来，所有其他的都被阻挡在防火墙之外。例如，如果您知道用户想要访问Web服务器，那么只有源端口号为80的数据包才能进入网络:
然而，新的问题出现了。首先，你怎么知道你要访问的服务器有哪些正在运行的端口号？像HTTP这样的服务器可以随意配置，使用的端口也可以随意配置。如果你像这样设置防火墙，你将不能访问任何不使用标准端口号的网站！反过来，你也不能保证进入网络的端口号为80的数据包一定来自Web服务器。有的黑客用这个自制入侵工具，在本机80端口运行！
检查ACK位
我们不相信源地址和源端口。在这个必须与黑客共舞的疯狂世界里，我们还能相信什么？好在事情还没到绝望的地步。有一些对策，但是这种方法只能用于TCP协议。
TCP是一种可靠的通信协议，“可靠”一词意味着该协议具有一些特殊的属性，包括纠错机制。为了实现其可靠性，每个TCP连接都必须经过“握手”过程来交换连接参数。此外，在发送其他后续数据包之前，每个发送的数据包都必须得到确认响应。然而，没有必要用特殊的ACK包来响应每个TCP包。实际上，这个功能可以通过在TCP报头上设置一个特殊的位来完成。因此，每当产生响应包时，ACK位都应置1。连接会话的第一个包不用于确认，所以它不设置ACK位，后续会话中交换的TCP包将设置ACK位。
例如，一台PC启动到远程Web服务器的连接，该服务器会生成一个未设置ACK位的连接请求数据包。当服务器响应请求时，服务器发回一个设置了ack位的数据包，并在数据包中标记从客户端接收的字节数。然后，客户端用自己的响应包响应数据包，该响应包也设置ACK位并标记从服务器接收的字节数。通过监控ACK位，我们可以将进入网络的数据限制在响应数据包的范围内。因此，远程系统根本无法启动TCP连接，但它可以响应收到的数据包。
这个机制并不完美。举个简单的例子，假设我们有一个内部Web服务器，那么必须打开端口80，这样外部请求才能进入网络。此外，不可能监控UDP数据包的ack位，因为UDP数据包根本没有ACK位。还有一些TCP应用，比如FTP，连接必须由这些服务器程序自己发起。
FTP带来的困难
一般的互联网服务在所有通信中只使用一对端口号，而FTP程序在连接时使用两对端口号。第一对端口号用于FTP的“命令通道”，为登录和执行命令提供通信链接，而另一对端口号用于FTP的“数据通道”，提供客户端和服务器之间的文件传输。
在正常的FTP会话中，客户端首先向服务器的端口21(命令通道)发送TCP连接请求，然后执行LOGIN、DIR等各种命令。一旦用户请求服务器发送数据，FTP服务器就使用其20端口(数据通道)启动与客户数据端口的连接。问题是如果服务器向客户端发起连接传输数据，会发送一个没有设置ACK位的数据包，防火墙会根据刚才的规则拒绝这个数据包，也就是说数据传输无望。通常只有高级防火墙，也就是足够智能的防火墙，才能看到客户端刚刚告诉服务器的端口，然后允许到那个端口的入站连接。
UDP端口过滤
好了，现在我们回过头来看看如何解决UDP问题。我刚才说了，UDP包没有ack位，所以不能用ACK位过滤。UDP是一种“不可靠”的通信，无论如何都会发送出去。这种类型的服务通常用于通信任务，如广播、路由和多媒体。NFS、DNS、WINS、NetBIOS-over-TCP/IP和NetWare/IP都使用UDP。
似乎最简单可行的方法就是不允许建立入站UDP连接。防火墙设置为仅转发来自内部接口的UDP数据包，而不转发来自外部接口的UDP数据包。现在的问题是，例如，DNS名称解析请求使用UDP。如果您提供DNS服务，至少必须允许一些内部请求通过防火墙。也有像IRC这样的客户端程序也使用UDP。如果您希望您的用户使用它，您也应该让他们的UDP数据包进入网络。我们能做的是限制从本地到可信站点的连接。然而，什么是值得信赖的！如果黑客采取地址欺骗的方法，岂不是又回到了老路？
一些新的路由器可以通过“记忆”出站UDP包来解决这个问题:如果入站UDP包与最新出站UDP包的目的地址和端口号匹配，就让它进来。如果你在内存中找不到匹配的UDP包，你就得拒绝它！但是，我们如何确定生成数据包的外部主机就是内部客户端想要与之通信的服务器呢？如果黑客谎称DNS服务器的地址，理论上当然可以从DNS附带的UDP端口发起攻击。只要你允许DNS查询和反馈包进入网络，这个问题就必然存在。解决方案是使用代理服务器。
所谓代理服务器，顾名思义，就是代表你的网络与外界打交道的服务器。代理服务器不允许网络内外的任何直接连接。它本身提供了公有* * *和私有DNS、邮件服务器等功能。代理服务器会重写数据包，而不是简单地转发它。它给人的感觉是网络中的主机站在网络的边缘，但实际上它们都藏在代理的背后，只不过是以代理的面具出现。
总结
IP地址可能是假的，这是由IP协议的源路径机制造成的，它告诉路由器不要对数据包使用正常路径，而是根据包头中的路径来传输数据包。然后黑客就可以利用系统的IP地址获取返回的数据包。一些高级防火墙允许用户阻止源路由。通常，我们的网络通过一条路径连接到ISP，然后进入互联网。禁用源路由将强制数据包沿正常路径返回。
此外，我们需要知道防火墙在拒绝数据包时还做了哪些工作。例如，防火墙是否向连接发起系统发回了“主机不可达”的ICMP消息？还是防火墙真的没做别的？这些问题可能存在安全隐患。ICMP“主机不可达”消息会告诉黑客“部分端口被防火墙封锁”，黑客可以立刻从这条消息中嗅到一些东西。如果ICMP“主机不可达”是通信错误，那么一个诚实的系统可能真的什么都没发。另一方面，没有响应会使发起通信的系统一直尝试建立连接，直到应用程序或协议栈超时，最终用户只能得到一条错误消息。当然，这种方式会让黑客无法判断一个端口是关闭的还是没有使用的。