Port Scan Detected

Hi,

try to check the intrusion protection logs and tell us what kind of traffic is detected as portscan. ACC does not establish many connections to the outside, should only be for Up2Date service (http, https). But it will not try to connect to an ASG directly, only possibility is that ACC tries to use the ASG in front as upstream proxy.

Cheers

Thanks for the suggestion, however I found that log a little confusing and I am not sure what it is saying. Perhaps the powers that be can give us a format that is much easier to use.

I just saved a copy of todays log and attached here. Please transulate if you can.

Hi,

thanx for posting the excerpt. I deduce that 192.168.0.3 is the internal IP of your ACC. It tries to detect the fastest Up2Date Server via netselect, sending one or more UDP packets. These are logged and probably dropped by your IPS settings. You can define an exception list for your ACC host, so your border ASG does not check for portscans from the ACC.

Cheers

Thanx. This is really funny for it to be doing that, so I need to ask 3 thngs. Firstly, (bearing in mind that I am a newbie) this sort of checking sounds like something that I would want the ACC to do. However it is not able to get through because the border device is blocking it. So why shouldn't I just put in a rule that will allow it to pass this particular traffic through so that the ACC can do its thing? if yes, how?

Secondly, if as you suggest I configure that the border device just simply not check for scans from the ACC what if there is a case where something else starts scanning ports from it when it shouldn't how else would I know quickly that something is going on?

Thirdly, and I know you don't like to mix issues but I just have to ask this question. Is it possible that this port scan problem could be related to the ACC not doing Up2Date Cache as it is supposed to?

Hi,

1) You could enable global traceroute forwarding on the border device as the Up2Date netselect is probing udp ports 33000 something upwards incrementally. Defining a specific packet-filter rule for netselect requests originating from the ACC is more secure though:

protocol: udp
srcip: 192.168.0.3, dstip: any
spts:1024:65535 dpts:33000:34000

2) A packet-filter or traceroute forwarding rule is of course more secure, the suggestion was merely to find out, whether it helps fixing the problem. 

3) We'll see as soon as the port scan problem does not exist anymore ;-)

Cheers

Hi,
Been out of touch with this due to the recent hurricane. I was looking through the Packet Filter and the Services Definitions but I did not see anywher that the rule could be set up as you have stated above, which means that I am looking in the wrong place. As dumb as this might sound, where should I look to set this rule up?

Hi,
Been out of touch with this due to the recent hurricane. I was looking through the Packet Filter and the Services Definitions but I did not see anywher that the rule could be set up as you have stated above, which means that I am looking in the wrong place. As dumb as this might sound, where should I look to set this rule up?

Hi,

you can enable global traceroute forwarding in:

Network Security >> Packet-Filter >> ICMP
and check the box "Firewall forwards Traceroute"

Or, for tighter security, you can add a specific rule in:

Network Security >> Packet Filter >> Rules
and add a new rule with:
- Source: your ACC (pick from list, should already be defined)
- Service: Traceroute (pick from list)
- Destination: Any

I would recommend trying the global ICMP Traceroute setting first and if it works try to tighten the screws and apply the more specific rule instead.

Cheers