Thanks for all your hard work on this Stefan. I am reporting the results of our testing to date.
Environment: C128 with Suricata from latest posted tarball (2019-03-02)
1. The web interface seems *very* sluggish – checking boxes requires quite a bit of wait time until the check mark appears. Maybe this is normal and to be expected?
2. Runs properly with most websites, with one MAJOR (at least for us) exception – the LogMeIn Central management panel. For those not familiar with this product, it is commonly used in the US to provide remote access for individual users, and management of large groups of computers by companies or managed service providers. With Suricata enabled and the monitor only box unchecked, it is not possible to connect to the remote machine – it freezes when it tries to set up the TLS connection. With Suricata enabled and the monitor only box checked it IS possible to connect to the remote machine. This was never a problem with the previous IPFire intrusion detection system. If you tell me what you want, I can provide copies of logs.
3. In the older intrusion detection system with Guardian installed, bad actors were automatically blocked. With Suricata, even when run for extended periods of time, this never seems to happen. Am I misunderstanding what Suricata is supposed to do?
4. With our typical machine (a Dell R610 12 core Xeon and 12 GB of RAM) it runs very substantially better than the previous intrusion detection system (snort) every did.
I am hoping my issue with the automatic blocking is simply my not understanding how to use Suricata. I really don’t want to have to go back to putting fail2ban back on all of the servers.
Best regards,
Fred
Fred Kienker fkienker@at4b.com
This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify us by reply e-mail or by telephone at 1.770.518.6166, and destroy the original transmission and its attachments without reading them or saving them to disk. This communication is covered by the Electronic Communications Privacy Act, 18 U.S.C. sections 2510-2521. Thank you.
Hello Fred,
thank you for your feedback.
- Runs properly with most websites, with one MAJOR (at least for us) exception – the LogMeIn Central management panel. For those not familiar with this product, it is commonly used in the US to provide remote access for individual users, and management of large groups of computers by companies or managed service providers. With Suricata enabled and the monitor only box unchecked, it is not possible to connect to the remote machine – it freezes when it tries to set up the TLS connection. With Suricata enabled and the monitor only box checked it IS possible to connect to the remote machine. This was never a problem with the previous IPFire intrusion detection system. If you tell me what you want, I can provide copies of logs.
Personally, I have never heard of such a portal (but it sounds quite interesting). Could you provide the Suricata logs so we can see which rule triggered here?
They should be visible in the WebUI log section, or at /var/log/messages .
- In the older intrusion detection system with Guardian installed, bad actors were automatically blocked. With Suricata, even when run for extended periods of time, this never seems to happen. Am I misunderstanding what Suricata is supposed to do?
As far as I am concerned, Suricata has a different approach than Snort did before: Snort was only monitoring traffic, writing some log entries if any rule matched. Afterwards - hopefully not too late - Guardian came across and created and IPtables rule to drop traffic from the source IP.
Now, all traffic is relayed through Suricata - in case anything is detected, a packet will be silently dropped and a log message written. There is no (easy) way of bypassing the intrusion detection.
This has two downsides: (a) Blocking traffic from an IP address in general may be desired if a signature matched. This is currently not implemented, but I would vote for it. (b) A remote attacker may causing a DoS by sending lots of traffic matching to a signature, causing high load on the IDS. This could be mitigated by the (a) approach.
This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify us by reply e-mail or by telephone at 1.770.518.6166, and destroy the original transmission and its attachments without reading them or saving them to disk. This communication is covered by the Electronic Communications Privacy Act, 18 U.S.C. sections 2510-2521. Thank you.
Just a personal comment: These footers are silly - especially if the recipient is a public mailing list. :-)
Thanks, and best regards, Peter Müller
-
Kienker, Fred -
Peter Müller