分类 企业安全 下的文章

企业常见服务漏洞检测&修复整理

前言

12月份要要给公司同学做安全技术分享,有一块是讲常见服务的漏洞,网上的漏洞检测和修复方案写都比较散,在这里一起做一个整合,整理部分常见服务最近的漏洞和使用上的安全隐患方便有需要的朋友查看。如文章有笔误的地方请与我联系WeChat:atiger77

目录

1.内核级别漏洞

Dirty COW

2.应用程序漏洞

Nginx
Tomcat
Glassfish
Gitlab
Mysql
Struts2
ImageMagick
...

3.应用安全隐患

SSH
Redis
Jenkins
Zookeeper
Zabbix 
Elasticsearch
Docker
...

4.总结

漏洞检测&修复方法

1.内核级别漏洞

Dirty COW脏牛漏洞,Linux 内核内存子系统的 COW 机制在处理内存写入时存在竞争,导致只读内存页可能被篡改。

影响范围:Linux kernel >= 2.6.22

漏洞影响:低权限用户可以利用该漏洞写入对自身只读的内存页(包括可写文件系统上对该用户只读的文件)并提权至 root

PoC参考:

漏洞详情&修复参考:

这个漏洞对于使用linux系统的公司来说是一定要修复的,拿web服务举例,我们使用一个低权限用户开放web服务当web被攻击者挂了shell就可以使用exp直接提权到root用户。目前某些云厂商已经在基础镜像中修复了这个问题但是对于之前已创建的主机需要手动修复,具体修复方案可以参考长亭的文章。

2.应用程序漏洞

Nginx

Nginx是企业中出现频率最高的服务之一,常用于web或者反代功能。11月15日,国外安全研究员Dawid Golunski公开了一个新的Nginx漏洞(CVE-2016-1247),能够影响基于Debian系列的发行版。

影响范围:

  • Debian: Nginx1.6.2-5+deb8u3
  • Ubuntu 16.04: Nginx1.10.0-0ubuntu0.16.04.3
  • Ubuntu 14.04: Nginx1.4.6-1ubuntu3.6
  • Ubuntu 16.10: Nginx1.10.1-0ubuntu1.1

漏洞详情&修复参考:

这个漏洞需要获取主机操作权限,攻击者可通过软链接任意文件来替换日志文件,从而实现提权以获取服务器的root权限。对于企业来说如果nginx部署在Ubuntu或者Debian上需要查看发行版本是否存在问题即使打上补丁即可,对于RedHat类的发行版则不需要任何修复。

Tomcat

Tomcat于10月1日曝出本地提权漏洞CVE-2016-1240。仅需Tomcat用户低权限,攻击者就能利用该漏洞获取到系统的ROOT权限。

影响范围: Tomcat 8 <= 8.0.36-2 Tomcat 7 <= 7.0.70-2 Tomcat 6 <= 6.0.45+dfsg-1~deb8u1

受影响的系统包括Debian、Ubuntu,其他使用相应deb包的系统也可能受到影响

漏洞详情&修复参考:

CVE-2016-4438这一漏洞其问题出在Tomcat的deb包中,使 deb包安装的Tomcat程序会自动为管理员安装一个启动脚本:/etc/init.d/tocat* 利用该脚本,可导致攻击者通过低权限的Tomcat用户获得系统root权限。

实现这个漏洞必须要重启tomcat服务,作为企业做好服务器登录的权限控制,升级有风险的服务可避免问题。

当然在企业中存在不少部署问题而导致了Tomcat存在安全隐患,运维部署完环境后交付给开发同学,如果没有删除Tomcat默认的文件夹就开放到了公网,攻击者可以通过部署WAR包的方式来获取机器权限。

Glassfish

Glassfish是用于构建 Java EE 5应用服务器的开源开发项目的名称。它基于 Sun Microsystems 提供的 Sun Java System Application Server PE 9 的源代码以及 Oracle 贡献的 TopLink 持久性代码。低版本存在任何文件读取漏洞。

影响范围:Glassfish4.0至4.1

修复参考:升级至4.11或以上版本

PoC参考:

http://1.2.3.4:4848/theme/META-INF/%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./domains/
domain1/config/admin-keyfile

因为公司有用到Glassfish服务,当时在乌云上看到PoC也测试了下4.0的确存在任何文件读取问题,修复方法也是升级到4.11及以上版本。

Gitlab

Gitlab是一个用于仓库管理系统的开源项目。含义使用Git作为代码管理工具,越来越多的公司从SVN逐步移到Gitlab上来,由于存放着公司代码,数据安全也变得格外重要。

影响范围:

  • 任意文件读取漏洞(CVE-2016-9086): GitLab CE/EEversions 8.9, 8.10, 8.11, 8.12,
    and 8.13
  • 任意用户authentication_token泄露漏洞: Gitlab CE/EE versions 8.10.3-8.10.5

漏洞详情&修复参考:

http://blog.knownsec.com/2016/11/gitlab-file-read-vulnerability-cve-2016-9086-and-access-all-user-authentication-token/

互联网上有不少公司的代码仓库公网可直接访问,有些是历史原因有些是没有考虑到安全隐患,对于已经部署在公网的情况,可以让Gitlab强制开启二次认证防止暴力破解这里建议使用Google的身份验证,修改默认访问端口,做好acl只允许指定IP进行访问。

Mysql

Mysql是常见的关系型数据库之一,翻了下最新的漏洞情况有CVE-2016-6662和一个Mysql代码执行漏洞。由于这两个漏洞实现均需要获取到服务器权限,这里就不展开介绍漏洞有兴趣的可以看下相关文章,主要讲一下Mysql安全加固。

漏洞详情&修复参考:

在互联网企业中Mysql是很常见的服务,我这边提几点Mysql的安全加固,首先对于某些高级别的后台比如运营,用户等能涉及到用户信息的可以做蜜罐表。在项目申请资源的时候就要做好权限的划分,我们是运维同学保留最高权限,给开发一个只读用户和一个开发权限的用户进行使用,密码一律32位,同时指定机器登录数据库,删除默认数据库和数据库用户。

找了一篇还不错的加固文章提供参考:http://www.it165.net/database/html/201210/3132.html

Struts2

Struts2是一个优雅的,可扩展的框架,用于创建企业准备的Java Web应用程序。出现的漏洞也着实的多每爆一个各大漏洞平台上就会被刷屏。

漏洞详情&修复参考:

在线检测平台: http://0day.websaas.com.cn/

记得有一段时间Struts2的漏洞连续被爆出,自动化的工具也越来越多S2-032,S2-033,S2-037,乌云首页上都是Struts2的漏洞,有国企行业的有证券公司的使用者都分分中招,如果有使用的话还是建议升级到最新稳定版。

ImageMagick

ImageMagick是一个图象处理软件。它可以编辑、显示包括JPEG、TIFF、PNM、PNG、GIF和Photo CD在内的绝大多数当今最流行的图象格式。

影响范围:

  • ImageMagick 6.5.7-8 2012-08-17
  • ImageMagick 6.7.7-10 2014-03-06 低版本至6.9.3-9released 2016-04-30

漏洞详情&修复参考:

这个漏洞爆出来时也是被刷屏的,各大互联网公司都纷纷中招,利用一张构造的图片使用管道服符让其执行反弹shell拿到服务器权限,产生原因是因为字符过滤不严谨所导致的执行代码.对于文件名传递给后端的命令过滤不足,导致允许多种文件格式转换过程中远程执行代码。

3.应用安全隐患

为了不加长篇幅长度,加固具体步骤可以自行搜索。

SSH

之前有人做过实验把一台刚初始化好的机器放公网上看多久会遭受到攻击,结果半个小时就有IP开始爆破SSH的密码,网上通过SSH弱密码进服务器的案列也比比皆是。

安全隐患:

  • 弱密码

加固建议:

  • 禁止使用密码登录,更改为使用KEY登录
  • 禁止root用户登录,通过普通权限通过连接后sudo到root用户
  • 修改默认端口(默认端口为22)

Redis

Redis默认是没有密码的,在不需要密码访问的情况下是非常危险的一件事,攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法,可以成功在 Redis 服务器上写入公钥,进而可以使用对应私钥直接登录目标服务器。

安全隐患:

  • 未认证访问
  • 开放公网访问

加固建议:

  • 禁止把Redis直接暴露在公网
  • 添加认证,访问服务必须使用密码

Jenkins

Jenkins在公司中出现的频率也特别频繁,从集成测试到自动部署都可以使用Jenkins来完成,默认情况下Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令,攻击者通过暴力破解用户密码进脚本执行界面从而获取服务器权限。

安全隐患:

  • 登录未设置密码或密码过于简单
  • 开放公网访问

加固建议:

  • 禁止把Jenkins直接暴露在公网
  • 添加认证,建议使用用户矩阵或者与JIRA打通,JIRA设置密码复杂度

Zookeeper

分布式的,开放源码的分布式应用程序协调服务;提供功能包括:配置维护、域名服务、分布式同步、组服务等。Zookeeper默认也是未授权就可以访问了,特别对于公网开放的Zookeeper来说,这也导致了信息泄露的存在。

安全隐患:

  • 开放公网访问
  • 未认证访问

加固建议:

  • 禁止把Zookeeper直接暴露在公网
  • 添加访问控制,根据情况选择对应方式(认证用户,用户名密码,指定IP)

Zabbix

Zabbix为运维使用的监控系统,可以对服务器各项指标做出监控报警,默认有一个不需要密码访问的用户(Guest)。可以通过手工SQL注入获取管理员用户名和密码甚至拿到session,一旦攻击者获取Zabbix登录权限,那么后果不堪设想。

安全隐患:

  • 开放公网访问
  • 未删除默认用户
  • 弱密码

加固建议:

  • 禁止把Zabbix直接暴露在公网
  • 删除默认用户
  • 加强密码复杂度

Elasticsearch

Elasticsearch是一个基于Lucene的搜索服务器。越来越多的公司使用ELK作为日志分析,Elasticsearch在低版本中存在漏洞可命令执行,通常安装后大家都会安装elasticsearch-head方便管理索引,由于默认是没有访问控制导致会出现安全隐患。

安全隐患:

  • 开放公网访问
  • 未认证访问
  • 低版本漏洞

加固建议:

  • 禁止把Zabbix直接暴露在公网
  • 删除默认用户
  • 升级至最新稳定版
  • 安装Shield安全插件

Docker

容器服务在互联网公司中出现的频率呈直线上升,越来越多的公司使用容器去代替原先的虚拟化技术,之前专门做过Docker安全的分析,从 Docker自身安全, DockerImages安全和Docker使用安全隐患进行展开,链接:https://toutiao.io/posts/2y9xx8/preview

之前看到一个外国哥们使用脏牛漏洞在容器中运行EXP跳出容器的视频,具体我还没有复现,如果有复现出来的大家一起交流下~

安全隐患:

  • Base镜像漏洞
  • 部署配置不当

加固建议:

  • 手动升级Base镜像打上对应补丁
  • 配置Swarm要当心

4.总结

当公司没有负责安全的同学,做到以下几点可以在一定程度上做到防护:

  1. 关注最新漏洞情况,选择性的进行修复;
  2. 梳理内部开放服务,了解哪些对外开放能内网访问的绝不开放公网;
  3. 开放公网的服务必须做好访问控制;
  4. 避免弱密码;避免弱密码;避免弱密码;

以上内容只是理想状态,实际情况即使有安全部门以上内容也不一定能全部做到,业务的快速迭代,开发安全意识的各不相同,跨部门沟通上出现问题等等都会导致出现问题,这篇文章只罗列了部分服务,还有很多服务也有同样的问题,我有空会不断的更新。WeChat:atiger77

从甲方的角度谈谈WAF测试方法--part2

继Part1之后,停了将近半个月才动笔写第二部分,不是因为懒,实在是最近几个项目事情多。顺手还准备了几个面试,耽搁到了现在。

今天把这篇给自己的总结写完吧。

0X05 Webshell防御

webshell拦截

文件上传防御难免百密一疏,普通的webshell上传后,攻击者必然要通过与webshell通信,开展后续渗透。WAF必须有能力识别通信内容,并及时阻断。很多webshell的通信内容是经过base64编码的,WAF必须具备解码后准确分析的能力。

测试方法很简单,在服务器上放好测试的webshell,客户端通过WAF后访问webshell,执行重要的操作,如:dir、ls、net user等系统命令;连接操作数据库;上传下载文件等。

这项测试需要收集大量常用webshell,用于覆盖常见webshell的识别。Github上有一个项目收集了各种格式的webshell,妈妈再也不担心我找不到shell啦。

Github webshell collect

一句话拦截

如果服务器安装有杀毒软件,常见webshell是可以被查杀的。大马能拦住,小马当然也不能放过。一句话木马可是杀软无力识别的。

防御一句话,其实防御的是菜刀以及各种版本的菜刀与一句话的通信。

这里要重点说两款工具:

  • cknife:项目地址,这把刀可以自定义各种通信方式和php执行函数用于绕过waf检测。实际测试下来,的确很多家waf的默认策略对自定义模式拦截无力。
  • antSword:项目地址,修改版的菜刀,也很好用。

0X06 暴力破解及其他杂项

暴力破解

WAF必须具备识别工具自动爆破密码的能力,其实判断的原理不难,分析请求某个文件的某几个参数的频率即可。用BurpSuite测一测就知道。在WAF上需要手工配置防爆破的策略,指明请求的URI、用户需要输入的参数名、访问阈值条件。

F5 ASM在判断暴力破解行为时,会判断会话有效性,造成这里有个bug,使用burpsuite爆密码时ASM根本拦不住。开了售前ticket查了半天,联系研发才闹明白是判断机制设计所致,自然也就无法修改了。

机器访问

为了防止薅羊毛,WAF必须具备能力,根据用户自定义的URI、参数名、源IP/目的IP、目的URL等条件,拦截超出正常频率的机器访问行为。

这项测试非常考验设备的自定义程度,而Imperva在自定义策略的灵活性上,遥遥领先其他友商,无愧于Gartner第一象限的位置。自定义程度越高,策略越灵活,防御效果越好,对甲方工程师的技术要求也就越高。很多传统行业的甲方工程师由于不熟悉攻防,对HTTP没研究那么深,自定义策略反而成了工作的负担。在和Imperva工程师交流时多次看到其他同行发来的邮件,询问某某场景下实现某功能,应该如何配置。我觉得如果不懂HTTP,WAF干脆就不要玩了,纯粹是给自己找负担。从白帽子的角度来说,目标网站有WAF不可怕,渗透还是要坚持的,万一对方不懂HTTP呢。

指定参数拦截

在post表单中,安全基线要求代码必须判断用户输入内容是否合理。比如,手机号一项,必须提交13/15/17/18开头的11位纯数字。如果编码时实现该需求,一行正则匹配就搞定。但是你不能保证每个程序猿都是勤奋的。所以,用WAF帮助站点实现该需求是必备功能要求。

WAF必须具备识别制定URI的指定参数,提交的数据格式。这一项也是将各厂家区分开的重要指标。

命令注入

WAF还必须具备识别命令注入攻击的能力,这一项DVWA是提供了测试功能的。之所以重点拿出来说,是因为Imperva、F5 ASM在这里都存在明显的疏漏。常见系统命令,这两家的WAF都不能在默认策略下准确识别。这一点我很奇怪,明明特征库里是有这一类特征的,可为何检出率如此低?

0X07 设备自身安全

WAF除了要保护目标网站的安全性之外,自身的安全性也不可或缺。别不信,FortiWeb的5.5.3版本就存在CSRF漏洞。国产主流的漏洞扫描产品,除了绿盟也都存在CSRF漏洞。

另外,要使用NMAP等各种工具扫描设备开放的端口,看看有没有什么服务存在已知漏洞。

第三,设备登录入口必须支持连续登录失败X次后拦截登录请求的功能,防止被爆破。

第四,设备web端会使用类似jQuery等库,而第三方库是有各种已知漏洞的,查到CVE后逐个验证下漏洞是否存在。

第四,开个WVS扫一扫页面吧,看看有没有什么明显的漏洞。

0X08 自学习

商业WAF相比自研WAF,最大的优势在于自学习功能。商业WAF拥有多项专利技术,可以根据web应用的访问行为和流量,自动学习用户正常访问行为特征,据此建立防御策略。Imperva在这方面技术领先很多,专利也最多。如果用好了自学习功能,WAF的漏过能够很大程度上的改善。

但是,凡事没有绝对。WAF的自学习功能最大的困扰是误报。Web应用的功能非常复杂,请求方式千奇百怪,机器学习算法再精妙,也不可能百分百还原所有用户正常行为。一旦误判,大量的误报拦截会让管理员叫苦不迭。

实际测试下来,个人感觉自学习功能更多时候是厂商拿来做宣传的噱头和控标的一个指标项,但是实际在生产环境中使用它,最好还是慎之又慎,就连厂商工程师都不建议使用,你敢给领导打保票背这个雷吗?

但是自学习功能并非是聋子的耳朵–摆设。自学习最大的用处其实是分析用户行为的工具。用这个功能连续监控一个月之后,哪个URL被访问次数最多,用户的请求方法与行为是什么,可以通过自动报告一览无余。有了这个报告,后续在做Web应用调优、访客行为分析、判断误报等方面还是很有用的。

0X09 第三方测试工具

除了上述各种手工测试项目,还可以使用第三方开源工具测试WAF的拦截能力。这里推荐两个工具。

第一:碳基体的测试工具:项目地址

这款工具是用perl写的,在t文件夹下已经写好了很多测试脚本,这些脚本可以把攻击payload放在http协议的各个字段提交,用于测试WAF在不同http参数的识别能力。具体用法不多说了,碳基体写的非常清楚。

这里想说两点:

  1. X-Forwared-For是很多WAF会漏过的点。
  2. 没有哪家WAF可以百分百拦截所有测试脚本。换句话说,测出来漏过的地方,需要WAF上手工配置策略,白帽子们也可以在渗透时自由发挥了。

第二:Ironbee项目:项目地址

Ironbee是一款开源waf,这个项目是测试拦截率的攻击,也是用perl写的。同样的,baseline-detection目录下的脚本,也不是默认策略可以百分百识别的。

0X10 管理与维护

WAF除了要满足低误报低漏报,还必须人性化易管理。下面的几个功能点,是从管理员角度出发测试的内容。

  • 设备操作日志:WAF的所有管理员操作必须留存日志备查。
  • 管理员权限分割:管理员必须不能删除和操作设备日志,管理与审计权限必须分立。
  • 误报后的快速例外:WAF会出现超过50%的误报,出现误报后,设备必须支持快速且简便的例外策略生成。
  • 日志包含完整http的request和response,高亮显示违规内容。
  • 日志可导出:WAF的日志必须支持以标准syslog格式导出,既可以与SIEM联动,也可以让管理员手工分析。
  • 多种形式的报表展现:包括但不限于自定义源地址、目的地址、攻击手法、规则、日期时间等条件的自由组合生成报表。
  • 流量可视化展现:统计每个站点流量、统计指定源的流量、统计点击次数,可视化展现。

0X11 写在最后

写这篇文章的初衷,绝非为某个品牌站台,或者贬损某个品牌。我在写作的过程中尽量避免带有个人感情色彩,尽量保持对品牌的中立性。任何WAF都是众多开发人员的辛苦结晶,每家都有自己独到的地方,也难免存在疏漏。希望通过甲方安全人员的和厂商研发人员的共同努力,把WAF完善的更好更易用。

受限于自己技术能力,测试方法和测试内容难免有遗漏或错误,希望读者反馈指正。

全文首发于安全客,地址请戳 很感谢360团队对我的认可。

从甲方的角度谈谈WAF测试方法--part1

网络上很多同行都发文讨论过各种绕WAF的技巧,也有很多文章分享自研WAF的思路。

作为传统行业的甲方安全工程师,我试着写一写自己在WAF选型测试时的大体思路。

一方面,是对自己完成一个项目的总结,另一方面,也算是提供一个不同的视角看看WAF,希望对乙方朋友今后设计、优化WAF产品有一点点帮助。

0X01 测试思路

环境搭建

  • 服务器:使用DVWA搭建一套包含各类漏洞的网站,并开启access日志以供分析。DVWA搭建过程不细说。
  • WAF:反向代理部署,将DVWA服务器做反向代理后映射出VS IP。测试时所有payload发送至VS
    IP,经WAF处理后交给DVWA服务器。
  • 测试方法:客户端构造payload提交给VS IP,服务器查看access日志。如被有效识别并过滤,access日志应没有相关内容。

0X02 OWASP TOP10 常规防御

SQLi

  • get型注入:http://10.44.100.18/dvwa/vulnerabilities/sqli/?id=22&Submit=Submit#
    的参数id可以注入,构造payload提交即可。
  • post型注入:DVWA登录过程用burpsuite抓包,即可构造post型注入。

XSS

  • 反射型XSS和存储型XSS在DVWA中都有,构造payload即可。

CSRF、command injection、Brute Foce、File upload等等方式,DVWA都有了,不细说。

漏掉的是SSRF、反序列化、structs、心脏滴血,这些攻击在当前版本的DVWA中是没有设计的,需要单独考虑。

0X03 绕过技术的防御

除了最常见攻击手法的防御以外,WAF还应该具备识别变形的Payload的能力。

目前国内外商业WAF可以识别99%以上的常规攻击手段,区别主要就体现在对各类编码后的变形Payload的分析能力上。

这里面又区分成了两大类思路。

思路一:

WAF抓取到HTTP包后,做多重解码,将每重解码的结果提取正则,与特征库进行匹配。各家能解码的层数会有区别。F5的ASM可以支持最多5层并且允许用户手工设定层数。其他家虽不可指定解码层数,但都具备相应能力。

思路二:

考虑到正则匹配容易误报漏报,有厂家放弃了这种分析模式,转而做语义分析。长亭科技的SqlChop就是如此,详情可阅读:SQLChop - 一个新型 SQL 注入检测引擎

在测试中,需要手工对payload做编码变形。详细说来:

SQLi变形

  • urlencode编码:别小看这种常见的绕过方法,有厂家的WAF还真检测不出来。
  • unicode编码
  • 关键字大小写替换:这个比较常规了,基本是没有检测不到的。
  • 关键字转为十六进制
  • 关键字用反引号引起来
  • 关键字用/#! #/注释引起来
  • 关键字用/##/注释截断:select转为sel/**/ect
  • 关键字用%00截断
  • 提交的HTTP包中,将x-originating-IP 改为127.0.0.1
  • 提交的HTTP包中,将X-remote-addr 改为127.0.0.1
  • SQLMAP的各类TAMPER,挨个试一试吧

XSS变形

XSS变形最多,WAF漏报也是最严重的。谁让HTML可利用的标签那么多呢。

这一块的测试,有赖于测试者平时收集各类XSS payload 的量。我仅列出一部分常见的以供参考:

<embed/src=//goo.gl/nlX0P>
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4=">
<a onmouseover="javascript:window.onerror=alert;throw 1>
<svg><script>varmyvar="YourInput";</script></svg>
<s%00c%00r%00%00ip%00t>confirm(0);</s%00c%00r%00%00ip%00t>
<script>//@cc_on!alert(1)/*@cc_on~alert(2)@*/</script>
<marquee/onstart=confirm(2)>/
<a/onmouseover[\x0b]=location=&#039;\x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3A\x61\x6C\x65\x72\x74\x28\x30\x29\x3B&#039;>XSS

文件包含绕过

data:text/plain;base64,ZGF0YTp0ZXh0L3BsYWluLDw/cGhwIHN5c3RlbSgnY2F0IC92YXIvd3d3L0ZpbGVJbmNsdWRlLnBocCcpPz4=

文件上传绕过

文件上传绕过主要考虑几个方面:

  • 123.php.123
  • 123.asp;.gif
  • as.php%00.gif
  • 文件开头添加GIF89a
  • burpsuite抓包修改Content-Type: image/jpeg

0X04 扫描器防御能力

WAF应具备根据数据包特征识别扫描器的能力,并加以阻止。常见的扫描器,如WVS、SQLMAP、Netsparker、havij、Appscan都应该拿来实际测试WAF的反应。

需要说明的一点是,WAF不仅要拦截扫描器发来的数据包,还应在日志中注明,攻击者使用何种扫描器。这对运维人员分析日志很有帮助。

例如,实际测试中,Imperva对SQLMAP和Netsparker都可以准确识别。而F5的ASM则可以准确识别WVS和SQLMAP。FortiWeb则不具备这个能力。

剩下几个章节,将讨论以下内容:

  • Webshell通信拦截测试