From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel =?utf-8?q?Weism=C3=BCller?= To: development@lists.ipfire.org Subject: Re: Betatest Guardian 2.0 Date: Wed, 24 Aug 2016 14:36:58 +0200 Message-ID: In-Reply-To: <251990ec-a92b-7c31-98ea-2b5451ad9b7a@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0541232456456851543==" List-Id: --===============0541232456456851543== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi there, I'm back from vacation. Are there any news about Guardian 2.0? - Daniel Am 07.08.2016 um 00:41 schrieb Matthias Fischer: > 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(a)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 >> ... > 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=C3=A4t: 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 >>>> --===============0541232456456851543==--