Suricata Update 4.0.13_9 PHP Warnings



  • My Suricata did an update a few days back, and beside from not showing up in the menu's anymore (although I can still access the pages directly), the update gives the following error, same if I try to re-install the package:

    PHP ERROR: Type: 1, File: /usr/local/pkg/suricata/suricata_migrate_config.php, Line: 241, Message: Uncaught Error: Cannot create references to/from string offsets in /usr/local/pkg/suricata/suricata_migrate_config.php:241
    Stack trace:
    #0 /usr/local/pkg/suricata/suricata_post_install.php(185): include()
    #1 /etc/inc/pkg-utils.inc(768) : eval()'d code(1): include_once('/usr/local/pkg/...')
    #2 /etc/inc/pkg-utils.inc(768): eval()
    #3 /etc/inc/pkg-utils.inc(854): eval_once('include_once("/...')
    #4 /etc/rc.packages(74): install_package_xml('suricata')
    #5 {main}
    

    Any ideas?



  • This error is coming from the recent update to PHP 7.2 in pfSense 2.4.4. I will need to send a fix to the pfSense team for them to merge into production. Your configuration must be missing some of the default settings for a few Suricata items in order for this error to be triggered. What previous version of Suricata were you running? Or if you are not sure what the version was, when did you last update Suricata before this most recent update?



  • I don’t recall what the previous version was, but I did install it a few weeks ago after 2.4.4 was out and installed, and everything was running fine at the time.

    I often check for package updates though, so I assume it would be the version that was pushed out before this.



  • The pull request containing the fix for this error is posted here. After it is reviewed, approved and merged by the pfSense team, a new Suricata package version 4.0.13_10 will appear.



  • After I updated to 4.0.13_11, it was all working fine, items are now all back in the services menus etc, but then I noticed today that it wasn’t running.... if I tried to start it, it just stopped again with no errors in the log.

    So I rebooted my pfSense, and the following showed up in the startup log:

    20:28:54 PHP ERROR: Type: 1, File: /usr/local/pkg/suricata/suricata_migrate_config.php, Line: 241, Message: Uncaught Error: Cannot create references to/from string offsets in /usr/local/pkg/suricata/suricata_migrate_config.php:241
    Stack trace:
    #0 /usr/local/pkg/suricata/suricata_post_install.php(185): include()
    #1 /etc/inc/pkg-utils.inc(768) : eval()'d code(1): include_once('/usr/local/pkg/...')
    #2 /etc/inc/pkg-utils.inc(768): eval()
    #3 /etc/inc/pkg-utils.inc(854): eval_once('include_once("/...')
    #4 /etc/rc.packages(74): install_package_xml('suricata')
    #5 {main}
    thrown
    


  • @veldkornet said in Suricata Update 4.0.13_9 PHP Warnings:

    After I updated to 4.0.13_11, it was all working fine, items are now all back in the services menus etc, but then I noticed today that it wasn’t running.... if I tried to start it, it just stopped again with no errors in the log.

    So I rebooted my pfSense, and the following showed up in the startup log:

    20:28:54 PHP ERROR: Type: 1, File: /usr/local/pkg/suricata/suricata_migrate_config.php, Line: 241, Message: Uncaught Error: Cannot create references to/from string offsets in /usr/local/pkg/suricata/suricata_migrate_config.php:241
    Stack trace:
    #0 /usr/local/pkg/suricata/suricata_post_install.php(185): include()
    #1 /etc/inc/pkg-utils.inc(768) : eval()'d code(1): include_once('/usr/local/pkg/...')
    #2 /etc/inc/pkg-utils.inc(768): eval()
    #3 /etc/inc/pkg-utils.inc(854): eval_once('include_once("/...')
    #4 /etc/rc.packages(74): install_package_xml('suricata')
    #5 {main}
    thrown
    

    Can you double-check the date and timestamp for those error messages? That's the error that was fixed in the last package update (4.0.13._11). Maybe you are seeing the error messages logged by the old package version. Another reason I say this is that the ONLY time the suricata_migrate_config.php file is loaded and run is during a package installation. You can't get an error from that file unless the package is being installed/updated again. That does not happen with just a plain-vanilla reboot of the firewall.

    Next question for you is what kind of hardware are you using. Is it by chance a Netgate SG-3100 appliance?

    Finally, look in the suricata.log for the interface and see what's in there. You can find that on the LOGS VIEW tab.



  • @bmeeks said in Suricata Update 4.0.13_9 PHP Warnings:

    Can you double-check the date and timestamp for those error messages? That's the error that was fixed in the last package update (4.0.13._11). Maybe you are seeing the error messages logged by the old package version. Another reason I say this is that the ONLY time the suricata_migrate_config.php file is loaded and run is during a package installation. You can't get an error from that file unless the package is being installed/updated again. That does not happen with just a plain-vanilla reboot of the firewall.

    Next question for you is what kind of hardware are you using. Is it by chance a Netgate SG-3100 appliance?

    Finally, look in the suricata.log for the interface and see what's in there. You can find that on the LOGS VIEW tab.

    I think you’re probably right wrt being the old error. Weird that it showed up in my boot log though....

    I’m using a PCEngines APU2C4.

    I’ve checked the suricata.log but it’s empty... check via the interface and via terminal.



  • @veldkornet
    Go to a command-line prompt and execute this command and post back the results if you can --

    /usr/local/bin/suricata -V
    

    That should print out some version information and exit. See if any error messages appear. If you have an empty suricata.log file for the interface, that would indicate perhaps some needed dependency packages are missing.



  • @bmeeks said in Suricata Update 4.0.13_9 PHP Warnings:

    @veldkornet
    Go to a command-line prompt and execute this command and post back the results if you can --

    /usr/local/bin/suricata -V
    

    That should print out some version information and exit. See if any error messages appear. If you have an empty suricata.log file for the interface, that would indicate perhaps some needed dependency packages are missing.

    This is Suricata version 4.0.6 RELEASE
    


  • That's the expected output. Now try this to start Suricata from the shell prompt --

    /usr/local/etc/rc.d/suricata.sh start
    

    Run that from the command line and give it a few seconds to startup. That should start Suricata on all of your configured interfaces. You should also see some data show up in the suricata.log file for each configured interface.

    If it fails to start, you need to carefully examine the firewall system log and the suricata.log for the interface to see if any messages were logged. It would be extraordinarily rare for Suricata to fail in startup but not log a single message anywhere.



  • It prints out this:

    ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/ipsec /usr/local/lib/mysql /usr/local/lib/nss /usr/local/lib/perl5/5.26/mach/CORE
    32-bit compatibility ldconfig path:
    

    But nothing in the suricata.log

    In the system.log, this is all that it shows:

    Nov 15 22:43:13	SuricataStartup	5237	Suricata START for WAN(8011_igb1)...
    


  • Well, at this point the easiest next step is to remove the Suricata package and reinstall it. You won't lose any settings.

    Go to the Package Manager screen and click the trashcan icon next to Suricata to remove the Suricata package. When that completes, click the Available Packages tab and find the Suricata package and install it again. Be sure to stay on that screen until the entire process completes. It will log the package installation progress on the screen.



  • I tried a reinstall, same result.

    Then I tried a remove, the new install... same result.

    Really weird....



  • Please excuse the following questions, but I have to ask them. Your issue is way out of the ordinary, so I need to get a feel for your experience level.

    How are you determining that Suricata is not running? What are you basing that on?

    Did you go in and configure an interface to use Suricata and save those changes?

    What rule sets (vendor rule archives) did you configure for download (Snort VRT and/or Emering Threats)?

    When you go to the LOGS VIEW tab, what interface are you selecting in the INTERFACE drop-down? Is it the same interface where you have Suricata configured?

    Do you have a /var/log/suricata directory tree? Does the root account have full permissions in that tree?



  • @bmeeks said in Suricata Update 4.0.13_9 PHP Warnings:

    Please excuse the following questions, but I have to ask them. Your issue is way out of the ordinary, so I need to get a feel for your experience level.

    Like I said, it was working... Then I noticed that it was stopped, and I couldn't start it up again.

    How are you determining that Suricata is not running? What are you basing that on?

    0_1542322408120_20181115_223649000_iOS.jpg

    Did you go in and configure an interface to use Suricata and save those changes?

    0_1542322436214_20181115_223739000_iOS.jpg

    What rule sets (vendor rule archives) did you configure for download (Snort VRT and/or Emering Threats)?

    Note that the only reason they are up to date is because they updated when I re-installed.
    0_1542322456692_20181115_223833000_iOS.jpg

    When you go to the LOGS VIEW tab, what interface are you selecting in the INTERFACE drop-down? Is it the same interface where you have Suricata configured?

    0_1542322494793_20181115_223917000_iOS.jpg

    Do you have a /var/log/suricata directory tree? Does the root account have full permissions in that tree?

    0_1542322543380_20181115_224031000_iOS.jpg

    0_1542322552729_20181115_224117000_iOS.jpg

    As extra info, I deleted all of the logs and tried to start suricata again. The suricata.log is re-created, but it's still blank.



  • I've never seen this type of problem before. It appears the Suricata process never even attempts to start up. But the fact you can run it from the command line (at least to print out the version information) would indicate the basic binary is there and installed OK.

    The suricata.log file is now blanked by the shell script when Suricata is started (actually, just before the Suricata binary is called, the log is blanked out). This is to prevent the log from growing unabated with each restart. So the empty log file is sort of expected, but only if the binary never even attempts to start. The very first line in that log file during startup should be the version string information. The fact even that is not there indicates to me the binary never gets called. Very weird indeed.

    Are you configured to use Legacy Mode blocking or Inline IPS Mode blocking? If Inline IPS Mode, try switching to Legacy Mode. I kind of doubt that's going to make a difference, though. At the very least I would expect to see something printed to the suricata.log file during the startup attempt.

    Try this from the command line to actually launch a Suricata session. See what it prints out. To exit the process (if it starts), do a CTRL-C.

    /usr/local/bin/suricata -i igb1 -c /usr/local/etc/suricata/suricata_18011_igb1/suricata.yaml
    

    The above command will launch a Suricata instance using the configuration information in the YAML file given. It should start up and print various stuff to the output screen and then seem to freeze. At that point you can CTRL-C to break out. Post back here with anything you think might be helpful in troubleshooting that you see in the output.



  • @bmeeks

    16/11/2018 -- 00:25:21 - <Error> - [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - Failed to parse configuration file at line 399: did not find expected key
    

    At line 399 though is the following (personality: IDS):

    ###########################################################################
    # Configure libhtp.
    libhtp:
       default-config:
              personality: IDS
         request-body-limit: 4096
         double-decode-path: no
         double-decode-query: no
         uri-include-all: no
    

    Update:
    Fixed those extra spaces in front on "personality". I know yaml's are fussy, so I put it in line with the request-body-limit.

    Weird that it was like that in the first place though...

    However, I see that removing these spaces fixes the issue, and I can start suricata. Although now during my testing, the spaces came back once or twice, and I had to remove them again for it to start.

    Also, the log is now littered with errors. Not sure if it's related, or if it's just the first time I've noticed it...

    16/11/2018 -- 00:52:31 - <Notice> -- This is Suricata version 4.0.6 RELEASE
    16/11/2018 -- 00:52:31 - <Info> -- CPUs/cores online: 4
    16/11/2018 -- 00:52:31 - <Info> -- HTTP memcap: 67108864
    16/11/2018 -- 00:52:31 - <Notice> -- using flow hash instead of active packets
    16/11/2018 -- 00:52:31 - <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Signature combines packet specific matches (like dsize, flags, ttl) with stream / state matching by matching on app layer proto (like using http_* keywords).
    16/11/2018 -- 00:52:31 - <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $HOME_NET any -> $EXTERNAL_NET 1024:65535 (msg:"MALWARE-CNC Win.Trojan.Fakeavlock variant outbound connection"; flow:to_server,established; dsize:267<>276; content:"User-Agent|3A| Mozilla/5.0 (Windows|3B| U|3B| MSIE 9.0|3B| Windows NT 9.0|3B| en-US)|0D 0A|"; fast_pattern:only; http_header; urilen:159; pcre:"/\x2f[A-F0-9]{158}/U"; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:url,www.virustotal.com/file/c49f7dbc036ad0a86df02cbbde00cb3b3fbd651d82f6c9c5a98170644374f64f/analysis/; classtype:trojan-activity; sid:25675; rev:7;)" from file /usr/local/etc/suricata/suricata_8011_igb1/rules/suricata.rules at line 52
    16/11/2018 -- 00:52:31 - <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - previous keyword has a fast_pattern:only; set. Can't have relative keywords around a fast_pattern only content
    16/11/2018 -- 00:52:32 - <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"MALWARE-OTHER Win.Trojan.Zeus Spam 2013 dated zip/exe HTTP Response - potential malware download"; flow:to_client,established; content:"-2013.zip|0D 0A|"; fast_pattern:only; content:"-2013.zip|0D 0A|"; http_header; content:"-"; within:1; distance:-14; http_header; file_data; content:"-2013.exe"; content:"-"; within:1; distance:-14; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:url,www.virustotal.com/en/file/2eff3ee6ac7f5bf85e4ebcbe51974d0708cef666581ef1385c628233614b22c0/analysis/; classtype:trojan-activity; sid:26470; rev:1;)" from file /usr/local/etc/suricata/suricata_8011_igb1/rules/suricata.rules at line 73
    16/11/2018 -- 00:52:32 - <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - previous keyword has a fast_pattern:only; set. Can't have relative keywords around a fast_pattern only content
    

    And a whole lot more tha tthe forum doesn't let me post because it thinks it's spam.



  • @veldkornet said in Suricata Update 4.0.13_9 PHP Warnings:

    @bmeeks

    16/11/2018 -- 00:25:21 - <Error> - [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - Failed to parse configuration file at line 399: did not find expected key
    

    At line 399 though is the following (personality: IDS):

    ###########################################################################
    # Configure libhtp.
    libhtp:
       default-config:
              personality: IDS
         request-body-limit: 4096
         double-decode-path: no
         double-decode-query: no
         uri-include-all: no
    

    Update:
    Fixed those extra spaces in front on "personality". I know yaml's are fussy, so I put it in line with the request-body-limit.

    Weird that it was like that in the first place though...

    I think you have or had corruption in part of your config.xml file related to Suricata. This item (libhtp) is the same thing that was causing the PHP error message you originally reported. This information is stored in the config.xml file as an array, and that array was not existent in your file when it really should have been there. All my fix did was initialize that array if it was missing before attempting to use it. This YAML config error happening with the same item is the connecting link.

    Look carefully on the FLOW/STREAM tab at the configuration engine settings for HTTP. Something is amiss in your setup. Making manual edits to the suricata.yaml file is pointless as that file is overwritten by the GUI code each time you start Suricata from the INTERFACES tab.

    The Invalid Signature errors are expected when using the Snort rules with Suricata. See several of my other posts in this forum in recent threads. Suricata does not understand and thus can't process several Snort rule keywords.