 |
1
tempdban Oct 26, 2018 via Android
netstat -anp
就算是有 pid 退出这么快你有啥办法 |
 |
2
hawhaw Oct 26, 2018
想法一：用 watch 监测 netstat 或者 ss 命令（都有参数支持显示 pid ）的输出
想法二：通过 audit 来监控相关系统调用，打印出相关 pid 信息 |
 |
3
zerofiny Oct 26, 2018
先抓包， 看目标主机及端口， 然后用 ss dst 主机 dport = :端口 -n 获取本地端口 然后用 lsof -i:本地端口 最好写哥脚本每秒去抓取 然后打印结果
|
 |
4
dwzhao OP 使用 tcpdump 抓包，抓到包了，找到端口了，但是很快就丢了，找不到对应进程 pid，这个真的很烦人，又不能改接口让连接长一些。。。
|
 |
5
yansheng1003 Oct 26, 2018 via Android
抓包查端口，然后去服务器根据端口查进程
|
 |
6
lihongjie0209 Oct 26, 2018
抓包
|
 |
7
jason56 Oct 26, 2018
按你描述的问题，似乎是针对 memcached 的 UDP 11211 端口 放大攻击.
|
 |
8
leconio Oct 26, 2018 via Android
>
|
 |
9
hcymk2 Oct 26, 2018
|
 |
10
libook Oct 26, 2018
HTTP 底层用的是 TCP 协议，如果能控制 HTTP 的接收方，可以分析 TCP 数据包拿到对方的 IP 和端口，在从发送方机器上用端口号找到对应进程。
|
|
11
libook Oct 26, 2018
在接受方上做一个 TCP 层的服务器，因为 HTTP 是封装在 TCP 包里的，可以一起拿到。
|
 |
12
Leigg Oct 26, 2018 via iPhone
写脚本每几秒获取 netstat 输出并持久化到文件，一个小时后来看文件。
|
 |
13
LGA1150 Oct 26, 2018
iptables TARPIT
TARPIT 会一直保持 TCP 连接 |
 |
14
microxiaoxiao Oct 26, 2018
top 只能看到一小部分进程， while ps 保存， 将请求时间段附近的所有进程依次执行，基本能重现这个问题。
|
 |
15
hu5ky Oct 26, 2018
wireshark 拦截看看？
|
 |
16
alcarl Oct 26, 2018 via Android
抓包看他访问的那，加一条静态路由给他指到一个奇怪的地方，应该就可以在等 synsend 的时候慢慢查了，用 netstat -anp，写个 shell while 一秒输出一次
|
 |
17
realpg PRO 写个极短间隔抓 PID 和程序路径的程序保存日志
写个极短间隔抓带 PID 的 TCP 连接的程序 挂 30 秒 总有对的上的记录 |
 |
18
scriptB0y Oct 27, 2018
你这边可以将 HTTP 服务可疑延长到 30 秒吗？如果客户端没设置超时的话，这样应该可以留住那边的客户端进程的。
|
 |
19
omph Oct 27, 2018
甩你一个命令
lsof -r 1 -i TCP:80 |
 |
20
winglight2016 Oct 27, 2018
这是被当成肉鸡 ddos 了吧，我之前的服务器也是同样中招，只能 rebuild 了
|
|
21
dwzhao OP 最后回复：
对应的进程找到，并且已经处理了，感谢大家的建议。 简单总结一下： 1、用极短的时间抓 pid 这个思路也不太行，应为极短的时间很难定义，各种参数 -c 1 都不行 2、用程序的方式也不行，程序也是调用系统命令，系统不行，程序也不行 最后的方法： 简单的说就是“撞大运”，不停的抓 pid （通过 tcpdump，netstat、lsof 都行），抓一天，两天这样。总会在连接刚开启的时候被发现一些业务中不应该出现的命令或者进程，然后再分析来源，最终定位到问题进程，所以我的感觉是长时间多次抓包，虽然概率低，但终究是能找到的，需要耐心了~ 感谢各位~ |
 |
22
DevilHunterXX Nov 2, 2018
|
|
23
dwzhao OP @DevilHunterXX，是的，写个脚本不停的抓，大不了抓几天，一定会碰到的
|
Select Language