Security vulnerabilities in snort and Guardian

Security vulnerabilities in snort and Guardian

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

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. :-|

(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.


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?

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.

Thanks and best regards,
Peter Müller

Re: Security vulnerabilities in snort and Guardian

[Michael Tremer]

[-- 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 --]

Re: Security vulnerabilities in snort and Guardian

[Stefan Schantl]

[-- Attachment #1: Type: text/plain, Size: 4490 bytes --]

Hello Peter, Hello Michael,
> 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.
Guardian has been designed to counter every single issue reported by
snort based on its active ruleset.

So if snort detects any incoming or outgoing (as you have pointed in
(b)) malicious traffic, guardian will counter the source IP-address and
will block it, if the configured block count has been reached.

There is no difference if this machine is placed in the Internet (RED),
 your internal LAN (GREEN), a wireless device (BLUE) or even a server
located in the DMZ (ORANGE). To prevent from blocking your own devices
you can whitelist them adding their IP-addresses or the whole subnets
to the ignore list - which of course will be against the idea of
running an IPS.

To prevent the system from blocking it self, there are a few addresses
automatically added to the whitelist. This are, the addresses of
localhost, the IP-addresses of each configured network device, the RED-
address the address of the gateway and from the configured DNS-Servers.
> 
> > (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.
You are right, the posted bug ID, reports the issue, that snort is not
capturing any packets from the "local" network zones (green, blue,
orange) which are transmitted to the internet.

If any bad packets directly will be send to the IPFire system, snort
will detect them and pass the event to guardian. So guardian will do
its job if snort detects the bad traffic correctly.

This will lead us the main problem, that the configuration of snort has
to be adjusted to monitor the traffic from the local network zones when
the traffic will be passed to the internet.

Best regards,

-Stefan
> 
> > 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 --]

Re: Security vulnerabilities in snort and Guardian

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 5451 bytes --]

Hello Stefan, hello Michael,

according to the telephone conference, there is now bug #11542,
which collects all the bugs in snort and Guardian /which I
consider critical/. There are some others which are less important
for security, and they are not included there since this was
not the intention.

At the moment, there is also bug #11169, but I am unsure if
this has security impact, too.

If you have some spare time, we might coordinate who is working
on what bug and how much effort it takes - unfortunately, my
programming skills (especially when it comes to Perl) are limited. :-(

Thanks and best regards,
Peter Müller

@All: See https://wiki.ipfire.org/devel/telco/2017-11-06 for details.

> Hello Peter, Hello Michael,
> > 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.  
> Guardian has been designed to counter every single issue reported by
> snort based on its active ruleset.
> 
> So if snort detects any incoming or outgoing (as you have pointed in
> (b)) malicious traffic, guardian will counter the source IP-address and
> will block it, if the configured block count has been reached.
> 
> There is no difference if this machine is placed in the Internet (RED),
>  your internal LAN (GREEN), a wireless device (BLUE) or even a server
> located in the DMZ (ORANGE). To prevent from blocking your own devices
> you can whitelist them adding their IP-addresses or the whole subnets
> to the ignore list - which of course will be against the idea of
> running an IPS.
> 
> To prevent the system from blocking it self, there are a few addresses
> automatically added to the whitelist. This are, the addresses of
> localhost, the IP-addresses of each configured network device, the RED-
> address the address of the gateway and from the configured DNS-Servers.
> >   
> > > (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.  
> You are right, the posted bug ID, reports the issue, that snort is not
> capturing any packets from the "local" network zones (green, blue,
> orange) which are transmitted to the internet.
> 
> If any bad packets directly will be send to the IPFire system, snort
> will detect them and pass the event to guardian. So guardian will do
> its job if snort detects the bad traffic correctly.
> 
> This will lead us the main problem, that the configuration of snort has
> to be adjusted to monitor the traffic from the local network zones when
> the traffic will be passed to the internet.
> 
> Best regards,
> 
> -Stefan
> >   
> > > 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