Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 4444 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Port Scan Detected

Datsys
Hey,
I hope someone will give this newbie a little help. I have noticed that when I have the ACC up then the ASG that is in fornt of it keeps getting port scans from the IP of the ACC. With that there are a ton of email alerts that go through my inbox. Is this normal or did I configure something wrong? Is there a way to stop this from happening? I don't think it would be a good idea to try and turn off such notifications because there might just be a time it is for something more serious.


This thread was automatically locked due to age.
Parents
  • 0
    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
  • 0 in reply to megaposer
    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.
  • 0 in reply to Datsys
    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
  • 0 in reply to megaposer
    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?
Reply
  • 0 in reply to megaposer
    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?
Children
  • 0 in reply to Datsys
    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
  • 0 in reply to megaposer
    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?
  • 0 in reply to Datsys
    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
Unfiltered HTML