服务器每天零点究竟做了什么事？

wewi

我在网关后面DMZ里架设了一台内部freebsd服务器（开启了电影和www,mail服务，未设防火墙），网关用debian（3块网卡，分别接内网，外网和DMZ），用iptables控制访问，将freebsd服务器的80，25，110，554等端口映射出来。原来一直用得很好。后来停电了一次，当然期间我也改动过iptalbes的规则（原来的忘了备份），不过到停电前都能正常工作的。可是停电之后服务器出现了一个很奇怪的现象(是之后1周左右才发现的)，www和mail还都正常，可是电影服务在每天晚上外部访问就无法播放，但是每天0点后却能恢复正常，我曾在早上测试过也有能播放的情况，但到了晚上绝对不行。所以我很想知道服务器在0点的时候究竟执行了什么操作。
    我看了网关和freebsd的crontab，发现只有freebsd有adjkerntz -a会在0-5点的1分进行，而且试验了不是这个造成的。在网关和freebsd上我用tcpdump抓包看，当不能访问的时候，外部的数据也能访问到freebsd 服务器的554端口，可是freebsd的数据到不了Internet客户端。网关内的客户端随时都可以正常播放，不受影响。
    我自己认为可能是网关内的一些客户端可能中了木马或者什么(arp攻击？) (因为有的时候个别电脑在dhcp服务分配ip地址时被分配了一个不存在的网关ip地址；很早的时候有的电脑中病毒后就算是重装，也会发生原来的ip不能ping通或连接网关服务器的情况，非要改ip才行；网络打印机也经常有远程下层文档在队列等现象)，将有问题的数据通过网关转向DMZ，debian或freebsd的机器对此做出了一些阻挡，导致internet访问出了一些问题。到了0点的时候，服务器可能执行了一个重置的操作，所以所有的服务又可以访问了。
    我白天在freebsd服务器用tcpdump抓了1天，有6M多数据，不知道有没有什么好工具可以进行分析？另外有用antiarp工具分析了一下网络，1个多小时左右，发现网络内有2,3台客户端的arp数据比一般的机器高了20多倍，一般的只有20多，这2，3台各有500-600。
    sorry, 基础知识不好，描述得不够专业。有知道的大侠帮忙分析下了。

[ 本帖最后由 wewi 于 2007-12-13 22:10 编辑 ]

lsstarboy

不是太了解，但楼主可以看一下
/etc/periodic/daily

wewi

freebsd服务器的crontab如下：

#minute hour    mday    month   wday    who     command
#
*/5     *       *       *       *       root    /usr/libexec/atrun
*/5     *       *       *       *       cacti   /usr/local/bin/php /usr/local/share/cac
ti/poller.php > /dev/null 2>&1
#
# Save some entropy so that /dev/random can re-seed on boot.
*/11    *       *       *       *       operator /usr/libexec/save-entropy
#
# Rotate log files every hour, if necessary.
0       *       *       *       *       root    newsyslog
#
# Perform daily/weekly/monthly maintenance.
1       3       *       *       *       root    periodic daily
15      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz( for details.
1,31    0-5     *       *       *       root    adjkerntz -a
0       20      *       *       6       root    /var/cron/sa.sh

那个periodic daily是3点1分执行的，不过晚上去试验看看。

wewi

今天不能播放时在网关上抓到的包，用(服务器IP)和(客户端IP)替换了实际的IP
tcpdump -i eth1 | grep  1755
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
12:15:33.639393 IP (服务器IP).1755 > (客户端IP).1801: F 3476006060:3476006060(0) ack 3289962653 win 65535
12:15:35.622281 IP (客户端IP).1857 > (服务器IP).1755: S 581001804:581001804(0) win 65535 <mss 1414,nop,nop,sackOK>
12:15:35.622504 IP (服务器IP).1755 > (客户端IP).1857: S 2756587824:2756587824(0) ack 581001805 win 65535 <mss 1460,sackOK,eol>
12:15:35.725351 IP (客户端IP).1857 > (服务器IP).1755: . ack 1 win 65535
12:15:53.117546 IP (服务器IP).1755 > (客户端IP).1805: F 2412225657:2412225657(0) ack 90686407 win 65535
12:16:13.469657 IP (服务器IP).1755 > (客户端IP).1794: F 604413288:604413288(0) ack 3354290555 win 65535
12:16:17.869463 IP (服务器IP).1755 > (客户端IP).1801: F 0:0(0) ack 1 win 65535
12:16:37.347627 IP (服务器IP).1755 > (客户端IP).1805: F 0:0(0) ack 1 win 65535
12:16:57.699717 IP (服务器IP).1755 > (客户端IP).1794: R 1:1(0) ack 1 win 65535
12:17:02.099544 IP (服务器IP).1755 > (客户端IP).1801: F 0:0(0) ack 1 win 65535

--------------------------------------------------
在Freebsd服务器上抓得包
20:26:51.591832 IP (客户端IP).2047 > (freebsd的IP).1755: S 3989581806:3989581806(0) win 65535 <mss 1414,nop,nop,sackOK>
20:26:51.591937 IP (freebsd的IP).1755 > (客户端IP).2047: S 4204720502:4204720502(0) ack 3989581807 win 65535 <mss 1460,sackOK,eol>
20:26:51.719196 IP (客户端IP).2047 > (freebsd的IP).1755: . ack 1 win 65535
20:29:50.003567 IP (客户端IP).2053 > (freebsd的IP).1755: S 1488607227:1488607227(0) win 65535 <mss 1414,nop,nop,sackOK>
20:29:50.003672 IP (freebsd的IP).1755 > (客户端IP).2053: S 3891257382:3891257382(0) ack 1488607228 win 65535 <mss 1460,sackOK,eol>
20:29:50.135327 IP (客户端IP).2053 > (freebsd的IP).1755: . ack 1 win 65535

--------------------------------------------------
在模拟环境下，能正常播放的情况, 192.168.0.206为服务器IP, 192.168.0.7为客户端IP
04:00:52.944606 IP 192.168.0.7.1689 > 192.168.0.206.1755: S 1028289189:1028289189(0) win 65535 <
04:00:52.944738 IP 192.168.0.206.1755 > 192.168.0.7.1689: S 2278810972:2278810972(0) ack 1028289p,sackOK>
04:00:52.944878 IP 192.168.0.7.1689 > 192.168.0.206.1755: . ack 1 win 65535
04:00:52.951055 IP 192.168.0.7.1689 > 192.168.0.206.1755: P 1:177(176) ack 1 win 65535
04:00:52.951203 IP 192.168.0.206.1755 > 192.168.0.7.1689: . ack 177 win 6432
04:00:52.967664 IP 192.168.0.206.1755 > 192.168.0.7.1689: P 1:121(120) ack 177 win 6432
04:00:52.968415 IP 192.168.0.7.1689 > 192.168.0.206.1755: P 177:225(4 ack 121 win 65415

wewi

果然12点后又恢复了

数据如下：
00:13:46.032955 IP (客户端IP).3174 > (服务器IP).1755: S 3659541490:3659541490(0) win 65535 <mss 1414,nop,nop,sackOK>
00:13:46.033227 IP (服务器IP).1755 > (客户端IP).3174: S 4071581604:4071581604(0) ack 3659541491 win 65535 <mss 1460,sackOK,eol>
00:13:46.115785 IP (客户端IP).3174 > (服务器IP).1755: . ack 1 win 65535
00:13:46.126188 IP (客户端IP).3174 > (服务器IP).1755: P 1:177(176) ack 1 win 65535
00:13:46.137424 IP (服务器IP).1755 > (客户端IP).3174: P 1:121(120) ack 177 win 65535
00:13:46.221737 IP (客户端IP).3174 > (服务器IP).1755: P 177:225(4 ack 121 win 65415
00:13:46.222173 IP (服务器IP).1755 > (客户端IP).3174: P 121:633(512) ack 225 win 65535
00:13:46.222377 IP (服务器IP).1755 > (客户端IP).3174: . 633:2047(1414) ack 225 win 65535

issjfk

三次握手最后一次的数据包看样子没到客户端。我觉得更有可能是你网关的问题。

zhangweizj

内网是否还有windows的机器，我想是不是中了arp了，现在这种病毒挺猖獗。