接手了一批TongWeb7应用服务器做安全加固扫描结果里有一条很刺眼控制台暴露在公网验证码形同虚设登录接口连访问频率限制都没有。运维同事在旁边补刀说每次登录控制台输验证码眼神不好使输错三次直接会话过期烦得要命。所以这次干脆把两件事一起办了——关闭控制台关闭验证码。整个过程不算复杂但里面有几个坑值得记一下本文把我的实操过程完整写出来给同样在用TongWeb7做国产化项目的朋友一个参考。先说清楚这篇文章讨论的是TongWeb7管理控制台的登录验证码以及控制台本身的开关问题不涉及业务系统里的验证码功能。你如果只想把控制台的验证码关掉或者想把整个控制台从公网环境里藏起来下文应该都有你能用的方案。1. 两个需求先拎清楚关验证码和关控制台是两码事很多人在拿到这个需求的时候第一反应是“这俩不是一回事吗”。还真不是。控制台是TongWeb7自带的Web管理应用验证码只是它登录环节里的一道关卡。你把验证码关了控制台还在只是登录的时候少输一组数字你把控制台关了验证码再也不用输了但对应的管理功能也没了。两个操作的目标、路径、影响范围都不同动手之前务必想清楚自己到底要哪一个。1.1 为什么控制台会成为众矢之的TongWeb7的控制台默认访问地址是“HTTP端口/console”。比如你的服务监听在8080那控制台地址就是http://IP:8080/console。这个地址对扫描器来说几乎是公开的几十块钱的漏扫工具扫一圈十个里有八个能发现这个路径。控制台一旦暴露在外网攻击者就可以对着登录页面不断尝试弱口令验证码虽然能起到一定的拦截作用但它本质上只是一个防脚本的验证机制拦截不了认真的爆破也拦不住已经泄露的账号。更麻烦的是有些项目在交付时沿用了默认账号密码或者把密码设置得极其简单。安全扫描报告里常见的“管理控制台暴露”“无锁定机制”“验证码可绕过”这类问题十有八九是指向这个页面。等保三级、护网、行业合规检查都会重点看这东西。所以“关闭控制台”或“关闭验证码”这两个动作本质上都是缩小攻击面。1.2 关验证码与关控制台的适用场景这两个操作分别适合什么情况我的判断是这样的关验证码一般适用于两个场景。一是内网环境网络边界本身可控团队里有多个人需要频繁登录控制台查日志、调数据源验证码纯属给运维添堵。二是自动化运维场景脚本需要调用控制台的部署接口或者定时检查运行状态验证码的存在会让脚本对接非常痛苦。关控制台则适用于更严格的场景。比如公网环境、客户要求最小权限、或者控制台的功能本来就用不上应用部署和配置都走自动化发布数据源通过配置文件管理那直接把控制台禁用掉是最省心的。需要注意的是控制台关闭后TongWeb7的图形化管理入口就没了你必须确认自己的运维手段能覆盖原有控制台的职责否则排查问题的时候会非常难受。2. 动手前的目录体检TongWeb7的部署结构长什么样别急着改先摸清家底。TongWeb7的安装目录结构和Tomcat很像但又有自己的特点。如果连控制台在哪个目录、配置在哪个文件里都没搞清楚就动手大概率会把配置文件改乱最后只能重装。2.1 安装目录里的关键路径以我见过的大多数生产环境为例TongWeb7通常安装在/opt/TongWeb7、/app/TongWeb7或者/usr/local/TongWeb7这类路径下。如果你不确定装在哪用下面的命令找一下find / -name startserver.sh 2/dev/null或者直接看进程ps -ef | grep tongweb找到安装目录后重点看这几个地方路径作用bin/启动、停止脚本比如startserver.sh、stopserver.shconf/server.xml核心服务配置文件监听端口、虚拟主机、Context映射都在这里conf/tongweb.xmlTongWeb的扩展配置类似Tomcat的context.xmldeployment/应用部署目录控制台应用通常在这里deployment/console/控制台Web应用的根目录logs/运行日志目录排错第一现场TongWeb7的控制台在deployment目录下一般表现为一个独立的文件夹名字就叫console。老一点的版本可能是console.warTongWeb7启动时自动解压到deployment/console。你在操作前先ls一下deployment目录确认控制台应用的实际存在形式。2.2 控制台应用的本质deployment目录下的独立Web应用很多人容易忽略一个事实TongWeb7的控制台本身就是一个标准Web应用和你的业务系统WAR包没有本质区别。它有自己的WEB-INF/web.xml、JSP页面、静态资源、Servlet逻辑。TongWeb7启动时会按照conf/server.xml里的配置或者按照deployment目录的自动部署机制把console这个应用加载到容器里。加载成功后就监听在HTTP端口上路径映射到/console。理解这一点特别重要。你后面不管是关验证码还是关控制台操作的本质上都是一个Web应用的内部文件或它的加载方式而不是去动TongWeb7的二进制核心。这大大降低了操作风险。2.3 备份与回滚先给自己留后路既然是动生产环境备份是必须的。我习惯在改任何配置前先把相关文件备份好这一步别省。# 备份核心配置文件 cp -p $TONGWEB_HOME/conf/server.xml $TONGWEB_HOME/conf/server.xml.bak.$(date %Y%m%d) # 备份整个控制台应用如果只是关验证码建议备份这一份 cp -rp $TONGWEB_HOME/deployment/console $TONGWEB_HOME/deployment/console.bak.$(date %Y%m%d)-p参数保留文件属性和时间戳-r用于目录递归复制。备份文件别放在deployment目录里TongWeb7可能会把它当成一个Web应用去自动部署到时候反而多暴露一个路径。我一般复制到/root/backup/或者/data/backup/这类专用目录。3. 关闭验证码改前端模板还是后台过滤器验证码这个东西实现方式五花八门。TongWeb7控制台的验证码在我经手的几个版本里基本是通过一个Servlet动态生成图片图片地址固定一个URL比如/console/captcha.png登录页面加载时把它塞到img标签里。用户提交表单时把图片上看到的字符一起提交后端再和Session里存的校验值比对。理解了这条链路关闭验证码的思路就清晰了要么让登录页面不渲染验证码输入框并把提交参数去掉要么让后端不再校验验证码字段。实际操作中我更推荐从后端走因为只改前端页面的话强刷浏览器缓存仍然可能看到老页面而且后端的校验逻辑还在说不定哪个接口绕过前端直接调用就卡在验证码上。3.1 验证码在登录链路中的位置正常登录流程大致是打开http://IP:8080/console页面弹出一个登录框旁边有一张验证码图片输入账号、密码、验证码点登录。浏览器把这三个字段POST给后端的登录接口一般是/console/login或/console/j_security_check这类地址后端先从Session里取出之前生成的验证码值和请求里提交的验证码做比对不一致就直接返回“验证码错误”一致了才继续走账号密码认证。搞清楚这个位置之后我们要做的就是让“比对验证码”这个环节失效。3.2 操作步骤找到验证码组件并让其失效不同小版本的TongWeb7验证码Servlet的类名和URL可能不一样但定位思路完全一致。第一步进入控制台应用目录搜验证码相关的关键词cd $TONGWEB_HOME/deployment/console/WEB-INF grep -ri captcha . --include*.xml --include*.properties --include*.js --include*.jsp | head -50captcha是最常见的命名如果搜不到再试试verify、code、validate这几个关键词。TongWeb7的验证码组件命名通常不会太花哨大概率能直接命中。第二步看找到的配置文件。如果验证码是独立Servlet实现的web.xml里会有类似这样的配置servlet servlet-nameCaptchaServlet/servlet-name servlet-classcom.tongweb.console.servlet.CaptchaServlet/servlet-class /servlet servlet-mapping servlet-nameCaptchaServlet/servlet-name url-pattern/captcha.png/url-pattern /servlet-mapping注意不同版本的servlet-class名称可能不同别纠结于类名是否和我写的一样重要的是找到这段结构。把它注释掉或者删掉保存文件。第三步如果搜遍了WEB-INF目录没有发现任何验证码相关配置那说明验证码逻辑可能写死在某个class文件里了。这种情况不用慌还有一个更简单的路径改登录页面。找到deployment/console目录下的登录JSP页面一般是login.jsp或index.jsp用编辑器打开找到验证码相关的HTML标签一般是这样的结构img srccaptcha.png idcaptchaImg onclickrefreshCaptcha() / input typetext namecaptchaCode idcaptchaCode /把整个img和input标签删掉同时把JS脚本里给验证码赋值的逻辑注释掉。这样前端提交时就不会带上captchaCode参数了。第四步也是最关键的一步后端逻辑如果还在校验验证码怎么办大多数TongWeb7版本的登录接口都会判断验证码参数是否存在如果请求里压根没带这个参数很多实现会直接放行或者跳过该校验具体取决于开发者的编码习惯。我在实际测试中发现只要前端不传验证码字段TongWeb7控制台的登录接口基本都能正常走完账号密码认证。如果你的版本不行——登录时报“验证码为空”或“验证码错误”——那就需要找到后端校验的入口。后端校验一般也是一个Filter或者登录Servlet里的几行代码。如果是Filter在web.xml里找到对应的filter-mapping把它注释掉即可。如果是写在Servlet里的那就比较麻烦class文件不好直接改这时候可以考虑我用过的另一种方法把登录接口从验证码校验逻辑里绕过去利用TongWeb7的SPI扩展点覆盖登录逻辑。但这种做法偏定制化不适合作为通用方案写死的步骤只能提供一个排查思路用javap -c反编译看下CaptchaServlet和登录相关的类确认校验逻辑所在再决定是改配置还是打补丁。3.3 验证码关闭后的验证清单改完配置重启TongWeb7重启命令见第5章然后逐项确认浏览器无痕模式访问控制台地址登录页面不再显示验证码图片。只输入账号和密码可以直接登录不再提示“验证码为空”或“验证码错误”。连续刷新登录页、连续输错几次密码不会再触发验证码刷新或会话锁定。如果第3条仍然触发说明控制台里还有一层登录安全策略在起作用那个属于账户锁定策略和验证码开关无关要关的话需要去控制台的用户安全配置里找这里不展开。4. 关闭整个控制台三种方案从温和到激进关闭验证码是“打了麻药做手术”关闭控制台则是“直接把手术室锁了”。如果你确认控制台在业务运维中已经没用了或者安全红线要求必须把它关掉下面三个方案按温和程度排序你根据现场情况选。4.1 方案一IP白名单限制控制台“隐身”而非消失这是我最推荐优先尝试的方案尤其是那些还需要保留控制台应急入口的场景。思路很简单不让控制台从任意IP都能访问只允许本机或者办公网白名单IP访问。TongWeb7继承了Tomcat内核的Valve机制我们可以利用RemoteAddrValve做IP访问控制。在conf/server.xml里找到Host节点为控制台应用单独加一个Context然后在Context里配置ValveHost namelocalhost appBasedeployment unpackWARstrue autoDeploytrue Context path/console docBaseconsole reloadablefalse Valve classNamecom.tongweb.catalina.valves.RemoteAddrValve allow127.0.0.1|192.168.10.0/24 deny/ /Context /Hostallow后面跟的是允许访问的IP或IP段用|分隔。deny表示不额外拒绝其他地址。这个配置的意思是只有本机和192.168.10.0/24网段能访问/console其他来源一律拒绝效果等同于“控制台不存在”。如果TongWeb7的部署机制里没有显式写Context而是靠自动扫描deployment目录那么把Valve放在Host层级也是一样的效果只不过作用范围会扩大到该Host下所有应用。为了避免误伤业务应用建议还是为/console单独建Context。这个方案的好处是控制台功能完全保留只是访问范围被限制万一以后需要从新IP访问改一下allow列表重启就生效。缺点是server.xml的Valve类名在不同版本里可能有差异有的版本类名里是catalina还是tongweb打开文件看一下同名的类路径即可确认改之前最好对照自己的TongWeb7版本确认。4.2 方案二注释server.xml中的Context按需启停如果你觉得控制台应该彻底停掉而不是留着做白名单限制那就直接把/console的Context从加载列表里摘掉。打开conf/server.xml找到类似下面的内容Context path/console docBaseconsole reloadablefalse /把它注释掉!-- Context path/console docBaseconsole reloadablefalse / --保存后重启TongWeb7控制台应用就不会再被加载了。浏览器访问http://IP:8080/console会返回404等于控制台从“可访问”变成了“不可访问”。但这里有个前提——你得确认你的TongWeb7里控制台是显式配置在server.xml里的。如果你的server.xml里压根找不到和console相关的Context那说明控制台是走deployment目录自动部署加载的注释server.xml里的任何东西都没用。这时候就得用方案三。判断方法很简单grep -i console $TONGWEB_HOME/conf/server.xml有输出就是显式配置没输出就是自动部署。方案二的优点基本不用动控制台的文件想恢复的时候取消注释再重启即可回滚成本极低。缺点只适用于显式配置的部署方式而且如果TongWeb7后续升级或者修复漏洞时重新生成了server.xml修改会被覆盖需要重新配置。4.3 方案三移除console部署目录物理屏蔽这是最直接、兜底效果最好的一招也是我在自动部署方式的TongWeb7环境里最常用的做法把deployment目录下的console应用移走让TongWeb7压根找不到它。cd $TONGWEB_HOME/deployment mv console /data/backup/console.bak.$(date %Y%m%d)注意别直接rm -rf尽量用mv改名或移走万一后面要恢复把目录移回来就行。移动完目录后重启TongWeb7$TONGWEB_HOME/bin/stopserver.sh $TONGWEB_HOME/bin/startserver.sh重启后deployment目录里没有console这个应用了控制台自然也就没了。访问/console会返回404同时启动日志里也不会再有控制台应用的加载记录。方案三的优点是对自动部署和手动部署两种方式都奏效物理上断了控制台被加载的可能最持久、最彻底。缺点是恢复时需要把备份目录复制回来并重启另外如果你没有备份直接删除那控制台应用文件就真的没了想重建只能重新安装或用安装包里自带的war包解压。4.4 三个方案怎么选一张表说清楚方案操作对象控制台还能不能用恢复难度适用场景方案一IP白名单server.xml添加Valve白名单内可正常使用低删掉Valve重启内网运维需要保留入口方案二注释Contextserver.xml注释Context不可用文件保留低取消注释重启显式配置部署、想保留控制台文件方案三移除目录deployment/console移走不可用文件不在部署目录中移动回来重启自动部署方式、物理隔离需求我的建议是如果你有疑虑、拿不准以后会不会还要用控制台先上方案一或方案二如果客户的安全要求非常严格明确说“控制台这东西就不允许存在”那就方案三一把梭。5. 重启、验证和回滚收尾工作别马虎改配置只是开始重启和验证才是真正决定成败的环节。很多人在这一步翻车要么重启失败要么服务起不来要么改了个寂寞——控制台还在。所以这章把重启、验证和常见问题单独拉出来说。5.1 重启TongWeb7的正确姿势TongWeb7的启停脚本在bin目录下先停后起顺序别反$TONGWEB_HOME/bin/stopserver.sh $TONGWEB_HOME/bin/startserver.sh等1到2分钟然后看进程和日志确认启动成功ps -ef | grep tongweb | grep -v grep tail -f $TONGWEB_HOME/logs/catalina.out看到类似“Server startup in xxx ms”或者“TongWeb started successfully”的日志说明启动完成。如果你的版本日志文件名是server.log或tongweb.log那就看对应的文件。总之一定要等日志明确提示启动完成再进行下一步验证别在启动中途就急着访问页面。5.2 怎么确认控制台真的关了验证分两步。第一步看HTTP响应码。用curl测一下控制台地址curl -I http://127.0.0.1:8080/console如果控制台已被关闭预期结果是404找不到页面或者连接超时被拒。如果返回200说明控制台还活着配置没生效回去检查是不是改错了文件或者没重启。第二步看启动日志。用grep过滤控制台相关的加载记录grep -i console $TONGWEB_HOME/logs/catalina.out | head -20如果控制台应用已正常被移出加载日志里应该看不到“Deploying web application archive console”或者“Loading console module”这类字样。有说明还在加载没有说明关闭成功。注意关闭验证码和关闭控制台的验证方式侧重点不同关验证码验证的是登录页面的交互形态关控制台验证的是路径的可达性和日志加载记录。两个别搞混。5.3 遇到这几种情况怎么办场景一删了console目录重启之后控制台又出现在deployment目录里。这是autoDeploytrue配合War包源文件导致的。有些版本在deployment目录下保留了console.war或者存在一个备用的console副本TongWeb7启动时检测到部署包又给它重新解压部署了。解决办法是找到deployment目录下的console.war也一起移走或改名然后再次重启。场景二关闭控制台后业务应用也访问不了了。先别慌大概率是你改server.xml的时候把整个Host节点的结构破坏了或者Valve配置写到了Host层级误伤了所有应用。检查server.xml把Valve限定在/console的Context里然后恢复业务应用的Context配置重启。场景三关闭验证码后登录控制台一直提示“验证码错误”。这说明后端校验逻辑没有被关掉前端输入框删了但接口还在拿Session里的验证码值做比对。回去看web.xml里有没有过滤器类和登录Servlet绑定到一起了把filter-mapping注释掉重启再试。实在不行把控制台关了吧一劳永逸。场景四回滚之后控制台还是访问不了。检查备份文件是否放在了正确的位置比如你改的是server.xml恢复时要确保把备份复制回conf目录而不是复制到deployment目录。恢复完重启再用curl验证。经历过一次回滚你就会发现备份时把原配置文件的修改时间和内容都记录清楚比什么都重要。6. 个人经验控制台是关是留建议想清楚再动手我在不少项目里做过TongWeb7的加固说实话真正需要完全关闭控制台的场景远比想象中少。大部分业务团队在排查线上问题的时候还是会依赖控制台看连接池状态、线程情况、JVM信息。如果你把控制台一刀切关了这些信息就只能靠日志和命令行工具去拿排查问题的效率会明显下降。所以我的做法通常是先评估团队有没有替代手段没有就先上IP白名单把控制台变成“内部工具”只有安全部门明确下了死命令我才会上移除目录这种终极手段。另外关闭验证码这件事我的看法是内网用可以放公网千万别这么干。验证码再弱也能把批量脚本挡掉一大半。如果公网环境实在受不了验证码优先应该做的是把控制台的访问方式改成内网域名堡垒机跳板而不是简单地把验证码关掉。堡垒机层面做一次认证比你靠一个验证码做第一道防线要靠谱得多。最后分享一个小技巧操作前把TongWeb7的版本号记录下来同时用diff备份文件和修改后的文件后面如果TongWeb7打了补丁或者版本升级你就能快速判断哪些改动需要重新做。我见过太多人升级中间件之后才发现自己之前手工改的加固项全部被覆盖了这种问题提前记录是可以完全避免的。