安全运营之告警如何区分自己人
文摘
科技
2024-09-13 13:39
美国
“A9 Team 甲方攻防团队，成员来自某证券、微步、青藤、长亭、安全狗等公司。成员能力涉及安全运营、威胁情报、攻防对抗、渗透测试、数据安全、安全产品开发等领域，持续分享安全运营和攻防的思考和实践。”
安全运营小伙伴可能都遇到过这样的情况，安全系统突然出现大量告警，看告警详情信息真真切切，凭感觉就是有攻击者在搞事情，于是立马启动应急响应，进入紧急状态，查询源目IP信息，电话联系相关人员开启三连问：这是什么系统，目前有做什么操作，能不能临时停用。最后一顿操作猛如虎，发现攻击者是安全测试人员，原来小丑是自己。聪明的小伙伴可能想到了，使用一台代理服务器便可以解决上面问题，让负责安全测试的同学都使用代理服务器进行测试，这样大家出口为统一IP，出现明显攻击告警后只要源IP为代理服务器，就不用太担心，大概率为自己人测试。
但经过一段时间的使用后，发现存在这样一种情况，有些系统是使用前后端分离构架或使用容器部署，请求的流量会在各个服务器/节点间相互转发，最后体现在告警设备的信息上就是前端服务器对后端服务器进行了攻击，或者是一个节点对另外一个节点进行攻击。
这种情况处理起来就比较头疼了。攻击源和目标都是应用系统或者容器平台的地址，要确认攻击者是不是自己人，就得拿具体被攻击站点名称、路径与安全测试的同学确认，但很多时候攻击请求是程序或脚本自动发送，安全测试人员拿到信息后也需要做一些分析才能确认，如果这个时候安全测试同学测了多个站点，确认起来就更加困难。基于上面的场景，笔者尝试自己编写socks5代理程序，请求流量经过代理程序，程序识别请求为http或https，会自动在包中插入事先设定的请求头，这样在查看告警信息的请求数据时，可以第一时间确认攻击包是通过代理程序发出，并且可以快速定位安全测试人员的IP，效果如下：![]()
工具使用C#编写，需要依赖于.net环境，支持windows和linux系统。
环境安装，访问https://aka.ms/dotnet-core-applaunch，下载对应操作系统的.net包，这里推荐使用.net 8.0。
windows系统直接跟着提示下一步安装完成即可运行，linux需要解压环境包，配置环境变量，命令如下：
tar -zxvf dotnet-sdk-8.0.203-linux-x64.tar.gz -C /opt/dotnet/chmod +x /opt/dotnet/dotnet/opt/dotnet/dotnet --version8.0.203vim /etc/bash.bashrcexport DOTNET_ROOT=/opt/dotnet/export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/toolssource /etc/bash.bashrcdotnet
Usage: dotnet [options]Usage: dotnet [path-to-application]
Options: -h|--help Display help. --info Display .NET information. --list-sdks Display the installed SDKs. --list-runtimes Display the installed runtimes.
path-to-application: The path to an application .dll file to execute.
做好上面环境配置后，运行代理程序，根据提示进行设置。
![]()
这里有一个细节需要注意，如果我们要解析https请求需要自定义证书，证书格式为.pfx，将证书保存到程序目录，并命名为cert.pfx，证书密码设置为xiaobaogua。
证书可以通过BurpSuite导出，操作如下图。
![]()
![]()
当代理程序运行后，我们只需要将BurpSuite的代理配置为程序代理，这样所有经过的流量请求就会被记录，并且会在包中添加请求头。
![]()
请求记录
![]()
请求头信息
![]()
工具链接放下面了，使用过程中有问题或建议可以通过邮箱和笔者联系。
https://github.com/xbaogua/BaoGuaSocks5ProxyServer
这里特别说明下，使用windows控制台程序偶尔会出现程序被暂停的情况，这是windows的问题笔者解决不了，可以尝试关闭cmd的快速编辑模式，情况会有所缓解，推荐在linux环境下运行。
另外，在编写程序过程中学习到的一些相关知识，与大家分享：
1.Socks5只是对请求进行转发，并不会对转发的数据进行加密，通信安全性依赖于被转发协议自身，Socks5适合在本机或者局域网使用，不建议公网使用。2.Socks5认证没有类似持续会话的机制，而是在每次请求时带上账号和密码，且账号密码是明文形式，抓到流量包就能看到使用的账号和密码。Socks5认证定义如下：
![]()
https://datatracker.ietf.org/doc/html/rfc1929
使用wireshark抓包可查账号密码
在服务器设置账号密码
![]()
使用错误密码尝试
![]()
使用正确密码
![]()
查看抓包情况
![]()
![]()
3.https也会泄漏访问站点的域名信息。聪明的小伙伴可能会想，Socks5协议的传输是明文的，如果使用加密的https协议是不是就安全了呢，其实不然，在这个通信过程中，至少有两个点会泄漏出你访问的站点信息，第一：Socks5转发流量时，代理端会对请求的域名进行解析得到对应的IP地址后才能进行访问，也就是代理服务器能知道你访问的站点域名；第二：在https通信过程中，存在一个SNI（Server Name Indication）机制，简单来说就是一个web站点可能会有多个域名的情况，每个域名会有不同的证书，如果直接加密通信服务器并不知道应该使用哪套证书进行加解密通信，所以需要通过SNI机制告诉服务器你要访问哪个域名，之后才能进行加密通信。简单理解为告诉服务器你要访问域名的过程就是SNI，这个过程是明文通信，也就是通信流量中可以看到你所请求的站点域名信息，这也是为啥明明访问的是https站点，上网行为类的管理系统也能对访问进行控制的原因。
4.关于web服务端接收到的奇怪请求，其实是https的握手包。如下：![]()
使用Socks5代理后，在服务端发现有一些奇怪的请求，笔者曾经在公司的WAF上也发现过类似的请求，当时领导问对方是在做什么利用，为何会发出这样的请求。笔者也是一脸困惑。现在自己编写程序后才恍然大悟，这些请求实际上是https的握手请求。原因是这样：客户端发起web站点请求后，流量给到代理后端，但是代理端只知道目标IP和端口以及需要发送给对方的数据包。如果不对数据包进行解析，代理端直接向目标发送这个数据包就可以了，但如果涉及代理端要对数据包进行解析，它就需要知道你请求的是http还是https（因为会涉及加解密），那代理端怎么知道呢？虽然请求时写明了是http://或者是https://，但这个协议是给浏览器看的，在流量侧都只是数据包。当代理端对数据包进行解析时，会出现比较尴尬的情况，程序处理网络流时只能往后面读取不能往前读取，如果读取数据包是http还好，直接转发处理就可以，但如果读取部分数据后，发现是https协议，就得将整个数据包解密后再读取，但是现在已经读取了一部分数据，怎么将这个读取的数据回退呢，这里就比较复杂了，笔者经过一顿折腾后并不能很好解决这个网络流的问题（也可能是笔者方法问题），于是找到一个更为简单方便的办法，通过服务端推断客户端发起是http还是https请求。过程是这样，客户端发起请求，代理端收到请求后并不会立马读取，而是先向服务端发起一个握手请求，如果握手成功说明客户端是https请求，就按照https流进行加解密处理；反之如果握手不成功，则认为是http请求，按http请求进行处理。
