Thank you for your reply! I am using it for my capstone security class. I received it from my professor who holds onto about every ISO he can get ahold of. We are using an outdated version that has known vulnerabilities and have to defend it
Thank you for the reply! Unfortunately i am unable to upgrade due to the rules of the class. I was able to get it running, then it stopped and i can’t get it running again. I saw in another thread that there was a known issue where surricata.pid would become locked and users had to manually delete it. However, when I looked for it, the file wasn’t there and I can’t get it to reappear when i activate the rules and IDS.
The pid file is the Process ID file for the suricata program. The pid file is, or should be created when suricata starts. Therefore you can not create it manually.
Could you check if the pid file is actually still present. It should be killed and removed when suricata stops but I am not sure what would happen if a pid file didn’t get removed for some reason and was already present when suricata tried to start.
The file, if existing, is at /var/run/suricata.pid
first of all, it is good to know that this outdated usage is actually intentional, and not caused by somebody distributing outdated installation media for productive usage. Good luck with that hardening exercise!
The PID problem was fixed in this commit in late 2020. Since it is a rather trivial change to the Suricata initscript, it should be easy to apply that manually.
ah, such non-reproducible issues are always nasty.
Should you decide to run an up-to-date IPFire version sometimes, and the problem persists (I don’t hope so, but no firewall distribution is perfect), please do let us know so we can investigate further on it. Also, should your research uncover any security problems in IPFire that have not been addressed meanwhile, please let us know (via email@example.com) as well.