Upstream has released Suricata 4.1.5 on September 24: https://suricata-ids.org/2019/09/24/suricata-4-1-5-released/ Some of the issues fixed are security issues (though it doesn't identify which). They also made bugfix release 4.1.6 on December 13: https://suricata-ids.org/2019/12/13/suricata-4-1-6-released/ Fedora has issued an advisory for this on October 8: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/PXOZXTDTLS63BEVAZ64VGM4H7TMTO7BJ/
I don't see any security issue, nor anything else worth an update here, closing.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
The upstream announcement explicitly says that some of the fixes are security fixes, even if they didn't go out of their way to identify what those are. I don't see why we can't update it.
There are definitely security fixes in sericata 4.1.6. For example https://suricata-ids.org/2019/12/13/suricata-4-1-6-released/ lists a number of security fixes. For example it mentions fixes for: Bug #3394: TCP evasion technique by overlapping a TCP segment with a fake packet (4.1.x) Bug #3395: TCP evasion technique by faking a closed TCP session (4.1.x) By the way sericata 5.0.1 was recently released and is the current stable release. sericata 4.1.6 is considered to be the old stable release.
CC: (none) => rihoward1
Thanks. Mageia 7 is on the old stable 4.1.x branch, so I'm sure it'll stay there.
Resolution: WONTFIX => (none)Status: RESOLVED => REOPENED
False negatives aren't security issues, just bugs. Anyway, I won't lose time myself here, feel free to provide an update if you want.
Guillaume, Fedora adds some security-related options to the systemd service file. It might be worth taking a look at for Cauldron. I've got the Mageia 7 update handled.
Advisory: ======================== Updated suricata packages fix security vulnerabilities: The suricata package has been updated to version 4.1.6, which fixes security issues and other bugs. See the upstream announcements for details. References: https://suricata-ids.org/2019/09/24/suricata-4-1-5-released/ https://suricata-ids.org/2019/12/13/suricata-4-1-6-released/ ======================== Updated packages in core/updates_testing: ======================== suricata-4.1.6-1.mga7 libhtp2-4.1.6-1.mga7 libhtp-devel-4.1.6-1.mga7 from suricata-4.1.6-1.mga7.src.rpm
Assignee: guillomovitch => qa-bugs
Having a look at this. There is a lot of background reading to do so it could take a while. If it goes nowhere shall throw it back.
CC: (none) => tarazed25
Mageia7, x86_64 Installed suricata packages then updated them. Modified the /etc/suricata/suricata.yaml file according to instructions at https://suricata.readthedocs.io/en/suricata-5.0.1/quickstart.html and ran # suricata-update to get the ET Open ruleset. That failed because module pyyaml was needed. Installed python-yaml and tried again. That succeeded in loading the ruleset into /var/lib/suricata/rules/. Should python-yaml be added as a dependency? # systemctl enable suricata # systemctl start suricata # systemctl status suricata ● suricata.service - Suricata Intrusion Detection Service Loaded: loaded (/usr/lib/systemd/system/suricata.service; enabled; vendor pr> Active: failed (Result: exit-code) since Fri 2020-01-17 20:49:00 GMT; 9s ago Process: 23991 ExecStart=/sbin/suricata -c /etc/suricata/suricata.yaml $OPTIO> Main PID: 23991 (code=exited, status=1/FAILURE) # tail /var/log/suricata/suricata.log 17/1/2020 -- 20:49:00 - <Notice> - This is Suricata version 4.1.6 RELEASE 17/1/2020 -- 20:49:00 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19) 17/1/2020 -- 20:49:00 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19) 17/1/2020 -- 20:49:00 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules 17/1/2020 -- 20:49:00 - <Warning> - [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rule was loaded at all! In suricata.yaml eth0 is enp3s0. The log implies that no rule file can be found. There is a suricata.rules in /var/lib/suricata and no other. All the other rules files live in /etc/suricata/rules The tutorial does not give any help at this stage. It expects the commands to work. So there is something missing - no idea what. Off to cogitate.
The update command (comment 9) placed a new directory /var/lib/suricata/update and a cache subdirectory in that containing a tar.gz file with dozens of "emerging" rules in it. Don't know what to do with that. Copy them to the rules directory?
It does look like a python-yaml dependency should be added. Does using documentation for the correct version help figure out what to do with it? https://suricata.readthedocs.io/en/suricata-4.1.6/
Thanks for the link David. No quickstart guide but there are commandline options as root. # suricata -T 18/1/2020 -- 15:40:09 - <Info> - Running suricata under test mode 18/1/2020 -- 15:40:09 - <Notice> - This is Suricata version 4.1.6 RELEASE 18/1/2020 -- 15:40:22 - <Notice> - Configuration provided was successfully loaded. Exiting. Made sure that suricata was not running and started it in daemon mode but not using systemd. # suricata -D -i enp3s0 18/1/2020 -- 15:50:15 - <Notice> - This is Suricata version 4.1.6 RELEASE # In another terminal: # ps aux | grep suricata root 11557 6.7 1.0 1223188 330156 ? Ssl 15:50 0:15 suricata -D -i enp3s0 # cat /var/run/suricata.pid 11557 # suricata --dump-config [...] mpipe.stack.size10386 = 0 mpipe.stack.size16384 = 0 default-rule-path = /var/lib/suricata/rules rule-files = (null) rule-files.0 = suricata.rules classification-file = /etc/suricata/classification.config reference-config-file = /etc/suricata/reference.config # ls /var/lib/suricata/rules suricata.rules # ls /etc/suricata/ classification.config rules/ suricata.yaml.rpmnew # tail /var/log/suricata/suricata.log [...] 18/1/2020 -- 15:50:15 - <Notice> - This is Suricata version 4.1.6 RELEASE 18/1/2020 -- 15:50:28 - <Notice> - all 8 packet processing threads, 4 management threads initialized, engine started. That all seems to hang together but no clue as to how to proceed from there. # head /var/log/suricata/stats.log ------------------------------------------------------------ Date: 1/18/2020 -- 15:45:05 (uptime: 0d, 00h 00m 21s) That quotes a time earlier than the current invocation - probably not important. Continues with a long list of attributes and their values. I would guess that it is working but am unable to go any further with the tests.
Monitoring the log:- # tail -f /var/log/suricata/fast.log 01/18/2020-15:45:12.929572 [**] [1:2012647:5] ET POLICY Dropbox.com Offsite File Backup in Use [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 162.125.35.135:443 -> 192.168.1.103:56886 01/18/2020-16:00:09.934604 [**] [1:2012647:5] ET POLICY Dropbox.com Offsite File Backup in Use [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 162.125.36.1:443 -> 192.168.1.103:48520 01/18/2020-16:03:20.092538 [**] [1:2012647:5] ET POLICY Dropbox.com Offsite File Backup in Use [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 162.125.64.3:443 -> 192.168.1.103:44288 01/18/2020-16:11:29.420259 [**] [1:2012647:5] ET POLICY Dropbox.com Offsite File Backup in Use [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 162.125.35.135:443 -> 192.168.1.103:56940 I do have a dropbox account.
Found this in the quickstart guide: # curl http://testmyids.com/ uid=0(root) gid=0(root) groups=0(root) The fast.log showed: 01/18/2020-16:24:39.699034 [**] [1:2013028:4] ET POLICY curl User-Agent Outbound [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.103:47364 -> 31.3.245.133:80 01/18/2020-16:24:39.722979 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 31.3.245.133:80 -> 192.168.1.103:47364 Within the limits of my ignorance this appears to be working as expected so it gets a pass.
Whiteboard: (none) => MGA7-64-OK
Keywords: (none) => advisory, validated_updateCC: (none) => tmb, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0043.html
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Two of the issues fixed in 4.1.6 have been assigned CVE-2019-18625 and CVE-2019-18792: https://www.debian.org/lts/security/2020/dla-2087
Summary: suricata new security issue(s) fixed upstream in 4.1.5 => suricata new security issue(s) fixed upstream in 4.1.6