2 Replies Latest reply on Sep 20, 2011 3:20 AM by dmease729

    Problems with syslog after NSM upgrade from 5.1.7.7 to 6.1.1.14 (via 5.1.17.7)

    dmease729

      Hi All,

       

      After the NSM upgrade as per the title, the NSM is no longer forwarding syslogs although the configuration seems to still be ok.  I have noted that the syslog configuration options have changed over the versions as follows:

       

      Version 5.0:

      IPS Settings -> Alert Notification -> Syslog

      Between 'severity mapping' and 'Enable IPS quarantine alert' we have:

       

      Forward Alerts by Attack

      Forward Alerts by Severity

       

      Version 6.0:

      IPS Settings -> Alert Notification -> Syslog

      Between 'severity mapping' and 'notify on IPS quarantine' we have:

       

      Send Notification if the attack definition has this notification option explicitly enabled

      Send Notification if the following notification filter is matched (6.0 IPS configuration guide advises that available options are: Allow All, Block All, Severity Informational and Above, Sev Low and above, Sev Med and above, Sev High

       

      Version 6.1:

      IPS Settings -> Alert Notification -> Syslog

      Between 'severity mapping' and 'notify on IPS quarantine' we have:

       

      same options as 6.0, however the only available options we have in the notification filters are: failed only, successful only and in progress only.

       

      ===

       

      On page 167 of the IPS Configuration Guide v6, it advises that we can perform a task of 'configuring alert notification filters' but doesnt have a hyperlink as the other options do.  On searching where to configure these alert notification filters I cannot find anything that advises on how to do so - am I being blind here? 

       

      Any assistance or feedback on this greatly appreciated!

       

      Cheers,

        • 1. Re: Problems with syslog after NSM upgrade from 5.1.7.7 to 6.1.1.14 (via 5.1.17.7)

          I had the same issue.  I tired to work with support but no luck..I had to end up fining a work around, it is lised below.

           

          - perform a full backup

          - install the same version of nsm on a seperate server

          - perform a restore of your full backup

          - upgrade the seperate nsm to version 6

          - uninstall version 5 on your main nsm

          - install version 6 on your main nsm

          - perform a full backup on your seperate nsm after upgrade is complete

          - copy full backup and perform a restore on your main nsm

          • 2. Re: Problems with syslog after NSM upgrade from 5.1.7.7 to 6.1.1.14 (via 5.1.17.7)
            dmease729

            Hi,

             

            Just to confirm, I have also carried out the above.  I did find a little more information out, however, before doing so.  The NSM had been up and running successfully for a while, so I had naively assumed a few things.  After noting that the packet logs download function wasnt working on real-time threat analyzer, *another* issue on the server resulted in the client removing AV and reinstalling.  This fixed the packet log issue, and got me thinking.  It turned out that the AV exceptions were not in place for the NSM app and MySQL directories.  We also had other issues after the above upgrade relating to potential DB corruption issues (noted in ems.log).

            When running the upgrade process on another box (offline, no AV), I also noted that the 6.1 installer advised that I had to run the offline SQL procedures (due to fact that client had > 1 million alerts) after the upgrade.  During the initial upgrade, I did not receive this warning.

             

            So in essence, I believe the main issue was related to the fact that I had not confirmed that the two directories above were configured as AV exceptions (using VSE 8.7i).

             

            All up and running now, though!  I hope this info from sthomas and myself helps others!  (Although on my part, I had done the RTM part, just not the confirming!)

             

            sthomas - just for completeness, could you confirm if AV exceptions were configured correctly on your NSM?  If this wasnt the main cause, then obviously there may be something else out there that could end up catching people out!

             

            Cheers,

             

            Message was edited by: dmease729 on 20/09/11 03:20:17 CDT