服务器远程管理端口变更与蜜罐诱捕设置

服务器远程管理端口，默认的22号（SSH）和3389号（RDP）端口，早已是互联网上自动化扫描攻击的重灾区。把远程端口从默认改为高位端口，比如五位数甚至六位数的随机端口，是降低噪音攻击、规避自动化脚本批量扫描最直接有效的手段。这并非什么高深的安全策略，而是一种基础的风险规避，目的是让你的服务器在互联网的“背景辐射”里变得不那么显眼，从而大幅减少被无差别攻击命中的概率。

变更端口不是为了彻底隐藏服务，而是提高攻击者的成本。绝大多数批量扫描工具只会探测默认端口或常见的几十个端口，一旦你跳出了这个范围，那些依赖于撞大运的扫描器就会直接略过。对于Linux系统下的SSH服务，修改配置文件是最稳妥的方式。编辑 /etc/ssh/sshd_config 文件，找到 Port 这一行，将其修改为一个你选定的高位端口，比如 49221。注意，不要直接删除原有的22端口配置，而是先新增一行 Port 49221，保留22端口，待新端口测试通过后再删除22端口那行。这样能防止因配置失误导致自己也被锁在服务器外面。

# 编辑SSH配置文件
vim /etc/ssh/sshd_config

# 先添加新端口，保留22端口
Port 22
Port 49221

# 保存退出后重启SSH服务
systemctl restart sshd

新开一个终端窗口，用新端口尝试连接，确认连接成功后，再回到配置文件里删除 Port 22 这一行，再次重启SSH服务。至此，端口变更才算安全完成。对于Windows服务器的RDP，操作同样简单，但需要在注册表里进行修改。定位到 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp，找到 PortNumber 键值，切换到十进制，输入你想要的高位端口号，然后重启服务器。务必在防火墙里同步放行这个新端口，否则修改后你将无法连接。

改了端口，整个运维链路里的相关工具都得同步更新。防火墙规则要第一时间把新端口放行，并视情况逐步关闭老端口的入站规则。自动化部署脚本、监控系统的探活检测、日志分析平台的采集配置，这些地方但凡有硬编码了端口的地方，遗漏一处就会导致运维盲区。很多人在变更端口后，发现堡垒机连不上了，或者监控告警开始误报，原因就在这里。建议在内部维护一份端口分配表，把变更记录文档化，避免团队协作时出现信息断层。

另外，本地客户端的SSH config文件也可以配合调整，简化日常连接操作。在 ~/.ssh/config 里为你的服务器设置别名和端口，之后连接时直接输别名即可，不必每次敲一串长端口号。

Host my-production-server
    HostName 192.168.1.100
    Port 49221
    User admin
    IdentityFile ~/.ssh/id_rsa

这样一次配置，后续连接效率不受端口变更的影响。端口变更本身不是一劳永逸的，它只是让服务器从“满大街都是”的目标变成了“需要针对性扫描”的目标。真正有目的的攻击者，一旦通过其他手段锁定了你的IP，依然会进行全端口扫描来发现你的SSH或RDP服务。这时候，蜜罐诱捕就该上场了。

蜜罐在远程管理安全里的核心价值，不是防御，而是欺骗和感知。在原本的默认端口上部署一个伪装服务，当攻击者扫描到22端口并尝试连接时，他会被引入一个虚假的、被严密监控的环境里。这个环境对正常业务毫无影响，因为你的真实服务根本不在这个端口上。任何对默认端口的访问，本质上都是非正常的，要么是扫描器，要么是攻击者。通过蜜罐，你能在攻击者还没摸到真实服务之前，就捕获到他的行为特征、IP来源、尝试的账号密码字典，甚至他下一步打算执行的命令。

选型上，对于SSH蜜罐，Cowrie 是目前社区最活跃、功能最完善的开源方案。它模拟了一个完整的SSH服务环境，允许攻击者“成功登录”，并提供一个伪造的文件系统，记录攻击者的每一条指令。对于RDP蜜罐，PyRDP 是主流选择，它能中间人劫持RDP连接，记录攻击者的桌面操作、键盘输入，甚至能回放攻击过程。这两款工具都支持将日志输出到JSON格式，方便对接SIEM或日志分析平台。

部署Cowrie建议使用Docker，隔离环境且方便管理。将Cowrie的SSH监听端口映射到宿主机的22端口，这样攻击者扫描你的服务器22端口时，实际上进入的是Cowrie的蜜罐。Cowrie默认不允许直接以root登录，需要先让攻击者用伪造的账号密码进入，这个设计本身就拖慢了攻击者的节奏。你需要修改cowrie.cfg里的hostname字段，让它看起来像一台真实的服务器名称，而不是默认的cowrie，否则有经验的攻击者一眼就能识别出来。

# docker-compose.yml 示例
version: '3'
services:
  cowrie:
    image: cowrie/cowrie:latest
    ports:
      - "22:2222"
    volumes:
      - ./cowrie/etc:/cowrie/cowrie-git/etc
      - ./cowrie/log:/cowrie/cowrie-git/log
    restart: unless-stopped

启动后，检查日志目录下的cowrie.log，你会看到所有对22端口的连接尝试。Cowrie会记录攻击者输入的每一条命令、下载的每一个文件。你可以设置cowrie.cfg中的download_limit_size来限制攻击者通过蜜罐下载文件的大小，防止蜜罐被滥用。还有一个重要的配置是fake_addr，把它设置成内网里一个不存在的IP段，这样攻击者在蜜罐里尝试扫描内网时，不会影响到真实内网资产。

PyRDP的工作模式是中间人代理，它需要监听在3389端口，同时你要把真实的RDP服务挪到另一个端口上。PyRDP在攻击者和真实RDP服务之间建立连接，透明地记录所有交互。如果你的服务器本身不需要对外提供RDP服务，那就更简单，直接让PyRDP监听3389，后端不接任何真实服务，纯粹作为一个高交互蜜罐运行。配置时，建议开启SSL以模拟真实的RDP加密连接，并设置证书路径。PyRDP的日志回放功能非常强大，你可以像看视频一样回放攻击者的桌面操作过程，这对于分析攻击者的意图和手法极有价值。

# PyRDP 命令行启动示例
pyrdp-mitm.py --listen 3389 --target 127.0.0.1:3390 \
  --certificate cert.pem --private-key key.pem \
  --log-dir /var/log/pyrdp --replay-dir /var/log/pyrdp/replays

如果攻击者在RDP会话里打开了浏览器、登录了某个系统，PyRDP都能完整记录下来。这些数据对于威胁情报的积累和攻击溯源非常有帮助。

蜜罐部署后会产生大量日志，如果不加以利用，蜜罐就只是一个摆设。核心是要把蜜罐日志接入到你的安全运营流程里。Cowrie和PyRDP都支持JSON格式日志输出，可以用Filebeat之类的轻量级采集器把日志送到日志中心或SIEM系统。在SIEM里建立规则，当某个IP在蜜罐里触发了特定行为，比如尝试下载恶意样本、执行了权限提升命令，就自动将该IP加入防火墙黑名单，阻断其对真实服务的访问。

更进一步，可以把蜜罐捕获的攻击者IP同步到威胁情报平台，或者在你管理的其他服务器上联动封禁。这样，攻击者在碰触蜜罐的那一刻，就丧失了访问你整个网络资产的机会。这种联动处置的时效性很重要，建议采用自动化的方式，通过脚本或SOAR平台来实现秒级响应。

把端口变更和蜜罐诱捕放在一起看，它们构成了一组互补的防御纵深。端口变更把真实服务隐藏到高位端口，蜜罐则在默认端口上张开一张网。攻击者的扫描行为会先撞上蜜罐，被记录、被分析、被阻断，而你的真实服务始终处于相对安全的位置。即便攻击者通过其他信息泄露知道了你的真实端口，蜜罐捕获的早期情报也已经为你争取到了响应时间。

这种组合还有一个隐蔽的好处：攻击者很难判断自己到底有没有找到真实服务。他在22端口遇到了一个SSH服务，但这个服务的行为模式可能和常规服务器略有不同，他会犹豫这是蜜罐还是配置特殊的真实服务器。这种不确定性本身就消耗了攻击者的时间和资源。而对于防守方来说，任何触碰默认端口的连接都是可疑的，不需要去辨别这是误触还是攻击，一律按攻击对待，处置逻辑清晰明确。

端口变更和蜜罐部署完成后，日常运维里还有几个容易忽视的点。第一，蜜罐本身也需要维护和更新，它的漏洞可能被攻击者利用来逃逸，所以蜜罐的Docker容器或运行环境要定期更新。第二，蜜罐的日志量可能很大，要设置合理的日志轮转策略，避免磁盘被撑爆。第三，如果你在多个云服务器上部署了蜜罐，可以考虑把蜜罐日志汇总到一个中心节点，这样能形成更全面的攻击者画像。

另外，蜜罐的伪装程度决定了它的诱捕效果。Cowrie的文件系统里可以放置一些看似敏感的假文件，比如名为“数据库密码.txt”的文件，内容则是虚假的凭证。攻击者一旦查看或下载这些文件，你就能获得更高置信度的攻击确认。这些细节能让蜜罐从简单的端口监听升级为一个真正的情报收集节点。

端口变更降低了被发现的概率，蜜罐增加了攻击者暴露的风险，两者结合，把远程管理这个原本脆弱的面，变成了一个具备主动感知能力的防御阵地。这种思路比单纯依赖密码强度或双因素认证更往前迈了一步，因为你开始掌握攻击者的行为数据，而不仅仅是被动地抵挡攻击。