WorkShop n°22 : Port Scanning
TcpCatcher comes with a simple but powerful port scanner. This can be useful when performing a security audit or if you just want to check the ports that are opened on your own computer.
We remind you that port scanning against a remote host may be legal, but will be considered as a very hostile activity.
- There are two ways to open the port scanner, the first way is to use port scan button located in the front Action Panel. The second is to right click on a packet and choose 'Scan Remote Host'.
- Let's scan my own pc ("localhost")
- You are asked to choose the port range you want to scan, the number of concurrent threads that will be scanning at the same time. Since TcpCatcher is based on non blocking IO you can also set up the timeout (ie the amont of time to wait before considering that the port is closed). 10 millisec for the localhost is good enough.
- Now, let's start scanning !
- You can notice that TcpCatcher comes with a dictionnary of usual ports definition. Most of the ports are know, but some not.. I should really check what these ports are..
- Full port range scanning on my laptop took 83 sec with 50 threads.
- You might wonder what is the best number of threads one should use to perfom the quickest port scan. Of course, that will depend of your own pc's power (cpu and memory). I did that test for you. Let's look at the result.
- We can see that multithreading is highly efficient at the beginning, but beyond 25 threads it does not add any value anymore, and beyond several thousands of threads you will just end up with an "Out of Memory error". Here on my laptop with a timeout of 10ms, 25 threads is the best choice.
- Suppose now that you are scanning a remote host. By default, TcpCatcher will set up a timeout equal to the double of the ping time (what is called 'ping time' is acutally the time needed to established a TCP handshake on the HTTP port). Should the timeout choice change the choice of best number of threads ? Actually, yes. Let's look at the result graph with a timeout of 90 millisec.
Here with a timeout of 90 ms, the best choice, is 100 concurrent threads !
