Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Snort - not starting anymore

    Scheduled Pinned Locked Moved pfSense Packages
    28 Posts 3 Posters 7.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ?
      Guest
      last edited by

      Hi again!

      I updated pfSense (2.15. nano serial 4GB) to the latest snort some days ago by un-installing and re-stalling snort without obvious problems.

      Since yesterday there were no alarms or blocked sites at the snort tabs, although updates were apparently successfully installed. I did a reboot, afterwards snort did not start again:

      Nov 8 20:52:29 snort[14552]: FATAL ERROR: OpenAlertFile() => fopen() alert file /var/log/snort/snort_re055504/alert: No such file or directory
      Nov 8 20:52:28 SnortStartup[14352]: Snort START for OPT1(55504_re0)…
      Nov 8 20:52:28 snort[13507]: FATAL ERROR: OpenAlertFile() => fopen() alert file /var/log/snort/snort_re247470/alert: No such file or directory
      Nov 8 20:52:28 SnortStartup[13273]: Snort START for LAN fam(47470_re2)…
      Nov 8 20:52:28 snort[12811]: FATAL ERROR: OpenAlertFile() => fopen() alert file /var/log/snort/snort_re159777/alert: No such file or directory
      Nov 8 20:52:27 SnortStartup[12644]: Snort START for WAN(59777_re1)…
      Nov 8 20:49:35 snort[46689]: FATAL ERROR: OpenAlertFile() => fopen() alert file /var/log/snort/snort_re055504/alert: No such file or directory
      Nov 8 20:49:35 SnortStartup[46667]: Snort START for OPT1(55504_re0)…
      Nov 8 20:49:35 snort[46061]: FATAL ERROR: OpenAlertFile() => fopen() alert file /var/log/snort/snort_re247470/alert: No such file or directory
      Nov 8 20:49:35 SnortStartup[45842]: Snort START for LAN fam(47470_re2)…
      Nov 8 20:49:35 snort[44977]: FATAL ERROR: OpenAlertFile() => fopen() alert file /var/log/snort/snort_re159777/alert: No such file or directory
      Nov 8 20:49:34 SnortStartup[44846]: Snort START for WAN(59777_re1)…

      Forced a rules update (paid oink VRT, Community, ET rules), did another reboot, switched to other slice without success, snort is not coming up again.

      The /var/log/snort looks like given below

      Any suggestions what to do (besides switching to a full install)?  ;-)

      Many thanx in advance

      chemlud
      ![snort fail.JPG_thumb](/public/imported_attachments/1/snort fail.JPG_thumb)
      ![snort fail.JPG](/public/imported_attachments/1/snort fail.JPG)

      1 Reply Last reply Reply Quote 0
      • ?
        Guest
        last edited by

        Package reinstall for snort. Appears to be up and running again…

        Which process deleted the directories in /var/log/snort ?  :o

        1 Reply Last reply Reply Quote 0
        • bmeeksB
          bmeeks
          last edited by

          Well, as you said, my recommendation is moving to a full install on a conventional hard disk and abandon Nano.  It seems to give all the packages trouble.

          Since I do not have a Nano install to test on, I am a bit hamstrung trying to make the Snort package behave better on Nano.  Does anyone know if I can fool NanoBSD into installing on a VMware virtual machine?  I have never tried.  Or does someone have a Nano-capable piece of hardware they want to donate to the effort so I can test Snort and Suricata on a Nano install?

          Bill

          1 Reply Last reply Reply Quote 0
          • ?
            Guest
            last edited by

            my three boxes are all "productive" and the shipping to the US would kill me anyways… what would be the minimum hardware requirements for such a box? could I order somefing for you at amazon? :-)

            chemlud

            ....PS: I don't remember if I ever tried to boot a CF card from a USB-card reader device plugged in to a notebook. Could give it a try...

            PPS: 2.1.5 nano vga 4gb on CF-card with card reader: boot process stops at

            Trying to mount root from ufs:/dev/ufs/pfsense0

            "ROOT MOUNT ERROR"

            (...same issue as with USB-stick...)

            PPPS: Pressing "3" (booting from USB device) and it runs like a charm, apparently...

            1 Reply Last reply Reply Quote 0
            • bmeeksB
              bmeeks
              last edited by

              @chemlud:

              my three boxes are all "productive" and the shipping to the US would kill me anyways… what would be the minimum hardware requirements for such a box? could I order somefing for you at amazon? :-)

              chemlud

              ....PS: I don't remember if I ever tried to boot a CF card from a USB-card reader device plugged in to a notebook. Could give it a try...

              PPS: 2.1.5 nano vga 4gb on CF-card with card reader: boot process stops at

              Trying to mount root from ufs:/dev/ufs/pfsense0

              "ROOT MOUNT ERROR"

              (...same issue as with USB-stick...)

              PPPS: Pressing "3" (booting from USB device) and it runs like a charm, apparently...

              Having never used Nano, I honestly don't know what the specs should be.  As far as Snort goes, the problems seem to occur during installs and updates and not during run times, so the box would not need to be much in terms of CPU or RAM.  What I mean is there is no need for large amounts of RAM or a super fast CPU if the only requirement is install and Snort starting up successfully and updating successfully.

              The best thing is if I can get it running in a VM.  I will try that first.  I never have tried before.  Will have to research if it is even possible to fool it like that.

              Bill

              1 Reply Last reply Reply Quote 0
              • ?
                Guest
                last edited by

                Believe, me you will like nano from the very first moment, the two slices are pretty cool!  8)

                I have set /tmp to 450 MB and /var to 250 MB under System/Advances/Misc…

                chemlud

                If you need real hardware and it's too much for me alone, maybe some nano users want to join, could check this, if necessary...

                1 Reply Last reply Reply Quote 0
                • ?
                  Guest
                  last edited by

                  After signature update yesterday evening the same problem: No alarms any more. Reboot: Snort does not start due to same error as posted above. Switching slice to copy made yesterday: Same errors (how can that be?).

                  Next try: A new CF-card. But for me it look like someone is messing up the updates to inactivate snort. That's not funny.

                  1 Reply Last reply Reply Quote 0
                  • bmeeksB
                    bmeeks
                    last edited by

                    @chemlud:

                    After signature update yesterday evening the same problem: No alarms any more. Reboot: Snort does not start due to same error as posted above. Switching slice to copy made yesterday: Same errors (how can that be?).

                    Next try: A new CF-card. But for me it look like someone is messing up the updates to inactivate snort. That's not funny.

                    I did some Google research yesterday.  Here is the deal as I currently understand it:

                    There are some tricks that will allow a NanoBSD install into a VMware VM.  So I could test without needing physical hardware.

                    However, after learning some more during my research about how Nano actually works, I see what the problem is and there is no easy fix.  The /var partition is a RAM disk that is wiped out with every reboot.  So each time you boot your box, the /var partition starts out fresh and clean (that is, no files or directories are there).  As you have noticed, Snort creates its logging directories in /var upon installation.  It then assumes those directories stay there until the user manually uninstalls the Snort package.  On a conventional full-install setup with a hard disk, that assumption works.  Obviously on Nano with its RAM disk setup for /var, all of Snort's created logging directories are gone after a reboot.  That's why you see those errors about non-existent files and directories.

                    It would require rewriting a lot of the Snort package to fix this, and then the fix would have to store log files in places they really should not be (like on the /usr partition).  It is likely sufficient free space would also then become an issue.

                    So I'm afraid for now that Snort and Suricata are not supported on NanoBSD installs.  If you want to hack it yourself and see what you can get working, then please do and share any results back with me.  Perhaps you may find a way I have not thought about.

                    Bill

                    1 Reply Last reply Reply Quote 0
                    • ?
                      Guest
                      last edited by

                      Hmmm, your suggested mechanism would imply that the error occurs on each and every nano + snort. But it worked fine on 3 boxes for about 1 year now, and the other boxes are doing fine with snort, even when rebooted from time to time.

                      The directories in /var/log are created during starting-up snort.

                      The problem occurs during rules updates, something is messed up, from time to time. Don't know where or what, I'm only a user, not an IT pro…

                      1 Reply Last reply Reply Quote 0
                      • bmeeksB
                        bmeeks
                        last edited by

                        @chemlud:

                        Hmmm, your suggested mechanism would imply that the error occurs on each and every nano + snort. But it worked fine on 3 boxes for about 1 year now, and the other boxes are doing fine with snort, even when rebooted from time to time.

                        The directories in /var/log are created during starting-up snort.

                        The problem occurs during rules updates, something is messed up, from time to time. Don't know where or what, I'm only a user, not an IT pro…

                        The rule updates download the rule tar balls to a directory on /tmp.  The files are unpacked there and then copied to locations on /usr.  There have been users reporting problems running out of space on /tmp during the unzip process.  Those users fixed it by increasing the /tmp partition to at least 80 MB and most to 100 MB.  Perhaps that is happening?

                        I will try to get a Nano install working in a VM so I can see firsthand what might be happening.  I based my earlier remarks on what I learned from some Google research.  As shocking as it sounds, it may in fact be true that I should not believe everything I read on the Internet …  ;D

                        Bill

                        1 Reply Last reply Reply Quote 0
                        • ?
                          Guest
                          last edited by

                          As shocking as it sounds, it may in fact be true that I should not believe everything I read on the Internet …  ;D

                          Wise man! :-D

                          One difference to the other two boxes, which are doing fine: These two have no subscribed oink code, only the free rules sets. One of the few differences I can imagine...

                          1 Reply Last reply Reply Quote 0
                          • bmeeksB
                            bmeeks
                            last edited by

                            @chemlud:

                            One difference to the other two boxes, which are doing fine: These two have no subscribed oink code, only the free rules sets. One of the few differences I can imagine…

                            That should not matter.  There is no difference at all in the download process other than the actual value of the code.  Both use the same URL and download directory, the Oinkcode is passed to Snort.org as a query string.

                            What could factor in, though, is the free space available.  I have not checked the differences in the tarball file sizes between the free and pay rules, but I doubt it would be much of a size difference.

                            So just to be clear:  you have multiple boxes, all on NanoBSD installs, all with the same Snort version, and two of them behave differently than the others.  Is that correct?  If so, are the four exactly the same in terms of CF size, free space on /tmp and /var, version of the Snort package, version of pfSense, etc.?

                            Bill

                            1 Reply Last reply Reply Quote 0
                            • F
                              fragged
                              last edited by

                              After each reboot after installing the latest Snort package, I need to go to Snort settings and save them again to get Snort to load up. It throws an error:

                              
                              SnortStartup[9906]: Snort START for SnortLAN(330_em1)...
                              pfsense snort[10117]: FATAL ERROR: OpenAlertFile() => fopen() alert file /var/log/snort/snort_em1330/alert: No such file or directory
                              
                              

                              Running 2.2 snapshots with ram drive for /var and /tmp so those get wiped on every reboot.

                              1 Reply Last reply Reply Quote 0
                              • bmeeksB
                                bmeeks
                                last edited by

                                @fragged:

                                After each reboot after installing the latest Snort package, I need to go to Snort settings and save them again to get Snort to load up. It throws an error:

                                
                                SnortStartup[9906]: Snort START for SnortLAN(330_em1)...
                                pfsense snort[10117]: FATAL ERROR: OpenAlertFile() => fopen() alert file /var/log/snort/snort_em1330/alert: No such file or directory
                                
                                

                                Running 2.2 snapshots with ram drive for /var and /tmp so those get wiped on every reboot.

                                This is expected behavior when you use the RAM drive.  Those directories are created when you make a "save" to the Snort configuration.  During a reboot, starting of Snort is handled by a shell script instead in /usr/local/etc/rc.d.  That script does not create the logging directories – it just assumes they exist.

                                I guess it would be possible to increase the complexity of the shell script so it creates the directories if missing, but you also will lose all previously logged data, so the ALERTS tab will always come up empty on the reboot.  Same thing for the Barnyard2 unified2 files.

                                Oh, and Snort also stores the IP REP databases and the new Auto-SID management files in /var/db/snort, so all that will be gone after a reboot.  You would need to recreate those from scratch after each reboot.

                                So my real question is what is the draw of running Snort or Suricata on such a limited logging platform?  Are you sending everything off someplace else?

                                Bill

                                1 Reply Last reply Reply Quote 0
                                • ?
                                  Guest
                                  last edited by

                                  All three are 2.1.5 nano serial, two with the latest snort (one ok, one with the problem), the other has snort version 3.1.2 (is located remotely, only updated when I'm physically present).

                                  The two working fine have 1GB RAM, the one with problems 2GB (all Atom systems).

                                  All 4GB Transcend industrial CF cards 200 or 300.

                                  /tmp is set to /var to 250 MB each on the smaller systems (working), the one with the problems has  /tmp set to 450 MB and /var to 250 MB.

                                  Logging: I have a cron job sending the snort log to a local email server. I reboot is not that frequent…

                                  1 Reply Last reply Reply Quote 0
                                  • bmeeksB
                                    bmeeks
                                    last edited by

                                    @chemlud:

                                    All three are 2.1.5 nano serial, two with the latest snort (one ok, one with the problem), the other has snort version 3.1.2 (is located remotely, only updated when I'm physically present).

                                    The two working fine have 1GB RAM, the one with problems 2GB (all Atom systems).

                                    All 4GB Transcend industrial CF cards 200 or 300.

                                    /tmp is set to /var to 250 MB each on the smaller systems (working), the one with the problems has  /tmp set to 450 MB and /var to 250 MB.

                                    How much actual free space is available on /tmp during the update procedure, though?  Could you find that out?  Maybe login via SSH and do a continuous

                                    
                                    df -h
                                    
                                    

                                    while kicking off the rules update from a web session.  Also scour your system logs to see if you are getting any kind of disk messages (particularly about space).

                                    Bill

                                    1 Reply Last reply Reply Quote 0
                                    • F
                                      fragged
                                      last edited by

                                      I'm not running on a "limited system" I just turned on ram drive for my setup way back when. This issue is a new one with the latest Snort package version. The package used to work fine for me before.

                                      Only thing I noticed not working with Snort before was enabling the IP list file thingy from the ET Open ruleset.

                                      1 Reply Last reply Reply Quote 0
                                      • bmeeksB
                                        bmeeks
                                        last edited by

                                        @fragged:

                                        I'm not running on a "limited system" I just turned on ram drive for my setup way back when. This issue is a new one with the latest Snort package version. The package used to work fine for me before.

                                        Only thing I noticed not working with Snort before was enabling the IP list file thingy from the ET Open ruleset.

                                        OK, I was able to get a Nano install working as a VM.  That let me test this out.  What I suspected is true – namely that /var partition is wiped out on each reboot.

                                        I also remembered moving some code to a different place for efficiency, but that move probably opened up this hole on Nano installs.  Some of what the moved code did was create the logging directories.  It was moved to reside with all the other install/save code.  Seeing how Nano works, that likely introduced this problem.

                                        Give me some time to come up with a good fix, and I will post an update for the pfSense devs to review and approve.

                                        Note that this will fix the problem of Snort not starting on a reboot on Nano platforms.  I still have not been able to reproduce chemlud's problem with the rule updates.  I will keep testing, though.

                                        Bill

                                        1 Reply Last reply Reply Quote 0
                                        • ?
                                          Guest
                                          last edited by

                                          As I'm a little busy these days, too, here the RAM RRD graph for the problematic box for this mornings rules update starting at 9:00-something and taking about half an hour to complete…

                                          Hope that helps! If anything else is needed I might find some time next week!

                                          Many thanx for the time spent so far on this issue

                                          chemlud

                                          ![snort update ram.JPG](/public/imported_attachments/1/snort update ram.JPG)
                                          ![snort update ram.JPG_thumb](/public/imported_attachments/1/snort update ram.JPG_thumb)

                                          1 Reply Last reply Reply Quote 0
                                          • bmeeksB
                                            bmeeks
                                            last edited by

                                            @chemlud:

                                            As I'm a little busy these days, too, here the RAM RRD graph for the problematic box for this mornings rules update starting at 9:00-something and taking about half an hour to complete…

                                            Hope that helps! If anything else is needed I might find some time next week!

                                            Many thanx for the time spent so far on this issue

                                            chemlud

                                            The rules update takes up to a half-hour to complete?  That is very unusual.  What is the WAN download speed for the box?  A long update time would be 4 or 5 minutes.  Mine are usually 30 seconds to maybe 90 seconds if both ET and VRT rules update together.  I have a 24 megabits/sec download speed.

                                            Bill

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.