如何捕获 SQL 服务器破解者？ [关闭]答案

【问题标题】：How to catch a SQL server cracker? [closed]如何捕获 SQL 服务器破解者？ [关闭]
【发布时间】：2008-12-31 14:53:20
【问题描述】：

简介：

我团队中的人一直在研究生产数据库（sql server 2005）。我们添加了各种东西，例如约束、添加的触发器等。

现在我们发现有人或某事在不同时间回滚了我们的更改。问题是我们都共享一个共同的管理员登录。（愚蠢，是的，我知道，我们正在解决这个问题）。它引起了很多挫败感，在这一点上，我们只想找出谁。

你将如何追查有罪的一方？

注意：我不是在寻找解决此问题的方法，这已经在完成。我正在寻找一种方法来追查罪魁祸首。

【问题讨论】：

你确定不是有人从旧备份恢复？
同意@Andrew Cox：这听起来确实是一个可能的原因。
如果您共享一个共同的登录名，您将无法跟踪它。也许您可以在您的 SQL 服务器上放置一个协议分析器并读取 TDS 数据包，并将它们映射回它们来自的 IP 地址。哈哈
你有没有考虑过你的工具造成的可能性？我使用过 DB Pro（VS Team Suite 的一部分），并且目睹了它在我的数据库中到处都是垃圾。还要考虑它可能不是恶意的，而是由于导致它的人缺乏理解。
我投票结束这个问题，因为这个问题与编程无关。可以在 dba.SE 上询问有关数据库管理的问题

标签： sql-server tsql

【解决方案1】：

远离生产数据库。创建您的脚本并将它们通过电子邮件发送给负责的 DBA（如果您没有，请获取）。可以访问生产数据库的开发人员是灾难的根源——我没有，也不想拥有它。

【讨论】：

是的...我会说甚至遵循这条规则来测试数据库。保留一个开发人员可以乱用的开发数据库。
我同意，我们称之为“验收”或“质量保证”数据库，DBA 可以在其中应用补丁并确保它在应用到产品之前能够正常工作。理想情况下，开发人员拥有自己的数据库沙箱来做他们想做的任何事情。
我同意。绝不应允许开发人员靠近生产箱（网络或数据库）。如果它在 staging 但在生产中不起作用，那么基础架构团队最好弄清楚为什么 staging 与生产不完全一样。

【解决方案2】：

跟踪您的问题显然是一种症状，而不是原因：因为它是一个 SQL Server 2005 数据库，所以应该有一个“默认”跟踪，开箱即用。它非常轻量级，但确实包括一些对象的创建和删除。您可以使用以下查询从 sys.traces 视图中查看它：

SELECT *
FROM sys.traces
WHERE id = 1

它仅在几 MB 后滚动，因此它的有用性取决于服务器上的活动量。

据推测，真正的原因可能是您的更改没有编写脚本和版本控制。

同意其他发帖人的观点，他们提到对生产数据库的所有更改都只能由管理员完成，而不是由个人开发人员完成。

【讨论】：

【解决方案3】：

我假设您有一个具有变更数据捕获功能的审核日志。这将跟踪每次更改的人员、内容和时间。

回滚是间歇性的还是一致的？您是否有机会关闭自动提交并忘记提交更改？

不可能有那么多人有足够的权限来做这样的事情。找出谁可以做到并询问。比您可以实施的任何技术都要好。

黑客？里面应该有人。如果您防火墙之外的人有权访问该数据库，您需要与您的网络人员交谈。

尝试将监视器添加到该 URL 和端口，以查看通过了哪些请求。

【讨论】：

【解决方案4】：

您需要注意的是，如果有人恶意更改数据库，并且他们具有管理员访问权限，您必须假设他们足够聪明，可以掩盖他们的踪迹。此时，您可以阻止进一步的破坏，但如果攻击者有任何好处，您要么责怪错误的人，因为日志文件将被更改，要么所有指向正确人的证据都将消失。

最好的方法是拥有它，这样没有人可以直接管理员访问生产数据库。我们设置了一个系统，默认情况下没有帐户具有管理权限，每个人都有自己的帐户。没有人可以使用 SA 帐户。

必须有人授予帐户访问权限，并且在被授予 24 小时后会自动将其删除。理想情况下，授予访问权限的同一个人不应该是获得对数据库的管理访问权限的人。这样一来，必须始终让两个人参与才能对系统进行更改。

理想情况下，应始终由两个人参与进行更改。这样第二个人就可以验证第一个人做了什么。（工作几个小时后晚上10点很容易出错）。

人们会反驳说，有时他们“需要”能够快速做出改变。在大多数地方，情况并非如此。让第二个人参与并解释情况可能需要额外的 10 分钟。清理某人窃取/更改公司数据的声誉需要数年时间。

【讨论】：

我不同意这样的前提，即拥有管理员访问权限会自动使一个人聪明到足以掩盖他们的踪迹。 OP 已经声明默认情况下每个人都有管理员访问权限。因此无法确定此人的知识或智力。

【解决方案5】：

通过添加您应该拥有的用户级安全性。

【讨论】：

【解决方案6】：

您能否将回滚时间与团队人员的行踪交叉引用？

或者，只是问每个人？

【讨论】：

【解决方案7】：

SQL Server 2005 添加了 DDL 和 DML 触发器，因此您可以跟踪谁在修改数据以及数据结构。

【讨论】：

【解决方案8】：

如果您要修复它——“修复它”是指锁定生产数据库并遵循此处提到的其他一些做法——那么不要担心找到罪魁祸首。无论如何，这可能是偶然的，当您将其锁定时，有人会开始想知道为什么有些东西不起作用。

追踪这样做的用户不会解决任何问题。如果是恶意的，他们会撒谎说这是偶然的。

根本原因是数据库的安全性，因此故障组是导致数据库如此易受攻击的组。

【讨论】：

【解决方案9】：

询问每个人没有用，人们会撒谎和/或不知道他们在搞砸这件事。我们假设它是恶意的，但希望不是。

【讨论】：

【解决方案10】：

哇，那你遇到了一个真正的问题。如果你不能信任自己的人......

是时候关闭除一个之外的所有 ID。确保那个人知道他们在做什么并且不撒谎。

【讨论】：

【解决方案11】：

除了您已经收到的回复之外，我的投票是没有人；你只是误会了你是如何使用这个系统的。

现在，不要误会我的意思，我在这里不是在谈论无能。不过，我的意思是，很可能有一些脚本会定期运行，并且有人正确地提到有时自动提交可能是打开还是关闭，有人被愚弄了。

我也相信您在生产环境中混合任何开发工作是在自找麻烦。磁盘空间很便宜——这些天一 TB 不到 300 美元！在大多数情况下，您不需要出色的性能来进行开发工作...

【讨论】：