在没有可用干净版本的情况下清理被黑网站的最佳方法？
我被要求修复一个在生产服务器上使用 osCommerce 构建的被黑网站。
该站点始终存在于远程主机上。没有离线干净版本。让我们暂时忘记这有多么愚蠢，并处理它的本质。
它已被黑客攻击多次，另一个人通过删除 Web shell 文件/上传脚本修复了它。
它经常被黑客攻击。
我能做些什么？
I have been asked to fix a hacked site that was built using osCommerce on a production server.
The site has always existed on the remote host. There is no offline clean version. Let's forget how stupid this is for a moment and deal with what it is.
It has been hacked multiple times and another person fixed it by removing the web shell files/upload scripts.
It is continually hacked often.
What can I do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
因为您无法信任网络主机上的任何内容（它可能安装了 rootkit），所以最安全的方法是方法是从头开始重建一个新的Web服务器；不要忘记在之前更新所有面向外部的软件在线。在严酷的防火墙的快乐的一面进行所有的更新。
当您重建系统时，一定要特别注意正确的配置。如果Web内容由与Web服务器的用户ID不同的Unix用户拥有，并且文件的权限设置为禁止写入，则Web服务器无法修改程序文件。
配置 Web 服务器的 Unix 用户帐户，使其只能对其日志文件和数据库套接字（如果它们位于文件系统中）进行写访问。被黑的网络服务器仍然可以向客户端提供被黑的页面，但重新启动将“撤销”“实时黑客”。当然，您的数据库内容可能会被发送给 Yakuza 或被认为您的数据应包含独角兽图片的人破坏。 最小权限原则将是一个很好的指南——您的网络服务器到底是做什么的<需要访问才能完成其工作吗？仅授予这一点。
还可以考虑部署强制访问控制系统，例如AppArmor, SELinux、TOMOYO 或 SMACK。这些系统中的任何一个，经过正确配置，都可以控制系统遭到黑客攻击时可能损坏或泄露的范围。 （我在 AppArmor 上工作了十年，我相信大多数系统管理员都可以在一两天的学习中学会如何在他们的系统上部署可行的安全策略。没有任何工具适用于所有情况，所以请确保阅读您的所有选择。）
第二次，请务必通过 puppet< 等工具来管理您的配置/a>, 厨师，或者至少在修订控制系统。
更新
其他内容，与重新上线有点无关，但仍然具有教育意义：从受感染的系统中保存硬盘驱动器，以便您可以安装它并从另一个系统检查其内容。也许可以通过对泄露的数据进行取证来了解一些东西：您可能会发现泄露发生在几个月前，并且一直在窃取密码或 ssh 密钥。您可能会发现 rootkit 或进一步的漏洞利用工具。您可能会找到显示攻击来源的信息 - 也许该网站的管理员尚未意识到他们已被黑客攻击。
检查被黑数据时要小心 - 您不认识的
.jpg很可能是首先破解系统的漏洞，并在“已知良好”系统也可能会破解它。使用硬盘进行工作，完成后可以对其进行格式化。 （虚拟化或强制访问控制系统可能足以限制基于数据的“被动”黑客攻击，但没有什么比一次性系统更能让您高枕无忧了。）Because you cannot trust anything on the web host (it might have had a rootkit installed), the safest approach is to rebuild a new web server from scratch; don't forget to update all the external-facing software before bringing it online. Do all the updating on the happy side of a draconian firewall.
When you rebuild the system, be sure to pay special attention to proper configuration. If the web content is owned by a different Unix user than the web server's userid and the permissions on the files are set to forbid writing, then the web server cannot modify the program files.
Configure your web server's Unix user account so it has write access to only its log files and database sockets, if they are in the filesystem. A hacked web server could still serve hacked pages to clients, but a restart would 'undo' the 'live hack'. Of course, your database contents could be sent to the Yakuza or corrupted by people who think your data should include pictures of unicorns. The Principle of Least Privilege will be a good guideline -- what, exactly, does your web server need to access in order to do its job? Grant only that.
Also consider deploying a mandatory access control system such as AppArmor, SELinux, TOMOYO, or SMACK. Any of these systems, properly configured, can control the scope of what can be damaged or leaked when a system is hacked. (I've worked on AppArmor for ten years, and I'm confident most system administrators can learn how to deploy a workable security policy on their systems in a day or two of study. No tool is applicable to all situations, so be sure to read about all of your choices.)
The second time around, be sure to keep your configuration managed through tools such as as puppet, chef, or at the very least in a revision control system.
Update
Something else, a little unrelated to coming back online, but potentially educational all the same: save the hard drive from the compromised system, so you can mount it and inspect its contents from another system. Maybe there's something that can be learned by doing forensics on the compromised data: you might find that the compromise happened months earlier and had been stealing passwords or
sshkeys. You might find a rootkit or further exploit tools. You might find information to show the source of the attack -- perhaps the admin of that site doesn't yet realize they've been hacked.Be careful when inspecting hacked data -- that
.jpgyou don't recognize might very well be the exploit that cracked the system in the first place, and viewing it on a 'known good' system might crack it, too. Do the work with a hard drive you can format when you're done. (Virtualized or with a mandatory access control system might be sufficient to confine "passive" data-based hacks, but there's nothing quite like throwaway systems for peace of mind.)获取网站构建时使用的 osCommerce 版本的新副本，并在新的 osCommerce 和被黑网站之间进行比较。还要检查服务器上存在但 osCommerce 包中不存在的文件。
通过手动比较差异，您可以追踪黑客可能创建或修改脚本的所有可能位置。
Obtain a fresh copy of the osCommerce version the site was built with, and do a diff between the new fresh osCommerce and the hacked site. Also check for files which exist on the server but not in the osCommerce package.
By manually comparing the differences, you can track down all possible places the hack may have created or modified scripts.
我知道现在提供这个解决方案有点晚了，但 osCommerce 开发的官方修复在这里：
http://library .oscommerce.com/confluence/display/OSCOM23/(A)+(SEC)+Administration+Tool+Log-In+Update
应用这些代码更改后，大部分实际工作就是清理网站。管理员登录绕过漏洞将导致攻击者通过文件管理器（通常）将文件上传到可写的目录（通常是图像目录）。
还有其他通常也是可写的文件，其中可能附加了恶意代码。 cookie_usage.php 和includes/languages/english/cookie_usage.php 是受影响的常见文件，但是在某些服务器配置上，所有站点文件都可能受到影响。
尽管官方 osCommerce 修复已链接到上面，但我也建议进行此更改：在上面的页面中，向下滚动，直到看到“更新 PHP_SELF 值”的链接。也进行这些更改。
这将纠正 $PHP_SELF 报告的方式，并防止攻击者使用格式错误的 URL 来尝试绕过管理员登录。
我还建议您将 htaccess 基本身份验证登录添加到 admin 目录。
另请查看我编写的名为 osC_Sec 的插件，它是一个一体化安全修复程序，虽然适用于大多数 php 支持的网络系统，但它是专门为处理旧版本 osCommerce 中存在的问题而设计的。
http://addons.oscommerce.com/info/8283
I know this is a little late in the day to be offering this solution but the official fix from osCommerce developement is here:
http://library.oscommerce.com/confluence/display/OSCOM23/(A)+(SEC)+Administration+Tool+Log-In+Update
Once those code changes are applied then most of the actual work is in cleaning up the website. The admin login bypass exploit will be the cause that has allowed attackers to upload files via the file manager (usually) into directories that are writable, often the images directory.
There are other files that are often writable too which can have malicious code appended in them. cookie_usage.php and includes/languages/english/cookie_usage.php are the usual files that are affected, however on some server configurations, all site files can be susceptible.
Even though the official osCommerce fix is linked to above, I would also suggest to make this change as well: In the page above, scroll down till you see the link that says "Update PHP_SELF Value". Make those changes as well.
This will correct the way $PHP_SELF reports and prevent attackers from using malformed URLs in attempts to bypass the admin login.
I also suggest that you add htaccess basic authentication login to the admin directory.
Also check out an addon I authored called osC_Sec which is an all in one security fix, which while works on most php backed websystems, it is specifically designed to deal to the issues that exist in the older versions of osCommerce.
http://addons.oscommerce.com/info/8283