企业官网建设流程全解析

简介：这是一套面向网络安全竞赛选手与攻防爱好者的AWD实战脚本工具包，聚焦攻防对抗场景下的信息收集、漏洞利用与系统防护需求。压缩包共34个文件，约3.18MB，以Python脚本、PHP木马、pyc编译文件、txt说明文档为主，另含exe工具、rar压缩包与md说明，覆盖攻击与防御两条主线。资源按攻击、防御及补充资料分区组织，攻击侧包含信息收集、不死马生成、Webshell上传与GetFlag等脚本，防御侧提供WAF、文件监控、日志分析与克制不死马等方案，并附命令生成说明与日志地址配置。目前已有688人学习下载，适合希望快速搭建攻防演练环境、熟悉常见脚本用法与排错思路的参赛者参考，也可作为团队协作与应急响应的练习素材。需注意所有工具应在合法合规前提下使用。

1. AWD 攻防赛脚本集合：从“手忙脚乱”到“半自动防守”的落地拆解

打 AWD 攻防赛最让人血压飙升的，不是对手有多强，而是你刚把 Web 服务修好，对手已经用脚本批量改了你三台机器的 SSH 密码；你还在手动ssh一台台看日志，隔壁队伍已经用自动化脚本把 flag 提交了三轮。AWD 的本质是“时间窗口内的攻防效率比拼”，谁先把重复动作脚本化，谁就能腾出手来做真正的漏洞利用和权限维持。这份《AWD攻防赛脚本集合.zip》就是冲着这个痛点来的——它不是某个单一漏洞的 EXP，而是一组覆盖“批量连接、服务巡检、flag 提交、权限维持、日志清理”的常用脚本合集，适合第一次打 AWD 的新手快速建立防守节奏，也适合老手拿来当模板改自己的私有工具链。下面我按“资源是什么 → 怎么用 → 坑在哪”的顺序，把包里脚本的典型用法和参数配置拆开讲。

2. 脚本集合的组成与运行环境：先搞清楚你手里有什么

2.1 包内脚本分类与典型文件结构

拿到一个脚本集合，第一件事不是急着跑，而是先看目录结构。AWD 脚本集合通常按功能分目录，常见结构如下：

awd_scripts/ ├── connect/ # 批量 SSH / 批量执行命令 │ ├── batch_ssh.py │ └── hosts.txt ├── check/ # 服务存活与端口巡检 │ ├── port_scan.sh │ └── web_check.py ├── submit/ # flag 自动提交 │ ├── auto_submit.py │ └── config.ini ├── persist/ # 权限维持与后门清理 │ ├── ssh_key_push.sh │ └── cron_backdoor.sh └── clean/ # 日志清理与痕迹处理 └── clear_log.sh

这个结构不是固定的，但功能划分逻辑基本一致。connect目录解决“怎么同时操作多台机器”，check解决“怎么快速发现服务异常”，submit解决“怎么在拿到 flag 后第一时间交上去”，persist和clean则是攻防对抗中“保权限”和“擦痕迹”的环节。先确认每个脚本的依赖：Python 脚本一般需要paramiko、requests，Shell 脚本依赖sshpass、nmap、curl。缺依赖直接跑，报错会让人误以为是脚本本身有问题。

2.2 运行环境准备：Python 依赖与 SSH 免密

AWD 比赛环境通常是 Linux 靶机，但你的攻击机可能是 Windows + WSL 或者一台 Linux 跳板。不管哪种，先把基础依赖装齐：

# 更新包列表并安装常用工具 sudo apt update sudo apt install -y python3 python3-pip sshpass nmap curl # 安装 Python 依赖 pip3 install paramiko requests beautifulsoup4

paramiko是 Python 里做 SSH 连接最常用的库，requests用来提交 flag 或探测 Web 服务，beautifulsoup4在需要解析 HTML 拿 flag 时用得上。sshpass则是 Shell 脚本里非交互式 SSH 登录的关键——没有它，batch_ssh.sh这类脚本会卡在密码输入提示上。

提示：如果比赛环境不允许联网装包，提前在本地把paramiko和requests的 wheel 包下好，用pip3 install --no-index --find-links=./wheels paramiko离线安装。

接下来配置 SSH 免密，这是批量操作的前提。假设你手上有三台靶机，IP 分别是192.168.1.10、192.168.1.11、192.168.1.12，统一用root登录：

# 生成密钥对（如果已有可跳过） ssh-keygen -t rsa -b 2048 -N "" -f ~/.ssh/awd_key # 把公钥推到每台靶机 for ip in 192.168.1.10 192.168.1.11 192.168.1.12; do sshpass -p '初始密码' ssh-copy-id -i ~/.ssh/awd_key.pub -o StrictHostKeyChecking=no root@$ip done

-N ""表示密钥不设密码，方便脚本自动调用；StrictHostKeyChecking=no跳过首次连接的指纹确认，否则脚本会卡在yes/no交互上。这一步做完，后续所有批量 SSH 操作都不需要再输密码。

2.3 批量连接脚本的参数配置与执行

batch_ssh.py这类脚本的核心逻辑是：读一个主机列表文件，对每台机器执行同一串命令，然后把输出汇总。典型用法如下：

# batch_ssh.py 核心片段 import paramiko HOSTS_FILE = "hosts.txt" KEY_FILE = "/root/.ssh/awd_key" CMD = "cat /flag 2>/dev/null; hostname; whoami" def run_cmd(host, cmd): client = paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, username="root", key_filename=KEY_FILE, timeout=5) stdin, stdout, stderr = client.exec_command(cmd) out = stdout.read().decode() client.close() return out with open(HOSTS_FILE) as f: for line in f: ip = line.strip() if not ip: continue try: print(f"===== {ip} =====") print(run_cmd(ip, CMD)) except Exception as e: print(f"[!] {ip} 连接失败: {e}")

hosts.txt每行一个 IP，不要带多余空格。timeout=5是连接超时，AWD 环境里靶机可能被对手打挂，超时设太长会拖慢整个脚本。AutoAddPolicy()自动接受未知主机密钥，省去手动确认。执行时直接python3 batch_ssh.py，输出会按机器分组打印。如果某台机器连不上，脚本会打印失败信息并继续下一台，不会整体中断——这个容错设计在比赛里很关键，因为对手可能已经把你某台机器搞下线了。

3. 服务巡检与 flag 自动提交：把重复动作交给脚本

3.1 端口与服务存活巡检脚本

AWD 比赛中，你的服务可能被对手kill掉，也可能被植入 WebShell 后门。巡检脚本要做的就是快速告诉你“哪些端口还活着、哪些页面被改了”。一个典型的 Shell 巡检脚本如下：

#!/bin/bash # port_scan.sh - 快速巡检常见 AWD 端口 HOSTS="192.168.1.10 192.168.1.11 192.168.1.12" PORTS="22 80 443 3306 8080" for host in $HOSTS; do echo "===== $host =====" for port in $PORTS; do timeout 2 bash -c "echo > /dev/tcp/$host/$port" 2>/dev/null \ && echo "[+] $port open" \ || echo "[-] $port closed" done done

/dev/tcp是 Bash 内置的 TCP 连接方式，不需要额外装nc或nmap，在比赛环境里更轻量。timeout 2控制单次探测不超过 2 秒，避免某个端口卡住导致整个巡检变慢。输出里[+]表示端口开放，[-]表示关闭或被防火墙拦截。如果发现 80 端口从 open 变成 closed，说明 Web 服务挂了，需要立刻上去重启。

Web 服务巡检可以进一步用curl检查 HTTP 状态码和页面关键字：

# web_check.sh - 检查 Web 服务是否返回正常页面 for host in $HOSTS; do code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 3 "http://$host/") echo "$host HTTP_CODE=$code" # 如果状态码不是 200，尝试重启服务 if [ "$code" != "200" ]; then ssh -i ~/.ssh/awd_key root@$host "systemctl restart nginx 2>/dev/null || service apache2 restart" fi done

-o /dev/null丢弃页面内容，-w "%{http_code}"只输出状态码，--max-time 3限制请求时间。状态码非 200 时自动尝试重启 Nginx 或 Apache，这个“自愈”逻辑在比赛里能省下大量手动操作时间。注意重启命令要兼容systemctl和service两种方式，因为不同靶机的初始化系统可能不一样。

3.2 flag 自动提交脚本的配置与去重

flag 提交是 AWD 里最机械也最不能出错的动作。手动提交容易漏、容易重复、容易在复制粘贴时出错。自动提交脚本的核心是：从目标位置读取 flag，通过比赛平台接口提交，并记录已提交的 flag 防止重复。

# auto_submit.py 核心逻辑 import requests import hashlib import time SUBMIT_URL = "http://比赛平台地址/api/submit" TOKEN = "你的队伍token" FLAG_FILE = "/flag" RECORD_FILE = "submitted.txt" def load_submitted(): try: with open(RECORD_FILE) as f: return set(line.strip() for line in f) except FileNotFoundError: return set() def save_submitted(flag): with open(RECORD_FILE, "a") as f: f.write(flag + "\n") def submit(flag): resp = requests.post(SUBMIT_URL, data={"flag": flag, "token": TOKEN}, timeout=5) return resp.status_code == 200 submitted = load_submitted() while True: try: with open(FLAG_FILE) as f: flag = f.read().strip() if flag and flag not in submitted: if submit(flag): print(f"[+] 提交成功: {flag}") save_submitted(flag) submitted.add(flag) else: print(f"[-] 提交失败: {flag}") except FileNotFoundError: pass time.sleep(10)

submitted.txt是去重记录，每提交成功一个 flag 就追加一行。time.sleep(10)控制轮询间隔，太短会给平台接口造成压力，太长会错过 flag 刷新窗口。TOKEN和SUBMIT_URL需要根据比赛平台的实际接口替换——不同平台的提交参数名可能不一样，常见的是flag和token，也有用answer和team_id的。拿到平台接口文档后先手动提交一次，用浏览器开发者工具看请求参数，再改脚本。

注意：有些比赛的 flag 是动态刷新的，每轮会变。这种情况下脚本要配合“flag 监控”逻辑，检测到/flag文件内容变化后立即提交，而不是固定间隔轮询。

3.3 权限维持与后门清理的脚本化

AWD 的攻防是双向的：你既要防对手进来，也要在拿到对手机器权限后维持住。权限维持脚本通常做两件事：推送自己的 SSH 公钥、写定时任务反弹 Shell。

#!/bin/bash # ssh_key_push.sh - 向目标机器推送公钥 TARGET=$1 KEY="ssh-rsa AAAAB3Nza... your_key_here" sshpass -p '拿到的密码' ssh -o StrictHostKeyChecking=no root@$TARGET \ "mkdir -p ~/.ssh && echo '$KEY' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

这个脚本把公钥追加到目标机器的authorized_keys，之后就能免密登录。chmod 600是必须的，否则 SSH 会拒绝使用这个密钥文件。如果对手已经改了密码，这个脚本就失效了，需要先用漏洞拿到的 Shell 来执行。

后门清理则是反向操作：检查自己机器上有没有对手留下的异常 SSH 公钥、异常定时任务、异常进程。

# check_backdoor.sh - 检查常见后门痕迹 echo "===== authorized_keys =====" cat ~/.ssh/authorized_keys 2>/dev/null echo "===== crontab =====" crontab -l 2>/dev/null ls -la /etc/cron.d/ /etc/cron.daily/ 2>/dev/null echo "===== 异常监听端口 =====" netstat -tlnp 2>/dev/null | grep -v "127.0.0.1" echo "===== 异常进程 =====" ps aux | grep -E "nc |ncat|socat|python -c" | grep -v grep

authorized_keys里如果出现不认识的公钥，直接删掉。crontab和/etc/cron.d/里如果有奇怪的定时任务，比如每隔几分钟反弹一次 Shell，也要清理。netstat看有没有非业务端口在监听，ps aux看有没有nc、socat这类常见反弹工具在跑。这个脚本建议每轮比赛间隙跑一次，养成习惯。

4. 避坑与常见问题：脚本跑不起来先看这几条

4.1 SSH 连接超时或拒绝

现象：batch_ssh.py对某台机器一直报TimeoutError或Connection refused。

原因：靶机 SSH 服务被对手打挂，或者防火墙规则被改，22 端口不通。也可能是你自己之前改了 SSH 配置导致服务没重启。

解决：先用port_scan.sh确认 22 端口状态。如果端口 closed，通过比赛平台的 VNC 或控制台进去重启 SSH：systemctl restart sshd。如果端口 open 但连接被拒，检查/etc/hosts.deny和iptables -L有没有被加规则。

4.2 flag 提交返回 403 或 token 无效

现象：auto_submit.py打印[-] 提交失败，HTTP 状态码 403。

原因：token 过期、提交频率过高被平台限流、或者 flag 格式不对（比如多了换行符或空格）。

解决：先手动提交一次确认 token 有效。检查flag.strip()是否去掉了所有空白字符。如果平台有限流，把time.sleep(10)改成 30 秒。有些平台要求 flag 带特定前缀，确认读取到的 flag 是否完整。

4.3 批量脚本把正常服务误杀

现象：巡检脚本执行后，原本正常的 Web 服务反而挂了。

原因：重启命令写得太粗暴，比如killall nginx之后没有正确启动，或者systemctl restart在服务本身有依赖问题时失败。

解决：重启前先nginx -t检查配置语法，确认无误再 restart。更稳妥的做法是先用curl确认服务确实不可用，再执行重启，避免“误判导致误杀”。可以在脚本里加一层判断：只有连续两次检测到非 200 才触发重启。

4.4 日志清理脚本把关键证据也删了

现象：跑完clear_log.sh后，自己排查问题时找不到任何日志。

原因：清理脚本直接rm -rf /var/log/*，把系统日志和业务日志一起清了。

解决：清理要有选择性，只清包含自己操作痕迹的日志行，比如sed -i '/你的IP/d' /var/log/auth.log，而不是整个删除。比赛里保留日志对复盘和申诉都有用，别图省事全删。

4.5 Python 脚本在靶机上跑报缺少模块

现象：把auto_submit.py传到靶机上执行，报ModuleNotFoundError: No module named 'requests'。

原因：靶机环境精简，没有装 Python 第三方库，且可能无法联网安装。

解决：提交脚本尽量放在自己的攻击机上跑，通过 SSH 读取靶机上的 flag 文件，而不是把脚本传到靶机。如果必须在靶机跑，提前用pip3 download把依赖包下好，一起传过去离线安装。

5. 进阶技巧：把脚本串成一条“防守流水线”

单个脚本用起来是散的，真正提效的是把它们串成一条定时执行的流水线。我一般会写一个watchdog.sh，每 30 秒跑一轮巡检 + 提交 + 后门检查，用cron或while循环驱动：

#!/bin/bash # watchdog.sh - AWD 防守流水线 while true; do echo "===== $(date) =====" bash port_scan.sh bash web_check.sh python3 auto_submit.py --once bash check_backdoor.sh sleep 30 done

auto_submit.py --once表示只跑一轮提交就退出，而不是无限循环，这样流水线不会卡在提交环节。sleep 30是整条流水线的节奏，比赛前期可以调到 10 秒，后期稳定后调到 60 秒减少负载。

另一个实用技巧是给脚本加“变更检测”：用md5sum记录关键文件的哈希，下一轮对比，发现变化就告警。

# 记录 Web 目录哈希 find /var/www/html -type f -exec md5sum {} \; > /tmp/web_hash_now.txt # 与上一轮对比 if [ -f /tmp/web_hash_last.txt ]; then diff /tmp/web_hash_last.txt /tmp/web_hash_now.txt && echo "无变化" || echo "[!] Web 目录被改动" fi mv /tmp/web_hash_now.txt /tmp/web_hash_last.txt

这个逻辑能帮你第一时间发现对手有没有在你的 Web 目录里留 WebShell。diff有输出就说明文件被增删改，需要立刻人工确认。

参数配置上，hosts.txt和config.ini这类文件建议用版本管理工具管起来，每轮比赛前确认 IP 列表和 token 是最新的。我吃过亏——有一次比赛换了靶机网段，脚本还在打上一轮的 IP，白白浪费了十分钟。从那以后我每次开赛前都强制走一遍“改配置 → 单机测试 → 批量执行”的流程，确认第一台机器返回正常后再放开跑。希望帮到你。

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