零基础DNN维护求助：遭入侵站点的谷歌广告清除与结构排查

哥们，我完全懂你刚接手这烂摊子的崩溃——旧DNN+被入侵，广告清了又冒，还摸不清目录结构，这组合真的头大。先别慌，咱们一步步拆解问题，先把广告的根子拔掉，再理清楚DNN的核心逻辑。

一、广告反复出现的核心原因（你可能漏了这些地方） #

你在UI删文章里的广告没用，大概率是攻击者把恶意代码藏在了数据库、全站皮肤/模板、模块底层，甚至服务器层面留了定时篡改的后门，不是只存在单篇博客里。

1. 先查数据库（重中之重！） #

DNN的博客内容99%存在数据库里，不是文件系统里的HTML文件！

• 打开SQL Server Management Studio连接你的DNN数据库（默认名一般是DNN_xxx），先找博客模块对应的表：
  • 如果是DNN内置的Blog模块，表名通常是Blog_Posts，看Content字段，直接搜谷歌广告的脚本关键词（比如googleadservices.com），找到后批量替换删除。
  • 如果是第三方博客模块（比如DNN Blog Module），找类似[ModulePrefix]_Posts的表，同样查内容字段。
• 顺便检查数据库里的Users表，除了你删的超级管理员，有没有创建时间异常、用户名奇怪的账号，直接删掉并清理关联的角色权限。

2. 检查全站皮肤/容器 #

恶意广告最常藏在全站通用的皮肤里，只要皮肤没清干净，所有页面都会自动加载广告：

• 去服务器的/Portals/_default/Skins/目录（默认站点的皮肤），还有对应站点的/Portals/[PortalID]/Skins/（比如Portals/0/），打开所有.ascx、.html、.cshtml文件，搜广告脚本关键词，删掉恶意代码。
• 同样检查/Portals/_default/Containers/和对应站点的容器目录，容器是包裹模块的模板，也可能被篡改。
• 去DNN后台「外观」→「皮肤」，确认当前使用的皮肤是官方干净版本，有没有被替换成恶意皮肤。

3. 排查Web.config和服务器层面的后门 #

• 重新检查web.config：除了你删的恶意配置，看有没有appSettings里的奇怪键、modules节点里的陌生模块，或者有没有configSource指向外部恶意配置文件（比如<appSettings configSource="malicious.config" />），找到后删掉。
• 检查服务器上的Global.asax文件，有没有被插入恶意代码（比如自动篡改内容的脚本）。
• 查看服务器的定时任务（Windows的任务计划、Linux的Cron），有没有攻击者创建的定时脚本，自动恢复广告内容。

4. 清理模块的恶意篡改 #

如果用的是第三方博客模块，攻击者可能替换了模块的核心文件：

• 去/DesktopModules/[YourBlogModuleName]/目录，对比官方同版本模块的文件，或者直接下载干净的模块安装包，替换掉可疑文件（先备份原文件！）。

二、快速搞懂DNN核心目录结构（针对你的问题） #

你找不到博客文章的存储位置，是因为DNN是数据库驱动的CMS，大部分内容都存在数据库，文件系统主要存模板、模块、上传文件：

• Portals/：每个站点（Portal）的独立资源，Portals/0/是默认站点：
  • Skins/：站点专属皮肤
  • Containers/：站点专属容器
  • Files/：用户上传的图片、文档等静态文件（博客文章的内容不在这）
• DesktopModules/：所有功能模块的代码（包括博客模块），核心逻辑都在这里
• Admin/ & Portals/_default/Admin/：后台管理相关的文件，攻击者可能改这里加后门
• bin/：DNN的核心程序集，一般不要随便改，但要确认有没有被替换成恶意dll

三、应急后的前置准备（为升级铺路） #

1. 清理完所有恶意内容后，立刻开启DNN的审计日志：后台「系统」→「日志」→「审计日志」，开启所有关键操作的记录，方便监控后续有没有异常修改。
2. 暂时关闭不必要的文件上传权限：后台「设置」→「安全」→「文件设置」，禁用非管理员的上传功能，防止攻击者再传恶意文件。
3. 做全量备份：数据库备份+整个文件系统的压缩备份，升级前一定要留好退路。

内容的提问来源于stack exchange，提问作者underhook