How to do it...

To discover the problem, follow these steps:

  1. Start Wireshark with capture on the interface that is close to the problem:
    • If the line to the internet becomes slow, port-mirror the line
    • If a server becomes slow, port-mirror the server
    • If remote offices become slow, port-mirror the lines to them
  1. If you see that Wireshark does not respond, it is probably because you have a very strong attack that generates thousands or more packets per second; so, Wireshark (or your laptop) cannot process them. In this case, stop Wireshark (with Ctrl Alt Del in Windows, the kill command in Unix if necessary, or Force Quit in Apple Mac) and configure it to capture multiple files (described in the start capturing data section in Chapter 1, Introduction to Wireshark Version 2).
  2. There are various patterns that you might see, all of them with the same behavior—massive scanning, ICMP or TCP in most of the cases, but also other types. The best way to understand is to see them with some examples.
  3. In the following diagram, you see a network that was under attack. Users from all the remote sites complained about a very slow network. They were all accessing servers on the center on the left-hand side of the diagram.
Figure 19.4: Wireshark location—slowness at remote sites

What I got when I connected Wireshark to a remote site (as illustrated) was many ICMP requests (3) coming from the LAN 192.168.110.0 (1) to random destinations (2). Was it random?

Figure 19.5: ICMP scan to random destination

Also, look at the time between the packets. If scanned, it will usually be very short.

When you go to Statistics | Conversations, you will see something interesting:

Figure 19.6: ICMP Scan to random destination—traffic conversations

When we sort the table by address A (1), we see a pattern of ICMP requests coming from various addresses on the network 192.168.110.0 (here, we see a very small part of it, that is, 192.168.110.12 scans the network).

This worm simply scans the network with ICMP requests. The moment someone answers, the worm infects him/her also, and after a few minutes, all communication lines are blocked with ICMP requests going out of the remote offices.

Conclusion
When you see a massive number of pings scanning on a communication channel or link, that is, thousands or more pings, check for the problem. It can be the SNMP software discovering the network, but it can also be a worm that will flood your communication line or server links (or both).
  1. Another common type of scan is the TCP-SYN scan. In this case, the attacker scans random TCP ports with TCP-SYN packets, waiting for someone to answer with SYN-ACK. The moment it happens, there are two options:
    • The attacker will continue to send SYN packets and receive the SYN-ACKs, thus leaving many half-open connections on the device under attack
    • The attacker will answer with ACK, thus initiating the connection, and leave it open as in DoS/DDoS attacks or try to harm the device under attack with this connection
  1. The TCP-SYN scan will look like one of the patterns in the following screenshots:
    • You will see many SYN packets without any response from the node under attack
Figure 19.7: TCP SYN attack—no response
    • You will see many SYN packets when a TCP RST packet is sent as a response to each one of them. This is usually when you have a firewall on the device that is under attack or will be attacked.
Figure 19.8: TCP SYN attack - connection reset
    • You can also have consecutive SYN and RST packets. When there is a port number that is opened, you will see the complete SYN/SYN-ACK/ACK when the scanner opens a connection to the victim. This is illustrated in the following screenshot:
 
Figure 19.9: TCP session initiation—three-way handshake
  1. Always look for unusual traffic patterns. Too many ICMP requests, for example, are a good indication of scanning. Look for multiple ICMP requests to clients, ICMP timestamp request, ICMP in ascending or descending order, and so on. These patterns can indicate malicious scanning.
    • When you suspect a scan, click on the title of the destination (address), and you will get the packet list sorted by the destination address. In this way, it will be easier to see the scan patterns.
    • In the following screenshot, you see an example of this scenario:
Figure 19.10: ICMP requests—malicious scan
  1. In the case of application scanning, you can have various types of scans:
    • NetBIOS: This looks for massive scanning of NetBIOS ports
    • HTTP: This looks for SYN requests to HTTP port 80 with HTTP requests later on
    • SMTP: This looks for massive scanning on the TCP port 25
    • SIP: This looks for massive requests on port 5060

Other types of applications are scanned according to their port numbers

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.223.195.29