Using the New to Refactor the Old: Port Scanner Edition
By Ricky Lawshae
Given all of the enhancements that have been made to the Security component of the BreakingPoint Storm CTM since the 2.0 firmware release, we decided it would be beneficial to take a look at rewriting some of our older strikes. After all, when you have a platform that lets you do more awesome things, you might as well take advantage, right?
Port scanner strikes seemed like a good place to start to demonstrate the power of the rewritten Security component. Our older port scanner strikes definitely served their purpose, but had fairly long run times and didn't quite mirror the behavior of modern standalone port scanners. In a world where networks are under constant assault by outside forces, realism is crucial for making sure that your defenses are functioning as they should, so making our port scanners more realistic helps in keeping you one step ahead.
TCP and UDP Port Scanners — Better and Faster
In our imminent just-released ATI update, you will find completely rewritten Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port scanners that use the new Security component's network stack to send and listen for packets asynchronously. These scanners use a single source and destination IP address per strike, as opposed to the old way of opening a session, sending a packet to a port, waiting for a result, closing the session, and then repeating the entire process for the next port. This not only dramatically decreases the average individual run time for these strikes to about eighty seconds each, but also more accurately reflects the traffic generated by real-world scanners like nmap.
In addition to refactoring the old scanners, I took the liberty of adding a few new ones, which are highlighted in this screenshot and described below:
TCP Port Scan (ACK) – This strike sends a TCP packet to each of the 65535 ports with the ACK flag set, then monitors for any responses it receives. This type of scan is often used to discover firewall filtering rules because, when a target host receives an ACK packet, it will respond with a RST regardless of whether the target port is open. When a RST is received in response, it indicates that communication with the port in question is not filtered by any intermediate defenses. Report results for this strike show whether ports are 'filtered' or 'unfiltered.'
TCP Port Scan (Maimon) – This strike is very similar to our existing FIN scan strike, but sends a FIN|ACK as opposed to just a FIN. Report results for this strike show whether ports are 'open,' 'open|filtered,' or 'closed.'
TCP Port Scan (Window) – This strike is similar to the ACK scan, but has the important distinction of being able to detect the open/closed state of a port based on the TCP window size of the received RST response. In certain configurations, closed ports send a RST with a window size of zero, while open ports do not. Report results for this strike show whether ports are 'filtered,' 'unfiltered,' 'open,' or 'closed.'
Now that we’ve taken a look at the new port scanners, it’s worth it to review the functionality of the older port scanners that we rewrote and improved for this update:
TCP Port Scan (FIN) – This strike sends TCP packets with the FIN flag set. If it receives a RST in response, that would indicate that the port is closed. If no response is received, the port is either open or filtered by some intermediate device. Report results for this strike show whether ports are 'open,' 'open|filtered,' or 'closed.'
TCP Port Scan (NULL) – In terms of how it interprets responses, this strike operates much like the FIN scan. The difference here is that there are no TCP flags at all set in the packets that the device sends out. If used in conjunction with the other types of scans, this scan starts to give you a very clear picture of the filtering rules in place in the target device to deal with anomalous TCP packets. Report results for this strike show whether ports are 'open,' 'open|filtered,' or 'closed.'
TCP Port Scan (SYN) – This strike is probably the one most likely to be seen on an actual network. It starts by sending a packet with the SYN flag set, as any TCP session would. It waits for a response, and then terminates the connection before completing the standard handshake. Because of that, this scan is less noisy and potentially quicker than the Standard scan. Report results for this strike show whether ports are 'open,' 'filtered,' or 'closed.'
TCP Port Scan (Standard) – Also called the 'full-connect' scan, this strike attempts to complete the entire TCP handshake for each of the 65535 ports. If the handshake is successful, the port is open. If it fails, the port is most likely closed. Report results for this strike show whether ports are 'open,' 'filtered,' or 'closed.'
TCP Port Scan (XMAS) – Named this way because the TCP flag bits are “lit up like a Christmas tree,” the XMAS scan sends packets with the FIN, PSH, and URG flags set. Again, the result is the same as the FIN scan, but this scan can be useful for evading detection and filtering rules. It can also be used to discover idiosyncrasies in packet handling that would allow a an attacker to better understand the system that the scan is being run against. Report results for this strike show whether ports are 'open,' 'open|filtered,' or 'closed.'
UDP Port Scan – This strike attempts to make a UDP connection with each of the 65535 ports. Simply put, if an 'ICMP port unreachable' message is received in response, the port is closed, and if a UDP packet is received in response, the port is open. Report results for this strike show whether ports are 'open,' 'open|filtered,' or 'closed.'
The inclusion of the new scanners and the reimplementation of the old scanners allow users of our device to add even more realism and coverage to their simulations. This in turn improves their ability to stop the real-world tools being used against them on a daily basis.
This is only the beginning of the improvements that are being made to current and future strikes, so be sure to keep an eye on this blog for more announcements of upgrades as they happen.
Related posts:
- Spam Fight! Emulating Spambots with Markov Text Generation To Validate Email Filtering Accuracy
- Scrambling the IP Stack for Fun and Profit
- Testing and Validation of Network Security Devices