解决通过 crontab 调用 FTP 命令行客户端未正确退出导致大量 FTP 进程滞留内存的问题

作者:wiLdGoose 发布时间:August 23, 2019 分类:技术 Technology

前阵子写了个小脚本,用于异地备份与自动删除过期文件。使用一段时间后发现异常,表现为:

ps aux | grep ftp

通过这个命令显示有大量的 FTP 客户端进程滞留内存。一开始以为传输未结束导致,经过文件比对后发现传输确实已结束。辣么为何 FTP 进程未能自动退出呢?

网上查询后有人说使用 passive 命令,但我的脚本中已经对 FTP 命令设置了 -inp 的参数,其中参数 p 即启用被动模式传输。若再使用 passive 命令,会使 FTP 从被动模式切换回默认的主动模式,导致连接与传输失败。

权宜之计是在 crontab 中,在定时备份的任务后若干小时再执行这个任务:

for i in `ps aux | grep "ftp -inp" | grep -v grep | awk '{ print $2 }'`; do kill -9 $i; done

确实挺 low 的,Google 了半天貌似没发现还有其他不幸遭遇的同志。若有更好的解决方案,跪求留言。

通过双向绑定防止 ARP 欺骗

作者:wiLdGoose 发布时间:February 1, 2008 分类:技术 Technology

又是一个不眠之夜,写点东西好了。

上个月托管在某电信机房的服务器遭受ARP 欺骗,虽然不是我的服务器中毒,但还是受到了一定程度的影响。事后我认识到双向绑定的重要性,于是和机房联系做了双绑。

对于双向绑定,我的理解是在下级客户端与上级网关上分别知道自己与对方的 IP 及其 MAC 地址,并且这是一个静态的关系。ARP 协议中,默认的关系是 dynamic,而且这与使用 DHCP 与否没有关系。我们来做个实验:

C:\>arp -a
Interface: 192.168.0.201 --- 0x10003
  Internet Address      Physical Address      Type
  192.168.0.1           00-14-78-99-3d-a9     dynamic
  192.168.0.50          00-0b-2f-10-12-ab     dynamic
C:\>arp -d
C:\>arp -s 192.168.0.1 00-14-78-99-3d-a9
C:\>arp -a
Interface: 192.168.0.201 --- 0x10003
  Internet Address      Physical Address      Type
  192.168.0.1           00-14-78-99-3d-a9     static
  192.168.0.50          00-0b-2f-10-12-ab     dynamic

这个例子已经说明了问题。绑定后的状态一直都是 static,直到系统下次重启。

如果服务器处于双线机房,或者由于其他原因,具有一个以上的 IP 地址,其操作方式雷同。我的服务器上有两个 IP 地址,arp -a 后的结果是这样的:

C:\>arp -a
Interface: 60.12.104.24 --- 0x10003
  Internet Address      Physical Address      Type
  60.12.104.1           00-11-bb-3e-62-3f     dynamic
  122.225.96.1          00-11-bb-3e-62-3f     dynamic

我设计了以下的脚本。将它放入计划任务,并设置为每次系统启动时启动该脚本,配合机房在网关设备上对该服务器 IP 与其 MAC 地址的绑定,就可以使 Windows 操作系统的服务器具备防止 ARP 欺骗的能力:

@echo off
arp -d
arp -s 122.225.96.1 00-11-bb-3e-62-3f
arp -s 60.12.104.1 00-11-bb-3e-62-3f
exit

对于类 Unix 操作系统的操作也基本相似。首先通过 arp -a 获取当前信息:

#arp -a
? (60.12.104.1) at 00:11:bb:3e:62:3f on em0 [ethernet]
? (60.12.104.31) at 00:0e:0c:3c:7d:ba on em0 permanent [ethernet]
? (122.225.96.1) at 00:11:bb:3e:62:3f on em0 [ethernet]
nstech (122.225.96.31) at 00:0e:0c:3c:7d:ba on em0 permanent [ethernet]

然后执行单向绑定,注意类 Unix 系统下对 MAC 地址的书写方式:

#arp -s 122.225.96.1 00:11:bb:3e:62:3f
#arp -s 60.12.104.1 00:11:bb:3e:62:3f

服务器上操作完成后,要求机房在网关设备上对该服务器 IP 与其 MAC 地址的绑定,就实现了传说中的双向绑定。

如果服务器当前正在遭受 ARP 欺骗攻击,在机房没有对中毒服务器实施断网处理前,我们只能每隔一段时间就执行一下上面的操作。为了方便起见,我们可以这样做:

#vi /etc/ipmac

将需要做绑定的网关 IP 与其 MAC 地址写入这个文件。每行一个,中间用空格隔开:

122.225.96.1 00:11:bb:3e:62:3f
60.12.104.1 00:11:bb:3e:62:3f

然后:

#crontab -e

添加一行:

*/1 * * * * /usr/sbin/arp -f /etc/ipmac

这里的“*/1”代表每隔 1 分钟执行一次,可以根据实际情况调整。和平时期,我一般设置为 10 分钟执行一次:

* */6 * * * /usr/sbin/arp -f /etc/ipmac

战争时期就设置为 5 秒执行一次:

*/12 * * * * /usr/sbin/arp -f /etc/ipmac

对于 Windows 操作系统,只要重新设置一下计划任务的属性,让它每隔一段时间执行一下脚本就可以了。

咳咳,综上所述,这个解决方案是一个临时性解决方案,比较适用于非战时的防御。如果真的遭遇 ARP 欺骗攻击,第一件事还是通过 arp -a 找到源头,然后将信息报告给机房,让机房尽快将中毒的机器断网才是上策。

听说 FreeBSD 系统下面有一个软件叫做“ipguard”,可以有效防御 ARP 欺骗。有空研究一下。

  1. 1