Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 2 subscribers
  • Views 2391 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

Error after IPS up2date from 1.feb

TOHIL
i have this error, after the newest update of intrusion protection system:

2006:02:02-20:01:55 (none) selfmonng[626]: triggerAction: 'cmd'
2006:02:02-20:01:55 (none) selfmonng[626]: actionCmd(+): '/var/mdw/scripts/snort restart'
2006:02:02-20:01:57 (none) selfmonng[626]: child returned status: exit='0' signal='0'
2006:02:02-20:02:13 (none) selfmonng[626]: check Failed increment snort_inline_running counter 1 - 3
2006:02:02-20:02:18 (none) selfmonng[626]: check Failed increment snort_inline_running counter 2 - 3
2006:02:02-20:02:23 (none) selfmonng[626]: check Failed increment snort_inline_running counter 3 - 3
2006:02:02-20:02:23 (none) selfmonng[626]: DEBUG: NOTIFYEVENT Name=snort_inline_running Level=INFO Id=115 suppressed
2006:02:02-20:02:23 (none) selfmonng[626]: triggerAction: 'cmd'
2006:02:02-20:02:23 (none) selfmonng[626]: actionCmd(+): '/var/mdw/scripts/snort restart'
2006:02:02-20:02:25 (none) selfmonng[626]: child returned status: exit='0' signal='0'
2006:02:02-20:02:35 (none) selfmonng[626]: check Failed increment snort_inline_running counter 1 - 3
2006:02:02-20:02:40 (none) selfmonng[626]: check Failed increment snort_inline_running counter 2 - 3
2006:02:02-20:02:46 (none) selfmonng[626]: check Failed increment snort_inline_running counter 3 - 3
2006:02:02-20:02:46 (none) selfmonng[626]: DEBUG: NOTIFYEVENT Name=snort_inline_running Level=INFO Id=115 suppressed
2006:02:02-20:02:46 (none) selfmonng[626]: triggerAction: 'cmd'
2006:02:02-20:02:46 (none) selfmonng[626]: actionCmd(+): '/var/mdw/scripts/snort restart'
2006:02:02-20:02:48 (none) selfmonng[626]: child returned status: exit='0' signal='0'


This thread was automatically locked due to age.
Parents
  • 0
    We had an error too.
    It stopped all traffic through our FW and didn't kick over to the HA system.
    Shutting down our primary got traffic going again.
    While I was looking for the cause the second FW performed the up2date and stopped all traffic.
    I logged the problem with Support.
    I shut down IPS and traffic started up again.
    I then got the information from support that the
     "WEB-CLIENT wmf file SetAbortProc arbitrary code execution attempt - ID 5318"
    rule is bad. They said to completely turn he rule off (red light).

    Hope this helps others.

     - steve
    2x IBM 2.6Ghz 1.5Gig  - 6.104 HA
  • 0 in reply to stevec_01
    [ QUOTE ]
    We had an error too.
    It stopped all traffic through our FW and didn't kick over to the HA system.
    Shutting down our primary got traffic going again.
    While I was looking for the cause the second FW performed the up2date and stopped all traffic.
    I logged the problem with Support.
    I shut down IPS and traffic started up again.
    I then got the information from support that the
     "WEB-CLIENT wmf file SetAbortProc arbitrary code execution attempt - ID 5318"
    rule is bad. They said to completely turn he rule off (red light).

    Hope this helps others.

     - steve
    2x IBM 2.6Ghz 1.5Gig  - 6.104 HA 

    [/ QUOTE ]

    OK, i will try this. i thougt, this rule was already before this update in the definiton file?

    Ok, switch this rule off solves the problem. waiting for a fix as soon as possible...
  • 0 in reply to TOHIL
    Nice solution.
    My entire network went off line due to this autoupdate.  WOW!
    Perhaps I'll see if I can prevent automatic updates in the future.

    Thanks for the fix.
  • 0 in reply to SalishSwede
    [ QUOTE ]
    Nice solution.
    My entire network went off line due to this autoupdate.  WOW!
    Perhaps I'll see if I can prevent automatic updates in the future.

    Thanks for the fix. 

    [/ QUOTE ]

    Shame on the astaro testing team
  • 0 in reply to TOHIL
    I must agree.

    I have an ASG 220 that was affected this morning. No WAN +  mission critical servers behind the DMZ were also affected for no apparent reason since WebAdmin and the ADSL modem were functionnal.
    I was lucky I had a recent config backup so no time was wasted and I was able to recover quickly. A backup made before the 5318 appeared, so it was off by default after the restore. But if the forum hadn't been there, I would have probably re-enabled the rule and cause another major "hang". 
    TOHIL , you're right about the rule already there before the february 1st up2date.  It was active on my ASG since it first appeared and didn't cause any problems before. If I review the latest ruleset_changes.txt before the actual crash, the 5318 doesn't appear, neither in the new, updated nor deleted sections.  So why is it affecting Snort now ...today ?  Anyone have a clue ? 

    I've noticed that 3 deamons went out right after this morning up2date : hyperdyper, middleware and Snort of course.
    Anyone else have noticed this ?  Specially the first .

    Anyway, let's hope for some stronger up2date push in the future. 

    Cheers,



    ** Still keeping the old Watchguard X1000 close, because you never know when you'll need it [:P] ** 
Reply
  • 0 in reply to TOHIL
    I must agree.

    I have an ASG 220 that was affected this morning. No WAN +  mission critical servers behind the DMZ were also affected for no apparent reason since WebAdmin and the ADSL modem were functionnal.
    I was lucky I had a recent config backup so no time was wasted and I was able to recover quickly. A backup made before the 5318 appeared, so it was off by default after the restore. But if the forum hadn't been there, I would have probably re-enabled the rule and cause another major "hang". 
    TOHIL , you're right about the rule already there before the february 1st up2date.  It was active on my ASG since it first appeared and didn't cause any problems before. If I review the latest ruleset_changes.txt before the actual crash, the 5318 doesn't appear, neither in the new, updated nor deleted sections.  So why is it affecting Snort now ...today ?  Anyone have a clue ? 

    I've noticed that 3 deamons went out right after this morning up2date : hyperdyper, middleware and Snort of course.
    Anyone else have noticed this ?  Specially the first .

    Anyway, let's hope for some stronger up2date push in the future. 

    Cheers,



    ** Still keeping the old Watchguard X1000 close, because you never know when you'll need it [:P] ** 
Children
  • 0 in reply to Stealth
    Update:
    I also found this in my IPS logs:
    FATAL ERROR: Warning: /etc/snort/rules/astaro.rules(3857) => Unknown keyword 'group = web-client sid' in rule!

    Then everything stops.
    (this is a different rule than the one being referenced by support)
    I don't like the idea of turning off updates, but it would be nice to have finer control over what gets updated. The all sigs or none could be broken up.

     - steve
  • 0 in reply to stevec_01
    Same here stevec, but different numbering :
    FATAL ERROR: Warning: /etc/snort/rules/astaro.rules(3732) => Unknown keyword 'group = web-client sid' in rule!
    It showed up a couple of hundred times (looping) between the actual up2date at around 6:00 AM here and the time  I did the first restore.

    The numbering doesn't follow the ruleset_changes.txt in here either. Yours (3857) and mine are not listed in this morning's update.

    So is it really the wmf vulnerability signature that caused all of this, or is there something else ? Anyone had a recent conversation with support ?