SSH 与 FTP 密码爆破防护

阻止针对您 Linux 服务器 的 SSH 暴力破解

SSH Protector 是一个轻量的 Linux 代理,用于阻止 SSH、SFTP 和 FTP 的暴力破解。它读取主机自身的认证日志(journald 或 auth.log),当攻击者持续失败时,用一条 nftables 规则封禁其整个 /24 子网,并且重启后依然有效。判断在服务器本机完成,因此即使与面板失联,防护仍在运行。安装只需几分钟,无需任何配置。

一条命令安装
curl -fsSL https://sshprotector.com/download/installer | sudo sh

免费版包含对一台服务器的完整保护。

一个代理支持所有 Linux 发行版

Debian · Ubuntu · FedoraRHEL · Alma · Rocky · Alpinex64 · x86 · ARM64CPU 占用几乎为零
00

安装代理

所有人使用同一个二进制文件,下载无需账户。可以先安装,之后再随时连接服务器 -- 代理会要求填写面板中的注册令牌,在此之前不会保护任何内容。

下载安装脚本

支持任意基于 systemd 的现代 Linux -- Debian、Ubuntu、RHEL/CentOS/Alma/Rocky、Fedora -- x86-64 或 ARM64。脚本安装的是同一个服务,更适合批量部署。

01为什么

开放的 SSH 端口全天候遭受攻击

僵尸网络会扫描整个互联网地址空间,对每一台可达的服务器尝试密码--无论是企业服务器还是一台普通 VPS。

每天数千次登录尝试
服务器上线几小时后就会开始收到来自世界各地的登录尝试。一台暴露 SSH 端口的普通服务器每天会记录数千次失败登录。
服务器资源被白白消耗
每次登录尝试都要消耗 CPU 时间、内存、事件日志写入和网络流量。持续不断的爆破请求形成常驻后台负载,拖慢服务器并让日志迅速膨胀。
猜中一个密码就会被入侵
只要猜中一次就能完全控制这台机器:勒索软件、数据被盗、用您的地址发送垃圾邮件。弱密码和重复使用的密码几天内就会被字典攻破。
攻击者可以锁定你的管理员账户
Linux(通过 PAM faillock)在多次登录失败后会锁定账户。攻击者只要猜中一个有效的用户名,就能触发该阈值并把真正的管理员锁在门外--即便从未猜出密码,也构成拒绝服务攻击。

SSH Protector 在防火墙层面切断攻击

代理发现连续的失败登录后,用一条 nftables 规则封禁攻击者的整个子网。被封禁的数据包在系统消耗任何资源之前就被丢弃:CPU 负载和日志噪音下降,服务器运行更快,机器人永远凑不够猜中密码所需的尝试次数。

02如何阻止

在 Linux 上阻止 SSH 暴力破解的三种方法

三项改动能真正减少到达 sshd 的流量。它们可以叠加,建议按这个顺序做。

  1. 01用密钥登录,而不是密码

    一旦 sshd 不再接受密码,猜解就无从下手。先把公钥放上去,再用第二个会话确认能用密钥登录,最后才关闭密码认证——顺序不能反,否则一个笔误就会把你关在门外。

    # /etc/ssh/sshd_config.d/10-keys-only.conf
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    PermitRootLogin prohibit-password
    完整指南
  2. 02缩小互联网能触达该端口的范围

    把 sshd 从 22 端口挪走能去掉绝大部分无差别扫描,除此之外不提供任何防护。把端口限制到 VPN 或已知地址列表,去掉的是攻击者本身而不只是噪声;如果服务器的管理员是固定的几个人,两件事都做。

    # /etc/ssh/sshd_config.d/20-exposure.conf
    Port 2202
    AllowGroups ssh-admins
    
    # nftables: only the VPN and the office reach it at all
    nft add rule inet filter input tcp dport 2202 \
      ip saddr { 10.8.0.0/24, 203.0.113.7 } accept
    完整指南
  3. 03在对方试够次数之前封禁来源

    fail2ban 是正确的第一步:它读认证日志、统计失败次数,并临时封禁地址。它的边界是结构性的——一次只封一个地址、状态会过期、主机之间不共享、日志格式一变 jail 可能悄悄失配。SSH Protector 用一条 nftables 规则封禁攻击者整个 /24 子网,重启后封禁仍然有效,并把一台受保护服务器学到的东西共享给其他服务器。

    # /etc/fail2ban/jail.d/sshd.local
    [sshd]
    enabled  = true
    backend  = systemd
    maxretry = 4
    findtime = 10m
    bantime  = 1h
    完整指南

一条子网规则能覆盖什么

拖动滑块。这是算术,不是跑分。

逐个地址封禁

32 条防火墙规则

128 次尝试仍然到达 sshd

封禁整个 /24

1 条防火墙规则

4 次尝试仍然到达 sshd

一个 /24 有 256 个地址。按地址封禁时,机器人每换一个地址就重新获得一次配额;封禁覆盖整个网段时,一次都没有。这里没有任何测量数据,这就是代理所做的同一套计数。

03工作原理

从下载到服务器受保护只需几分钟

没有配置文件,也不用命令行:下载安装程序,运行并确认 sudo 提示即可。

  1. 创建账户

    使用邮箱或通过 Google/GitHub 注册,无需银行卡。

  2. 下载安装程序

    您会获得一个已内嵌访问令牌的个人签名安装程序。

  3. 在服务器上运行

    代理会自动识别 SSH 端口,并把您当前的 IP 加入白名单,避免把自己锁在门外。

  4. 完成

    几秒钟后服务器就会在面板中显示为在线,并以合理的默认设置开始拦截攻击者。

04功能

保护和管理服务器所需的一切

以防爆破为核心,辅以共享攻击者情报、地区规则、临时访问和集中管理。

SSH 与 FTP 防爆破01

代理读取 systemd 日志(journald)和 FTP 服务器日志中的失败登录,并在本地即时封禁攻击者--即使与云端断开连接也能工作。

封禁整个子网,而非单个地址02

攻击者会在自己的网络内轮换地址。SSH Protector 根据 ASN 数据封禁整个子网,只用一条合并的防火墙规则。

共享攻击者数据库03

对一个客户的攻击会保护所有人:子网信誉在整个平台汇总,最恶劣的网络在到达您之前就已被封禁。

地区规则04

只允许来自您实际工作所在国家的 SSH 连接。全部在代理本地判定,速度快且离线可用。

临时访问05

默认保持端口关闭,在通过 MFA 确认后为特定地址临时开放,带计时器并自动关闭。

白名单与严格模式06

受信任的地址和动态 DNS 名称永远不会被封禁。严格模式下,只有白名单中的来源才能访问端口。

通知与审计07

封禁激增、服务器离线、配置变更--通过邮件、Telegram、Slack 或 Webhook 通知。所有操作都记录在审计日志中。

一个轻量级代理08

一个以服务形式运行的小巧可执行文件。仅占用几 MB 内存,CPU 占用几乎为零,支持所有主流 Linux 发行版和架构。

集中管理09

服务器列表、策略、版本回滚、分组和批量操作--全部在面板中完成,服务器上无需开放任何入站端口。

Always-On 锁定保护10

确保暴力破解下账户永远不会被锁定:代理会在达到 PAM faillock 锁定阈值之前封禁攻击者,并自动解锁受保护的账户(管理员 + 你的名单)。所有套餐默认开启。

05价格

固定套餐价格,不按服务器加价

Free 永久免费,无需银行卡。付费套餐价格固定,包含明确数量的服务器。

Free

1 台服务器
$0/月

单台服务器的基础 SSH 防护。

  • SSH 防爆破
  • 宽松白名单
  • 基础统计

Solo

1 台服务器
$9/月

一台生产服务器的完整防护。

  • 包含 Free 全部功能
  • FTP 防爆破
  • 完整统计
  • 邮件通知
  • 基础审计

Pro

热门最多 5 台服务器
$15/月

适合团队和小型服务器集群。

  • 包含 Solo 全部功能
  • 严格白名单与分组
  • 完整审计与导出
  • 扩展统计
  • 共享行为封禁列表

Enterprise

最多 50 台服务器
$99/月

适合拥有大量服务器的企业。

  • 包含 Pro 全部功能
  • 管理员与协管员角色
  • 优先支持
  • 共享行为封禁列表

需要比套餐多一台服务器?按台加购即可,每台 $3/月,无需升级套餐。

14 天 Pro 免费 -- 无需银行卡

注册后即可在自己的服务器上试用子网封禁、Telegram 通知、GeoIP 和共享威胁库。试用结束后账户会自动回到 Free,防护继续运行。不会扣款,也无需取消。

开始免费试用
06适用场景

何时真正需要保护一台 Linux 服务器

十五种情形:在这些情形下,对 Linux 机器的远程访问不再是理论上的风险,而是每天都在发生的风险。如果其中任何一种与您的服务器相符,它的密码已经在被人试探了。

0.0.0.0/022 · 21LISTEN 0.0.0.0$sshduptime 412dno consoleone host · always on

何时必须保护 Linux 上的 SSH 服务器

第一组关乎机器本身:它放在哪里、谁能够到它、上面还有什么在监听。这些情形没有一种属于失误。它们都是运维 Linux 服务器的寻常而合理的方式,而每一种都把一个密码提示摆在了整个互联网面前。

  1. 01

    SSH 从任何地方都能连上,而且密码登录仍然可用

    22 端口回应世界上的每一个地址,前面既没有 VPN,也没有堡垒机。对租来的机器而言这就是默认状态:服务商交付一个公网地址,服务器恰恰是通过 SSH 配置的,配置完成之后端口就那样留在原处--而且多半在密钥之外仍然开着密码认证。

    扫完整个 IPv4 段是几分钟的事,不是几天。一个刚分配的地址,在上线后数小时内就会开始收到连接尝试,那时服务器还没有名字、没有证书,也没有一个真实用户。从那一刻起,这台机器就在昼夜不停地回应陌生人。

    • 以公网地址可达的 VPS 或云主机
    • 位于路由器之后、被映射了 22 端口的办公机器
    • 为一次迁移“临时”打开、之后再没关上的服务器
    • 地址从未对外公布,却仍然落在被扫描网段里的机器
  2. 02

    云镜像自带一个人人都已知道的用户名

    发行版和服务商的镜像都带着一个众所周知的首个账户:裸 VPS 上的 root、Ubuntu 上的 ubuntu,以及 ec2-user、debian、admin、pi。猜解工作的一半--找到一个有效用户名--在机器完成首次启动之前就已经解决了。

    这正是一台暴露的服务器整天在日志里看到同一份简短名单的原因。攻击者不需要摸索什么:这个账户是标准的,它存在于互联网上相当大比例的 Linux 主机上,而在其中许多主机上,它至今仍可直接用来登录。

  3. 03

    一台租来的 VPS 同时扛着网站、数据库和备份

    小公司和单人项目常把所有东西塞进一台机器:Web 服务、数据库、队列、夜间导出。没有第二台可以切换的主机,也没有专职管理员--登录去发布的人,就是维护它的人。

    服务商的防护到不了这一层。主机商过滤的是流量洪水,而不是密码猜解:来自不断变换地址的每秒几次尝试,从网络的角度看就是普通流量,滥用处理部门永远不会看到它们。

    • 没有余量:一旦被攻陷,项目不是变慢,而是停摆
    • 备份往往就在同一块磁盘上--勒索软件正是指望这一点
    • 没人拿钱去读 auth.log,于是尝试记录无声地堆积
  4. 04

    这台 Linux 是路由器、NAS 或某个没人当成服务器的设备

    一台防火墙设备、一台网络存储、一块跑着店铺收银软件的树莓派、机房里的一个控制器、桌子底下负责备份的迷你主机--它们全都是 Linux,全都开着 SSH,而且全都不在任何人的服务器清单上。

    被遗忘的恰恰是这类机器。它们只被配置过一次,之后一直在跑,从选定密码那天到再次有人去看它们那天,中间隔着好几年。而在这段时间里,端口一直在回应互联网。

  5. 05

    FTP 与 SSH 监听在同一台主机上

    Linux 服务器很少只发布一个服务。用于与客户或设计师交换文件的 FTP,加上用于管理的 SSH,通常同居在同一个地址上;而 FTP 账户往往比这台机器上的其他一切都要古老。

    每一个开放端口都是一扇独立的门,各有各的登录提示,而攻击者并不分工。同一套扫描设施会把两扇门挨个试过去,决定整台主机命运的是较弱的那一扇,因为从任何一扇进来的人,站的都是同一个操作系统。

    • 为某个外包方开过一次、此后再没复核的 FTP 账户
    • 普通 FTP 让凭据以明文在网络上传输
    • 半个办公室都知道密码的共享上传账户
users triedrootadminubuntudeploypostgrestestpassword:PasswordAuthentication yesfailed9 999

当账户和密钥不再受控时

第二组关乎谁手里握着这台机器的凭据。密钥、部署账户、外包方和旧密码累积的速度,快过任何人复核它们的速度,而它们最终都通向同一个提示符。大多数真实的入侵,正是从这里开始的。

  1. 06

    开发者和外包方各自持有登录方式

    外包开发者、需要上传构建包的设计师、维护网站的代理商、行业应用的供应商--每一方都要过访问权限,每一方都拿到了账户,或者往 authorized_keys 里加了一把密钥,而其中大部分在项目结束多年之后依然有效。

    这些凭据被如何保管,您看不到。一把私钥可能未加密地躺在笔记本电脑里,可能在共享的云盘目录中,也可能在一位一年前就已离职的员工的主目录里。一次授予的访问权限,通常比项目活得久,也比当初被授予的那个人活得久。

    • 为一次部署而添加、事后从未移除的密钥
    • 外包方全员共用一个账户,而不是一人一个
    • 外包方换人时,没有任何人会通知您
  2. 07

    部署和自动化账户无法使用第二因素

    CI 流水线、备份脚本、监控代理、rsync 任务和配置管理工具,都必须在无人在场的情况下登录。因此,任何需要向人索要验证码的机制都保护不了它们--而它们的权限通常比任何一个人都宽。

    于是这些账户就那样留着:可预测的名字、多年未轮换的密钥或密码,以及一条凌晨三点照样畅通、无人察觉的登录路径。攻击者瞄准的正是它们--恰恰因为它们从不改变。

  3. 08

    密码认证被“以防万一”地留着

    密钥登录已经配好,密码则作为后备继续开着--为了万一丢了密钥的那天,为了没有密钥的同事,为了一年没人试过的那个控制台。出发点是合理的;效果却是:整套密钥策略从攻击者一侧看是可选的。

    猜解并不在乎密钥是否存在。只要机器上还有任何一个账户的 PasswordAuthentication 为 yes,字典攻击就有入口,而服务器上最强的密钥一秒钟也拖不住它。

  4. 09

    这个密码早已出现在泄露库里

    大多数得手的入侵毫不高明。有人把论坛、商店或旧邮箱的密码重复使用了,而那些站点后来发生了泄露,同一串字符如今就躺在每个扫描机器人都会跑一遍的字典里。

    于是猜解不再是概率问题,而是排期问题:正确的密码已经在名单上,唯一的悬念是机器人什么时候轮到您的地址。复杂度规则在这里帮不上忙,因为这样的密码完全可能满足您写下的每一条规则。

    • 服务器账户与个人服务用了同一个密码
    • 从外包方系统而非贵方系统泄露出去的凭据
    • 策略放行、字典早已收录的套路--Summer2024!、公司名1
  5. 10

    某个人的笔记本里存着一把没有口令的私钥

    密钥比密码更强,这一点一直成立,直到密钥文件被复制的那一刻为止。被盗笔记本里未加密的 id_rsa、同步中的云盘目录、推送到公共镜像仓库的容器镜像、误提交进代码仓库的文件--每一种都是一份根本不需要猜的、可直接使用的凭据。

    服务器分辨不出差别。签名有效,账户真实,会话看上去和那位开发者的一模一样。所以有用的问题不只是谁持有密钥,还包括:当有人从那位开发者从未去过的地方连进来时,会发生什么。

/var/log/auth.log22:0023:0124:0225:0326:0427:0528:0629:07this month12 480blockedexported · signed

当日志、审计人员或服务商把问题摆上台面

第三组关乎在任何入侵发生之前就已到来的后果。那些从未得手的尝试,照样消耗磁盘、CPU、注意力和信誉。而迟早会有技术团队之外的人提出一个问题,需要用证据而不是保证来回答。

  1. 11

    审计人员、保险公司或客户询问远程访问是如何防护的

    网络安全保险的投保问卷、企业客户的安全问询、以及涉及支付数据和个人数据的监管要求,都在用不同措辞问同一件事:是什么在阻止针对您远程访问的反复密码猜解,您又凭什么知道它在起作用。

    “我们用密钥”经不起追问,因为追问会落在那些仍然接受密码的账户上,以及那些无论如何都能抵达端口的尝试上。对方要的是一项独立于任何具体凭据而存在的控制措施,以及一份能证明它在整个受审期间持续生效的记录。

    • 签发或续保之前的网络安全保险问卷
    • 签约之前大客户所做的供应商安全审查
    • 要求对远程访问设置暴力破解防护的支付或个人数据规范
  2. 12

    auth.log 和磁盘被登录失败塞满

    每一次被拒绝的尝试都会被记下来。在一台暴露的服务器上,这意味着每天数以万计的日志行,而且影响会叠加:轮转会在几小时内丢掉真实事件,日志外发按摄入量计费,而一个小小的根分区确实可能因为那些本来就不会被放进来的流量而被撑满。

    代价不止是存储。每次尝试都要一条 TCP 连接、一次密钥交换和一次凭据校验,因此这台机器每天都要拿出可测量的一部分算力,去应付它永远不会放进来的人。在单核 VPS 上,这个比例大到足以让服务器真正该干的活感觉出来。

  3. 13

    手工维护的封禁列表本身成了一项运维负担

    通常的第一反应是一个本地过滤器,外加一堆越来越大的防火墙规则。它管用一阵子--然后规则集变成几千行,一半的条目没人记得为什么在那里,某个繁忙的早晨自家分支机构被拦在了外面,而每装一台新机器,同样的地址段都要从头再摸一遍。

    一批机器真正需要的,是一次决定、处处适用的策略,是被记录下来而不是被记在脑子里的例外,以及不必在每次重装服务器后手工重建的封禁。

  4. 14

    一位管理员照看着许多客户的服务器

    托管服务商、自由系统管理员和小型主机公司,手里握着分布在不同客户、不同服务商、不同网络结构中的数十台 Linux 机器。每一台都有自己的规则、自己的账户,以及自己能承受多少停机。

    一台台手工配置扩展不了,等客户打电话来才发现问题同样扩展不了。这样的机器群需要的是一套到处适用的统一基线、在客户确实特殊之处按机器设置的例外,以及一个能一眼看全的地方。

    • 机器散布在多个服务商和多个地址段中
    • 某个客户的站点无论看起来多反常都绝不能被拦
    • 管理员之间交接时,不丢失某项设置背后的理由
  5. 15

    到服务器的链路并不可靠,而防护仍须成立

    链路会断,运营商会改路由,DNS 会出问题,远端机架上的机器可能几个小时都没有出网路由。攻击不会因此暂停;恰恰相反,网络故障正是服务器最无人注视的时刻。

    因此,守住登录的东西必须在本机就地作出判断,不依赖能否连上外部服务。凡是断网就停止生效的防护,只在您本来不需要它的日子里保护您。

07常见问题

常见问题

安装在生产服务器上安全吗?

安装在生产服务器上安全吗?

安全。代理只读取本机操作系统的安全日志,并封禁指向本机受保护端口的入站连接。它只发起出站 HTTPS 请求,不开放任何入站端口。

没有网络连接时防护还有效吗?

没有网络连接时防护还有效吗?

有效。封禁决策在代理本地做出,即使无法连接云端,防护也会按最后应用的策略继续工作。

如果我改了 SSH 端口怎么办?

如果我改了 SSH 端口怎么办?

代理会通过 sshd_config 和监听套接字自动识别实际的 SSH 端口,端口变化时会自动重建规则。FTP 端口同样自动识别。

我会把自己锁在外面吗?

我会把自己锁在外面吗?

不会。安装时您当前的 IP 地址会自动加入白名单,而白名单来源的优先级始终高于任何封禁。

支持哪些 Linux 发行版?

支持哪些 Linux 发行版?

任何基于 systemd 的现代发行版--Debian、Ubuntu、RHEL/CentOS/Alma/Rocky、Fedora--支持 x86-64 和 ARM64。单个静态可执行文件,无需额外运行时。

如何付款?

如何付款?

国际支付通过 PayPro Global,俄罗斯境内通过 YooKassa,另外支持加密货币。Free 套餐永久有效且无需银行卡。

启用密码验证的 SSH 保护

我启用了密码身份验证,并在 Linux 服务器的公共地址上侦听 SSH。 auth.log 中有数千个来自不同 IP 和登录的失败密码,移动端口 22 没有帮助,并且无法完全阻止访问。如何在成功登录之前设置 SSH 保护以防止密码暴力破解?

使用 SSH Protector,我将代理安装为 systemd 服务:它在本地读取身份验证日志,确定实际的 sshd 端口,并在达到时间窗口阈值后,在系统防火墙中阻止源网络。我提前将我的地址或VPN添加到白名单中,在面板中控制历史记录并在断网时保存最新策略。

免费,无需 SSH Protector 我禁用 PasswordAuthentication 和 PermitRootLogin,将密钥保留给 Ed25519,限制 AllowUsers/AllowGroups 并仅允许来自 VPN 或受信任 CIDR 的端口。如果临时需要密码,我会使用journald/auth.log配置fail2ban,检查nftables/iptables,设置findtime、maxretry和bantime,并定期从备份控制台测试异常。

保护云Linux镜像的标准登录

我从公共云映像部署了 Ubuntu/Debian/RHEL,因此机器人提前知道用户名 ubuntu、debian、ec2-user 或 root。即使密码良好,日志中也会充满有针对性的尝试,一个错误的密码会使帐户容易受到攻击。如何使用标准登录来保护云 VPS 上的 SSH?

使用 SSH Protector,我可以阻止实际登录失败的源,无论它尝试什么名称,并且可以将禁令扩展到攻击者的网络。我检查找到的 SSH 端口,将管理 VPN 添加到白名单,并使用本地代理解决方案,以便保护不依赖于面板可用性。

我免费禁用密码和 root 登录,使用 sudo 创建单独的用户,通过 cloud-init 上传唯一密钥,并关闭 VPN/我的网络的安全组。我删除了未使用的authorized_keys,在堡垒上启用MFA,配置fail2ban和接受未知来源的密码/公钥警报;我考虑改变端口只是为了减少噪音。

使用网站和数据库保护单个 Linux VPS

我有一台 Linux VPS,网站、数据库和备份同时工作,并且需要 SSH 进行管理。以 sudo 用户身份成功登录将使攻击者能够访问所有层,并允许攻击者删除本地备份文件。如何以最小的负载保护关键 VPS 上的 SSH?

使用 SSH Protector,我安装了一个静态代理,该代理读取本地事件并在防火墙中阻止源,直到帐户受到威胁。我使用免费的第一台服务器保护,将我的频道列入白名单,并确保代理继续离线工作;我将备份和最低权限保留为单独的层。

我免费将 SSH 锁定在 WireGuard/Tailscale 后面,禁用密码和 root,需要带有密码的密钥,并限制为 sudo。我使用单独的凭据将备份存储在 VPS 之外,启用自动安全更新、fail2ban 和成功登录审核;在加强防火墙之前我会检查提供商的紧急控制台。

路由器、NAS 和 Linux 设备上的 SSH 保护

我管理一个 Linux 路由器、NAS 或 ARM 设备,我不认为它们是成熟的服务器,但它运行 sshd 并且可以从外部网络访问该端口。该设备很少更新,资源稀缺,妥协将使其在本地网络中立足。如何在低功耗 Linux 设备上保护 SSH 的安全?

通过 SSH Protector,我使用支持的静态二进制文件来实现适当的架构和 systemd,无需传入控制端口即可启用本地日志解析和防火墙阻止。我在安装之前检查操作系统和防火墙兼容性,设置管理白名单,并确保代理不会淹没有限的设备资源。

免费的,我根本不对外发布 SSH:我通过 VPN 连接设备,禁用密码和 root,允许一键和一个控制子网。我更新固件,禁用未使用的服务,仅在有足够内存的情况下设置最小fail2ban并保存防火墙配置;对于不受支持的操作系统,我选择外部网关而不是未知的二进制文件。

Linux 上的统一 SSH 和 FTP 安全

我在 Linux 主机上打开了 SSH 和 FTP,机器人通过不同的日志遍历这两个服务。 sshd脚本封锁的IP继续攻击FTP,手动iptables链发散。如何集中阻止通过 SSH 和 FTP 进行的密码猜测?

借助 SSH Protector,我可以读取受支持的 SSH 和 FTP 日志,让代理确定端口,并将单个本地规则应用于源网络。我将可信集成添加到白名单中,检查仪表板中的历史记录,并考虑到高级 FTP 保护和其他功能可能取决于资费。

如果确实需要该协议,我会免费将常规 FTP 替换为基于 SSH 的 SFTP 或 FTPS,并关闭整个 Internet 的服务。我为 sshd 和 FTP 创建单独的fail2ban 监狱,将它们定向到一个设置了超时的 nftables,在更新后检查日志格式并禁用共享帐户。

控制开发人员和承包商的 SSH 登录

我向开发人员和承包商颁发了单独的 Linux 登录名和 SSH 密钥,但其中一些密钥被复制到个人笔记本电脑上,并且所有者列表已过时。我需要停止暴力破解,快速回忆起一个人并了解谁在不使用一把通用密钥的情况下进入了。如何确保多用户 SSH 访问的安全?

借助 SSH Protector,我对所有外部源保留自动网络阻止,并且仅将受控 VPN 列入白名单,而不是每个家庭 IP。我使用面板进行攻击,但我将身份保存在单独的 Unix 帐户和密钥中:代理保护外围,我通过删除特定密钥来撤销访问权限。

免费地,我通过 Ansible 集中管理authorized_keys,为每个人和设备发放一个密钥并带有明确的注释,禁用共享帐户并限制 sudo。我在堡垒上启用 VPN/MFA,在清单中设置访问期限,在 SIEM 中收集带有指纹的接受公钥,并在合同结束时自动删除密钥。

无需 MFA 即可保护企业 SSH 帐户

我有 CI 和自动化使用的部署/备份帐户,因此交互式 MFA 不适用于它们。他们的密钥应该在没有操作员的情况下工作,但破坏运行者或重复密码可能会打开服务器。如何在不破坏部署的情况下保护计算机 SSH 访问?

借助 SSH Protector,我通过精确的白名单分离受信任的运行者地址,并让所有其他来源因登录失败而被阻止。我不认为这可以替代密钥控制:代理减少了来自外部的暴力,而服务帐户本身的限制包含了成功身份验证的后果。

免费地,我使用单独的 Ed25519 密钥来完成该作业,将其存储在秘密存储中,通过 from=、command=、no-port-forwarding、no-agent-forwarding 和 no-pty 将其限制在authorized_keys 中。我只允许来自运行者网络的 SSH,发出最少的 sudo 命令,定期轮换密钥,并在部署日志中记录指纹。

通过 SSH 安全禁用密码登录

我保留了 SSH 登录密码“以防万一”,因为我担心在更改 sshd_config 后丢失密钥或被锁定。因此,PasswordAuthentication yes 会保留多年,并且 auth.log 会不断显示选择。如何切换到 SSH 密钥而不会有失去服务器访问权限的风险?

使用 SSH Protector,我首先安装额外的保护层,并在执行迁移时将当前管理地址列入白名单。代理会阻止主动暴力破解,自动考虑实际端口并使策略保持离线状态,但在成功验证密钥后,我仍然禁用密码登录。

我免费打开第二个 SSH 会话和提供程序控制台,添加唯一密钥,检查 ~/.ssh 700 和authorized_keys 600 权限,运行 sshd -t 并重新加载,而不关闭第一个会话。然后我设置PasswordAuthentication no,KbdInteractiveAuthentication no和PermitRootLogin no,检查新登录并单独保存紧急密钥。

对泄露 SSH 密码的反应

我发现Linux用户的密码被泄露,auth.log中出现了来自多个国家的尝试使用他的名字的密码。我不确定登录是否成功,因为服务器正在从不同的网络使用。如何紧急关闭 SSH 搜索并检查是否存在泄露?

借助 SSH Protector,我可以立即阻止活动来源和网络,检查攻击历史记录,并仅通过受信任的白名单保留访问权限。然后我更改密码/密钥,结束会话并单独分析接受的密码/公钥;阻止会减少攻击窗口,但并不能证明不存在已成功登录的情况。

我免费暂时关闭了 VPN 的 SSH 安全组或 nftables、阻止用户、撤销密钥并更改关联的机密。我检查last/lastlog、journalctl、sudo、新用户/密钥、cron/systemd 单元、进程和网络连接,然后恢复仅密钥访问并禁用重复使用的密码。

无需密码的 SSH 私钥保护

我在一名员工的笔记本电脑上发现了一个没有密码的 SSH 私钥;该密钥允许在多个服务器上使用,并且可能最终会出现在备份或恶意软件中。这样的登录不会创建一系列不正确的密码,因此常规的反暴力破解不会阻止它。如何限制损害并正确保护 SSH 密钥?

通过 SSH Protector,我可以继续阻止外部暴力破解并查看可疑来源,但不依赖它来对抗正确的被盗密钥。我立即从所有服务器上删除指纹,发出带有密码的新密钥,并只为 VPN 保留白名单;我将单独调查成功的参赛作品。

免费地,我在所有authorized_keys中查找旧的公钥,通过配置管理撤销它,并通过指纹和来源检查接受的公钥。我发出硬件 FIDO2/ed25519-sk 或带有密码和 ssh-agent 超时的密钥,除非必要,否则禁用代理转发,并保留所有者、设备和轮换日期的注册表。

确认 SSH 安全性以进行审核

我必须向审核员、客户或保险公司展示如何保护管理 SSH 访问:控制哪些端口和主机、如何阻止自动选择、谁在白名单中以及当互联网丢失时会发生什么。如何收集 SSH 暴力保护的可验证证据?

通过 SSH Protector,我附上了攻击和阻止历史记录、策略设置、受保护服务列表和批准的例外情况。我记录代理的本地解决方案、传出 TLS 通道以及缺少传入控制端口的情况,然后执行受控的错误登录并保存日志行、防火墙规则和通知。

我免费从 Git 导出 sshd_config、nftables/ufw、fail2banijil 和变更日志,并将 auth.log/journald 发送到安全存储。我每月检查PasswordAuthentication、PermitRootLogin、MFA/VPN 并测试密钥吊销,对结果进行签名并在规定的期限内存储证据。

由于 SSH 暴力破解,auth.log 量减少

我的 auth.log 或日志充满了失败的密码和无效的用户,有用的历史记录由于轮换而丢失,并且日志解析器浪费了资源。我不想禁用审核,因为需要调查成功登录。如何减少 SSH 暴力破解事件的流量?

使用 SSH Protector,我在发生一系列故障后在防火墙中阻止源,因此下一个 TCP 连接不会到达 sshd,也不会创建那么多条目。我保留系统审计,单独控制日志的大小/保留,并使用面板中的攻击历史作为索引,而不是作为原始日志的替代品。

我免费关闭了 VPN/白名单的 SSH,禁用密码和标准登录,并将fail2ban 发送到设置了超时的 nftables。我配置 SystemMaxUse 和 Journald/rsyslog 轮换,将 Accepted 和关键 Failed 事件发送到外部 syslog,并且不将 LogLevel 降低到调查所需的值以下。

Linux 自动化阻止而不是手动黑名单

我手动将 IP 从 auth.log 复制到 ufw/iptables,但地址变化很快,旧规则没有删除,链条不断增长,一个错误就可能关闭我的访问。黑名单支持已成为一项单独的日常任务。如何安全地自动化 SSH 暴力阻止?

使用 SSH Protector,我设置了一次阈值和窗口,之后代理在本地创建和释放锁,并且白名单优先。我使用网络禁令,攻击者轮换相邻地址,检查面板中的更改并在第一个策略之前保存备份控制台。

免费地,我用带有超时或fail2ban操作的nftables替换了单独的永恒iptables规则,为VPN设置了maxretry/findtime/bantime和ignoreip。我在真实的日志行上测试过滤器,仔细启用重复性,限制设置大小,并在发行版更新后监视重新加载错误。

管理多个客户端的 SSH 安全

我在 Debian、Ubuntu、RHEL 和 ARM 上为多个客户维护 Linux 服务器,每个服务器都有自己的端口、可信网络和联系人。本地fail2ban和防火墙配置存在分歧,客户端之间的通用白名单是不可接受的。如何在多租户队列中集中 SSH 安全?

借助 SSH Protector,我可以将主机与受支持的代理连接起来,从一个面板查看检测到的端口和攻击,但将异常和策略保留在所需服务器/客户端的范围内。我应用基线值,单独记录偏差,并通知负责的客户。

我免费描述 Ansible 角色中的 sshd、fail2ban 和 nftables,为每个客户端提供单独的清单和保管库,检查 CI 中的更改并使用租户标签收集 Wazuh/central syslog 中的日志。我会自动将配置与基线进行比较,并且从不组合来自不同客户的密钥、CIDR 和机密。

不稳定网络上的离线 SSH 保护

我的 Linux 服务器位于分支机构或不稳定的通道后面:云面板和 DNS 有时不可用,但内部或通过转发端口的 SSH 继续响应。安全性不必等待每个解决方案的远程 API。如何保持 SSH 暴力破解离线?

通过 SSH Protector,我提前对代理强制执行策略;当与主机的通信丢失时,它会继续读取本地日志并将系统防火墙更改为最新配置。我在关机前同步白名单,恢复后检查累积的历史记录,并且不打开传入代理控制端口。

免费地,我将控制完全本地化:nftables/ufw 只允许从 VPN 或所需子网进行 SSH,而fail2ban 通过journald 工作,无需外部网络。我保存加载规则,设置本地通知队列,测试没有 DNS 的重启,然后离开物理/提供商控制台来恢复错误规则。

替换 fail2ban 而不留出防护空窗

这台 Linux 服务器上的 fail2ban 已经跑了两年,sshd 的 jail 一直正常。我想换成托管代理试试,但 22 端口连几分钟都不能失去防护,也不希望两个工具抢同一批防火墙规则。怎样把 fail2ban 换成 SSH Protector 而不停机?

我在 fail2ban 继续运行的情况下安装 SSH Protector 代理。代理有自己独立的 nftables 表(inet sshprotector,老系统上则是带前缀的 ipset 命名空间),并且只重建这张表,因此完全不碰 fail2ban 的链,两者谁也不会回滚谁。安装时我先把自己的地址加入白名单,然后在面板里观察一天,看代理抓到的来源是否和 jail 一致。确认之后才停掉 fail2ban 并清掉它的规则。如果我改变主意,卸载代理会把它自己的规则一并带走,防火墙恢复原样。

即使不用任何代理,两个读日志的工具之间的切换也是同样的做法:让旧的继续跑,给新的单独的链名或表名,使规则不会冲突,用整整一天的真实流量比较各自抓到了什么,等新工具的封禁数不再是两者中较少的那个,再关掉旧的。永远不要先卸掉正在工作的那个:暴露的 SSH 端口上几分钟没有防护,对一个已经在扫描你的僵尸网络来说就够了。

在 CrowdSec 和托管代理之间做选择

我在为一小批 Linux 服务器挑选 SSH 暴力破解防护方案,CrowdSec 反复被提到:开源、有社区黑名单、覆盖面也不只是 SSH。SSH Protector 有哪些 CrowdSec 没有的东西?我该怎么在两者之间做决定?

两者从不同方向解决有重叠的问题,我按形状而不是按打分来选。CrowdSec 是一个引擎:有场景语言、需要自己安装并接好的封禁组件,以及由所有使用者共同喂养的黑名单,覆盖范围远不止 SSH。SSH Protector 是一个只做一件事的二进制:读 SSH、SFTP 和 FTP 的认证日志,在自己的 nftables 表里封禁攻击者整个 /24,重启后封禁仍然有效,从 sshd 配置里识别真实端口而不是假定 22,并向面板汇报,在受保护的服务器失声时告诉我。情报在受保护账户之间共享,而不是共享给整个互联网。

所以这个决定取决于我手上实际有什么。如果我需要广度——HTTP、数据库、任意日志源、自己写的检测场景——CrowdSec 有这个空间,而且运行起来不花钱。如果我手上只是几台开着 SSH 端口的 Linux 机器,又没有人维护一整套检测栈,那我要的是那个不用配置就正确的窄东西。我没有在同一台机器上把两者对比跑过,所以不按性能数字来选——拿这些数字来说服我的人也不该那样做。

今天就保护您的第一台服务器

Free 套餐永久免费。需要时一键升级。

08信任

谁在开发、你付款给谁,以及代理程序能在你的服务器上做什么

在生产服务器上以管理员权限安装任何东西之前,这三个问题值得先有答案。

谁在开发01

SSH Protector 由 Recovery Toolbox 首席服务器安全专家 Victor G. Bobrov 编写:20 多年系统开发与安全经验,持有 Microsoft MCSD/MCDBA 认证。检测规则、封禁逻辑以及本站的文章都是他的工作,以本人署名发布,而不是匿名品牌。 关于作者 →

你付款给谁02

供应商是在保加利亚(欧盟)注册的 File Master LLC:Bulstat/VAT 180842207,办公室位于瓦尔纳,可通过电话与邮件联系。付款由 PayPro Global 作为登记商户处理;服务条款、隐私政策和数据处理协议均全文公开,而非概要。 服务条款 · 隐私政策 · DPA

代理程序能做什么、不能做什么03

代理程序读取所在主机自己的 SSH 认证日志,并在同一台主机上写入 nftables 规则。它不开放任何入站端口,没有远程命令通道,对外只走 HTTPS。它没有攻击能力:其中没有任何东西可以攻击另一台机器。封禁判断在本地做出,因此云端不可达时防护照常工作;安装时会把你当前的 IP 加入白名单,代理程序不会把你挡在自己的服务器之外。安装程序经过代码签名。 工作原理 →

09资源

资源:这一切所处的协议、攻击与标准

SSH 暴力破解防护并不是一个独立话题,而是一个协议、一类攻击和一组公开标准的交汇点。以下是定义它们各自的来源。

链接指向来源本身:实体有标识符时指向 Wikidata,没有时指向一手资料。

Recovery Toolbox / File Master LLC

联系 Recovery Toolbox

Recovery Toolbox 与 File Master LLC 的联系方式,以及公司首席安全专家 Victor G. Bobrov 的简介。

公司办公室

File Master LLC 是 Recovery Toolbox 在线服务和软件产品背后的法律实体。

File Master LLC
Serena app., office C13
Golden Sands, Varna, 9007
保加利亚,欧盟
Bulstat/增值税
180842207

关于 Recovery Toolbox

File Master LLC 开发并维护 Recovery Toolbox 的在线服务和软件产品,用于修复损坏的文件、数据库和邮件存储格式。公司专注于为需要恢复损坏数据访问权限的用户、IT 专业人员和企业提供实用的恢复工具。

欢迎您的意见和建议。请通过电子邮件向我们发送对网站的反馈: webmaster@recoverytoolbox.com

Victor G. Bobrov, server security specialist and author of SSH Protector
安全专家

Victor G. Bobrov

服务器安全专家 · 20 多年系统开发与安全经验

Victor G. Bobrov 在 File Master LLC / Recovery Toolbox 负责安全研发。他设计了 SSH Protector 的检测与封禁逻辑:解析 SSH 认证日志,区分暴力破解、密码喷洒与普通输错,用一条 nftables 规则封禁攻击方所在子网,并在受保护的服务器群之间共享攻击者信誉。

  • 暴力破解防护
  • Linux 与 SSH 加固
  • nftables 与网络策略
  • MCSD
  • MCDBA
关于作者 →

Microsoft 认证

Microsoft Certified Solutions Developer - MCSD。Microsoft Certified Database Administrator - MCDBA。

MCSD MCDBA