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
Reply Children
  • 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] ** 
  • 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 ?
  • 0 in reply to TOHIL
    [ QUOTE ]
    Shame on the astaro testing team 

    [/ QUOTE ]

    Shame on you for not testing all updates/patches in a test network before deploying to production.
  • 0 in reply to mkofron
    I have to take issue with the last "shame on you" comment.
    There are networks of all sizes and for smaller entworks with fewer resources, there frequently isn't the time or money to test every update that goes into production.  

    It is prefectly reasonable to expect that updates will not cause catastrophic failures of a network.  It is on the other hand, not unreasonable to test many updates, but since this was  only a functionality upgrade akin to a changing virus definitions, it seems like a good practice to make the updates available as soon as possible.  

    [an asside]
    With this in mind, it would be nice to have updates applied with a configurable default setting, like active - block or active - allow.  This way an admin with a smaller network with minimal resources could reduce the time required to implement blocking on these new updates.
  • 0 in reply to mkofron
    [ QUOTE ]
    [ QUOTE ]
    Shame on the astaro testing team 

    [/ QUOTE ]

    Shame on you for not testing all updates/patches in a test network before deploying to production. 

    [/ QUOTE ]

    Testing system updates is a good choice, but do you test every defintion update? like the definitons of your anti virus environment? i don't think so, and it make sense to enable an update routine, wich update this definition files, as fast as possible. 

    de freakiest thing is, that this rule, was not touched in the last up2date.
  • 0 in reply to TOHIL
    ok, the up2date from 3. feb fixed the prob

    Intrusion Protection Ruleset Update
    -----------------------------------
    This file contains the changes in the latest ruleset.

    General information
    -------------------
    -

    New rules
    ---------
    -

    Updated rules
    -------------
        5318 - WEB-CLIENT wmf file SetAbortProc arbitrary code execution attempt (web-client.rules)

    Deleted rules
    -------------
    -