From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: Suricata testing Date: Mon, 11 Mar 2019 19:56:00 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5756530070848284163==" List-Id: --===============5756530070848284163== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Fred, thank you for your feedback. > 2. Runs properly with most websites, with one MAJOR (at least for us) > exception =E2=80=93 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 =E2=80=93 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 interest= ing). 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 . > 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? 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=C3=BCller --=20 The road to Hades is easy to travel. -- Bion of Borysthenes --===============5756530070848284163==--