Upgrade Suricata 4.0.3

The Sky Heart

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.

but I'm getting some errors in the logs:

12/1/2018 – 18:56:58 - <notice>-- This is Suricata version 4.0.3 RELEASE
12/1/2018 -- 18:56:58 - <info>-- CPUs/cores online: 6
12/1/2018 -- 18:56:58 - <info>-- HTTP memcap: 67108864
12/1/2018 -- 18:56:58 - <notice>-- using flow hash instead of active packets
12/1/2018 -- 18:56:58 - <error>-- [ERRCODE: SC_ERR_INVALID_YAML_CONF_ENTRY(139)] - malformed integer value for stream.max-sessions: ''

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></error></notice></info></info></notice>

NRgia

Package updated with no issues but I get the same error in the logs:

2/1/2018 – 20:16:46 - <notice>-- This is Suricata version 4.0.3 RELEASE
12/1/2018 -- 20:16:46 - <info>-- CPUs/cores online: 2
12/1/2018 -- 20:16:46 - <info>-- Netmap: Setting IPS mode
12/1/2018 -- 20:16:46 - <info>-- HTTP memcap: 67108864
12/1/2018 -- 20:16:46 - <notice>-- using flow hash instead of active packets
12/1/2018 -- 20:16:46 - <error>-- [ERRCODE: SC_ERR_INVALID_YAML_CONF_ENTRY(139)] - malformed integer value for stream.max-sessions: ''

I searched the forum and I found this from a long time ago https://forum.pfsense.org/index.php?topic=80224.msg437622#msg437622

The solution was a fix</error></notice></info></info></info></notice>

bmeeks

At the moment this error appears to be harmless.


[ERRCODE: SC_ERR_INVALID_YAML_CONF_ENTRY(139)] - malformed integer value for stream.max-sessions: ''

I can't find where in the binary source code it is coming from. I did a "grep max-sessions *" in the source directory tree and found only a single line in one source file with the string, but that line prints a warning and not an error; and it prints a message about it being obsolete and does not say anything about it being malformed.

UPDATE EDIT: Never mind, I found the issue. It is a meaningless error, and I will fix it soon. It is a deprecated parameter and needs to be removed from the /usr/local/pkg/suricata/suricata_yaml_template.inc file. If you want to implement your own fix, edit that file and remove line number 220. It reads like this:


  max-sessions: {$stream_max_sessions}

Bill

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

NRgia

Thank you for investigating.

If I don't use PCRE keyword in any of the sid.conf why I am getting this?

12/1/2018 – 22:24:01 - <error>-- [ERRCODE: SC_ERR_PCRE_PARSE(7)] - parse error, ret -1, string 1,=,0x05,6,relative,bitmask 0x14

Or is not related to sid.conf parsing?

Thanks</error>

bmeeks

@NRgia:

Thank you for investigating.

If I don't use PCRE keyword in any of the sid.conf why I am getting this?

12/1/2018 – 22:24:01 - <error>-- [ERRCODE: SC_ERR_PCRE_PARSE(7)] - parse error, ret -1, string 1,=,0x05,6,relative,bitmask 0x14

Or is not related to sid.conf parsing?

Thanks</error>

That is a Suricata binary error code, and from the looks of the text I'm guessing it is choking on some rule text. This error would not be from the sid.conf parsing as only the GUI does that work and the GUI can't write to the suricata.log file. It can only write to the pfSense system log. From the format of the text you posted, it appears to have been pulled from the suricata.log file for the interface.

Bill

micropone

I got an different issue

![suracata failed.png](/public/imported_attachments/1/suracata failed.png)
![suracata failed.png_thumb](/public/imported_attachments/1/suracata failed.png_thumb)

bmeeks

@micropone:

I got an different issue

This is from a problem with the pkg utility itself that is used to install packages on pfSense. I have never seen this error in my testing using pfSense virtual machines. Do you have /var on a RAMDISK by chance?

You can also try to remove the package and then install it again. I believe that uses a different set of routines within the pkg utiilty.

Bill

NRgia

@bmeeks:

@NRgia:

Thank you for investigating.

If I don't use PCRE keyword in any of the sid.conf why I am getting this?

12/1/2018 – 22:24:01 - <error>-- [ERRCODE: SC_ERR_PCRE_PARSE(7)] - parse error, ret -1, string 1,=,0x05,6,relative,bitmask 0x14

Or is not related to sid.conf parsing?

Thanks</error>

That is a Suricata binary error code, and from the looks of the text I'm guessing it is choking on some rule text. This error would not be from the sid.conf parsing as only the GUI does that work and the GUI can't write to the suricata.log file. It can only write to the pfSense system log. From the format of the text you posted, it appears to have been pulled from the suricata.log file for the interface.

Bill

You're correct, the log is from /var/log/suricata/suricata_interface_name/suricata.log , and I think it's about the rules that are not parsed correctly, but I did not saw this error with previous version, and the selected rules are almost the same(taking in account the updates):

12/1/2018 – 20:16:57 - <error>-- [ERRCODE: SC_ERR_PCRE_PARSE(7)] - parse error, ret -1, string 1,=,0x05,6,relative,bitmask 0x14

I attached an unaltered log if you have time to look over it.

If you say it's nothing to worry about, then I can rest easy.

Thank you for your time.

OP @The Sky Heart , sorry for hijacking the thread, did you solve your issue?

suricata.log.txt</error>

bmeeks

@NRgia:

@bmeeks:

@NRgia:

Thank you for investigating.

If I don't use PCRE keyword in any of the sid.conf why I am getting this?

12/1/2018 – 22:24:01 - <error>-- [ERRCODE: SC_ERR_PCRE_PARSE(7)] - parse error, ret -1, string 1,=,0x05,6,relative,bitmask 0x14

Or is not related to sid.conf parsing?

Thanks</error>

That is a Suricata binary error code, and from the looks of the text I'm guessing it is choking on some rule text. This error would not be from the sid.conf parsing as only the GUI does that work and the GUI can't write to the suricata.log file. It can only write to the pfSense system log. From the format of the text you posted, it appears to have been pulled from the suricata.log file for the interface.

Bill

You're correct, the log is from /var/log/suricata/suricata_interface_name/suricata.log , and I think it's about the rules that are not parsed correctly, but I did not saw this error with previous version, and the selected rules are almost the same(taking in account the updates):

12/1/2018 – 20:16:57 - <error>-- [ERRCODE: SC_ERR_PCRE_PARSE(7)] - parse error, ret -1, string 1,=,0x05,6,relative,bitmask 0x14

I attached an unaltered log if you have time to look over it.

If you say it's nothing to worry about, then I can rest easy.

Thank you for your time.

OP @The Sky Heart , sorry for hijacking the thread, did you solve your issue?</error>

The error message does not give the SID of the rule where the PCRE parsing failed, so troubleshooting that is a challenge. However, remember that each update of the Suricata binary means some things changed in the source code. There are two parts of the Suricata package. The main piece is the command-line driven binary. That code is wholly and totally supported by the upstream team at Suricata.org. The secondary piece of the Suricata packge on pfSense is a GUI program that interacts with the user. The GUI code ultimately just winds up writing the suricata.yaml file used to send configuration information to the binary.

So why am I going into this detail? It is to make sure users understand that Suricata, and Snort, along with most every other package on pfSense, has an underlying binary piece that does the real work; and a GUI piece used to gather configuration input and pass it to the underlying binary. Sometimes, based on questions and bug reports I see, it seems users conflate the two pieces of a package and make them into one. For example, I can't do anything about issues within the Suricata binary itself. This particular error is one of those. It is a problem in the binary that probably got introduced in version 4.0.3 of the binary. Previously we were running the older 4.0.1 version of the Suricata binary. Sometimes changes in the binary require changes in the GUI, though. The other error posted about an invalid integer value for "stream.max-sessions" is one of those. The newer 4.0.3 binary no longer wants to see that parameter, but the older version did still want to see it.

Bill

NRgia

Actually this is the idea behind pfSense and GUI packages. The user can do the config by CLI also, but it's more work.

IMHO in SDLC when you test integrated pieces of code you don't always know(from returned errors) were the root cause is, if you're not the one who maintained the GUI or the binary. It could be with a bad config from my part, or maybe the config that is passed to the binary is misinterpreted, due to code change in GUI or binary.

I consider you responded my question, by pointing which of the pieces is the culprit.

For binary issues I can take it on the Suricata redmine, or with the maintainer on Fresh Ports.

Thank you

bmeeks

@NRgia:

I consider you responded my question, by pointing which of the pieces is the culprit.

For binary issues I can take it on the Suricata redmine, or with the maintainer on Fresh Ports.

Thank you

Yes, my opinion is the binary is the cause of your error message. I recommend posting a bug report on Suricata redmine as the Fresh Ports maintainer is really just using the code from Suricata upstream with no changes. If it is a binary bug, it needs to be reported and fixed by the actual Suricata team. I guess there is an outside chance it's a problem with the syntax of some rule, but since the GID:SID is not provided in the error it will be hard to locate the offending rule. Maybe you could try "grep" with some of the content text from the error and locate the rule ???. You can find the actual file of enabled rules here:

/usr/local/etc/suricata/suricata__interface_/rules/suricata.rules

where "interface" will be the physical interface name on your firewall plus a UUID random number.

Bill

drewsaur

Will the update GUI package be coming out anytime soon? I am still showing that 4.0.1_1 is current for my box.

fgro

Well folks, i am a bit disappointing with the current release of suricata 4.0.3 due it has a performance issue since upgrading.

*green shows idle, *yellow shows user

Upgrade to recent version / snort with barnyard2 was enabled
shutdown of snort barnyard2 & reenabled it
shutdown of snort at all and reenabled barnyard2 within suricata package on only 2 interfaces as it would rise up to 99% load at 4 nics

CPU: 47.5% user, 0.0% nice, 16.8% system, 0.2% interrupt, 35.5% idle
Mem: 1608M Active, 1758M Inact, 1011M Wired, 675M Buf, 3488M Free
Swap: 16G Total, 16G Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
32784 root 1 102 0 561M 489M CPU1 1 11:12 88.10% barnyard2
36442 root 1 102 0 555M 483M CPU2 2 11:11 85.92% barnyard2

so is there a way rolling back to previous suricata version?

all it seems to be a barnyard2 issue with the performance… due suricata itself runs at low load. but after deinstalling suricata and only running snort barnyard2 it opt out the load issue with barnyard2. :-(

fgro

@fgro:

Well folks, i am a bit disappointing with the current release of suricata 4.0.3 due it has a performance issue since upgrading.

*green shows idle, *yellow shows user

Upgrade to recent version / snort with barnyard2 was enabled

shutdown of snort barnyard2 & reenabled it

shutdown of snort at all and reenabled barnyard2 within suricata package on only 2 interfaces as it would rise up to 99% load at 4 nics

CPU: 47.5% user, 0.0% nice, 16.8% system, 0.2% interrupt, 35.5% idle
Mem: 1608M Active, 1758M Inact, 1011M Wired, 675M Buf, 3488M Free
Swap: 16G Total, 16G Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
32784 root 1 102 0 561M 489M CPU1 1 11:12 88.10% barnyard2
36442 root 1 102 0 555M 483M CPU2 2 11:11 85.92% barnyard2

so is there a way rolling back to previous suricata version?

all it seems to be a barnyard2 issue with the performance… due suricata itself runs at low load. but after deinstalling suricata and only running snort barnyard2 it opt out the load issue with barnyard2. :-(

Ok, figured it out - i am using barnyard2 with mysql and snorby - so the fact that some old references where in the table i resettet snorby and voila - barnyard2 is running under normal beheavior.

bmeeks

@fgro:

@fgro:

Well folks, i am a bit disappointing with the current release of suricata 4.0.3 due it has a performance issue since upgrading.

*green shows idle, *yellow shows user

Upgrade to recent version / snort with barnyard2 was enabled

shutdown of snort barnyard2 & reenabled it

shutdown of snort at all and reenabled barnyard2 within suricata package on only 2 interfaces as it would rise up to 99% load at 4 nics

CPU: 47.5% user, 0.0% nice, 16.8% system, 0.2% interrupt, 35.5% idle
Mem: 1608M Active, 1758M Inact, 1011M Wired, 675M Buf, 3488M Free
Swap: 16G Total, 16G Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
32784 root 1 102 0 561M 489M CPU1 1 11:12 88.10% barnyard2
36442 root 1 102 0 555M 483M CPU2 2 11:11 85.92% barnyard2

so is there a way rolling back to previous suricata version?

all it seems to be a barnyard2 issue with the performance… due suricata itself runs at low load. but after deinstalling suricata and only running snort barnyard2 it opt out the load issue with barnyard2. :-(

Ok, figured it out - i am using barnyard2 with mysql and snorby - so the fact that some old references where in the table i resettet snorby and voila - barnyard2 is running under normal beheavior.

Barnyard2 needs a lot of "love" from its developer in the area of SQL statements. It did that with me on Snort so often that I just abandoned using it completely. I had the Barnyard2 and Snorby combination, but those high CPU utilizations while running flawed SQL statements finally exasperated me enough to abandon the Barnyard2 idea.

Bill

bmeeks

@drewsaur:

Will the update GUI package be coming out anytime soon? I am still showing that 4.0.1_1 is current for my box.

It is out. What version of pfSense are you running? It should be showing up for all 2.4.x versions. I'm not so sure about 2.3.x versions because there may be other port dependencies that are not satisifed in that older pfSense tree.

Bill

The Sky Heart

@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.

RonpfS

@bmeeks:

It is out. What version of pfSense are you running? It should be showing up for all 2.4.x versions. I'm not so sure about 2.3.x versions because there may be other port dependencies that are not satisifed in that older pfSense tree.

Bill

Under 2.3.5-RELEASE-p1 (amd64) I have "Update available to 4.0.3"

drewsaur

@bmeeks:

@drewsaur:

Will the update GUI package be coming out anytime soon? I am still showing that 4.0.1_1 is current for my box.

It is out. What version of pfSense are you running? It should be showing up for all 2.4.x versions. I'm not so sure about 2.3.x versions because there may be other port dependencies that are not satisifed in that older pfSense tree.

Bill

As of this evening, the update showed up. FWIW, I am using 2.4.x.

Drew