查看服务器上别人连接的IP地址，核心方法就两类：用命令实时看当前连接（如ss、netstat），或者翻日志看历史记录（如auth.log、Nginx访问日志）。下面我把Linux服务器上最实用的查看方式拆开讲，从基础命令到应对攻击的场景，一步步说清楚。
服务器查看连接IP的常用命令
ss命令：看当前所有TCP连接
ss是Linux上查看网络连接的首选命令,替代了老旧的netstat，它能列出当前所有ESTABLISHED（已建立）状态的连接，直接显示对方的IP和端口。
ss -tunap
拆解一下参数：-t只看TCP，-u看UDP，-n用数字显示IP和端口（不做域名反解，速度快得多），-a显示所有状态的连接，-p顺带显示进程信息。
如果你想一眼看出哪些IP连接数最多,可以配合awk统计：
ss -t | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
输出的第一列是连接次数,第二列是IP地址，连接数异常高的IP，十有八九在搞扫描或爆破。
netstat命令：老牌工具依然好用
部分最小化安装的服务器不带ss,但netstat通常还在，用法几乎一样：
netstat -tunap
这里-a会显示所有监听和已建立连接，-p能看到哪个进程在跟这个IP通信，比如你发现某个陌生IP连着你的443端口，netstat能直接告诉你这是Nginx还是其他程序在响应。
who和last：看谁登录过服务器
查看SSH登录的IP,用who看当前在线用户，用last查看历史登录记录，包括IP地址、登录时间、持续时间。
who last -20
last的输出最后一行是reboot或者wtmp begins这类系统记录，不用管，前面每一行对应一次登录会话，第三列就是来源IP，想排查有没有陌生人登录过你的服务器，这个命令最直接。
查找恶意扫描和攻击来源IP
从认证日志定位暴力破解IP
Linux服务器把SSH登录失败的记录都写在/var/log/auth.log（Ubuntu系）或/var/log/secure（CentOS系）里，查看最近失败的登录尝试，能看到攻击者的IP一直在刷屏。
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10
这条命令把失败登录次数最多的IP排在前面,业内专家指出，一个IP在短时间内出现几十次Failed password，基本可以断定是密码爆破，需要直接封禁。
fail2ban自动封禁恶意IP
手动封IP太累,人不可能24小时盯着日志，fail2ban这个工具就是干这事的，它监控日志文件，发现异常就自动调用iptables或firewalld把IP拉黑。
fail2ban-client status sshd
这条命令查看sshd服务的封禁状态,中间那块Banned IP list就是已经被拉黑的IP列表，配置在/etc/fail2ban/jail.local里，默认sshd的封禁时间是10分钟，可以按需改成永久封禁。
用tcpdump抓包看实时连接
如果你怀疑某个IP在偷偷跟服务器通信,tcpdump可以抓网卡上的所有流量，比如监听eth0网卡的80端口流量：
tcpdump -i eth0 port 80 -n
-n参数很关键，不做DNS反解，不然大量域名查询会拖慢抓包速度，抓到的每一行都包含源IP和目的IP，你能直观看到谁在访问你的Web服务。
iftop实时监控带宽占用
iftop是个命令行工具,界面类似top，但显示的是网络带宽占用，它能实时列出每个IP占用了多少带宽，哪个IP在疯狂下载你的文件、耗尽你的流量，一眼就能认出来：
iftop -i eth0 -n -P
-P参数显示端口，可以区分是HTTP流量还是SSH流量，界面中间那一列就是对方IP，数字是实时速率，哪天服务器CPU和带宽莫名其妙飙满，先跑一下iftop基本能定位到元凶。
区分Web访问和数据库连接的来源
查看Nginx或Apache访问日志中的IP
Web服务器的访问日志是最常被忽略的IP来源,Nginx的日志默认在/var/log/nginx/access.log，Apache的在/var/log/apache2/access.log，每一条访问记录都有客户端IP，用命令行统计访问量最高的IP：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
Nginx日志的$1字段就是IP地址，如果某个IP的请求量远高于其他IP，多半是爬虫或有人在刷接口，配合grep可以查特定IP的访问路径：
grep "1.2.3.4" /var/log/nginx/access.log | awk '{print $7}' | head -30
这条命令能列出这个IP访问过哪些页面,帮你判断对方是搜索引擎蜘蛛还是担忧的爬虫。
分析MySQL连接来源
数据库端口默认3306通常只对内网开放,但如果你为了远程管理开了公网访问，就得学会查谁连了你的数据库，MySQL里直接执行：
SHOW PROCESSLIST;
这个命令列出当前所有数据库连接,Host字段就是客户端的IP和端口，反复执行几次，如果看到很多来自同一个IP的Sleep连接，可能是连接池没释放，也可能是有人在拖库。
排查服务器被入侵时的连接IP
服务器被入侵后,第一件事就是查攻击者已经建立的反连shell，查看当前所有对外建立的连接，重点关注非标准端口（比如4444、5555这类）：
lsof -i | grep ESTABLISHED | grep -v "ssh|nginx|apache"
正常服务器的对外连接基本只有DNS查询、NTP对时、apt更新，剩下那些连到国外高端的IP和端口的连接，大概率是木马在跟控制端通信，结合netstat -tunap找到对应的PID，再用ps -ef查看这个进程的启动路径，能顺藤摸瓜找到恶意文件。
查询历史登录记录的完整方法
用last和lastb查看登录成败记录
前面提到last看的是成功登录的记录,那失败的登录记录看什么呢？用lastb，这个命令读取btmp文件，记录的是所有失败的登录尝试，包括IP、时间、尝试的用户名。
lastb -20
大多数发行版需要root权限才能执行,lastb的输出会直接告诉你哪个IP在尝试哪些用户名，如果你的服务器是一台公网服务器，跑了几天再执行lastb，你会发现来自全球各地的爆破尝试相当多，这里建议顺手把SSH默认端口改掉，改成高位端口能省去九成以上的爆破流量。
从bash历史查管理员操作来源
思路再开阔一点,如果你的服务器同时被多人管理，查谁在什么时候干了什么操作，可以看每个用户家目录下的.bash_history，但历史记录本身不包含IP，要追查到具体IP，还是得结合auth.log里的登录IP和登录时间，两者一对照，基本就能确定某条命令操作对应哪一次远程登录。
排查IP地址时的注意事项
区分公网IP和内网IP
查出来的一大堆IP里,10.x.x.x、172.16.x.x、192.168.x.x开头的都是内网IP，说明连接来自你的内网环境而不是公网，只有非保留段的IP才是真实公网地址，如果你的服务器前面挂了CDN或者负载均衡，看到的IP会是CDN节点的IP，而不是真实用户IP，这时候要看HTTP头里的X-Forwarded-For字段，需要修改Nginx配置中的log_format让日志记录真实IP。
不要只盯着一堆数字
查IP只是一个起点,更重要的是判断这个IP是否构成威胁，评估一个IP是否可疑，可以从这几个维度看：
- 地理位置是否跟业务相关（用geoiplookup工具能查IP归属地）
- 请求的频率和模式是人工还是脚本（比如每秒十几个请求基本确定是程序）
- 访问的路径是否敏感（比如疯狂探测/wp-admin或/.git目录的IP肯定在找漏洞）
- 连接持续时长是否符合正常用户习惯（一个连接挂几小时不动多半是木马）
常见问题
Linux服务器如何查看别人连接的IP？
使用ss -tunap命令实时查看当前所有TCP和UDP连接的IP与端口，使用who查看当前登录用户及来源IP，使用last查看历史登录记录，三者覆盖了实时连接和登录历史两种主要场景，绝大多数情况下够用。
服务器被攻击时查看IP用什么命令？
先用iftop -i eth0 -n -P观察哪个IP占满了带宽，再用awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10找到高频请求IP，最后用lastb确认是否有爆破尝试，三个命令从带宽、访问日志、认证日志三个角度锁定攻击源。
怎么查看服务器上SSH登录失败的IP地址？
执行grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn，输出的第一列是失败次数，第二列是IP，如果失败次数比较多，建议直接配置fail2ban自动封禁，不做手工处理。
查看服务器上的IP连接信息是日常运维的基础操作,核心逻辑是：实时连接用ss，历史登录用last，应用访问看Web日志，异常流量用iftop，掌握这几条命令，即使服务器出了问题，你也能在几分钟内定位到来源IP并作出响应。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/676187.html
