brimdata / build-suricata

Build Suricata for packaging with Brim
8 stars 2 forks source link

suricatarunner.exe failure on Windows Server 2019 #31

Closed philrz closed 4 years ago

philrz commented 4 years ago

I tried testing manually on a scratch Windows Server 2019 Datacenter VM on Google Cloud using the brim12 artifact. This was the error I witnessed:

C:\Users\phil\Desktop\foo\suricata>type \users\phil\Desktop\NTLM-wenchao.pcap | .\suricatarunner.exe
18/11/2020 -- 15:52:04 - <Info> - Running as service: no
18/11/2020 -- 15:52:04 - <Error> - [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - Failed to parse configuration file at line 158: could not find expected directive name

2020/11/18 15:52:04 launchSuricata failed exit status 1
The process tried to write to a nonexistent pipe.

These are the final lines of brim-conf-run.yaml, with the middle one being the line 158 (at least, that's what Notepad++ labels as line 158):

rule-files:
  - C:\Users\phil\Desktop\foo\suricata\var\lib\suricata\rules\suricata.rules
%!(EXTRA string=C:\Users\phil\Desktop\foo\suricata)
philrz commented 4 years ago

I tried running with the new brim13 artifact that has the benefit of the fix in the linked PR. I no longer see the symptom previously shown, but Suricata still seems to fail.

C:\Users\phil\Desktop\suricata-v5.0.3-brim13.windows-amd64\suricata>type \users\phil\Desktop\wrccdc.pcap | .\suricatarunner.exe
18/11/2020 -- 22:57:36 - <Info> - Running as service: no
18/11/2020 -- 22:57:36 - <Notice> - This is Suricata version 5.0.3 RELEASE running in USER mode
18/11/2020 -- 22:57:36 - <Info> - CPUs/cores online: 2
2020/11/18 22:57:36 launchSuricata failed exit status 3221225501
The process tried to write to a nonexistent pipe.

I'm not sure if this is the root cause, but if I try to run suricata.exe by itself, I see a series of DLL error pop-ups one after the other.

image

image

image

image

Since the original top-level title of this issue still seems to apply, I'll just reopen this one rather than start yet another issue.

henridf commented 4 years ago

Hmm. The second failure (DLL errors when you run suricata.exe directly) is to be expected. One thing that suricatarunner.exe does is to set up the environment so that the DLLs that ship with the package are found.

The first failure however is surprising. I had checked that this worked when putting up the PR intended to close this issue, and I just checked again to make sure that I'm not mixing things up, and I can run suricatarunner.exe fine.

This is on a gcloud windows-server-2019-dc-v20201110 host. I've run suricatarunner.exe in cmd, powershell, git-bash, and the google cloud sdk shell, and all worked.

philrz commented 4 years ago

Verified in artifact suricata-v5.0.3-brim14.windows-amd64. As shown in the linked PR, the root cause of the problem was determined to be due to architecture-specific compilation. Now that we've disabled that, I've been able to successfully generate the eve.json from a pcap using the suricata-v5.0.3-brim14.windows-amd64 arfifact.

C:\Users\phil\Desktop\suricata-v5.0.3-brim14.windows-amd64\suricata>type \users\phil\Desktop\wrccdc.pcap | .\suricatarunner.exe
20/11/2020 -- 21:08:45 - <Info> - Running as service: no
20/11/2020 -- 21:08:45 - <Notice> - This is Suricata version 5.0.3 RELEASE running in USER mode
20/11/2020 -- 21:08:45 - <Info> - CPUs/cores online: 2
20/11/2020 -- 21:08:45 - <Info> - Configuring core dump is not yet supported on Windows.
20/11/2020 -- 21:08:45 - <Info> - No 'host-mode': suricata is in IDS mode, using default setting 'sniffer-only'
20/11/2020 -- 21:08:45 - <Info> - eve-log output device (regular) initialized: eve.json
...

C:\Users\phil\Desktop\suricata-v5.0.3-brim14.windows-amd64\suricata>dir eve.json
 Volume in drive C has no label.
 Volume Serial Number is FA0C-5C0F

 Directory of C:\Users\phil\Desktop\suricata-v5.0.3-brim14.windows-amd64\suricata

11/20/2020  09:10 PM       108,540,437 eve.json
               1 File(s)    108,540,437 bytes
               0 Dir(s)  32,966,414,336 bytes free

Thanks @henridf!

henridf commented 4 years ago

As shown in the linked PR, the root cause of the problem was determined to be due to architecture-specific compilation.

And for future reference, the platform that failed with ILLEGAL INSTRUCTION was Intel Broadwell, while on Skylake the binary ran ok.