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