On Sun, 2016-07-31 at 09:20 +0200, Matthias Fischer wrote:
Hi,
On 28.07.2016 20:05, Stefan Schantl wrote:
New test version (004) available.
http://people.ipfire.org/~stevee/guardian-2.0/
Changelog: http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
Installation is the same way than all previous versions.
Please do a lot of testing, I'm still lacking of feedback for
- owncloud
- proper handling of reconnections on red
- detection of rotating the logfiles (logrotate)
As usual please provide your feedback on this list and report any bugs to our bugtracker.
Best regards,
-Stefan
...
Perhaps this is something you need to know?
Yesterday 'guardian' was still running, but didn't block anymore. I think this happened because I had changed the DNS-Servers through 'setup'!?
Since I'm 'static', there is no way doing this through GUI, so I had to do this with a 'root'-console and PuTTY.
After network had stopped/started, 'guardian' was still running, but scanning with http://www.whatsmyip.org/port-scanner/server/ didn't trigger a block action on Port 1433 anymore as it usually did before.
I'm using Snort 2.9.8.3 with "Emergingthreats.net Community Rules" and this test normally ends with:
Datum: 07/31 01:26:34 Name: ET POLICY Suspicious inbound to MSSQL port 1433 Priorität: 2 Typ: Potentially Bad Traffic IP-Info: 208.64.38.55:55036 -> 192.168.99.254:1433 Referenzen: http://doc.emergingthreats.net/2010935 SID: 2010935
But after changing DNS entries and restarting network, 'guardian' didn't react/block anymore during the next scan test.
After restarting 'guardian' with /'etc/init.d/guardian restart', 'guardian' changed status ID, memory raised from 14342 KB to 14732 KB and during the next scan, 208.64.38.55 was blocked again.
'pstree' says:
... |-guardian-+-iptables | `-4*[{guardian}] ...
I would like to know as well why this iptables process seems to remain in memory all of the time.
Memory consumption of guardian itself seems to be fixed now.
Best, Matthias