Upgrade Suricata 4.0.3

bmeeks

@bmeeks:

@The:

Hi Guys,

I noticed the new version for Suricata in package manager, so I clicked on update, but the update failed with an error for some missing files, so had to remove the package and reinstall it again.

also I noticed this log:
12/1/2018 – 18:57:24 - <info>-- Invalid IP() parameter provided in Pass List, skipping...

i'm not sure where () came from but the list is an Alias list, and I didn't have that log in Suricata 4.0.1_1

Best Regards</info>

I suspect this error message might be the result of fixing one of the bugs. There was a logic flaw in how HOME_NET was populated in some circumstances. That warning about the slash means you have an alias or an interface IP that is resolving to "nothing" at run time when written to the configuration. The single slash is what would normally be part of a CIDR network string such as "192.168.1.0/24".

Bill

Hi Bill,
thanks a lot for the reply, and also sorry for the late update,

I'm not sure if I got your explanation about the Invalid IP(), I do have some interfaces with no IP's but those interfaces are not enabled, also the Alias list I have is all Network Alias so even single IP's are added with /32, and if I check the list which is imported by suricata I can see that there is a record with \ which is different from (/), even if I remove it from that list it will be rewritten when I restart Suricata.

one more question please, does the below load look's ok? cause I have Suricata jumps to above 150% and it's only running on WAN interface with no extra settings apart from around 10 ET Rules list enabled, but I do admit that there is alot of traffic passing through this box.

the box is a Dell R430 Server with CPU E5-2603 v4 @ 1.70GHz and 32GB of Memory.
last pid: 25566;  load averages:  2.88,  2.85,  2.96                                                                             
41 processes:  2 running, 39 sleeping
CPU:  1.0% user, 14.9% nice,  5.3% system, 17.8% interrupt, 61.0% idle
Mem: 322M Active, 504M Inact, 2270M Wired, 414M Buf, 28G Free
Swap: 4096M Total, 4096M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
69632 root         11  40   20   768M   687M nanslp  2  95.7H 100.06% suricata
36702 root          1  24    0 12696K  2820K bpf     0  26.6H   7.75% filterlog
I also noticed that I have a lot of the below lines in suricata.log file:
16/1/2018 -- 18:18:56 - <info>-- Flow emergency mode over, back to normal... unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1516123136, ts.tv_usec:1399) flow_spare_q status(): 33% flows at the queue
16/1/2018 -- 18:19:05 - <info>-- Flow emergency mode over, back to normal... unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1516123145, ts.tv_usec:1896) flow_spare_q status(): 39% flows at the queue
16/1/2018 -- 18:19:09 - <info>-- Flow emergency mode over, back to normal... unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1516123149, ts.tv_usec:2995) flow_spare_q status(): 38% flows at the queue
16/1/2018 -- 18:19:14 - <info>-- Flow emergency mode over, back to normal... unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1516123153, ts.tv_usec:997415) flow_spare_q status(): 32% flows at the queue
16/1/2018 -- 18:19:15 - <info>-- Flow emergency mode over, back to normal... unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1516123155, ts.tv_usec:2263) flow_spare_q status(): 42% flows at the queue
16/1/2018 -- 18:19:19 - <info>-- Flow emergency mode over, back to normal... unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1516123159, ts.tv_usec:1779) flow_spare_q status(): 43% flows at the queue</info></info></info></info></info></info> 
is this something I have to worry about or need to fix?

Thanks again for the help.

Let me answer the question about flow emergency mode errors first. You need to go read this document (scroll down to the section on Flow): https://www.aldeid.com/wiki/Suricata/Suricata-yaml-configuration-file. The short answer is on a high-traffic interface you are going to have to increase the flow memcap value substantially from the default. Some info is posted at the link given, plus I suggest some additional Google searches for the terms "suricata flow" "suricata flow memcap" and "suricata flow emergency mode". That search should net you additional information.

I'm sorry I confused the backslash and forward slash in my reply. If you indeed have a backslash, and you can see that backslash listed when viewing the Pass List on the INTERFACE SETTINGS tab (using the View List button), then you need to test by removing things from the list to see where the backslash is coming from. I would suspect an alias, if you have those configured, is the source of the backslash.

Bill

The Sky Heart

Hi Guys,

Thanks you so much @bmeeks I was finally able to find out the issue with the passlist, it was this record ::1 causing it, it was manually added to the Alias list, after removing it didn't see the alert in logs anymore, I also fixed the flow alerts by increasing the memory to 512mb.

but I have another issue now, it seem's that after the daily rules update cron pfsense GUI can't figure out if Suricata is running or not, so it's showing in the GUI that it's stopped for the interface, but checking the service and alert and block logs I can see it's Suricata is running, doing a start from the gui shows it's running again.

is anyone else facing this issue?

bmeeks

@The:

Hi Guys,

Thanks you so much @bmeeks I was finally able to find out the issue with the passlist, it was this record ::1 causing it, it was manually added to the Alias list, after removing it didn't see the alert in logs anymore, I also fixed the flow alerts by increasing the memory to 512mb.

but I have another issue now, it seem's that after the daily rules update cron pfsense GUI can't figure out if Suricata is running or not, so it's showing in the GUI that it's stopped for the interface, but checking the service and alert and block logs I can see it's Suricata is running, doing a start from the gui shows it's running again.

is anyone else facing this issue?

With the latest update I made a change to the GUI code on the INTERFACES tab to make it dynamically show service status. I was copying the same code over into the latest Snort update (since the two packages share most of the same GUI code) and found a couple of mistakes in the logic. So could be that the new dynamic GUI code is getting fooled when Suricata restarts from a rules update. It is likely a cosmetic display issue only.

Now one other thing I've seen folks do that I have strongly recommended AGAINST is use the Service Watchdog package. That package is great, but it does not understand how Suricata and Snort work with multiple processes (one per interface). The package also does not understand how to cope with Suricata restarting after a rules update, and the instant Service Watchdog sees one of the Suricata processes die it immediately executes the shell script to restart. That can really confuse things because Suricata is already restarting itself, so you wind up with multiple processes running on the same interface.

Bill

The Sky Heart

Hi @bmeeks

Thank you so much again for the explanation, I actually added Suricata to watchdog service after noticing this issue, but as you mentioned it doesn't really know how Suricata service work so I was noticing the CPU usage is much higher everytime I manually restart Suricata from the interface tab, I removed it from watchdog now.

Thanks.

bmeeks

@The:

Hi @bmeeks

Thank you so much again for the explanation, I actually added Suricata to watchdog service after noticing this issue, but as you mentioned it doesn't really know how Suricata service work so I was noticing the CPU usage is much higher everytime I manually restart Suricata from the interface tab, I removed it from watchdog now.

Thanks.

I will fix the GUI issue with showing the status correctly on the INTERFACES tab. Probably will be sometime next week, though, before I can get it put together and posted.

Bill