Hi,
On 04.08.2016 18:41, Matthias Fischer wrote:
Hi,
...for the records...:
Today I found the time to take a look with 'htop' and 'top' for the 'iptables'-process and found that 'top' lists '1 zombie' (screenshots attached).
"ps -el | grep 'Z'" says:
... root@ipfire: / # ps -el | grep 'Z' Warning: /boot/System.map-3.14.65-ipfire-pae not parseable as a System.map F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 4 Z 0 771 10643 0 80 0 - 0 - ? 00:00:00 iptables <defunct> ...
Ok, I think at last I found something - perhaps this helps:
After some playing around I discovered that this 'iptables'-zombie comes up if I unblock an entry from the "Currently blocked hosts"-list.
Secondly I altered the 'sleep'-time of the 'stop/start'-cycle in '/etc/init.d/guardian' to four seconds to avoid restart problems. If start/stop happens too soon, I got "Unable to continue: /usr/sbin/guardian is running" warnings.
Now, after stopping/restarting 'guardian, the 'iptables'-zombie is gone.
HTH, Matthias
IMHO this is definitely not as it should be...
Best, Matthias
On 31.07.2016 10:39, Michael Tremer wrote:
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