- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-01-2017 08:37 AM
Hi all,
Looking for some feedback from anyone else who has run into this issue before.
Basically we have zone protection set up for our Wifi and ResNet security zones. Included in this zone protection is a block-ip rule for port scanning. We've received a request to allow client devices on these networks to reach a server using a specific piece of software and that software, by default, does a port scan... I'm guessing to identify which ports the server is set up to use. My security logs show the traffic is allowed but with tcp-rst-from-server on the attempts. If I go and look at the threat logs on the firewalls (instead of Panorama) I'm seeing block-ip happening due to the port scan.
Is there a way around this that anyone has come up with besides disabling port scan protection? The simplest thing to do would be to put in an exception for that specific destination IP but it looks like exceptions are currently source IP based only. I would not know the source IP addresses for these clients since it is DHCP and we wouldn't be doing reservations for them.
Thanks!
08-01-2017 01:08 PM
Currently I don't know of a way to make an exclusion by the destination IP address if it's triggering on a zone protection policy. It might be a case for a feature request unless anyone else has some magic to toss at the idea?
08-01-2017 03:47 PM
I agree, there is not an option without disabling the zone protection that I can think of. I also would like a solution since my scanners get blocked and it takes a long time to scan certian zones.
08-01-2017 08:20 PM
@OtakarKlier the scanners you mention, if they're on static IP addresses or have DHCP resverations you could add them to an exception list in the zone protection profile.
Sadly that isn't an option for me. I think having a destination exception list would be very handy if it is possible.
08-02-2017 12:13 PM
I think we determined we'd use a client config file that specifies a port unstead of letting it do the port scan. It seems like a lazy way to program a client application, especially when there are only ten or so ports it could use, why shouldn't the server just listen on all of them and the client be a little more subtle about checking them instead of blasting them all at once?
I'm going to go ahead and reach out to my account rep and ask about the destination exclusion as a possible feature request.
08-03-2017 09:44 AM
... i would really love to hear / read the conversation the developpers had when they decided how to solve the problem of the unknown destination port :D:D:D
... and if they also discussed about scanning the whole IP space in order to find the server when the user does not know it ...
08-03-2017 11:08 AM
Haha right? It reminds me of one of my favorite quotes from the movie Aliens:
"We'll nuke it from orbit, it's the only way to be sure"
How do we know what port to use? We'll just try them all, at once, two or three times.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!