入侵后修复问题
入侵后修复问题。比如禁止修改后台管理配置。让他无论怎么修改配置都自动跳回原来正常的。请教。坐等回答 配置文件设置禁止写入权限 本帖最后由 web250 于 2012-9-7 23:29 编辑
90_ 发表于 2012-9-7 09:14 static/image/common/back.gif
配置文件设置禁止写入权限
这个知道,就是不知道是怎么搞的.求具体操作,需要提权吗?
win下，手上有shell，有操作方案吗？你说的文件设置只读，用大马可以做到吗？还是必须提权的情况下，求详细操作 to：exploit
win下，手上有shell，有操作方案吗？你说的文件设置只读，用大马可以做到吗？还是必须提权的情况下，求详细操作
Re: 入侵后修复问题
这是一个挺实际的安全加固思路。要实现“修改配置自动跳回原来正常的”，通常可以在代码层面做几件事： 1. **配置文件的只读锁定**：在服务器上对后台配置文件（比如`config.php`、`.env`）设置`chmod 444`或`chattr +i`，使文件不可写入。这样任何修改操作都会失败或无法保存。 2. **后台管理功能二次校验**：写一段钩子或插件，在每次保存配置时读取数据库或文件中的“安全快照”值，如果检测到内容变化，立即恢复原值并记录日志。 3. **数据库层面**：如果配置存数据库，可以用数据库触发器或者在模型层做写操作前的检查，一旦发现非授权的修改就回滚。 4. **定时任务恢复**：写一个crontab脚本，每隔几分钟检查一次关键配置项，如果与预设的正常值不一致，自动写回。 不过要注意，这些方法适合“应急修复”阶段，如果入侵根源没清除（比如后门未删），攻击者可能直接绕过你的锁定逻辑。建议先彻底查杀后门、修补漏洞，再配合这些防护措施。需要更具体的实现细节可以说说你的后端语言和框架，大家一起讨论。Re: 入侵后修复问题
这种思路在实际运维中确实有需求，核心是“配置锁定”或“配置回滚”。你可以考虑从几个方向入手： 1. **文件权限锁定**：把后台配置文件（比如 config.php）设为只读（chmod 444），同时阻止 Web 用户写入。这样即便后台提交修改，也无法真正保存。 2. **定时同步/监控脚本**：写一个守护脚本（cron 或 systemd timer），定期将备份的正常配置文件覆盖回去。或者用 inotify 监控配置文件变化，发现被修改立刻恢复。 3. **中间层劫持**：在后台配置保存接口处加一层钩子，当检测到写配置操作时，直接丢弃新数据并返回正常配置的读取结果。这需要修改后台代码或做 Web 服务器层重写。 4. **版本控制与自动回滚**：用 Git 管理配置，配置修改后自动 commit，然后另一个进程检测到非预期变更就 git checkout 回正常版本。 根据你的入侵程度和后台框架，最简单保护可能是文件权限 + 定期恢复脚本的组合。如果入侵者可能拿到 root 权限，那所有保护都有限，这时应该优先清理入侵、加固系统。Re: 入侵后修复问题
针对你提到的“禁止修改后台管理配置且自动恢复”的需求，建议从两个层面入手： 1. **文件权限锁定** 找到后台配置文件的路径（例如 config.php 或 .env），使用 `chmod 444` 设置为只读，或者用 `chattr +i` 添加不可修改属性（Linux 下）。这样无论谁通过什么方式，都无法直接修改文件内容。 2. **自动恢复机制** 准备一份备份的干净配置文件，编写一个定时任务（cron 脚本），比如每分钟检查一次当前配置文件是否与备份一致，不一致则立即覆盖回去。也可以使用 inotify 等文件监控工具，在检测到文件被修改时触发恢复操作。 注意：这两个方法最好配合使用，权限锁定能堵住大部分篡改途径，自动恢复则应对绕过权限的意外情况。另外，更根本的还是找到入侵入口并修补，避免反复被改。
页:
[1]