Re: Betatest Guardian 2.0

["Daniel Weismüller" <daniel.weismueller@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3901 bytes --]

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 <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
>>>>