You probably wonder why that could be a big deal. Usually clients not doing LDAPs are the ones we worry about (for security reasons, simple binds over LDAP aren't your best friends). Yet I have been facing situations where we need to identify who is doing LDAPs. Here is the scenario I have been seeing a couple of times:
What do we have to track them down by default?
We can enable the SChannel logging. It will tell us that the TLS handshake went well but it does not tell us about who is doing this handshakeWe can enable the 16 LDAP Interface Events. It will generate an event for each of the LDAP or LDAPs binds and searches but nothing about the sources of the calls.We can enable the security audit and parse the incoming successful connections, and crosscheck that information with LDAP events... It's a pain and it does not even tell us if it is LDAP or LDAPs.Since Windows Server 2008 we have the possibility to run a network capture out of the box with netsh. But there is no filter and it might impact the overall performance of the server. Moreover, the server in our case is a domain controller. So we'd better be sure we are not bringing it down.
What can we do?
One possibility (and this is the one explored in this post) is to use Network Monitor to run a capture with a custom configuration to reduce the performance impact. What are the performance issues we can have?- it uses CPU cycles to filter the capture- it uses CPU cycles to parse the capture in real time- it uses memory to put the stream from the wire to the buffer- it uses disk IO to write what we capture into a fileTo address these, we will:- create a custom parser to minimize the memory- run it in command line using nmcap and disabling some options to reduce the footprint- limit the capture to the first few bytes to reduce the disk and memory usage
Create a custom parser (taken from http://blogs.technet.com/b/netmon/archive/2010/01/04/capturing-a-trace-a-boot-up.aspx)
Create a folder like C:\LDAPs
In that folder, create a text file called sparser.npl with the exact following content:
This parser is the simplest ever. Basically it does not do any sort of analysis, instead it just enables us to make filter based on the presence of a specific group of bytes at a specific offset of the frame. To make Netmon use this parser, simply run the following command:
In case of success you should see the following output:
If not, review the syntax of your file sparser.npl or maybe the path you are specifying.
Run nmcap with some custom parameters
Now that we have our custom parser, we cannot filter the incoming traffic based on the classic syntax. The only filter we can do is with: Stuff(FrameData, <offset>, <length>). So if we want to capture only the LDAPs traffic, it means we need to know what is the position of the port used by LDAPs in the FrameData. What, you don't know your TCP/IP offsets by heart? Well, who does, maybe my network professor back in school day? (well I'm actually sure he does) Let's open a network trace with some LDAPs traffic and look what we have and in which position (offset).
It's a TCP Syn message. No need to capture further. We actually do not really care if the domain controller will send back a SYN ACK or not, we are just interested in the incoming traffic. The offset information we need are:
So if we want to catch all incoming LDAPs connections in our domain controllers we need:
Here comes our optimized filter: ( Stuff( FrameData, 30, 4 ) == 0x0a000001 and Stuff( FrameData, 47, 1 ) == 0x02 and ( Stuff( FrameData, 36, 2 ) == 0x027c or Stuff( FrameData, 36, 2 ) == 0x0cc5) )What else we will use:
Here is the final command:
And here is the output:
Once you are fed up, just hit [Ctrl] + [C]. This is the actual way to stop the capture, do not worry about the file, it will contain everything and won't get corrupted.
And now what?
Now we have the list of all IPs which are doing LDAPs with this specific DC during the capture. How can we easily extract them? We have two simple ways:
Another way would be to use LogParser available here: http://www.microsoft.com/en-us/download/confirmation.aspx?id=24659. LogParser has a feature that parses the .cap files and generates other export format such as CSV. Unfortunately, because we truncated the frame LogParser will not do the job.
Now we have a list of IP addresses and we have to contact the owner of the server or check ourselves what is happening on those machines and how they handle the LDAPs.