tcpdump -vv
这个命令后:
14:58:14.568332 IP (tos 0x0, ttl 64, id 65523, offset 0, flags [DF], proto UDP (17), length 73)
150.138.168.10,83.143.168.10,238.87.162.10这些是不是IP呀?
iZ329ljpa3gZ.49517 > 10.202.72.116.domain: [bad udp cksum 8908!] 59574+ PTR? 150.138.168.10.in-addr.arpa. (45)
14:58:14.569975 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.168.138.150 tell 10.168.143.83, length 42
14:58:14.570219 IP (tos 0xc0, ttl 58, id 47164, offset 0, flags [none], proto UDP (17), length 123)
10.202.72.116.domain > iZ329ljpa3gZ.49517: [udp sum ok] 59574 NXDomain* q: PTR? 150.138.168.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
14:58:14.570476 IP (tos 0x0, ttl 64, id 65525, offset 0, flags [DF], proto UDP (17), length 72)
iZ329ljpa3gZ.36626 > 10.202.72.118.domain: [bad udp cksum 8b39!] 51551+ PTR? 83.143.168.10.in-addr.arpa. (44)
14:58:14.572439 IP (tos 0xc0, ttl 58, id 24514, offset 0, flags [none], proto UDP (17), length 122)
10.202.72.118.domain > iZ329ljpa3gZ.36626: [udp sum ok] 51551 NXDomain* q: PTR? 83.143.168.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (94)
14:58:14.573416 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.168.143.84 tell 10.168.138.150, length 42
14:58:14.573567 IP (tos 0x0, ttl 64, id 65528, offset 0, flags [DF], proto UDP (17), length 72)
iZ329ljpa3gZ.56484 > 10.202.72.118.domain: [bad udp cksum 2e10!] 42026+ PTR? 84.143.168.10.in-addr.arpa. (44)
14:58:14.575711 IP (tos 0xc0, ttl 58, id 24515, offset 0, flags [none], proto UDP (17), length 122)
10.202.72.118.domain > iZ329ljpa3gZ.56484: [udp sum ok] 42026 NXDomain* q: PTR? 84.143.168.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (94)
14:58:14.641206 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.162.87.238 tell 10.168.136.108, length 42
14:58:14.641552 IP (tos 0x0, ttl 64, id 60, offset 0, flags [DF], proto UDP (17), length 72)
iZ329ljpa3gZ.51262 > 10.202.72.116.domain: [bad udp cksum 686!] 29577+ PTR? 238.87.162.10.in-addr.arpa. (44)
14:58:14.643654 IP (tos 0xc0, ttl 58, id 8727, offset 0, flags [none], proto UDP (17), length 122)
10.202.72.116.domain > iZ329ljpa3gZ.51262: [udp sum ok] 29577 NXDomain* q: PTR? 238.87.162.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (94)
14:58:14.644051 IP (tos 0x0, ttl 64, id 63, offset 0, flags [DF], proto UDP (17), length 73)
iZ329ljpa3gZ.37458 > 10.202.72.116.domain: [bad udp cksum 33e7!] 15905+ PTR? 108.136.168.10.in-addr.arpa. (45)
14:58:14.646065 IP (tos 0xc0, ttl 58, id 47165, offset 0, flags [none], proto UDP (17), length 123)
10.202.72.116.domain > iZ329ljpa3gZ.37458: [udp sum ok] 15905 NXDomain* q: PTR? 108.136.168.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
怎么几乎每秒都有这一些
还有探针下居然:
服务器已运行时间0天18小时22分钟
lo : | 已接收 : 0 GB | 已发送 : 0 GB |
eth0 : | 已接收 : 0.03712 GB | 已发送 : 0.00024 GB |
eth1 : | 已接收 : 0.43614 GB | 已发送 : 0.00624 GB |
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
是的,您列出的150.138.168.10
、83.143.168.10
和238.87.162.10
这些确实是IP地址。从您的tcpdump输出来看,这些请求似乎是在尝试进行反向DNS查询(PTR记录查询),即根据IP地址查找对应的域名信息。每个查询都得到了NXDomain响应,意味着所查询的IP地址在DNS中没有对应的PTR记录。
至于为什么几乎每秒都有这样的查询,这可能与运行在您服务器上的应用程序或服务有关。某些程序或系统进程会定期执行DNS查询,比如监控系统、日志收集服务、安全软件或者某些应用框架的网络诊断功能。此外,如果您的服务器配置了错误的DNS解析设置,或者被设置为对特定流量进行监控,也可能导致频繁的DNS查询。
关于流量显示的问题,即使服务器主要用于学习且没有大量页面访问,仍然可能会有背景流量。这里有几个可能的原因:
系统更新和后台任务:操作系统会自动检查更新,同时一些守护进程和服务可能会定时与外部通信,如时间同步(NTP)、包管理器更新检查等。
日志和监控服务:即使您没有主动设置,云服务商可能默认开启了基本的监控服务,这些服务会定期发送数据到监控中心。
恶意活动:虽然可能性较小,但也不排除服务器被利用进行未授权的活动,如DDoS攻击的跳板、挖矿软件等,需要检查服务器的安全状况。
网络配置问题:有时候,错误的路由配置或网络接口设置可能导致意外的流量流出,例如错误地设置了代理或转发规则。
建议您: - 检查服务器上运行的服务和进程,看是否有任何程序正在进行频繁的DNS查询。 - 使用如netstat
、iftop
或nethogs
等工具进一步分析网络流量的具体来源。 - 查看服务器的日志文件,特别是系统日志和应用日志,以获取更多线索。 - 确认服务器的防火墙规则和安全组设置,确保只开放必要的端口和服务。 - 考虑安装并运行安全扫描软件,检查是否存在潜在的安全威胁。