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 tried the second solution on a local system, but it only worked when IPS was activated.

    When I tried it with deactivated IPS, there was an error: "No such file or directory"
  • That's fine and not an issue.
    Best
    Sven Wurth
    ASTARO


    The updates seem to fix the issue for me and few others by the look of it.

    Maybe there are other side issues going on as well not sure.

    What gets me is that since this whole issue began and maybe from 24 hrs ago I seem to have this issue in my IPS log along with another 2 dozen rules specified. Any ideas?

    2010:05:07-18:48:02 ******** snort[8442]: Encoded Rule Plugin SID: 11016504, GID: 3 not registered properly. Disabling this rule. 
    2010:05:07-18:48:02 ******** snort[8442]: Encoded Rule Plugin SID: 52016534, GID: 3 not registered properly. Disabling this rule. 
    2010:05:07-18:48:02 ******** snort[8442]: Encoded Rule Plugin SID: 41016533, GID: 3 not registered properly. Disabling this rule.
  • Noted my frustrations in another thread, glad we have one thread to follow on the issue now. [[:)]]  At first it just looked like they were being closed as fast as they were opened!

    Anyway, after losing some time on this, I added a vote to be able to roll back Up2Date packages.  Might want to add your vote as well now! Up2Date: Configuration Roll Back Option

    I'll bring the Astaro back to service once this gets sorted out in the next day or so.  For those that haven't been affected yet, you may want to disable Up2Date for the time being.  I'm going to be changing my update time frames I think after getting stung by having the latest and greatest... [[:)]]
  • Just to be curious:
    What *are* the patterns 15851 and 16576 for (or rather what kinds of attacks were they intended for if everything had gone right)?
  • I just had Pattern version 12408 installed, but this update did not include any new IPS patterns, so the original problem remains in place.

    What confuses me as that there do not seem to be separate versions for the different modules that use Patterns (IPS / AV / etc.). The way I see it is that an update of the Pattern version from 12406 to 12408 does not mean that the update included new IPS patterns - it may well be that only AV patters were updated. 

    How can we tell the difference?
  • Had the issue too, disbaled IPS added the disabled rules then it worked again but....

    Pattern 12408 was just installed and now we loose all web connectivity. I have to disable the transparent proxy in order to have http access again.

    Enabling the proxy blocks all outgoing http traffic.

    What's going on here.

    Franc.
  • Hi,

    the same problem again! Nothing working, even if you turn off ISP!

    tov
  • Disabling double scan at http proxy settings solves this issue temporarely. It seems to be a pattern problem from clamav.
  • Yes - confirmed. When I now enable double scanning in HTTP Proxy, everything is blocked. When I only use Single scanning everything works fine.

    Nice... Two pattern issues within 24 hours...

    We now have unreliable IPS (it needs to run with a workaround in place) and we have a broken clamav resulting in reduced Web Security. So, what's next?
  • NOTHING.........

    2010:05:07-13:27:25 asg httpproxy[21793]: Integrated HTTP-Proxy (c) 2007-2008 Astaro AG, Version 7.504
    2010:05:07-13:27:25 asg httpproxy[21793]: [ (nil)] main (httpproxy.c:176) reading configuration
    2010:05:07-13:27:26 asg httpproxy[21793]: [ (nil)] main (httpproxy.c:186) reading profiles
    2010:05:07-13:27:27 asg httpproxy[21793]: [ (nil)] disk_cache_zap (diskcache.c:431) creating cache
    2010:05:07-13:27:27 asg httpproxy[21793]: [ (nil)] disk_cache_zap (diskcache.c:451) rename: Directory not empty
    2010:05:07-13:27:28 asg httpproxy[21793]: [ (nil)] adir_auth_init (auth_adir.c:220) gss_acquire_cred host/asg.***@***.***.BIZ: No such file or directory
    2010:05:07-13:27:31 asg httpproxy[21793]: [ (nil)] sc_check_servers (scr_scanner.c:724) server 'cffs01.astaro.com' access time: 113ms
    2010:05:07-13:27:31 asg httpproxy[21793]: [ (nil)] sc_check_servers (scr_scanner.c:724) server 'cffs02.astaro.com' access time: 118ms
    2010:05:07-13:27:32 asg httpproxy[21793]: [ (nil)] sc_check_servers (scr_scanner.c:724) server 'cffs03.astaro.com' access time: 353ms
    2010:05:07-13:27:32 asg httpproxy[21793]: [ (nil)] sc_check_servers (scr_scanner.c:724) server 'cffs04.astaro.com' access time: 351ms
    2010:05:07-13:27:32 asg httpproxy[21793]: [ (nil)] sc_check_servers (scr_scanner.c:724) server 'cffs05.astaro.com' access time: 118ms
    2010:05:07-13:27:32 asg httpproxy[21793]: [ (nil)] sc_check_servers (scr_scanner.c:724) server 'cffs06.astaro.com' access time: 337ms
    2010:05:07-13:27:33 asg httpproxy[21793]: [ (nil)] sc_check_servers (scr_scanner.c:724) server 'cffs07.astaro.com' access time: 345ms
    2010:05:07-13:27:33 asg httpproxy[21793]: [ (nil)] sc_handle_cmd (scr_scanner.c:512) write: Connection refused
    2010:05:07-13:27:33 asg httpproxy[21793]: [ (nil)] sc_check_servers (scr_scanner.c:724) server 'cffs09.astaro.com' access time: 220ms
    2010:05:07-13:27:34 asg httpproxy[21793]: [ (nil)] sc_check_servers (scr_scanner.c:724) server 'cffs10.astaro.com' access time: 760ms 

    Are they sleeping?

    tov