新闻组协议的加密端口
563 对应 nntps，早期注册名叫 snntp，规范是 RFC 4642，指的是把新闻组协议放进传输层加密之中。明文版本使用 119，加密版本则在会话建立时就直接协商加密，因此客户端配置时需要区分两者。新闻组服务在企业内部仍用于技术讨论与公告分发，公网服务商也普遍提供加密读取端口。
基本信息
| 服务 | nntps（加密的新闻组协议） |
|---|---|
| 协议 | TCP 563（明文版本为 119） |
| 规范 | RFC 4642 |
| 登记属主 | 互联网工程指导组 |
| 相关机制 | 另有一种在明文端口上升级加密的协商方式 |
典型使用场景
- 内部技术讨论：以新闻组形式分发公告与邮件列表镜像
- 客户端配置：为阅读器选择加密端口与认证方式
- 排障：能连上但无法认证时先确认端口与加密方式的组合
- 安全核对：确认是否仍在使用明文端口传输凭据
- 迁移规划：把明文读取切换到加密端口
端口与加密方式
| 端口 | 加密方式 | 客户端配置要点 |
|---|---|---|
| 119 | 明文 | 凭据在链路上暴露 |
| 563 | 会话建立即加密 | 需在客户端选择加密连接 |
| 119 加升级协商 | 先明文后升级 | 取决于服务端支持情况 |
连通与核对
连通与核对
# 查看服务端监听情况
ss -lntp | grep -E ':119 |:563 '
# 加密端口连通性验证
nc -zv news.example.com 563
# 使用加密方式发起会话做人工确认
openssl s_client -connect news.example.com:563 -quiet
# 查看服务端配置中的加密相关项
grep -n -i -E 'ssl|tls' /etc/news/inn.conf 2>/dev/null两种加密路径不能混用：直接加密端口与在明文端口上协商升级是不同配置，客户端与服务端必须匹配。排障时先确认双方选择的路径，再去怀疑凭据或权限问题。
明文端口会传输账号与口令：若服务器同时开着 119 与 563，攻击者可以直接走明文端口绕过加密要求。加固时应明确是否允许明文端口存在，而不是只在客户端侧做要求。
加固要点
- 明确是否保留明文端口，必要时只留加密端口
- 为读取与投递分别设置权限，避免共用高权限账号
- 把认证失败次数纳入监控，便于发现暴力尝试
- 定期核对服务端配置与实际监听是否一致