AD域控服务器问题解决记录--lsass.exe流量异常

AD域控服务器问题解决记录–lsass.exe流量异常

前序

公司对技术部门要求做AD域控的计划，在落实这个计划的过程中，会碰到一些奇奇怪怪的问题，再解决问题后，记录一下过程和事后的感受。

出现

在落实域控的过程中，由于技术部门的资产中，有一部分在云上，一部分在本地机房，为了实现统一的LDAP管理，通过一些标准的AD域控接口和插件来实现登陆时的账户和密码验证。于是，在本地防火墙上，对域控服务器AD-1的389端口做了外网映射，以便云端通过这个端口来进行AD验证。
在一两天后，每天下午，测试部门的伙伴开始在群里说，云上jenkins无法拉取本地svn代码编译。由于服务器线路和办公线路网络时分开的。所以在办公区域浏览网页什么的都没有什么感觉。但是服务器上通过PING百度等都延迟相当高，甚至会未响应。通过观察，早上的服务器网络都是正常的。一到下午2点之后，服务器网络就开始高延迟。

排查

首先，怀疑时运营商问题。之前有段时间，运营商把我们服务器的固定IP网络拉到他们内网去了，所以跨网访问延迟有点高。但是云端设备的网络时混合网络接入，应该不是运营商的锅。
在防火墙上，看流量监控。发现，排行ip流量第一的就是AD-1。每天跑4-5T的流量。通过观察，域控服务器每日早上的数据流量正常，最高也就200Kbps，大部分时间是0-10Kbps波动，一到下午，开始出现1-6Mbps，而且是持续长时间。在关闭了AD-1后，发现每日下午的服务器网络高延迟不见了。云端设备连接本地资源都正常了。那基本能确定是这台AD-1的锅了。
AD-1系统是新装的，没有装太多软件。就安装了Azure的AzureADConnect用于Azure和本地AD的同步。难道是同步流量？
通过同步的两个服务，进行跟踪，

AzureADConnectHealthSyncInsights
AzureADConnectHealthSyncMonitor

找到监控端口的同步客户端，经过以断时间的观察，流量是正常的。即使每个小时同步的时候，实际流量都是非常小，不影响整个网络的使用。

名称	PID	本地地址	本地端口	远程地址	远程端口	数据包丢失 (%)	延迟时间 (ms)
Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup.exe	1076	192.168.1.231	54379	40.116.232.96	443	-	-

通过资源监视器中，网络活动的排序，找到几个活动量最大的，一排序，都是同一个程序，唯一的区别就是远程地址不同，一直在对外发送数据。

名称	PID	地址	发送(字节/秒)	接收(字节/秒)	总数(字节/秒)
lsass.exe	644	169.235.24.133	14802	184	3320876
lsass.exe	644	153.19.50.62	23256	125	2532345
lsass.exe	644	41.210.252.16	14532	57	1013212
lsass.exe	644	129.107.60.14	6435	5	101232

所以lsass.exe这货疯狂上传数据，才是导致整个服务器网络阻塞的最大凶手了？
那我是不是结束这个进程就可以让网络恢复呢？
然而，结束完后，系统就重启了。。。

解决

Local Security Authority Subsystem Service
本地安全机构子系统服务（LSASS）是Microsoft Windows 操作系统中的一个过程，负责在系统上实施安全策略。它验证登录到Windows计算机或服务器的用户，处理密码更改并创建访问令牌。[1]它还写入Windows安全日志。
强制终止lsass.exe将导致“欢迎”屏幕丢失其帐户，从而提示重新启动计算机。
由于lsass.exe是至关重要的系统文件，因此其名称经常被恶意软件伪造。Windows使用的lsass.exe文件位于目录中 %WINDIR%\System32。如果从任何其他位置运行，则lsass.exe很可能是病毒，间谍软件，特洛伊木马或蠕虫。由于某些系统显示字体的方式，恶意开发人员可能会将该文件命名为Isass.exe（大写的“ I”而不是小写的“ l”），以诱使用户安装或执行恶意文件而不是受信任的系统。文件。

难道是病毒？可是通过一系列检查都没有发现lsass程序被感染。在找到问题发生源，但是没有找出实际发生问题的原因时，以先处理当前故障恢复生产为第一准则。在没办法永久结束进程的时候，通过服务器内安全软件的进程限速和防火墙的IP限速，先把AD-1这台的数据上传量控制下来。降速下来后，网络恢复了正常。但是连接域控的其他域内用户出现了登陆缓慢等跟域通信有关的问题。这是为何呢？
如上面解释的，lsass负责验证登陆到windows计算机或服务器的用户,而域用户登陆也是通过这个程序和域控服务器进行通信验证。但是即使lsass被我限速了，它还是满速在上传数据，还是影响了其他用户使用lsass。
那我是否可以限制只有本地用户可以使用访问lsass.exe.在服务器系统防火墙上，看到涉及到lsass.exe进程的项目有

于是在每个对应规则中，常规-选择了只允许安全操作

远程计算机-添加了Domain Users.只允许域控用户连接。

在暂时恢复后，某个周末，公司都没有人使用网络的时候，我重新取消了所有的限制，然后用Wireshark进行抓包分析。
发现通过筛选，指向莫名IP的数据包，都是通过CLDAP协议，进行search ROOT

这又是什么鬼协议。看起来好像跟LDAP有一毛钱关系呀。

Connection-less Lightweight Directory Access Protocol
无连接轻量目录访问协议（CLDAP）
使用LDAP版本3 [1]涉及正常的TCP / IP连接设置对于某些应用程序可能构成不希望的开销，特别是在只有未经身份验证的请求执行。通常用于快速轻量级只读必须将等待时间降至最低的客户端或向多个LDAP服务器发出大量请求。

以上是tools.ietf.org里关于CLDAP的原理。表示没看懂。就看到了最后几个字，大量请求。敲黑板，划重点了，必考题。
这是链接： CLDAP
于是，搜索走一波科普。于是作案凶手，就浮出了水面。

CLDAP DRDoS

轻量目录访问协议（LDAP）被定义在RFC2251（LDAPv3）中，由于LDAP是以TCP字节流的方式进行数据传输，其必要的绑定操作和频繁的数据搜索查询会在一定程度消耗较多的TCP连接资源，于是IETF在1995年发布了面向无连接的轻量目录访问协议（CLDAP），官方文档为RFC1798（2003年RFC3352将CLDAP置为历史状态）。在CLDAP中只提供三种操作：searchRequest、searchResponse （searchResEntry和searchResDone）、abandonRequest，在不提供身份验证功能的情况下，客户端可以使用UDP数据报对LDAP服务器389端口发起操作请求。由于客户端发起searchRequest后服务端将返回searchResEntry和searchResDone两条应答消息，一般情况下执行该操作将具有较小数据包反射出较大数据包的效果，这一缺陷随即被利用进行反射放大DDoS攻击。

根据Akamai SIRT发布的报告，目前捕获到的CLDAP DRDoS最高峰值流量为24Gbps，最大反射倍数为70倍。由于CLDAP未被广泛运用，开源LDAP软件openLDAP早已不再支持UDP协议的请求。事实上，目前进行CLDAP DRDoS攻击被利用最多的服务是Windows服务器的活动目录服务Active Directory（AD）。通常AD服务会在TCP端口389上监听来自客户端的LDAP操作请求，同时也会在UDP端口389上使用CLDAP协议来等待执行rootDSE的搜索操作（rootDSE条目在AD服务配置时创建，且允许未经身份验证的客户端对服务器的配置状态、功能和扩展属性进行查询，也被称作“AD ping”）。一些Windows服务器的AD服务监听端口暴露在公网，进而被利用来执行rootDSE查询产生放大反射DDoS攻击

重点：
389端口
反射较大数据包
rootDSE
端口暴露公网
是不是跟之前排查到的都能一一对上了。
于是我关闭了映射到外网的389端口。而服务器上防护都撤除。巨大的流量上传戛然而止。目前，由于云端的AD同步插件写死了389端口为同步，所以不开放389，就意味着无法让云端设备和本地域控做验证。而防护这个攻击除了不暴露外网端口一个办法外，还有就是我之前使用的客户端白名单。由于公司的防火墙太低端，无法做端口上的白名单访问。而我之前使用服务器上做白名单又影响其他域控用户验证。只好关闭外网端口。那么新的问题又出现了，如何让云端设备也能向本地域控服务器做LDAP验证。

待续