From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH 00/20] Suricata Configuration Updates Date: Sat, 02 Mar 2019 17:19:49 +0000 Message-ID: In-Reply-To: <54A91EB7-56CC-4CA0-9693-A20734124D63@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1464000944943463490==" List-Id: --===============1464000944943463490== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I rebased the whole branch and sent a second patchset with the three remainin= g patches only. Hope that helps and merges. -Michael > On 2 Mar 2019, at 16:52, Michael Tremer wrote: >=20 > Why are you asking me that? >=20 > What does =E2=80=9Cgit am=E2=80=9D tell you? There should be a reason why i= t didn=E2=80=99t work. >=20 > Probably there have been other changes in the section? >=20 > -Michael >=20 >> On 1 Mar 2019, at 19:01, Stefan Schantl wrot= e: >>=20 >>> Hi, >>>=20 >>> Did you apply all of them in order? >>>=20 >>=20 >> Yes, I did. >>=20 >> The reported two patches did not apply. >>=20 >> However, the changes on the second patch depends on modifications of >> the first one, but why does the first one does not apply by using "git >> am" ?=20 >>=20 >>> It is not very helpful to only merge half the patchset. >>>=20 >>> Did you use pwclient? >>>=20 >>> -Michael >>>=20 >>>> On 1 Mar 2019, at 17:09, Stefan Schantl >>>> wrote: >>>>=20 >>>> Hello Michael, >>>>=20 >>>> thanks for working on optimizing the suricata configuration file. >>>>=20 >>>> I've merged all of the patches except number "8" and "10" which >>>> does >>>> not apply with "git am". >>>>=20 >>>> When simple adding the changes with "patch" the changes can be >>>> applied >>>> - any idea why this happened? >>>>=20 >>>> Thanks in advance, >>>>=20 >>>> -Stefan=20 >>>>> I have worked on suricata's configuration. >>>>>=20 >>>>> My objective was to use more system resources (because suricata >>>>> did >>>>> not use much RAM, etc.) >>>>> to make it faster and to be able to have some deeper decoding and >>>>> matching. >>>>>=20 >>>>> Please review these changes and let me know what you think. >>>>>=20 >>>>> All in all, suricata should not use more than 1G of RAM which I >>>>> think >>>>> is a very good >>>>> amount. If your system is weaker than that, there is no point in >>>>> running an IPS. >>>>>=20 >>>>> On my system in my office, this runs with a hand full of rules >>>>> enabled from the >>>>> Emerging Threats Community set at around 110MB of RAM. >>>>>=20 >>>>> Michael Tremer (20): >>>>> Revert "Suricata: detect DNS events on port 853, too" >>>>> suricata: Set max-pending-packets to 1024 >>>>> suricata: Set default packet size to 1514 >>>>> suricata: Set detection profile to high >>>>> suricata: Drop profiling section from configuration >>>>> suricata: Drop some commented stuff from configuration >>>>> suricata: Drop sections that require Rust >>>>> suricata: Configure HTTP decoder >>>>> suricata: Allow 32MB of RAM for DNS decoding >>>>> suricata: Drop parsers I have never heard of >>>>> suricata: We do not use any IP reputation lists >>>>> suricata: Log to syslog >>>>> suricata: Use the correct path for the magic database >>>>> suricata: Use 64MB of RAM for defragmentation >>>>> suricata: Use up to 256MB of RAM for the flow cache >>>>> suricata: Log to syslog like a normal process >>>>> suricata: Increase memory size for the stream engine >>>>> suricata: Disable decoding for Teredo >>>>> suricata: Start capture first and then load rules >>>>> suricata: Fix syntax error >>>>>=20 >>>>> config/etc/syslog.conf | 2 +- >>>>> config/suricata/suricata.yaml | 282 +++++---------------------- >>>>> ----- >>>>> ---------- >>>>> 2 files changed, 30 insertions(+), 254 deletions(-) >>>>>=20 >=20 --===============1464000944943463490==--