SNORT backup solution



  • I recently tried to restore a 2.1 backup after a hard drive failure and I discovered my Snort config wasn't there.

    Can anyone suggest a way to keep the snort settings when you have to restore?



  • @bwlinux:

    I recently tried to restore a 2.1 backup after a hard drive failure and I discovered my Snort config wasn't there.

    Can anyone suggest a way to keep the snort settings when you have to restore?

    All the Snort configuration is stored in the config.xml file.  Did you do regular backups of the config.xml file from Diagnostics…Backup/Restore?  And did you do one or more backups after you installed the Snort package?  If the answer to the first two questions is "yes", and you still didn't get the Snort configuration back from the restore, then make sure that on the Backup/Restore page the box for Do Not Backup Package Information is not checked (or in other words, you DO want to backup package information in order to get the Snort configuration saved).

    Oh, and one point I should mention.  When recovering from something like a hard-drive crash, then Snort's configuration information would get restored with the config.xml file restore, but the actual binary and PHP files that drive the GUI may not.  You might need to reinstall the Snort package from System…Packages, and then restore the configuration file one more time.  I have never actually done a bare-metal restore with pfSense and a backup config.xml file, so I'm not sure how it would behave.  My own personal experience was migrating to a completely new machine.  For that, I installed pfSense, installed my packages again, and then restored my backed up config.xml.  Everything was restored that way.

    Bill



  • thanks bmeeks,

    "Do not backup package information" definitely is NOT checked when I make backups. That would be sort of silly for my objective.  I do check the "Do not backup RRD data" though because I honestly don't care if I lose that.

    After digging into a fresh config.xml backup file, I found the path using an XML editor
    xml->pfsense->installedpackages->snortglobal

    The settings are there. I went back and looked at several older config backups that I've ran previously.  And the same thing, the settings are there.

    However, when I ran the restore process that section does not get restored.  I'm going to test it on some fresh installs in a VM but I believe there is a current problem related to restoring the configuration related to the SNORT package.
    platform: 2.1-Release(amd64)

    BTW: In my experience with the 2.x series, it's not necessary to install the packages prior to running the restore unless you are just trying to add time to the billing clock. The restore process removes any installed package and re-installs it.

    Brian



  • @bwlinux:

    thanks bmeeks,

    "Do not backup package information" definitely is NOT checked when I make backups. That would be sort of silly for my objective.  I do check the "Do not backup RRD data" though because I honestly don't care if I lose that.

    After digging into a fresh config.xml backup file, I found the path using an XML editor
    xml->pfsense->installedpackages->snortglobal

    The settings are there. I went back and looked at several older config backups that I've ran previously.  And the same thing, the settings are there.

    However, when I ran the restore process that section does not get restored.  I'm going to test it on some fresh installs in a VM but I believe there is a current problem related to restoring the configuration related to the SNORT package.
    platform: 2.1-Release(amd64)

    BTW: In my experience with the 2.x series, it's not necessary to install the packages prior to running the restore unless you are just trying to add time to the billing clock. The restore process removes any installed package and re-installs it.

    Brian

    I'm not sure why Snort would behave any differently than other package in that regard.  But as I mentioned, I have never tried a bare-metal type of restore with pfSense.  Does the Snort package never get reinstalled as part of the restore process?  What I mean is, do the binary files get put back down by the restore procedure?  You can look in /usr/local/bin for the snort binary executable.  Do any other packages you have installed come back OK with the restore?

    Bill



  • @bmeeks:

    I have never tried a bare-metal type of restore with pfSense.  Does the Snort package never get reinstalled as part of the restore process?  What I mean is, do the binary files get put back down by the restore procedure?

    I have, just last week.  Everything was restored to the new hardware automagically.  Package download and installation was automatic.  All the previous Snort and Suricata configuration came back just as before.

    This was to 2.1.1 PRE.  I have also rebuilt VM's with a restore and everything came right back.



  • @priller:

    @bmeeks:

    I have never tried a bare-metal type of restore with pfSense.  Does the Snort package never get reinstalled as part of the restore process?  What I mean is, do the binary files get put back down by the restore procedure?

    I have, just last week.  Everything was restored to the new hardware automagically.  Package download and installation was automatic.  All the previous Snort and Suricata configuration came back just as before.

    This was to 2.1.1 PRE.  I have also rebuilt VM's with a restore and everything came right back.

    Thanks Priller.  Do you have any suggestions or ideas for the OP on what his problem could be?  I have no personal experience with this process.

    Bill



  • Perhaps somehow related to the recent package problem?  The packages didn't restore and that part of the config got wiped?  Just a SWAG.

    Diagnostics - Backup/Restore - Reinstall Packages does nothing useful
    https://forum.pfsense.org/index.php?topic=74170.0

    packages.pfsense.org down
    https://forum.pfsense.org/index.php?topic=74167.0

    I just loaded pfs on the virgin drive, then restored the most recent config backup.  The packages downloaded and the config for all the packages was there.



  • Hi!

    I can't confirm for sure, but I think there was a recent issue with snort re-install (I had problem). I could be because I saved config before before snort was upgraded to the latest package (2.9.5.5 or earlier was installed).
    When config was imported on another system, latest version (2.9.5.6) was installed, but could not even start because of corrupted config.
    Unfortunately, I already wiped out and re-configured (manually) the system, which had this problem.
    Also - isn't there an issue restoring x86 config to amd64 system?



  • @dgcom:

    Hi!

    I can't confirm for sure, but I think there was a recent issue with snort re-install (I had problem). I could be because I saved config before before snort was upgraded to the latest package (2.9.5.5 or earlier was installed).
    When config was imported on another system, latest version (2.9.5.6) was installed, but could not even start because of corrupted config.
    Unfortunately, I already wiped out and re-configured (manually) the system, which had this problem.
    Also - isn't there an issue restoring x86 config to amd64 system?

    The Snort configuration section changed significantly with the release of the v3.0.0 package late last year.  So if you have a configuration from an earlier v2.x package version, there may be some issues trying to run with that.  I'm talking more about the GUI package version than the binary version.

    It would be a good idea to always make a configuration backup when upgrading Snort or any other packages to make sure the most current setup is saved.

    Bill



  • Hi!

    That were Snort versions in my post above. Corresponding package versions were 3.0.2 -> 3.0.4.

    Also - on one of the installs I remember upgrading Snort, but Package Manager stil showing me that upgrade is available…



  • @dgcom:

    Hi!

    That were Snort versions in my post above. Corresponding package versions were 3.0.2 -> 3.0.4.

    Also - on one of the installs I remember upgrading Snort, but Package Manager stil showing me that upgrade is available…

    The changes in the configuration from 3.0.2 to 3.0.4 were very minor and should not have caused Snort to not start.  There was a short-lived "oops" with one of the updates where a string did not get updated properly in the package file and that caused an update to not register properly, but that was fixed within a couple of days if I recall correctly.

    Bill



  • Ok, that explains why it still shows as an update even after i updated it. No biggie.

    As for configuration restore issue - no idea what happened exactly, but one problem I had was that interfaces where different between old and new servers - em0 was WAN on old one and em1 was WAN on new one.
    I found that I had to edit backup xml file to match new machine before restore.
    The other issue was that Snort completely refused to download updates.

    As I said, I solved all of this by rebuilding the box and reconfiguring everything manually. Got a much cleaner system then the original one anyway.



  • Thanks for all the replies.

    I've had other fish to fry at other sites so this issue was put on the back burner.

    I suspect the problem may be related to trying to restore a config from the previous version of SNORT.

    Whatever the case, I will test this in my lab before applying any new SNORT updates.

    And I concur that all other packages I use restore just fine to a fresh install (bare metal and VM). That's one of many things I've been doing in the last 72 hours.



  • @dgcom:

    Ok, that explains why it still shows as an update even after i updated it. No biggie.

    As for configuration restore issue - no idea what happened exactly, but one problem I had was that interfaces where different between old and new servers - em0 was WAN on old one and em1 was WAN on new one.
    I found that I had to edit backup xml file to match new machine before restore.
    The other issue was that Snort completely refused to download updates.

    As I said, I solved all of this by rebuilding the box and reconfiguring everything manually. Got a much cleaner system then the original one anyway.

    Yes, changes in interface names will confuse Snort.  It uses the name to distinguish interfaces.  So a change from say "em0" to "le1" would sort of blow Snort's mind since the configuration no longer matches reality.

    I assume you are talking about rule updates with the updates download issue.  If so, that could be because the Snort VRT folks tie rule versions to specific Snort binary versions.  This is completely out of the control of the Snort package on pfSense.  The VRT make it so that say the 2.9.5.5 version of Snort cannot use any rules from the VRT except 2.9.5.5 rules.  You can't use 2.9.5.6, nor can you use 2.9.5.3, as examples.  They also stop supporting older rule versions over time.  Each version of Snort and its matching rules have finite lifetimes.  You may already know all of this, and if so, ignore this post.  But I mention it just in case.  There have been other users that were not aware of the version number lock-ins between the binary and the rules package and wondered why their Snort install would not show the latest rule versions as posted on the Snort VRT web site.

    Bill



  • @bmeeks:

    I assume you are talking about rule updates with the updates download issue.  If so, that could be because the Snort VRT folks tie rule versions to specific Snort binary versions.  This is completely out of the control of the Snort package on pfSense.

    Yes, I am talking about rule download issue. But I wonder how this breaks during restore? It should be downloading rules for whatever version of Snort initiated said download, right? Regardless of what version the restored config was… It restored my oinkmastercode and tried to download something but then complained that checksum was wrong.
    If no one else is suffering this, it might be not important to spend your time on, really. Thank you for you work on this package, Bill.



  • @dgcom:

    @bmeeks:

    I assume you are talking about rule updates with the updates download issue.  If so, that could be because the Snort VRT folks tie rule versions to specific Snort binary versions.  This is completely out of the control of the Snort package on pfSense.

    Yes, I am talking about rule download issue. But I wonder how this breaks during restore? It should be downloading rules for whatever version of Snort initiated said download, right? Regardless of what version the restored config was… It restored my oinkmastercode and tried to download something but then complained that checksum was wrong.
    If no one else is suffering this, it might be not important to spend your time on, really. Thank you for you work on this package, Bill.

    I will take a look at this by playing around in a virtual machine.  It will be a week or two before I have some time, though.  Trying to get the next Snort update out the door and also will be away on a family trip for a week.

    Bill


Log in to reply