From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Security vulnerabilities in snort and Guardian
Date: Fri, 27 Oct 2017 16:06:31 +0100 [thread overview]
Message-ID: <1509116791.4838.230.camel@ipfire.org> (raw)
In-Reply-To: <20171026214945.68960724.peter.mueller@link38.eu>
[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]
Hi,
Stefan is the maintainer of Guardian.
On Thu, 2017-10-26 at 21:49 +0200, Peter Müller wrote:
> Hello,
>
> there are two security vulnerabilities in IPFire's IDS/IPS
> (snort/Guardian) which I consider quite critical:
>
> (a) Guardian does not malicious destination IP addresses
> As described in bug #11532, it is possible to access a "bad"
> IP address (C&C server, Spamhaus DROP, Dshield, and others)
> in the internet from a internal network behind IPFire.
>
> This is because Guardian only looks at the source IP of
> a snort alert, and in this case, it is the firewall's IP
> which should not be blocked for obvious reason.
>
> There is little change that an admin will notice that the IPS
> is only working in case of inbound attacks since snort
> triggers an alert correctly.
>
> Could someone (maintainer?) have a look at Guardian and
> fix this? Unfortunately, my programming skills are too little
> for this job. :-|
I think this is a problem that could be solved. Probably the solution is quite
simple even.
However, I do not consider this a security issue that requires us to send an
update immediately.
> (b) Snort does not detect internal attacks
> As described in bug #10273 (which has been reported back in
> 2012), the IDS is fully working on RED only. Although it
> can be turned on for GREEN, BLUE and ORANGE, too, it does not
> capture any attacks in internal networks.
>
> This can be hardly examined from the WebUI, too, since it
> shows snort being up and running on GREEN and others.
>
> Changing this also allows blocking an infected PC in a local
> network which is spreading malware. On RED, the internal IP
> is already NATted.
>
> Maybe Guardian can be configured so it shows a big warning in case
> of blocked local IPs (internal networks should be clean), but
> this is kind of a feature request.
I think it blocks this now as I think it should be.
Of course it won't be able to block the one machine attacking others on the same
network because the firewall does not see that traffic, but Guardian blocks
attacks from the internal network to the Internet if snort detects it.
Let's see if Stefan can clear this up for us.
> See also:
> * https://bugzilla.ipfire.org/show_bug.cgi?id=10273
> * https://bugzilla.ipfire.org/show_bug.cgi?id=11532
> (Thanks again to Michael for enabling HTTPS with trusted certificates.)
>
> One question left: If there are attacks from a network connected
> via VPN, where are they captured by snort? On RED?
They should show up on the RED interface.
> I hate bringing up bugs like this - and hope I did not harm
> anybody :-) - but since this has a security impact, it seems okay
> to me.
Well, we all hate bugs :)
>
> Thanks and best regards,
> Peter Müller
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-10-27 15:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-26 19:49 Peter Müller
2017-10-27 15:06 ` Michael Tremer [this message]
2017-10-30 12:48 ` Stefan Schantl
2017-11-08 21:50 ` Peter Müller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1509116791.4838.230.camel@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox