凌晨两点十七分，检测我手机弹出一条告警：某台数据库服务器的暴力1433端口在十分钟内收到超过四千次登录失败记录。这不是破解误报。我连上VPN，检测打开SQL Server的暴力Error Log，满屏的破解“Login failed for user 'sa'”，每秒钟六七条，检测像心跳一样规律。暴力

暴力破解SQL Server从来不是破解什么新鲜事。但这次有点不一样——攻击源IP来自三个不同国家的检测云主机，登录名从sa、暴力admin、破解test，检测到一些我根本没见过的暴力自定义账户名，字典明显是破解精心准备过的。更关键的是，他们只盯着1433端口打，其他端口碰都不碰。这说明对方很清楚自己在找什么。

我拉了一下防火墙日志，发现攻击其实从三天前就开始了，只是频率很低，每小时两三次，混在正常扫描流量里根本不起眼。从昨天下午开始突然加速，大概是字典跑到了“常用弱密码”那一段。这种阶梯式加压的手法，比一上来就狂轰滥炸更危险——它试探的是你的告警阈值和响应速度。

SQL Server的暴力破解有个特点：它不像Web登录那样有验证码、有账户锁定策略（默认没有）、有WAF挡着。1433端口一旦暴露在公网，就等于把钥匙孔直接怼到别人脸上。我见过太多运维图省事，直接把数据库服务器放在DMZ区，或者用端口映射把内网1433映射出去，理由是“方便远程管理”。方便了谁，不言而喻。

说回这次。我查了攻击用的密码字典，前一百个全是“123456”“password”“sa123”这类。到第三百个左右开始出现“P@ssw0rd”“Admin@123”这种稍微像样点的。真正让我后背发凉的是，字典里有一批密码是带公司域名后缀的，比如“CompanyName@2024”。这说明攻击者不是随机撒网，他们大概率已经掌握了部分企业信息，甚至可能从之前泄露的社工库里拼出了目标画像。

我做了三件事。第一，临时封禁了所有境外IP对1433的访问——业务只在境内跑，没必要留这个口子。第二，把sa账户禁用，检查所有SQL登录账户的密码强度，发现两个测试账户还在用默认密码，直接改掉。第三，在防火墙上加了条规则：同一IP五分钟内失败超过二十次，封禁一小时。这条规则不完美，但能挡住大部分自动化工具。

处理完已经凌晨四点。我坐在椅子上想，这次是运气好，告警来得及时。如果攻击发生在周末，如果我没看到那条推送，如果字典再跑快一点——结果可能就是另一回事了。SQL Server的暴力破解不像漏洞利用那样有技术含量，它靠的就是耐心和概率。而防守方最怕的，恰恰是这种低技术、高重复的攻击方式，因为它太容易被忽略了。

天亮后我跟团队说了这事，有人问要不要上双因素认证。我说先别急着堆方案，把1433从公网撤下来比什么都管用。数据库这东西，本来就不该直接面对互联网。你把它藏在内网，加个跳板机，再配个VPN，攻击面能砍掉九成。剩下的那一成，靠强密码和登录审计兜底。

现在那台服务器的Error Log里，失败记录已经归零。但我知道，扫描不会停。明天可能换个端口，后天可能换个字典。做运维这行，有时候就是跟这些看不见的对手比谁更细心、谁更勤快。没什么捷径，就是盯紧点，别偷懒。