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

UPDATE - IPS Pattern Update fixed

Hi Everyone,

We have tested that the new IPS patterns on the Up2Date server are fixed and working.

If your system is affected there are two ways to get the updated and fixed patterns:

1) WebAdmin (the preferred way)

- login to WebAdmin via https://YOUR_ASG_IP:4444
- go to left menu item “Network Security”
- go to sub menu item “Intrusion Prevention”
- disable the IPS system (if not already done)
- go to the last tab “Advanced”
- click on the green “+” sign under “Modified rules”
- enter under “Rule ID”: 15851 and check “Disable this rule”
- click “Save”
- click again on the green “+” sign under “Modified rules”
- enter under “Rule ID”: 16576 and check “Disable this rule”
- click “Save”
-     go back to the first tab and activate the IPS system again

This will fix the problem and install the new IPS pattern. 

PLEASE NOTE: Depending on the speed and workload of your ASG it can take a minute!

 
2. Command line (only for experienced users)
-     login via SSH or local on console
-     become "root"
-     enter "echo 1 > /proc/net/nf_condition/ips"

That's all and will do the following: 

*     it will bypass completely the IPS system on lowest level (ASG is online then), independent if IPS is activated or deactivated on WebAdmin

*     the new IPS pattern will be fetched and installed

*     the next IPS pattern update we will provide later today will remove this bypass automatically and the ASG works like configured (with new pattern)


If your ASG uses ACC as an Up2Date cache: do the same above for these ASGs if there are affected. There is no todo on ACC.


If your ASG is not and was not affected, because IPS was turned off last 8 hours or not online and therefore didn't fetched the corrupt pattern then there is no action needed. The old, corrupt patterns are removed from the Up2Date server. It is safe the activate IPS now and set the ASG online again to fetch IPS pattern.


We are very sorry for this inconvenience.

Best regards,

Dominic Schmidl


This thread was automatically locked due to age.
  • I would like to get a little bit of clarification.  Once 12410 has been detected, downloaded, and installed, can the IPS rule modifications to disable 15851 and 16576 be removed safely?
     
    Thanks.

  • 2. Command line (only for experienced users)
    -     login via SSH or local on console
    -     become "root"
    -     enter "echo 1 > /proc/net/nf_condition/ips"


    What are the steps to reverse the /proc work-around once the system is patched with the corrections?
  • What are the steps to reverse the /proc work-around once the system is patched with the corrections?
    If you read a few lines further in the post you quoted, you'll find 
    * the next IPS pattern update we will provide later today will remove this bypass automatically and the ASG works like configured (with new pattern)
  • I had lots of fun today fixing about 20 ASGs of various customers ...


    Tell me about it.  There are not words to describe what it is like to be awakened by your entire customer base calling with outages while your own NOC is down.
  • What pattern version has completely corrected these problems?

    The "blog" at Astaro Up2Date Announcements is woefully short on specifics and details.

    Astaro: details matter.  Where should I go for definitive information?
  • 2010:05:07-11:30:05 fw audld[10160]: >=========================================================================
    2010:05:07-11:30:05 fw audld[10160]: All 2 Authentication Servers failed
    2010:05:07-11:30:05 fw audld[10160]: '213.144.15.5:443'                     Code: '500'
    2010:05:07-11:30:05 fw audld[10160]: 
    2010:05:07-11:30:05 fw audld[10160]:  1. Modules::Trad_Get_Filelist::contact:1529() audld.pl
    2010:05:07-11:30:05 fw audld[10160]:  2. main::authenticate:579() audld.pl
    2010:05:07-11:30:05 fw audld[10160]:  3. main::run:383() audld.pl
    2010:05:07-11:30:05 fw audld[10160]:  4. main::top-level:33() audld.pl
    2010:05:07-11:30:05 fw audld[10160]: |=========================================================================
    2010:05:07-11:30:05 fw audld[10160]: id="3703" severity="error" sys="system" sub="up2date" name="Authentication failed, no valid answer from Authentication Servers"
    2010:05:07-11:30:05 fw audld[10160]: 
    2010:05:07-11:30:05 fw audld[10160]:  1. main::alf:846() audld.pl
    2010:05:07-11:30:05 fw audld[10160]:  2. main::authenticate:583() audld.pl
    2010:05:07-11:30:05 fw audld[10160]:  3. main::run:383() audld.pl
    2010:05:07-11:30:05 fw audld[10160]:  4. main::top-level:33() audld.pl
    2010:05:07-11:41:02 fw audld[10708]: Starting Up2Date Package Downloader (Version 1.57)
    2010:05:07-11:41:03 fw audld[10708]: patch up2date possible
    2010:05:07-11:41:07 fw audld[10708]: Could not connect to Authentication Server 213.144.15.5:443 (code=500).
    2010:05:07-11:41:07 fw audld[10708]: Could not connect to Authentication Server 213.144.15.5:443 (code=500).
    2010:05:07-11:41:07 fw audld[10708]: >=========================================================================
    2010:05:07-11:41:07 fw audld[10708]: All 2 Authentication Servers failed
    2010:05:07-11:41:07 fw audld[10708]: '213.144.15.5:443'                     Code: '500'
    2010:05:07-11:41:07 fw audld[10708]: 
    2010:05:07-11:41:07 fw audld[10708]:  1. Modules::Trad_Get_Filelist::contact:1529() audld.pl
    2010:05:07-11:41:07 fw audld[10708]:  2. main::authenticate:579() audld.pl
    2010:05:07-11:41:07 fw audld[10708]:  3. main::run:383() audld.pl
    2010:05:07-11:41:07 fw audld[10708]:  4. main::top-level:33() audld.pl
    2010:05:07-11:41:07 fw audld[10708]: |=========================================================================
    2010:05:07-11:41:07 fw audld[10708]: id="3703" severity="error" sys="system" sub="up2date" name="Authentication failed, no valid answer from Authentication Servers"
    2010:05:07-11:41:07 fw audld[10708]: 
    2010:05:07-11:41:07 fw audld[10708]:  1. main::alf:846() audld.pl
    2010:05:07-11:41:07 fw audld[10708]:  2. main::authenticate:583() audld.pl
    2010:05:07-11:41:07 fw audld[10708]:  3. main::run:383() audld.pl
    2010:05:07-11:41:07 fw audld[10708]:  4. main::top-level:33() audld.pl
    2010:05:07-11:56:01 fw audld[11535]: Starting Up2Date Package Downloader (Version 1.57)
    2010:05:07-11:56:02 fw audld[11535]: patch up2date possible
    2010:05:07-11:56:04 fw audld[11535]: Could not connect to Authentication Server 213.144.15.5:443 (code=500).
    2010:05:07-11:56:04 fw audld[11535]: Could not connect to Authentication Server 213.144.15.5:443 (code=500).
    2010:05:07-11:56:04 fw audld[11535]: >=========================================================================
    2010:05:07-11:56:04 fw audld[11535]: All 2 Authentication Servers failed
    2010:05:07-11:56:04 fw audld[11535]: '213.144.15.5:443'                     Code: '500'
    2010:05:07-11:56:04 fw audld[11535]: 
    2010:05:07-11:56:04 fw audld[11535]:  1. Modules::Trad_Get_Filelist::contact:1529() audld.pl
    2010:05:07-11:56:04 fw audld[11535]:  2. main::authenticate:579() audld.pl
    2010:05:07-11:56:04 fw audld[11535]:  3. main::run:383() audld.pl
    2010:05:07-11:56:04 fw audld[11535]:  4. main::top-level:33() audld.pl
  • Two issues - Can IPS be turned off until new patterns are downloaded, or do you need to have IPS turned on with the two rules disabled to get the correct Pattern?

    What is the working pattern, and why do the messages from Astaro not refer to those patten numbers?  Something like - If you have pattern 12410 IPS is broken, wait until pattern *** is downloaded.

    Nick
  • I would like to get a little bit of clarification.  Once 12410 has been detected, downloaded, and installed, can the IPS rule modifications to disable 15851 and 16576 be removed safely?
     
    Thanks.



    Scott, I would not remove those rule modifications; I'm sure that they removed the rules from the latest ruleset, but as insurance against some future event, if, somehow, someway, they accidentally add those rules back in, I'd leave them in place.
  • Astaro needs to develop a common communications format for times such as this.

    The latest blog post (Letter from the CEO) is better, but I don't need apologies right now.  I need definitive, factual information and procedures I can use to fix this without having to guess or make assumptions.

    Example: http://security.freebsd.org/advisories/FreeBSD-SA-10:01.bind.asc
  • For Astaro: I am interested in getting more information on the cause of the problem. Was it a question of inadequate testing before deploying a specific IPS pattern update? Is there an ongoing issue with the AV scan engine?