Hello Michael,
thanks for having a look at suricata and your feedback.
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 “No” rules as default and also “no”
automatic rule updates? I guess we can configure at least 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?
Making the free ruleset of emergingthreads as default is okay for me - ACK.
I'm also fine with doing a weekly ruleset update as default setting.
My personal opinion is, it should be possible to disable the automatic rule update. There are some situations where this feature could be quite usefull, for example if you have only volume limited internet access or even other (which we currently do not have in mind....).
Bugs:
- When I enabled IDS in IPS mode, I checked the box to activate it
and selected the ET ruleset and hit save. Suricata starts but without rules which is definitely not what I wanted. Either the box should be greyed out or the downloader is launched when there are no rules, yet.
- It is possible to enable suricata without selecting any interfaces.
That just wastes RAM and makes it easy to enable it without actually having the protection.
If you agree, I will create tickets for this.
Thanks, fixed.
https://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=ebdd0f9a90...
UI Stuff:
- I think that the settings to enable suricata up to and including
“Traffic analysing” should be in the top box. The second box should only care about the rules. That might even solve the problem described above.
During development I had a very similar idea, of grouping all suricata settings and all which are for the ruleset together into seperate boxes. I dropped this idea, because of some big restrictions of the code and I was afraid of how many work this would be to re-write huge parts of it to get the desired result.
- I find it quite confusing that one has to “Activate Intrusion
Detection System” and then again select IDS or IPS. It doesn’t seem 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 “Activate” and that switches on or off the whole thing, and then a second box that says “monitor only” or something along these lines. That box 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 there is a risk here that people enable IDS and think that they are protected when they are in fact not. I think the “monitor only” checkbox makes this a lot clearer.
Fair enough - I'm going now to rework the current section for choosing the runmode and move from the radio buttons to a select box which will be called "Only monitor traffic" as you suggested and will place it right next to the box where you can enable the whole IPS/IDS system.
- The Traffic Analyzing headline doesn’t make any sense. It should
rather be “Monitored zones” or “Monitored interfaces”. Internet should be RED because it is called RED everywhere else.
ACK
- We will need to grep for Snort everywhere and replace that phrase
with “Intrusion Prevention System”. I do not think that we have to mention suricata here instead. It is confusing when the menu option is called IDS.
Most work on this already should be done, I'll remove the last existing snort entries if I'll found one.
- The menu option should be called IPS instead of IDS I think since
IPS mode is default. Spelled out obviously.
ACK - It should be a very easy task to switch the language string from "Intrusion Detection System" to the desired "Intrusion Prevention System".
Apart from that I have to say that this is really really good work, Stefan. The main thing is: it works. I think this is a huge improvement over what we had in the past and that this is bringing IPFire to the next level. It solves many problems that we didn’t dare to touch because snort was simply badly 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 as possible.
Please feel free to disagree with me above, but please do that via email if possible.
I want to target merging this into next as soon as possible in January. I hope that we can get the things above sorted out over the holidays since it should not be much work.
Best regards,
-Stefan
On 17 Dec 2018, at 19:08, Stefan Schantl <stefan.schantl@ipfire.org
wrote:
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.
Best, -Michael
Hello Michael,
taken from the official suricata.yaml documentation:
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’t need it then...
In my commit, I've disabled the bypass options to exactly prevent from any issuse again with the SNAT packet mark.
Best regards,
-Stefan
Best, -Michael
On 17 Dec 2018, at 14:21, Stefan Schantl < stefan.schantl@ipfire.org
wrote:
Am Sonntag, den 16.12.2018, 21:28 +0100 schrieb Peter Müller:
Hello Stefan,
to be a bit more precise about the NAT issue:
My setup is the IPFire Suricata test VM running in KVM, with two clients (Debian and OpenBSD) directly attached to it.
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).
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.
Let me know whether is is useful or not. :-)
Thanks, and best regards, Peter Müller
Hello Stefan,
back again. :-)
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).
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".
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).
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.
Any outgoing connection is in state "SYN_SENT" if Suricata is active.
A portscan against the firewall (GREEN interface) is not detected, even though ET SCAN ruleset is enabled (used nmap with NSE active).
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.
Thanks again for your work; I hope the feedback can appreciate it somehow. :-)
Let me know if there are questions.
Thanks, and best regards, Peter Müller
Hello Peter,
thanks for testing and your feedback.
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.
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.
The changes can be found in my git repository:
https://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=f5ad510e3c...
I'll upload a fixed image very soon - please keep on testing.
Best regards,
-Stefan