From: Matthias Fischer <matthias.fischer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Betatest Guardian 2.0
Date: Sun, 07 Aug 2016 00:41:21 +0200 [thread overview]
Message-ID: <251990ec-a92b-7c31-98ea-2b5451ad9b7a@ipfire.org> (raw)
In-Reply-To: <8916bfc3-2af6-af48-992b-b014d51a405a@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 3709 bytes --]
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
>>>
>>
>
next prev parent reply other threads:[~2016-08-06 22:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8916bfc3-2af6-af48-992b-b014d51a405a@ipfire.org>
2016-08-06 19:39 ` Michael Tremer
2016-08-06 22:41 ` Matthias Fischer [this message]
2016-08-24 12:36 ` Daniel Weismüller
[not found] <1468920284.13947.5.camel@ipfire.org>
2016-07-19 12:54 ` Matthias Fischer
2016-07-19 17:26 ` Stefan Schantl
2016-07-19 18:01 ` Matthias Fischer
2016-07-18 14:01 Stefan Schantl
2016-07-19 7:14 ` Daniel Weismüller
2016-07-19 10:01 ` Stefan Schantl
2016-07-20 13:37 ` Stefan Schantl
2016-07-20 13:33 ` Stefan Schantl
2016-07-20 14:28 ` Matthias Fischer
2016-07-21 11:25 ` Matthias Fischer
2016-07-21 11:28 ` Michael Tremer
2016-07-21 13:07 ` Matthias Fischer
2016-07-21 15:57 ` Matthias Fischer
2016-07-21 19:05 ` Flying Trashcan
2016-07-21 19:52 ` Flying Trashcan
2016-07-21 21:07 ` Matthias Fischer
2016-07-22 20:28 ` Matthias Fischer
2016-07-22 22:23 ` Matthias Fischer
2016-07-26 15:10 ` Michael Tremer
2016-07-26 18:31 ` Matthias Fischer
2016-07-28 17:41 ` Stefan Schantl
2016-07-28 10:47 ` Stefan Schantl
2016-07-28 18:05 ` Stefan Schantl
2016-07-29 16:20 ` Matthias Fischer
2016-07-30 19:06 ` Matthias Fischer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=251990ec-a92b-7c31-98ea-2b5451ad9b7a@ipfire.org \
--to=matthias.fischer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox