|
之前发邮件,没开到,今天给停了,发了ticket,还没回复!
这个问题怎么解决!
- You appear to be running an open SNMP server at IP address 107.161.118.168 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 SNMP-speaking device in one or more of these ways:
- - Block queries made by unauthorized addresses. This can be done with an ACL or other firewall rule.
- - Use a different query string than "public" and which cannot be easily guessed by a 3rd party.
- - Disable SNMP entirely.
- 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 SNMP responses sent to us by your device during the attack are given below.
- Date/timestamps (far left) are UTC.
- 2015-03-14 03:26:05.187035 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 1305) 107.161.118.168.161 > 66.150.214.x.27015: UDP, length 1277
- 0x0000: 4500 0519 0000 4000 3811 a669 6ba1 12a6 E.....@.8..ik...
- 0x0010: 4296 d68d 00a1 6987 0505 d8a2 3082 04f9 B.....i.....0...
- 0x0020: 0201 0104 0670 7562 6c69 63a2 8204 ea02 .....public.....
- 0x0030: 047b 73cc 1302 0100 0201 0030 8204 da30 .{s........0...0
- 0x0040: 5606 082b 0601 0201 0101 0004 4a4c 696e V..+........JLin
- 0x0050: 7578 ux
- (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 "141".)
复制代码
给我个解决办法,停止了snmp服务就可以了是吧! |
|