收到 Digital Ocean 一封邮件(Abuse Complaint), 这个应该咋处理啊?
inet6 · 2015-02-20 06:33:50 +08:00 · 2450 次点击这是一个创建于 3556 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天收到一封邮件，我在DO上配置了一个SS代理，翻墙用的。用了一年多了，一直平安无事，这次是怎么了? 我贴一下邮件内容(很长...)， 我应该怎么处理一下，怎么回复啊，是因为SS的密码泄漏了而被人用来攻击了么?
Support Request Posted on 02/19/15 at 12:42 UTC
Please review the following abuse complaint and provide us with a resolution:
******************************
You appear to be running an open recursive resolver at IP address 我的IP地址 that participated in an attack against a customer of ours, generating large UDP responses to spoofed queries, with those responses becoming fragmented because of their size.
Please consider reconfiguring your resolver in one or more of these ways:
- To only serve your customers and not respond to outside IP addresses (in BIND, this is done by defining a limited set of hosts in "allow-query"; with a Windows DNS server, you would need to use firewall rules to block external access to UDP port 53)
- To only serve domains that it is authoritative for (in BIND, this is done by defining a limited set of hosts in "allow-query" for the server overall but setting "allow-query" to "any" for each zone)
- To rate-limit responses to individual source IP addresses (such as by using DNS Response Rate Limiting or iptables rules)
More information on this type of attack and what each party can do to mitigate it can be found here: http://www.us-cert.gov/ncas/alerts/TA13-088A
If you are an ISP, please also look at your network configuration and make sure that you do not allow spoofed traffic (that pretends to be from external IP addresses) to leave the network. Hosts that allow spoofed traffic make possible this type of attack.
Example DNS responses from your resolver during this attack are given below.
Date/timestamps (far left) are UTC.
2015-02-19 04:33:56.305717 IP (tos 0x0, ttl 56, id 33341, offset 0, flags [+], proto UDP (17), length 1500) 我的IP地址.53 > 208.146.44.x.2894: 65264 28/0/1 pidarastik.ru. SOA[|domain]
0x0000: 4500 05dc 823d 2000 3811 a96b 80c7 b3e6 E....=..8..k....
0x0010: d092 2c28 0035 0b4e 0fff 3992 fef0 8180 ..,(.5.N..9.....
0x0020: 0001 001c 0000 0001 0a70 6964 6172 6173 .........pidaras
0x0030: 7469 6b02 7275 0000 ff00 01c0 0c00 0600 tik.ru..........
0x0040: 0100 0001 7b00 2f03 6e73 3108 7370 6163 ....{./.ns1.spac
0x0050: 6577 ew
2015-02-19 04:33:56.479486 IP (tos 0x0, ttl 56, id 33342, offset 0, flags [+], proto UDP (17), length 1500) 我的IP地址.53 > 208.146.44.x.52563: 49998 28/0/1 pidarastik.ru. SOA[|domain]
0x0000: 4500 05dc 823e 2000 3811 a96a 80c7 b3e6 E....>..8..j....
0x0010: d092 2c28 0035 cd53 0fff b32e c34e 8180 ..,(.5.S.....N..
0x0020: 0001 001c 0000 0001 0a70 6964 6172 6173 .........pidaras
0x0030: 7469 6b02 7275 0000 ff00 01c0 0c00 0600 tik.ru..........
0x0040: 0100 0001 7b00 2f03 6e73 3108 7370 6163 ....{./.ns1.spac
0x0050: 6577 ew
2015-02-19 04:33:57.652575 IP (tos 0x0, ttl 56, id 33343, offset 0, flags [+], proto UDP (17), length 1500) 我的IP地址.53 > 208.146.44.x.13219: 27099 28/0/1 pidarastik.ru. SOA[|domain]
0x0000: 4500 05dc 823f 2000 3811 a969 80c7 b3e6 E....?..8..i....
0x0010: d092 2c28 0035 33a3 0fff b262 69db 8180 ..,(.53....bi...
0x0020: 0001 001c 0000 0001 0a70 6964 6172 6173 .........pidaras
0x0030: 7469 6b02 7275 0000 ff00 01c0 0c00 0600 tik.ru..........
0x0040: 0100 0001 7a00 2f03 6e73 3108 7370 6163 ....z./.ns1.spac
0x0050: 6577 ew
(The final octet of our customer's IP address is masked in the above output because some automatic parsers become confused when multiple IP addresses are included. The value of that octet is "40".)
-John
President
Nuclearfallout, Enterprises, Inc. (NFOservers.com)
(We're sending out so many of these notices, and seeing so many auto-responses, that we can't go through this email inbox effectively. If you have follow-up questions, please contact us at [email protected].)
******************************
Please note that generating multiple abuse complaints in a short period of time may lead to your account being suspended.
Support Request Posted on 02/19/15 at 12:42 UTC
Please review the following abuse complaint and provide us with a resolution:
******************************
You appear to be running an open recursive resolver at IP address 我的IP地址 that participated in an attack against a customer of ours, generating large UDP responses to spoofed queries, with those responses becoming fragmented because of their size.
Please consider reconfiguring your resolver in one or more of these ways:
- To only serve your customers and not respond to outside IP addresses (in BIND, this is done by defining a limited set of hosts in "allow-query"; with a Windows DNS server, you would need to use firewall rules to block external access to UDP port 53)
- To only serve domains that it is authoritative for (in BIND, this is done by defining a limited set of hosts in "allow-query" for the server overall but setting "allow-query" to "any" for each zone)
- To rate-limit responses to individual source IP addresses (such as by using DNS Response Rate Limiting or iptables rules)
More information on this type of attack and what each party can do to mitigate it can be found here: http://www.us-cert.gov/ncas/alerts/TA13-088A
If you are an ISP, please also look at your network configuration and make sure that you do not allow spoofed traffic (that pretends to be from external IP addresses) to leave the network. Hosts that allow spoofed traffic make possible this type of attack.
Example DNS responses from your resolver during this attack are given below.
Date/timestamps (far left) are UTC.
2015-02-19 04:33:56.305717 IP (tos 0x0, ttl 56, id 33341, offset 0, flags [+], proto UDP (17), length 1500) 我的IP地址.53 > 208.146.44.x.2894: 65264 28/0/1 pidarastik.ru. SOA[|domain]
0x0000: 4500 05dc 823d 2000 3811 a96b 80c7 b3e6 E....=..8..k....
0x0010: d092 2c28 0035 0b4e 0fff 3992 fef0 8180 ..,(.5.N..9.....
0x0020: 0001 001c 0000 0001 0a70 6964 6172 6173 .........pidaras
0x0030: 7469 6b02 7275 0000 ff00 01c0 0c00 0600 tik.ru..........
0x0040: 0100 0001 7b00 2f03 6e73 3108 7370 6163 ....{./.ns1.spac
0x0050: 6577 ew
2015-02-19 04:33:56.479486 IP (tos 0x0, ttl 56, id 33342, offset 0, flags [+], proto UDP (17), length 1500) 我的IP地址.53 > 208.146.44.x.52563: 49998 28/0/1 pidarastik.ru. SOA[|domain]
0x0000: 4500 05dc 823e 2000 3811 a96a 80c7 b3e6 E....>..8..j....
0x0010: d092 2c28 0035 cd53 0fff b32e c34e 8180 ..,(.5.S.....N..
0x0020: 0001 001c 0000 0001 0a70 6964 6172 6173 .........pidaras
0x0030: 7469 6b02 7275 0000 ff00 01c0 0c00 0600 tik.ru..........
0x0040: 0100 0001 7b00 2f03 6e73 3108 7370 6163 ....{./.ns1.spac
0x0050: 6577 ew
2015-02-19 04:33:57.652575 IP (tos 0x0, ttl 56, id 33343, offset 0, flags [+], proto UDP (17), length 1500) 我的IP地址.53 > 208.146.44.x.13219: 27099 28/0/1 pidarastik.ru. SOA[|domain]
0x0000: 4500 05dc 823f 2000 3811 a969 80c7 b3e6 E....?..8..i....
0x0010: d092 2c28 0035 33a3 0fff b262 69db 8180 ..,(.53....bi...
0x0020: 0001 001c 0000 0001 0a70 6964 6172 6173 .........pidaras
0x0030: 7469 6b02 7275 0000 ff00 01c0 0c00 0600 tik.ru..........
0x0040: 0100 0001 7a00 2f03 6e73 3108 7370 6163 ....z./.ns1.spac
0x0050: 6577 ew
(The final octet of our customer's IP address is masked in the above output because some automatic parsers become confused when multiple IP addresses are included. The value of that octet is "40".)
-John
President
Nuclearfallout, Enterprises, Inc. (NFOservers.com)
(We're sending out so many of these notices, and seeing so many auto-responses, that we can't go through this email inbox effectively. If you have follow-up questions, please contact us at [email protected].)
******************************
Please note that generating multiple abuse complaints in a short period of time may lead to your account being suspended.
 |
1
imlonghao 2015-02-20 08:32:05 +08:00 via Android  1
检查一下你的53端口是否开了Bind之类的东西
|
 |
2
extreme 2015-02-20 08:39:59 +08:00 1
DNS用的是UDP协议，有人伪造来源，向你发出DNS查询的请求，你的DNS服务器就把回应的数据包发送给“所宣称的来源IP”，由于请求次数多，频率高，因此就实现了“借DNS服务器发动DDOS攻击”的目标。
如果不是公用DNS服务器，只提供给本机用，就让BIND只Listen 127.0.0.1:53吧。 |
 |
3
DreaMQ 2015-02-20 08:50:07 +08:00 1
如果你没有运行 DNS 服务器，只是 SS， 用 iptables 封掉 53 端口就好了
然后回复说没有运行 BIND，已加强安全措施，应该就没事了 |
 |
4
msg7086 2015-02-20 09:25:43 +08:00
为什么要开启DNS服务呢。
|
 |
5
hjc4869 2015-02-20 12:08:11 +08:00
有些端口是必须封的，论坛里好像有人发过
|
 |
6
inet6 OP 比较纠结的是，我根本没有开DNS服务...
|
 |
7
luo362722353 2015-02-20 12:36:33 +08:00 via iPhone
干掉53
|
|
10
inet6 OP @snnn
@imlonghao 我水平比较菜，可能我不知道。帮我看一下吧。谢谢。 inet@hope:~$ netstat -nlp (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:36837 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN - tcp6 0 0 :::443 :::* LISTEN - tcp6 0 0 :::36837 :::* LISTEN - tcp6 0 0 :::80 :::* LISTEN - udp 0 0 127.0.0.1:4500 0.0.0.0:* - udp 0 0 128.199.179.230:4500 0.0.0.0:* - udp 0 0 0.0.0.0:1701 0.0.0.0:* - udp 0 0 0.0.0.0:443 0.0.0.0:* - udp 0 0 127.0.0.1:500 0.0.0.0:* - udp 0 0 128.199.179.230:500 0.0.0.0:* - udp6 0 0 :::443 :::* - udp6 0 0 ::1:500 :::* - Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ACC ] STREAM LISTENING 9278 - /var/run/mysqld/mysqld.sock unix 2 [ ACC ] STREAM LISTENING 7503 - /var/run/dbus/system_bus_socket unix 2 [ ACC ] STREAM LISTENING 10377 1631/tmux /tmp/tmux-1000/default unix 2 [ ACC ] STREAM LISTENING 6975 - @/com/ubuntu/upstart unix 2 [ ACC ] SEQPACKET LISTENING 7333 - /run/udev/control unix 2 [ ACC ] STREAM LISTENING 9128 - /var/run/pluto/pluto.ctl unix 2 [ ACC ] STREAM LISTENING 8885 - /var/run/acpid.socket unix 2 [ ACC ] STREAM LISTENING 10452 - /var/run/occtl.socket unix 2 [ ACC ] STREAM LISTENING 10454 - /var/run/ocserv-socket.1647 |
|
11
inet6 OP 补充一点信息: 这个上面运行了wordpress一个，ss服务一个，还有开源的anyconnect服务一个。
1. wordpress废弃掉了，根本没用过。 2. ss服务我在家里用。 3. anyconnect我出门的时候在iphone上用。 我就是对着网上的教程操作的，自己也没深入研究过这几个软件。对网络也一知半解的，虽然我也是程序员，（惭愧啊），一直在做游戏，对linux和网络的了解实在是少的可怜... |
 |
12
liyaoxinchifan 2015-02-20 14:29:25 +08:00 1
# Completed on Fri Feb 13 09:27:36 2015
# Generated by iptables-save v1.4.7 on Fri Feb 13 09:27:36 2015 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [21:2028] -A INPUT -p tcp -m tcp --dport anyconnect端口 -j ACCEPT -A INPUT -p tcp -m tcp --dport 你的ssh端口 -j ACCEPT -A INPUT -p tcp -m tcp --dport ss端口 -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on Fri Feb 13 09:27:36 2015 编辑/etc/sysconfig/iptables文件，如果没用到nat链的话，把上面的规则按你的情况修改之后覆盖进去，重启iptables应该就不会受攻击了 |
|
13
liyaoxinchifan 2015-02-20 14:30:52 +08:00 1
@liyaoxinchifan 里面的80端口没有开，如果wrodpress想访问的话加一条 -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 在最上面就好
|
|
14
inet6 OP @liyaoxinchifan 非常感谢！
|
|
15
liyaoxinchifan 2015-02-20 14:36:32 +08:00 1
@liyaoxinchifan 没有关注过anyconnect，刚才看了下貌似需要iptables的nat链的，楼主只覆盖filter链就好， 貌似还需要允许udp -A INPUT -p tcp -m udp --dport anyconnect端口 -j ACCEPT
|
|
16
inet6 OP @liyaoxinchifan 谢谢你，我得好好研究一下linux的防火墙。网络的技能太少了，只会用ifconfig, traceroute, ping, netstat这几个简单的命令查看网络通不通... 人家发个邮件过来，都看不懂...
|
 |
18
acgeo 2015-02-20 16:01:09 +08:00
拒绝使用DO
马勒戈壁的。。。。 |
 |
19
benjiam 2015-02-20 20:04:55 +08:00 via Android
他根本没有开53端口,你们给的建议有什么意思吗？
|
 |
20
Yamade 2015-02-20 23:48:49 +08:00
奇怪,他都没开 53 攻击何来?看下系统日志.
|
 |
21
docee 2015-02-21 13:34:27 +08:00
建议把SSH端口换掉。。。。
|
Select Language