From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Betatest Guardian 2.0 Date: Sat, 06 Aug 2016 20:39:18 +0100 Message-ID: <1470512358.2710.456.camel@ipfire.org> In-Reply-To: <8916bfc3-2af6-af48-992b-b014d51a405a@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1444183023672023120==" List-Id: --===============1444183023672023120== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-08-04 at 18:41 +0200, Matthias Fischer wrote: > Hi, >=20 > ...for the records...: >=20 > 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). >=20 > "ps -el | grep 'Z'" says: >=20 > ... > root(a)ipfire: / # ps -el | grep 'Z' > Warning: /boot/System.map-3.14.65-ipfire-pae not parseable as a System.map > F S=C2=A0=C2=A0=C2=A0UID=C2=A0=C2=A0=C2=A0PID=C2=A0=C2=A0PPID=C2=A0=C2=A0C = PRI=C2=A0=C2=A0NI ADDR SZ=C2=A0=C2=A0WCHAN TTY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0TIME CMD > 4 Z=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00=C2=A0=C2=A0=C2=A0771 10643=C2=A0=C2=A00= =C2=A0=C2=A080=C2=A0=C2=A0=C2=A00 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0- ?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A000:00:00 > iptables > ... >=20 > IMHO this is definitely not as it should be... Definitely not. And I would like to stress again that I would like to see the smaller issues gone as soon as possible so that nothing is holding back a release. Best, -Michael >=20 > Best, > Matthias >=20 > On 31.07.2016 10:39, Michael Tremer wrote: > > On Sun, 2016-07-31 at 09:20 +0200, Matthias Fischer wrote: > > > Hi, > > >=20 > > > On 28.07.2016 20:05, Stefan Schantl wrote: > > > > New test version (004) available. > > > >=20 > > > > http://people.ipfire.org/~stevee/guardian-2.0/ > > > >=20 > > > >=20 > > > > Changelog: http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt > > > >=20 > > > > Installation is the same way than all previous versions. > > > >=20 > > > > Please do a lot of testing, I'm still lacking of feedback for=C2=A0 > > > >=20 > > > > * owncloud > > > > * proper handling of reconnections on red > > > > * detection of rotating the logfiles (logrotate) > > > >=20 > > > > As usual please provide your feedback on this list and report any bugs > > > > to our bugtracker. > > > >=20 > > > > Best regards, > > > >=20 > > > > -Stefan > > > > > ... > > >=20 > > > Perhaps this is something you need to know? > > >=20 > > > Yesterday 'guardian' was still running, but didn't block anymore. I > > > think this happened because I had changed the DNS-Servers through > > > 'setup'!? > > >=20 > > > Since I'm 'static', there is no way doing this through GUI, so I had to > > > do this with a 'root'-console and PuTTY. > > >=20 > > > 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. > > >=20 > > > I'm using Snort 2.9.8.3 with "Emergingthreats.net Community Rules" and > > > this test normally ends with: > > >=20 > > > Datum: 07/31 01:26:34 > > > Name: ET POLICY Suspicious inbound to MSSQL port 1433 > > > Priorit=C3=A4t: 2 > > > Typ: Potentially Bad Traffic > > > IP-Info:=C2=A0 208.64.38.55:55036 -> 192.168.99.254:1433 > > > Referenzen: http://doc.emergingthreats.net/2010935 > > > SID:=C2=A0 2010935 > > >=20 > > > But after changing DNS entries and restarting network, 'guardian' didn't > > > react/block anymore during the next scan test. > > >=20 > > > 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. > > >=20 > > > 'pstree' says: > > >=20 > > > ... > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|-guardian-+-iptables > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0`-4*[{guardian}] > > > ... > >=20 > > I would like to know as well why this iptables process seems to remain in > > memory > > all of the time. > >=20 > > Memory consumption of guardian itself seems to be fixed now. > >=20 > > >=20 > > >=20 > > > Best, > > > Matthias > > >=20 > >=20 >=20 --===============1444183023672023120== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWNCQUFC Q2dBR0JRSlhwanpuQUFvSkVJQjU4UDl2a0FrSFdxOFArd2J4NHhLdVV0WXdOU2hBWXFFNHZPajMK T0x2c3VYbjl0TXRIMFNGbCtYcXoxL2hjNm9rSm1IMVlXTm95bjRIRFYvcy81c2kycUxzRU9UWTFn TGlaazlWRwpZSDNob24yRHUycFZ1KzBiNHFUU3lHUTFjNXNkRFlMeHJHdjdEYUh3QzlPTGM5YXFJ R2JiUjBxVEVjMS9XSTkzClAvTnhnUDllUzFCU1BXTTdnTnc4c0h0VzRmN2pIM1gyNWZCUHN3dzVX N1k1clo2VkJCbitvVUxvWHFhdzdaT1kKZFJwTWZWZS9Dd0k2ekhxWmJ0bndDbkw1STZKSFNEaHhH aEthRXQ4QkF0b2VxTEc2UHVPdTN6ajlmUHRvQjQ1NQpZMmVRZUg0anZsWUwvb2E2ZnhYeDgxRGha c0U5NW5CVVRTYlhYMjNXWTk5Qy9mMkdNeHJQMWxZdWFqeTBIYnZYCmtzZktmZnl1VXliU1k3K1VI Skx2eEJnK2hvQWdlZk9NWnRBalJLUVdTaWJlbWRReklXYUVockxpN0UvOWs1T2EKV010RlhSQnF5 TUc4R2Z6Y0tGT0ZkSThEVWtHMWN0RWhjYmtxaTNvYkhPd2h1SEw1SmI3RDlOeHk5UnJhNzFqUAo5 SVgwRHlsSm9uV2xQV0U5WTByY21hVzQrUVJKWUhrbEZKVnJ1VnVrZDdJa1lSaHUxaG1hWFAzc0dO WkxQalEyClVFWkNlUjZReGo0aE41VnRCNFByTG15TmRGK3MwTHQwZ0ZlMURsNTd5cXM2VVg3NDRH MGtqajhHZkp0VGhrajYKUVFEVUFPeXpETlNZS1hBZmQxdmxkQzZ5My95YlZwTlYwTmpDcWtLMGhN dy9ESkxoRVRGNlFjZnVhTGhvYmlkeQpUbUNoamN0SHdzVnRTbGwzcVJEaAo9WWJ3bQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============1444183023672023120==--