Ayoi's

OK, this is the second part of the previous post here.

For security monitoring, the most important factor is HUMAN factor. Without a knowledgeable and skillful analyst who can give appropriate dissection on the output presented to them by the tools, the detection process will definitely failed on Identification process level. If they failed to provide any useful context on the output or indicator produced, then how can they produce appropriate warning? It doesn’t matter how advance the application will be, how comprehensive the guidelines prepared because at the end of the day, these analysts failed to understand what are they looking at, what actually happened and what are the appropriate reactions needed.

According to one of NSM’s Principles;

“Indicators are collected and analyzed where Products perform collection because people need assistance in interpreting the network traffics. People will perform analysis as product or tool will only provides outputs or conclusions about the traffics but PEOPLE will provide context based on the situation and network environment.” Unless we have super intelligent tools that can replace human decision making and intuition, then this statement remains true.

Like the previous post, I’ve provided a simple example of using wireshark. Again I will use this example again..

The KEY point here is simple, IF you know what you are looking for, where to look and consequently understands what are being presented to you by the tools (the outputs) then you might have no or less complaints on using that tool.

From the information presented by the wireshark, we know that SYN Flood attack occurred. From the general view we know that the attacks source seem like from many hosts to 192.168.2.127. We also know that the targeted port is increasing from each packet came from these hosts. Agree? But you might say that due to the increasing destination port (increment by 1), perhaps the source hosts are performing NMAP -sS scanning?

Well the TCP control flags involved in those two type of traffics (SYN Flood and Nmap -sS) might be the same (SYN Flag) but the objective is totally different. Scanning or reconnaissance is the act of information gathering meaning that when you sending some request, you want to know the reply. In Nmap -sS case, when you send a SYN packet to a machine at specific port, you want to know whether the service that using the port is running or not based on the response given by the targeted machine. A SYN + ACK flagged response will indicates the service via the targeted port is available while a RST + ACK shows otherwise.

As Example  (This scanning is targeted to closed https port):

ayoi# nmap -sS 192.168.2.126 -p 443

Starting Nmap 4.52 ( http://insecure.org ) at 2008-05-02 22:01 MYT
Interesting ports on 192.168.2.126:
PORT    STATE  SERVICE
443/tcp closed https
MAC Address: 00:1E:C9:BA:E0:8E (Dell)

And the packets will be

22:01:55.144824 IP 192.168.2.7.47264 > 192.168.2.126.443: S 3725734349:3725734349(0) win 3072 <mss 1460>
22:01:55.145338 IP 192.168.2.126.443 > 192.168.2.7.47264: R 0:0(0) ack 3725734350 win 0
22:01:55.246070 IP 192.168.2.7.47265 > 192.168.2.126.443: S 3725799884:3725799884(0) win 2048 <mss 1460>
22:01:55.246394 IP 192.168.2.126.443 > 192.168.2.7.47265: R 0:0(0) ack 3725799885 win 0

Note the Bold ones. Btw how on earth that NMAP knows that 192.168.2.126 is using DELL NIC? Of cause based on the first 3 bytes of the MAC Address. For MAC Address, the first 3 bytes belongs to Manufacturer.

Ok proceed with the open port scanning result (MSSQL port)

ayoi# nmap -sS 192.168.2.126 -p 1433

Nmap done: 1 IP address (1 host up) scanned in 0.818 seconds

Let see the packets generated by this activity

22:07:26.614121 IP 192.168.2.7.39401 > 192.168.2.126.1433: S 2210806291:2210806291(0) win 4096 <mss 1460>
22:07:26.614298 IP 192.168.2.126.1433 > 192.168.2.7.39401: S 1072455176:1072455176(0) ack 2210806292 win 16384 <mss 1460>
22:07:26.614312 IP 192.168.2.7.39401 > 192.168.2.126.1433: R 2210806292:2210806292(0) win 0

So by this kind of responses then you know which port or services is available and which is not.

As for SYN Flood attacks, you definitely do not want any response from the targeted machine. Your main purpose is to brought down the machine or any services that running on that particular machine. So the wise way is to send many SYN flagged packets to the targeted machine with spoof IPs as the sender. Meaning the targeted machine will reply to non-existence hosts. Agree?

Back to the packet captured shown in the wireshark, based on the Layer 2 information also we can identify that those spoof IPs are coming from one source. Take note on the MAC address, for each packet will have different source IP but same source MAC address.

OK, the packets shown below not exactly taken from wireshark, I used Windump (too lazy to do screen capture and photoshop editing)

12:31:05.298444 00:0c:29:f3:a6:39 > 00:16:d3:06:6f:0e, ethertype IPv4 (0×0800), length 54: 138.248.102.217.2898 > 192.168.2.127.4: S 1224680571:1224680571(0) win 512
0×0000:  0016 d306 6f0e 000c 29f3 a639 0800 4500
0×0010:  0028 4688 0000 4006 7f4f 8af8 66d9 c0a8
0×0020:  027f 0b52 0004 48ff 247b 66b4 2cad 5002
0×0030:  0200 ecb7 0000
12:31:06.299688 00:0c:29:f3:a6:39 > 00:16:d3:06:6f:0e, ethertype IPv4 (0×0800), length 54: 75.4.79.22.2899 > 192.168.2.127.5: S 937274104:937274104(0) win 512
0×0000:  0016 d306 6f0e 000c 29f3 a639 0800 4500
0×0010:  0028 592a 0000 4006 c464 4b04 4f16 c0a8
0×0020:  027f 0b53 0005 37dd aaf8 3a03 9c6f 5002
0×0030:  0200 8c00 0000
12:31:07.301244 00:0c:29:f3:a6:39 > 00:16:d3:06:6f:0e, ethertype IPv4 (0×0800), length 54: 222.140.18.61.2900 > 192.168.2.127.6: S 725808845:725808845(0) win 512
0×0000:  0016 d306 6f0e 000c 29f3 a639 0800 4500
0×0010:  0028 8fb7 0000 4006 3728 de8c 123d c0a8
0×0020:  027f 0b54 0006 2b42 f6cd 3959 22eb 5002
0×0030:  0200 7043 0000
12:31:08.302673 00:0c:29:f3:a6:39 > 00:16:d3:06:6f:0e, ethertype IPv4 (0×0800), length 54: 107.230.246.46.2901 > 192.168.2.127.7: S 382745863:382745863(0) win 512
0×0000:  0016 d306 6f0e 000c 29f3 a639 0800 4500
0×0010:  0028 3fdf 0000 4006 15b5 6be6 f62e c0a8
0×0020:  027f 0b55 0007 16d0 3d07 4156 a244 5002

SO again, it doesn’t matter what kind of tools or applications that you are using, but the most important thing is you understand and know how to give a proper dissection on the information presented. Once you know what, when, How, why to give proper analysis, the relevance information needed then you can start demanding or perhaps insisting on having the rite tools to give you the right information in performing your tasks. Not just a mere guidelines.

We had a lively discussion yesterday. Yeah quite lively. Topics ranging from issue on the application and tools that we use up to the macro things like the basic security knowledge/understanding etc. One of the issues is most of the SA found that the current tools that they use are not user friendly, too cumbersome, not too helpful and yeah, lack of guidelines on how to use those tools…

Regarding this guidelines, I have to admit that we are suppose to have some simple documented guideline on the usage of the application (besides the overall process of Detection and also perhaps IRH) but after a while then I realized that some of the SA actually did not want those kind of guidelines. What they wanted is how to perform the analysis or Identification process (based on the feedbacks that I’ve received from some of them) And yes, I do remember that during my time at The Client site, I was asked by The Client to prepare some SOPs on how to analyze security events (Fascinating huh). I told them what I could do is just to prepare some general guidelines and even I stated in those manuals or SOPs that by no means that those guidelines and SOPs will be a definite one. If I could produce what The Client wanted, I might as well should write a book on how to be a Security Analyst. Sigh

Anyway, one of my colleague point out one good point. He said that this is not a case of SA being overwhelmed or confused by the tools and application interface but merely they want some guidelines like the ones that I prepared for The Client (or sort of – But based on their spoon-fed attitude, no surprise). So my colleague did mention that the current application and tools allow the analyst to see or to perform their analysis from different angles and views. Meaning the Analysts should or must know what to find, when to start investigate, what kind of information needed, where to find that kind of information and also HOW to make use of the application or tools’ features in order to perform their identification process.

Like sguil, ethereal, wireshark, OSSIM etc only have guides on how to make use of the application’s features but none on HOW to perform your analysis (of cause). It seems like most of these SAs failed to grep the fundamental knowledge that these application merely assisting them to perform their analysis and not the other way around. Let me put this wireshark example..

Ok I purposely disable the coloring rule for this packet capture file. By default, for anyone who use this tool must know the features or capabilities that wireshark offers and also he or she knows what to find/look and plus understand on the information presented to them by the wireshark (where in this case protocols).

IF you dun have such knowledge then I believe:

a). You will say that this tool is too cumbersome, not user friendly etc

b). You might as well complaint to the seniors that this tool is not suitable for your usage.

c). IF this tool is mandatory for u to use, then you will crying for guidelines (in this case even the wireshark help file will be deemed not that helpful) because actually you want a guideline on how to digest or understand the information presented.

I think I have to stop now. Wait for part two…