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