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

Strange IPS warnings since today

Hello all,

since today the IPS has some strange detections and I receive periodically the notifications, until now approx. 130.

Unfortunately I can't figure out what the problem is.

---
Subject: [GQDN Gateway][WARN-850] Intrusion Prevention Alert

Intrusion Prevention Alert

Details about the intrusion alert:

Message........: ICMP Microsoft remote unauthenticated DoS/bugcheck vulnerability
Details........: Snort ::
Time...........: 2012:05:21-16:02:07
Packet dropped.: no
Priority.......: medium
Classification.: Attempted Denial of Service
IP protocol....: 1 (ICMP)

Source IP address: ***.***.***.1 (gateway)
Source port: 0
Destination IP address: ***.***.***.201 (FQDN Server)
Destination port: 0
---

System Version is 8.302.

I receive this notifacations for two server ***.***.***.200 and .201. Both servers are configured as DC and DNS.

Why the Astaro is initiating such requestes on Port 0?

Thoughts, comments, solutions are much appreciated.

Many thanks.

PSyc


This thread was automatically locked due to age.
  • Hi, PSyc,

    1. Which Remote Access methods do you have active when this occurs? 
    2. Do you have a masquerading rule like 'VPN Pool (????) -> Internal' or a similar SNAT? 
    3. Can you confirm that the Host definitions for your two DCs have 'Interface: >' instead of being bound to an interface?
    4. Is "VPN Pool (????)" listed in 'Internal networks' in Intrusion Prevention?

    Cheers - Bob
  • Hi Bob,

    thanks for your fast reply.

    1. Only SSL VPN is active
    2. Yes, rules are set SSL VPN to INTERNAL
    3. Confirmed
    4. Yes

    The strange thing is, that we didn't had this issue in the past. We didn't changed the enviroment in the last days/weeks .. 

    Looks like I've a misconfiguration.

    Any ideas?

    Many thanks.

    Cheers
    Alex
  • Why the Astaro is initiating such requestes on Port 0?

    SSL VPN is active

    I think that's the answer.

    2. The masq rule shouldn't be necessary.  The mistake in 3 is usually the reason people have it.  Try disabling this masq rule.

    If that doesn't fix the problem, the easiest would be to disable the Snort rule or create an exception for Source = "Internal (Address)" and Destination = Group of DCs.

    Cheers - Bob
  • I'm getting thousands of these as well but the addresses in the errors are not within any VPN Pools.

    1. Remote Access is turned on for IPSec & L2TP  [Remote access has not been in use]
    2. I've had masquerading turned on VPN Pools --> External but I'm assuming this IS necessary.
         I deleted these but I haven't tested as of yet.
    3. Hosts all have Interfaces defined in definitions (none say >)
    4. No VPN Pools are listed in Internal Networks in Intrusion Prevention.

    No changes were implemented that I know of that would cause this new flood of errors.

    The messages began on June 26 in the late evening. 

    The source is a Mac OSX client.  - No updates around this time
    The destination is the Astaro Firewall. - Only virus pattern updates found

    Update: after reviewing the documentation I reestablished the NAT rules between VPN Pools & the external interface.
  • 2. I've had masquerading turned on VPN Pools --> External but I'm assuming this IS necessary.

    Yes, that's necessary if you're using a full tunnel.  If you're only using a Remote Access tunnel to access internal servers, or all internet traffic passes via the web proxy, then masquerading isn't necessary.  A full tunnel with Transparent web proxy usually requires masq rules.

    Cheers - Bob
  • As of 29 June, the errors have stopped.
    Not clear what has affected this change.
    Not happy about that.