From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: IPFire meets Suricata - Call for tester Date: Wed, 19 Dec 2018 16:30:46 +0000 Message-ID: In-Reply-To: <1f2821bc88afa25b10917a144d82ab19fefe3557.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7372354954402960401==" List-Id: --===============7372354954402960401== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, So I finally had a closer look at this, too. I have a couple of questions and= would like to propose some changes to the UI: Questions: * Is it a good idea to have =E2=80=9CNo=E2=80=9D rules as default and also = =E2=80=9Cno=E2=80=9D automatic rule updates? I guess we can configure at leas= t Emerging Threats as a good default because they are free. I also think that= when IDS is enabled, the system should update the ruleset by default once a = day. When IDS is enabled, there should be no rule update. * That also leads me to: Should no automatic updates even be an option? Bugs: * When I enabled IDS in IPS mode, I checked the box to activate it and select= ed the ET ruleset and hit save. Suricata starts but without rules which is de= finitely not what I wanted. Either the box should be greyed out or the downlo= ader is launched when there are no rules, yet. * It is possible to enable suricata without selecting any interfaces. That ju= st wastes RAM and makes it easy to enable it without actually having the prot= ection. If you agree, I will create tickets for this. UI Stuff: * I think that the settings to enable suricata up to and including =E2=80=9CT= raffic analysing=E2=80=9D should be in the top box. The second box should onl= y care about the rules. That might even solve the problem described above. * I find it quite confusing that one has to =E2=80=9CActivate Intrusion Detec= tion System=E2=80=9D and then again select IDS or IPS. It doesn=E2=80=99t see= m to make much sense even to select the top box when IPS is checked. I would = therefore prefer the following: one box that just says =E2=80=9CActivate=E2= =80=9D and that switches on or off the whole thing, and then a second box tha= t says =E2=80=9Cmonitor only=E2=80=9D or something along these lines. That bo= x should be disabled by default which will run suricata in IPS mode (which is= what everybody wants!) and when checked will downgrade it to IDS mode. Right= now it looks like this is an equal level of both options but I think that th= ere is a risk here that people enable IDS and think that they are protected w= hen they are in fact not. I think the =E2=80=9Cmonitor only=E2=80=9D checkbox= makes this a lot clearer. * The Traffic Analyzing headline doesn=E2=80=99t make any sense. It should ra= ther be =E2=80=9CMonitored zones=E2=80=9D or =E2=80=9CMonitored interfaces=E2= =80=9D. Internet should be RED because it is called RED everywhere else. * We will need to grep for Snort everywhere and replace that phrase with =E2= =80=9CIntrusion Prevention System=E2=80=9D. I do not think that we have to me= ntion suricata here instead. It is confusing when the menu option is called I= DS. * The menu option should be called IPS instead of IDS I think since IPS mode = is default. Spelled out obviously. Apart from that I have to say that this is really really good work, Stefan. T= he main thing is: it works. I think this is a huge improvement over what we h= ad in the past and that this is bringing IPFire to the next level. It solves = many problems that we didn=E2=80=99t dare to touch because snort was simply b= adly integrated into IPFire and did not really do much instead of wasting CPU= cycles and memory. I hope that we can continue working in this direction and maybe add some nice= reports and so on and obviously carry over this work into IPFire 3 as soon a= s possible. Please feel free to disagree with me above, but please do that via email if p= ossible. I want to target merging this into next as soon as possible in January. I hop= e that we can get the things above sorted out over the holidays since it shou= ld not be much work. > On 17 Dec 2018, at 19:08, Stefan Schantl wrot= e: >=20 >> What is the bypass mark for? At least that should be set to nothing >> instead of one, because that will again conflict with the SNAT fix >> rule. >>=20 >> Best, >> -Michael >>=20 > Hello Michael, >=20 > taken from the official suricata.yaml documentation: >=20 > bypass mark and mask can be used to implement NFQ bypass. If bypass > mark is set then the NFQ bypass is activated. Suricata will set the > bypass mark/mask on packet of a flow that need to be bypassed. The > Nefilter ruleset has to directly accept all packets of a flow once a > packet has been marked. Weird. Why would you even pass this to the userspace process then? Whatever, we don=E2=80=99t need it then... >=20 > In my commit, I've disabled the bypass options to exactly prevent from > any issuse again with the SNAT packet mark. >=20 > Best regards, >=20 > -Stefan Best, -Michael >=20 >>> On 17 Dec 2018, at 14:21, Stefan Schantl >>> wrote: >>>=20 >>> Am Sonntag, den 16.12.2018, 21:28 +0100 schrieb Peter M=C3=BCller: >>>> Hello Stefan, >>>>=20 >>>> to be a bit more precise about the NAT issue: >>>>=20 >>>> My setup is the IPFire Suricata test VM running in KVM, with >>>> two clients (Debian and OpenBSD) directly attached to it. >>>>=20 >>>> The Debian machine is located in GREEN, OpenBSD in ORANGE. >>>> RED interface is connected via bridge to my actual testing LAN; >>>> for the first testing, any outgoing traffic to the internet >>>> was allowed (I will test upstream proxy behaviour later). >>>>=20 >>>> While GREEN was using IPv4 range 192.168.100.0/24, with IPFire >>>> as 192.168.100.1, enabling Suricata caused packets coming from >>>> GREEN not to be NATted anymore: Instead of using the firewall's >>>> RED IP for destination, it was the internal GREEN IP. >>>>=20 >>>> Let me know whether is is useful or not. :-) >>>>=20 >>>> Thanks, and best regards, >>>> Peter M=C3=BCller >>>>=20 >>>>> Hello Stefan, >>>>>=20 >>>>> back again. :-) >>>>>=20 >>>>> The new IDS WebUI looks quite good so far - enabling/disabling >>>>> Suricata works as well as selecting the rule source and the >>>>> operation mode (IDS/IPS). >>>>>=20 >>>>> I was also able to download the "Snort/VRT Community" ruleset. >>>>> Trying to switch to the "Emerging Threats" ruleset is possible, >>>>> but downloading its ruleset afterwards is not: The GUI simply >>>>> stalls, printing a message that "Snort (!) is performing a >>>>> task". >>>>>=20 >>>>> The WebUI services page still shows IDS status for each >>>>> interface, >>>>> which does not seem to work anymore (everything is stopped, but >>>>> Suricata was active on RED and GREEN). >>>>>=20 >>>>> Further, a client located in GREEN behind the test firewall >>>>> instance is unable to browse the internet as soon as Suricata >>>>> is >>>>> enabled. If disabled, downloading ET rulesets work as well as >>>>> internet traffic. At the moment, I am flying blind here, but it >>>>> looks >>>>> like packets are not NATted anymore if Suricata is active. >>>>>=20 >>>>> Any outgoing connection is in state "SYN_SENT" if Suricata is >>>>> active. >>>>>=20 >>>>> A portscan against the firewall (GREEN interface) is not >>>>> detected, >>>>> even though ET SCAN ruleset is enabled (used nmap with NSE >>>>> active). >>>>>=20 >>>>> Especially the outgoing connection/NAT/? issue mentioned above >>>>> breaks things in my scenario. Anything else are minor issues >>>>> (of >>>>> course, a portscan should be detected, this needs further >>>>> investigation >>>>> indeed). WebUI works fine so far. >>>>>=20 >>>>> Thanks again for your work; I hope the feedback can appreciate >>>>> it >>>>> somehow. :-) >>>>>=20 >>>>> Let me know if there are questions. >>>>>=20 >>>>> Thanks, and best regards, >>>>> Peter M=C3=BCller >>>>>=20 >>> Hello Peter, >>>=20 >>> thanks for testing and your feedback. >>>=20 >>> I've setup a test environment and was able to re-produce your NAT >>> issue >>> very easy. After some research and help of Michael, we were able to >>> find the real issue. >>>=20 >>> It was located in a identical mark on the packets which already >>> have >>> been scanned by suricata and packets which should be modified for >>> SNAT >>> in the "Mangle" table of the routing logic by the kernel. >>>=20 >>> The changes can be found in my git repository: >>>=20 >>> https://git.ipfire.org/?p=3Dpeople/stevee/ipfire-2.x.git;a=3Dcommit;h=3Df= 5ad510e3c0f416a1507999f5ad20ab171df9c07 >>>=20 >>> I'll upload a fixed image very soon - please keep on testing. >>>=20 >>> Best regards, >>>=20 >>> -Stefan --===============7372354954402960401==--