1. 项目概述为什么我们今天还要禁用23端口如果你在管理一台暴露在公网或者处于不那么“纯洁”的内网环境中的Linux服务器那么“禁用23端口”这个操作可能比你定期更新密码还要基础但往往更容易被忽略。23端口这个几乎与Telnet协议划等号的古老端口在今天看来其存在的风险远大于它那点微乎其微的便利性。我见过太多因为一个默认开启的Telnet服务导致整个服务器被当成“肉鸡”的案例。这不仅仅是关闭一个服务那么简单它背后涉及的是对最小权限原则的践行、对攻击面的主动收缩以及对整个系统安全基线的加固。简单来说这个项目的核心就是彻底关闭Linux系统上监听23端口的Telnet服务并确保其不会随系统重启而恢复同时用更安全的替代方案如SSH来满足远程管理需求。它适合所有Linux系统管理员、运维工程师、安全爱好者甚至是任何一位希望自己云服务器更安全的个人开发者。无论你是刚接触Linux的新手还是经验丰富的老兵重新审视并处理23端口都是一次有价值的安全实践。接下来我会带你从原理到实操完整走一遍禁用23端口的流程并分享一些只有踩过坑才知道的细节。2. 核心原理与风险剖析Telnet为何成为“弃子”在动手之前我们必须搞清楚“为什么”。盲目操作不如不操作。Telnet设计于互联网的“田园时代”其最大的原罪在于所有通信内容包括用户名和密码都以明文形式在网络中传输。这意味着任何一个能够截获你数据包的人比如在同一局域网内的攻击者或者不安全的公共Wi-Fi都可以像看报纸一样看到你的登录凭证。2.1 Telnet与SSH的本质区别我们可以用一个简单的类比来理解Telnet就像你通过明信片寄送银行账号和密码邮递路上的任何人都能看见而SSHSecure Shell默认端口22则像是把这些信息装进一个只有你和收件人才有钥匙的坚固保险箱里再寄送即使被截获对方也束手无策。SSH使用了非对称加密、对称加密和哈希算法等多种技术确保了认证、通信的完整性和机密性。2.2 23端口开启的潜在风险凭证窃取这是最直接的风险。攻击者使用抓包工具如Wireshark、tcpdump可以轻易还原出Telnet会话中的所有击键。中间人攻击Man-in-the-Middle, MITM攻击者可以介入你的Telnet会话不仅窃听还可能篡改你执行的命令或服务器返回的结果。暴力破解Telnet服务本身可能存在的漏洞或者结合弱密码会成为自动化攻击脚本的首要目标。23端口的存在就像在门口挂了一个“欢迎尝试”的牌子。扩大攻击面任何不必要的开放端口都是潜在的攻击入口。关闭它就相当于给房子的墙上少留了一扇窗。注意有些老旧设备、工业控制系统或特定网络设备可能仍依赖Telnet。但在通用Linux服务器领域SSH已是绝对标准。我们的目标是在通用Linux服务器上禁用它。2.3 检查23端口状态在动手禁用前先确认它是否真的开启了。最常用的命令是netstat和ss。# 使用 netstat 命令查看 sudo netstat -tlnp | grep :23 # 使用更现代的 ss 命令查看 sudo ss -tlnp | grep :23如果看到类似下面的输出说明23端口正在被监听且通常关联着telnet或inetd/xinetd进程。tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 1234/telnet或者tcp 0 0 :::23 :::* LISTEN 567/xinetd3. 禁用23端口的完整操作指南禁用端口本质上是停止并禁用监听该端口的服务。根据你的Linux发行版和系统初始化方式Systemd 或 SysVinit操作略有不同。我们分情况讨论。3.1 情况一使用Systemd的系统CentOS 7/RHEL 7/Ubuntu 16.04等现代主流发行版基本都使用Systemd。首先需要确定提供Telnet服务的具体单元unit名称。步骤1查找服务名# 方法1通过端口反查服务 sudo systemctl list-units --typeservice | grep telnet # 方法2查看所有服务状态 sudo systemctl list-unit-files | grep telnet常见的Telnet服务名可能是telnet.socket,telnet.service, 或者由超级守护进程xinetd.service管理。步骤2停止并禁用服务假设服务名是telnet.socket。# 停止当前运行的服务 sudo systemctl stop telnet.socket # 禁止服务开机自启 sudo systemctl disable telnet.socket # 同时如果存在对应的 telnet.service也一并处理 sudo systemctl stop telnet.service sudo systemctl disable telnet.service步骤3验证服务状态sudo systemctl status telnet.socket你应该看到类似Active: inactive (dead)和Loaded: masked (disabled)的提示表示已成功禁用。3.2 情况二使用SysVinit的系统较老的CentOS/RHEL 6 Debian 7等在这些系统上通常使用chkconfig和service命令。步骤1检查Telnet服务运行级别chkconfig --list | grep telnet步骤2关闭服务# 立即停止服务 sudo service telnet stop # 或者 sudo /etc/init.d/telnet stop # 禁止在所有运行级别下自启 sudo chkconfig telnet off步骤3确认关闭再次运行chkconfig --list | grep telnet所有运行级别下的状态都应为“off”。3.3 情况三由xinetd超级守护进程管理的Telnet这是一种传统模式Telnet服务并非独立守护进程而是由xinetd按需启动。常见于为兼容性而安装Telnet的场景。步骤1定位配置文件Telnet的xinetd配置通常位于/etc/xinetd.d/目录下文件名为telnet。ls -la /etc/xinetd.d/telnet步骤2禁用服务编辑该配置文件将disable参数的值改为yes。sudo vi /etc/xinetd.d/telnet找到类似下面的行disable no将其修改为disable yes步骤3重启xinetd服务使配置生效sudo systemctl restart xinetd # Systemd系统 # 或 sudo service xinetd restart # SysVinit系统3.4 终极验证与防火墙加固完成上述步骤后必须进行最终验证。验证1检查端口监听状态再次运行sudo ss -tlnp | grep :23或sudo netstat -tlnp | grep :23。此时应该没有任何输出证明23端口已关闭。验证2从外部测试从网络内的另一台机器使用telnet或nc(netcat) 命令测试telnet 你的服务器IP 23或者nc -zv 你的服务器IP 23连接应该失败提示“Connection refused”或超时。防火墙加固强烈建议 即使服务停了配置防火墙拒绝23端口的入站请求是另一道安全屏障。使用firewalld (CentOS/RHEL):sudo firewall-cmd --permanent --remove-servicetelnet # 移除telnet服务规则 sudo firewall-cmd --permanent --add-port23/tcp # 更直接拒绝23端口 sudo firewall-cmd --reload使用iptables (通用):sudo iptables -A INPUT -p tcp --dport 23 -j DROP sudo iptables -A INPUT -p udp --dport 23 -j DROP # 记得保存iptables规则具体命令取决于发行版如 iptables-save /etc/sysconfig/iptables使用UFW (Ubuntu/Debian):sudo ufw deny 23/tcp sudo ufw deny 23/udp4. 替代方案安全远程管理的唯一选择——SSH禁用Telnet后我们唯一的远程管理通道就是SSH。但仅仅使用SSH还不够必须安全地配置它。4.1 基础安全配置/etc/ssh/sshd_config编辑SSH服务端配置文件应用以下关键设置sudo vi /etc/ssh/sshd_config修改默认端口将#Port 22改为Port 你的自定义端口号如 2345。这能减少自动化脚本的扫描骚扰。禁止root直接登录将#PermitRootLogin yes改为PermitRootLogin no。强制使用普通用户登录后再su或sudo。使用密钥认证禁用密码认证PasswordAuthentication no PubkeyAuthentication yes这是提升安全性的最关键一步。你需要先在客户端生成SSH密钥对并将公钥上传到服务器的~/.ssh/authorized_keys文件中。限制用户和IPAllowUsers 你的用户名指定IP # 或 AllowGroups ssh-users DenyUsers 可疑用户名启用失败锁定如果系统支持PAM可以配置pam_tally2或faillock模块在多次密码尝试失败后锁定账户。修改后务必重启SSH服务sudo systemctl restart sshd # 或 ssh取决于发行版重启前请确保你已配置好密钥认证并打开了另一个活动连接否则可能导致自己无法登录4.2 SSH密钥对生成与部署实操在客户端你的电脑生成密钥ssh-keygen -t ed25519 -C “your_emailexample.com” # 推荐ed25519算法更安全更快 # 或使用传统的RSA算法ssh-keygen -t rsa -b 4096 -C “your_emailexample.com”一路回车会在~/.ssh/目录下生成id_ed25519私钥和id_ed25519.pub公钥。将公钥上传到服务器ssh-copy-id -p 你的SSH端口 -i ~/.ssh/id_ed25519.pub 你的用户名服务器IP如果ssh-copy-id不可用可以手动将公钥内容复制到服务器的~/.ssh/authorized_keys文件末尾并确保该文件和目录的权限正确chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys4.3 使用Fail2ban防御暴力破解即使改了端口、用了密钥SSH端口仍会遭受扫描和暴力破解尝试。Fail2ban可以监控日志将多次失败尝试的IP地址临时加入防火墙黑名单。安装与配置# Ubuntu/Debian sudo apt-get install fail2ban # CentOS/RHEL sudo yum install epel-release sudo yum install fail2ban创建本地配置文件覆盖默认设置sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo vi /etc/fail2ban/jail.local找到[sshd]段落进行如下调整假设你的SSH端口是2345[sshd] enabled true port 2345 # 改为你的SSH端口 filter sshd logpath /var/log/auth.log # Ubuntu/Debian # logpath /var/log/secure # CentOS/RHEL maxretry 5 # 最大尝试次数 bantime 3600 # 禁止时间秒 findtime 600 # 在10分钟内统计失败次数启动并启用Fail2bansudo systemctl start fail2ban sudo systemctl enable fail2ban你可以通过sudo fail2ban-client status sshd查看当前被禁止的IP。5. 深度排查与疑难问题解决实录在实际操作中你可能会遇到一些意料之外的情况。这里记录了几个我亲身经历或常见的问题。5.1 问题一禁用服务后端口依然显示监听现象执行了systemctl stop和disable但ss -tlnp仍显示23端口被某个进程监听。排查思路确认进程PID和名称ss -tlnp或netstat -tlnp会显示进程PID和名称。仔细看是哪个进程。检查是否被其他服务占用可能是其他非Telnet服务意外绑定了23端口。用sudo lsof -i :23查看详细信息。检查是否由inetd/xinetd管理如果进程名是xinetd或inetd你需要按照上文“情况三”去修改/etc/xinetd.d/下的配置。检查是否有Docker容器运行sudo docker ps并检查是否有容器映射了主机的23端口。如果有需要进入容器内部修改或停止该容器服务。检查是否有残留进程用kill -9 PID强制杀死该进程再观察端口是否释放。但这只是临时措施需找到根本原因。我的踩坑记录有一次在客户服务器上发现23端口被一个名为remote_shell的自定义进程监听。查了半天发现是一个多年前部署的遗留监控脚本其守护进程配置错误绑定到了23端口。最终通过清理该脚本的启动项解决了问题。5.2 问题二禁用Telnet后某些老旧设备或脚本无法连接现象内网某台网络交换机或老式打印机只能通过Telnet管理禁用后无法配置。解决方案局部放行不推荐如果必须使用可以在防火墙上设置严格的访问控制规则只允许特定管理IP访问服务器的23端口。绝对不要在公网IP上开放。# 例如使用iptables只允许192.168.1.100访问 sudo iptables -A INPUT -p tcp -s 192.168.1.100 --dport 23 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 23 -j DROP使用SSH隧道推荐在能连接该老旧设备的管理机上建立一条SSH隧道将本地一个端口“转发”到老旧设备的23端口。# 在管理机能SSH到服务器也能Telnet到设备上执行 ssh -L 2323:老旧设备IP:23 用户名你的服务器IP -p 你的SSH端口执行后在管理机上telnet localhost 2323流量就会通过加密的SSH通道转发到老旧设备的23端口。既满足了设备需求又保证了传输安全。彻底升级推动更换支持SSH或更安全管理协议的新设备这是治本之策。5.3 问题三如何彻底卸载Telnet客户端与服务端软件如果你确定永远不再需要Telnet为了极致的安全和系统简洁可以将其卸载。查找已安装的Telnet包# RPM系CentOS/RHEL/Fedora rpm -qa | grep -i telnet # DEB系Ubuntu/Debian dpkg -l | grep -i telnet卸载# CentOS/RHEL sudo yum remove telnet telnet-server xinetd # Ubuntu/Debian sudo apt-get remove --purge telnet telnetd inetutils-telnetd xinetd--purge选项会同时删除配置文件。卸载后建议再次执行ss -tlnp | grep :23确认。重要心得在卸载任何系统自带服务前尤其是在生产环境最好先将其禁用并观察一段时间确认没有任何依赖或报错后再卸载。直接卸载有时会带来意想不到的依赖问题。6. 自动化与持续安全将安全基线脚本化对于需要管理大量服务器的运维人员来说手动在每台机器上操作是不现实的。我们需要将“禁用23端口”和“加固SSH”这样的安全基线操作脚本化。6.1 使用Ansible剧本批量禁用23端口下面是一个简单的Ansible剧本示例针对使用Systemd的CentOS/Ubuntu系统--- - name: Harden Linux servers - Disable Telnet port 23 hosts: all become: yes tasks: - name: Check if telnet.socket is active systemd: name: telnet.socket state: stopped enabled: no ignore_errors: yes # 如果服务不存在忽略错误 - name: Check if telnet.service is active systemd: name: telnet.service state: stopped enabled: no ignore_errors: yes - name: Check for xinetd managed telnet block: - name: Disable telnet in xinetd lineinfile: path: /etc/xinetd.d/telnet regexp: ^disable\s* line: disable yes state: present register: xinetd_conf_changed when: telnet in xinetd_d_files.stdout - name: Restart xinetd if config changed systemd: name: xinetd state: restarted when: xinetd_conf_changed.changed when: xinetd_d_files.stdout is defined vars: xinetd_d_files: “{{ lookup(‘fileglob’, ‘/etc/xinetd.d/*’) }}” - name: Ensure port 23 is not listening (immediate kill) shell: “ss -tlpn | grep ‘:23 ‘ | awk ‘{print $7}’ | cut -d’’ -f2 | xargs -r kill -9” changed_when: false failed_when: false - name: Deny port 23 via firewalld (if used) firewalld: port: 23/tcp permanent: yes state: disabled when: “‘firewalld’ in ansible_facts.services” - name: Deny port 23 via iptables (fallback) iptables: chain: INPUT protocol: tcp destination_port: 23 jump: DROP comment: “Disable insecure telnet port” when: “‘firewalld’ not in ansible_facts.services”这个剧本会尝试多种方法确保23端口被关闭。你可以将其保存为disable_telnet.yml并运行ansible-playbook -i inventory.ini disable_telnet.yml。6.2 配置安全扫描与定期审计安全不是一劳永逸的。你需要定期检查是否有服务重新监听在了23端口。使用Nmap进行自我扫描sudo nmap -sS -p 23 你的服务器IP定期例如每周运行此命令或将其加入监控系统如果发现23端口状态从closed变为open立即告警。配置auditd审计规则对于安全要求极高的环境可以配置Linux审计系统auditd记录任何尝试绑定23端口的行为。sudo auditctl -a always,exit -F archb64 -S bind -F a023 -k telnet_port_bind这条规则会监控所有尝试绑定23端口的系统调用并记录日志。集中式日志分析将系统的/var/log/secure(auth.log)、防火墙日志等集中到SIEM安全信息与事件管理系统或ELK栈中设置规则当出现与“23端口”、“telnet”相关的连接尝试或服务启动日志时触发告警。禁用23端口这个看似微小的动作是构建服务器安全防线的第一块坚实砖石。它代表了一种安全态度主动减少不必要的暴露遵循最小权限原则。结合强化的SSH配置、 Fail2ban防护以及定期的安全审计你就能为你的Linux服务器建立起一道应对自动化攻击和初级黑客的有效屏障。记住安全是一个持续的过程而非一次性的任务。从关闭这个古老的端口开始逐步完善你的每一层防护。