What is CLDAP Attack and how Monitor & Prevent !

CLDAP: 

· The Connection-less Lightweight Directory Access Protocol (CLDAP) is an alternative to the LDAP protocol from Microsoft. It is used to connect, search, and modify shared internet directories. 

· While both protocols operate on port 389, LDAP uses TCP and CLDAP works via UDP. 

· LDAP is one of the most widely used protocols for accessing username and password information in databases such as Active Directory, which is integrated into lots of online servers. An incorrectly configured Active Directory server exposes the CLDAP service to the internet. This makes it vulnerable to being exploited in DDoS attacks. 

· CLDAP DDoS can amplify traffic to 70 times its normal volume. This can lead to service outages or serve as a cover-up for other malicious activities, such as breaches of personally identifiable data.

HOW ATTACKER PERFORM DDOS ATTACK USING CLDAP: 

· The attacker would ask the CLDAP infrastructure to retrieve all the users registered in the Active Directory. Because the attacker makes this query look like it was initiated by the victim by replacing the originating IP address with the victims. 

· the CLDAP service will actually send the answer to the victim. Subsequently, the victim finds itself being bombarded with the information they did not request. If the attacker can harness enough power, the victim’s infrastructure will crash under a load of unsolicited information.

IMPLEMENTATION:

·       Step 1: Monitoring Network Traffic Speed from Task Manager. There was no operation is running still it’s amplified huge traffic in compare of its normal volume on the server.

·       Step 2: To see Server’s Traffic & For Monitoring, Download Wireshark (https://www.wireshark.org/download.html)

·       Step 3: Open Wireshark & Configured on Ethernet Network

·       Step 4: Captured Live Network Traffic Packets in Wireshark for Analyze the Traffic.

·       Step 5: Found TCP SYN Flood Attack During Network Traffic Analyzing.

1.    A SYN flood attack works by not reacting to the server with the normal ACK code. The pernicious customer can either basically not send the normal ACK, or by satirizing the source IP address in the SYN, bringing about the server to send the SYN-ACK to a distorted IP address.

2.    Look out for an immense number of TCP connection requests. The proper display filter is tcp.flags.syn == 1 and tcp.flags.ack == 0

1.    The server, that is under attack, will respond with a smaller number of SYN/ACKs. These can be spotted with the display filter tcp.flags.syn == 1 and tcp.flags.ack == 1

2.    Try to compare the number of SYNs with the number of SYN/ACKs. As long as the numbers are identical your firewall or server is holding up.

3.    Very often, the source addresses are spoofed. A good indicator of a spoofed source address is a packet with the RST bit set in response to the SYN/ACK from your server. The normal response would be a packet with just the ACK flag being set.

·       Step 6: Second Finding is CLDAP Generating Constant Traffic on Server during Packet Capturing So Analyze Those Packets.

1.    Src Port: 47893, Dst Port: 389 (CLDAP)

2.    CLDAP Packets Length is Constantly Same in Each Packets.

3.    Source IP were Different, but Destination IP were same.

PREVENTION & MITIGATION:  

•  A Solution that we did as per our project Requirement
•  Block Port & Stop Services: CLDAP Service were open for Windows Server Essential. It was not Required for our Project, so stop all active directory Services & uninstall Windows Server Essential into IIS.
•  Now unnecessary Port & services are stop so server is not responding to the malicious Services & Traffic Generating in Normal speed.
•  Most reflection methods, except DNS and NTP, do not require 389 port to be exposed.

 OTHER WAYS TO PREVENT THIS ATTACK:                                                          

·       Define an IDS rule: An alternative is to apply an ids rule, such as the snort rule. This is specific to the requests observed so far but can be adapted to a more generic LDAP search request. This rule is suitable for alerting rather than mitigating and is intended to provide an indicator of an attempt to use your systems as part of a CLDAP reflection attack.

(https://www.akamai.com/kr/ko/multimedia/documents/state-of-the-internet/cldap-threat-advisory.pdf)

·       Use stateful UDP inspections—such as reflexive access control lists—to reduce the impact to critical services on border firewalls or border routers.

·       Use a Border Gateway Protocol (BGP) to create a Remotely Triggered Blackhole, preferably in coordination with upstream providers or ISPs.

       (https://www.cisco.com/c/dam/en_us/about/security/intelligence/blackhole.pdf) 

CONCLUSION:

• Enterprises are not filtering the CLDAP (UDP port 389) on all traffic to (ingress) and from (egress) on their network.
• Service Providers (ISPs and Carriers) are not putting the CLDAP port in the Exploitable Port Filtering (some don’t have any)

•  Cloud Operator are allowing customers to create new instances with CLDAP open to the world, making each new instance a CLDAP DOS reflector with the power of the “cloud.”