Penetration Testing mailing list archives

Re: port scan to juniper fw


From: aditya mukadam <aditya.mukadam () gmail com>
Date: Thu, 22 Oct 2009 23:57:44 +0530

Its good to know that the issue is resolved. However,please also note
the below default behavior of Juniper SSG for a port scan.

The security device internally logs the number of different ports
scanned from one remote source. Using the default settings, if a
remote host scans 10 ports in 0.005 seconds (5000 microseconds), the
device flags this as a port scan attack, and rejects all further
packets from the remote source for
the remainder of the specified timeout period. The device detects and drops the
tenth packet that meets the port scan attack criterion.

Thanks,
Aditya Govind Mukadam

On Wed, Oct 21, 2009 at 11:17 PM, raimarm () gmail com
<raimarm () googlemail com> wrote:
Hi All,

thank you very much for your answers and advices.
Deactivating the syn-proxy solved the issue.

Many Thanks
rm

2009/10/20 Paul Melson <pmelson () gmail com>:
On Sun, Oct 18, 2009 at 8:15 AM, raimarm () gmail com
<raimarm () googlemail com> wrote:

Dear list,
I am performing a port scan to an IP address of juniper SSG firewall (6.2.r3).
When the port scan finishes the results show me a lot of open ports
although they are not open.
Further the results differ and the same scan shows different open
ports next time.
The tcpdump during the port scan shows me that the fw is answering
with a syn-ack after the third syn.
Why is this happening ? I would expect no answer or a rst packet.

This is the result of the Juniper firewall having SYN flood protection
mode being enabled.  This causes the firewall to begin responding to
SYN packets with SYN-ACK once the flood threshold is reached.  There
are two modes, syn-proxy and syn-cookie.  This is intended to protect
slow/unresponsive servers behind the firewall as well as the firewall
itself.  Y

https://support.neoteris.com/products/integrated/dos.pdf

ou can detect which is being used by capturing the traffic from your
portscan using tcpdump or Wireshark and examining the SYN+ACK packets
from the firewall.  If the ISNs are random, then the firewall is using
syn-proxy mode.  If the ISNs incrementally by port number (and then
again by time every 64s) then syn-cookie mode is enabled.  This might
be an interesting finding to share with your client.  Or not.  If they
are using syn-proxy mode, you can recommend that they use syn-cookie
mode since it's less CPU and memory intensive for the firewall.

For the purposes of your test, you could ask your client to disable
this feature temporarily while you scan, but advise them that it could
leave older, slower servers vulnerable to a DoS attack.  Or you could
simply ask them to share a copy of the firewall configuration in order
to speed up the pen-test.  If neither of these is an option, you could
try a FIN scan or a Version (-sV) scan to try and reduce the false
open port findings.  Either way, I would go back to the client and
communicate the issue you're having so that they understand the delay.
 Port scanning always sounds like the easiest part of a pen-test, but
often it's the hardest.

PaulM


------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board

Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT 
and CEPT certs require a full practical examination in order to become certified.

http://www.iacertification.org
------------------------------------------------------------------------



------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board

Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT 
and CEPT certs require a full practical examination in order to become certified.

http://www.iacertification.org
------------------------------------------------------------------------


Current thread: