In my last post I discussed an idle scan and how it can permit an attacker to mask their IP address during a port scan. In this installment we'll look at some traces, as well as discuss how to identify when an idle scan has been used against your network.
Suivi de l'incrémentation IP ID
Commençons par regarder les paquets qui ont été suivi le champ ID IP sur le système Windows. Here is what our probe packet looked like:
07:22:15.367140 IP (tos 0×0, ttl 64, id 63897, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.1.2203 > 192.168.100.2.0: ., cksum 0xeca2 (correct), win 512
A few of these fields are kind of interesting. La valeur TTL est configuré à "64", ce qui suggère un système Linux ou UNIX. Since we are raw writing the packet directly to the wire this value is actually controlled by hping. 64 just happen to be the program default, but we could change the value to anything we wish with the “-t” switch.
The target address is printed as “192.168.100.2.0”, which means the packet was sent to TCP port 0 at IP address 192.168.100.2. Windows does not offer services on TCP port 0 but that's OK. We're not actually trying to connect to the Windows system. We just need it to send us an IP packet so we can check the IP ID value. Si nous voulions frapper un port différent, nous pourrions utiliser hping de "-p" commutateur.
The “.,” after the target specification means that no TCP flags were set within the packet. This is referred to as a null packet and would never occur during normal IP communications. For this reason, may NIDS, NIPS and firewalls will flag it. Nous avons créé un paquet nulle parce que nous n'avons pas dire hping d'envoyé l'un des drapeaux TCP. Par exemple en ajoutant l'option "-S" interrupteur aurait allumé le drapeau SYN, «-A» serait son tour sur le drapeau de reconnaissance, et ainsi de suite.
All of our probe packets to the Windows systems would look similar to this one. Les seules valeurs qui allait changer l'horodatage sont (évidemment), le port TCP source et la valeur du CRC checksum.
Voici ce que les réponses ressemblent à revenir à partir du système Windows:
07:22:15.367296 IP (TOS 0 × 0, ttl 128, id 108, offset 0, flags [none], proto TCP (6), longueur 40) 192.168.100.2.0> 192.168.100.1.2203: R, cksum 0xc431 (correct), 00h00 (0) ack 918250228 win 0
07:22:16.367453 IP (tos 0×0, ttl 128, id 109, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.2.0 > 192.168.100.1.2204: R, cksum 0xfa78 (correct), 0:0(0) ack 2127488152 win 0
07:22:17.367763 IP (TOS 0 × 0, ttl 128, id 110, offset 0, flags [none], proto TCP (6), longueur 40) 192.168.100.2.0> 192.168.100.1.2205: R, cksum 0x2b9f (correct), 00h00 (0) ack 1611256374 win 0
La valeur importante ici est l'ID IP, identifié comme "id". In the first packet it is set to 108, and then the value increments by +1 for each subsequent packet (109 then 110). As long as we continue to see an uninterrupted sequence in the IP ID, we know the Windows system is not transmitting any other packets except the ones that are part of this session.
Sonder un port fermé
Remember that as part of our scan, we will be spoofing the source IP address of the Windows system when target ports on a remote system. A change in the IP ID increment is what tells us we found an open port.
Let's take a look at one of these can packets:
10:30:28.852602 IP (tos 0×0, ttl 64, id 41256, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.2.1266 > 192.168.100.3.79: S, cksum 0x97a6 (correct), 1704542340:1704542340(0) win 512
Note the source IP address is that of the Windows system (192.168.100.2). Nous savons que cela ne pouvait pas venir du système Windows Mais parce que le TTL est fixé à 64 ans. So this is a packet we generated from 192.168.100.1 using a second instance of hping.
Also note we have targeted TCP port 79 and have turned on the SYN flag. Here is the response we received from the remote target:
10:30:28.852839 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.100.3.79 > 192.168.100.2.1266: R, cksum 0xbb1a (correct), 0:0(0) ack 1704542341 win 0
Note the “R” value that tells us the reset flag was turned on in the TCP header. Nous voyons aussi «ack» qui nous indique le flag d'acquittement a été allumé aussi. This is an error packet informing the source that the TCP port is in a closed state. Also note the packet is being transmitted to the Windows system since that was the source IP address in the probe packet.
So how will the Windows system respond? You may remember from my last post that the RFCs state you should never respond to an error packet. Even though the Windows system has no idea what the target is talking about, it will quietly discard this error packet. En d'autres termes, le système Windows ne sera pas envoyer une réponse. This means we should see no change in the IP ID increment.
Probing an open port
Now let's take a look at what happens when we target a port that is actually in an open state. Here's the probe packet. Note it is pretty similar to the last one, except now we are checking TCP port 80.
10:29:46.947964 IP (tos 0×0, ttl 64, id 15249, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.2.1984 > 192.168.100.3.80: S, cksum 0x476b (correct), 947341260:947341260(0) win 512
Here is the response from the target. Note that we see an “S” instead of an “R” which means they SYN flag is turned on rather than the reset flag. This is the targets way of informing the source that TCP port 80 is open and has an application sitting behind it servicing connections.
10:29:46.953333 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44) 192.168.100.3.80 > 192.168.100.2.1984: S, cksum 0x0de6 (correct), 262246932:262246932(0) ack 947341261 win 5840 <mss 1460>
So this time the Windows system receives a packet saying “Sure, you can connect to TCP port 80”. This is a problem for the Windows system because it has no connection entry saying that it actually tried to connect to port 80 on the target. Without the connection entry, Windows has no way of knowing which application requested the session. Dans cet esprit, il ne la seule chose qu'il peut faire; transmettre un paquet de réinitialisation à la cible de tuer la session. Here is what the packet looked like:
10:29:46.953439 IP (tos 0×0, ttl 128, id 176, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.2.1984 > 192.168.100.3.80: R, cksum 0x5df1 (correct), 947341261:947341261(0) win 0
Note that Windows stamped the next available IP ID in the IP header (176). So had we been monitoring the IP ID increment on the Windows system in a different session, we would see: 173, 174, 175, 177, 178, 179. En d'autres termes, nous avons vu que 176 était manquant (deux dans le paquet précédent). This would be our indication that the TCP/80 probe sent to the target hit an open port.
Identification d'un scan ralenti
So an idle scan does an excellent job of masking the true source IP address of a port scan. This means that without access to log information on the Windows host (something that will not exist if the attack has done their homework), we will never be able to discover the true source IP address of the attack.
Is there a way to tell an idle scan was performed rather than a straight forward port scan so we know if it is worth investigating the source IP address? There are in fact a couple of clues we can look for.
Probe retries
Si le système cible est assise derrière un firewall, vous remarquerez une différence dans le nombre de tentatives de test par rapport à un scanner de port normaux. When someone runs a normal port scanner, the scanner will typically hit open ports only once but firewalled ports multiple times. This is because the firewalled ports return no response. The scanner will make multiple attempts to ensure the packets are not just getting lost. Since the open port will actually respond, only one probe packet is required.
Quand un scan d'inactivité est effectué, l'inverse est vrai. If a firewalled port is probed there will be no IP ID increment change on the Windows system. So only one check is required to confirm this is not an active listening port. When an open port is probed however, we'll detect a change in the Windows system's IP ID increment. While we think this is due to us finding an open port, it could just as likely be because the Windows system sent a broadcast. So we will want to perform multiple probes against the open port to ensure the Windows IP ID data remains constant.
Donc:
- Probe firewalled ports more often than open ports = normal port scanner
- Probe open ports more often that firewalled ports = idle scan
Le calendrier
Normal port scans be extremely fast. It is not uncommon to see hundreds of probe packets per second. With an idle scan however, we have to take things a bit slower. This is because we must check the IP ID of the spoofed address, send the probe packet, permit enough time for the probe to elicit a response, give the spoofed system enough time to respond with a reset if required (thus using up an IP ID), and then check the IP ID again to see if the increment has changed.
Try to perform all of these steps too quickly, and you will pay the price in accuracy. Par exemple nmap supporte les balayages d'inactivité avec le "SI" interrupteur. The default extremely fast scanning speed works fine if all of the systems are on the same switched network. If the hosts are 15 hops away from each other on the Internet however, my experience has been the accuracy rating drops off considerably unless you slow down the scanning speed.
Donc:
- Hundreds of packets per second = normal port scanner
- Une douzaine ou moins de paquets par seconde = Idle scan possible, pourrait juste être un balayage lent
Champ TTL
Let's look again at the spoofed probe packet as well as the legitimate reset response sent by the Windows system:
10:29:46.947964 IP (tos 0×0, ttl 64, id 15249, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.2.1984 > 192.168.100.3.80: S, cksum 0x476b (correct), 947341260:947341260(0) win 512
10:29:46.953439 IP (tos 0×0, ttl 128, id 176, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.2.1984 > 192.168.100.3.80: R, cksum 0x5df1 (correct), 947341261:947341261(0) win 0
You may have noticed the TTLs are way off from each other. If both of these packets had in fact originated from 192.168.200.2 then they would both have the same starting TTL value. The fact that they are different tells us that one of them is spoofed.
If you are monitoring the perimeter of the target system and notice that the SYN and reset packets have different TTL values, that's a clue that you may be experiencing an idle scan. Now, as mentioned earlier, it is entirely possible to set the TTL to what ever we wish in our spoofed packet. So a smart attacker is simply going to set their starting TTL to 128 to better mimic the Windows system. Si ils font cela, votre seul espoir est que l'attaquant et le système Windows sont un nombre différent de houblon loin. In other words, if you consistently see the SYN packets with a TTL of 115, but the resets consistently have a TTL of 113, you are most likely looking at an idle scan.
Si le TTL ne correspondent pas, nous ne pouvons pas totalement exclure une analyse de ralenti. The attacker may just be that good.
Donc:
- TTLs of SYNs and RSTs are consistent but do not match = idle scan
- TTLS of SYNs and RSTs match = normal port scanner or smart idle scanner
IP ID value
The best way to tag an idle scan is leverage the same thing the attacker uses, namely the IP ID value. Take another look at those last two decoded packets. Note that the IP ID in the first one is 15249 but in the second it is 176. If you are seeing an idle scan, you will notice the rest packets consistently have an IP ID of +2 (same thing the attacker sees), but the SYN packets will have some completely unrelated value. L'incrément d'identité IP dans les paquets SYN peut être prévisible ou il pourrait être aléatoire. Quite honestly it does not matter. What does matter is that you can spot some pattern in IP ID of the rest packets that does not jive with the IP IDs in the SYN packets.
Donc:
- IP ID of SYN and RST packets appear related = normal port scanner
- IP ID increment of RST does not match SYNs = idle scan
Résumé Exec
Espérons que vous avez maintenant une meilleure compréhension de ce qui se passe sur le fil quand un attaquant effectue un scan ralenti. If we are targeted with an idle scan, we cannot determine the true source IP address of the attacker. Le mieux qu'on puisse espérer accomplir est de déterminer que le scan est un scan ralenti par rapport à un scan de port normaux. There are a number of tell tale clues in packets, the best of which is the IP ID value.
