因为是刚开始看 haskell 所以很多概念不是很清楚，比如何时用 do 、“ <- ”和 let 。 Exerceise3.10 算是做出来，但是肯定不是一个好办法。希望给我改改吧，顺便解答一下我的疑问。不得不说的是编译信息相当地没有用啊，这真是太遗憾了。

因为在用 Perl-Tk 或者 Socket 时，经常会需要监视某些打开的句柄而不至于阻塞主循环，对于这些 win32 下的 Perl表现远不如Linux下来得得心应手，但这时候我基本没有什么办法。这和windows的底层select实现有关，而Perl恰恰是调用它的，但我一直认为肯定有别的替代办法，因为Tcl/Tk的fileevent就表现得很好。

下面是一个例子，用来显示 ping 的结果。这里有两个组件，一个是按钮，用来开始和停止 ping ；另一个是 text 用来显示 ping 的结果。分别用 Perl 和 Tcl/Tk 代码来实现，看看他们有什么不同。

运行的结果很让人失望，在 readable 的事件中加入 print 后而已更清楚地看到，事实上 readable 事件是没有被触发过的。这里的 fileevent 是 Tk 中处理事件触发的函数，它为句柄的两个状态（ readable ， writable ）设定触发函数，其本质上使用了系统的 select 或者 poll ，换句话说即便是用 Perl 的 select 或者 IO::Seelct 也是于事无补。文档里的原话佐证了这点“ A file is considered to be readable on same basis as the system's select() (or poll()). ”。

所以可以这么讲， win32 下的 Perl 是不大适合处理事件响应的，因而也就很难处理好处理网络相关或者界面需要运行后台长时间操作的情况。接下来换作是使用 Tcl/Tk 来实现这一功能，值得一提的是在 Perl 下 50 宽度的 button 和 text 是不等长的，所以索性在 pack 里用 fill 自动拓宽了，而在 Tcl/Tk 中没有这个问题。

为了使用同样条件的管道，屏蔽了设置非阻塞的代码行，但这么作 因为系统不得不等待管道中的进程运行结束，所以 也使得 close 没有起到应有的作用。

运行的结果很令人满意， test 没有被阻塞，在显示 ping 结果的同时，依然可以在 text 中执行输入，而且 button 也可以被顺利按下。这么看来 Tcl/Tk 比之 Perl 在 win32 下，显然在事件处理上占有优势，而且这个占优的方面是极其重要的。

前言

大约是在三年前的时候，第一次碰到 ARP 病毒，当时的情况现在依然历历在目。不断的有人断网，之后范围越来越扩大，重启了交换机之后好了一段时间，接着又开始不正常，周而复始。后来在 net130 的 BBS 上有人说是 ARP 病毒，针对于我的 huawei3526e 可以使用 display log 的命令来查看具体的冲突源发生在哪里，于是问题很快就解决了。之后的日子里为了快速定位，统计了全台的电脑 mac 地址，这样粗粗算来大约也有 300 多台的电脑了。

什么是 ARP 病毒

首先要说一下什么是 ARP 协议。在局域网中，网络中实际传输的是 “ 帧 ” ，帧里面是有目标主机的 MAC 地址的。在以太网中，一个主机要和另一个主机进行直接通信，必须要知道目标主机的 MAC 地址。但这个目标 MAC 地址是如何获得的呢？它就是通过地址解析协议获得的。所谓 “ 地址解析 ” 就是主机在发送帧前将目标 IP 地址转换成目标 MAC 地 址的过程。 ARP 协议的基本功能就是通过目标设备的 IP 地址，查询目标设备的 MAC 地址，以保证通信的顺利进行。

ARP 病毒通过发送伪装的 ARP 包，欺骗交换机或者本网段内的邻居电脑，将 MAC 地址与 IP 地址的对应关系更改为自身，从而达到截取数据包、盗取密码等目的。

就如我在上面讲到的， ARP 病毒发作的特点是会导致某个网段的瘫痪，对于不同的网段间一般来说是不会传染的。当然也有可能导致其他网段阻塞，这是因为过多的 ARP 包可能大量占用交换机 CPU 资源，并使其死机。我有一次如此的经历，一个网段中同时有两个 ARP 病毒源，结果交换机 CPU 使用率达到了 99% ，所有网段全部瘫痪，甚至无法 telnet 登陆，最后使用 console 线恢复的系统。这些只是表面现象，病毒源还通过解析捕获的数据包，极有可能获取重要的信息和密码，导致隐私被泄露、密码被盗取等等。

ARP 病毒是局域网内部安全最大的威胁者，如何能有效地防护关系到工作正常地开展，因此需要从原理上对其有深入的理解，并且针对不同的表现，作出及时、有效判断和处理，同时针对不同的场合、情况，做好防范的工作。

如何快速定位 ARP 病毒源

这个基本上是一个力气活，为什么这么说呢？因为即便是可以通过各种手段获得病毒源的 MAC 地址，但是这个 MAC 所对应的电脑是属于谁的，具体的物理位置在哪里，这就不得而知了。所以事先不得不做一些必要的调查工作，统计每一台电脑的 MAC 地址、位置和所属的人员。之后做一张表，最好是存在数据库中，这样以后可以做一个查询系统。但不是制作完成这张表就万事大吉了，还要定期维护，尤其是在部门变动和人员轮换的时候，可能需要重新做这样的统计。对于有 400 台以上电脑的网络来说，这显然不是一件轻松的工作。当然，这也是没有办法的。

这是针对于 ARP 病毒已经发作而采用的应急预案，对于平时的维护，最好是可以做一些预防的工作，这样可以有效地减少此类事件的发生，无论对管理者还是使用人员，都可以感到轻松一些。

预防 ARP 病毒发作的几个方法

不同的网络有其不同的特点，因此对于其中发生的病毒事件也有着不一样的预防方法。针对于 ARP 病毒而言，网上流传着一种似乎很 “ 神奇 ” 的办法，甚至被一些专业人士奉为一种有效的解决方案。具体是这样：在网关上绑定每一台电脑的 MAC 和 IP 地址，然后在每台电脑绑定到网管的 MAC 和 IP 。举例如下： arp –s 192.168.0.1 00-17-16-00-88-ad 。很明显这里有漏洞。首先这个命令是 windows 下的 arp 绑定指令，并适合其他的操作系统。第二，这个网络结构的网关是一台安装了 windows 的电脑，不适合使用交换机的局域网。所以说，这个办法是应用于 windows 操作系统的 NAT 单网段结构。事实上，它只是提供了一个思路，就是说要在路由端和客户端做双向的 ARP 解析绑定，这样就从根本上消除了 ARP 病毒的根源，即 ARP 解析。

对于使用交换机的网络，我们可以在交换机上绑定其下每一个网段中，每一台电脑的 MAC 和 IP 地址，然后关闭交换机的动态 APR 功能；之后在每一台电脑上，针对不同的操作系统，使用不同的指令完成网关 MAC 和 IP 的绑定。但还是和定位病毒时所遇到的困难一样，这样很费劲，而且需要不断地维护。当然，就目前的情况看来这是一种效果很好的办法，而且可以使用在绝大多数不同的网络结构中。以前我写过一个这样的解决方案，里面有很详细的配置步骤，可以到我的 blog （ http://www.cnitblog.com/gyn ）上查阅。

还有一种比较商业化的防御办法，就是设置 ARP 病毒防火墙，即是在交换机之前架设一台监控过滤器，对于检测到的威胁来源进行封锁。有些解决方案可能还会在客户端安装一个监控小软件，但这其实是有风险的，因为对于这样的解决方案，如果一旦客户端受到病毒攻击，可能使得该软件被破坏，从而导致监控失效。其实这样的商业解决方案，将其分解开来，每一个模块都是很容易实现的。首先，在防火墙上设置网管和路由，保证数据的正常进出，在 windows 和 linux 下都有 route 指令来完成该功能；第二，需要一个抓包的工具，通过它来检测网络中的 ARP 包，并对其进行分析，可以使用 pcap 工具；第三，针对分析得到的结果，比如说一个病毒源，使用一定的手段对其封锁，在 linux 环境相可以使用强大的 iptables 。

ARP 防火墙实现的几点细节

针对于以上描述的三个模块，可以具体实现如下：

首先是抓包的实现。在类 unix 的操作系统之下可以使用 pcap ，在 windows 下有 winpcap ，功能都是类似的，但又都非常强大。这里以 windows 为例，编程工具使用 ActivePerl5.8.8 。第一步，到 http://www.winpcap.org/install/default.htm 下载最新的版本，然后安装。第二，在 ppm 下安装 NetPacket 网络数据包解析工具和 Net-Pcap 及其它的简化工具 Net-PcapUtil ，其中后两者的 ppd 文件在 http://www.bribes.org/perl/ppm/Net-Pcap.ppd 和 http://www.bribes.org/perl/ppm/Net-PcapUtils.ppd 中。之后参照安装之后生成的帮助文档，我们就可以开始着手抓包了。

关键是下面这个 Net::PcapUtil 中的 loop 方法，该方法启动一个循环检测，将符合过滤要求的包送给处理程序进行分析。

callback_fn 就是包处理程序。其中 ARG 是如下结构的一下哈希表：

需要注意的两点，其一是 FILTER ，包过滤器，具体的语法可以到 winpcap 手册中查询。这里使用了“ arp or rarp ”，即是只抓取 arp 和反向 arp 解析的包。其二是 DEV ，需要使用 Net::Pcap::findalldevs(\$err) 来得到本机的网络设备列表，因为有宽带连接的存在，本地连接会被放在比较靠后的位置，一般会是在最后一位。

抓到包之后，就要对其进行解析。这里要用到 NetPacket ，它提供了针对不同网络层次的包的分析工具。局域网中的“帧”数据以太网层的数据，所以先要使用 NetPacket::Ethernet 得到其中的有效数据，之后再使用 NetPacket::ARP 得到其中的 MAC 和 IP 对应关系。如果对于相同的 MAC 地址，存在不同的 IP 地址映射，那么我们就可以确定该 MAC 地址即是病毒源。为了防止 MAC 伪装，还可以增加在 ethernet 中的检验。但是因为 IP 地址是以八进制的形式存储的，为了方便阅读和进一步利用，需要做一些转换，使其变现为 点分十进制 。

第二，对于得到的病毒源 MAC 地址，经过一定的处理之后，交由 iptables 进行进一步的处理。在这里我们要用到基于 MAC 地址的匹配，可以使用如下的指令：

这表示，在 INPUT 链中，丢弃所有源 MAC 地址为“ xx:xx:xx:xx:xx:xx ”的包。这样就封锁了所有来自病毒源的数据和请求，包括 ARP 请求。

第三，完成网关的路由功能。相比较原先的网络结构，建立了防火墙的子网，需要将网关由交换机移到防火墙上。根据防火墙连接子网的数量，防火墙上应该配有相应数量的网卡或者说是网络接口。对于单子网的结构，在这里需要两块网卡。首先，假设子网的 IP 段为 192.168.138.0/24, 交换机中的内部连接网络为 192.168.65.0/24 ，那么我们需要在防火墙中做如下的配置：

子网“ 192.168.138.0 ”中的所有的数据将通过转发，从而交给上层交换机中的 IP 地址“ 192.168.65.25 ”，这样就完成了路由功能。

结束语

局域网的管理，最重要的还是要理解这些问题发生背后的原因，以及相关的一些概念和原理，只有这样才能从根本上找出解决的办法，举一反三、触类旁通。 ARP 病毒的防护只是一个例子，它不仅仅需要网络相关的知识，还需要熟悉一些操作系统指令，这些东西都是一个系统的，因此在平时的工作中在深入专业知识的同时，要注意拓展知识的面，从而更好地应对不断进步的科技发展及其中带来和出现的一些问题。

引入文件结构保护的原因

随着越来越多的工作、数据被迁移到服务器及存储上，对于这些作为业务基础的软硬件的安全性和可靠性，我们需要提高关注度，并在尽可能的范围内提高这种可靠性，以保障工作的平稳顺利开展。

针对不同的内容，我们可以采取不同的安全保障策略。比方说，对于服务器的灾难恢复，比较方便而合适的办法是用双机热备，备机通过监视主机运行状况，实现尽可能快地恢复服务。而对于资料的存储，我们多是会选择一些实践证明了的比较可靠的数据备份和恢复方法，这些方法多是基于某种特定的数据库的，或者是数据库自身提供的。

以上两点内容是大多数管理者想得到并且可以做得不错的，我们常常会忽略一点是，作为提供某种服务的程序本身的安全性。打个比方说，提供 web 服务的 apache ，其配置和一些附属的文件可能遭到破坏，而且即便是有操作系统锁级的保护，进程也可能被恶意停止，进而破坏文件。拓展开来讲，任何以文件或者文件树形式存储的数据的安全性，一向被忽略。其结果是，我们不得不重新安装服务并配置参数，这不是一项轻松的工作，尤其是对于一些复杂的程序而言。

虽然针对不同服务的保护各不相同，但一般都需要涉及到对于该服务的文件结构保护，在此基础上在做一些进程的恢复工作等。

文件结构保护系统的架构

除了必要的防杀毒软件之外，还需要一些更一般的保护手段，因为病毒库的更新总是有滞后性的。这些手段包括建立文件结构信息备份、实时监控和文件恢复等。

首先，在确定系统一切正常的前提下，对于需要进行保护的文件结构，我们需要采集能唯一标识该结构的必要信息，至少包括一个描述文件结构的数据结构和在其中每一个文件的唯一标记。就前者而言，可以是一个多叉树或者向量，这个根据不同的工具的特性具体而定；文件唯一标记可以通过计算整个文件的 md5 码来得到，这也是现阶段在网络上发布文件尤其是大型文件时，保证文件完整性的一个通用做法，比如说 ubuntu 的发布。除了多叉树或向量数据结构需要驻留本地之外，其他的必要信息连同文件结构中所有有效文件将存储到一个可以保证安全的位置，这个位置一般是一台被隔离的服务器，通过有限的端口与存在受保护文件结构的服务器相连接，也就是监控端。

完成了文件结构的备份之后，将建立服务器之间的监控关系。因为文件遍历的本地性特点，所以主逻辑即数据结构与文件结构之间的比较需要在被监控段实现。根据比较之后的结果，包括被恶意添加或删除的文件，做出是否恢复或删除的决定。而具体到每一个文件的完整性检测，则需要被监测端将当前次文件遍历中得到的 md5 码，发送至监测端进行比较。因此，从最终的实现来看，服务器两端之间的关系并不能完全用监控来描述，事实上被监控端将负责起遍历文件结构的工作，而监控端将主要负责 md5 码比较和文件恢复的功能。

最后在监控端，通过一定的途径连接监控程序和备份信息，实现文件按顺序有效地回传，这样就基本上形成了一个文件结构保护系统的框架。

需要注意的一些细节

文件结构信息的采集需要在系统建立之初就准备就绪，然后通过人工拷贝的方法移植到监控端。这个采集过程相对来说比较简单，只需要一次文件结构的遍历就可以实现。监控端的信息存储可以考虑使用数据库，而在存储文件的时候，根据具体的回传特点可以直接存储在文件系统之下或者以 blob 的形式存入数据库。

相比于略显简单的初始化，保护系统实现的关键环节在于文件结构与数据结构的比较以及如何准确地回传文件。

首先数据结构的建立需要在保护系统启动的初始化环节完成，之后它将作为整个系统运行的基础，循环地将文件结构与它进行对比。而该对比过程可以通过两种方法来实现。第一：两次遍历，即数据结构和文件结构遍历。这么做的好处是实现难度不大，尤其是在文件结构遍历部分，可以任意选择深度或广度遍历。但是针对遍历中每个节点遇到的文件或文件夹，不得不查询一次数据结构，对于设计不佳的数据结构，这么做的结果可能又是一次遍历，这就增加了运行的时长。第二：一次遍历，即在数据结构和文件结构同时以一种相对协调的步调向下遍历。这里所说的向下即是说，需要在完成本层次遍历的基础上才能继续下一个层次，也就是层次优先遍历。这样的做法需要在设计上保证数据结构与文件结构具有类似性，而对于层次的控制也完全依靠人工逻辑完成，但在运行上将获得比前一种方法快一个数量级以上的优势。

在文件回传方面，由于存在很大可能性是需要恢复的一个文件列表，所以应准确控制其中每一个文件恢复的启动与截至。可以采用架设 ftp 服务器的方法，在传输单文件时阻塞本地剩余传输队列中的文件。在这里采用了这种模式，但未直接使用 ftp ，而是采用了一种简化的模拟方式：被监控端维护一个文件处理队列，通过阻塞的方式和先进先出的顺序来处理 文件句柄 ；建立了两个 socket 连接，其中之一在监控端接受被监控端发出的指令并启动数据传输，另一个在被监控端接受来自监控端的文件传输完成信号并关闭本地文件句柄，然后通知启动下一个文件传输。

Perl 实现的几点建议

一： 对于这种通过网络来连接的服务，整体的框架可以考虑使用 poe ，这将极大地减少底层代码的维护量，而将精力主要集中到业务逻辑的实现上来。尤其是在合理利用 component 的情况下，一段几十行的 socket 代码可能会被压缩为短短几行。更为重要的是， poe 在单线程内实现了多任务模式，虽然依旧会阻塞在长任务执行过程中，但这方便各个任务之间信息的传递和资源的共享。对于未来其他模块功能的增加，也 提供了 一个可扩展的基础。比如，需要为客户端提供一个可视的操作界面，只需引入 Tk ， poe 会在变量表中自动添加根元素 $poe_main_window 。

二： 由于文件结构信息的量一般不是很大，因此在事先未安装其他数据库的情况下，信息的存储可以考虑使用轻量级的 sqlite 。它没有守护进程，一般以嵌入的形式 服务 于各个 任务 中。

三： 体现文件结构逻辑的数据结构，可以使用 hash 表来实现，在这里 hash 表起得是多叉树的作用。打个比方，针对绝对路径

其数据结构将是 :

也就是说任意的目录是一个 hash 引用，而最终的文件节点是一个内容为“ f ”的 text 变量。那么在遍历时，就可以通过 ref 节点类型来判断是目录还是文件。

四： 在处理关闭文件传输的指令时，可以考虑使用 ikc 来远程调用本地指令，这实际上是简化了由远程发指令、本地翻译再到本地指令执行这一连串的过程，用在这里也方便未来丰富远程指令。