Booting stuck on “Restoring contents from RAM store…”
-
Glad to read You!
@Gertjan said in Booting stuck on “Restoring contents from RAM store…”:
@Sergei_Shablovsky said in Booting stuck on “Restoring contents from RAM store…”:
Where and how delete unneeded pfSense caches (and may be some logs also) to be able to start pfSense normally ?
How determine source why SWAP is filled so quickly?
As always : use the console access !
( Or ssh, and use a SSH client like putty and/or WinSCP)and visit every folder and sub folder in /var/
You'll find out quickly what are the big files, and what are the files that grow rapidly.I already using SSH, and VERY useful Termius + SSH Editor (iOS/macOS).
VERY useful apps, take a look!And command
du -h -d 1 /var/logto see
and
yes | rm -IPR /var/log/*to remove all (or the same modified for certain dir)
Btw : the day you've decides to use "Suricata, ntopng" you also signed up a permanent (!), manually ( !) inspection of the folders where these process log. Running out of space with these two - and some others - is a very commun issue.
Hm.
If this is CONSTANTLY EXISTED PROBLEM (but for 7+ years I see this is constant problem that pop-up again and again), may be MUCH BETTER to create redmine ticket to ask Netgate to create settings:
Notifications about dusk space:
When free disk space are below [25%…..]
(You may entering amount of disk space in Gb or %. For example “15%”, “40Gb”)
When size of /var/log system and packages logs directory are more than [40Gb]
(You may entering dir size in “Gb” or “Mb”)If pfSense admin are serious about their pfSense installation, BOTH LICAL LOGGING and LIGGING ON REMOTE SERVER ARE MUST HAVE!
You have a 124G SSD : why use a RAM disk ?
Sorry, my mistyping. HDD on this pfSense.
-
@stephenw10 said in Booting stuck on “Restoring contents from RAM store…”:
Yup, I would argue you don't need a RAM disk at all.
But /var on SSD in comparison with RAM are MORE slower.
Am I wrong ?
-
It is slower but it's not usually significantly. It can help a lot on slow storage like CF cards but SSDs are already fast enough that the you're unlikely to see much difference.
-
@stephenw10 said in Booting stuck on “Restoring contents from RAM store…”:
It is slower but it's not usually significantly. It can help a lot on slow storage like CF cards but SSDs are already fast enough that the you're unlikely to see much difference.
Even on 10G throughput with snort/suricata and a lot of logging ?
-
Well as far as I know, yes. But I've never tested that directly. I doubt the logging would be slowing anything there though. Running Snort against that is going to be slower.
-
@stephenw10 said in Booting stuck on “Restoring contents from RAM store…”:
Well as far as I know, yes. But I've never tested that directly. I doubt the logging would be slowing anything there though. Running Snort against that is going to be slower.
Ok, thank You!
When traffic would be rising up. of coarse, I remove Snort/Suricata on SEPARATE server where incoming traffic from all WLANs would be mirrored.
But I need to be sure that Snort/Suricata would be able to keep throughput to be able to instructing pfSense creating BLOCK records in a rules...
Did You know great source with detailed explanation how to make this installation: pfSense on one bare metal server + Snort/Suricata on other bare metal server ?
—
CLOSE SKY FOR UKRAINE https://youtu.be/_tU1i8VAdCo !
Help Ukraine to resist, save civilians people’s lives !
(Take an active part in public protests, push on Your country’s politics, congressmans, mass media, leaders of opinion.) -
Hmm, not sure I've seen that specifically. I'm not sure how you would arrange the block rules to be sent between them. The pfSense Snort package includes some custom code to make that happen.
-
@Sergei_Shablovsky said in Booting stuck on “Restoring contents from RAM store…”:
But I need to be sure that Snort/Suricata would be able to keep throughput to be able to instructing pfSense creating BLOCK records in a rules...
This is not possible. Neither package supports "remote" blocking. The code in the pfSense packages is written to communicate with only the local
pffirewall engine.What you could do with Suricata (or Snort) is use the standard FreeBSD package (not the GUI version provided with pfSense) and configure the package to use Inline IPS Mode on the separate server. All management and interaction would have to be done on the local server through the shell interface as there would be no GUI. You would use two NIC ports on the separate server and connect them inline between the pfSense LAN connection and the master LAN switch. But this configuration is totally outside of pfSense and you would be on your own to configure it. And I would suggest going this route that you use Linux on the separate server and install a Suricata package from the packages tree for the particular Linux distro you choose. With Linux you have the option of using DPDK or AF_PACKET for the IPS mode in Suricata. With Snort you are limited to an older netmap interface.
-
Thank You for detailed answering!
@bmeeks said in Booting stuck on “Restoring contents from RAM store…”:
@Sergei_Shablovsky said in Booting stuck on “Restoring contents from RAM store…”:
But I need to be sure that Snort/Suricata would be able to keep throughput to be able to instructing pfSense creating BLOCK records in a rules...
This is not possible. Neither package supports "remote" blocking. The code in the pfSense packages is written to communicate with only the local
pffirewall engine.Thank You for confirming my toughs.
Also I already have a plan on this site (when overall traffic bandwidth goes up, and tuning IDS/IPS rules would be more complete) to take Snort/Suricata out from pfSense itself and leave pfSense only for FW/ROUTE/VPN needs.
What you could do with Suricata (or Snort) is use the standard FreeBSD package (not the GUI version provided with pfSense) and configure the package to use Inline IPS Mode on the separate server. All management and interaction would have to be done on the local server through the shell interface as there would be no GUI.
Clearly understand. Thank You!
You would use two NIC ports on the separate server and connect them inline between the pfSense LAN connection and the master LAN switch.
Please explain me how to realize this in case when for example pfSense server
- have 4 WANs (working simultaneously, balanced by Tiers);
- have 8 LANs (office, public web services, etc.)
Is this mean on this separate Snort/Suricata server I need 16 (2 x 8, for inspecting traffic) + 1 for SecAdmins management?
But this configuration is totally outside of pfSense and you would be on your own to configure it. And I would suggest going this route that you use Linux on the separate server and install a Suricata package from the packages tree for the particular Linux distro you choose. With Linux you have the option of using DPDK or AF_PACKET for the IPS mode in Suricata. With Snort you are limited to an older netmap interface.
Why exactly Linux (and which one ? RHEL, Debian?) and not FreeBSD ?
Thank You so much for detailed answering!
Have a nice day! -
@Sergei_Shablovsky said in Booting stuck on “Restoring contents from RAM store…”:
Is this mean on this separate Snort/Suricata server I need 16 (2 x 8, for inspecting traffic) + 1 for SecAdmins management?
Yes. It will take two separate NIC ports per pathway to implement. Think of it as a transparent firewall "bridge" of sorts. Suricata sits between two NIC ports (directly) and either forwards or drops particular packets between those two ports.
You could consider splitting the load across two mostly identical servers (4 complete pathways on each server). 8 Suricata instances inspecting a lot of traffic against many rules is going to be resource intensive. Splitting that across multiple servers might work better performance wise. You will want multi-queue NICs and high core-count CPUs and lots of RAM.
@Sergei_Shablovsky said in Booting stuck on “Restoring contents from RAM store…”:
Why exactly Linux (and which one ? RHEL, Debian?) and not FreeBSD ?
Mostly because Suricata is primarily developed and debugged on Linux platforms and thus has excellent support there. While the Suricata team does compile and test on FreeBSD, they must do that manually because none of their automated testing tools work on FreeBSD. And none of them that I know run Suricata on FreeBSD themselves.
Another reason is that the AF_PACKET interface is quite well established on Linux and less buggy than the netmap interface in FreeBSD.
These are the available IPS options on Linux: https://docs.suricata.io/en/suricata-7.0.5/setting-up-ipsinline-for-linux.html.
I don't think it really matters about the Linux distro. Just choose one you might already be familiar with.
-
Thank You for patience and detailed answering!
So, let’s dive in ;)@bmeeks said in Booting stuck on “Restoring contents from RAM store…”:
@Sergei_Shablovsky said in Booting stuck on “Restoring contents from RAM store…”:
Is this mean on this separate Snort/Suricata server I need 16 (2 x 8, for inspecting traffic) + 1 for SecAdmins management?
Yes. It will take two separate NIC ports per pathway to implement. Think of it as a transparent firewall "bridge" of sorts. Suricata sits between two NIC ports (directly) and either forwards or drops particular packets between those two ports.
Adding 2 multi-CPU is not a problem for us.
More important-
You could consider splitting the load across two mostly identical servers (4 complete pathways on each server). 8 Suricata instances inspecting a lot of traffic against many rules is going to be resource intensive. Splitting that across multiple servers might work better performance wise.
You will want multi-queue NICs and high core-count CPUs and lots of RAM.
@Sergei_Shablovsky said in Booting stuck on “Restoring contents from RAM store…”:
Why exactly Linux (and which one ? RHEL, Debian?) and not FreeBSD ?
Mostly because Suricata is primarily developed and debugged on Linux platforms and thus has excellent support there. While the Suricata team does compile and test on FreeBSD, they must do that manually because none of their automated testing tools work on FreeBSD. And none of them that I know run Suricata on FreeBSD themselves.
Another reason is that the AF_PACKET interface is quite well established on Linux and less buggy than the netmap interface in FreeBSD.
These are the available IPS options on Linux: https://docs.suricata.io/en/suricata-7.0.5/setting-up-ipsinline-for-linux.html.
I don't think it really matters about the Linux distro. Just choose one you might already be familiar with.
