port scan to juniper fw
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
port scan to juniper fw
by raimarm
::
Rate this Message:
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. I would be very happy if somebody could explain me this strange behaviour and let me know how I can fix it. Maybe there is an option on the fw to switch this off. This is the nmap scan command: nmap -sS -P0 <fw-untrust-ip> Many Thanks rm ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------ |
|
|
Re: port scan to juniper fw
by Paul Melson-2
::
Rate this Message:
On Sun, Oct 18, 2009 at 8:15 AM, raimarm@...
<raimarm@...> 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 ------------------------------------------------------------------------ |
|
|
Re: port scan to juniper fw
by raimarm
::
Rate this Message:
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@...>: > On Sun, Oct 18, 2009 at 8:15 AM, raimarm@... > <raimarm@...> 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 ------------------------------------------------------------------------ |
|
|
Re: port scan to juniper fw
by aditya mukadam
::
Rate this Message:
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@... <raimarm@...> 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@...>: >> On Sun, Oct 18, 2009 at 8:15 AM, raimarm@... >> <raimarm@...> 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 ------------------------------------------------------------------------ |
|
|
Re: port scan to juniper fw
by Huzeyfe Onal
::
Rate this Message:
Hi,
what if i spoof my source address to any ip like root dns servers, company's gateway router etc? Very dangerous options... --- Huzeyfe ONAL Ag Guvenligi Listesine uye oldunuz mu? http://www.lifeoverip.net/netsec-listesi/ --- On Thu, Oct 22, 2009 at 8:27 PM, aditya mukadam <aditya.mukadam@...> wrote: > > 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@... > <raimarm@...> 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@...>: > >> On Sun, Oct 18, 2009 at 8:15 AM, raimarm@... > >> <raimarm@...> 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 > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------ |
|
|
|
|
|
Re: port scan to juniper fw
by Chris Brenton
::
Rate this Message:
On Thu, 2009-10-29 at 08:22 +0530, aditya mukadam wrote:
> > Juniper FW Anti-spoofing mechnism's logic is to check the > route for the incoming SRC-IP. If the packet with SRC-IP a.b.c.d > enters firewall via interface 'X' and the route on the firewall for > a.b.c.d is to interface 'Y, this packet will be dropped due to > anti-spoofing because it is entering via an interface through which it > is not expected to be sent back. Have you verified this? Last time I tested their anti-spoofing it didn't actually drop the packet. It would pass it through and then follow it up with a host unreachable (to the target) in order to kill the session. What was odd was the TTL would get decremented by 2. My best guess is it was the single honed IPS code dealing with the spoofing and that was introducing an extra routing hop. I have not tested this for a few years, so they may have rewritten how they handle it. Just curious if you have checked this or if you are going by the docs. HTH, Chris -- www.chrisbrenton.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 ------------------------------------------------------------------------ |
|
|
Re: port scan to juniper fw
by aditya mukadam
::
Rate this Message:
Yes, I have verified and also have the relevant logs with me from the
'flow filter' . Thanks, Aditya Govind Mukadam On Wed, Nov 4, 2009 at 2:49 PM, Chris Brenton <cbrenton@...> wrote: > > On Thu, 2009-10-29 at 08:22 +0530, aditya mukadam wrote: > > > > Juniper FW Anti-spoofing mechnism's logic is to check the > > route for the incoming SRC-IP. If the packet with SRC-IP a.b.c.d > > enters firewall via interface 'X' and the route on the firewall for > > a.b.c.d is to interface 'Y, this packet will be dropped due to > > anti-spoofing because it is entering via an interface through which it > > is not expected to be sent back. > > Have you verified this? Last time I tested their anti-spoofing it didn't > actually drop the packet. It would pass it through and then follow it up > with a host unreachable (to the target) in order to kill the session. > > What was odd was the TTL would get decremented by 2. My best guess is it > was the single honed IPS code dealing with the spoofing and that was > introducing an extra routing hop. > > I have not tested this for a few years, so they may have rewritten how > they handle it. Just curious if you have checked this or if you are > going by the docs. > > HTH, > Chris > -- > www.chrisbrenton.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 ------------------------------------------------------------------------ |
| Free embeddable forum powered by Nabble | Forum Help |
