Snort with RAM disk?

michaelschefczyk

Dear all,

Please let me know if there is an issue with package snort when using RAM for /var and /tmp. On some systems, I find that snort will not start and produce log entries similar to this one:

FATAL ERROR: /usr/local/etc/snort/snort_11669_igb0/snort.conf(401) => Unable to open address file /var/db/snort/iprep/emerging-compromised-ips.txt, Error: No such file or directory

Once the file is present, snort will start of course. Rule reloading does work. Without uploading the missing file snort does not start even after many hours including a scheduled reloading of rules. RAM is available in sufficient amounts (16 GB) and the RAM disks are used less than 5 %.

The background is that the availability of ZFS since 2.4 motivated me to reinstall. On four systems, I did replace mirrors of notebook quality HDD which were in constant operation for more than four years by 256 GB SATA SDD by a leading manufacturer offering 10 years limited warranty. I am using ZFS mirrors now.

On two of the systems, snort will start, albeit with some delay, maybe. On two other systems, snort refuses to start for > 12 hours.

Is there a way to avoid this? Is it likely that RAM disk is the cause of this? Should I move back to /var and /tmp on SSD?

Regards,

Michael Schefczyk

bmeeks

Do not use RAM disks with Snort or Suricata. Both packages currently store files in /var/db, and since those directories get erased on each reboot it will confuse Snort and Suricata. You see the "no such file" error message …

/var definitely must be on a regular disk (or SSD). It should be OK to put /tmp on a RAM disk.

Bill

Edit: fix typos

autarkis

meeks,

Is it possible to configure pfsense to create a RAM disk just for /tmp and not /var??

@bmeeks:

Do not use RAM disks with Snort or Suricata. Both packages currently store files in /var/db, and since those directories get erased on each reboot it will confuse Snort and Suricata. You see the "no such file" error message …

/var definitely must be on a regular disk (or SSD). It should be OK to put /tmp on a RAM disk.

Bill

Edit: fix typos

bmeeks

@autarkis:

meeks,

Is it possible to configure pfsense to create a RAM disk just for /tmp and not /var??

I just went and checked the GUI and the answer is "no". I don't see an option in the GUI to split them, so I was in error to suggest it was possible. I don't use the feature and have not looked at that screen for quite some time.

As cheap as conventional disks are today, and with the reliability and durability of the latest SSD devices, I don't really see the utility of creating RAM disks anymore. You certainly don't want to do that with either the Snort or Suricata packages.

Bill

dales

I am running snort with a RAM disk. Details below, bmeeks is welcome to tell me I'm an idiot or point out ways it can be improved.

I'm using the RAM_Disk_Store stuff that's baked into pfsense 2.4.2. I use a script to backup /var/db/snort into /cf/conf/RAM_Disk_Store. pfSense will automatically restore the backup at boot time before snort starts.

I created the script below at /usr/local/etc/rc.d/rc.backup_snort.sh and made it executable. Because the name ends in .sh it will be run automatically at shutdown and boot. [The run at boot is superfluous.]

Improvements that could be made:

I am not calling the script from cron or modifying the snort package to run it after operations that modify /var/db/snort. So in the event of a crash, /var/snort/db is restored to the state of the last clean shutdown, not necessarily the latest state.
Script isn't retained in the config, so if I ever reinstall I'll need to recreate it
Script would need to be modified if I ever switch to Suricata.
Script isn't a proper rc script that takes start and stop args. But since running at boot doesn't hurt…


#!/bin/sh
: ${DBPATH:=/var/db/snort}
: ${CF_CONF_PATH:=/cf/conf}
: ${RAM_Disk_Store:=${CF_CONF_PATH}/RAM_Disk_Store}

# Save the Snort databases to the RAM disk store.
if [ -d "${DBPATH}" ]; then
        echo -n "Saving Snort to RAM disk store...";
        [ -f "${RAM_Disk_Store}/snort.tgz" ] && /bin/rm -f "${RAM_Disk_Store}/snort.tgz"
        if [ ! -d "${RAM_Disk_Store}" ]; then
                mkdir -p "${RAM_Disk_Store}"
        fi
        /usr/bin/tar -czf "${RAM_Disk_Store}/snort.tgz" -C / "${DBPATH#/}/"
        echo "done.";
fi

– Dale

bmeeks

@dales:

I am running snort with a RAM disk. Details below, bmeeks is welcome to tell me I'm an idiot or point out ways it can be improved.

I'm using the RAM_Disk_Store stuff that's baked into pfsense 2.4.2. I use a script to backup /var/db/snort into /cf/conf/RAM_Disk_Store. pfSense will automatically restore the backup at boot time before snort starts.

I created the script below at /usr/local/etc/rc.d/rc.backup_snort.sh and made it executable. Because the name ends in .sh it will be run automatically at shutdown and boot. [The run at boot is superfluous.]

Improvements that could be made:

I am not calling the script from cron or modifying the snort package to run it after operations that modify /var/db/snort. So in the event of a crash, /var/snort/db is restored to the state of the last clean shutdown, not necessarily the latest state.

Script isn't retained in the config, so if I ever reinstall I'll need to recreate it

Script would need to be modified if I ever switch to Suricata.

Script isn't a proper rc script that takes start and stop args. But since running at boot doesn't hurt…
#!/bin/sh
: ${DBPATH:=/var/db/snort}
: ${CF_CONF_PATH:=/cf/conf}
: ${RAM_Disk_Store:=${CF_CONF_PATH}/RAM_Disk_Store}

# Save the Snort databases to the RAM disk store.
if [ -d "${DBPATH}" ]; then
        echo -n "Saving Snort to RAM disk store...";
        [ -f "${RAM_Disk_Store}/snort.tgz" ] && /bin/rm -f "${RAM_Disk_Store}/snort.tgz"
        if [ ! -d "${RAM_Disk_Store}" ]; then
                mkdir -p "${RAM_Disk_Store}"
        fi
        /usr/bin/tar -czf "${RAM_Disk_Store}/snort.tgz" -C / "${DBPATH#/}/"
        echo "done.";
fi
– Dale

You're not an "idiot" … :). Being dumb enough to be called an "idiot" on the forum is a high hurdle to overcome in my view ;D. I generally subscribe to the old "no question is a dumb question" approach.

What you have configured is fine, but my question is "why?". I admit to being biased against RAM disks these days, especially for the Snort and Suricata packages. What does the RAM disk approach buy you? You are sacrificing RAM that could potentially be used by the IPS (whether Snort or Suricata). You also give yourself limited logging space since log files go to /var/log/snort or /var/log/suricata. I can understand the appeal of RAM disks back on the old NanoBSD installs with CF cards, but since NanoBSD is on the way out and SSDs are so cheap and reliable, I fail to see the appeal in the present day.

If you put /tmp on a RAM disk, be sure it has at least 300 MB of free space or you may encounter rules update failures if you run many rules packages. There has to be enough free space on /tmp to download all the enabled rules tarball archives and then expand them during the daily rules update.

Bill

dales

TL;DR: "Why Not?" :)

A couple reasons, neither important:

I am running snort for recreational reasons on a small appliance. Getting it to work on a RAM disk kept me occupied for a few minutes.
My "day job" is HPC systems at extreme scale. In that environment most solutions are stateless root for reliability and performance reasons. Those concerns probably bias how I approach recreational programming.

I think you're correct about average SSD reliability being more than adequate for pfSense deployments. At large scale it's still something we worry about, and my pfSense box had enough RAM, so "why not". As long as pfSense has the option, my OCD side says it should work regardless of which packages I select. It did not, so I fixed it.

Proper fix would probably be for the pfsense base to copy out all of /var/db rather than just /var/db/rrd. The additional directories don't add much space. Or stop providing the RAM disk option. :)