Timed out in penetration testing

[mindf]

We are doing an external penetration test to our client network but can't proceed further as our scan/request are timed out every time we start the initial scan. As an example, we knew port 21 is open and could connect to it, but after we did a scan to check any available open ports, all requests(pings, etc) are timed out without any results and we can't even connect back to port 21. This would last for 10 mins and ping replies would return to normal.

We're thinking this might be an issue(or feature) on the ISP's side because all the IPs in the network block behaved in the same way. Is there any advice on how to proceed with the pentest? Should we notify the ISP or the client about the issue? Results would be very minimal and inconsistent and i am sure the client will be not satisfied if we mention the problem at the end of the day.

Thanks

[Thorn]

Sounds like your client (or the ISP) has an IDS kicking in, and as a educated guess, the behavior is that it's doing exactly what it is supposed to be doing. There are several IDS packages that will do similar things. My suggestion would be to make appropriate notes, adjust timing on your tool(s) to perform the needed scan(s) and move on. Depending on the scope of the pen test, you might want to see if you can identify the IDS, and see what vulnerabilities it may possess.

[secure_it]

today's IDS/IPS and firewall are able to easily detect almost all kind of scan attacks like syn,null,tcp etc. and consider as attack patterns.if there is IDS in place it is denying you for next 10 mins according to signature tuning and that may be firewall too.because if you are pinging then the first 1 or 2 packet's reply you will get and after that firewall or IDS will learn about the attacking host and based on signature tuning its action can be request block,signature alarm,RST.so I think you are getting RST signal and connection is being terminated.but I think you have to PT for client so you must consult ISP about it as it will be taken as criminal offense if you dont take him into consideration.no ISP will allow scanning through his network as its vital for security and can lead to security breach.

[thorin]

We're thinking this might be an issue(or feature) on the ISP's side because all the IPs in the network block behaved in the same way.

I hope you were contracted to assess all the IPs in that netblock, otherwise you've attempted to pentest resources of the ISP or other clients of the ISP that you have no contract for.

Is there any advice on how to proceed with the pentest?

I see a few options:
1) Script or schedule your way around the IDS/IPS which is imposing the timeout.
2) Tell the client you've noted that their protections (or the ISPs) are working (somewhat) but that you'd like them to insert some exceptions for your testing so that you can proceed within a decent time frame. (Of course this means you'll have to provide them with source addressing that you'll be doing the testing from).
3) Present the results as you've found them, as this represents the way the majority of the attacks will come at them (though nothing says an attacker wouldn't go to the trouble of #1 above....the client should make this determination. i.e.: How much effort do they expect an attacker/malicious user to invest in attacking them).

Should we notify the ISP or the client about the issue?

That depends on your contract and agreements (or lack thereof) with the client and ISP.

[opreat0r]

get on the LAN or get some user to use a java scanner or excel template port scanner..

-T 1 in nmap ... ( also try syn etc . )

only thing you can do with IDP is first
* slow down the scans
* set max threads down
* obfuscate the test manually and find out what does not trigger the IDS ( unicode base26 etc .. )
* own a client inside the LAN ...scan away!
* also fun one is to hijack the LAN and trigger the IDP to block everybody on the network ( if miss configured )

[secure_it]

get on the LAN or get some user to use a java scanner or excel template port scanner..

-T 1 in nmap ... ( also try syn etc . )

only thing you can do with IDP is first
* slow down the scans
* set max threads down
* obfuscate the test manually and find out what does not trigger the IDS ( unicode base26 etc .. )
* own a client inside the LAN ...scan away!
* also fun one is to hijack the LAN and trigger the IDP to block everybody on the network ( if miss configured )

These are fully detectable by most of modern IDS/IPS and a proper configuration and signature tuning and Meta event generators are able to catch these scans easily.I have tested Nmap IDS evasion scans,fragmentation attacks.all are easily detectable by modern IDS/IPS like cisco 5.1,6.0,6.1 and ISS IPS so they wont make sense while scanning.