Suricata port enabling



  • I am new to Suricata and I have set it up to monitor both WAN and LAN. I was able to start the service on the WAN interface but was not able to start it on the LAN side.



  • I strongly recommend running Suricata on the LAN only, especially for home users and even small business users. Unless you have publicly exposed services like a web server, mail server or DNS server on your network, there is no real security benefit to running the IDS on the WAN. The firewall is going to block all unsolicited inbound traffic by default.

    The benefit of running on your LAN is that you still see the traffic coming and going into your local network, but all the IP addresses you see in alerts for any local hosts will be native instead of all showing up as the WAN public IP. When you run Suricata on the WAN, all of your LAN hosts that are in alerts will show up as the WAN public IP since Suricata sees the traffic after NAT is applied. That makes identifying which local host triggered the alert very difficult. Running on the LAN prevents this problem.

    There will be an error message of some type logged if Suricata is failing to start. Go the LOGS VIEW and open the suricata.log file for the LAN interface. Select LAN in the Interface drop-down and then suricata.log in the Log File drop-down. Post the contents of that log back here for me to see. Or you may notice the error yourself and attempt to correct it.



  • @bmeeks Thank you so much for the explanation. Below is the error message for the log file.

    31/1/2019 -- 19:02:22 - <Error> -- [ERRCODE: SC_ERR_INITIALIZATION(45)] - pid file '/var/run/suricata_mvneta0.409126987.pid' exists but appears stale. Make sure Suricata is not running and then remove /var/run/suricata_mvneta0.409126987.pid. Aborting!

    I deleted the file as suggested by the message and the service is now running.

    Any suggestion on Blocking mode?



  • @markchen said in Suricata port enabling:

    @bmeeks Thank you so much for the explanation. Below is the error message for the log file.

    31/1/2019 -- 19:02:22 - <Error> -- [ERRCODE: SC_ERR_INITIALIZATION(45)] - pid file '/var/run/suricata_mvneta0.409126987.pid' exists but appears stale. Make sure Suricata is not running and then remove /var/run/suricata_mvneta0.409126987.pid. Aborting!

    I deleted the file as suggested by the message and the service is now running.

    Any suggestion on Blocking mode?

    If you are new to operating an IDS/IPS such as Suricata, I would not enable any blocking for at least a week and potentially up to a month. This will give you time to see what types of alerts are happening on your network and give you time to evaluate which are false positives. For false positives, you will want to either disable those rules or suppress alerts using a Suppress List. After you get your rule set tuned, you will probably need to use Legacy Mode with your NIC hardware.

    What kind of hardware are you using? Is it an SG-3100 appliance? If so, look in the System Log of pfSense to see if you see any Signal 10 Bus Error messages. What version of the Suricata package are you running?



  • @bmeeks I have the SG-1100. Suricata version is 4.1.2_3. I do not see any Signal 10 error in system.log



  • @markchen
    I asked because that PID file error is a symptom of Suricata starting and then unexpectedly crashing. When it crashes, it does not clear the PID file and thus on the next start up attempt you get the error you first posted about.

    There were some sporadic issues with Signal 10 crashes with Suricata on ARM hardware, but the last package update was an attempt to fix that.



  • @bmeeks It looks the problem they attempted to fix need a bit more work. Today morning the process stopped again. I will delete the PID file later today and restart the service.

    I have blocking off and its probably a different issue, but for some reason I am being blocked from accessing the Apple App Store.



  • @markchen said in Suricata port enabling:

    @bmeeks It looks the problem they attempted to fix need a bit more work. Today morning the process stopped again. I will delete the PID file later today and restart the service.

    I have blocking off and its probably a different issue, but for some reason I am being blocked from accessing the Apple App Store.

    If it is stopping because of the Signal 10 error, there will be something listed in the pfSense system log about that. That error generates a specific hardware interrupt which the kernel responds to and then logs an appropriate message.

    How many rules do you have enabled? Suricata can consume lots of RAM with many rules enabled. Also look carefully through the suricata.log file to see if there are any warning messages or even errors prior to the end of the log.



  • @bmeeks I went overboard with the rules. I am going to go over each one and disable some.



  • @bmeeks I removed some rules and so far the process is staying on. Thank you very much for your input.