1. 概述
无连接轻量目录访问协议（Connectionless Lightweight Directory Access Protocol，CLDAP）是一种基于UDP的网络协议，用于目录服务的查询操作。与基于TCP的轻量目录访问协议（LDAP）不同，CLDAP不需要建立持久的TCP连接来进行通信。
CLDAP协议设计的目的是为了提供对目录的访问，同时避免产生目录访问协议（DAP）的资源需求，特别适合那些只需要从目录的单个条目中读取少量属性值的简单查找应用程序。CLDAP是对轻量级目录访问协议版本2（LDAPv2）的补充，在协议规范上很大程度地借鉴了LDAPv2。
2. CLDAP反射攻击
LDAPv2定义在RFC1777，由于LDAP是以TCP字节流的方式进行数据传输，其必要的绑定操作和频繁的数据搜索查询会在一定程度消耗较多的TCP连接资源，于是IETF在1995年发布了面向无连接的轻量目录访问协议（CLDAP），官方文档为RFC1798（2003年 RFC3352将CLDAP置为历史状态）。在CLDAP中只提供三种操作：searchRequest、searchResponse （searchResEntry和searchResDone）、abandonRequest，在不提供身份验证功能的情况下，客户端可以使用UDP数据报对LDAP服务器389端口发起操作请求。由于客户端发起searchRequest后服务端将返回searchResEntry和searchResDone两条应答消息，一般情况下执行该操作将具有较小数据包反射出较大数据包的效果，这一缺陷随即被利用进行反射放大DDoS攻击。
在这种DDoS攻击中，黑客向互联网上开放的服务器发送大量伪造的CLDAP请求。这些DNS服务器随后会对这些伪造的请求作出响应，向目标网络发送比攻击者最初发送的数据量多得多的数据。这种放大效应导致大量数据涌入目标网络，使其无法为合法用户提供服务。CLDAP反射DDoS攻击分为三个阶段：
- 侦察：攻击者搜索响应CLDAP请求的开放服务器的IP地址，这一步使用自动化工具完成。这些工具扫描互联网寻找易受攻击的服务器。大多数是开放的DNS解析器。
- 伪装：攻击者向开放服务器发送大量伪造的CLDAP请求，使其看起来像是请求来自目标网络。
- 放大：开放服务器响应这些伪造的请求，向目标网络发送的数据量远远超过攻击者最初发送的数据量。这种放大因子（原始请求的56-70倍）会导致大量带宽和数据涌入，压垮目标的IP基础设施。
攻击者更倾向于选择反射和放大类型的攻击载体，这种方式能够以较低的成本获得更高的攻击效果。攻击者无需自己构建和维护僵尸网络来进行DDoS攻击。他们可以利用现有的网络服务，例如CLDAP反射器、SNMP、SSDP、Chargen、Memcached和NTP等，这些服务都支持UDP协议，使得攻击者能够通过它们放大攻击流量，对目标发起规模更大的DDoS攻击。
现在已经执行了上述最低限度的三个阶段，拒绝服务攻击就很容易策划了。只需启动一个脚本，就有了开放CLDAP服务器的源IP地址。黑客有了目标端点和目标端口的受害者IP地址，现在他们可以开始他们的攻击活动。基于CLDAP的DDOS攻击的平均攻击规模从1 Gbps到60 Gbps不等。转发率在1 Mpps到30 Mpps之间，这为CLDAP提供了一个可观的放大因子。
3. 目录用户信息模型
目录服务器（更专业地称为目录服务器代理或DSA）是一种网络数据库，它存储以条目树形式表示的信息。这与使用由行和列组成的表的关系数据库不同，因此目录服务器可以被视为一种NoSQL数据库。
3.1 目录信息树
目录信息树（DIT）是一个用于组织目录信息库（DIB）中条目的树状结构。在这个树结构中，每个节点（顶点）代表一个条目，而节点之间的连接表示条目之间的关系。如果存在从条目X到条目Y的连接，X就是Y的直接上级，Y就是X的直接下级。一个条目的所有上级构成了一个层级结构，从直接上级一直到树的根；而一个条目的所有下级则构成了从该条目向下的所有后代。
条目之间的上下级关系可以用来推断它们所代表的实际对象之间的关系。DIT的结构规则定义了这些关系如何被组织和管理。一个条目的直接上级有时被称为父条目，直接下级被称为子条目。如果两个条目有相同的父条目，它们就被称为兄弟条目，这表明它们在树结构中位于同一层次上，但属于不同的分支。
3.2 条目的结构
在CLDAP中，一个条目代表目录中的一个对象，比如一个人、一个组织或一个设备。每个条目由多个属性组成，这些属性可以是用户属性，包含用户信息，如名字、电子邮件地址等；或者是操作属性，包含用于目录操作和管理的信息。
每个属性由两部分组成：属性描述和属性值。属性描述包括属性类型和选项（零个或多个）。属性选项是对属性类型的额外修饰，可以提供关于属性的更多信息，如语言选项（例如，"lang-de"表示德语）。属性通常以其属性描述来引用。属性类型决定了属性是否可以有多个值，且定义了属性值的语法和如何比较这些值。属性的两个值不能等价。如果两个值根据属性类型的等值匹配规则匹配，则它们被视为等价。如果属性类型没有定义等值匹配规则，那么两个值只有在它们完全相同的情况下才被视为等价。属性值不能有重复，且不能违反属性类型定义的匹配规则。例如，'givenName'属性可以有多个值，它们必须是目录字符串，并且是不区分大小写的。'givenName'属性不能同时包含"John"和"JOHN"，因为根据属性类型的等值匹配规则，这些是等价值。当属性用于条目的命名时，会从该属性的值中选择一个作为区分值，用于构建条目的相对区分名（RDN）。相对区分名通常由属性描述和区分值组成，例如"cn=John Smith"。
3.3 条目的命名
3.3.1 相对区分名
每个条目相对于其直接上级被命名。这个相对名称，被称为它的相对区分名（RDN），由一组无序的属性值断言（AVA，AttributeValueAssertion）组成，每个AVA由一个属性描述（零个选项）和一个属性值组成。这些AVA被选择来匹配条目的属性值（每个都是一个区分值）。一个条目的相对区分名必须在其直接上级的所有直接下级（即所有兄弟条目）中是唯一的。一个RDN可以由多个AVA组成，这种情况下称为多值RDN。例如，"CN=Kurt Zeilenga+L=Redwood Shores"包含了两个属性：常见名（CN）和地点（L）。
3.3.2区分名
条目的完全合格名称，被称为它的区分名（DN），是其RDN与其直接上级的DN的连接。CLDAP的DN由一个或多个相对可区分名称（RDN）组成。DN在整个DIT中是唯一的，它包括了从根到该条目的完整路径。以下是DN字符串表示形式的例子：
UID=nobody@example.com,DC=example,DC=com,CN=John Smith,
OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
由零个RDN组成的特殊可区分名称（因此其字符串表示只是一个空字符串）有时被称为“空DN”，它引用了一种特殊类型的条目，称为根DSE。根DSE提供了有关目录服务器内容和功能的信息。
3.4 对象类
每个Entry都是一个Object Class的一个具体实例，用来标识这个Entry是一个什么类型的对象，以及用来要求这个Entry必须具备一些什么样的属性。组织机构和人员类型的Entry在LDAP对应的Object Class就是OrganizationalUnit（组织机构）和Person（人员）。
- Object Identifier，OID：在LDAP广泛使用，唯一定义一个元素的存在，Person的OID就是2.5.6.6
- Objectclass name：可选，一个用来代替OID的名称，如person
- Description：可选，人类可读描述信息
- Objectclass Category：这个Class是什么类型的，主要分为三种：Abstract、Structural、Auxiliay。
- Must Attributes：这个Object的实例Entry必须要包含的属性
- May Attributes：这个Object的实例Entry可能包含的属性
- SuperClasses：这个Object class继承的超类
- SubClasses：这个Object class的子类
Object Category和Super Class、Sub Class这三个内容是紧密关联的：首先每个Object Class都具备一种类型，只有Structural Class才可以实例化一个Entry，然后每个Structural Class都是继承一个Abstract Class，最顶级的Class 是Top；Auxiliay Class 是辅助类，不能初始化实例，可以被继承，用来规定某些必须包含的属性。
3.5对象标识符
对象标识符（OID）是一个用来唯一标识LDAP协议中各种元素的字符串。OID由一系列数字组成，数字之间用句点分隔（例如，“1.2.840.113556.1.4.473”是表示服务器端排序请求控制的OID）。在LDAP中，OID用于标识诸如模式元素（如属性类型、对象类、语法、匹配规则等）、控制项以及扩展请求和响应。这些OID确保了无论在哪个LDAP实现中，这些元素都能被准确无误地识别。
4. BER编码
BER（Basic Encoding Rules）是一种用于描述ASN.1（Abstract Syntax Notation One）数据的编码规则，广泛用于网络协议和数据交换标准，例如SNMP和LDAP。BER编码使用TLV（Type-Length-Value）的结构方法编码，其基本结构由以下三个部分组成：类型域（Type）、长度域（Length）、内容域（Value）。其中类型域（Type）部分又有三部分组成：标签类型（Class）、构造类型（P/C）、标签号（Tag）。
4.1 类型域
在 BER编码中，类型域（Type）用于标识数据的类型和类别。类型域编码包含三个部分：类（Class）、构造类型（PC, Primitive/Constructed）、和标签号（Tag Number）。类型域结构：类型域是一个字节（8 位）或多个字节（对于较大的标签号）。第一个字节的结构如下：
第8-7位：标签类（Tag Class）
00：通用类（Universal）
01：应用类（Application）
10：上下文特定类（Context-specific）
11：私有类（Private）
第6位：构造类型（Constructed/Primitive）
0：原始类型（Primitive）
1：构造类型（Constructed）
第5-1位：标签号（Tag Number）
若标签号小于 31（即 0-30），则直接使用这些位表示标签号。若标签号大于等于 31，则这些位全为 1，并且标签号以基于共占 7 位的块形式在后续字节中表示，每个字节的最高位为 1，表示后续有更多字节；最后一个字节的最高位为 0，表示后面没有字节了。
4.2 长度域
在 BER编码中，长度域用于指示随后的值域（Value）的长度。长度域的编码有主要两种形式：短形式和长形式。下面是对这两种形式的详细说明：
- 短形式。短形式用于表示长度小于 128 字节（即 0 到 127）的情况。在这种形式中，长度域仅占一个字节。该字节的最高位（第八位）为 0，低七位表示长度的值。例如：若长度为 5，则长度域为 0000 0101（即 0x05）。若长度为 127，则长度域为 0111 1111（即 0x7F）。
- 长形式。长形式用于表示长度大于等于 128 字节的情况。在这种形式中，长度域的第一个字节的最高位（第八位）为 1，低七位表示后续长度字节的个数。例如：若长度为 128，则长度域为 1000 0001（表示后续有 1 个字节）加上 1000 0000（表示长度为 128），即 0x81 0x80。若长度为 300，则长度域为 1000 0010（表示后续有 2 个字节）加上 0000 0001 0010 1100（即 300），即 0x82 0x01 0x2C。
- 长度不确定。上述俩种情况适合用于长度确定的情况，当长度不确定的时候，长度字节最高位置1，该字节的低7位置0。紧随的字节为内容字节，最后以两个字节 0x00 和 0x00 作为结束标志。
4.3 通用标签
5. CLDAPMessage
CLDAPMessage 是CLDAP协议用于封装所有协议操作的通用结构。在CLDAP协议中，无论是客户端发送请求还是服务器返回响应，所有的通信都是通过LDAPMessage结构来完成的。MessageID、LDAPDN、SearchRequest、SearchResponse和AbandonRequest在LDAP中定义。CLDAPMessage格式由以下ASN.1定义：
CLDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
searchRequest SearchRequest,
searchResponse SEQUENCE OF SearchResponse,
abandonRequest AbandonRequest
}
}
MessageID ::= INTEGER (0 .. maxInt)- messageID：消息标识符，用于匹配请求和响应。
- protocolOp：协议操作，可以是：
- searchRequest：搜索请求。
- searchResponse：搜索响应序列，包含多个搜索结果。
- abandonRequest：放弃请求。
在 CLDAP 会话中，每个请求的消息ID 必须是唯一的。当服务器接收到一个请求并需要返回响应时，它必须在响应的 LDAPMessage 中回显（即复制）原始请求中的消息ID，以确保请求和响应能够正确匹配。
5.1 搜索请求SearchRequest
SearchRequest ::= SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2)
},
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly BOOLEAN,
filter Filter,
attributes SEQUENCE OF AttributeType
}
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeType,
approxMatch [8] AttributeValueAssertion
}- baseObject：指定了搜索操作的起始点，即搜索应该从哪个LDAP条目开始。这个条目通过LDAPDN（LDAP可区分名称）来标识。
- scope：定义了搜索的深度和广度。
- baseObject：只搜索指定的基础对象本身，不包括其下属条目。
- singleLevel：只搜索基础对象的直接下属条目，不继续深入搜索更深层次的条目。
- wholeSubtree：搜索基础对象及其所有下属条目，形成一个递归搜索。
- derefAliases：定义了在搜索过程中对别名的处理方式。定位搜索指的是确定搜索操作的起始点，即确定搜索的基础对象。
- neverDerefAliases：在搜索或定位搜索的基础对象时不解析别名。
- derefInSearching：在搜索基础对象的下属时解析别名，但在定位搜索的基础对象时不解析。
- derefFindingBaseObj：在定位搜索的基础对象时解析别名，但在搜索基础对象的下属时不解析。
- derefAlways：在搜索和定位搜索的基础对象时都解析别名。
- sizelimit：定义了搜索操作可以返回的最大条目数量。如果设置为0，表示没有数量上的限制，搜索可以返回所有匹配的条目。
- timelimit：定义了搜索操作可以持续的最长时间。如果设置为0，表示没有时间上的限制，搜索可以持续到找到所有匹配的条目为止。
- attrsOnly：是一个布尔值，用来决定搜索结果的返回内容。如果设置为TRUE，搜索结果将只包含属性的类型，不包含属性的值。这通常用于快速获取目录中条目的属性列表，而不需要获取每个属性的完整值，可以减少数据传输量。如果设置为FALSE，搜索结果将包含属性的类型和值，提供更完整的信息。
- filter：指定了搜索匹配过程中必须满足的条件。过滤器可以采用多种形式，包括但不限于相等匹配、子字符串匹配、范围匹配（大于或等于、小于或等于）和逻辑操作（AND、OR、NOT）。过滤器用于从目录中筛选出符合特定条件的条目。
- attributes：定义了搜索结果中应该返回的属性列表。如果这个列表不为空，那么搜索结果将仅包含列表中指定的属性。如果列表为空，那么搜索结果将包含每个匹配条目的所有属性。这个参数允许客户端根据需求定制返回的数据量，既可以减少网络传输的数据量，也可以提高搜索操作的效率。
5.2 搜索响应SearchResponse
在CLDAP协议中，searchResponse由一系列的SearchResponse组成。除了最后一个SearchResponse，每个SearchResponse包含一个或多个条目，每个条目代表目录中的一个记录。每个条目包含对象的属性和对应的值。最后一个SearchResponse包含操作的结果代码（resultCode）。
Search Response ::= CHOICE {
entry SEQUENCE {
objectName LDAPDN,
attributes SEQUENCE OF SEQUENCE {
AttributeType,
SET OF AttributeValue
}
},
resultCode LDAPResult
}
AttributeValueAssertion ::= SEQUENCE {
attributeType AttributeType,
attributeValue AttributeValue
}
AttributeType ::= LDAPString
AttributeValue ::= OCTET STRING收到搜索请求后，服务器将对DIT（目录信息树）进行搜索。服务器将向客户端返回一系列响应，包括：
- 零个或多个搜索响应，每个响应包含在搜索过程中找到的一个条目；
- 响应序列以一个最终的搜索响应结束，该响应包含操作结果的状态码，指示搜索成功或出现错误
AttributeType 和 AttributeValue 分别定义为 LDAPString 和 OCTET STRING。LDAPString 是LDAP协议中使用的字符串类型，OCTET STRING 是一种二进制数据类型，可以表示任意的字节序列。属性类型 AttributeType 的值通常是一个与X.500目录标准中定义的属性类型相关联的文本字符串。如果协议实现遇到一个它无法关联文本字符串的属性类型，可以替换为与属性类型关联的对象标识符的ASCII字符串编码。例如，如果协议实现无法将字符串 "organizationName" 与它关联，organizationName 属性类型可以由ASCII字符串 "2.5.4.10" 表示。（注：对象标识符OID用于唯一标识属性类型）
5.3 响应代码LDAPResult
当LDAPMessage协议数据单元（PDU）包含的操作结果太大，无法在单个UDP数据报中发送时，就会返回resultsTooLarge (70)。这个错误代码是CLDAP特有的，它与协议的无连接特性直接相关。由于CLDAP通过UDP传输数据，而UDP数据报的大小受限于网络的最大传输单元（MTU），通常为1500字节。如果目录查询的返回结果超过了这个大小限制，就无法在一个UDP数据报中完整地发送，这时CLDAP服务器将返回resultsTooLarge错误。
LDAPResult ::=
SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
isLeaf (35),
aliasDereferencingProblem (36),
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
resultsTooLarge (70),
other (80)
},
matchedDN LDAPDN,
errorMessage LDAPString
}LDAPResult是用于从服务器向客户端返回成功或失败指示的构造。在响应各种请求时，服务器将返回包含LDAPResult类型字段的响应，以指示协议操作请求的最终状态。在服务器选项下，此构造的errorMessage字段可用于返回包含文本、人类可读错误诊断的ASCII字符串。由于此错误诊断没有标准化，因此实现不应依赖于返回的值。如果服务器选择不返回文本诊断，LDAPResult类型的errorMessage字段应包含零长度字符串。
对于noSuchObject、aliasProblem、invalidDNSyntax、isLeaf和aliasDerencingProblem的resultCodes， matchedDN字段设置为DIT中匹配的最低条目（对象或别名）的名称，并且是所提供名称的截断形式，或者如果别名已被取消引用，则是结果名称的截断格式。在所有其他情况下，matchedDN字段应设置为NULL DN（零长度字符串）。
5.4 编码优化
CLDAP协议允许在searchResponse中使用尾随的星号（*）字符来简化对象名称（objectName）的表示。当响应中的objectName与请求中的baseObject相同，可以使用尾随星号来代替完整的DN（Distinguished Name）字符串。假设我们发出了一个搜索请求，想要查找在目录中的基本对象"o=UofM, c=US"下的所有条目。搜索请求如下：
SearchRequest:
baseObject: o=UofM, c=US接收到搜索请求后，目录服务可能会找到多个条目，每个条目都有不同的通用名称（cn）但共享相同的组织（o）和国家（c）部分。如果使用尾随星号优化，响应如下：
SearchResponse:
Entry:
ObjectName: cn=Babs Jensen, *
Attributes:
cn: Babs Jensen
otherAttribute: otherValue
扫一扫
3226
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
