Re: Betatest Guardian 2.0

Re: Betatest Guardian 2.0

[Michael Tremer]

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

On Thu, 2016-08-04 at 18:41 +0200, 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>
> ...
> 
> 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
> 
> 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
> > > 
> > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Re: Betatest Guardian 2.0

[Daniel Weismüller]

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

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

I found some typos in '/usr/sbin/guardian'.

Didn't know how to do this better, so I'm sending an *attached* patch.

In the meantime, 'guardian' is running without seen problems - great
work! ;-)

Best,
Matthias




[-- Attachment #2: _usr_sbin_guardian_typos.patch --]
[-- Type: text/plain, Size: 6558 bytes --]

--- old/guardian	Thu Jul 28 19:27:22 2016
+++ new/guardian	Sat Jul 30 20:54:29 2016
@@ -37,7 +37,7 @@
 
 use warnings;
 
-# Disable warnings of unjoinded threads when stopping guardian.
+# Disable warnings of unjoined threads when stopping guardian.
 no warnings 'threads';
 
 # Define version.
@@ -58,7 +58,7 @@
 	print "Guardian $version \n";
 	print "Usage: guardian <optional arguments>\n";
 	print " -c, --config\t\tspecifiy a configuration file other than the default (/etc/guardian/guardian.conf)\n";
-	print " -f, --foreground\trun in the foreground (doesn't fork, any output goes to STDOUT)\n";
+	print " -f, --foreground\turn in the foreground (doesn't fork, any output goes to STDOUT)\n";
 	print " -h, --help\t\tshows this help\n";
 	print " -v, --version\t\tdisplay programm version and exit.\n";
 	exit;
@@ -69,7 +69,7 @@
 
 # Check if another instance of guardian is allready running.
 if (&Guardian::Daemon::IsRunning()) {
-	die "Another instance of Guardian is allready running...\n";
+	die "Another instance of Guardian is already running...\n";
 }
 
 # Read-in the configuration file and store the settings.
@@ -183,18 +183,18 @@
 ## with huge logfiles, at initialization time of the worker process, the file will
 ## be opened once and the cursor position of the end of file (EOF) get stored. When
 ## reading any newly added lines from the file, we directly can jump to the last
-## known position and get these lines. Afterwards, we store the current curser position
+## known position and get these lines. Afterwards, we store the current cursor position
 ## again, so we can do it in this way over and over again.
 #
 ## All read lines get stored in an array, which will be passed to the Parser.
 #
-## If any response (action) from the parser get recieved, it will be put into the
+## If any response (action) from the parser is received, it will be put into the
 ## shared event queue.
 #
 sub Worker ($) {
 	my $file = $_[0];
 
-	# Obtain the parser name which should be used to parser any
+	# Obtain the parser name which should be used to parse any
 	# messages of this file.
 	my $parser = $monitored_files{$file};
 
@@ -215,7 +215,7 @@
 
 	# Infinite loop.
 	while(1) {
-		# Check if the workers should pause or perform it's desired work.
+		# Check if the workers should pause or perform their desired work.
 		if ($workers_pause) {
 			# Wait 1 second until the next check.
 			sleep(1);
@@ -286,7 +286,7 @@
 ## Socket function.
 #
 ## This function uses the Socket module to create and listen to an UNIX socket.
-## It automatically accepts all incomming connections and pass the recieved
+## It automatically accepts all incoming connections and pass the received
 ## data messages to the the Message_Parser function which is also part of the
 ## socket module.
 #
@@ -300,10 +300,10 @@
 	# Log successfull creation of socket.
 	$logger->Log("debug", "Listening to Socket...");
 
-        # Accept incomming connections from the socket.
+        # Accept incoming connections from the socket.
         while (my $connection = $server->accept()) {
 		# Autoflush the socket after the data
-		# has been recieved.
+		# has been received.
 		$connection->autoflush(1);
 
 		# Gather all data from the connection.
@@ -311,10 +311,10 @@
 			# Remove any newlines.
 			chomp($message);
 
-			# Log recieved socket command.
+			# Log received socket command.
 			$logger->Log("debug", "Socket - Recieved message: $message");
 
-			# Send the recieved data message to the
+			# Send the received data message to the
 			# socket parser.
 			my $action = &Guardian::Socket::Message_Parser($message);
 
@@ -335,7 +335,7 @@
 ## Function for capturing process signals.
 #
 ## This function captures any sent process signals and will call various
-## actions, basend on the captured signal.
+## actions, based on the captured signal.
 #
 sub SignalHandler {
 	$SIG{INT} = \&Shutdown;
@@ -359,7 +359,7 @@
 	# Loop through the hash which contains the monitored files and start
 	# a worker thread for each single one.
 	foreach my $file (keys %monitored_files) {
-		# Check if an worker allready is running for this file.
+		# Check if an worker is already running for this file.
 		# If not, start the worker.
 		unless (exists($running_workers{$file})) {
 			$logger->Log("debug", "Starting worker thread for $file");
@@ -380,7 +380,7 @@
 	# Loop through all running workers.
 	foreach my $worker (keys %running_workers) {
 		# Determine if the worker should be stopped.
-		# This happen if the file should not be longer monitored.
+		# This happens if the file should not be longer monitored.
 		unless(exists($monitored_files{$worker})) {
 			$logger->Log("debug", "Stopping worker thread for $worker");
 
@@ -408,7 +408,7 @@
 #
 sub PauseWorkers() {
 	# Set workers_pause variable to "1".
-	# All workers will be sleep until the variable has been set to "0".
+	# All workers will sleep until the variable has been set to "0".
 	$workers_pause = 1;
 
 	# Log paused workers.
@@ -438,7 +438,7 @@
 #
 ## Reload function.
 #
-## This function will get called if the signal handler recieves a "SIGHUP" signal,
+## This function will get called if the signal handler receives a "SIGHUP" signal,
 ## or the reload command will be sent via socket connection. It is responsible for
 ## reloading all configure options and stopping/starting the worker threads.
 #
@@ -483,7 +483,7 @@
 #
 ## ReloadIgnoreList function.
 #
-## This function will be called if the signal handler recieves a "SIGUSR1" signal,
+## This function will be called if the signal handler receives a "SIGUSR1" signal,
 ## or the reload-ignore-list command will be sent via the socket connection. It just
 ## performs a simple check if an ignore file has been configured and calls the responsible
 ## function on the events module.
@@ -504,7 +504,7 @@
 #
 ## This function only get called when the logrotate command will be sent via
 ## the socket connection. It is responsible for validating and altering the current
-## curser positions of the monitored files and stopping/starting the worker threads.
+## cursor positions of the monitored files and stopping/starting the worker threads.
 #
 sub Logrotate () {
 	# Stop all running workers.
@@ -549,7 +549,7 @@
 ## Shutdown function.
 #
 ## This function is used to do a clean shutdown of guardian. It will be called
-## by the signal handler when recieving INT (2), QUIT (3) and TERM (15) signals.
+## by the signal handler when receiving INT (2), QUIT (3) and TERM (15) signals.
 #
 sub Shutdown () {
 	# Log shutdown.

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

On 28.07.2016 20:05, Stefan Schantl wrote:
> New test version (004) available.

First test: thanks - seems to work for me!

Once started, 'guardian' memory usage is at 14342 KB and stays there, no
matter what I do. I'll keep on testing...

Best,
Matthias

> 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
>> Hello testers,
>> 
>> after a lot of code debugging I was able to determine
>> the reason of those memory leak.
>> 
>> It is the default behavior of not freeing used virtual memory again
>> after a thread has been stopped.
>> 
>> Guardian stops and restarts each worker thread on a reload and a
>> logrotate event.
>> 
>> I'll have to rework the corresponding code to solve this issue and
>> come
>> back after finished this.
>> 
>> Thanks for pointing this out,
>> 
>> -Stefan
>> > 
>> > Did anyone try to monitor the size of the log files that guardian
>> > is
>> > parsing as
>> > well? Could it be that every line that is read remains in memory?
>> > 
>> > This is just an idea...
>> > 
>> > Best,
>> > -Michael
>> > 
>> > On Sat, 2016-07-23 at 00:23 +0200, Matthias Fischer wrote:
>> > > 
>> > > 
>> > > Correction: in the meanwhile it jumped to 47890 KB, I don't know
>> > > why.
>> > > Logrotation?.
>> > > 
>> > > On 22.07.2016 22:28, Matthias Fischer wrote:
>> > > > 
>> > > > 
>> > > > Hi,
>> > > > 
>> > > > ...for the records...:
>> > > > 
>> > > > Since I switched "Loglevel" to OFF, memory usage stays at
>> > > > "14333
>> > > > KB" and
>> > > > didn't change/rise since then.
>> > > > 
>> > > > HTH,
>> > > > Matthias
>> > > > 
>> > > > On 21.07.2016 23:07, Matthias Fischer wrote:
>> > > > > 
>> > > > > 
>> > > > > Hi,
>> > > > > 
>> > > > > Sounds interesting.
>> > > > > 
>> > > > > So I thought I take a little test...
>> > > > > 
>> > > > > Initial RAM-Usage: 14334 KB
>> > > > > 
>> > > > > First I just switched logging, did nothing else:
>> > > > > 
>> > > > > syslog => file => 22726 KB
>> > > > > file => syslog => 31117 KB
>> > > > > syslog => file => 39507/47898 KB (RAM suddenly altered. Why?
>> > > > > No
>> > > > > idea.)
>> > > > > file => syslog => 56289 KB
>> > > > > 
>> > > > > Restarted through console:
>> > > > > 
>> > > > > root(a)ipfire: /var/log/guardian # guardianctrl restart
>> > > > > Stopping Guardian...
>> > > > > Starting Guardian...
>> > > > > Unable to continue: /usr/sbin/guardian is running
>> > > > >                   [ WARN ]
>> > > > > 
>> > > > > Hm?
>> > > > > 
>> > > > > Stopped through console, no output, 'guardian' not found
>> > > > > anymore,
>> > > > > neither in GUI nor through console:
>> > > > > 
>> > > > > root(a)ipfire: /var/log/guardian # ps ax | grep guardian
>> > > > >  6962 pts/1    S+     0:00 grep guardian
>> > > > > 
>> > > > > Started through console and we're exactly where we started
>> > > > > (14334 KB).
>> > > > > 
>> > > > > The same happens if I switch the 'Priority-level' or the
>> > > > > 'Firewall-
>> > > > > Action'.
>> > > > > 
>> > > > > Initial: 2
>> > > > > 2 => 3 => 22723 KB
>> > > > > 3 => 2 => 31112 KB
>> > > > > 
>> > > > > Firewall-Action:
>> > > > > Reject => Drop => 39501 KB
>> > > > > 
>> > > > > Stop => Start => 14334 KB
>> > > > > 
>> > > > > Interestingly, during MY (log-)switching, 'guardian' never
>> > > > > stopped.
>> > > > > 
>> > > > > HTH,
>> > > > > Matthias
>> > > > > 
>> > > > > On 21.07.2016 21:52, Flying Trashcan wrote:
>> > > > > > 
>> > > > > > 
>> > > > > > I am now noticing that when I switch from Log facility
>> > > > > > “file”
>> > > > > > to
>> > > > > > “syslog”, Guardian Daemon stops and doesn’t
>> > > > > > restart.  Switching from
>> > > > > > syslog to file didn’t stop the service, only switching back
>> > > > > > to syslog
>> > > > > > from file.  I can manually start the service and be back to
>> > > > > > normal.  Not
>> > > > > > a big deal, but if someone made the switch and didn’t think
>> > > > > > to manually
>> > > > > > start the service, it could be left without running
>> > > > > > Guardian.
>> > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > On Jul 21, 2016, at 4:25 AM, Matthias Fischer
>> > > > > > > <matthias.fis
>> > > > > > > cher(a)ipfire
>> > > > > > > .org> wrote:
>> > > > > > > 
>> > > > > > > Hi,
>> > > > > > > 
>> > > > > > > I mentioned this earlier, but it seems that 'guardian'
>> > > > > > > has
>> > > > > > > some kind
>> > > > > > > of
>> > > > > > > memory leak?
>> > > > > > > 
>> > > > > > > It started about two days ago with ~14 MB RAM. Then it
>> > > > > > > jumped to ~34
>> > > > > > > MB,
>> > > > > > > then to ~48 MB - today it suddenly uses 71 MB.
>> > > > > > > 
>> > > > > > > And if I start it on my testmachine (offline!) it uses
>> > > > > > > ~90
>> > > > > > > MB.
>> > > > > > > 
>> > > > > > > Can someone confirm?
>> > > > > > > 
>> > > > > > > Besides this, its working without seen problems.
>> > > > > > > 
>> > > > > > > Best,
>> > > > > > > Matthias
>> > > > > > > 
>> > > > > > > On 20.07.2016 15:33, Stefan Schantl wrote:
>> > > > > > > > 
>> > > > > > > > 
>> > > > > > > > Hello testers,
>> > > > > > > > 
>> > > > > > > > I've uploaded  a new test version (003).
>> > > > > > > > 
>> > > > > > > > Update or fresh install works like described in the
>> > > > > > > > announcement
>> > > > > > > > mail.
>> > > > > > > > 
>> > > > > > > > The Changelog can be found here:
>> > > > > > > > 
>> > > > > > > > http://people.ipfire.org/~stevee/guardian-2.0/Changelog
>> > > > > > > > .t
>> > > > > > > > xt
>> > > > > > > > 
>> > > > > > > > At the moment I'm missing feedback for the following
>> > > > > > > > functions:
>> > > > > > > > 
>> > > > > > > > * Manually blocking / unblocking addresses.
>> > > > > > > > * Dealing with the ignore list.
>> > > > > > > > * Owncloud message parser.
>> > > > > > > > * Logrotate, there should be an corresponding log entry
>> > > > > > > > in the
>> > > > > > > > guardian
>> > > > > > > > logfile after rotation of the logfiles have been done.
>> > > > > > > > * Reload of the ignore list after "Red" has been
>> > > > > > > > reconnected. There
>> > > > > > > > also a corresponding log entry should be logged to the
>> > > > > > > > logfile and
>> > > > > > > > the
>> > > > > > > > new "Red-address" should also be logged as part of the
>> > > > > > > > ignore list
>> > > > > > > > (If
>> > > > > > > > you own an dynamic assigned one).
>> > > > > > > > 
>> > > > > > > > As always please report your bugs or experience with
>> > > > > > > > the
>> > > > > > > > new version
>> > > > > > > > to
>> > > > > > > > this list.
>> > > > > > > > 
>> > > > > > > > Best regards,
>> > > > > > > > 
>> > > > > > > > -Stefan
>> > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > Hello mailing list followers,
>> > > > > > > > > 
>> > > > > > > > > this is the official release announcement for the
>> > > > > > > > > first
>> > > > > > > > > beta
>> > > > > > > > > release
>> > > > > > > > > of
>> > > > > > > > > the new Guardian 2.0 approach.
>> > > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > - What are the differences to the current version of
>> > > > > > > > > guardian
>> > > > > > > > > (legacy)
>> > > > > > > > > and the first approach of guardian 2.0?
>> > > > > > > > > 
>> > > > > > > > > The most important difference is, that the new
>> > > > > > > > > version
>> > > > > > > > > of Guardian
>> > > > > > > > > 2.0
>> > > > > > > > > completely has been re-written from scratch and
>> > > > > > > > > released under the
>> > > > > > > > > terms of the GPLv3. The legacy version of guardian is
>> > > > > > > > > not
>> > > > > > > > > maintained
>> > > > > > > > > anymore by it's developer and the software has been
>> > > > > > > > > released
>> > > > > > > > > without
>> > > > > > > > > any license details at all.
>> > > > > > > > > 
>> > > > > > > > > Guardian 2.0 has a very modular code base and has
>> > > > > > > > > been
>> > > > > > > > > designed as
>> > > > > > > > > a
>> > > > > > > > > multi-threaded application. This allows a parallel
>> > > > > > > > > parsing of all
>> > > > > > > > > monitored logfiles and faster actions, if one of the
>> > > > > > > > > used modules
>> > > > > > > > > detects an attack.
>> > > > > > > > > 
>> > > > > > > > > A very important difference to the legacy version is
>> > > > > > > > > the support
>> > > > > > > > > of
>> > > > > > > > > configuring and managing the entire service through
>> > > > > > > > > the
>> > > > > > > > > IPFire
>> > > > > > > > > webinterface. The entire configuration, managing of
>> > > > > > > > > current
>> > > > > > > > > blocked
>> > > > > > > > > hosts, unblocking them or editing the ignored hosts
>> > > > > > > > > list now can
>> > > > > > > > > be
>> > > > > > > > > done in a graphical way. 
>> > > > > > > > > 
>> > > > > > > > > The legacy version of guardian only supported parsing
>> > > > > > > > > snort
>> > > > > > > > > alerts.
>> > > > > > > > > HTTPD and SSH support has been patched by the IPFire
>> > > > > > > > > development
>> > > > > > > > > team
>> > > > > > > > > some time ago. Guardian 2.0 supports all of them out
>> > > > > > > > > of
>> > > > > > > > > the box
>> > > > > > > > > and
>> > > > > > > > > includes a filter to detect owncloud login brute-
>> > > > > > > > > force
>> > > > > > > > > attempts.
>> > > > > > > > > As a
>> > > > > > > > > benefit of the new modular design, additional filters
>> > > > > > > > > easily can
>> > > > > > > > > be
>> > > > > > > > > added.
>> > > > > > > > > 
>> > > > > > > > > Guardian 2.0 is able to reload it's configuration,
>> > > > > > > > > reloading
>> > > > > > > > > the ignore list during runtime and handle, if the
>> > > > > > > > > logfiles will
>> > > > > > > > > get
>> > > > > > > > > rotated by logrotate. This actions can be called by
>> > > > > > > > > using the
>> > > > > > > > > webinterface or from the command line interface by
>> > > > > > > > > using
>> > > > > > > > > "guardianctrl".
>> > > > > > > > > 
>> > > > > > > > > These are just a handful of the changes and benefits
>> > > > > > > > > which comes
>> > > > > > > > > with
>> > > > > > > > > Guardian 2.0, a complete list would be to long for
>> > > > > > > > > this
>> > > > > > > > > mailing
>> > > > > > > > > list.
>> > > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > - How to join testing?
>> > > > > > > > > 
>> > > > > > > > > To get part of the testing team, simple navigate to
>> > > > > > > > > htt
>> > > > > > > > > p://people.
>> > > > > > > > > ipf
>> > > > > > > > > ir
>> > > > > > > > > e.org/~stevee/guardian-2.0/ and download the latest
>> > > > > > > > > tarball
>> > > > > > > > > (currently
>> > > > > > > > > 002). Please take care to download the correct one,
>> > > > > > > > > based on your
>> > > > > > > > > used
>> > > > > > > > > architecture. The i585 packages are for 32Bit
>> > > > > > > > > installations of
>> > > > > > > > > IPFire,
>> > > > > > > > > the x86_64 packages only can be used on 64Bit
>> > > > > > > > > installations.
>> > > > > > > > > 
>> > > > > > > > > Put the downloaded file on your IPFire test system
>> > > > > > > > > and
>> > > > > > > > > extract the
>> > > > > > > > > package by using "tar -xvf guardian-2.0-
>> > > > > > > > > 002.<arch>.tar.gz -C /".
>> > > > > > > > > 
>> > > > > > > > > The final installation step would be to regenerate
>> > > > > > > > > the
>> > > > > > > > > language
>> > > > > > > > > cache
>> > > > > > > > > by executing "update-lang-cache" on the console.
>> > > > > > > > > 
>> > > > > > > > > From now you can find a new menu item called
>> > > > > > > > > "Guardian"
>> > > > > > > > > in your
>> > > > > > > > > "Service" menu after you have logged-in into your
>> > > > > > > > > IPFire's
>> > > > > > > > > webinterface.
>> > > > > > > > > 
>> > > > > > > > > Documentation can be found on the IPFire wiki:
>> > > > > > > > > http://w
>> > > > > > > > > iki.ipfire.
>> > > > > > > > > org
>> > > > > > > > > /e
>> > > > > > > > > n/addons/guardian/start#the_guardian_20_addon
>> > > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > - Where to post bugs reports or provide feedback?
>> > > > > > > > > 
>> > > > > > > > > If you find any bugs, please report them as usual on
>> > > > > > > > > the IPFire
>> > > > > > > > > bugtracker, which can be found at https://bugzilla.ip
>> > > > > > > > > fi
>> > > > > > > > > re.org.
>> > > > > > > > > 
>> > > > > > > > > To provide feedback or to join a discussion, please
>> > > > > > > > > send your
>> > > > > > > > > mails
>> > > > > > > > > to
>> > > > > > > > > "development(a)lists.ipfire.org" (Please register first
>> > > > > > > > > at http://li
>> > > > > > > > > sts
>> > > > > > > > > .i
>> > > > > > > > > pfire.org if not yet done).
>> > > > > > > > > 
>> > > > > > > > > The source code can be found at http://git.ipfire.org
>> > > > > > > > > /?
>> > > > > > > > > p=people/st
>> > > > > > > > > eve
>> > > > > > > > > e/
>> > > > > > > > > guardian.git;a=summary
>> > > > > > > > > 
>> > > > > > > > > 
>> > > > > > > > > Happy testing,
>> > > > > > > > > 
>> > > > > > > > > -Stefan
>> > > > > > > > > 
> 

Re: Betatest Guardian 2.0

[Stefan Schantl]

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

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
> Hello testers,
> 
> after a lot of code debugging I was able to determine
> the reason of those memory leak.
> 
> It is the default behavior of not freeing used virtual memory again
> after a thread has been stopped.
> 
> Guardian stops and restarts each worker thread on a reload and a
> logrotate event.
> 
> I'll have to rework the corresponding code to solve this issue and
> come
> back after finished this.
> 
> Thanks for pointing this out,
> 
> -Stefan
> > 
> > Did anyone try to monitor the size of the log files that guardian
> > is
> > parsing as
> > well? Could it be that every line that is read remains in memory?
> > 
> > This is just an idea...
> > 
> > Best,
> > -Michael
> > 
> > On Sat, 2016-07-23 at 00:23 +0200, Matthias Fischer wrote:
> > > 
> > > 
> > > Correction: in the meanwhile it jumped to 47890 KB, I don't know
> > > why.
> > > Logrotation?.
> > > 
> > > On 22.07.2016 22:28, Matthias Fischer wrote:
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > ...for the records...:
> > > > 
> > > > Since I switched "Loglevel" to OFF, memory usage stays at
> > > > "14333
> > > > KB" and
> > > > didn't change/rise since then.
> > > > 
> > > > HTH,
> > > > Matthias
> > > > 
> > > > On 21.07.2016 23:07, Matthias Fischer wrote:
> > > > > 
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Sounds interesting.
> > > > > 
> > > > > So I thought I take a little test...
> > > > > 
> > > > > Initial RAM-Usage: 14334 KB
> > > > > 
> > > > > First I just switched logging, did nothing else:
> > > > > 
> > > > > syslog => file => 22726 KB
> > > > > file => syslog => 31117 KB
> > > > > syslog => file => 39507/47898 KB (RAM suddenly altered. Why?
> > > > > No
> > > > > idea.)
> > > > > file => syslog => 56289 KB
> > > > > 
> > > > > Restarted through console:
> > > > > 
> > > > > root(a)ipfire: /var/log/guardian # guardianctrl restart
> > > > > Stopping Guardian...
> > > > > Starting Guardian...
> > > > > Unable to continue: /usr/sbin/guardian is running
> > > > >                   [ WARN ]
> > > > > 
> > > > > Hm?
> > > > > 
> > > > > Stopped through console, no output, 'guardian' not found
> > > > > anymore,
> > > > > neither in GUI nor through console:
> > > > > 
> > > > > root(a)ipfire: /var/log/guardian # ps ax | grep guardian
> > > > >  6962 pts/1    S+     0:00 grep guardian
> > > > > 
> > > > > Started through console and we're exactly where we started
> > > > > (14334 KB).
> > > > > 
> > > > > The same happens if I switch the 'Priority-level' or the
> > > > > 'Firewall-
> > > > > Action'.
> > > > > 
> > > > > Initial: 2
> > > > > 2 => 3 => 22723 KB
> > > > > 3 => 2 => 31112 KB
> > > > > 
> > > > > Firewall-Action:
> > > > > Reject => Drop => 39501 KB
> > > > > 
> > > > > Stop => Start => 14334 KB
> > > > > 
> > > > > Interestingly, during MY (log-)switching, 'guardian' never
> > > > > stopped.
> > > > > 
> > > > > HTH,
> > > > > Matthias
> > > > > 
> > > > > On 21.07.2016 21:52, Flying Trashcan wrote:
> > > > > > 
> > > > > > 
> > > > > > I am now noticing that when I switch from Log facility
> > > > > > “file”
> > > > > > to
> > > > > > “syslog”, Guardian Daemon stops and doesn’t
> > > > > > restart.  Switching from
> > > > > > syslog to file didn’t stop the service, only switching back
> > > > > > to syslog
> > > > > > from file.  I can manually start the service and be back to
> > > > > > normal.  Not
> > > > > > a big deal, but if someone made the switch and didn’t think
> > > > > > to manually
> > > > > > start the service, it could be left without running
> > > > > > Guardian.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Jul 21, 2016, at 4:25 AM, Matthias Fischer
> > > > > > > <matthias.fis
> > > > > > > cher(a)ipfire
> > > > > > > .org> wrote:
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I mentioned this earlier, but it seems that 'guardian'
> > > > > > > has
> > > > > > > some kind
> > > > > > > of
> > > > > > > memory leak?
> > > > > > > 
> > > > > > > It started about two days ago with ~14 MB RAM. Then it
> > > > > > > jumped to ~34
> > > > > > > MB,
> > > > > > > then to ~48 MB - today it suddenly uses 71 MB.
> > > > > > > 
> > > > > > > And if I start it on my testmachine (offline!) it uses
> > > > > > > ~90
> > > > > > > MB.
> > > > > > > 
> > > > > > > Can someone confirm?
> > > > > > > 
> > > > > > > Besides this, its working without seen problems.
> > > > > > > 
> > > > > > > Best,
> > > > > > > Matthias
> > > > > > > 
> > > > > > > On 20.07.2016 15:33, Stefan Schantl wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hello testers,
> > > > > > > > 
> > > > > > > > I've uploaded  a new test version (003).
> > > > > > > > 
> > > > > > > > Update or fresh install works like described in the
> > > > > > > > announcement
> > > > > > > > mail.
> > > > > > > > 
> > > > > > > > The Changelog can be found here:
> > > > > > > > 
> > > > > > > > http://people.ipfire.org/~stevee/guardian-2.0/Changelog
> > > > > > > > .t
> > > > > > > > xt
> > > > > > > > 
> > > > > > > > At the moment I'm missing feedback for the following
> > > > > > > > functions:
> > > > > > > > 
> > > > > > > > * Manually blocking / unblocking addresses.
> > > > > > > > * Dealing with the ignore list.
> > > > > > > > * Owncloud message parser.
> > > > > > > > * Logrotate, there should be an corresponding log entry
> > > > > > > > in the
> > > > > > > > guardian
> > > > > > > > logfile after rotation of the logfiles have been done.
> > > > > > > > * Reload of the ignore list after "Red" has been
> > > > > > > > reconnected. There
> > > > > > > > also a corresponding log entry should be logged to the
> > > > > > > > logfile and
> > > > > > > > the
> > > > > > > > new "Red-address" should also be logged as part of the
> > > > > > > > ignore list
> > > > > > > > (If
> > > > > > > > you own an dynamic assigned one).
> > > > > > > > 
> > > > > > > > As always please report your bugs or experience with
> > > > > > > > the
> > > > > > > > new version
> > > > > > > > to
> > > > > > > > this list.
> > > > > > > > 
> > > > > > > > Best regards,
> > > > > > > > 
> > > > > > > > -Stefan
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hello mailing list followers,
> > > > > > > > > 
> > > > > > > > > this is the official release announcement for the
> > > > > > > > > first
> > > > > > > > > beta
> > > > > > > > > release
> > > > > > > > > of
> > > > > > > > > the new Guardian 2.0 approach.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > - What are the differences to the current version of
> > > > > > > > > guardian
> > > > > > > > > (legacy)
> > > > > > > > > and the first approach of guardian 2.0?
> > > > > > > > > 
> > > > > > > > > The most important difference is, that the new
> > > > > > > > > version
> > > > > > > > > of Guardian
> > > > > > > > > 2.0
> > > > > > > > > completely has been re-written from scratch and
> > > > > > > > > released under the
> > > > > > > > > terms of the GPLv3. The legacy version of guardian is
> > > > > > > > > not
> > > > > > > > > maintained
> > > > > > > > > anymore by it's developer and the software has been
> > > > > > > > > released
> > > > > > > > > without
> > > > > > > > > any license details at all.
> > > > > > > > > 
> > > > > > > > > Guardian 2.0 has a very modular code base and has
> > > > > > > > > been
> > > > > > > > > designed as
> > > > > > > > > a
> > > > > > > > > multi-threaded application. This allows a parallel
> > > > > > > > > parsing of all
> > > > > > > > > monitored logfiles and faster actions, if one of the
> > > > > > > > > used modules
> > > > > > > > > detects an attack.
> > > > > > > > > 
> > > > > > > > > A very important difference to the legacy version is
> > > > > > > > > the support
> > > > > > > > > of
> > > > > > > > > configuring and managing the entire service through
> > > > > > > > > the
> > > > > > > > > IPFire
> > > > > > > > > webinterface. The entire configuration, managing of
> > > > > > > > > current
> > > > > > > > > blocked
> > > > > > > > > hosts, unblocking them or editing the ignored hosts
> > > > > > > > > list now can
> > > > > > > > > be
> > > > > > > > > done in a graphical way. 
> > > > > > > > > 
> > > > > > > > > The legacy version of guardian only supported parsing
> > > > > > > > > snort
> > > > > > > > > alerts.
> > > > > > > > > HTTPD and SSH support has been patched by the IPFire
> > > > > > > > > development
> > > > > > > > > team
> > > > > > > > > some time ago. Guardian 2.0 supports all of them out
> > > > > > > > > of
> > > > > > > > > the box
> > > > > > > > > and
> > > > > > > > > includes a filter to detect owncloud login brute-
> > > > > > > > > force
> > > > > > > > > attempts.
> > > > > > > > > As a
> > > > > > > > > benefit of the new modular design, additional filters
> > > > > > > > > easily can
> > > > > > > > > be
> > > > > > > > > added.
> > > > > > > > > 
> > > > > > > > > Guardian 2.0 is able to reload it's configuration,
> > > > > > > > > reloading
> > > > > > > > > the ignore list during runtime and handle, if the
> > > > > > > > > logfiles will
> > > > > > > > > get
> > > > > > > > > rotated by logrotate. This actions can be called by
> > > > > > > > > using the
> > > > > > > > > webinterface or from the command line interface by
> > > > > > > > > using
> > > > > > > > > "guardianctrl".
> > > > > > > > > 
> > > > > > > > > These are just a handful of the changes and benefits
> > > > > > > > > which comes
> > > > > > > > > with
> > > > > > > > > Guardian 2.0, a complete list would be to long for
> > > > > > > > > this
> > > > > > > > > mailing
> > > > > > > > > list.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > - How to join testing?
> > > > > > > > > 
> > > > > > > > > To get part of the testing team, simple navigate to
> > > > > > > > > htt
> > > > > > > > > p://people.
> > > > > > > > > ipf
> > > > > > > > > ir
> > > > > > > > > e.org/~stevee/guardian-2.0/ and download the latest
> > > > > > > > > tarball
> > > > > > > > > (currently
> > > > > > > > > 002). Please take care to download the correct one,
> > > > > > > > > based on your
> > > > > > > > > used
> > > > > > > > > architecture. The i585 packages are for 32Bit
> > > > > > > > > installations of
> > > > > > > > > IPFire,
> > > > > > > > > the x86_64 packages only can be used on 64Bit
> > > > > > > > > installations.
> > > > > > > > > 
> > > > > > > > > Put the downloaded file on your IPFire test system
> > > > > > > > > and
> > > > > > > > > extract the
> > > > > > > > > package by using "tar -xvf guardian-2.0-
> > > > > > > > > 002.<arch>.tar.gz -C /".
> > > > > > > > > 
> > > > > > > > > The final installation step would be to regenerate
> > > > > > > > > the
> > > > > > > > > language
> > > > > > > > > cache
> > > > > > > > > by executing "update-lang-cache" on the console.
> > > > > > > > > 
> > > > > > > > > From now you can find a new menu item called
> > > > > > > > > "Guardian"
> > > > > > > > > in your
> > > > > > > > > "Service" menu after you have logged-in into your
> > > > > > > > > IPFire's
> > > > > > > > > webinterface.
> > > > > > > > > 
> > > > > > > > > Documentation can be found on the IPFire wiki:
> > > > > > > > > http://w
> > > > > > > > > iki.ipfire.
> > > > > > > > > org
> > > > > > > > > /e
> > > > > > > > > n/addons/guardian/start#the_guardian_20_addon
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > - Where to post bugs reports or provide feedback?
> > > > > > > > > 
> > > > > > > > > If you find any bugs, please report them as usual on
> > > > > > > > > the IPFire
> > > > > > > > > bugtracker, which can be found at https://bugzilla.ip
> > > > > > > > > fi
> > > > > > > > > re.org.
> > > > > > > > > 
> > > > > > > > > To provide feedback or to join a discussion, please
> > > > > > > > > send your
> > > > > > > > > mails
> > > > > > > > > to
> > > > > > > > > "development(a)lists.ipfire.org" (Please register first
> > > > > > > > > at http://li
> > > > > > > > > sts
> > > > > > > > > .i
> > > > > > > > > pfire.org if not yet done).
> > > > > > > > > 
> > > > > > > > > The source code can be found at http://git.ipfire.org
> > > > > > > > > /?
> > > > > > > > > p=people/st
> > > > > > > > > eve
> > > > > > > > > e/
> > > > > > > > > guardian.git;a=summary
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Happy testing,
> > > > > > > > > 
> > > > > > > > > -Stefan
> > > > > > > > > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Stefan Schantl]

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

Hello Matthias,

thanks for the hint - changed.

Best regards,

-Stefan
> Hi,
> 
> On 26.07.2016 17:10, Michael Tremer wrote:
> > 
> > Did anyone try to monitor the size of the log files that guardian
> > is parsing as
> > well? Could it be that every line that is read remains in memory?
> > 
> > This is just an idea...
> Could be, but I'm not so firm with such behaviour. I'm using 'syslog'
> and memory raises, see below.
> 
> Some things I found in the meantime while playing around:
> 
> '/etc/init.d/guardian' needs a 'sleep'-command for restart-option.
> Otherwise we get a warning that '/usr/sbin/guardian' is still
> running:
> 
> ...
> root(a)ipfire: ~ # /etc/init.d/guardian restart
> Stopping Guardian...
> Starting Guardian...
> Unable to continue: /usr/sbin/guardian is running
>                   [ WARN ]
> ...
> 
> After adding 'sleep 2' between '$0 stop' and '$0 start' in
> '/etc/init.d/guardian', warning is gone:
> 
> ...
>         restart)
>                 $0 stop
>                 sleep 2
>                 $0 start
> ...
> 
> Output:
> 
> root(a)ipfire: /etc/init.d # /etc/init.d/guardian restart
> Stopping Guardian...
> Starting Guardian...
>                   [  OK  ]
> 
> ##########
> 
> Each saving through GUI alters memory usage of 'guardian' process.
> 
> Example (logging to 'syslog'!).
> While switching (e.g.) 'Loglevel' from '2' to '3' and back again,
> each
> saving alters memory usage for about 9 MB (see my former message
> above,
> 21.7.2016/11:07pm). I stopped at ~56289 MB.
> 
> After stopping and starting 'guardian' process is at ~14334 MB again.
> 
> If you do nothing, it stays there.
> 
> ##########
> 
> Saving firewall rules changes sometimes 'pstree'-output for
> 'guardian':
> 
> Before:
> 
> root(a)ipfire: /etc/init.d # pstree
> init-+-acpid
>      |-6*[agetty]
>      |-clamd---{clamd}
>      |-collectd---3*[{collectd}]
>      |-dhcpd
>      |-dnsmasq
>      |-fcron
>      |-freshclam
>      |-guardian---4*[{guardian}]
>      |-httpd---10*[httpd]
>      |-klogd
>      |-privoxy---11*[{privoxy}]
>      |-saslauthd---saslauthd
>      |-snort---{snort}
>      |-squid---squid-+-16*[redirect_wrappe-+-squidGuard]
>      |               |                     `-squidclamav]
>      |               `-16*[{squid}]
>      |-sshd---bash---pstree
>      |-syslogd
>      `-udevd
> 
> As you see, output for'guardian' is:
> 
> ...
>      |-guardian---4*[{guardian}]
> 
> ...
> 
> Today, after activating/deactivating one firewall rule and clicking
> 'Apply changes':
> 
> root(a)ipfire: ~ # pstree
> init-+-acpid
>      |-6*[agetty]
>      |-clamd---2*[{clamd}]
>      |-collectd---3*[{collectd}]
>      |-dhcpd
>      |-dnsmasq
>      |-fcron
>      |-freshclam
>      |-guardian-+-iptables
>      |          `-4*[{guardian}]
>      |-httpd---10*[httpd]
>      |-klogd
>      |-privoxy
>      |-saslauthd---saslauthd
>      |-snort---{snort}
>      |-squid---squid-+-redirect_wrappe-+-squidGuard
>      |               |                 `-squidclamav
>      |               `-16*[{squid}]
>      |-sshd---bash---pstree
>      |-syslogd
>      `-udevd
> 
> Suddenly its says:
> 
> ...
>      |-guardian-+-iptables
>      |          `-4*[{guardian}]
> ...
> 
> I don't know why, perhaps someone has an idea what happened here?
> 
> Best,
> Matthias
> 
> > 
> > Best,
> > -Michael
> > 
> > On Sat, 2016-07-23 at 00:23 +0200, Matthias Fischer wrote:
> > > 
> > > Correction: in the meanwhile it jumped to 47890 KB, I don't know
> > > why.
> > > Logrotation?.
> > > 
> > > On 22.07.2016 22:28, Matthias Fischer wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > ...for the records...:
> > > > 
> > > > Since I switched "Loglevel" to OFF, memory usage stays at
> > > > "14333 KB" and
> > > > didn't change/rise since then.
> > > > 
> > > > HTH,
> > > > Matthias
> > > > 
> > > > On 21.07.2016 23:07, Matthias Fischer wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Sounds interesting.
> > > > > 
> > > > > So I thought I take a little test...
> > > > > 
> > > > > Initial RAM-Usage: 14334 KB
> > > > > 
> > > > > First I just switched logging, did nothing else:
> > > > > 
> > > > > syslog => file => 22726 KB
> > > > > file => syslog => 31117 KB
> > > > > syslog => file => 39507/47898 KB (RAM suddenly altered. Why?
> > > > > No idea.)
> > > > > file => syslog => 56289 KB
> > > > > 
> > > > > Restarted through console:
> > > > > 
> > > > > root(a)ipfire: /var/log/guardian # guardianctrl restart
> > > > > Stopping Guardian...
> > > > > Starting Guardian...
> > > > > Unable to continue: /usr/sbin/guardian is running
> > > > >                   [ WARN ]
> > > > > 
> > > > > Hm?
> > > > > 
> > > > > Stopped through console, no output, 'guardian' not found
> > > > > anymore,
> > > > > neither in GUI nor through console:
> > > > > 
> > > > > root(a)ipfire: /var/log/guardian # ps ax | grep guardian
> > > > >  6962 pts/1    S+     0:00 grep guardian
> > > > > 
> > > > > Started through console and we're exactly where we started
> > > > > (14334 KB).
> > > > > 
> > > > > The same happens if I switch the 'Priority-level' or the
> > > > > 'Firewall-
> > > > > Action'.
> > > > > 
> > > > > Initial: 2
> > > > > 2 => 3 => 22723 KB
> > > > > 3 => 2 => 31112 KB
> > > > > 
> > > > > Firewall-Action:
> > > > > Reject => Drop => 39501 KB
> > > > > 
> > > > > Stop => Start => 14334 KB
> > > > > 
> > > > > Interestingly, during MY (log-)switching, 'guardian' never
> > > > > stopped.
> > > > > 
> > > > > HTH,
> > > > > Matthias
> > > > > 
> > > > > On 21.07.2016 21:52, Flying Trashcan wrote:
> > > > > > 
> > > > > > I am now noticing that when I switch from Log facility
> > > > > > “file” to
> > > > > > “syslog”, Guardian Daemon stops and doesn’t
> > > > > > restart.  Switching from
> > > > > > syslog to file didn’t stop the service, only switching back
> > > > > > to syslog
> > > > > > from file.  I can manually start the service and be back to
> > > > > > normal.  Not
> > > > > > a big deal, but if someone made the switch and didn’t think
> > > > > > to manually
> > > > > > start the service, it could be left without running
> > > > > > Guardian.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > On Jul 21, 2016, at 4:25 AM, Matthias Fischer <matthias.f
> > > > > > > ischer(a)ipfire
> > > > > > > .org> wrote:
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I mentioned this earlier, but it seems that 'guardian'
> > > > > > > has some kind
> > > > > > > of
> > > > > > > memory leak?
> > > > > > > 
> > > > > > > It started about two days ago with ~14 MB RAM. Then it
> > > > > > > jumped to ~34
> > > > > > > MB,
> > > > > > > then to ~48 MB - today it suddenly uses 71 MB.
> > > > > > > 
> > > > > > > And if I start it on my testmachine (offline!) it uses
> > > > > > > ~90 MB.
> > > > > > > 
> > > > > > > Can someone confirm?
> > > > > > > 
> > > > > > > Besides this, its working without seen problems.
> > > > > > > 
> > > > > > > Best,
> > > > > > > Matthias
> > > > > > > 
> > > > > > > On 20.07.2016 15:33, Stefan Schantl wrote:
> > > > > > > > 
> > > > > > > > Hello testers,
> > > > > > > > 
> > > > > > > > I've uploaded  a new test version (003).
> > > > > > > > 
> > > > > > > > Update or fresh install works like described in the
> > > > > > > > announcement
> > > > > > > > mail.
> > > > > > > > 
> > > > > > > > The Changelog can be found here:
> > > > > > > > 
> > > > > > > > http://people.ipfire.org/~stevee/guardian-2.0/Changelog
> > > > > > > > .txt
> > > > > > > > 
> > > > > > > > At the moment I'm missing feedback for the following
> > > > > > > > functions:
> > > > > > > > 
> > > > > > > > * Manually blocking / unblocking addresses.
> > > > > > > > * Dealing with the ignore list.
> > > > > > > > * Owncloud message parser.
> > > > > > > > * Logrotate, there should be an corresponding log entry
> > > > > > > > in the
> > > > > > > > guardian
> > > > > > > > logfile after rotation of the logfiles have been done.
> > > > > > > > * Reload of the ignore list after "Red" has been
> > > > > > > > reconnected. There
> > > > > > > > also a corresponding log entry should be logged to the
> > > > > > > > logfile and
> > > > > > > > the
> > > > > > > > new "Red-address" should also be logged as part of the
> > > > > > > > ignore list
> > > > > > > > (If
> > > > > > > > you own an dynamic assigned one).
> > > > > > > > 
> > > > > > > > As always please report your bugs or experience with
> > > > > > > > the new version
> > > > > > > > to
> > > > > > > > this list.
> > > > > > > > 
> > > > > > > > Best regards,
> > > > > > > > 
> > > > > > > > -Stefan
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hello mailing list followers,
> > > > > > > > > 
> > > > > > > > > this is the official release announcement for the
> > > > > > > > > first beta
> > > > > > > > > release
> > > > > > > > > of
> > > > > > > > > the new Guardian 2.0 approach.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > - What are the differences to the current version of
> > > > > > > > > guardian
> > > > > > > > > (legacy)
> > > > > > > > > and the first approach of guardian 2.0?
> > > > > > > > > 
> > > > > > > > > The most important difference is, that the new
> > > > > > > > > version of Guardian
> > > > > > > > > 2.0
> > > > > > > > > completely has been re-written from scratch and
> > > > > > > > > released under the
> > > > > > > > > terms of the GPLv3. The legacy version of guardian is
> > > > > > > > > not
> > > > > > > > > maintained
> > > > > > > > > anymore by it's developer and the software has been
> > > > > > > > > released
> > > > > > > > > without
> > > > > > > > > any license details at all.
> > > > > > > > > 
> > > > > > > > > Guardian 2.0 has a very modular code base and has
> > > > > > > > > been designed as
> > > > > > > > > a
> > > > > > > > > multi-threaded application. This allows a parallel
> > > > > > > > > parsing of all
> > > > > > > > > monitored logfiles and faster actions, if one of the
> > > > > > > > > used modules
> > > > > > > > > detects an attack.
> > > > > > > > > 
> > > > > > > > > A very important difference to the legacy version is
> > > > > > > > > the support
> > > > > > > > > of
> > > > > > > > > configuring and managing the entire service through
> > > > > > > > > the IPFire
> > > > > > > > > webinterface. The entire configuration, managing of
> > > > > > > > > current
> > > > > > > > > blocked
> > > > > > > > > hosts, unblocking them or editing the ignored hosts
> > > > > > > > > list now can
> > > > > > > > > be
> > > > > > > > > done in a graphical way. 
> > > > > > > > > 
> > > > > > > > > The legacy version of guardian only supported parsing
> > > > > > > > > snort
> > > > > > > > > alerts.
> > > > > > > > > HTTPD and SSH support has been patched by the IPFire
> > > > > > > > > development
> > > > > > > > > team
> > > > > > > > > some time ago. Guardian 2.0 supports all of them out
> > > > > > > > > of the box
> > > > > > > > > and
> > > > > > > > > includes a filter to detect owncloud login brute-
> > > > > > > > > force attempts.
> > > > > > > > > As a
> > > > > > > > > benefit of the new modular design, additional filters
> > > > > > > > > easily can
> > > > > > > > > be
> > > > > > > > > added.
> > > > > > > > > 
> > > > > > > > > Guardian 2.0 is able to reload it's configuration,
> > > > > > > > > reloading
> > > > > > > > > the ignore list during runtime and handle, if the
> > > > > > > > > logfiles will
> > > > > > > > > get
> > > > > > > > > rotated by logrotate. This actions can be called by
> > > > > > > > > using the
> > > > > > > > > webinterface or from the command line interface by
> > > > > > > > > using
> > > > > > > > > "guardianctrl".
> > > > > > > > > 
> > > > > > > > > These are just a handful of the changes and benefits
> > > > > > > > > which comes
> > > > > > > > > with
> > > > > > > > > Guardian 2.0, a complete list would be to long for
> > > > > > > > > this mailing
> > > > > > > > > list.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > - How to join testing?
> > > > > > > > > 
> > > > > > > > > To get part of the testing team, simple navigate to h
> > > > > > > > > ttp://people.
> > > > > > > > > ipf
> > > > > > > > > ir
> > > > > > > > > e.org/~stevee/guardian-2.0/ and download the latest
> > > > > > > > > tarball
> > > > > > > > > (currently
> > > > > > > > > 002). Please take care to download the correct one,
> > > > > > > > > based on your
> > > > > > > > > used
> > > > > > > > > architecture. The i585 packages are for 32Bit
> > > > > > > > > installations of
> > > > > > > > > IPFire,
> > > > > > > > > the x86_64 packages only can be used on 64Bit
> > > > > > > > > installations.
> > > > > > > > > 
> > > > > > > > > Put the downloaded file on your IPFire test system
> > > > > > > > > and extract the
> > > > > > > > > package by using "tar -xvf guardian-2.0-
> > > > > > > > > 002.<arch>.tar.gz -C /".
> > > > > > > > > 
> > > > > > > > > The final installation step would be to regenerate
> > > > > > > > > the language
> > > > > > > > > cache
> > > > > > > > > by executing "update-lang-cache" on the console.
> > > > > > > > > 
> > > > > > > > > From now you can find a new menu item called
> > > > > > > > > "Guardian" in your
> > > > > > > > > "Service" menu after you have logged-in into your
> > > > > > > > > IPFire's
> > > > > > > > > webinterface.
> > > > > > > > > 
> > > > > > > > > Documentation can be found on the IPFire wiki: http:/
> > > > > > > > > /wiki.ipfire.
> > > > > > > > > org
> > > > > > > > > /e
> > > > > > > > > n/addons/guardian/start#the_guardian_20_addon
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > - Where to post bugs reports or provide feedback?
> > > > > > > > > 
> > > > > > > > > If you find any bugs, please report them as usual on
> > > > > > > > > the IPFire
> > > > > > > > > bugtracker, which can be found at https://bugzilla.ip
> > > > > > > > > fire.org.
> > > > > > > > > 
> > > > > > > > > To provide feedback or to join a discussion, please
> > > > > > > > > send your
> > > > > > > > > mails
> > > > > > > > > to
> > > > > > > > > "development(a)lists.ipfire.org" (Please register first
> > > > > > > > > at http://li
> > > > > > > > > sts
> > > > > > > > > .i
> > > > > > > > > pfire.org if not yet done).
> > > > > > > > > 
> > > > > > > > > The source code can be found at http://git.ipfire.org
> > > > > > > > > /?p=people/st
> > > > > > > > > eve
> > > > > > > > > e/
> > > > > > > > > guardian.git;a=summary
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Happy testing,
> > > > > > > > > 
> > > > > > > > > -Stefan
> > > > > > > > > 
> > > > > > 
> > > > > 
> > > > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Stefan Schantl]

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

Hello testers,

after a lot of code debugging I was able to determine
the reason of those memory leak.

It is the default behavior of not freeing used virtual memory again
after a thread has been stopped.

Guardian stops and restarts each worker thread on a reload and a
logrotate event.

I'll have to rework the corresponding code to solve this issue and come
back after finished this.

Thanks for pointing this out,

-Stefan
> Did anyone try to monitor the size of the log files that guardian is
> parsing as
> well? Could it be that every line that is read remains in memory?
> 
> This is just an idea...
> 
> Best,
> -Michael
> 
> On Sat, 2016-07-23 at 00:23 +0200, Matthias Fischer wrote:
> > 
> > Correction: in the meanwhile it jumped to 47890 KB, I don't know
> > why.
> > Logrotation?.
> > 
> > On 22.07.2016 22:28, Matthias Fischer wrote:
> > > 
> > > Hi,
> > > 
> > > ...for the records...:
> > > 
> > > Since I switched "Loglevel" to OFF, memory usage stays at "14333
> > > KB" and
> > > didn't change/rise since then.
> > > 
> > > HTH,
> > > Matthias
> > > 
> > > On 21.07.2016 23:07, Matthias Fischer wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > Sounds interesting.
> > > > 
> > > > So I thought I take a little test...
> > > > 
> > > > Initial RAM-Usage: 14334 KB
> > > > 
> > > > First I just switched logging, did nothing else:
> > > > 
> > > > syslog => file => 22726 KB
> > > > file => syslog => 31117 KB
> > > > syslog => file => 39507/47898 KB (RAM suddenly altered. Why? No
> > > > idea.)
> > > > file => syslog => 56289 KB
> > > > 
> > > > Restarted through console:
> > > > 
> > > > root(a)ipfire: /var/log/guardian # guardianctrl restart
> > > > Stopping Guardian...
> > > > Starting Guardian...
> > > > Unable to continue: /usr/sbin/guardian is running
> > > >                   [ WARN ]
> > > > 
> > > > Hm?
> > > > 
> > > > Stopped through console, no output, 'guardian' not found
> > > > anymore,
> > > > neither in GUI nor through console:
> > > > 
> > > > root(a)ipfire: /var/log/guardian # ps ax | grep guardian
> > > >  6962 pts/1    S+     0:00 grep guardian
> > > > 
> > > > Started through console and we're exactly where we started
> > > > (14334 KB).
> > > > 
> > > > The same happens if I switch the 'Priority-level' or the
> > > > 'Firewall-
> > > > Action'.
> > > > 
> > > > Initial: 2
> > > > 2 => 3 => 22723 KB
> > > > 3 => 2 => 31112 KB
> > > > 
> > > > Firewall-Action:
> > > > Reject => Drop => 39501 KB
> > > > 
> > > > Stop => Start => 14334 KB
> > > > 
> > > > Interestingly, during MY (log-)switching, 'guardian' never
> > > > stopped.
> > > > 
> > > > HTH,
> > > > Matthias
> > > > 
> > > > On 21.07.2016 21:52, Flying Trashcan wrote:
> > > > > 
> > > > > I am now noticing that when I switch from Log facility “file”
> > > > > to
> > > > > “syslog”, Guardian Daemon stops and doesn’t
> > > > > restart.  Switching from
> > > > > syslog to file didn’t stop the service, only switching back
> > > > > to syslog
> > > > > from file.  I can manually start the service and be back to
> > > > > normal.  Not
> > > > > a big deal, but if someone made the switch and didn’t think
> > > > > to manually
> > > > > start the service, it could be left without running Guardian.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > On Jul 21, 2016, at 4:25 AM, Matthias Fischer <matthias.fis
> > > > > > cher(a)ipfire
> > > > > > .org> wrote:
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > I mentioned this earlier, but it seems that 'guardian' has
> > > > > > some kind
> > > > > > of
> > > > > > memory leak?
> > > > > > 
> > > > > > It started about two days ago with ~14 MB RAM. Then it
> > > > > > jumped to ~34
> > > > > > MB,
> > > > > > then to ~48 MB - today it suddenly uses 71 MB.
> > > > > > 
> > > > > > And if I start it on my testmachine (offline!) it uses ~90
> > > > > > MB.
> > > > > > 
> > > > > > Can someone confirm?
> > > > > > 
> > > > > > Besides this, its working without seen problems.
> > > > > > 
> > > > > > Best,
> > > > > > Matthias
> > > > > > 
> > > > > > On 20.07.2016 15:33, Stefan Schantl wrote:
> > > > > > > 
> > > > > > > Hello testers,
> > > > > > > 
> > > > > > > I've uploaded  a new test version (003).
> > > > > > > 
> > > > > > > Update or fresh install works like described in the
> > > > > > > announcement
> > > > > > > mail.
> > > > > > > 
> > > > > > > The Changelog can be found here:
> > > > > > > 
> > > > > > > http://people.ipfire.org/~stevee/guardian-2.0/Changelog.t
> > > > > > > xt
> > > > > > > 
> > > > > > > At the moment I'm missing feedback for the following
> > > > > > > functions:
> > > > > > > 
> > > > > > > * Manually blocking / unblocking addresses.
> > > > > > > * Dealing with the ignore list.
> > > > > > > * Owncloud message parser.
> > > > > > > * Logrotate, there should be an corresponding log entry
> > > > > > > in the
> > > > > > > guardian
> > > > > > > logfile after rotation of the logfiles have been done.
> > > > > > > * Reload of the ignore list after "Red" has been
> > > > > > > reconnected. There
> > > > > > > also a corresponding log entry should be logged to the
> > > > > > > logfile and
> > > > > > > the
> > > > > > > new "Red-address" should also be logged as part of the
> > > > > > > ignore list
> > > > > > > (If
> > > > > > > you own an dynamic assigned one).
> > > > > > > 
> > > > > > > As always please report your bugs or experience with the
> > > > > > > new version
> > > > > > > to
> > > > > > > this list.
> > > > > > > 
> > > > > > > Best regards,
> > > > > > > 
> > > > > > > -Stefan
> > > > > > > 
> > > > > > > > 
> > > > > > > > Hello mailing list followers,
> > > > > > > > 
> > > > > > > > this is the official release announcement for the first
> > > > > > > > beta
> > > > > > > > release
> > > > > > > > of
> > > > > > > > the new Guardian 2.0 approach.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > - What are the differences to the current version of
> > > > > > > > guardian
> > > > > > > > (legacy)
> > > > > > > > and the first approach of guardian 2.0?
> > > > > > > > 
> > > > > > > > The most important difference is, that the new version
> > > > > > > > of Guardian
> > > > > > > > 2.0
> > > > > > > > completely has been re-written from scratch and
> > > > > > > > released under the
> > > > > > > > terms of the GPLv3. The legacy version of guardian is
> > > > > > > > not
> > > > > > > > maintained
> > > > > > > > anymore by it's developer and the software has been
> > > > > > > > released
> > > > > > > > without
> > > > > > > > any license details at all.
> > > > > > > > 
> > > > > > > > Guardian 2.0 has a very modular code base and has been
> > > > > > > > designed as
> > > > > > > > a
> > > > > > > > multi-threaded application. This allows a parallel
> > > > > > > > parsing of all
> > > > > > > > monitored logfiles and faster actions, if one of the
> > > > > > > > used modules
> > > > > > > > detects an attack.
> > > > > > > > 
> > > > > > > > A very important difference to the legacy version is
> > > > > > > > the support
> > > > > > > > of
> > > > > > > > configuring and managing the entire service through the
> > > > > > > > IPFire
> > > > > > > > webinterface. The entire configuration, managing of
> > > > > > > > current
> > > > > > > > blocked
> > > > > > > > hosts, unblocking them or editing the ignored hosts
> > > > > > > > list now can
> > > > > > > > be
> > > > > > > > done in a graphical way. 
> > > > > > > > 
> > > > > > > > The legacy version of guardian only supported parsing
> > > > > > > > snort
> > > > > > > > alerts.
> > > > > > > > HTTPD and SSH support has been patched by the IPFire
> > > > > > > > development
> > > > > > > > team
> > > > > > > > some time ago. Guardian 2.0 supports all of them out of
> > > > > > > > the box
> > > > > > > > and
> > > > > > > > includes a filter to detect owncloud login brute-force
> > > > > > > > attempts.
> > > > > > > > As a
> > > > > > > > benefit of the new modular design, additional filters
> > > > > > > > easily can
> > > > > > > > be
> > > > > > > > added.
> > > > > > > > 
> > > > > > > > Guardian 2.0 is able to reload it's configuration,
> > > > > > > > reloading
> > > > > > > > the ignore list during runtime and handle, if the
> > > > > > > > logfiles will
> > > > > > > > get
> > > > > > > > rotated by logrotate. This actions can be called by
> > > > > > > > using the
> > > > > > > > webinterface or from the command line interface by
> > > > > > > > using
> > > > > > > > "guardianctrl".
> > > > > > > > 
> > > > > > > > These are just a handful of the changes and benefits
> > > > > > > > which comes
> > > > > > > > with
> > > > > > > > Guardian 2.0, a complete list would be to long for this
> > > > > > > > mailing
> > > > > > > > list.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > - How to join testing?
> > > > > > > > 
> > > > > > > > To get part of the testing team, simple navigate to htt
> > > > > > > > p://people.
> > > > > > > > ipf
> > > > > > > > ir
> > > > > > > > e.org/~stevee/guardian-2.0/ and download the latest
> > > > > > > > tarball
> > > > > > > > (currently
> > > > > > > > 002). Please take care to download the correct one,
> > > > > > > > based on your
> > > > > > > > used
> > > > > > > > architecture. The i585 packages are for 32Bit
> > > > > > > > installations of
> > > > > > > > IPFire,
> > > > > > > > the x86_64 packages only can be used on 64Bit
> > > > > > > > installations.
> > > > > > > > 
> > > > > > > > Put the downloaded file on your IPFire test system and
> > > > > > > > extract the
> > > > > > > > package by using "tar -xvf guardian-2.0-
> > > > > > > > 002.<arch>.tar.gz -C /".
> > > > > > > > 
> > > > > > > > The final installation step would be to regenerate the
> > > > > > > > language
> > > > > > > > cache
> > > > > > > > by executing "update-lang-cache" on the console.
> > > > > > > > 
> > > > > > > > From now you can find a new menu item called "Guardian"
> > > > > > > > in your
> > > > > > > > "Service" menu after you have logged-in into your
> > > > > > > > IPFire's
> > > > > > > > webinterface.
> > > > > > > > 
> > > > > > > > Documentation can be found on the IPFire wiki: http://w
> > > > > > > > iki.ipfire.
> > > > > > > > org
> > > > > > > > /e
> > > > > > > > n/addons/guardian/start#the_guardian_20_addon
> > > > > > > > 
> > > > > > > > 
> > > > > > > > - Where to post bugs reports or provide feedback?
> > > > > > > > 
> > > > > > > > If you find any bugs, please report them as usual on
> > > > > > > > the IPFire
> > > > > > > > bugtracker, which can be found at https://bugzilla.ipfi
> > > > > > > > re.org.
> > > > > > > > 
> > > > > > > > To provide feedback or to join a discussion, please
> > > > > > > > send your
> > > > > > > > mails
> > > > > > > > to
> > > > > > > > "development(a)lists.ipfire.org" (Please register first
> > > > > > > > at http://li
> > > > > > > > sts
> > > > > > > > .i
> > > > > > > > pfire.org if not yet done).
> > > > > > > > 
> > > > > > > > The source code can be found at http://git.ipfire.org/?
> > > > > > > > p=people/st
> > > > > > > > eve
> > > > > > > > e/
> > > > > > > > guardian.git;a=summary
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Happy testing,
> > > > > > > > 
> > > > > > > > -Stefan
> > > > > > > > 
> > > > > 
> > > > 
> > > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

On 26.07.2016 17:10, Michael Tremer wrote:
> Did anyone try to monitor the size of the log files that guardian is parsing as
> well? Could it be that every line that is read remains in memory?
> 
> This is just an idea...

Could be, but I'm not so firm with such behaviour. I'm using 'syslog'
and memory raises, see below.

Some things I found in the meantime while playing around:

'/etc/init.d/guardian' needs a 'sleep'-command for restart-option.
Otherwise we get a warning that '/usr/sbin/guardian' is still running:

...
root(a)ipfire: ~ # /etc/init.d/guardian restart
Stopping Guardian...
Starting Guardian...
Unable to continue: /usr/sbin/guardian is running
                  [ WARN ]
...

After adding 'sleep 2' between '$0 stop' and '$0 start' in
'/etc/init.d/guardian', warning is gone:

...
        restart)
                $0 stop
                sleep 2
                $0 start
...

Output:

root(a)ipfire: /etc/init.d # /etc/init.d/guardian restart
Stopping Guardian...
Starting Guardian...
                  [  OK  ]

##########

Each saving through GUI alters memory usage of 'guardian' process.

Example (logging to 'syslog'!).
While switching (e.g.) 'Loglevel' from '2' to '3' and back again, each
saving alters memory usage for about 9 MB (see my former message above,
21.7.2016/11:07pm). I stopped at ~56289 MB.

After stopping and starting 'guardian' process is at ~14334 MB again.

If you do nothing, it stays there.

##########

Saving firewall rules changes sometimes 'pstree'-output for 'guardian':

Before:

root(a)ipfire: /etc/init.d # pstree
init-+-acpid
     |-6*[agetty]
     |-clamd---{clamd}
     |-collectd---3*[{collectd}]
     |-dhcpd
     |-dnsmasq
     |-fcron
     |-freshclam
     |-guardian---4*[{guardian}]
     |-httpd---10*[httpd]
     |-klogd
     |-privoxy---11*[{privoxy}]
     |-saslauthd---saslauthd
     |-snort---{snort}
     |-squid---squid-+-16*[redirect_wrappe-+-squidGuard]
     |               |                     `-squidclamav]
     |               `-16*[{squid}]
     |-sshd---bash---pstree
     |-syslogd
     `-udevd

As you see, output for'guardian' is:

...
     |-guardian---4*[{guardian}]

...

Today, after activating/deactivating one firewall rule and clicking
'Apply changes':

root(a)ipfire: ~ # pstree
init-+-acpid
     |-6*[agetty]
     |-clamd---2*[{clamd}]
     |-collectd---3*[{collectd}]
     |-dhcpd
     |-dnsmasq
     |-fcron
     |-freshclam
     |-guardian-+-iptables
     |          `-4*[{guardian}]
     |-httpd---10*[httpd]
     |-klogd
     |-privoxy
     |-saslauthd---saslauthd
     |-snort---{snort}
     |-squid---squid-+-redirect_wrappe-+-squidGuard
     |               |                 `-squidclamav
     |               `-16*[{squid}]
     |-sshd---bash---pstree
     |-syslogd
     `-udevd

Suddenly its says:

...
     |-guardian-+-iptables
     |          `-4*[{guardian}]
...

I don't know why, perhaps someone has an idea what happened here?

Best,
Matthias

> Best,
> -Michael
> 
> On Sat, 2016-07-23 at 00:23 +0200, Matthias Fischer wrote:
>> Correction: in the meanwhile it jumped to 47890 KB, I don't know why.
>> Logrotation?.
>> 
>> On 22.07.2016 22:28, Matthias Fischer wrote:
>> > Hi,
>> > 
>> > ...for the records...:
>> > 
>> > Since I switched "Loglevel" to OFF, memory usage stays at "14333 KB" and
>> > didn't change/rise since then.
>> > 
>> > HTH,
>> > Matthias
>> > 
>> > On 21.07.2016 23:07, Matthias Fischer wrote:
>> > > Hi,
>> > > 
>> > > Sounds interesting.
>> > > 
>> > > So I thought I take a little test...
>> > > 
>> > > Initial RAM-Usage: 14334 KB
>> > > 
>> > > First I just switched logging, did nothing else:
>> > > 
>> > > syslog => file => 22726 KB
>> > > file => syslog => 31117 KB
>> > > syslog => file => 39507/47898 KB (RAM suddenly altered. Why? No idea.)
>> > > file => syslog => 56289 KB
>> > > 
>> > > Restarted through console:
>> > > 
>> > > root(a)ipfire: /var/log/guardian # guardianctrl restart
>> > > Stopping Guardian...
>> > > Starting Guardian...
>> > > Unable to continue: /usr/sbin/guardian is running
>> > >                   [ WARN ]
>> > > 
>> > > Hm?
>> > > 
>> > > Stopped through console, no output, 'guardian' not found anymore,
>> > > neither in GUI nor through console:
>> > > 
>> > > root(a)ipfire: /var/log/guardian # ps ax | grep guardian
>> > >  6962 pts/1    S+     0:00 grep guardian
>> > > 
>> > > Started through console and we're exactly where we started (14334 KB).
>> > > 
>> > > The same happens if I switch the 'Priority-level' or the 'Firewall-
>> > > Action'.
>> > > 
>> > > Initial: 2
>> > > 2 => 3 => 22723 KB
>> > > 3 => 2 => 31112 KB
>> > > 
>> > > Firewall-Action:
>> > > Reject => Drop => 39501 KB
>> > > 
>> > > Stop => Start => 14334 KB
>> > > 
>> > > Interestingly, during MY (log-)switching, 'guardian' never stopped.
>> > > 
>> > > HTH,
>> > > Matthias
>> > > 
>> > > On 21.07.2016 21:52, Flying Trashcan wrote:
>> > > > I am now noticing that when I switch from Log facility “file” to
>> > > > “syslog”, Guardian Daemon stops and doesn’t restart.  Switching from
>> > > > syslog to file didn’t stop the service, only switching back to syslog
>> > > > from file.  I can manually start the service and be back to normal.  Not
>> > > > a big deal, but if someone made the switch and didn’t think to manually
>> > > > start the service, it could be left without running Guardian.
>> > > > 
>> > > > 
>> > > > 
>> > > > 
>> > > > > On Jul 21, 2016, at 4:25 AM, Matthias Fischer <matthias.fischer(a)ipfire
>> > > > > .org> wrote:
>> > > > > 
>> > > > > Hi,
>> > > > > 
>> > > > > I mentioned this earlier, but it seems that 'guardian' has some kind
>> > > > > of
>> > > > > memory leak?
>> > > > > 
>> > > > > It started about two days ago with ~14 MB RAM. Then it jumped to ~34
>> > > > > MB,
>> > > > > then to ~48 MB - today it suddenly uses 71 MB.
>> > > > > 
>> > > > > And if I start it on my testmachine (offline!) it uses ~90 MB.
>> > > > > 
>> > > > > Can someone confirm?
>> > > > > 
>> > > > > Besides this, its working without seen problems.
>> > > > > 
>> > > > > Best,
>> > > > > Matthias
>> > > > > 
>> > > > > On 20.07.2016 15:33, Stefan Schantl wrote:
>> > > > > > Hello testers,
>> > > > > > 
>> > > > > > I've uploaded  a new test version (003).
>> > > > > > 
>> > > > > > Update or fresh install works like described in the announcement
>> > > > > > mail.
>> > > > > > 
>> > > > > > The Changelog can be found here:
>> > > > > > 
>> > > > > > http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
>> > > > > > 
>> > > > > > At the moment I'm missing feedback for the following functions:
>> > > > > > 
>> > > > > > * Manually blocking / unblocking addresses.
>> > > > > > * Dealing with the ignore list.
>> > > > > > * Owncloud message parser.
>> > > > > > * Logrotate, there should be an corresponding log entry in the
>> > > > > > guardian
>> > > > > > logfile after rotation of the logfiles have been done.
>> > > > > > * Reload of the ignore list after "Red" has been reconnected. There
>> > > > > > also a corresponding log entry should be logged to the logfile and
>> > > > > > the
>> > > > > > new "Red-address" should also be logged as part of the ignore list
>> > > > > > (If
>> > > > > > you own an dynamic assigned one).
>> > > > > > 
>> > > > > > As always please report your bugs or experience with the new version
>> > > > > > to
>> > > > > > this list.
>> > > > > > 
>> > > > > > Best regards,
>> > > > > > 
>> > > > > > -Stefan
>> > > > > > 
>> > > > > > > Hello mailing list followers,
>> > > > > > > 
>> > > > > > > this is the official release announcement for the first beta
>> > > > > > > release
>> > > > > > > of
>> > > > > > > the new Guardian 2.0 approach.
>> > > > > > > 
>> > > > > > > 
>> > > > > > > - What are the differences to the current version of guardian
>> > > > > > > (legacy)
>> > > > > > > and the first approach of guardian 2.0?
>> > > > > > > 
>> > > > > > > The most important difference is, that the new version of Guardian
>> > > > > > > 2.0
>> > > > > > > completely has been re-written from scratch and released under the
>> > > > > > > terms of the GPLv3. The legacy version of guardian is not
>> > > > > > > maintained
>> > > > > > > anymore by it's developer and the software has been released
>> > > > > > > without
>> > > > > > > any license details at all.
>> > > > > > > 
>> > > > > > > Guardian 2.0 has a very modular code base and has been designed as
>> > > > > > > a
>> > > > > > > multi-threaded application. This allows a parallel parsing of all
>> > > > > > > monitored logfiles and faster actions, if one of the used modules
>> > > > > > > detects an attack.
>> > > > > > > 
>> > > > > > > A very important difference to the legacy version is the support
>> > > > > > > of
>> > > > > > > configuring and managing the entire service through the IPFire
>> > > > > > > webinterface. The entire configuration, managing of current
>> > > > > > > blocked
>> > > > > > > hosts, unblocking them or editing the ignored hosts list now can
>> > > > > > > be
>> > > > > > > done in a graphical way. 
>> > > > > > > 
>> > > > > > > The legacy version of guardian only supported parsing snort
>> > > > > > > alerts.
>> > > > > > > HTTPD and SSH support has been patched by the IPFire development
>> > > > > > > team
>> > > > > > > some time ago. Guardian 2.0 supports all of them out of the box
>> > > > > > > and
>> > > > > > > includes a filter to detect owncloud login brute-force attempts.
>> > > > > > > As a
>> > > > > > > benefit of the new modular design, additional filters easily can
>> > > > > > > be
>> > > > > > > added.
>> > > > > > > 
>> > > > > > > Guardian 2.0 is able to reload it's configuration, reloading
>> > > > > > > the ignore list during runtime and handle, if the logfiles will
>> > > > > > > get
>> > > > > > > rotated by logrotate. This actions can be called by using the
>> > > > > > > webinterface or from the command line interface by using
>> > > > > > > "guardianctrl".
>> > > > > > > 
>> > > > > > > These are just a handful of the changes and benefits which comes
>> > > > > > > with
>> > > > > > > Guardian 2.0, a complete list would be to long for this mailing
>> > > > > > > list.
>> > > > > > > 
>> > > > > > > 
>> > > > > > > - How to join testing?
>> > > > > > > 
>> > > > > > > To get part of the testing team, simple navigate to http://people.
>> > > > > > > ipf
>> > > > > > > ir
>> > > > > > > e.org/~stevee/guardian-2.0/ and download the latest tarball
>> > > > > > > (currently
>> > > > > > > 002). Please take care to download the correct one, based on your
>> > > > > > > used
>> > > > > > > architecture. The i585 packages are for 32Bit installations of
>> > > > > > > IPFire,
>> > > > > > > the x86_64 packages only can be used on 64Bit installations.
>> > > > > > > 
>> > > > > > > Put the downloaded file on your IPFire test system and extract the
>> > > > > > > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>> > > > > > > 
>> > > > > > > The final installation step would be to regenerate the language
>> > > > > > > cache
>> > > > > > > by executing "update-lang-cache" on the console.
>> > > > > > > 
>> > > > > > > From now you can find a new menu item called "Guardian" in your
>> > > > > > > "Service" menu after you have logged-in into your IPFire's
>> > > > > > > webinterface.
>> > > > > > > 
>> > > > > > > Documentation can be found on the IPFire wiki: http://wiki.ipfire.
>> > > > > > > org
>> > > > > > > /e
>> > > > > > > n/addons/guardian/start#the_guardian_20_addon
>> > > > > > > 
>> > > > > > > 
>> > > > > > > - Where to post bugs reports or provide feedback?
>> > > > > > > 
>> > > > > > > If you find any bugs, please report them as usual on the IPFire
>> > > > > > > bugtracker, which can be found at https://bugzilla.ipfire.org.
>> > > > > > > 
>> > > > > > > To provide feedback or to join a discussion, please send your
>> > > > > > > mails
>> > > > > > > to
>> > > > > > > "development(a)lists.ipfire.org" (Please register first at http://li
>> > > > > > > sts
>> > > > > > > .i
>> > > > > > > pfire.org if not yet done).
>> > > > > > > 
>> > > > > > > The source code can be found at http://git.ipfire.org/?p=people/st
>> > > > > > > eve
>> > > > > > > e/
>> > > > > > > guardian.git;a=summary
>> > > > > > > 
>> > > > > > > 
>> > > > > > > Happy testing,
>> > > > > > > 
>> > > > > > > -Stefan
>> > > > > > > 
>> > > > > > 
>> > > > > 
>> > > > 
>> > > > 
>> > > 
>> > > 
>> > 
>> > 
>> 
> 

Re: Betatest Guardian 2.0

[Michael Tremer]

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

Did anyone try to monitor the size of the log files that guardian is parsing as
well? Could it be that every line that is read remains in memory?

This is just an idea...

Best,
-Michael

On Sat, 2016-07-23 at 00:23 +0200, Matthias Fischer wrote:
> Correction: in the meanwhile it jumped to 47890 KB, I don't know why.
> Logrotation?.
> 
> On 22.07.2016 22:28, Matthias Fischer wrote:
> > Hi,
> > 
> > ...for the records...:
> > 
> > Since I switched "Loglevel" to OFF, memory usage stays at "14333 KB" and
> > didn't change/rise since then.
> > 
> > HTH,
> > Matthias
> > 
> > On 21.07.2016 23:07, Matthias Fischer wrote:
> > > Hi,
> > > 
> > > Sounds interesting.
> > > 
> > > So I thought I take a little test...
> > > 
> > > Initial RAM-Usage: 14334 KB
> > > 
> > > First I just switched logging, did nothing else:
> > > 
> > > syslog => file => 22726 KB
> > > file => syslog => 31117 KB
> > > syslog => file => 39507/47898 KB (RAM suddenly altered. Why? No idea.)
> > > file => syslog => 56289 KB
> > > 
> > > Restarted through console:
> > > 
> > > root(a)ipfire: /var/log/guardian # guardianctrl restart
> > > Stopping Guardian...
> > > Starting Guardian...
> > > Unable to continue: /usr/sbin/guardian is running
> > >                   [ WARN ]
> > > 
> > > Hm?
> > > 
> > > Stopped through console, no output, 'guardian' not found anymore,
> > > neither in GUI nor through console:
> > > 
> > > root(a)ipfire: /var/log/guardian # ps ax | grep guardian
> > >  6962 pts/1    S+     0:00 grep guardian
> > > 
> > > Started through console and we're exactly where we started (14334 KB).
> > > 
> > > The same happens if I switch the 'Priority-level' or the 'Firewall-
> > > Action'.
> > > 
> > > Initial: 2
> > > 2 => 3 => 22723 KB
> > > 3 => 2 => 31112 KB
> > > 
> > > Firewall-Action:
> > > Reject => Drop => 39501 KB
> > > 
> > > Stop => Start => 14334 KB
> > > 
> > > Interestingly, during MY (log-)switching, 'guardian' never stopped.
> > > 
> > > HTH,
> > > Matthias
> > > 
> > > On 21.07.2016 21:52, Flying Trashcan wrote:
> > > > I am now noticing that when I switch from Log facility “file” to
> > > > “syslog”, Guardian Daemon stops and doesn’t restart.  Switching from
> > > > syslog to file didn’t stop the service, only switching back to syslog
> > > > from file.  I can manually start the service and be back to normal.  Not
> > > > a big deal, but if someone made the switch and didn’t think to manually
> > > > start the service, it could be left without running Guardian.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > On Jul 21, 2016, at 4:25 AM, Matthias Fischer <matthias.fischer(a)ipfire
> > > > > .org> wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I mentioned this earlier, but it seems that 'guardian' has some kind
> > > > > of
> > > > > memory leak?
> > > > > 
> > > > > It started about two days ago with ~14 MB RAM. Then it jumped to ~34
> > > > > MB,
> > > > > then to ~48 MB - today it suddenly uses 71 MB.
> > > > > 
> > > > > And if I start it on my testmachine (offline!) it uses ~90 MB.
> > > > > 
> > > > > Can someone confirm?
> > > > > 
> > > > > Besides this, its working without seen problems.
> > > > > 
> > > > > Best,
> > > > > Matthias
> > > > > 
> > > > > On 20.07.2016 15:33, Stefan Schantl wrote:
> > > > > > Hello testers,
> > > > > > 
> > > > > > I've uploaded  a new test version (003).
> > > > > > 
> > > > > > Update or fresh install works like described in the announcement
> > > > > > mail.
> > > > > > 
> > > > > > The Changelog can be found here:
> > > > > > 
> > > > > > http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
> > > > > > 
> > > > > > At the moment I'm missing feedback for the following functions:
> > > > > > 
> > > > > > * Manually blocking / unblocking addresses.
> > > > > > * Dealing with the ignore list.
> > > > > > * Owncloud message parser.
> > > > > > * Logrotate, there should be an corresponding log entry in the
> > > > > > guardian
> > > > > > logfile after rotation of the logfiles have been done.
> > > > > > * Reload of the ignore list after "Red" has been reconnected. There
> > > > > > also a corresponding log entry should be logged to the logfile and
> > > > > > the
> > > > > > new "Red-address" should also be logged as part of the ignore list
> > > > > > (If
> > > > > > you own an dynamic assigned one).
> > > > > > 
> > > > > > As always please report your bugs or experience with the new version
> > > > > > to
> > > > > > this list.
> > > > > > 
> > > > > > Best regards,
> > > > > > 
> > > > > > -Stefan
> > > > > > 
> > > > > > > Hello mailing list followers,
> > > > > > > 
> > > > > > > this is the official release announcement for the first beta
> > > > > > > release
> > > > > > > of
> > > > > > > the new Guardian 2.0 approach.
> > > > > > > 
> > > > > > > 
> > > > > > > - What are the differences to the current version of guardian
> > > > > > > (legacy)
> > > > > > > and the first approach of guardian 2.0?
> > > > > > > 
> > > > > > > The most important difference is, that the new version of Guardian
> > > > > > > 2.0
> > > > > > > completely has been re-written from scratch and released under the
> > > > > > > terms of the GPLv3. The legacy version of guardian is not
> > > > > > > maintained
> > > > > > > anymore by it's developer and the software has been released
> > > > > > > without
> > > > > > > any license details at all.
> > > > > > > 
> > > > > > > Guardian 2.0 has a very modular code base and has been designed as
> > > > > > > a
> > > > > > > multi-threaded application. This allows a parallel parsing of all
> > > > > > > monitored logfiles and faster actions, if one of the used modules
> > > > > > > detects an attack.
> > > > > > > 
> > > > > > > A very important difference to the legacy version is the support
> > > > > > > of
> > > > > > > configuring and managing the entire service through the IPFire
> > > > > > > webinterface. The entire configuration, managing of current
> > > > > > > blocked
> > > > > > > hosts, unblocking them or editing the ignored hosts list now can
> > > > > > > be
> > > > > > > done in a graphical way. 
> > > > > > > 
> > > > > > > The legacy version of guardian only supported parsing snort
> > > > > > > alerts.
> > > > > > > HTTPD and SSH support has been patched by the IPFire development
> > > > > > > team
> > > > > > > some time ago. Guardian 2.0 supports all of them out of the box
> > > > > > > and
> > > > > > > includes a filter to detect owncloud login brute-force attempts.
> > > > > > > As a
> > > > > > > benefit of the new modular design, additional filters easily can
> > > > > > > be
> > > > > > > added.
> > > > > > > 
> > > > > > > Guardian 2.0 is able to reload it's configuration, reloading
> > > > > > > the ignore list during runtime and handle, if the logfiles will
> > > > > > > get
> > > > > > > rotated by logrotate. This actions can be called by using the
> > > > > > > webinterface or from the command line interface by using
> > > > > > > "guardianctrl".
> > > > > > > 
> > > > > > > These are just a handful of the changes and benefits which comes
> > > > > > > with
> > > > > > > Guardian 2.0, a complete list would be to long for this mailing
> > > > > > > list.
> > > > > > > 
> > > > > > > 
> > > > > > > - How to join testing?
> > > > > > > 
> > > > > > > To get part of the testing team, simple navigate to http://people.
> > > > > > > ipf
> > > > > > > ir
> > > > > > > e.org/~stevee/guardian-2.0/ and download the latest tarball
> > > > > > > (currently
> > > > > > > 002). Please take care to download the correct one, based on your
> > > > > > > used
> > > > > > > architecture. The i585 packages are for 32Bit installations of
> > > > > > > IPFire,
> > > > > > > the x86_64 packages only can be used on 64Bit installations.
> > > > > > > 
> > > > > > > Put the downloaded file on your IPFire test system and extract the
> > > > > > > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
> > > > > > > 
> > > > > > > The final installation step would be to regenerate the language
> > > > > > > cache
> > > > > > > by executing "update-lang-cache" on the console.
> > > > > > > 
> > > > > > > From now you can find a new menu item called "Guardian" in your
> > > > > > > "Service" menu after you have logged-in into your IPFire's
> > > > > > > webinterface.
> > > > > > > 
> > > > > > > Documentation can be found on the IPFire wiki: http://wiki.ipfire.
> > > > > > > org
> > > > > > > /e
> > > > > > > n/addons/guardian/start#the_guardian_20_addon
> > > > > > > 
> > > > > > > 
> > > > > > > - Where to post bugs reports or provide feedback?
> > > > > > > 
> > > > > > > If you find any bugs, please report them as usual on the IPFire
> > > > > > > bugtracker, which can be found at https://bugzilla.ipfire.org.
> > > > > > > 
> > > > > > > To provide feedback or to join a discussion, please send your
> > > > > > > mails
> > > > > > > to
> > > > > > > "development(a)lists.ipfire.org" (Please register first at http://li
> > > > > > > sts
> > > > > > > .i
> > > > > > > pfire.org if not yet done).
> > > > > > > 
> > > > > > > The source code can be found at http://git.ipfire.org/?p=people/st
> > > > > > > eve
> > > > > > > e/
> > > > > > > guardian.git;a=summary
> > > > > > > 
> > > > > > > 
> > > > > > > Happy testing,
> > > > > > > 
> > > > > > > -Stefan
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Correction: in the meanwhile it jumped to 47890 KB, I don't know why.
Logrotation?.

On 22.07.2016 22:28, Matthias Fischer wrote:
> Hi,
> 
> ...for the records...:
> 
> Since I switched "Loglevel" to OFF, memory usage stays at "14333 KB" and
> didn't change/rise since then.
> 
> HTH,
> Matthias
> 
> On 21.07.2016 23:07, Matthias Fischer wrote:
>> Hi,
>> 
>> Sounds interesting.
>> 
>> So I thought I take a little test...
>> 
>> Initial RAM-Usage: 14334 KB
>> 
>> First I just switched logging, did nothing else:
>> 
>> syslog => file => 22726 KB
>> file => syslog => 31117 KB
>> syslog => file => 39507/47898 KB (RAM suddenly altered. Why? No idea.)
>> file => syslog => 56289 KB
>> 
>> Restarted through console:
>> 
>> root(a)ipfire: /var/log/guardian # guardianctrl restart
>> Stopping Guardian...
>> Starting Guardian...
>> Unable to continue: /usr/sbin/guardian is running
>>                   [ WARN ]
>> 
>> Hm?
>> 
>> Stopped through console, no output, 'guardian' not found anymore,
>> neither in GUI nor through console:
>> 
>> root(a)ipfire: /var/log/guardian # ps ax | grep guardian
>>  6962 pts/1    S+     0:00 grep guardian
>> 
>> Started through console and we're exactly where we started (14334 KB).
>> 
>> The same happens if I switch the 'Priority-level' or the 'Firewall-Action'.
>> 
>> Initial: 2
>> 2 => 3 => 22723 KB
>> 3 => 2 => 31112 KB
>> 
>> Firewall-Action:
>> Reject => Drop => 39501 KB
>> 
>> Stop => Start => 14334 KB
>> 
>> Interestingly, during MY (log-)switching, 'guardian' never stopped.
>> 
>> HTH,
>> Matthias
>> 
>> On 21.07.2016 21:52, Flying Trashcan wrote:
>>> I am now noticing that when I switch from Log facility “file” to “syslog”, Guardian Daemon stops and doesn’t restart.  Switching from syslog to file didn’t stop the service, only switching back to syslog from file.  I can manually start the service and be back to normal.  Not a big deal, but if someone made the switch and didn’t think to manually start the service, it could be left without running Guardian.
>>> 
>>> 
>>> 
>>> 
>>>> On Jul 21, 2016, at 4:25 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I mentioned this earlier, but it seems that 'guardian' has some kind of
>>>> memory leak?
>>>> 
>>>> It started about two days ago with ~14 MB RAM. Then it jumped to ~34 MB,
>>>> then to ~48 MB - today it suddenly uses 71 MB.
>>>> 
>>>> And if I start it on my testmachine (offline!) it uses ~90 MB.
>>>> 
>>>> Can someone confirm?
>>>> 
>>>> Besides this, its working without seen problems.
>>>> 
>>>> Best,
>>>> Matthias
>>>> 
>>>> On 20.07.2016 15:33, Stefan Schantl wrote:
>>>>> Hello testers,
>>>>> 
>>>>> I've uploaded  a new test version (003).
>>>>> 
>>>>> Update or fresh install works like described in the announcement mail.
>>>>> 
>>>>> The Changelog can be found here:
>>>>> 
>>>>> http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
>>>>> 
>>>>> At the moment I'm missing feedback for the following functions:
>>>>> 
>>>>> * Manually blocking / unblocking addresses.
>>>>> * Dealing with the ignore list.
>>>>> * Owncloud message parser.
>>>>> * Logrotate, there should be an corresponding log entry in the guardian
>>>>> logfile after rotation of the logfiles have been done.
>>>>> * Reload of the ignore list after "Red" has been reconnected. There
>>>>> also a corresponding log entry should be logged to the logfile and the
>>>>> new "Red-address" should also be logged as part of the ignore list (If
>>>>> you own an dynamic assigned one).
>>>>> 
>>>>> As always please report your bugs or experience with the new version to
>>>>> this list.
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>>> Hello mailing list followers,
>>>>>> 
>>>>>> this is the official release announcement for the first beta release
>>>>>> of
>>>>>> the new Guardian 2.0 approach.
>>>>>> 
>>>>>> 
>>>>>> - What are the differences to the current version of guardian
>>>>>> (legacy)
>>>>>> and the first approach of guardian 2.0?
>>>>>> 
>>>>>> The most important difference is, that the new version of Guardian
>>>>>> 2.0
>>>>>> completely has been re-written from scratch and released under the
>>>>>> terms of the GPLv3. The legacy version of guardian is not maintained
>>>>>> anymore by it's developer and the software has been released without
>>>>>> any license details at all.
>>>>>> 
>>>>>> Guardian 2.0 has a very modular code base and has been designed as a
>>>>>> multi-threaded application. This allows a parallel parsing of all
>>>>>> monitored logfiles and faster actions, if one of the used modules
>>>>>> detects an attack.
>>>>>> 
>>>>>> A very important difference to the legacy version is the support of
>>>>>> configuring and managing the entire service through the IPFire
>>>>>> webinterface. The entire configuration, managing of current blocked
>>>>>> hosts, unblocking them or editing the ignored hosts list now can be
>>>>>> done in a graphical way. 
>>>>>> 
>>>>>> The legacy version of guardian only supported parsing snort alerts.
>>>>>> HTTPD and SSH support has been patched by the IPFire development team
>>>>>> some time ago. Guardian 2.0 supports all of them out of the box and
>>>>>> includes a filter to detect owncloud login brute-force attempts. As a
>>>>>> benefit of the new modular design, additional filters easily can be
>>>>>> added.
>>>>>> 
>>>>>> Guardian 2.0 is able to reload it's configuration, reloading
>>>>>> the ignore list during runtime and handle, if the logfiles will get
>>>>>> rotated by logrotate. This actions can be called by using the
>>>>>> webinterface or from the command line interface by using
>>>>>> "guardianctrl".
>>>>>> 
>>>>>> These are just a handful of the changes and benefits which comes with
>>>>>> Guardian 2.0, a complete list would be to long for this mailing list.
>>>>>> 
>>>>>> 
>>>>>> - How to join testing?
>>>>>> 
>>>>>> To get part of the testing team, simple navigate to http://people.ipf
>>>>>> ir
>>>>>> e.org/~stevee/guardian-2.0/ and download the latest tarball
>>>>>> (currently
>>>>>> 002). Please take care to download the correct one, based on your
>>>>>> used
>>>>>> architecture. The i585 packages are for 32Bit installations of
>>>>>> IPFire,
>>>>>> the x86_64 packages only can be used on 64Bit installations.
>>>>>> 
>>>>>> Put the downloaded file on your IPFire test system and extract the
>>>>>> package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>>>>>> 
>>>>>> The final installation step would be to regenerate the language cache
>>>>>> by executing "update-lang-cache" on the console.
>>>>>> 
>>>>>> From now you can find a new menu item called "Guardian" in your
>>>>>> "Service" menu after you have logged-in into your IPFire's
>>>>>> webinterface.
>>>>>> 
>>>>>> Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
>>>>>> /e
>>>>>> n/addons/guardian/start#the_guardian_20_addon
>>>>>> 
>>>>>> 
>>>>>> - Where to post bugs reports or provide feedback?
>>>>>> 
>>>>>> If you find any bugs, please report them as usual on the IPFire
>>>>>> bugtracker, which can be found at https://bugzilla.ipfire.org.
>>>>>> 
>>>>>> To provide feedback or to join a discussion, please send your mails
>>>>>> to
>>>>>> "development(a)lists.ipfire.org" (Please register first at http://lists
>>>>>> .i
>>>>>> pfire.org if not yet done).
>>>>>> 
>>>>>> The source code can be found at http://git.ipfire.org/?p=people/steve
>>>>>> e/
>>>>>> guardian.git;a=summary
>>>>>> 
>>>>>> 
>>>>>> Happy testing,
>>>>>> 
>>>>>> -Stefan
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

...for the records...:

Since I switched "Loglevel" to OFF, memory usage stays at "14333 KB" and
didn't change/rise since then.

HTH,
Matthias

On 21.07.2016 23:07, Matthias Fischer wrote:
> Hi,
> 
> Sounds interesting.
> 
> So I thought I take a little test...
> 
> Initial RAM-Usage: 14334 KB
> 
> First I just switched logging, did nothing else:
> 
> syslog => file => 22726 KB
> file => syslog => 31117 KB
> syslog => file => 39507/47898 KB (RAM suddenly altered. Why? No idea.)
> file => syslog => 56289 KB
> 
> Restarted through console:
> 
> root(a)ipfire: /var/log/guardian # guardianctrl restart
> Stopping Guardian...
> Starting Guardian...
> Unable to continue: /usr/sbin/guardian is running
>                   [ WARN ]
> 
> Hm?
> 
> Stopped through console, no output, 'guardian' not found anymore,
> neither in GUI nor through console:
> 
> root(a)ipfire: /var/log/guardian # ps ax | grep guardian
>  6962 pts/1    S+     0:00 grep guardian
> 
> Started through console and we're exactly where we started (14334 KB).
> 
> The same happens if I switch the 'Priority-level' or the 'Firewall-Action'.
> 
> Initial: 2
> 2 => 3 => 22723 KB
> 3 => 2 => 31112 KB
> 
> Firewall-Action:
> Reject => Drop => 39501 KB
> 
> Stop => Start => 14334 KB
> 
> Interestingly, during MY (log-)switching, 'guardian' never stopped.
> 
> HTH,
> Matthias
> 
> On 21.07.2016 21:52, Flying Trashcan wrote:
>> I am now noticing that when I switch from Log facility “file” to “syslog”, Guardian Daemon stops and doesn’t restart.  Switching from syslog to file didn’t stop the service, only switching back to syslog from file.  I can manually start the service and be back to normal.  Not a big deal, but if someone made the switch and didn’t think to manually start the service, it could be left without running Guardian.
>> 
>> 
>> 
>> 
>>> On Jul 21, 2016, at 4:25 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>> 
>>> Hi,
>>> 
>>> I mentioned this earlier, but it seems that 'guardian' has some kind of
>>> memory leak?
>>> 
>>> It started about two days ago with ~14 MB RAM. Then it jumped to ~34 MB,
>>> then to ~48 MB - today it suddenly uses 71 MB.
>>> 
>>> And if I start it on my testmachine (offline!) it uses ~90 MB.
>>> 
>>> Can someone confirm?
>>> 
>>> Besides this, its working without seen problems.
>>> 
>>> Best,
>>> Matthias
>>> 
>>> On 20.07.2016 15:33, Stefan Schantl wrote:
>>>> Hello testers,
>>>> 
>>>> I've uploaded  a new test version (003).
>>>> 
>>>> Update or fresh install works like described in the announcement mail.
>>>> 
>>>> The Changelog can be found here:
>>>> 
>>>> http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
>>>> 
>>>> At the moment I'm missing feedback for the following functions:
>>>> 
>>>> * Manually blocking / unblocking addresses.
>>>> * Dealing with the ignore list.
>>>> * Owncloud message parser.
>>>> * Logrotate, there should be an corresponding log entry in the guardian
>>>> logfile after rotation of the logfiles have been done.
>>>> * Reload of the ignore list after "Red" has been reconnected. There
>>>> also a corresponding log entry should be logged to the logfile and the
>>>> new "Red-address" should also be logged as part of the ignore list (If
>>>> you own an dynamic assigned one).
>>>> 
>>>> As always please report your bugs or experience with the new version to
>>>> this list.
>>>> 
>>>> Best regards,
>>>> 
>>>> -Stefan
>>>> 
>>>>> Hello mailing list followers,
>>>>> 
>>>>> this is the official release announcement for the first beta release
>>>>> of
>>>>> the new Guardian 2.0 approach.
>>>>> 
>>>>> 
>>>>> - What are the differences to the current version of guardian
>>>>> (legacy)
>>>>> and the first approach of guardian 2.0?
>>>>> 
>>>>> The most important difference is, that the new version of Guardian
>>>>> 2.0
>>>>> completely has been re-written from scratch and released under the
>>>>> terms of the GPLv3. The legacy version of guardian is not maintained
>>>>> anymore by it's developer and the software has been released without
>>>>> any license details at all.
>>>>> 
>>>>> Guardian 2.0 has a very modular code base and has been designed as a
>>>>> multi-threaded application. This allows a parallel parsing of all
>>>>> monitored logfiles and faster actions, if one of the used modules
>>>>> detects an attack.
>>>>> 
>>>>> A very important difference to the legacy version is the support of
>>>>> configuring and managing the entire service through the IPFire
>>>>> webinterface. The entire configuration, managing of current blocked
>>>>> hosts, unblocking them or editing the ignored hosts list now can be
>>>>> done in a graphical way. 
>>>>> 
>>>>> The legacy version of guardian only supported parsing snort alerts.
>>>>> HTTPD and SSH support has been patched by the IPFire development team
>>>>> some time ago. Guardian 2.0 supports all of them out of the box and
>>>>> includes a filter to detect owncloud login brute-force attempts. As a
>>>>> benefit of the new modular design, additional filters easily can be
>>>>> added.
>>>>> 
>>>>> Guardian 2.0 is able to reload it's configuration, reloading
>>>>> the ignore list during runtime and handle, if the logfiles will get
>>>>> rotated by logrotate. This actions can be called by using the
>>>>> webinterface or from the command line interface by using
>>>>> "guardianctrl".
>>>>> 
>>>>> These are just a handful of the changes and benefits which comes with
>>>>> Guardian 2.0, a complete list would be to long for this mailing list.
>>>>> 
>>>>> 
>>>>> - How to join testing?
>>>>> 
>>>>> To get part of the testing team, simple navigate to http://people.ipf
>>>>> ir
>>>>> e.org/~stevee/guardian-2.0/ and download the latest tarball
>>>>> (currently
>>>>> 002). Please take care to download the correct one, based on your
>>>>> used
>>>>> architecture. The i585 packages are for 32Bit installations of
>>>>> IPFire,
>>>>> the x86_64 packages only can be used on 64Bit installations.
>>>>> 
>>>>> Put the downloaded file on your IPFire test system and extract the
>>>>> package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>>>>> 
>>>>> The final installation step would be to regenerate the language cache
>>>>> by executing "update-lang-cache" on the console.
>>>>> 
>>>>> From now you can find a new menu item called "Guardian" in your
>>>>> "Service" menu after you have logged-in into your IPFire's
>>>>> webinterface.
>>>>> 
>>>>> Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
>>>>> /e
>>>>> n/addons/guardian/start#the_guardian_20_addon
>>>>> 
>>>>> 
>>>>> - Where to post bugs reports or provide feedback?
>>>>> 
>>>>> If you find any bugs, please report them as usual on the IPFire
>>>>> bugtracker, which can be found at https://bugzilla.ipfire.org.
>>>>> 
>>>>> To provide feedback or to join a discussion, please send your mails
>>>>> to
>>>>> "development(a)lists.ipfire.org" (Please register first at http://lists
>>>>> .i
>>>>> pfire.org if not yet done).
>>>>> 
>>>>> The source code can be found at http://git.ipfire.org/?p=people/steve
>>>>> e/
>>>>> guardian.git;a=summary
>>>>> 
>>>>> 
>>>>> Happy testing,
>>>>> 
>>>>> -Stefan
>>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

Sounds interesting.

So I thought I take a little test...

Initial RAM-Usage: 14334 KB

First I just switched logging, did nothing else:

syslog => file => 22726 KB
file => syslog => 31117 KB
syslog => file => 39507/47898 KB (RAM suddenly altered. Why? No idea.)
file => syslog => 56289 KB

Restarted through console:

root(a)ipfire: /var/log/guardian # guardianctrl restart
Stopping Guardian...
Starting Guardian...
Unable to continue: /usr/sbin/guardian is running
                  [ WARN ]

Hm?

Stopped through console, no output, 'guardian' not found anymore,
neither in GUI nor through console:

root(a)ipfire: /var/log/guardian # ps ax | grep guardian
 6962 pts/1    S+     0:00 grep guardian

Started through console and we're exactly where we started (14334 KB).

The same happens if I switch the 'Priority-level' or the 'Firewall-Action'.

Initial: 2
2 => 3 => 22723 KB
3 => 2 => 31112 KB

Firewall-Action:
Reject => Drop => 39501 KB

Stop => Start => 14334 KB

Interestingly, during MY (log-)switching, 'guardian' never stopped.

HTH,
Matthias

On 21.07.2016 21:52, Flying Trashcan wrote:
> I am now noticing that when I switch from Log facility “file” to “syslog”, Guardian Daemon stops and doesn’t restart.  Switching from syslog to file didn’t stop the service, only switching back to syslog from file.  I can manually start the service and be back to normal.  Not a big deal, but if someone made the switch and didn’t think to manually start the service, it could be left without running Guardian.
> 
> 
> 
> 
>> On Jul 21, 2016, at 4:25 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>> 
>> Hi,
>> 
>> I mentioned this earlier, but it seems that 'guardian' has some kind of
>> memory leak?
>> 
>> It started about two days ago with ~14 MB RAM. Then it jumped to ~34 MB,
>> then to ~48 MB - today it suddenly uses 71 MB.
>> 
>> And if I start it on my testmachine (offline!) it uses ~90 MB.
>> 
>> Can someone confirm?
>> 
>> Besides this, its working without seen problems.
>> 
>> Best,
>> Matthias
>> 
>> On 20.07.2016 15:33, Stefan Schantl wrote:
>>> Hello testers,
>>> 
>>> I've uploaded  a new test version (003).
>>> 
>>> Update or fresh install works like described in the announcement mail.
>>> 
>>> The Changelog can be found here:
>>> 
>>> http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
>>> 
>>> At the moment I'm missing feedback for the following functions:
>>> 
>>> * Manually blocking / unblocking addresses.
>>> * Dealing with the ignore list.
>>> * Owncloud message parser.
>>> * Logrotate, there should be an corresponding log entry in the guardian
>>> logfile after rotation of the logfiles have been done.
>>> * Reload of the ignore list after "Red" has been reconnected. There
>>> also a corresponding log entry should be logged to the logfile and the
>>> new "Red-address" should also be logged as part of the ignore list (If
>>> you own an dynamic assigned one).
>>> 
>>> As always please report your bugs or experience with the new version to
>>> this list.
>>> 
>>> Best regards,
>>> 
>>> -Stefan
>>> 
>>>> Hello mailing list followers,
>>>> 
>>>> this is the official release announcement for the first beta release
>>>> of
>>>> the new Guardian 2.0 approach.
>>>> 
>>>> 
>>>> - What are the differences to the current version of guardian
>>>> (legacy)
>>>> and the first approach of guardian 2.0?
>>>> 
>>>> The most important difference is, that the new version of Guardian
>>>> 2.0
>>>> completely has been re-written from scratch and released under the
>>>> terms of the GPLv3. The legacy version of guardian is not maintained
>>>> anymore by it's developer and the software has been released without
>>>> any license details at all.
>>>> 
>>>> Guardian 2.0 has a very modular code base and has been designed as a
>>>> multi-threaded application. This allows a parallel parsing of all
>>>> monitored logfiles and faster actions, if one of the used modules
>>>> detects an attack.
>>>> 
>>>> A very important difference to the legacy version is the support of
>>>> configuring and managing the entire service through the IPFire
>>>> webinterface. The entire configuration, managing of current blocked
>>>> hosts, unblocking them or editing the ignored hosts list now can be
>>>> done in a graphical way. 
>>>> 
>>>> The legacy version of guardian only supported parsing snort alerts.
>>>> HTTPD and SSH support has been patched by the IPFire development team
>>>> some time ago. Guardian 2.0 supports all of them out of the box and
>>>> includes a filter to detect owncloud login brute-force attempts. As a
>>>> benefit of the new modular design, additional filters easily can be
>>>> added.
>>>> 
>>>> Guardian 2.0 is able to reload it's configuration, reloading
>>>> the ignore list during runtime and handle, if the logfiles will get
>>>> rotated by logrotate. This actions can be called by using the
>>>> webinterface or from the command line interface by using
>>>> "guardianctrl".
>>>> 
>>>> These are just a handful of the changes and benefits which comes with
>>>> Guardian 2.0, a complete list would be to long for this mailing list.
>>>> 
>>>> 
>>>> - How to join testing?
>>>> 
>>>> To get part of the testing team, simple navigate to http://people.ipf
>>>> ir
>>>> e.org/~stevee/guardian-2.0/ and download the latest tarball
>>>> (currently
>>>> 002). Please take care to download the correct one, based on your
>>>> used
>>>> architecture. The i585 packages are for 32Bit installations of
>>>> IPFire,
>>>> the x86_64 packages only can be used on 64Bit installations.
>>>> 
>>>> Put the downloaded file on your IPFire test system and extract the
>>>> package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>>>> 
>>>> The final installation step would be to regenerate the language cache
>>>> by executing "update-lang-cache" on the console.
>>>> 
>>>> From now you can find a new menu item called "Guardian" in your
>>>> "Service" menu after you have logged-in into your IPFire's
>>>> webinterface.
>>>> 
>>>> Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
>>>> /e
>>>> n/addons/guardian/start#the_guardian_20_addon
>>>> 
>>>> 
>>>> - Where to post bugs reports or provide feedback?
>>>> 
>>>> If you find any bugs, please report them as usual on the IPFire
>>>> bugtracker, which can be found at https://bugzilla.ipfire.org.
>>>> 
>>>> To provide feedback or to join a discussion, please send your mails
>>>> to
>>>> "development(a)lists.ipfire.org" (Please register first at http://lists
>>>> .i
>>>> pfire.org if not yet done).
>>>> 
>>>> The source code can be found at http://git.ipfire.org/?p=people/steve
>>>> e/
>>>> guardian.git;a=summary
>>>> 
>>>> 
>>>> Happy testing,
>>>> 
>>>> -Stefan
>>>> 
>>> 
>> 
> 
> 

Re: Betatest Guardian 2.0

[Flying Trashcan]

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

I am now noticing that when I switch from Log facility “file” to “syslog”, Guardian Daemon stops and doesn’t restart.  Switching from syslog to file didn’t stop the service, only switching back to syslog from file.  I can manually start the service and be back to normal.  Not a big deal, but if someone made the switch and didn’t think to manually start the service, it could be left without running Guardian.




> On Jul 21, 2016, at 4:25 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> I mentioned this earlier, but it seems that 'guardian' has some kind of
> memory leak?
> 
> It started about two days ago with ~14 MB RAM. Then it jumped to ~34 MB,
> then to ~48 MB - today it suddenly uses 71 MB.
> 
> And if I start it on my testmachine (offline!) it uses ~90 MB.
> 
> Can someone confirm?
> 
> Besides this, its working without seen problems.
> 
> Best,
> Matthias
> 
> On 20.07.2016 15:33, Stefan Schantl wrote:
>> Hello testers,
>> 
>> I've uploaded  a new test version (003).
>> 
>> Update or fresh install works like described in the announcement mail.
>> 
>> The Changelog can be found here:
>> 
>> http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
>> 
>> At the moment I'm missing feedback for the following functions:
>> 
>> * Manually blocking / unblocking addresses.
>> * Dealing with the ignore list.
>> * Owncloud message parser.
>> * Logrotate, there should be an corresponding log entry in the guardian
>> logfile after rotation of the logfiles have been done.
>> * Reload of the ignore list after "Red" has been reconnected. There
>> also a corresponding log entry should be logged to the logfile and the
>> new "Red-address" should also be logged as part of the ignore list (If
>> you own an dynamic assigned one).
>> 
>> As always please report your bugs or experience with the new version to
>> this list.
>> 
>> Best regards,
>> 
>> -Stefan
>> 
>>> Hello mailing list followers,
>>> 
>>> this is the official release announcement for the first beta release
>>> of
>>> the new Guardian 2.0 approach.
>>> 
>>> 
>>> - What are the differences to the current version of guardian
>>> (legacy)
>>> and the first approach of guardian 2.0?
>>> 
>>> The most important difference is, that the new version of Guardian
>>> 2.0
>>> completely has been re-written from scratch and released under the
>>> terms of the GPLv3. The legacy version of guardian is not maintained
>>> anymore by it's developer and the software has been released without
>>> any license details at all.
>>> 
>>> Guardian 2.0 has a very modular code base and has been designed as a
>>> multi-threaded application. This allows a parallel parsing of all
>>> monitored logfiles and faster actions, if one of the used modules
>>> detects an attack.
>>> 
>>> A very important difference to the legacy version is the support of
>>> configuring and managing the entire service through the IPFire
>>> webinterface. The entire configuration, managing of current blocked
>>> hosts, unblocking them or editing the ignored hosts list now can be
>>> done in a graphical way. 
>>> 
>>> The legacy version of guardian only supported parsing snort alerts.
>>> HTTPD and SSH support has been patched by the IPFire development team
>>> some time ago. Guardian 2.0 supports all of them out of the box and
>>> includes a filter to detect owncloud login brute-force attempts. As a
>>> benefit of the new modular design, additional filters easily can be
>>> added.
>>> 
>>> Guardian 2.0 is able to reload it's configuration, reloading
>>> the ignore list during runtime and handle, if the logfiles will get
>>> rotated by logrotate. This actions can be called by using the
>>> webinterface or from the command line interface by using
>>> "guardianctrl".
>>> 
>>> These are just a handful of the changes and benefits which comes with
>>> Guardian 2.0, a complete list would be to long for this mailing list.
>>> 
>>> 
>>> - How to join testing?
>>> 
>>> To get part of the testing team, simple navigate to http://people.ipf
>>> ir
>>> e.org/~stevee/guardian-2.0/ and download the latest tarball
>>> (currently
>>> 002). Please take care to download the correct one, based on your
>>> used
>>> architecture. The i585 packages are for 32Bit installations of
>>> IPFire,
>>> the x86_64 packages only can be used on 64Bit installations.
>>> 
>>> Put the downloaded file on your IPFire test system and extract the
>>> package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>>> 
>>> The final installation step would be to regenerate the language cache
>>> by executing "update-lang-cache" on the console.
>>> 
>>> From now you can find a new menu item called "Guardian" in your
>>> "Service" menu after you have logged-in into your IPFire's
>>> webinterface.
>>> 
>>> Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
>>> /e
>>> n/addons/guardian/start#the_guardian_20_addon
>>> 
>>> 
>>> - Where to post bugs reports or provide feedback?
>>> 
>>> If you find any bugs, please report them as usual on the IPFire
>>> bugtracker, which can be found at https://bugzilla.ipfire.org.
>>> 
>>> To provide feedback or to join a discussion, please send your mails
>>> to
>>> "development(a)lists.ipfire.org" (Please register first at http://lists
>>> .i
>>> pfire.org if not yet done).
>>> 
>>> The source code can be found at http://git.ipfire.org/?p=people/steve
>>> e/
>>> guardian.git;a=summary
>>> 
>>> 
>>> Happy testing,
>>> 
>>> -Stefan
>>> 
>> 
> 

Re: Betatest Guardian 2.0

[Flying Trashcan]

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

My Guardian 2.0 has been running for 24hrs (since a power outage yesterday) and is only using 14434KB with the log file set to syslog and the log level set to debug.  Changing log facility to file ups the memory to 22828KB.  

I have also tested block and unblock and they work as expected.  

Joe

> On Jul 21, 2016, at 4:25 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> I mentioned this earlier, but it seems that 'guardian' has some kind of
> memory leak?
> 
> It started about two days ago with ~14 MB RAM. Then it jumped to ~34 MB,
> then to ~48 MB - today it suddenly uses 71 MB.
> 
> And if I start it on my testmachine (offline!) it uses ~90 MB.
> 
> Can someone confirm?
> 
> Besides this, its working without seen problems.
> 
> Best,
> Matthias
> 
> On 20.07.2016 15:33, Stefan Schantl wrote:
>> Hello testers,
>> 
>> I've uploaded  a new test version (003).
>> 
>> Update or fresh install works like described in the announcement mail.
>> 
>> The Changelog can be found here:
>> 
>> http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
>> 
>> At the moment I'm missing feedback for the following functions:
>> 
>> * Manually blocking / unblocking addresses.
>> * Dealing with the ignore list.
>> * Owncloud message parser.
>> * Logrotate, there should be an corresponding log entry in the guardian
>> logfile after rotation of the logfiles have been done.
>> * Reload of the ignore list after "Red" has been reconnected. There
>> also a corresponding log entry should be logged to the logfile and the
>> new "Red-address" should also be logged as part of the ignore list (If
>> you own an dynamic assigned one).
>> 
>> As always please report your bugs or experience with the new version to
>> this list.
>> 
>> Best regards,
>> 
>> -Stefan
>> 
>>> Hello mailing list followers,
>>> 
>>> this is the official release announcement for the first beta release
>>> of
>>> the new Guardian 2.0 approach.
>>> 
>>> 
>>> - What are the differences to the current version of guardian
>>> (legacy)
>>> and the first approach of guardian 2.0?
>>> 
>>> The most important difference is, that the new version of Guardian
>>> 2.0
>>> completely has been re-written from scratch and released under the
>>> terms of the GPLv3. The legacy version of guardian is not maintained
>>> anymore by it's developer and the software has been released without
>>> any license details at all.
>>> 
>>> Guardian 2.0 has a very modular code base and has been designed as a
>>> multi-threaded application. This allows a parallel parsing of all
>>> monitored logfiles and faster actions, if one of the used modules
>>> detects an attack.
>>> 
>>> A very important difference to the legacy version is the support of
>>> configuring and managing the entire service through the IPFire
>>> webinterface. The entire configuration, managing of current blocked
>>> hosts, unblocking them or editing the ignored hosts list now can be
>>> done in a graphical way. 
>>> 
>>> The legacy version of guardian only supported parsing snort alerts.
>>> HTTPD and SSH support has been patched by the IPFire development team
>>> some time ago. Guardian 2.0 supports all of them out of the box and
>>> includes a filter to detect owncloud login brute-force attempts. As a
>>> benefit of the new modular design, additional filters easily can be
>>> added.
>>> 
>>> Guardian 2.0 is able to reload it's configuration, reloading
>>> the ignore list during runtime and handle, if the logfiles will get
>>> rotated by logrotate. This actions can be called by using the
>>> webinterface or from the command line interface by using
>>> "guardianctrl".
>>> 
>>> These are just a handful of the changes and benefits which comes with
>>> Guardian 2.0, a complete list would be to long for this mailing list.
>>> 
>>> 
>>> - How to join testing?
>>> 
>>> To get part of the testing team, simple navigate to http://people.ipf
>>> ir
>>> e.org/~stevee/guardian-2.0/ and download the latest tarball
>>> (currently
>>> 002). Please take care to download the correct one, based on your
>>> used
>>> architecture. The i585 packages are for 32Bit installations of
>>> IPFire,
>>> the x86_64 packages only can be used on 64Bit installations.
>>> 
>>> Put the downloaded file on your IPFire test system and extract the
>>> package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>>> 
>>> The final installation step would be to regenerate the language cache
>>> by executing "update-lang-cache" on the console.
>>> 
>>> From now you can find a new menu item called "Guardian" in your
>>> "Service" menu after you have logged-in into your IPFire's
>>> webinterface.
>>> 
>>> Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
>>> /e
>>> n/addons/guardian/start#the_guardian_20_addon
>>> 
>>> 
>>> - Where to post bugs reports or provide feedback?
>>> 
>>> If you find any bugs, please report them as usual on the IPFire
>>> bugtracker, which can be found at https://bugzilla.ipfire.org.
>>> 
>>> To provide feedback or to join a discussion, please send your mails
>>> to
>>> "development(a)lists.ipfire.org" (Please register first at http://lists
>>> .i
>>> pfire.org if not yet done).
>>> 
>>> The source code can be found at http://git.ipfire.org/?p=people/steve
>>> e/
>>> guardian.git;a=summary
>>> 
>>> 
>>> Happy testing,
>>> 
>>> -Stefan
>>> 
>> 
> 

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

some additional information:

After running for about two days, I got four 'guardians' running in
'htop', claiming to use ~84176 KB memory. Perhaps this corresponds with
the GUI: it says 73087 KB.

'pstree' says:

root(a)ipfire: /var/log/guardian # pstree
init-+-acpid
     |-6*[agetty]
     |-clamd---{clamd}
     |-collectd---3*[{collectd}]
     |-dhcpd
     |-dnsmasq
     |-fcron
     |-freshclam
     |-guardian-+-iptables
     |          `-4*[{guardian}]
     |-httpd---10*[httpd]
     |-klogd
     |-privoxy---12*[{privoxy}]
     |-saslauthd---saslauthd
     |-snort---{snort}
     |-squid---squid-+-18*[redirect_wrappe-+-squidGuard]
     |               |                     `-squidclamav]
     |               `-16*[{squid}]
     |-sshd---bash---pstree
     |-syslogd
     `-udevd

After shutting down, 'guardian' is gone, but after restart there are
four 'guardians' again - using 14334 KB, blocking was tested and is OK -
*without* 'iptables':

root(a)ipfire: /var/log/guardian # pstree
init-+-acpid
     |-6*[agetty]
     |-clamd---{clamd}
     |-collectd---3*[{collectd}]
     |-dhcpd
     |-dnsmasq
     |-fcron
     |-freshclam
     |-guardian---4*[{guardian}]
     |-httpd---10*[httpd]
     |-klogd
     |-privoxy
     |-saslauthd---saslauthd
     |-snort---{snort}
     |-squid---squid-+-18*[redirect_wrappe-+-squidGuard]
     |               |                     `-squidclamav]
     |               `-16*[{squid}]
     |-sshd---bash---pstree
     |-syslogd
     `-udevd

Perhaps this helps somehow...

Best,
Matthias

On 21.07.2016 13:28, Michael Tremer wrote:
> On Thu, 2016-07-21 at 13:25 +0200, Matthias Fischer wrote:
>> Hi,
>> 
>> I mentioned this earlier, but it seems that 'guardian' has some kind of
>> memory leak?
> 
> Probably not a leak, but it seems that some used data is not freed. Maybe the
> log files that guardian reads?
> 
>> It started about two days ago with ~14 MB RAM. Then it jumped to ~34 MB,
>> then to ~48 MB - today it suddenly uses 71 MB.
> 
> Is this RSS or VIRT?
> 
>> And if I start it on my testmachine (offline!) it uses ~90 MB.
>> 
>> Can someone confirm?
>> 
>> Besides this, its working without seen problems.
>> 
>> Best,
>> Matthias
>> 
>> On 20.07.2016 15:33, Stefan Schantl wrote:
>> > Hello testers,
>> > 
>> > I've uploaded  a new test version (003).
>> > 
>> > Update or fresh install works like described in the announcement mail.
>> > 
>> > The Changelog can be found here:
>> > 
>> > http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
>> > 
>> > At the moment I'm missing feedback for the following functions:
>> > 
>> > * Manually blocking / unblocking addresses.
>> > * Dealing with the ignore list.
>> > * Owncloud message parser.
>> > * Logrotate, there should be an corresponding log entry in the guardian
>> > logfile after rotation of the logfiles have been done.
>> > * Reload of the ignore list after "Red" has been reconnected. There
>> > also a corresponding log entry should be logged to the logfile and the
>> > new "Red-address" should also be logged as part of the ignore list (If
>> > you own an dynamic assigned one).
>> > 
>> > As always please report your bugs or experience with the new version to
>> > this list.
>> > 
>> > Best regards,
>> > 
>> > -Stefan
>> > 
>> > > Hello mailing list followers,
>> > > 
>> > > this is the official release announcement for the first beta release
>> > > of
>> > > the new Guardian 2.0 approach.
>> > > 
>> > > 
>> > > - What are the differences to the current version of guardian
>> > > (legacy)
>> > > and the first approach of guardian 2.0?
>> > > 
>> > > The most important difference is, that the new version of Guardian
>> > > 2.0
>> > > completely has been re-written from scratch and released under the
>> > > terms of the GPLv3. The legacy version of guardian is not maintained
>> > > anymore by it's developer and the software has been released without
>> > > any license details at all.
>> > > 
>> > > Guardian 2.0 has a very modular code base and has been designed as a
>> > > multi-threaded application. This allows a parallel parsing of all
>> > > monitored logfiles and faster actions, if one of the used modules
>> > > detects an attack.
>> > > 
>> > > A very important difference to the legacy version is the support of
>> > > configuring and managing the entire service through the IPFire
>> > > webinterface. The entire configuration, managing of current blocked
>> > > hosts, unblocking them or editing the ignored hosts list now can be
>> > > done in a graphical way. 
>> > > 
>> > > The legacy version of guardian only supported parsing snort alerts.
>> > > HTTPD and SSH support has been patched by the IPFire development team
>> > > some time ago. Guardian 2.0 supports all of them out of the box and
>> > > includes a filter to detect owncloud login brute-force attempts. As a
>> > > benefit of the new modular design, additional filters easily can be
>> > > added.
>> > > 
>> > > Guardian 2.0 is able to reload it's configuration, reloading
>> > > the ignore list during runtime and handle, if the logfiles will get
>> > > rotated by logrotate. This actions can be called by using the
>> > > webinterface or from the command line interface by using
>> > > "guardianctrl".
>> > > 
>> > > These are just a handful of the changes and benefits which comes with
>> > > Guardian 2.0, a complete list would be to long for this mailing list.
>> > > 
>> > > 
>> > > - How to join testing?
>> > > 
>> > > To get part of the testing team, simple navigate to http://people.ipf
>> > > ir
>> > > e.org/~stevee/guardian-2.0/ and download the latest tarball
>> > > (currently
>> > > 002). Please take care to download the correct one, based on your
>> > > used
>> > > architecture. The i585 packages are for 32Bit installations of
>> > > IPFire,
>> > > the x86_64 packages only can be used on 64Bit installations.
>> > > 
>> > > Put the downloaded file on your IPFire test system and extract the
>> > > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>> > > 
>> > > The final installation step would be to regenerate the language cache
>> > > by executing "update-lang-cache" on the console.
>> > > 
>> > > From now you can find a new menu item called "Guardian" in your
>> > > "Service" menu after you have logged-in into your IPFire's
>> > > webinterface.
>> > > 
>> > > Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
>> > > /e
>> > > n/addons/guardian/start#the_guardian_20_addon
>> > > 
>> > > 
>> > > - Where to post bugs reports or provide feedback?
>> > > 
>> > > If you find any bugs, please report them as usual on the IPFire
>> > > bugtracker, which can be found at https://bugzilla.ipfire.org.
>> > > 
>> > > To provide feedback or to join a discussion, please send your mails
>> > > to
>> > > "development(a)lists.ipfire.org" (Please register first at http://lists
>> > > .i
>> > > pfire.org if not yet done).
>> > > 
>> > > The source code can be found at http://git.ipfire.org/?p=people/steve
>> > > e/
>> > > guardian.git;a=summary
>> > > 
>> > > 
>> > > Happy testing,
>> > > 
>> > > -Stefan
>> > > 
>> > 
>> 
> 

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

On 21.07.2016 13:28, Michael Tremer wrote:
> On Thu, 2016-07-21 at 13:25 +0200, Matthias Fischer wrote:
>> Hi,
>> 
>> I mentioned this earlier, but it seems that 'guardian' has some kind of
>> memory leak?
> 
> Probably not a leak, but it seems that some used data is not freed. Maybe the
> log files that guardian reads?

That would be a huge amount of RAM for some (tiny) log-files...

>> It started about two days ago with ~14 MB RAM. Then it jumped to ~34 MB,
>> then to ~48 MB - today it suddenly uses 71 MB.
> 
> Is this RSS or VIRT?

This is Core 103 on real hardware. ;-)
Profile:
http://fireinfo.ipfire.org/profile/63d7b5d45f8a7816ca68810ed0061d7ff95a9958

Best,
Matthias

>> And if I start it on my testmachine (offline!) it uses ~90 MB.
>> 
>> Can someone confirm?
>> 
>> Besides this, its working without seen problems.
>> 
>> Best,
>> Matthias
>> 
>> On 20.07.2016 15:33, Stefan Schantl wrote:
>> > Hello testers,
>> > 
>> > I've uploaded  a new test version (003).
>> > 
>> > Update or fresh install works like described in the announcement mail.
>> > 
>> > The Changelog can be found here:
>> > 
>> > http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
>> > 
>> > At the moment I'm missing feedback for the following functions:
>> > 
>> > * Manually blocking / unblocking addresses.
>> > * Dealing with the ignore list.
>> > * Owncloud message parser.
>> > * Logrotate, there should be an corresponding log entry in the guardian
>> > logfile after rotation of the logfiles have been done.
>> > * Reload of the ignore list after "Red" has been reconnected. There
>> > also a corresponding log entry should be logged to the logfile and the
>> > new "Red-address" should also be logged as part of the ignore list (If
>> > you own an dynamic assigned one).
>> > 
>> > As always please report your bugs or experience with the new version to
>> > this list.
>> > 
>> > Best regards,
>> > 
>> > -Stefan
>> > 
>> > > Hello mailing list followers,
>> > > 
>> > > this is the official release announcement for the first beta release
>> > > of
>> > > the new Guardian 2.0 approach.
>> > > 
>> > > 
>> > > - What are the differences to the current version of guardian
>> > > (legacy)
>> > > and the first approach of guardian 2.0?
>> > > 
>> > > The most important difference is, that the new version of Guardian
>> > > 2.0
>> > > completely has been re-written from scratch and released under the
>> > > terms of the GPLv3. The legacy version of guardian is not maintained
>> > > anymore by it's developer and the software has been released without
>> > > any license details at all.
>> > > 
>> > > Guardian 2.0 has a very modular code base and has been designed as a
>> > > multi-threaded application. This allows a parallel parsing of all
>> > > monitored logfiles and faster actions, if one of the used modules
>> > > detects an attack.
>> > > 
>> > > A very important difference to the legacy version is the support of
>> > > configuring and managing the entire service through the IPFire
>> > > webinterface. The entire configuration, managing of current blocked
>> > > hosts, unblocking them or editing the ignored hosts list now can be
>> > > done in a graphical way. 
>> > > 
>> > > The legacy version of guardian only supported parsing snort alerts.
>> > > HTTPD and SSH support has been patched by the IPFire development team
>> > > some time ago. Guardian 2.0 supports all of them out of the box and
>> > > includes a filter to detect owncloud login brute-force attempts. As a
>> > > benefit of the new modular design, additional filters easily can be
>> > > added.
>> > > 
>> > > Guardian 2.0 is able to reload it's configuration, reloading
>> > > the ignore list during runtime and handle, if the logfiles will get
>> > > rotated by logrotate. This actions can be called by using the
>> > > webinterface or from the command line interface by using
>> > > "guardianctrl".
>> > > 
>> > > These are just a handful of the changes and benefits which comes with
>> > > Guardian 2.0, a complete list would be to long for this mailing list.
>> > > 
>> > > 
>> > > - How to join testing?
>> > > 
>> > > To get part of the testing team, simple navigate to http://people.ipf
>> > > ir
>> > > e.org/~stevee/guardian-2.0/ and download the latest tarball
>> > > (currently
>> > > 002). Please take care to download the correct one, based on your
>> > > used
>> > > architecture. The i585 packages are for 32Bit installations of
>> > > IPFire,
>> > > the x86_64 packages only can be used on 64Bit installations.
>> > > 
>> > > Put the downloaded file on your IPFire test system and extract the
>> > > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>> > > 
>> > > The final installation step would be to regenerate the language cache
>> > > by executing "update-lang-cache" on the console.
>> > > 
>> > > From now you can find a new menu item called "Guardian" in your
>> > > "Service" menu after you have logged-in into your IPFire's
>> > > webinterface.
>> > > 
>> > > Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
>> > > /e
>> > > n/addons/guardian/start#the_guardian_20_addon
>> > > 
>> > > 
>> > > - Where to post bugs reports or provide feedback?
>> > > 
>> > > If you find any bugs, please report them as usual on the IPFire
>> > > bugtracker, which can be found at https://bugzilla.ipfire.org.
>> > > 
>> > > To provide feedback or to join a discussion, please send your mails
>> > > to
>> > > "development(a)lists.ipfire.org" (Please register first at http://lists
>> > > .i
>> > > pfire.org if not yet done).
>> > > 
>> > > The source code can be found at http://git.ipfire.org/?p=people/steve
>> > > e/
>> > > guardian.git;a=summary
>> > > 
>> > > 
>> > > Happy testing,
>> > > 
>> > > -Stefan
>> > > 
>> > 
>> 
> 

Re: Betatest Guardian 2.0

[Michael Tremer]

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

On Thu, 2016-07-21 at 13:25 +0200, Matthias Fischer wrote:
> Hi,
> 
> I mentioned this earlier, but it seems that 'guardian' has some kind of
> memory leak?

Probably not a leak, but it seems that some used data is not freed. Maybe the
log files that guardian reads?

> It started about two days ago with ~14 MB RAM. Then it jumped to ~34 MB,
> then to ~48 MB - today it suddenly uses 71 MB.

Is this RSS or VIRT?

> And if I start it on my testmachine (offline!) it uses ~90 MB.
> 
> Can someone confirm?
> 
> Besides this, its working without seen problems.
> 
> Best,
> Matthias
> 
> On 20.07.2016 15:33, Stefan Schantl wrote:
> > Hello testers,
> > 
> > I've uploaded  a new test version (003).
> > 
> > Update or fresh install works like described in the announcement mail.
> > 
> > The Changelog can be found here:
> > 
> > http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
> > 
> > At the moment I'm missing feedback for the following functions:
> > 
> > * Manually blocking / unblocking addresses.
> > * Dealing with the ignore list.
> > * Owncloud message parser.
> > * Logrotate, there should be an corresponding log entry in the guardian
> > logfile after rotation of the logfiles have been done.
> > * Reload of the ignore list after "Red" has been reconnected. There
> > also a corresponding log entry should be logged to the logfile and the
> > new "Red-address" should also be logged as part of the ignore list (If
> > you own an dynamic assigned one).
> > 
> > As always please report your bugs or experience with the new version to
> > this list.
> > 
> > Best regards,
> > 
> > -Stefan
> > 
> > > Hello mailing list followers,
> > > 
> > > this is the official release announcement for the first beta release
> > > of
> > > the new Guardian 2.0 approach.
> > > 
> > > 
> > > - What are the differences to the current version of guardian
> > > (legacy)
> > > and the first approach of guardian 2.0?
> > > 
> > > The most important difference is, that the new version of Guardian
> > > 2.0
> > > completely has been re-written from scratch and released under the
> > > terms of the GPLv3. The legacy version of guardian is not maintained
> > > anymore by it's developer and the software has been released without
> > > any license details at all.
> > > 
> > > Guardian 2.0 has a very modular code base and has been designed as a
> > > multi-threaded application. This allows a parallel parsing of all
> > > monitored logfiles and faster actions, if one of the used modules
> > > detects an attack.
> > > 
> > > A very important difference to the legacy version is the support of
> > > configuring and managing the entire service through the IPFire
> > > webinterface. The entire configuration, managing of current blocked
> > > hosts, unblocking them or editing the ignored hosts list now can be
> > > done in a graphical way. 
> > > 
> > > The legacy version of guardian only supported parsing snort alerts.
> > > HTTPD and SSH support has been patched by the IPFire development team
> > > some time ago. Guardian 2.0 supports all of them out of the box and
> > > includes a filter to detect owncloud login brute-force attempts. As a
> > > benefit of the new modular design, additional filters easily can be
> > > added.
> > > 
> > > Guardian 2.0 is able to reload it's configuration, reloading
> > > the ignore list during runtime and handle, if the logfiles will get
> > > rotated by logrotate. This actions can be called by using the
> > > webinterface or from the command line interface by using
> > > "guardianctrl".
> > > 
> > > These are just a handful of the changes and benefits which comes with
> > > Guardian 2.0, a complete list would be to long for this mailing list.
> > > 
> > > 
> > > - How to join testing?
> > > 
> > > To get part of the testing team, simple navigate to http://people.ipf
> > > ir
> > > e.org/~stevee/guardian-2.0/ and download the latest tarball
> > > (currently
> > > 002). Please take care to download the correct one, based on your
> > > used
> > > architecture. The i585 packages are for 32Bit installations of
> > > IPFire,
> > > the x86_64 packages only can be used on 64Bit installations.
> > > 
> > > Put the downloaded file on your IPFire test system and extract the
> > > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
> > > 
> > > The final installation step would be to regenerate the language cache
> > > by executing "update-lang-cache" on the console.
> > > 
> > > From now you can find a new menu item called "Guardian" in your
> > > "Service" menu after you have logged-in into your IPFire's
> > > webinterface.
> > > 
> > > Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
> > > /e
> > > n/addons/guardian/start#the_guardian_20_addon
> > > 
> > > 
> > > - Where to post bugs reports or provide feedback?
> > > 
> > > If you find any bugs, please report them as usual on the IPFire
> > > bugtracker, which can be found at https://bugzilla.ipfire.org.
> > > 
> > > To provide feedback or to join a discussion, please send your mails
> > > to
> > > "development(a)lists.ipfire.org" (Please register first at http://lists
> > > .i
> > > pfire.org if not yet done).
> > > 
> > > The source code can be found at http://git.ipfire.org/?p=people/steve
> > > e/
> > > guardian.git;a=summary
> > > 
> > > 
> > > Happy testing,
> > > 
> > > -Stefan
> > > 
> > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

I mentioned this earlier, but it seems that 'guardian' has some kind of
memory leak?

It started about two days ago with ~14 MB RAM. Then it jumped to ~34 MB,
then to ~48 MB - today it suddenly uses 71 MB.

And if I start it on my testmachine (offline!) it uses ~90 MB.

Can someone confirm?

Besides this, its working without seen problems.

Best,
Matthias

On 20.07.2016 15:33, Stefan Schantl wrote:
> Hello testers,
> 
> I've uploaded  a new test version (003).
> 
> Update or fresh install works like described in the announcement mail.
> 
> The Changelog can be found here:
> 
> http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
> 
> At the moment I'm missing feedback for the following functions:
> 
> * Manually blocking / unblocking addresses.
> * Dealing with the ignore list.
> * Owncloud message parser.
> * Logrotate, there should be an corresponding log entry in the guardian
> logfile after rotation of the logfiles have been done.
> * Reload of the ignore list after "Red" has been reconnected. There
> also a corresponding log entry should be logged to the logfile and the
> new "Red-address" should also be logged as part of the ignore list (If
> you own an dynamic assigned one).
> 
> As always please report your bugs or experience with the new version to
> this list.
> 
> Best regards,
> 
> -Stefan
> 
>> Hello mailing list followers,
>> 
>> this is the official release announcement for the first beta release
>> of
>> the new Guardian 2.0 approach.
>> 
>> 
>> - What are the differences to the current version of guardian
>> (legacy)
>> and the first approach of guardian 2.0?
>> 
>> The most important difference is, that the new version of Guardian
>> 2.0
>> completely has been re-written from scratch and released under the
>> terms of the GPLv3. The legacy version of guardian is not maintained
>> anymore by it's developer and the software has been released without
>> any license details at all.
>> 
>> Guardian 2.0 has a very modular code base and has been designed as a
>> multi-threaded application. This allows a parallel parsing of all
>> monitored logfiles and faster actions, if one of the used modules
>> detects an attack.
>> 
>> A very important difference to the legacy version is the support of
>> configuring and managing the entire service through the IPFire
>> webinterface. The entire configuration, managing of current blocked
>> hosts, unblocking them or editing the ignored hosts list now can be
>> done in a graphical way. 
>> 
>> The legacy version of guardian only supported parsing snort alerts.
>> HTTPD and SSH support has been patched by the IPFire development team
>> some time ago. Guardian 2.0 supports all of them out of the box and
>> includes a filter to detect owncloud login brute-force attempts. As a
>> benefit of the new modular design, additional filters easily can be
>> added.
>> 
>> Guardian 2.0 is able to reload it's configuration, reloading
>> the ignore list during runtime and handle, if the logfiles will get
>> rotated by logrotate. This actions can be called by using the
>> webinterface or from the command line interface by using
>> "guardianctrl".
>> 
>> These are just a handful of the changes and benefits which comes with
>> Guardian 2.0, a complete list would be to long for this mailing list.
>> 
>> 
>> - How to join testing?
>> 
>> To get part of the testing team, simple navigate to http://people.ipf
>> ir
>> e.org/~stevee/guardian-2.0/ and download the latest tarball
>> (currently
>> 002). Please take care to download the correct one, based on your
>> used
>> architecture. The i585 packages are for 32Bit installations of
>> IPFire,
>> the x86_64 packages only can be used on 64Bit installations.
>> 
>> Put the downloaded file on your IPFire test system and extract the
>> package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>> 
>> The final installation step would be to regenerate the language cache
>> by executing "update-lang-cache" on the console.
>> 
>> From now you can find a new menu item called "Guardian" in your
>> "Service" menu after you have logged-in into your IPFire's
>> webinterface.
>> 
>> Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
>> /e
>> n/addons/guardian/start#the_guardian_20_addon
>> 
>> 
>> - Where to post bugs reports or provide feedback?
>> 
>> If you find any bugs, please report them as usual on the IPFire
>> bugtracker, which can be found at https://bugzilla.ipfire.org.
>> 
>> To provide feedback or to join a discussion, please send your mails
>> to
>> "development(a)lists.ipfire.org" (Please register first at http://lists
>> .i
>> pfire.org if not yet done).
>> 
>> The source code can be found at http://git.ipfire.org/?p=people/steve
>> e/
>> guardian.git;a=summary
>> 
>> 
>> Happy testing,
>> 
>> -Stefan
>> 
> 

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

On 20.07.2016 15:33, Stefan Schantl wrote:
> Hello testers,

Hi Stefan,

> I've uploaded  a new test version (003).

Thanks! ;-)

> Update or fresh install works like described in the announcement mail.
> 
> The Changelog can be found here:
> 
> http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
> 
> At the moment I'm missing feedback for the following functions:
> 
> * Manually blocking / unblocking addresses.

Tested - seems to work.
Manually added to block list: "Connection timed out".
Unblocked: Runs at once.
Logs says: "<info> Socket - User-requested action."

> * Dealing with the ignore list.

Added my own IP and tried to login - with wrong password.

Log says:
"16:12:37	guardian[5773]: 	<info> Reloading ignore list...
16:12:57	guardian[5773]: 	<info> Ignoring event for 192.XXX.YYY.ZZZ,
because it is part of the ignore list.
16:13:01	guardian[5773]: 	<info> Ignoring event for 192.XXX.YYY.ZZZ,
because it is part of the ignore list.
16:13:05	guardian[5773]: 	<info> Ignoring event for 192.XXX.YYY.ZZZ,
because it is part of the ignore list. "

After deleting this entry and after the second attempt (Blockcount = 2)
the IP was blocked - tested with my daughter... <EG>

> * Owncloud message parser.

Can't test this here, sorry.

> * Logrotate, there should be an corresponding log entry in the guardian
> logfile after rotation of the logfiles have been done.

Using 'syslog' there were NO rotation entry yesterday, the log just went on.

> * Reload of the ignore list after "Red" has been reconnected. There
> also a corresponding log entry should be logged to the logfile and the
> new "Red-address" should also be logged as part of the ignore list (If
> you own an dynamic assigned one).

I'm "static", sorry. ;-)

> As always please report your bugs or experience with the new version to
> this list.

One suggestion:

The 'ids.cgi' contains the old 'snortrules'-version and an outdated
license link (patch attached).

Best,
Matthias

> Best regards,
> 
> -Stefan
> 
>> Hello mailing list followers,
>> 
>> this is the official release announcement for the first beta release
>> of
>> the new Guardian 2.0 approach.
>> 
>> 
>> - What are the differences to the current version of guardian
>> (legacy)
>> and the first approach of guardian 2.0?
>> 
>> The most important difference is, that the new version of Guardian
>> 2.0
>> completely has been re-written from scratch and released under the
>> terms of the GPLv3. The legacy version of guardian is not maintained
>> anymore by it's developer and the software has been released without
>> any license details at all.
>> 
>> Guardian 2.0 has a very modular code base and has been designed as a
>> multi-threaded application. This allows a parallel parsing of all
>> monitored logfiles and faster actions, if one of the used modules
>> detects an attack.
>> 
>> A very important difference to the legacy version is the support of
>> configuring and managing the entire service through the IPFire
>> webinterface. The entire configuration, managing of current blocked
>> hosts, unblocking them or editing the ignored hosts list now can be
>> done in a graphical way. 
>> 
>> The legacy version of guardian only supported parsing snort alerts.
>> HTTPD and SSH support has been patched by the IPFire development team
>> some time ago. Guardian 2.0 supports all of them out of the box and
>> includes a filter to detect owncloud login brute-force attempts. As a
>> benefit of the new modular design, additional filters easily can be
>> added.
>> 
>> Guardian 2.0 is able to reload it's configuration, reloading
>> the ignore list during runtime and handle, if the logfiles will get
>> rotated by logrotate. This actions can be called by using the
>> webinterface or from the command line interface by using
>> "guardianctrl".
>> 
>> These are just a handful of the changes and benefits which comes with
>> Guardian 2.0, a complete list would be to long for this mailing list.
>> 
>> 
>> - How to join testing?
>> 
>> To get part of the testing team, simple navigate to http://people.ipf
>> ir
>> e.org/~stevee/guardian-2.0/ and download the latest tarball
>> (currently
>> 002). Please take care to download the correct one, based on your
>> used
>> architecture. The i585 packages are for 32Bit installations of
>> IPFire,
>> the x86_64 packages only can be used on 64Bit installations.
>> 
>> Put the downloaded file on your IPFire test system and extract the
>> package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>> 
>> The final installation step would be to regenerate the language cache
>> by executing "update-lang-cache" on the console.
>> 
>> From now you can find a new menu item called "Guardian" in your
>> "Service" menu after you have logged-in into your IPFire's
>> webinterface.
>> 
>> Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
>> /e
>> n/addons/guardian/start#the_guardian_20_addon
>> 
>> 
>> - Where to post bugs reports or provide feedback?
>> 
>> If you find any bugs, please report them as usual on the IPFire
>> bugtracker, which can be found at https://bugzilla.ipfire.org.
>> 
>> To provide feedback or to join a discussion, please send your mails
>> to
>> "development(a)lists.ipfire.org" (Please register first at http://lists
>> .i
>> pfire.org if not yet done).
>> 
>> The source code can be found at http://git.ipfire.org/?p=people/steve
>> e/
>> guardian.git;a=summary
>> 
>> 
>> Happy testing,
>> 
>> -Stefan
>> 
> 




[-- Attachment #2: snort_ids_cgi_latest_rules_and_link.txt --]
[-- Type: text/plain, Size: 1357 bytes --]

--- old/ids.cgi	Wed Oct 22 19:27:52 2014
+++ new/ids.cgi	Tue Jul 19 04:10:39 2016
@@ -254,9 +254,9 @@
 #######################  End added for snort rules control  #################################
 
 if ($snortsettings{'RULES'} eq 'subscripted') {
-	$url=" https://www.snort.org/rules/snortrules-snapshot-2961.tar.gz?oinkcode=$snortsettings{'OINKCODE'}";
+	$url=" https://www.snort.org/rules/snortrules-snapshot-2983.tar.gz?oinkcode=$snortsettings{'OINKCODE'}";
 } elsif ($snortsettings{'RULES'} eq 'registered') {
-	$url=" https://www.snort.org/rules/snortrules-snapshot-2961.tar.gz?oinkcode=$snortsettings{'OINKCODE'}";
+	$url=" https://www.snort.org/rules/snortrules-snapshot-2983.tar.gz?oinkcode=$snortsettings{'OINKCODE'}";
 } elsif ($snortsettings{'RULES'} eq 'community') {
 	$url=" https://www.snort.org/rules/community";
 } else {
@@ -485,7 +485,7 @@
 </tr>
 <tr>
 	<td><br />
-		$Lang::tr{'ids rules license'} <a href='https://www.snort.org/signup' target='_blank'>www.snort.org</a>$Lang::tr{'ids rules license1'}<br /><br />
+		$Lang::tr{'ids rules license'} <a href='https://www.snort.org/subscribe' target='_blank'>www.snort.org</a>$Lang::tr{'ids rules license1'}<br /><br />
 		$Lang::tr{'ids rules license2'} <a href='https://www.snort.org/account/oinkcode' target='_blank'>Get an Oinkcode</a>, $Lang::tr{'ids rules license3'}
 	</td>
 </tr>

Re: Betatest Guardian 2.0

[Stefan Schantl]

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

> Hello Daniel,
> 
> thanks for testing and your feedback.
> > 
> > Hi
> > At first everything seems to wok as designed.
> > 
> > First thing I found...
> > If  I add an IP to the ignorelist it also works as designed. But if
> > I 
> > remove it the Webif didn't show it any more but the IP seems to be
> > still 
> > ignored until I restart the Guardian.
> > 
> Seems to be a bug, I'll have a look on the code.

Should be fixed in the latest version 003.
> 
> > 
> > Next thing.
> > The owncloud parser don't work. Please tell me what you need.
> Nothing at all, I will have to do a deeper look into the non working
> code. I'll post the updated parser to the mailinglist so the new one
> can be tested.
> 

Please install the latest test version 003. This release should contain
a fixed parser for owncloud. (untested because I don't use owncloud)
> > 
> > 
> > I wish me a restart button on the webif.
> Why do you think to need such a button. Guardian is designed to
> reload
> and communicate with the WUI over a Socket connection. So there
> should
> not be any need to do a restart of guardian, except an update of the
> daemon has been installed.
> > 
> > 
> > -
> > Daniel
> Best regards,
> 
> -Stefan
> > 
> > 
> > 
> > 
> > Am 18.07.2016 um 16:01 schrieb Stefan Schantl:
> > > 
> > > 
> > > Hello mailing list followers,
> > > 
> > > this is the official release announcement for the first beta
> > > release of
> > > the new Guardian 2.0 approach.
> > > 
> > > 
> > > - What are the differences to the current version of guardian
> > > (legacy)
> > > and the first approach of guardian 2.0?
> > > 
> > > The most important difference is, that the new version of
> > > Guardian
> > > 2.0
> > > completely has been re-written from scratch and released under
> > > the
> > > terms of the GPLv3. The legacy version of guardian is not
> > > maintained
> > > anymore by it's developer and the software has been released
> > > without
> > > any license details at all.
> > > 
> > > Guardian 2.0 has a very modular code base and has been designed
> > > as
> > > a
> > > multi-threaded application. This allows a parallel parsing of all
> > > monitored logfiles and faster actions, if one of the used modules
> > > detects an attack.
> > > 
> > > A very important difference to the legacy version is the support
> > > of
> > > configuring and managing the entire service through the IPFire
> > > webinterface. The entire configuration, managing of current
> > > blocked
> > > hosts, unblocking them or editing the ignored hosts list now can
> > > be
> > > done in a graphical way.
> > > 
> > > The legacy version of guardian only supported parsing snort
> > > alerts.
> > > HTTPD and SSH support has been patched by the IPFire development
> > > team
> > > some time ago. Guardian 2.0 supports all of them out of the box
> > > and
> > > includes a filter to detect owncloud login brute-force attempts.
> > > As
> > > a
> > > benefit of the new modular design, additional filters easily can
> > > be
> > > added.
> > > 
> > > Guardian 2.0 is able to reload it's configuration, reloading
> > > the ignore list during runtime and handle, if the logfiles will
> > > get
> > > rotated by logrotate. This actions can be called by using the
> > > webinterface or from the command line interface by using
> > > "guardianctrl".
> > > 
> > > These are just a handful of the changes and benefits which comes
> > > with
> > > Guardian 2.0, a complete list would be to long for this mailing
> > > list.
> > > 
> > > 
> > > - How to join testing?
> > > 
> > > To get part of the testing team, simple navigate to http://people
> > > .i
> > > pfir
> > > e.org/~stevee/guardian-2.0/ and download the latest tarball
> > > (currently
> > > 002). Please take care to download the correct one, based on your
> > > used
> > > architecture. The i585 packages are for 32Bit installations of
> > > IPFire,
> > > the x86_64 packages only can be used on 64Bit installations.
> > > 
> > > Put the downloaded file on your IPFire test system and extract
> > > the
> > > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
> > > 
> > > The final installation step would be to regenerate the language
> > > cache
> > > by executing "update-lang-cache" on the console.
> > > 
> > >  From now you can find a new menu item called "Guardian" in your
> > > "Service" menu after you have logged-in into your IPFire's
> > > webinterface.
> > > 
> > > Documentation can be found on the IPFire wiki: http://wiki.ipfire
> > > .o
> > > rg/e
> > > n/addons/guardian/start#the_guardian_20_addon
> > > 
> > > 
> > > - Where to post bugs reports or provide feedback?
> > > 
> > > If you find any bugs, please report them as usual on the IPFire
> > > bugtracker, which can be found at https://bugzilla.ipfire.org.
> > > 
> > > To provide feedback or to join a discussion, please send your
> > > mails
> > > to
> > > "development(a)lists.ipfire.org" (Please register first at http://l
> > > is
> > > ts.i
> > > pfire.org if not yet done).
> > > 
> > > The source code can be found at http://git.ipfire.org/?p=people/s
> > > te
> > > vee/
> > > guardian.git;a=summary
> > > 
> > > 
> > > Happy testing,
> > > 
> > > -Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Stefan Schantl]

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

Hello testers,

I've uploaded  a new test version (003).

Update or fresh install works like described in the announcement mail.

The Changelog can be found here:

http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt

At the moment I'm missing feedback for the following functions:

* Manually blocking / unblocking addresses.
* Dealing with the ignore list.
* Owncloud message parser.
* Logrotate, there should be an corresponding log entry in the guardian
logfile after rotation of the logfiles have been done.
* Reload of the ignore list after "Red" has been reconnected. There
also a corresponding log entry should be logged to the logfile and the
new "Red-address" should also be logged as part of the ignore list (If
you own an dynamic assigned one).

As always please report your bugs or experience with the new version to
this list.

Best regards,

-Stefan

> Hello mailing list followers,
> 
> this is the official release announcement for the first beta release
> of
> the new Guardian 2.0 approach.
> 
> 
> - What are the differences to the current version of guardian
> (legacy)
> and the first approach of guardian 2.0?
> 
> The most important difference is, that the new version of Guardian
> 2.0
> completely has been re-written from scratch and released under the
> terms of the GPLv3. The legacy version of guardian is not maintained
> anymore by it's developer and the software has been released without
> any license details at all.
> 
> Guardian 2.0 has a very modular code base and has been designed as a
> multi-threaded application. This allows a parallel parsing of all
> monitored logfiles and faster actions, if one of the used modules
> detects an attack.
> 
> A very important difference to the legacy version is the support of
> configuring and managing the entire service through the IPFire
> webinterface. The entire configuration, managing of current blocked
> hosts, unblocking them or editing the ignored hosts list now can be
> done in a graphical way. 
> 
> The legacy version of guardian only supported parsing snort alerts.
> HTTPD and SSH support has been patched by the IPFire development team
> some time ago. Guardian 2.0 supports all of them out of the box and
> includes a filter to detect owncloud login brute-force attempts. As a
> benefit of the new modular design, additional filters easily can be
> added.
> 
> Guardian 2.0 is able to reload it's configuration, reloading
> the ignore list during runtime and handle, if the logfiles will get
> rotated by logrotate. This actions can be called by using the
> webinterface or from the command line interface by using
> "guardianctrl".
> 
> These are just a handful of the changes and benefits which comes with
> Guardian 2.0, a complete list would be to long for this mailing list.
> 
> 
> - How to join testing?
> 
> To get part of the testing team, simple navigate to http://people.ipf
> ir
> e.org/~stevee/guardian-2.0/ and download the latest tarball
> (currently
> 002). Please take care to download the correct one, based on your
> used
> architecture. The i585 packages are for 32Bit installations of
> IPFire,
> the x86_64 packages only can be used on 64Bit installations.
> 
> Put the downloaded file on your IPFire test system and extract the
> package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
> 
> The final installation step would be to regenerate the language cache
> by executing "update-lang-cache" on the console.
> 
> From now you can find a new menu item called "Guardian" in your
> "Service" menu after you have logged-in into your IPFire's
> webinterface.
> 
> Documentation can be found on the IPFire wiki: http://wiki.ipfire.org
> /e
> n/addons/guardian/start#the_guardian_20_addon
> 
> 
> - Where to post bugs reports or provide feedback?
> 
> If you find any bugs, please report them as usual on the IPFire
> bugtracker, which can be found at https://bugzilla.ipfire.org.
> 
> To provide feedback or to join a discussion, please send your mails
> to
> "development(a)lists.ipfire.org" (Please register first at http://lists
> .i
> pfire.org if not yet done).
> 
> The source code can be found at http://git.ipfire.org/?p=people/steve
> e/
> guardian.git;a=summary
> 
> 
> Happy testing,
> 
> -Stefan
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

On 19.07.2016 19:26, Stefan Schantl wrote:
> Hello Matthias,
> 
> also a big thanks for joining the testing team and sharing your
> experience with us.

No problem... ;-)

>>... 
>> 1. One bug(?).
>> On the first start after installation, I got a blank screen from
>> 'guardian.cgi'.
>> ...
> I recently installed the guardian-2.0-002.x86_64 tarball on a fresh
> test installation and everything worked as expected. If you previously
> installed the broken 002 tarball, there might be some permission issues
> left - especially the "/var/ipfire/guardian/" folder requires
> nobody:nobody as ownership.

Ok, you got me. It was root:root. Don't know why. *sigh* ;-)

>> 
>> ###########################################################
>> 
>> 2. Using 'syslog' as 'Log facility' I added some lines in
>> 'srv/web/ipfire/cgi-bin/logs.cgi/log.dat' (you mentioned this
>> below!?):
>> 
>> ...
>> my %sections = (
>> ...
>>         'snort' => '(snort\[.*\]: )',
>>         'guardian' => '(guardian\[.*\]: )'
>> ...
>> my %trsections = (
>> ...
>>         'snort' => "$Lang::tr{'intrusion detection'}",
>>         'guardian' => 'Guardian'
>> ...
> 
> This would be one of my next goals, if you have already a working
> patch, please send it the usual way to this list.

Work in progress.

>> ###########################################################
>> 
>> 3. Would it be possible to extrude the guardian-lang-strings from
>> 'de.pl' and 'en.pl' and add these to
>> '/var/ipfire/addon-lang/guardian.de.pl' and 'guardian.en.pl'
>> respectively?
>> 
> 
> Do you have any special reason why this should be done?

In my opinion, its much more simple - to handle and to maintain for both
users and developers.
Once in a while it happens that various (addon-)menu-entries are
suddenly missing or can't be read anymore because specific 'de.pl' or
'en.pl' lines are missing. E.G.: Core update with changed 'de/en.pl'.
In most of the cases I found in the forum that the specific addon had to
be uninstalled and installed again, leading to new trouble because it
came with an older lang-version. And so on...
If we would use the addon-lang directory like its meant to be, then
those problems would never arise.
One just has to bundle the needed addon-lang-strings in a matching
[addon_name].[language].pl-file and put it in '/var/log/addon-lang'.
Thats all - Jm2C!

Best,
Matthias

>> If you need these, they're attached. I searched with...
>> 
>> cat guardian.cgi| grep "Lang::tr{'guardian"
>> 
>> ...and extracted all found lang-strings in two seperate lang-files
>> (de/en). I hope they're complete, testing seemed to be ok.
>> 
>> Sad to say, the translation files are rather incomplete, but thats
>> beyond my skills, sorry...
>> 
>> Best,
>> Matthias
> 
> Best regards,
> 
> -Stefan
>> 
>> On 19.07.2016 11:24, Stefan Schantl wrote:
>> > 
>> > Hello Mark,
>> > thanks for testing and your feedback.
>> > The details why a host has been blocked or the time, can be grabbed
>> > from the guardian logfile if configured or in the default settings
>> > from
>> > syslog (/var/log/messages). I'll very soon the support in the
>> > IPFire
>> > Webinterface to get the guardian related messages from the syslog
>> > on
>> > the corresponding CGI.
>> > Best regards,
>> > -Stefan
>> > > 
>> > > Everything seems to work well here Stefan. Is it possible to put
>> > > the
>> > > reason for the host being blocked in the UI. It would be very
>> > > nice to
>> > > know which ones, for instance, were custom-blocked. The snort log
>> > > would give a reason why they were flagged. It would also be nice
>> > > to
>> > > know when the block was applied.
>> > > I know you probably don't want to get the interface too crowded
>> > > but
>> > > those are just things I was thinking of.
>> > > 
>> > > Thanks for this.
>> > > 
>> > > On Mon, Jul 18, 2016 at 10:01 AM, Stefan Schantl 
>> > > re.org> wrote:
>> > > > 
>> > > > Hello mailing list followers,
>> > > > 
>> > > > this is the official release announcement for the first beta
>> > > > release of
>> > > > the new Guardian 2.0 approach.
>> > > > 
>> > > > 
>> > > > - What are the differences to the current version of guardian
>> > > > (legacy)
>> > > > and the first approach of guardian 2.0?
>> > > > 
>> > > > The most important difference is, that the new version of
>> > > > Guardian
>> > > > 2.0
>> > > > completely has been re-written from scratch and released under
>> > > > the
>> > > > terms of the GPLv3. The legacy version of guardian is not
>> > > > maintained
>> > > > anymore by it's developer and the software has been released
>> > > > without
>> > > > any license details at all.
>> > > > 
>> > > > Guardian 2.0 has a very modular code base and has been designed
>> > > > as
>> > > > a
>> > > > multi-threaded application. This allows a parallel parsing of
>> > > > all
>> > > > monitored logfiles and faster actions, if one of the used
>> > > > modules
>> > > > detects an attack.
>> > > > 
>> > > > A very important difference to the legacy version is the
>> > > > support of
>> > > > configuring and managing the entire service through the IPFire
>> > > > webinterface. The entire configuration, managing of current
>> > > > blocked
>> > > > hosts, unblocking them or editing the ignored hosts list now
>> > > > can be
>> > > > done in a graphical way. 
>> > > > 
>> > > > The legacy version of guardian only supported parsing snort
>> > > > alerts.
>> > > > HTTPD and SSH support has been patched by the IPFire
>> > > > development
>> > > > team
>> > > > some time ago. Guardian 2.0 supports all of them out of the box
>> > > > and
>> > > > includes a filter to detect owncloud login brute-force
>> > > > attempts. As
>> > > > a
>> > > > benefit of the new modular design, additional filters easily
>> > > > can be
>> > > > added.
>> > > > 
>> > > > Guardian 2.0 is able to reload it's configuration, reloading
>> > > > the ignore list during runtime and handle, if the logfiles will
>> > > > get
>> > > > rotated by logrotate. This actions can be called by using the
>> > > > webinterface or from the command line interface by using
>> > > > "guardianctrl".
>> > > > 
>> > > > These are just a handful of the changes and benefits which
>> > > > comes
>> > > > with
>> > > > Guardian 2.0, a complete list would be to long for this mailing
>> > > > list.
>> > > > 
>> > > > 
>> > > > - How to join testing?
>> > > > 
>> > > > To get part of the testing team, simple navigate to http://peop
>> > > > le.i
>> > > > pfir
>> > > > e.org/~stevee/guardian-2.0/ and download the latest tarball
>> > > > (currently
>> > > > 002). Please take care to download the correct one, based on
>> > > > your
>> > > > used
>> > > > architecture. The i585 packages are for 32Bit installations of
>> > > > IPFire,
>> > > > the x86_64 packages only can be used on 64Bit installations.
>> > > > 
>> > > > Put the downloaded file on your IPFire test system and extract
>> > > > the
>> > > > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C
>> > > > /".
>> > > > 
>> > > > The final installation step would be to regenerate the language
>> > > > cache
>> > > > by executing "update-lang-cache" on the console.
>> > > > 
>> > > > From now you can find a new menu item called "Guardian" in your
>> > > > "Service" menu after you have logged-in into your IPFire's
>> > > > webinterface.
>> > > > 
>> > > > Documentation can be found on the IPFire wiki: http://wiki.ipfi
>> > > > re.o
>> > > > rg/e
>> > > > n/addons/guardian/start#the_guardian_20_addon
>> > > > 
>> > > > 
>> > > > - Where to post bugs reports or provide feedback?
>> > > > 
>> > > > If you find any bugs, please report them as usual on the IPFire
>> > > > bugtracker, which can be found at https://bugzilla.ipfire.org.
>> > > > 
>> > > > To provide feedback or to join a discussion, please send your
>> > > > mails
>> > > > to
>> > > > "development(a)lists.ipfire.org" (Please register first at http:/
>> > > > /lis
>> > > > ts.i
>> > > > pfire.org if not yet done).
>> > > > 
>> > > > The source code can be found at http://git.ipfire.org/?p=people
>> > > > /ste
>> > > > vee/
>> > > > guardian.git;a=summary
>> > > > 
>> > > > 
>> > > > Happy testing,
>> > > > 
>> > > > -Stefan
>> > > > 
>> > > > 
>> > > 
> 

Re: Betatest Guardian 2.0

[Stefan Schantl]

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

Hello Matthias,

also a big thanks for joining the testing team and sharing your
experience with us.
> Hi,
> 
> thanks Stefan - great work, it seems to work now. I'd still have a
> few
> suggestions.
> 
> ###########################################################
> 
> 1. One bug(?).
> On the first start after installation, I got a blank screen from
> 'guardian.cgi'.
> 
> '/var/log/httpd/error_log' says:
> 
> ...
> [Tue Jul 19 03:58:31 2016] [error] [client 192.XXX.YYY.ZZZ] cannot
> touch
> '/var/ipfire/guardian/ignored': Permission denied, referer:
> https://192.168.100.254:444/cgi-bin/ids.cgi
> [Tue Jul 19 03:58:31 2016] [error] [client 192.XXX.YYY.ZZZ] Unable to
> read file /var/ipfire/guardian/ignored at
> /var/ipfire/general-functions.pl line 778., referer:
> https://192.168.100.254:444/cgi-bin/ids.cgi
> ...
> 
> After I 'touched' this file manually, and 'chown'ing the correct
> rights,
> everything went ok. But the first initialization through
> 'guardian.cgi'
> failed for some reasons:
> 
> Line 79:
> ...
> unless (-e "$ignoredfile") { system("touch $ignoredfile"); }).
> ...
I recently installed the guardian-2.0-002.x86_64 tarball on a fresh
test installation and everything worked as expected. If you previously
installed the broken 002 tarball, there might be some permission issues
left - especially the "/var/ipfire/guardian/" folder requires
nobody:nobody as ownership.
> 
> ###########################################################
> 
> 2. Using 'syslog' as 'Log facility' I added some lines in
> 'srv/web/ipfire/cgi-bin/logs.cgi/log.dat' (you mentioned this
> below!?):
> 
> ...
> my %sections = (
> ...
>         'snort' => '(snort\[.*\]: )',
>         'guardian' => '(guardian\[.*\]: )'
> ...
> my %trsections = (
> ...
>         'snort' => "$Lang::tr{'intrusion detection'}",
>         'guardian' => 'Guardian'
> ...

This would be one of my next goals, if you have already a working
patch, please send it the usual way to this list.
> 
> ###########################################################
> 
> 3. Would it be possible to extrude the guardian-lang-strings from
> 'de.pl' and 'en.pl' and add these to
> '/var/ipfire/addon-lang/guardian.de.pl' and 'guardian.en.pl'
> respectively?
> 

Do you have any special reason why this should be done?
> If you need these, they're attached. I searched with...
> 
> cat guardian.cgi| grep "Lang::tr{'guardian"
> 
> ...and extracted all found lang-strings in two seperate lang-files
> (de/en). I hope they're complete, testing seemed to be ok.
> 
> Sad to say, the translation files are rather incomplete, but thats
> beyond my skills, sorry...
> 
> Best,
> Matthias

Best regards,

-Stefan
> 
> On 19.07.2016 11:24, Stefan Schantl wrote:
> > 
> > Hello Mark,
> > thanks for testing and your feedback.
> > The details why a host has been blocked or the time, can be grabbed
> > from the guardian logfile if configured or in the default settings
> > from
> > syslog (/var/log/messages). I'll very soon the support in the
> > IPFire
> > Webinterface to get the guardian related messages from the syslog
> > on
> > the corresponding CGI.
> > Best regards,
> > -Stefan
> > > 
> > > Everything seems to work well here Stefan. Is it possible to put
> > > the
> > > reason for the host being blocked in the UI. It would be very
> > > nice to
> > > know which ones, for instance, were custom-blocked. The snort log
> > > would give a reason why they were flagged. It would also be nice
> > > to
> > > know when the block was applied.
> > > I know you probably don't want to get the interface too crowded
> > > but
> > > those are just things I was thinking of.
> > > 
> > > Thanks for this.
> > > 
> > > On Mon, Jul 18, 2016 at 10:01 AM, Stefan Schantl 
> > > re.org> wrote:
> > > > 
> > > > Hello mailing list followers,
> > > > 
> > > > this is the official release announcement for the first beta
> > > > release of
> > > > the new Guardian 2.0 approach.
> > > > 
> > > > 
> > > > - What are the differences to the current version of guardian
> > > > (legacy)
> > > > and the first approach of guardian 2.0?
> > > > 
> > > > The most important difference is, that the new version of
> > > > Guardian
> > > > 2.0
> > > > completely has been re-written from scratch and released under
> > > > the
> > > > terms of the GPLv3. The legacy version of guardian is not
> > > > maintained
> > > > anymore by it's developer and the software has been released
> > > > without
> > > > any license details at all.
> > > > 
> > > > Guardian 2.0 has a very modular code base and has been designed
> > > > as
> > > > a
> > > > multi-threaded application. This allows a parallel parsing of
> > > > all
> > > > monitored logfiles and faster actions, if one of the used
> > > > modules
> > > > detects an attack.
> > > > 
> > > > A very important difference to the legacy version is the
> > > > support of
> > > > configuring and managing the entire service through the IPFire
> > > > webinterface. The entire configuration, managing of current
> > > > blocked
> > > > hosts, unblocking them or editing the ignored hosts list now
> > > > can be
> > > > done in a graphical way. 
> > > > 
> > > > The legacy version of guardian only supported parsing snort
> > > > alerts.
> > > > HTTPD and SSH support has been patched by the IPFire
> > > > development
> > > > team
> > > > some time ago. Guardian 2.0 supports all of them out of the box
> > > > and
> > > > includes a filter to detect owncloud login brute-force
> > > > attempts. As
> > > > a
> > > > benefit of the new modular design, additional filters easily
> > > > can be
> > > > added.
> > > > 
> > > > Guardian 2.0 is able to reload it's configuration, reloading
> > > > the ignore list during runtime and handle, if the logfiles will
> > > > get
> > > > rotated by logrotate. This actions can be called by using the
> > > > webinterface or from the command line interface by using
> > > > "guardianctrl".
> > > > 
> > > > These are just a handful of the changes and benefits which
> > > > comes
> > > > with
> > > > Guardian 2.0, a complete list would be to long for this mailing
> > > > list.
> > > > 
> > > > 
> > > > - How to join testing?
> > > > 
> > > > To get part of the testing team, simple navigate to http://peop
> > > > le.i
> > > > pfir
> > > > e.org/~stevee/guardian-2.0/ and download the latest tarball
> > > > (currently
> > > > 002). Please take care to download the correct one, based on
> > > > your
> > > > used
> > > > architecture. The i585 packages are for 32Bit installations of
> > > > IPFire,
> > > > the x86_64 packages only can be used on 64Bit installations.
> > > > 
> > > > Put the downloaded file on your IPFire test system and extract
> > > > the
> > > > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C
> > > > /".
> > > > 
> > > > The final installation step would be to regenerate the language
> > > > cache
> > > > by executing "update-lang-cache" on the console.
> > > > 
> > > > From now you can find a new menu item called "Guardian" in your
> > > > "Service" menu after you have logged-in into your IPFire's
> > > > webinterface.
> > > > 
> > > > Documentation can be found on the IPFire wiki: http://wiki.ipfi
> > > > re.o
> > > > rg/e
> > > > n/addons/guardian/start#the_guardian_20_addon
> > > > 
> > > > 
> > > > - Where to post bugs reports or provide feedback?
> > > > 
> > > > If you find any bugs, please report them as usual on the IPFire
> > > > bugtracker, which can be found at https://bugzilla.ipfire.org.
> > > > 
> > > > To provide feedback or to join a discussion, please send your
> > > > mails
> > > > to
> > > > "development(a)lists.ipfire.org" (Please register first at http:/
> > > > /lis
> > > > ts.i
> > > > pfire.org if not yet done).
> > > > 
> > > > The source code can be found at http://git.ipfire.org/?p=people
> > > > /ste
> > > > vee/
> > > > guardian.git;a=summary
> > > > 
> > > > 
> > > > Happy testing,
> > > > 
> > > > -Stefan
> > > > 
> > > > 
> > > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Matthias Fischer]

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

Hi,

thanks Stefan - great work, it seems to work now. I'd still have a few
suggestions.

###########################################################

1. One bug(?).
On the first start after installation, I got a blank screen from
'guardian.cgi'.

'/var/log/httpd/error_log' says:

...
[Tue Jul 19 03:58:31 2016] [error] [client 192.XXX.YYY.ZZZ] cannot touch
'/var/ipfire/guardian/ignored': Permission denied, referer:
https://192.168.100.254:444/cgi-bin/ids.cgi
[Tue Jul 19 03:58:31 2016] [error] [client 192.XXX.YYY.ZZZ] Unable to
read file /var/ipfire/guardian/ignored at
/var/ipfire/general-functions.pl line 778., referer:
https://192.168.100.254:444/cgi-bin/ids.cgi
...

After I 'touched' this file manually, and 'chown'ing the correct rights,
everything went ok. But the first initialization through 'guardian.cgi'
failed for some reasons:

Line 79:
...
unless (-e "$ignoredfile") { system("touch $ignoredfile"); }).
...

###########################################################

2. Using 'syslog' as 'Log facility' I added some lines in
'srv/web/ipfire/cgi-bin/logs.cgi/log.dat' (you mentioned this below!?):

...
my %sections = (
...
        'snort' => '(snort\[.*\]: )',
        'guardian' => '(guardian\[.*\]: )'
...
my %trsections = (
...
        'snort' => "$Lang::tr{'intrusion detection'}",
        'guardian' => 'Guardian'
...

###########################################################

3. Would it be possible to extrude the guardian-lang-strings from
'de.pl' and 'en.pl' and add these to
'/var/ipfire/addon-lang/guardian.de.pl' and 'guardian.en.pl' respectively?

If you need these, they're attached. I searched with...

cat guardian.cgi| grep "Lang::tr{'guardian"

...and extracted all found lang-strings in two seperate lang-files
(de/en). I hope they're complete, testing seemed to be ok.

Sad to say, the translation files are rather incomplete, but thats
beyond my skills, sorry...

Best,
Matthias

On 19.07.2016 11:24, Stefan Schantl wrote:
> Hello Mark,
> thanks for testing and your feedback.
> The details why a host has been blocked or the time, can be grabbed
> from the guardian logfile if configured or in the default settings from
> syslog (/var/log/messages). I'll very soon the support in the IPFire
> Webinterface to get the guardian related messages from the syslog on
> the corresponding CGI.
> Best regards,
> -Stefan
>> Everything seems to work well here Stefan. Is it possible to put the
>> reason for the host being blocked in the UI. It would be very nice to
>> know which ones, for instance, were custom-blocked. The snort log
>> would give a reason why they were flagged. It would also be nice to
>> know when the block was applied.
>> I know you probably don't want to get the interface too crowded but
>> those are just things I was thinking of.
>> 
>> Thanks for this.
>> 
>> On Mon, Jul 18, 2016 at 10:01 AM, Stefan Schantl 
>> re.org> wrote:
>> > Hello mailing list followers,
>> > 
>> > this is the official release announcement for the first beta
>> > release of
>> > the new Guardian 2.0 approach.
>> > 
>> > 
>> > - What are the differences to the current version of guardian
>> > (legacy)
>> > and the first approach of guardian 2.0?
>> > 
>> > The most important difference is, that the new version of Guardian
>> > 2.0
>> > completely has been re-written from scratch and released under the
>> > terms of the GPLv3. The legacy version of guardian is not
>> > maintained
>> > anymore by it's developer and the software has been released
>> > without
>> > any license details at all.
>> > 
>> > Guardian 2.0 has a very modular code base and has been designed as
>> > a
>> > multi-threaded application. This allows a parallel parsing of all
>> > monitored logfiles and faster actions, if one of the used modules
>> > detects an attack.
>> > 
>> > A very important difference to the legacy version is the support of
>> > configuring and managing the entire service through the IPFire
>> > webinterface. The entire configuration, managing of current blocked
>> > hosts, unblocking them or editing the ignored hosts list now can be
>> > done in a graphical way. 
>> > 
>> > The legacy version of guardian only supported parsing snort alerts.
>> > HTTPD and SSH support has been patched by the IPFire development
>> > team
>> > some time ago. Guardian 2.0 supports all of them out of the box and
>> > includes a filter to detect owncloud login brute-force attempts. As
>> > a
>> > benefit of the new modular design, additional filters easily can be
>> > added.
>> > 
>> > Guardian 2.0 is able to reload it's configuration, reloading
>> > the ignore list during runtime and handle, if the logfiles will get
>> > rotated by logrotate. This actions can be called by using the
>> > webinterface or from the command line interface by using
>> > "guardianctrl".
>> > 
>> > These are just a handful of the changes and benefits which comes
>> > with
>> > Guardian 2.0, a complete list would be to long for this mailing
>> > list.
>> > 
>> > 
>> > - How to join testing?
>> > 
>> > To get part of the testing team, simple navigate to http://people.i
>> > pfir
>> > e.org/~stevee/guardian-2.0/ and download the latest tarball
>> > (currently
>> > 002). Please take care to download the correct one, based on your
>> > used
>> > architecture. The i585 packages are for 32Bit installations of
>> > IPFire,
>> > the x86_64 packages only can be used on 64Bit installations.
>> > 
>> > Put the downloaded file on your IPFire test system and extract the
>> > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>> > 
>> > The final installation step would be to regenerate the language
>> > cache
>> > by executing "update-lang-cache" on the console.
>> > 
>> > From now you can find a new menu item called "Guardian" in your
>> > "Service" menu after you have logged-in into your IPFire's
>> > webinterface.
>> > 
>> > Documentation can be found on the IPFire wiki: http://wiki.ipfire.o
>> > rg/e
>> > n/addons/guardian/start#the_guardian_20_addon
>> > 
>> > 
>> > - Where to post bugs reports or provide feedback?
>> > 
>> > If you find any bugs, please report them as usual on the IPFire
>> > bugtracker, which can be found at https://bugzilla.ipfire.org.
>> > 
>> > To provide feedback or to join a discussion, please send your mails
>> > to
>> > "development(a)lists.ipfire.org" (Please register first at http://lis
>> > ts.i
>> > pfire.org if not yet done).
>> > 
>> > The source code can be found at http://git.ipfire.org/?p=people/ste
>> > vee/
>> > guardian.git;a=summary
>> > 
>> > 
>> > Happy testing,
>> > 
>> > -Stefan
>> > 
>> > 
>> 
>> 
> 






[-- Attachment #2: guardian.de.pl --]
[-- Type: text/plain, Size: 1561 bytes --]

%tr = ( 
%tr,

'guardian' => 'Guardian',
'guardian block a host' => 'Host blocken',
'guardian block httpd brute-force' => 'HTTPD Brute-Force Erkennung',
'guardian block owncloud brute-force' => 'Owncloud Brute-Force Erkennung',
'guardian block ssh brute-force' => 'SSH Brute-Force Erkennung',
'guardian blocked hosts' => 'Aktuell geblockte Hosts',
'guardian blockcount' => 'Blockzähler',
'guardian blocktime' => 'Blockzeit',
'guardian common settings' => 'Allgemeine Einstellungen',
'guardian configuration' => 'Guardian Konfiguration',
'guardian daemon' => 'Daemon',
'guardian enabled' => 'Guardian aktivieren',
'guardian empty input' => 'Fehlende Eingabe: Bitte geben Sie einen gültigen Host oder ein gültiges Netzwerk an.',
'guardian firewallaction' => 'Firewall-Aktion',
'guardian invalid address or subnet' => 'Ungültige Addresse oder Netzwerk.',
'guardian invalid blockcount' => 'Ungültige Anzahl: Bitte verwenden Sie eine natürliche Zahl größer als Null.',
'guardian invalid blocktime' => 'Ungültige Blockzeit: Bitte verwenden Sie eine natürliche Zahl größer als Null.',
'guardian invalid logfile' => 'Der angegebene Pfad zum "Ignore file" ist ungültig.',
'guardian ignored hosts' => 'Ignorierte Hosts',
'guardian logfacility' => 'Logziel',
'guardian logfile' => 'Logfile',
'guardian loglevel' => 'Loglevel',
'guardian no entries' => 'Aktuell sind keine Einträge vorhanden.',
'guardian priority level' => 'Prioritätslevel',
'guardian service' => 'Guardian Service',
'guardian watch snort alertfile' => 'Monitor Snort alertfile',

);

#EOF

[-- Attachment #3: guardian.en.pl --]
[-- Type: text/plain, Size: 1468 bytes --]

%tr = ( 
%tr,

'guardian' => 'Guardian',
'guardian block a host' => 'Block Host',
'guardian block httpd brute-force' => 'HTTPD Brute-force detection',
'guardian block owncloud brute-force' => 'Owncloud Brute-force detection',
'guardian block ssh brute-force' => 'SSH Brute-force detection',
'guardian blocked hosts' => 'Currently blocked hosts',
'guardian blockcount' => 'Blockcount',
'guardian blocktime' => 'Blocktime',
'guardian common settings' => 'Common settings',
'guardian configuration' => 'Guardian Configuration',
'guardian daemon' => 'Daemon',
'guardian enabled' => 'Enable guardian',
'guardian empty input' => 'Empty input: Please enter a valid host address or subnet.',
'guardian firewallaction' => 'Firewall action',
'guardian invalid address or subnet' => 'Invalid host address or subnet.',
'guardian invalid blockcount' => 'Invalid BlockCount: Please provide a natural number higher than zero.',
'guardian invalid blocktime' => 'Invalid BlockTime: Please provide a natural number higher than zero.',
'guardian invalid logfile' => 'The provided path for the logfile is not valid.',
'guardian ignored hosts' => 'Ignored Hosts',
'guardian logfacility' => 'Log facility',
'guardian logfile' => 'Logfile',
'guardian loglevel' => 'Loglevel',
'guardian no entries' => 'No entries at the moment.',
'guardian priority level' => 'Prioritylevel',
'guardian service' => 'Guardian Service',
'guardian watch snort alertfile' => 'Monitor Snort alertfile',

);

#EOF

Re: Betatest Guardian 2.0

[Stefan Schantl]

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

Hello Daniel,

thanks for testing and your feedback.
> Hi
> At first everything seems to wok as designed.
> 
> First thing I found...
> If  I add an IP to the ignorelist it also works as designed. But if
> I 
> remove it the Webif didn't show it any more but the IP seems to be
> still 
> ignored until I restart the Guardian.
> 
Seems to be a bug, I'll have a look on the code.

> Next thing.
> The owncloud parser don't work. Please tell me what you need.
Nothing at all, I will have to do a deeper look into the non working
code. I'll post the updated parser to the mailinglist so the new one
can be tested.

> 
> I wish me a restart button on the webif.
Why do you think to need such a button. Guardian is designed to reload
and communicate with the WUI over a Socket connection. So there should
not be any need to do a restart of guardian, except an update of the
daemon has been installed.
> 
> -
> Daniel

Best regards,

-Stefan
> 
> 
> 
> Am 18.07.2016 um 16:01 schrieb Stefan Schantl:
> > 
> > Hello mailing list followers,
> > 
> > this is the official release announcement for the first beta
> > release of
> > the new Guardian 2.0 approach.
> > 
> > 
> > - What are the differences to the current version of guardian
> > (legacy)
> > and the first approach of guardian 2.0?
> > 
> > The most important difference is, that the new version of Guardian
> > 2.0
> > completely has been re-written from scratch and released under the
> > terms of the GPLv3. The legacy version of guardian is not
> > maintained
> > anymore by it's developer and the software has been released
> > without
> > any license details at all.
> > 
> > Guardian 2.0 has a very modular code base and has been designed as
> > a
> > multi-threaded application. This allows a parallel parsing of all
> > monitored logfiles and faster actions, if one of the used modules
> > detects an attack.
> > 
> > A very important difference to the legacy version is the support of
> > configuring and managing the entire service through the IPFire
> > webinterface. The entire configuration, managing of current blocked
> > hosts, unblocking them or editing the ignored hosts list now can be
> > done in a graphical way.
> > 
> > The legacy version of guardian only supported parsing snort alerts.
> > HTTPD and SSH support has been patched by the IPFire development
> > team
> > some time ago. Guardian 2.0 supports all of them out of the box and
> > includes a filter to detect owncloud login brute-force attempts. As
> > a
> > benefit of the new modular design, additional filters easily can be
> > added.
> > 
> > Guardian 2.0 is able to reload it's configuration, reloading
> > the ignore list during runtime and handle, if the logfiles will get
> > rotated by logrotate. This actions can be called by using the
> > webinterface or from the command line interface by using
> > "guardianctrl".
> > 
> > These are just a handful of the changes and benefits which comes
> > with
> > Guardian 2.0, a complete list would be to long for this mailing
> > list.
> > 
> > 
> > - How to join testing?
> > 
> > To get part of the testing team, simple navigate to http://people.i
> > pfir
> > e.org/~stevee/guardian-2.0/ and download the latest tarball
> > (currently
> > 002). Please take care to download the correct one, based on your
> > used
> > architecture. The i585 packages are for 32Bit installations of
> > IPFire,
> > the x86_64 packages only can be used on 64Bit installations.
> > 
> > Put the downloaded file on your IPFire test system and extract the
> > package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
> > 
> > The final installation step would be to regenerate the language
> > cache
> > by executing "update-lang-cache" on the console.
> > 
> >  From now you can find a new menu item called "Guardian" in your
> > "Service" menu after you have logged-in into your IPFire's
> > webinterface.
> > 
> > Documentation can be found on the IPFire wiki: http://wiki.ipfire.o
> > rg/e
> > n/addons/guardian/start#the_guardian_20_addon
> > 
> > 
> > - Where to post bugs reports or provide feedback?
> > 
> > If you find any bugs, please report them as usual on the IPFire
> > bugtracker, which can be found at https://bugzilla.ipfire.org.
> > 
> > To provide feedback or to join a discussion, please send your mails
> > to
> > "development(a)lists.ipfire.org" (Please register first at http://lis
> > ts.i
> > pfire.org if not yet done).
> > 
> > The source code can be found at http://git.ipfire.org/?p=people/ste
> > vee/
> > guardian.git;a=summary
> > 
> > 
> > Happy testing,
> > 
> > -Stefan
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Betatest Guardian 2.0

[Daniel Weismüller]

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

Hi
At first everything seems to wok as designed.

First thing I found...
If  I add an IP to the ignorelist it also works as designed. But if I 
remove it the Webif didn't show it any more but the IP seems to be still 
ignored until I restart the Guardian.

Next thing.
The owncloud parser don't work. Please tell me what you need.

I wish me a restart button on the webif.

-
Daniel



Am 18.07.2016 um 16:01 schrieb Stefan Schantl:
> Hello mailing list followers,
>
> this is the official release announcement for the first beta release of
> the new Guardian 2.0 approach.
>
>
> - What are the differences to the current version of guardian (legacy)
> and the first approach of guardian 2.0?
>
> The most important difference is, that the new version of Guardian 2.0
> completely has been re-written from scratch and released under the
> terms of the GPLv3. The legacy version of guardian is not maintained
> anymore by it's developer and the software has been released without
> any license details at all.
>
> Guardian 2.0 has a very modular code base and has been designed as a
> multi-threaded application. This allows a parallel parsing of all
> monitored logfiles and faster actions, if one of the used modules
> detects an attack.
>
> A very important difference to the legacy version is the support of
> configuring and managing the entire service through the IPFire
> webinterface. The entire configuration, managing of current blocked
> hosts, unblocking them or editing the ignored hosts list now can be
> done in a graphical way.
>
> The legacy version of guardian only supported parsing snort alerts.
> HTTPD and SSH support has been patched by the IPFire development team
> some time ago. Guardian 2.0 supports all of them out of the box and
> includes a filter to detect owncloud login brute-force attempts. As a
> benefit of the new modular design, additional filters easily can be
> added.
>
> Guardian 2.0 is able to reload it's configuration, reloading
> the ignore list during runtime and handle, if the logfiles will get
> rotated by logrotate. This actions can be called by using the
> webinterface or from the command line interface by using
> "guardianctrl".
>
> These are just a handful of the changes and benefits which comes with
> Guardian 2.0, a complete list would be to long for this mailing list.
>
>
> - How to join testing?
>
> To get part of the testing team, simple navigate to http://people.ipfir
> e.org/~stevee/guardian-2.0/ and download the latest tarball (currently
> 002). Please take care to download the correct one, based on your used
> architecture. The i585 packages are for 32Bit installations of IPFire,
> the x86_64 packages only can be used on 64Bit installations.
>
> Put the downloaded file on your IPFire test system and extract the
> package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".
>
> The final installation step would be to regenerate the language cache
> by executing "update-lang-cache" on the console.
>
>  From now you can find a new menu item called "Guardian" in your
> "Service" menu after you have logged-in into your IPFire's
> webinterface.
>
> Documentation can be found on the IPFire wiki: http://wiki.ipfire.org/e
> n/addons/guardian/start#the_guardian_20_addon
>
>
> - Where to post bugs reports or provide feedback?
>
> If you find any bugs, please report them as usual on the IPFire
> bugtracker, which can be found at https://bugzilla.ipfire.org.
>
> To provide feedback or to join a discussion, please send your mails to
> "development(a)lists.ipfire.org" (Please register first at http://lists.i
> pfire.org if not yet done).
>
> The source code can be found at http://git.ipfire.org/?p=people/stevee/
> guardian.git;a=summary
>
>
> Happy testing,
>
> -Stefan
>

Betatest Guardian 2.0

[Stefan Schantl]

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

Hello mailing list followers,

this is the official release announcement for the first beta release of
the new Guardian 2.0 approach.


- What are the differences to the current version of guardian (legacy)
and the first approach of guardian 2.0?

The most important difference is, that the new version of Guardian 2.0
completely has been re-written from scratch and released under the
terms of the GPLv3. The legacy version of guardian is not maintained
anymore by it's developer and the software has been released without
any license details at all.

Guardian 2.0 has a very modular code base and has been designed as a
multi-threaded application. This allows a parallel parsing of all
monitored logfiles and faster actions, if one of the used modules
detects an attack.

A very important difference to the legacy version is the support of
configuring and managing the entire service through the IPFire
webinterface. The entire configuration, managing of current blocked
hosts, unblocking them or editing the ignored hosts list now can be
done in a graphical way. 

The legacy version of guardian only supported parsing snort alerts.
HTTPD and SSH support has been patched by the IPFire development team
some time ago. Guardian 2.0 supports all of them out of the box and
includes a filter to detect owncloud login brute-force attempts. As a
benefit of the new modular design, additional filters easily can be
added.

Guardian 2.0 is able to reload it's configuration, reloading
the ignore list during runtime and handle, if the logfiles will get
rotated by logrotate. This actions can be called by using the
webinterface or from the command line interface by using
"guardianctrl".

These are just a handful of the changes and benefits which comes with
Guardian 2.0, a complete list would be to long for this mailing list.


- How to join testing?

To get part of the testing team, simple navigate to http://people.ipfir
e.org/~stevee/guardian-2.0/ and download the latest tarball (currently
002). Please take care to download the correct one, based on your used
architecture. The i585 packages are for 32Bit installations of IPFire,
the x86_64 packages only can be used on 64Bit installations.

Put the downloaded file on your IPFire test system and extract the
package by using "tar -xvf guardian-2.0-002.<arch>.tar.gz -C /".

The final installation step would be to regenerate the language cache
by executing "update-lang-cache" on the console.

>From now you can find a new menu item called "Guardian" in your
"Service" menu after you have logged-in into your IPFire's
webinterface.

Documentation can be found on the IPFire wiki: http://wiki.ipfire.org/e
n/addons/guardian/start#the_guardian_20_addon


- Where to post bugs reports or provide feedback?

If you find any bugs, please report them as usual on the IPFire
bugtracker, which can be found at https://bugzilla.ipfire.org.

To provide feedback or to join a discussion, please send your mails to
"development(a)lists.ipfire.org" (Please register first at http://lists.i
pfire.org if not yet done).

The source code can be found at http://git.ipfire.org/?p=people/stevee/
guardian.git;a=summary


Happy testing,

-Stefan


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]