简介面向CTF线下AWDAttack-Defence赛事的脚本合集专为想在攻防对抗中快速得分、又不愿从零编写工具的选手准备覆盖AWD及AWD Plus常见比赛场景对初学者和经验型玩家均有实用价值。压缩包共34个文件整体仅3.18MB内容以Python脚本12个、PHP文件6个、文本笔记7个为主另含pyc预编译模块、一个RAR工具包及单个exe程序分别承担自动化攻击、漏洞利用、防御加固与日志分析等任务。已有3008人学习下载热度可观。内部按Prepare-for-AWD-master组织提供扫描探测、SQL注入与XSS利用、不死马批量生成/查杀、Web日志安全分析、WAF防护脚本等模块并附有操作笔记与命令提示可直接在合法CTF环境中部署使用帮助参赛者缩短临场调试时间、提升攻防效率。1. CTF线下AWD脚本合集先把生存率拉满再谈骚操作参加过线下CTF的人都有这种体验AWDAttack With Defense赛制下60秒一轮的flag刷新周期全场靶机都在被别人打自己的靶机也可能已经被种了不死马。这时候最缺的不是某个0day而是一套能立刻部署、能止血、能抢分的脚本合集。CTF线下AWD脚本合集就是干这个的——它把批量提交flag、查杀不死马、快速均码、流量分析、WAF防护这些高频动作打包成一个个可以直接跑的脚本帮你把精力从重复劳动里解放出来放到真正需要人脑判断的攻击路径上。这个合集适合三类人第一次打线下赛的新手战队、想把手动操作自动化的大二大三学生、以及需要在赛前快速搭一套防御基座的安全从业者。别指望脚本合集能替你赢比赛但它能保证你在比赛前30分钟不崩盘。2. 先看懂AWD的攻防节奏再决定脚本怎么选2.1 60秒一轮的抢分循环每个脚本挂在哪一环AWD的计分规则直接决定了脚本的用途。主办方会在你的靶机上运行一个flag生成程序每隔60秒左右生成一个新的flag字符串你需要把这个字符串submit到裁判系统submit成功才能得分。与此同时其他队伍的靶机也在执行同样的流程你的攻击脚本如果能从他们的靶机里把flag读出来并提交等于替他们得分这分就算你的。这个循环里最机械的动作就是读flag、提交flag。手动完成一次大约需要3到5秒而一轮只有60秒攻击脚本跑一次可能拿到二三十个队的flag手动根本来不及submit。所以批量提交器是整个合集的刚需比赛刚开始的头10分钟它就是你的得分主力。第二个关键动作是防守。你的靶机一上线就会被扫描Web目录下可能被种PHP一句话木马甚至是不死马——删掉文件后它会通过memcache、数据库会话或者其他方式再生。你需要在被种马之后最快速度发现并清掉否则比分会被不断扣掉。查杀不死马的脚本必须常驻运行至少要做到定时扫描。2.2 按任务分类脚本批量提交、不死马查杀、流量回放、Flag嗅探我一般把脚本合集按用途分成四类第一类是批量提交脚本核心功能是自动从多个靶机上读取flag、批量POST到裁判系统处理提交频率限制和去重逻辑。这类脚本最成熟也最容易写赛前甚至可以拿上一届的题目练手。第二类是不死马查杀与防护脚本功能包括扫描Web目录下最近被修改的文件、识别常见的木马特征函数eval、assert、system等、删除可疑文件、对关键目录做只读保护。第三类是漏洞利用脚本这需要根据现场靶机的情况来调整但基础姿势是通用的扫描开放端口、识别中间件版本、尝试已知CVE和常见弱口令、通过SQL注入或命令执行读取flag。这里要注意利用脚本写得太激进容易把对面靶机打崩裁判会认为你是恶意破坏直接取消资格。第四类是流量分析脚本用tcpdump抓网卡流量用Python解析pcap文件提取HTTP请求中出现的flag字符串或攻击payload。这部分脚本在AWD里特别实用因为对方攻击你的流量里往往带着他的利用代码直接抄回来打他靶机等于用别人的矛戳别人的盾。2.3 语言选型Python为主、Bash为辅助、单文件优先做AWD脚本合集不需要微服务不需要框架甚至不需要面向对象。我踩过坑有一年我写了一个带配置文件、日志模块、异常捕获框架的工程化工具包比赛当天发现靶机环境里连pip的依赖都装不全Python版本还是2.7。从此之后我的原则是脚本一律单文件不引入第三方依赖只用标准库。requests能用urllib替代就绝不用requests因为目标靶机上很可能没有这个包。能用Bash写清楚的就用Bash比如定时查shell、统计文件变更Bash几行就够。Python只在需要正则提取、HTTP交互、pcap解析时出现。代码里不写绝对路径全部用相对路径或环境变量因为你不知道靶机上的Web目录是/var/www/html还是/usr/share/nginx/html。脚本头部统一用os.getenv或参数传入来指定。这种环境友好型脚本虽然在本地看着不像正规军但在AWD那种不给你装依赖的时间点上能跑就是硬道理。很多脚本合集之所以翻车不是因为逻辑不对而是因为环境依赖太重上了靶机连运行都运行不起来。3. 核心脚本逐个拆解从提交器到不死马查杀3.1 批量Flag提交器别把时间耗在网页上比赛开始后你唯一想自动化的就是提交flag。我见过有人用浏览器手动刷一轮刷不过来就得不到了。下面这个脚本是常见的做法用urllib替代requests直接用Python标准库完成批量提交#!/usr/bin/env python3 AWD批量flag提交器 - 单文件版 import urllib.request import urllib.parse import time import re import os # 裁判系统提交接口按实际赛制修改 SUBMIT_URL http://10.0.0.1/api/submit_flag # 从环境变量读取token避免硬编码 TOKEN os.getenv(SUBMIT_TOKEN, game_token) def submit_flag(flag: str) - bool: 提交单个flag返回是否提交成功 data urllib.parse.urlencode({ flag: flag, token: TOKEN }).encode(utf-8) req urllib.request.Request(SUBMIT_URL, datadata) try: with urllib.request.urlopen(req, timeout5) as resp: body resp.read().decode(utf-8, errorsignore) # 裁判系统一般返回success或fail字符串 if success in body.lower(): return True return False except Exception as e: print(f[!] 提交失败: {flag} - {e}) return False def submit_batch(flag_file: str, max_retry: int 3): 读取文件中的flag列表按行提交并去重 seen set() with open(flag_file, r, encodingutf-8, errorsignore) as f: for line in f: flag line.strip() if not flag or flag in seen: continue seen.add(flag) ok False for attempt in range(max_retry): if submit_flag(flag): ok True break time.sleep(1) # 重试间隔避免被限流 print(f[{成功 if ok else 失败}] {flag}) if __name__ __main__: # 用法: python submit.py flags.txt import sys if len(sys.argv) ! 2: print(Usage: python submit.py flag_file) sys.exit(1) submit_batch(sys.argv[1])这段代码的逻辑很简单但有几个讲究。seen集合做去重因为一个flag被提交成功后再次提交是无效的还会拖慢速度max_retry控制重试次数因为AWD现场网络抖动很常见一次超时就放弃会白白丢分TOKEN从环境变量读取而不是硬编码到脚本里这样队友拷贝脚本时不会把token带走。参数调整上timeout5和time.sleep(1)是两个关键值。如果裁判系统响应快可以把timeout压到3秒重试间隔压到0.5秒提升吞吐量如果现场频繁限流要把时间放宽到2秒以上。不做设置的后果就是提交器被裁判系统判定为攻击行为IP被拉黑全队集体丢分。这个真不是玄学我见过连续三年都有人栽在这里。3.2 不死马查杀脚本连接、特征、清杀三步走不死马常驻WebShell是AWD里最让人头疼的东西。它通常用异步连接或写入系统计划任务的方式让自己从内存中恢复单纯删掉文件没有任何意义。查杀脚本我一般做成三步走第一步连接靶机第二步扫描Web目录和系统计划任务第三步删除可疑文件并关闭持久化通道。#!/bin/bash # AWD不死马查杀脚本 - 在靶机上用root权限执行 # 用法: ./kill_webshell.sh /var/www/html WEB_DIR${1:-/var/www/html} echo [*] 步骤一: 扫描最近5分钟内被修改的PHP文件 find $WEB_DIR -name *.php -mmin -5 -type f 2/dev/null | while read f; do echo [] 最近被修改: $f # 提取可疑特征函数 grep -lE eval\(|assert\(|system\(|exec\(|passthru\( $f 2/dev/null done echo [*] 步骤二: 检查系统计划任务中是否有恶意任务 crontab -l 2/dev/null | grep -iE wget|curl|php|python || echo [/] 计划任务干净 echo [*] 步骤三: 删除特征明显的WebShell文件 find $WEB_DIR -name *.php -type f 2/dev/null | while read f; do if grep -qE preg_replace\s*\(\s*[\/e $f 2/dev/null; then rm -f $f echo [-] 已删除: $f fi done echo [*] 查杀完成。建议立即重启php-fpm或Apache清理内存马。这个脚本要解释几个关键点。-mmin -5表示只看5分钟内被修改的文件因为不死马一旦进场一定会在短时间内留下痕迹crontab检查是为了防止对手把重启命令写进计划任务里你删了文件它又拉回来preg_replace的/e修饰符是早年PHP木马的经典特征现在虽然host不支持了但老靶机仍然可能中招。更重要的是清杀之后的操作。删掉文件不等于安全因为你不知道对方是不是把马种在了缓存目录、session目录或者其他可写目录里。查杀脚本之后正确操作是chmod -R o-w /var/www/html # 取消Web目录的其他用户写权限 chattr i /var/www/html/index.php # 锁定关键文件防止被覆盖这两条命令才是防守的核心。关闭文件写权限后对方即使有写入漏洞也写不进新马chattr i锁死文件后连root都不能随意修改。当然这也意味着你自己也不能在线更新代码所以要在确认自己的代码没问题之后才执行。3.3 开局均码脚本把每台靶机调成同一配置均码统一配置听起来像运维操作但在AWD里有另外一个作用减少被攻击面。如果你的靶机和别人的靶机不一样比如多开了一个管理后台多留了一个测试接口那就是天然的突破口。均码脚本的意义在于把靶机环境恢复到主办方给出的初始配置关闭不必要的端口和文件。#!/bin/bash # AWD开局均码脚本 - 根据主办方提供的环境说明做收敛 # 用法: ./hardening.sh # 1. 备份原有配置 BACKUP/tmp/awd_backup_$(date %s) mkdir -p $BACKUP cp -r /var/www/html $BACKUP/html_default 2/dev/null cp /etc/nginx/nginx.conf $BACKUP/nginx.conf.bak 2/dev/null cp /etc/apache2/apache2.conf $BACKUP/apache2.conf.bak 2/dev/null echo [*] 备份完成存于 $BACKUP # 2. 删除常见危险文件 remove_if_exists() { [ -f $1 ] rm -f $1 echo [-] 删除 $1 } remove_if_exists /var/www/html/phpinfo.php remove_if_exists /var/www/html/test.php remove_if_exists /var/www/html/info.php remove_if_exists /var/www/html/backup.zip remove_if_exists /var/www/html/.git/config # 3. 修改默认口令 if [ -f /var/www/html/config.php ]; then sed -i s/password\s*\s*[^]*/password Awd_$(openssl rand -hex 4)/g /var/www/html/config.php echo [*] 数据库口令已随机化 fi # 4. 只保留80和443端口 iptables -A INPUT -p tcp --dport 3306 -j DROP iptables -A INPUT -p tcp --dport 22 -j DROP iptables -A INPUT -p tcp --dport 8080 -j DROP echo [*] 均码完成。非必要端口已关闭。这里最容易被忽略的是数据库端口。很多AWD赛制里选手是可以直连数据库读取flag的这意味着3306端口一旦暴露对方就能直接连你的MySQL把数据拖走。iptables规则里把3306直接DROP等于切断了对方从数据库端口入场的路径。如果你自己还要用数据库那就限定白名单IP访问iptables -A INPUT -p tcp --dport 3306 -s 你所在子网 -j ACCEPT iptables -A INPUT -p tcp --dport 3306 -j DROP均码脚本的坑在备份策略上。cp -r如果目标目录已有同名文件默认覆盖可能会把你自己修改过的代码也覆盖掉。我建议先把整个Web目录打成一个tar包而不是简单复制这样出问题时可以直接解包恢复。比赛现场没人会花时间逐文件对比差异有备份包才算有后悔药。3.4 漏洞利用脚本的边界能用但别迷信AWD的漏洞利用脚本是最具神话色彩的部分。外行以为这是万能钥匙内行知道这只是一张入场券。常见的利用脚本包括扫描同一网段内所有存活靶机的Web服务、测试常见SQL注入点、尝试命令执行端点和文件上传漏洞。这些脚本可以写但你必须清楚它的边界。#!/usr/bin/env python3 AWD网段扫描 常见Web漏洞探测 - 单文件版 import socket import ipaddress import urllib.request import urllib.error import sys import re def check_port(host: str, port: int, timeout: float 1.0) - bool: 检测目标主机端口是否开放 try: s socket.create_connection((host, port), timeouttimeout) s.close() return True except OSError: return False def try_flag_read(host: str) - str: 尝试从常见flag路径读取flag paths [ /flag, /flag.txt, /flag.php, /files/flag, /var/www/html/flag ] for path in paths: url fhttp://{host}{path} try: req urllib.request.Request(url, headers{User-Agent: Mozilla/5.0}) with urllib.request.urlopen(req, timeout2) as resp: body resp.read().decode(utf-8, errorsignore) if re.search(r[a-zA-Z0-9]{20,}, body): return f{url} - {body.strip()} except Exception: pass return def main(network: str): 扫描网段内所有主机的80端口并尝试读取flag for ip in ipaddress.ip_network(network, strictFalse).hosts(): ip_str str(ip) if check_port(ip_str, 80, timeout0.5): result try_flag_read(ip_str) if result: print(f[] {result}) else: print(f[*] {ip_str}:80 开放但未直接读取到flag) if __name__ __main__: if len(sys.argv) ! 2: print(Usage: python scan_web.py 192.168.1.0/24) sys.exit(1) main(sys.argv[1])注意这个脚本的两个阈值timeout0.5是端口探测的超时对AWD这种高强度并发场景来说0.5秒已经是比较激进的设置再短就容易漏报timeout2是HTTP请求的超时因为对方靶机可能负载很高响应慢是常态。如果你把这两个值调成1秒整个扫描可能漏掉一半存活主机。但这脚本最大的问题不是性能而是它太理想化。现实比赛里对面靶机可能压根不在80端口提供Web服务可能在8080甚至随机端口常见的flag路径也可能被主办方改了名字。所以利用脚本之前最好先跑一次pcap流量分析看看对手是怎么攻击你的——他用了哪个端口、哪个路径你照着改脚本去打他成功率高得多。4. 流量分析与WAF部署防守侧的自动应答4.1 用tcpdump抓流量再用Python解析攻击迹在AWD现场你的靶机会收到大量攻击流量这些流量里不仅藏着对方的利用方式有时候对方提交flag的HTTP请求也会从你网卡上经过。抓流量是防守的第一步也是拿到攻击者思路的最快途径。#!/bin/bash # AWD流量抓取脚本 - 后台运行抓取网卡流量并滚动保存 # 用法: ./sniffer.sh eth0 ./pcap IFACE${1:-eth0} OUTDIR${2:-./pcap} mkdir -p $OUTDIR # 按10分钟滚动保存每个文件不超过200MB exec tcpdump -i $IFACE -nn -s 0 \ -w $OUTDIR/awd_$(date %Y%m%d_%H%M%S).pcap \ -G 600 -W 50 \ tcp port 80 or tcp port 443 or udp port 53-G 600表示每600秒生成一个新文件-W 50表示最多保留50个文件超过就删除最旧的。这样抓一整天流量最多占5GB磁盘不会把靶机磁盘打满。-s 0表示抓取完整数据包不要裁剪因为flag或payload可能藏在包尾。抓到流量之后用Python解析pcap提取关键信息#!/usr/bin/env python3 从pcap文件中提取HTTP请求中的flag特征和攻击payload import os import re import sys # 使用dpkt解析pcap如果没有dpkt则跳过HTTP解析 try: import dpkt except ImportError: print([-] 需要安装dpkt: pip install dpkt) sys.exit(1) def extract_http_flags(pcap_file: str): 从HTTP流中提取疑似flag的字符串 flag_pattern re.compile(rflag\{[^}]\}, re.I) attack_patterns [ reval\(, rbase64_decode\(, rsystem\(.*whomai, rcat\s/flag, r/tmp/, r\.php\?cmd, ] with open(pcap_file, rb) as f: pcap dpkt.pcap.Reader(f) for ts, buf in pcap: try: eth dpkt.ethernet.Ethernet(buf) if eth.type ! dpkt.ethernet.ETH_TYPE_IP: continue ip eth.data if ip.p ! dpkt.ip.IP_PROTO_TCP: continue tcp ip.data # 过滤出HTTP流量 if len(tcp.data) 0: continue payload tcp.data.decode(utf-8, errorsignore)[:2048] if HTTP in payload or GET in payload or POST in payload: # 提取flag for m in flag_pattern.findall(payload): print(f[FLAG] {m} from {ip.src}) # 提取攻击payload for pat in attack_patterns: if re.search(pat, payload, re.I): print(f[ATTACK] {pat} from {ip.src}) except Exception: continue if __name__ __main__: if len(sys.argv) ! 2: print(Usage: python parse_pcap.py pcap_file) sys.exit(1) extract_http_flags(sys.argv[1])这段代码本质上就是一个极简的IDS。它不做深度解码只提取明文HTTP流量中的特征字符串但AWD里绝大多数Web攻击都是明文HTTP足够用了。attack_patterns列表里写的都是真实出现过的特征比如base64_decode(代表对方尝试用编码绕过cat /flag代表对方已经能执行命令。每抓到一条你就多一条针对对手的利用思路。很多人以为AWD的攻击手在脑内进行复杂推演实际上高手都在抄流量包。4.2 WAF规则拦截常见PHP攻击特征但不误伤队友AWD的WAF部署和线上业务WAF不同不需要高并发不需要语义分析只需要规则精准且能快速更新。最常见的做法是改Nginx层拦截。# 在nginx.conf的server段中加入防注入和防文件包含规则 # 重点拦截: SQL注入、XSS简单变体、命令执行、PHP文件包含 location ~* \.(php|asp|jsp)$ { # SQL注入基础拦截 if ($query_string ~* union.*select.*from) { return 403; } if ($query_string ~* \.\./\.\.) { return 403; } if ($query_string ~* base64_decode.*) # PHP文件包含拦截 if ($query_string ~* include.*php) { return 403; } if ($query_string ~* data://) { return 403; } if ($query_string ~* php://filter) { return 403; } # 命令执行拦截 if ($query_string ~* system.*cat) { return 403; } if ($query_string ~* passthru) { return 403; } # 上传目录禁止执行PHP location ^~ /upload/ { location ~* \.php$ { return 403; } } }这个WAF配置的精髓在最后一段/upload/目录下的所有PHP请求直接403。攻击者的惯用手法是先传一个PHP幻术图片再通过文件包含漏洞去执行它。把上传目录的执行权关掉这整条攻击链就断了一半。这比你在应用层写一堆if判断要高效得多而且不需要修改业务代码。WAF规则最大的坑是误伤队友。AWD是允许选手之间互相攻击的你的WAF如果拦截了正常提交flag的操作那比被打还要致命。我在比赛里干过这事——把flag字符串当作黑名单关键词写进WAF结果自己队的submit请求被自己的Nginx拦了整整10分钟没提交上分。从那之后我给自己定了一条规矩WAF规则里绝对不碰flag这个纯字符串只拦攻击特征不拦数据内容。4.3 日志监控告警脚本用最少资源发现被攻破流量抓取是被动的WAF拦截是主动的但真正的风险在于对方已经打进你的靶机但你还没察觉。一个轻量的日志监控脚本能解决这个问题不用引入ELK不用安装Agent几行Bash就能做到。#!/bin/bash # 日志监控告警 - 每隔30秒扫描一次Web日志发现可疑请求立即告警 # 用法: ./log_monitor.sh /var/log/nginx/access.log LOG_FILE${1:-/var/log/nginx/access.log} CURSOR_FILE/tmp/awd_log_cursor INTERVAL${2:-30} # 记录上次扫描到的行数 if [ ! -f $CURSOR_FILE ]; then wc -l $LOG_FILE $CURSOR_FILE fi while true; do OLD_POS$(cat $CURSOR_FILE) NEW_POS$(wc -l $LOG_FILE) if [ $NEW_POS -gt $OLD_POS ]; then # 提取新增日志中的可疑请求 tail -n $((OLD_POS 1)) $LOG_FILE | \ grep -iE \.\./|union.*select|php://|system\(|eval\(|/tmp/|\.bak|\.sql | \ while read line; do NOW$(date %H:%M:%S) echo [$NOW] [WARN] 可疑请求: $(echo $line | cut -c1-200) # 可选: 通过curl发送到团队告警群 done fi echo $NEW_POS $CURSOR_FILE sleep $INTERVAL done这个脚本的资源占用几乎可以忽略不计但效果很直接。每当有攻击者尝试路径穿越、SQL注入、文件包含时日志里会留下痕迹grep模式会在30秒内发现并输出告警。这里最值得调的参数是INTERVAL——我在实际使用时设成15秒因为攻击者在AWD里的操作窗口很短30秒他可能已经种完马走人了。但如果你靶机配置低15秒的轮询也会造成一定负载需要做一个取舍。告警之后别急着去删文件。先顺着IP查对方的行为链条看他尝试了哪些路径、用了哪些参数。很多时候你看到的不只是攻击尝试而是对方完整的利用流程这比你自己Fuzz半天的收获大多了。5. AWD脚本合集的翻车现场我踩过的坑都在这了5.1 Flag提交器把自身作业给提交了现象批量提交器跑了几分钟后提交成功率突然变为0日志里全是重复提交失败。 原因脚本设置了while True无限重试没做flag去重立刻把已经提交过的flag又提交了一遍。更糟的是脚本从靶机A读到了靶机B的flagB队已经把同样的flag提交过了你这属于替别人重复得分裁判系统会拒绝。 解决把脚本改成只提交未出现在本地历史记录中的flag用seen集合持久化到本地文件每次运行先加载上次的结果。同时对同一个flag设置冷却时间至少5分钟之内不重复提交。这是脚本合集里最不该犯的错但每年都有人犯。5.2 查杀不死马时把自家正常后门也删了现象对自己的靶机跑查杀脚本后靶机上的正常管理功能全部失效比赛后半程想更新代码都没法操作。 原因查杀脚本只按特征匹配grep -E eval|system|exec把业务代码中正常调用的exec函数也识别为木马直接删除。 解决查杀脚本里加一个白名单机制对已知的正常文件做哈希记录只删除不在白名单且命中多个特征的文件。判定条件从一个特征命中升级为至少命中3个特征且文件不在白名单。我在脚本里专门写了一个KNOWN_GOOD_SHA256列表赛前把主办方的初始代码全部跑一遍记录哈希比赛过程中只扫哈希变化过的文件。5.3 iptables规则把自己SSH断掉现象均码脚本执行后自己无法SSH登录靶机远程操作完全瘫痪。 原因均码脚本里执行了iptables -A INPUT -p tcp --dport 22 -j DROP本意是关掉SSH防止别人进但自己也没留白名单。 解决在执行任何DROP规则之前先确认自己的IP在允许列表里MY_IP$(curl -s ifconfig.me 2/dev/null || echo 未知IP) iptables -A INPUT -p tcp --dport 22 -s $MY_IP -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP这个顺序不能反过来先加白再DROP。另外建议在执行脚本前先开一个临时screenshot会话就算iptables崩了还能通过物理终端恢复。这个坑我翻过一次车比赛到一半只能找裁判要控制台权限特别狼狈。5.4 WAF拦截了自己队的批量submit请求现象攻击流量确实被拦截了但自己的得分也开始直线下降。 原因Nginx的if ($query_string ~* flag)把submit请求的body当成query string检查凡是带flag字符串的请求全部403。 解决如前面说的不要把flag当黑名单关键词。WAF拦截对象应该是攻击特征而不是数据内容——flag本身是正常业务数据。我最后写的WAF规则只匹配union select、../../、php://filter、system(这类攻击语法完全不管请求里带不带flag。5.5 流量分析脚本被现场海量垃圾流量淹没现象抓了10分钟流量pcap文件已经几个GB解析脚本跑了一个小时还在处理前10分钟的包。 原因AWD现场同网段有几十台靶机广播包、ARP包、大量扫描流量全都被抓了进来有效HTTP请求只占很小比例。 解决抓包时就用过滤条件收缩范围只抓TCP端口80和443的数据且只抓发往自己靶机IP的流量。如果你不知道攻击者的IP范围可以抓目标为自身的流量tcpdump -i eth0 -nn -s 0 -w output.pcap tcp port 80 and dst host 你的靶机IPdst host直接限定目标能过滤掉80%的无关流量。这个改动看着小但直接影响你能不能及时解析出攻击payload。5.6 脚本合集的版本混乱上靶机才发现是旧版现象比赛当天从网盘/优盘拷脚本到靶机运行报错参数对不上队友之间互相传的副本还不一致。 原因脚本合集没有做版本管理迭代了20多个版本文件名还都一样。有人改了代码没改文件名传到群里又被人覆盖。 解决每份脚本头部都要写清楚VERSION和CHANGELOG文件名也要带版本号例如submit_flags_v2.1.py。最好赛前把所有脚本打包成一个tar.gz用固定的压缩包名字存到U盘和网盘两个地方上靶机解压时先比对md5。这一点看起来是管理问题但每年都有队伍因为脚本版本不一致临时改代码浪费30分钟这30分钟够别人拿三次flag了。6. 让脚本合集真正跑起来从本地验收到赛前预演6.1 赛前48小时的脚本演练清单脚本写出来不是终点能在比赛现场稳定运行才是。我建议赛前48小时做一次完整演练严格模拟比赛环境检查项操作通过标准提交器端到端用一个临时账号向裁判系统提交100次随机flag提交成功且无超时查杀脚本有效性手动在Web目录放一个测试马跑脚本删除测试马被清正常代码未被误删WAF规则回归模拟SQL注入、路径穿越、文件包含三类攻击全部返回403正常业务不受影响流量抓取后台跑10分钟tcpdump检查文件大小和解析结果pcap文件可正常解析出HTTP请求均码脚本收敛在当前靶机跑完检查所有非必要端口已关闭只剩80/443和SSH白名单脚本合集md5打包并记录所有脚本的md5U盘和网盘文件md5一致这张表里的任何一项在实战中翻车都足以让你整场比赛陷入被动。演练不是走流程我发现可以每次都发现至少一个问题——有年演练时发现提交器在Windows靶机上Python编码有问题改了三行才修好还有年WAF规则漏了data://协议补上后才放心。6.2 应急时只信任自己能解释的脚本脚本合集再全也有覆盖不到的意外场景。我的经验是在应急情况下只运行完全看得懂逻辑的脚本绝不执行看不懂的大神脚本。这句话背后的教训很深刻——有一年别人传给我一个万能查杀脚本说是能清所有马我信了跑完之后发现靶机上的Web服务直接起不来了后来排查发现脚本里有一段rm -rf /tmp/*把PHP的session文件全删了直接导致服务不可用。应急时你需要的是把原理讲清楚的脚本提交器知道你提交的URL是什么、查杀脚本知道它删了哪个文件、WAF规则知道你拦了哪种攻击。但凡有任何一个环节是黑匣子都不要让它出现在正式比赛里。CTF线下AWD脚本合集的价值在于可控的自动化而不是神秘的武器库。6.3 快速验证脚本、学会给自己留后悔药最后一个习惯和验证有关。每次修改脚本后不要只跑一次就收工。我的标准流程是先在本地起一个最小靶场环境一个容器或者一台虚拟机跑NginxPHP放上测试flag和测试木马文件跑一遍全套脚本。这个验证过程每次不超过10分钟但能拦住80%的翻车场景。同时任何操作之前先想好怎么回滚。均码脚本跑出问题要能从备份恢复、WAF拦错流量要能快速关掉规则、ipset拉黑要能清空列表。我给每台靶机的/tmp都放了一个自己写的rollback.sh内容很简单调用备份目录里的原始配置覆盖回去然后重启服务。这个脚本在比赛后半段几乎都会用到——当你发现某个限制条件误伤了正常业务立刻执行它就能恢复。AWD比赛不是写代码能力的较量而是在极度紧张和噪音环境下保持操作正确性的较量。脚本合集帮你把高频操作变成半自动但半自动的前提是你能解释它、信任它、控制它。我这几年的感受是与其囤积各种华丽的脚本库不如把自己最常用的五个脚本打磨到极致并且知道它们的每一行在干什么。希望这份经验对你有用祝比赛顺利。本文还有配套的精品资源点击获取
