尧图网站建设 
简介这是一份面向AWD线下赛选手与网络安全爱好者的攻防工具合集聚焦真实网络攻防场景下的实战需求帮助使用者在代码审计、流量分析、远程控制与端口探测等环节快速调用趁手工具适合具备一定渗透测试基础、希望系统备赛的中高级选手。压缩包共115个文件约92.7MB以php、exe、dll等可执行与脚本文件为主辅以conf、ini配置文件和css、js、png等界面资源另含jar、py、aspx、jsp等跨平台组件覆盖工具运行与配置的完整依赖。资源整合了OWASP ZAP、Burp Suite、Wireshark、tcpdump、Nmap、masscan、SSH、RDP等常用工具并附带AWD教程、策略指南与往届案例分析便于理解比赛规则、复盘攻防思路。目前已有2616人学习下载可作为线下赛备赛与日常攻防练习的参考工具集。1. 从一场被打穿的线下赛说起这套 AWD 工具集合到底值不值得留去年一场线下攻防赛我们队在第三轮被对手用一句话木马连穿三台靶机裁判席的计分板直接翻红。复盘时发现问题不在漏洞本身而在于我们手里那套工具链太散——扫描用一个、流量分析用一个、权限维持又换一个切换窗口的几十秒就是对手的黄金窗口。AWDAttack With Defense线下赛的节奏和线上 CTF 完全是两码事你既要打别人又要守自己还要在裁判的流量审计下活下来。这套「各种 AWD 工具工具集合」就是冲着这个场景攒的——它不是某个单点神器而是一组覆盖信息收集、漏洞利用、流量监控、权限维持、批量操作的脚本与二进制工具包。适合谁打过一两场线下赛、知道 SSH 怎么连靶机、但工具链还没成型的队伍。如果你还在用浏览器标签页管理十台靶机这篇笔记能帮你把工具收进一个目录里。2. 工具集合的目录结构与核心组件拆解拿到一个工具集合第一件事不是急着跑脚本而是先看清楚它到底装了什么。AWD 场景下的工具和通用渗透测试工具集有个本质区别它必须能在极短时间内完成「发现-利用-修复」的闭环而且很多操作要批量执行。所以目录结构往往按功能域划分而不是按工具类型。2.1 典型目录布局与各模块职责我拆过的这类集合常见布局大致是这样awd-toolkit/ ├── recon/ # 信息收集端口扫描、目录爆破、指纹识别 │ ├── port_scan.sh │ ├── dir_brute.py │ └── fingerprint.py ├── exploit/ # 漏洞利用Web 漏洞、服务漏洞的 PoC │ ├── web_poc/ │ └── service_poc/ ├── persist/ # 权限维持后门、计划任务、SSH key │ ├── ssh_key_gen.sh │ └── cron_persist.sh ├── monitor/ # 流量监控与告警 │ ├── traffic_watch.py │ └── flag_monitor.sh ├── batch/ # 批量操作多靶机并行执行 │ ├── batch_ssh.py │ └── batch_upload.sh └── utils/ # 辅助工具编码转换、payload 生成 ├── encode.py └── payload_gen.py这个布局的逻辑是比赛开始后的前五分钟你只需要碰recon/拿到入口点后切到exploit/同时后台挂着monitor/盯 flag 和流量persist/是防守回合用的batch/贯穿全程。每个目录下的脚本通常都接受统一的环境变量或配置文件这样批量调用时不用改代码。提示不同来源的工具集合目录名可能不同但功能域划分基本一致。拿到手先跑一遍tree -L 2看清楚层级比直接翻 README 快。2.2 核心脚本的参数设计与调用约定以batch_ssh.py为例这是 AWD 里用得最频繁的脚本之一——你需要同时对十台甚至几十台靶机执行命令。一个设计合理的批量 SSH 脚本通常长这样#!/usr/bin/env python3 # batch_ssh.py - 对多台靶机并行执行命令 import paramiko import concurrent.futures import argparse def run_cmd(host, user, password, cmd, port22): 单台靶机执行命令返回 (host, stdout, stderr) try: client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, portport, usernameuser, passwordpassword, timeout5) stdin, stdout, stderr client.exec_command(cmd, timeout10) out stdout.read().decode(errorsignore) err stderr.read().decode(errorsignore) client.close() return (host, out, err) except Exception as e: return (host, , str(e)) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(-f, --file, requiredTrue, help靶机列表文件每行 ip:port) parser.add_argument(-u, --user, defaultroot) parser.add_argument(-p, --password, requiredTrue) parser.add_argument(-c, --cmd, requiredTrue, help要执行的命令) parser.add_argument(-t, --threads, typeint, default10) args parser.parse_args() hosts [] with open(args.file) as f: for line in f: line line.strip() if line and not line.startswith(#): hosts.append(line) with concurrent.futures.ThreadPoolExecutor(max_workersargs.threads) as executor: futures [executor.submit(run_cmd, h.split(:)[0], args.user, args.password, args.cmd, int(h.split(:)[1]) if : in h else 22) for h in hosts] for future in concurrent.futures.as_completed(futures): host, out, err future.result() print(f {host} ) print(out) if err: print(f[stderr] {err})这段代码的关键参数有三个-f指定靶机列表文件格式是每行ip:port支持#注释-t控制并发线程数线下赛网络环境通常比较稳定开到 10-20 问题不大但如果你同时跑多个批量任务建议降到 5 以下避免把靶机 SSH 连接数打满-c是要执行的命令注意命令里如果有特殊字符要加引号。逻辑上它用ThreadPoolExecutor做并发每个线程独立建立 SSH 连接执行完立即关闭不会在靶机上留下长连接痕迹。traffic_watch.py是另一个高频脚本通常基于scapy或直接调tcpdump做流量抓取和关键词匹配。它的核心参数一般是-i指定网卡、-k指定要监控的关键词比如 flag 格式、-o输出告警日志。线下赛里这个脚本要一直挂着所以资源占用要低常见做法是只抓特定端口的流量而不是全量抓包。2.3 工具之间的协作流程单看每个脚本都不复杂但 AWD 的实战价值在于把它们串起来。一个典型的协作流程是比赛开始recon/port_scan.sh扫全场靶机开放端口输出结果存到hosts.txtrecon/fingerprint.py对开放 Web 端口的靶机做指纹识别标记出可能的 CMS 和框架根据指纹结果从exploit/web_poc/里挑对应的 PoC用batch_ssh.py批量打拿到 shell 后persist/ssh_key_gen.sh批量写入 SSH key同时monitor/traffic_watch.py开始监控 flag 流量防守回合用batch/batch_upload.sh把修复补丁推到所有己方靶机。这个流程里hosts.txt是贯穿始终的「单一数据源」——所有脚本都从它读靶机列表避免手动维护多份清单导致遗漏。我一般会在比赛开始前就把这个文件建好格式统一成ip:port注释行写清楚每台靶机的角色己方/敌方/未知。3. 从零跑通一套 AWD 工具链环境准备与批量操作实战工具集合拿到手最怕的是「在我机器上跑不起来」。AWD 线下赛的环境通常是 Kali 或者 Ubuntu但不同比赛给的靶机系统版本差异很大所以工具链的依赖管理要提前做。3.1 依赖安装与 Python 虚拟环境隔离这类工具集合的依赖主要集中在几个方向SSH 操作paramiko、流量处理scapy、Web 请求requests、并发concurrent.futures 标准库。常见做法是建一个独立的虚拟环境避免和系统 Python 冲突# 创建虚拟环境并安装依赖 python3 -m venv awd-env source awd-env/bin/activate # 核心依赖 pip install paramiko scapy requests beautifulsoup4 # 如果工具集合里有 requirements.txt直接 pip install -r requirements.txt # 验证关键模块 python3 -c import paramiko, scapy, requests; print(deps ok)这里有个血泪经验scapy在不同 Linux 发行版上的安装坑最多尤其是缺少libpcap开发库的时候会编译失败。Ubuntu/Debian 下先跑apt install libpcap-devCentOS 下是yum install libpcap-devel。另外线下赛的靶机可能不允许你安装额外软件包所以批量操作脚本尽量只用标准库和 paramiko把 scapy 相关的流量监控放在自己的攻击机上跑。注意有些比赛环境会限制出网pip 安装依赖要提前在本地做好 wheel 包或者用比赛提供的镜像源。我一般会在赛前把常用依赖打包成wheelhouse/目录现场直接pip install --no-index --find-linkswheelhouse/ -r requirements.txt。3.2 靶机列表管理与批量命令执行批量操作的核心是「一份清单多处复用」。我习惯把靶机信息写成一个简单的 YAML 或者纯文本文件纯文本更通用# hosts.txt 192.168.1.10:22 # 己方 web01 192.168.1.11:22 # 己方 web02 192.168.1.20:2222 # 敌方 web01SSH 端口改过 192.168.1.21:22 # 未知然后所有脚本都通过-f hosts.txt读取。批量执行命令时除了前面展示的batch_ssh.py还有一个常见需求是批量上传文件。batch_upload.sh通常用scp或者paramiko的 SFTP 实现#!/bin/bash # batch_upload.sh - 批量上传文件到多台靶机 # 用法: ./batch_upload.sh hosts.txt /local/path /remote/path HOSTS_FILE$1 LOCAL_PATH$2 REMOTE_PATH$3 while IFS read -r line; do # 跳过注释和空行 [[ $line ~ ^#.*$ || -z $line ]] continue host$(echo $line | awk {print $1}) ip$(echo $host | cut -d: -f1) port$(echo $host | cut -d: -f2) port${port:-22} echo [*] Uploading to $ip:$port scp -P $port -o StrictHostKeyCheckingno -o ConnectTimeout5 \ $LOCAL_PATH root$ip:$REMOTE_PATH done $HOSTS_FILE wait echo [*] All uploads finished这个脚本用把每个 scp 放到后台并行执行最后wait等所有任务结束。-o StrictHostKeyCheckingno跳过主机密钥确认线下赛里靶机经常重装这个选项能省不少事。-o ConnectTimeout5防止某台靶机不通导致整个脚本卡住。参数上hosts.txt的格式和前面一致/local/path是本地文件路径/remote/path是靶机上的目标路径。3.3 流量监控与 flag 自动告警AWD 的计分核心是 flag所以监控 flag 流量是防守回合的重中之重。traffic_watch.py的典型实现是抓取指定网卡的流量匹配 flag 格式通常是flag{...}或者比赛自定义的格式一旦命中就打印告警并记录来源 IP#!/usr/bin/env python3 # traffic_watch.py - 监控流量中的 flag 关键词 from scapy.all import sniff, TCP, Raw import re import argparse import datetime FLAG_PATTERN re.compile(rbflag\{[^}]\}, re.IGNORECASE) def handle_packet(pkt): if pkt.haslayer(Raw) and pkt.haslayer(TCP): payload pkt[Raw].load matches FLAG_PATTERN.findall(payload) for m in matches: src pkt[TCP].socketerror if hasattr(pkt[TCP], socketerror) else pkt[0][1].src dst pkt[0][1].dst ts datetime.datetime.now().strftime(%H:%M:%S) print(f[{ts}] FLAG DETECTED: {m.decode(errorsignore)} | {src} - {dst}) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(-i, --iface, requiredTrue, help网卡名如 eth0) parser.add_argument(-p, --port, typeint, default80, help监控端口) args parser.parse_args() print(f[*] Watching {args.iface} on port {args.port}...) sniff(ifaceargs.iface, filterftcp port {args.port}, prnhandle_packet, store0)关键参数-i指定网卡线下赛里通常是eth0或者ens33用ip a确认-p指定监控端口Web 题一般盯 80 和 443但有些比赛 flag 走其他端口需要根据题目调整。sniff的filter参数用的是 BPF 语法store0表示不把包存内存避免长时间运行吃满内存。这个脚本的局限是只能看到经过本机网卡的流量如果比赛网络做了端口镜像或者你不在流量路径上需要配合tcpdump在靶机上抓包再回传。4. 避坑与排查AWD 工具链最容易翻车的五个地方工具集合用起来爽但翻车的时候也是真翻。下面这五个坑是我和队友在实战里踩出来的每个都按「现象 → 原因 → 解决」写清楚。4.1 批量 SSH 执行时部分靶机无响应现象batch_ssh.py跑出去大部分靶机秒回但总有几台一直卡着整个脚本要等超时才能结束。原因靶机 SSH 服务负载高、网络抖动或者密码错误导致 paramiko 反复重试。默认timeout5在某些慢速环境下不够而ThreadPoolExecutor会等所有 future 完成才退出。解决把connect和exec_command的 timeout 分开设置连接超时设 3 秒命令执行超时设 10 秒同时在run_cmd里捕获socket.timeout和paramiko.ssh_exception.AuthenticationException快速失败而不是重试。另外可以在hosts.txt里把已知不稳定的靶机标记出来单独处理。4.2 scapy 抓包权限不足或网卡选错现象traffic_watch.py启动报PermissionError或者抓不到任何包。原因scapy 抓包需要 root 权限或者CAP_NET_RAW能力网卡名写错比如写了eth0但实际是ens33也会导致静默失败。解决用sudo运行或者setcap cap_net_raweip $(which python3)给 Python 解释器加能力。网卡名先用ip a或ifconfig确认脚本里可以加一个启动检查if args.iface not in os.listdir(/sys/class/net): sys.exit(iface not found)。4.3 flag 监控脚本误报或漏报现象监控脚本疯狂打印 flag 告警但去靶机上看根本没有 flag 被读取或者对手明明拿了 flag脚本一点反应没有。原因误报通常是正则写得太宽比如flag\{.*\}会匹配到正常业务里的类似字符串漏报则可能是 flag 走了 HTTPSpayload 被加密或者监控端口不对。解决正则收紧用flag\{[a-f0-9]{32}\}这种精确格式具体看比赛 flag 规则。HTTPS 流量要么在靶机上装证书做中间人要么直接监控靶机的文件读取行为比如inotifywait盯 flag 文件。端口方面除了 80/443也要关注 8080、8000 这些常见 Web 端口。4.4 权限维持脚本被裁判判定违规现象写了 SSH key 或者计划任务结果被裁判扣分甚至判负。原因不同比赛对「权限维持」的界定不一样有些比赛允许写 SSH key有些只允许在 Web 目录留后门还有些完全禁止任何持久化操作。解决赛前仔细读规则不确定的操作先在小范围测试。我一般会准备两套 persist 脚本一套「激进版」用于明确允许的比赛一套「保守版」只做内存驻留比如nohup起一个反弹 shell赛后自动清理。4.5 工具集合里的脚本带硬编码路径或 IP现象脚本在别人机器上跑得好好的到你这里就报FileNotFoundError或者连到错误的 IP。原因很多工具集合是作者从自己环境里直接打包的脚本里硬编码了/home/xxx/tools/或者192.168.1.100这类路径和地址。解决拿到集合后先全局搜一遍硬编码grep -rn /home/\|192\.168\.\|10\.0\. --include*.py --include*.sh。把路径改成相对路径或者环境变量IP 统一从hosts.txt读。这个步骤花十分钟能省掉后面一小时的调试。5. 进阶技巧把工具集合改造成自己的「一键响应」流水线工具集合用熟了之后下一步是把它从「一堆脚本」变成「一条流水线」。我的做法是写一个总控脚本awd.sh把常用操作封装成子命令配合hosts.txt和几个环境变量实现「一条命令完成一轮攻防」。#!/bin/bash # awd.sh - AWD 工具链总控 # 用法: ./awd.sh command [args] TOOLKIT_DIR$(cd $(dirname $0) pwd) HOSTS_FILE${AWD_HOSTS:-$TOOLKIT_DIR/hosts.txt} SSH_USER${AWD_USER:-root} SSH_PASS${AWD_PASS:-} case $1 in scan) # 全场端口扫描 bash $TOOLKIT_DIR/recon/port_scan.sh -f $HOSTS_FILE -o scan_result.txt ;; fingerprint) python3 $TOOLKIT_DIR/recon/fingerprint.py -f scan_result.txt -o fp_result.json ;; batch) # 批量执行命令: ./awd.sh batch id python3 $TOOLKIT_DIR/batch/batch_ssh.py -f $HOSTS_FILE \ -u $SSH_USER -p $SSH_PASS -c $2 ;; watch) # 启动流量监控 sudo python3 $TOOLKIT_DIR/monitor/traffic_watch.py -i ${AWD_IFACE:-eth0} -p 80 ;; persist) # 批量写 SSH key bash $TOOLKIT_DIR/persist/ssh_key_gen.sh -f $HOSTS_FILE -u $SSH_USER -p $SSH_PASS ;; *) echo Usage: $0 {scan|fingerprint|batch|watch|persist} exit 1 ;; esac这个总控脚本的关键设计是环境变量覆盖AWD_HOSTS、AWD_USER、AWD_PASS、AWD_IFACE都可以在赛前通过export设置脚本里用${VAR:-default}做兜底。这样同一套工具可以在不同比赛环境里快速切换不用改代码。batch子命令把命令作为第二个参数传入配合 shell 的$2就能实现./awd.sh batch cat /flag这种用法。验证流水线是否可靠我一般会做一次「空跑」用一台自己的测试机当靶机把hosts.txt只写这一台然后依次跑scan、fingerprint、batch、persist确认每一步的输出符合预期。特别是persist之后要验证 SSH key 是否真的能免密登录watch要确认能抓到测试用的 flag 字符串。这个空跑流程我每次赛前都会走一遍有一次就是靠它发现traffic_watch.py在新内核上因为 scapy 版本问题抓不到包提前换了tcpdump方案。从那以后我每次拿到新的工具集合都强制走一遍「空跑验证 → 硬编码检查 → 规则确认」这三步再急也不跳过。希望帮到你。本文还有配套的精品资源点击获取 AWD线下赛工具集合实战：从批量SSH到流量监控的攻防流水线
简介这是一份面向AWD线下赛选手与网络安全爱好者的攻防工具合集聚焦真实网络攻防场景下的实战需求帮助使用者在代码审计、流量分析、远程控制与端口探测等环节快速调用趁手工具适合具备一定渗透测试基础、希望系统备赛的中高级选手。压缩包共115个文件约92.7MB以php、exe、dll等可执行与脚本文件为主辅以conf、ini配置文件和css、js、png等界面资源另含jar、py、aspx、jsp等跨平台组件覆盖工具运行与配置的完整依赖。资源整合了OWASP ZAP、Burp Suite、Wireshark、tcpdump、Nmap、masscan、SSH、RDP等常用工具并附带AWD教程、策略指南与往届案例分析便于理解比赛规则、复盘攻防思路。目前已有2616人学习下载可作为线下赛备赛与日常攻防练习的参考工具集。1. 从一场被打穿的线下赛说起这套 AWD 工具集合到底值不值得留去年一场线下攻防赛我们队在第三轮被对手用一句话木马连穿三台靶机裁判席的计分板直接翻红。复盘时发现问题不在漏洞本身而在于我们手里那套工具链太散——扫描用一个、流量分析用一个、权限维持又换一个切换窗口的几十秒就是对手的黄金窗口。AWDAttack With Defense线下赛的节奏和线上 CTF 完全是两码事你既要打别人又要守自己还要在裁判的流量审计下活下来。这套「各种 AWD 工具工具集合」就是冲着这个场景攒的——它不是某个单点神器而是一组覆盖信息收集、漏洞利用、流量监控、权限维持、批量操作的脚本与二进制工具包。适合谁打过一两场线下赛、知道 SSH 怎么连靶机、但工具链还没成型的队伍。如果你还在用浏览器标签页管理十台靶机这篇笔记能帮你把工具收进一个目录里。2. 工具集合的目录结构与核心组件拆解拿到一个工具集合第一件事不是急着跑脚本而是先看清楚它到底装了什么。AWD 场景下的工具和通用渗透测试工具集有个本质区别它必须能在极短时间内完成「发现-利用-修复」的闭环而且很多操作要批量执行。所以目录结构往往按功能域划分而不是按工具类型。2.1 典型目录布局与各模块职责我拆过的这类集合常见布局大致是这样awd-toolkit/ ├── recon/ # 信息收集端口扫描、目录爆破、指纹识别 │ ├── port_scan.sh │ ├── dir_brute.py │ └── fingerprint.py ├── exploit/ # 漏洞利用Web 漏洞、服务漏洞的 PoC │ ├── web_poc/ │ └── service_poc/ ├── persist/ # 权限维持后门、计划任务、SSH key │ ├── ssh_key_gen.sh │ └── cron_persist.sh ├── monitor/ # 流量监控与告警 │ ├── traffic_watch.py │ └── flag_monitor.sh ├── batch/ # 批量操作多靶机并行执行 │ ├── batch_ssh.py │ └── batch_upload.sh └── utils/ # 辅助工具编码转换、payload 生成 ├── encode.py └── payload_gen.py这个布局的逻辑是比赛开始后的前五分钟你只需要碰recon/拿到入口点后切到exploit/同时后台挂着monitor/盯 flag 和流量persist/是防守回合用的batch/贯穿全程。每个目录下的脚本通常都接受统一的环境变量或配置文件这样批量调用时不用改代码。提示不同来源的工具集合目录名可能不同但功能域划分基本一致。拿到手先跑一遍tree -L 2看清楚层级比直接翻 README 快。2.2 核心脚本的参数设计与调用约定以batch_ssh.py为例这是 AWD 里用得最频繁的脚本之一——你需要同时对十台甚至几十台靶机执行命令。一个设计合理的批量 SSH 脚本通常长这样#!/usr/bin/env python3 # batch_ssh.py - 对多台靶机并行执行命令 import paramiko import concurrent.futures import argparse def run_cmd(host, user, password, cmd, port22): 单台靶机执行命令返回 (host, stdout, stderr) try: client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, portport, usernameuser, passwordpassword, timeout5) stdin, stdout, stderr client.exec_command(cmd, timeout10) out stdout.read().decode(errorsignore) err stderr.read().decode(errorsignore) client.close() return (host, out, err) except Exception as e: return (host, , str(e)) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(-f, --file, requiredTrue, help靶机列表文件每行 ip:port) parser.add_argument(-u, --user, defaultroot) parser.add_argument(-p, --password, requiredTrue) parser.add_argument(-c, --cmd, requiredTrue, help要执行的命令) parser.add_argument(-t, --threads, typeint, default10) args parser.parse_args() hosts [] with open(args.file) as f: for line in f: line line.strip() if line and not line.startswith(#): hosts.append(line) with concurrent.futures.ThreadPoolExecutor(max_workersargs.threads) as executor: futures [executor.submit(run_cmd, h.split(:)[0], args.user, args.password, args.cmd, int(h.split(:)[1]) if : in h else 22) for h in hosts] for future in concurrent.futures.as_completed(futures): host, out, err future.result() print(f {host} ) print(out) if err: print(f[stderr] {err})这段代码的关键参数有三个-f指定靶机列表文件格式是每行ip:port支持#注释-t控制并发线程数线下赛网络环境通常比较稳定开到 10-20 问题不大但如果你同时跑多个批量任务建议降到 5 以下避免把靶机 SSH 连接数打满-c是要执行的命令注意命令里如果有特殊字符要加引号。逻辑上它用ThreadPoolExecutor做并发每个线程独立建立 SSH 连接执行完立即关闭不会在靶机上留下长连接痕迹。traffic_watch.py是另一个高频脚本通常基于scapy或直接调tcpdump做流量抓取和关键词匹配。它的核心参数一般是-i指定网卡、-k指定要监控的关键词比如 flag 格式、-o输出告警日志。线下赛里这个脚本要一直挂着所以资源占用要低常见做法是只抓特定端口的流量而不是全量抓包。2.3 工具之间的协作流程单看每个脚本都不复杂但 AWD 的实战价值在于把它们串起来。一个典型的协作流程是比赛开始recon/port_scan.sh扫全场靶机开放端口输出结果存到hosts.txtrecon/fingerprint.py对开放 Web 端口的靶机做指纹识别标记出可能的 CMS 和框架根据指纹结果从exploit/web_poc/里挑对应的 PoC用batch_ssh.py批量打拿到 shell 后persist/ssh_key_gen.sh批量写入 SSH key同时monitor/traffic_watch.py开始监控 flag 流量防守回合用batch/batch_upload.sh把修复补丁推到所有己方靶机。这个流程里hosts.txt是贯穿始终的「单一数据源」——所有脚本都从它读靶机列表避免手动维护多份清单导致遗漏。我一般会在比赛开始前就把这个文件建好格式统一成ip:port注释行写清楚每台靶机的角色己方/敌方/未知。3. 从零跑通一套 AWD 工具链环境准备与批量操作实战工具集合拿到手最怕的是「在我机器上跑不起来」。AWD 线下赛的环境通常是 Kali 或者 Ubuntu但不同比赛给的靶机系统版本差异很大所以工具链的依赖管理要提前做。3.1 依赖安装与 Python 虚拟环境隔离这类工具集合的依赖主要集中在几个方向SSH 操作paramiko、流量处理scapy、Web 请求requests、并发concurrent.futures 标准库。常见做法是建一个独立的虚拟环境避免和系统 Python 冲突# 创建虚拟环境并安装依赖 python3 -m venv awd-env source awd-env/bin/activate # 核心依赖 pip install paramiko scapy requests beautifulsoup4 # 如果工具集合里有 requirements.txt直接 pip install -r requirements.txt # 验证关键模块 python3 -c import paramiko, scapy, requests; print(deps ok)这里有个血泪经验scapy在不同 Linux 发行版上的安装坑最多尤其是缺少libpcap开发库的时候会编译失败。Ubuntu/Debian 下先跑apt install libpcap-devCentOS 下是yum install libpcap-devel。另外线下赛的靶机可能不允许你安装额外软件包所以批量操作脚本尽量只用标准库和 paramiko把 scapy 相关的流量监控放在自己的攻击机上跑。注意有些比赛环境会限制出网pip 安装依赖要提前在本地做好 wheel 包或者用比赛提供的镜像源。我一般会在赛前把常用依赖打包成wheelhouse/目录现场直接pip install --no-index --find-linkswheelhouse/ -r requirements.txt。3.2 靶机列表管理与批量命令执行批量操作的核心是「一份清单多处复用」。我习惯把靶机信息写成一个简单的 YAML 或者纯文本文件纯文本更通用# hosts.txt 192.168.1.10:22 # 己方 web01 192.168.1.11:22 # 己方 web02 192.168.1.20:2222 # 敌方 web01SSH 端口改过 192.168.1.21:22 # 未知然后所有脚本都通过-f hosts.txt读取。批量执行命令时除了前面展示的batch_ssh.py还有一个常见需求是批量上传文件。batch_upload.sh通常用scp或者paramiko的 SFTP 实现#!/bin/bash # batch_upload.sh - 批量上传文件到多台靶机 # 用法: ./batch_upload.sh hosts.txt /local/path /remote/path HOSTS_FILE$1 LOCAL_PATH$2 REMOTE_PATH$3 while IFS read -r line; do # 跳过注释和空行 [[ $line ~ ^#.*$ || -z $line ]] continue host$(echo $line | awk {print $1}) ip$(echo $host | cut -d: -f1) port$(echo $host | cut -d: -f2) port${port:-22} echo [*] Uploading to $ip:$port scp -P $port -o StrictHostKeyCheckingno -o ConnectTimeout5 \ $LOCAL_PATH root$ip:$REMOTE_PATH done $HOSTS_FILE wait echo [*] All uploads finished这个脚本用把每个 scp 放到后台并行执行最后wait等所有任务结束。-o StrictHostKeyCheckingno跳过主机密钥确认线下赛里靶机经常重装这个选项能省不少事。-o ConnectTimeout5防止某台靶机不通导致整个脚本卡住。参数上hosts.txt的格式和前面一致/local/path是本地文件路径/remote/path是靶机上的目标路径。3.3 流量监控与 flag 自动告警AWD 的计分核心是 flag所以监控 flag 流量是防守回合的重中之重。traffic_watch.py的典型实现是抓取指定网卡的流量匹配 flag 格式通常是flag{...}或者比赛自定义的格式一旦命中就打印告警并记录来源 IP#!/usr/bin/env python3 # traffic_watch.py - 监控流量中的 flag 关键词 from scapy.all import sniff, TCP, Raw import re import argparse import datetime FLAG_PATTERN re.compile(rbflag\{[^}]\}, re.IGNORECASE) def handle_packet(pkt): if pkt.haslayer(Raw) and pkt.haslayer(TCP): payload pkt[Raw].load matches FLAG_PATTERN.findall(payload) for m in matches: src pkt[TCP].socketerror if hasattr(pkt[TCP], socketerror) else pkt[0][1].src dst pkt[0][1].dst ts datetime.datetime.now().strftime(%H:%M:%S) print(f[{ts}] FLAG DETECTED: {m.decode(errorsignore)} | {src} - {dst}) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(-i, --iface, requiredTrue, help网卡名如 eth0) parser.add_argument(-p, --port, typeint, default80, help监控端口) args parser.parse_args() print(f[*] Watching {args.iface} on port {args.port}...) sniff(ifaceargs.iface, filterftcp port {args.port}, prnhandle_packet, store0)关键参数-i指定网卡线下赛里通常是eth0或者ens33用ip a确认-p指定监控端口Web 题一般盯 80 和 443但有些比赛 flag 走其他端口需要根据题目调整。sniff的filter参数用的是 BPF 语法store0表示不把包存内存避免长时间运行吃满内存。这个脚本的局限是只能看到经过本机网卡的流量如果比赛网络做了端口镜像或者你不在流量路径上需要配合tcpdump在靶机上抓包再回传。4. 避坑与排查AWD 工具链最容易翻车的五个地方工具集合用起来爽但翻车的时候也是真翻。下面这五个坑是我和队友在实战里踩出来的每个都按「现象 → 原因 → 解决」写清楚。4.1 批量 SSH 执行时部分靶机无响应现象batch_ssh.py跑出去大部分靶机秒回但总有几台一直卡着整个脚本要等超时才能结束。原因靶机 SSH 服务负载高、网络抖动或者密码错误导致 paramiko 反复重试。默认timeout5在某些慢速环境下不够而ThreadPoolExecutor会等所有 future 完成才退出。解决把connect和exec_command的 timeout 分开设置连接超时设 3 秒命令执行超时设 10 秒同时在run_cmd里捕获socket.timeout和paramiko.ssh_exception.AuthenticationException快速失败而不是重试。另外可以在hosts.txt里把已知不稳定的靶机标记出来单独处理。4.2 scapy 抓包权限不足或网卡选错现象traffic_watch.py启动报PermissionError或者抓不到任何包。原因scapy 抓包需要 root 权限或者CAP_NET_RAW能力网卡名写错比如写了eth0但实际是ens33也会导致静默失败。解决用sudo运行或者setcap cap_net_raweip $(which python3)给 Python 解释器加能力。网卡名先用ip a或ifconfig确认脚本里可以加一个启动检查if args.iface not in os.listdir(/sys/class/net): sys.exit(iface not found)。4.3 flag 监控脚本误报或漏报现象监控脚本疯狂打印 flag 告警但去靶机上看根本没有 flag 被读取或者对手明明拿了 flag脚本一点反应没有。原因误报通常是正则写得太宽比如flag\{.*\}会匹配到正常业务里的类似字符串漏报则可能是 flag 走了 HTTPSpayload 被加密或者监控端口不对。解决正则收紧用flag\{[a-f0-9]{32}\}这种精确格式具体看比赛 flag 规则。HTTPS 流量要么在靶机上装证书做中间人要么直接监控靶机的文件读取行为比如inotifywait盯 flag 文件。端口方面除了 80/443也要关注 8080、8000 这些常见 Web 端口。4.4 权限维持脚本被裁判判定违规现象写了 SSH key 或者计划任务结果被裁判扣分甚至判负。原因不同比赛对「权限维持」的界定不一样有些比赛允许写 SSH key有些只允许在 Web 目录留后门还有些完全禁止任何持久化操作。解决赛前仔细读规则不确定的操作先在小范围测试。我一般会准备两套 persist 脚本一套「激进版」用于明确允许的比赛一套「保守版」只做内存驻留比如nohup起一个反弹 shell赛后自动清理。4.5 工具集合里的脚本带硬编码路径或 IP现象脚本在别人机器上跑得好好的到你这里就报FileNotFoundError或者连到错误的 IP。原因很多工具集合是作者从自己环境里直接打包的脚本里硬编码了/home/xxx/tools/或者192.168.1.100这类路径和地址。解决拿到集合后先全局搜一遍硬编码grep -rn /home/\|192\.168\.\|10\.0\. --include*.py --include*.sh。把路径改成相对路径或者环境变量IP 统一从hosts.txt读。这个步骤花十分钟能省掉后面一小时的调试。5. 进阶技巧把工具集合改造成自己的「一键响应」流水线工具集合用熟了之后下一步是把它从「一堆脚本」变成「一条流水线」。我的做法是写一个总控脚本awd.sh把常用操作封装成子命令配合hosts.txt和几个环境变量实现「一条命令完成一轮攻防」。#!/bin/bash # awd.sh - AWD 工具链总控 # 用法: ./awd.sh command [args] TOOLKIT_DIR$(cd $(dirname $0) pwd) HOSTS_FILE${AWD_HOSTS:-$TOOLKIT_DIR/hosts.txt} SSH_USER${AWD_USER:-root} SSH_PASS${AWD_PASS:-} case $1 in scan) # 全场端口扫描 bash $TOOLKIT_DIR/recon/port_scan.sh -f $HOSTS_FILE -o scan_result.txt ;; fingerprint) python3 $TOOLKIT_DIR/recon/fingerprint.py -f scan_result.txt -o fp_result.json ;; batch) # 批量执行命令: ./awd.sh batch id python3 $TOOLKIT_DIR/batch/batch_ssh.py -f $HOSTS_FILE \ -u $SSH_USER -p $SSH_PASS -c $2 ;; watch) # 启动流量监控 sudo python3 $TOOLKIT_DIR/monitor/traffic_watch.py -i ${AWD_IFACE:-eth0} -p 80 ;; persist) # 批量写 SSH key bash $TOOLKIT_DIR/persist/ssh_key_gen.sh -f $HOSTS_FILE -u $SSH_USER -p $SSH_PASS ;; *) echo Usage: $0 {scan|fingerprint|batch|watch|persist} exit 1 ;; esac这个总控脚本的关键设计是环境变量覆盖AWD_HOSTS、AWD_USER、AWD_PASS、AWD_IFACE都可以在赛前通过export设置脚本里用${VAR:-default}做兜底。这样同一套工具可以在不同比赛环境里快速切换不用改代码。batch子命令把命令作为第二个参数传入配合 shell 的$2就能实现./awd.sh batch cat /flag这种用法。验证流水线是否可靠我一般会做一次「空跑」用一台自己的测试机当靶机把hosts.txt只写这一台然后依次跑scan、fingerprint、batch、persist确认每一步的输出符合预期。特别是persist之后要验证 SSH key 是否真的能免密登录watch要确认能抓到测试用的 flag 字符串。这个空跑流程我每次赛前都会走一遍有一次就是靠它发现traffic_watch.py在新内核上因为 scapy 版本问题抓不到包提前换了tcpdump方案。从那以后我每次拿到新的工具集合都强制走一遍「空跑验证 → 硬编码检查 → 规则确认」这三步再急也不跳过。希望帮到你。本文还有配套的精品资源点击获取