Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
- Daniel
Hi guys,
even if you have a conversation on the phone, please try keeping us in the loop.
So the key points of what I know:
* A release is targeted for core update 104
* There are a few changes required so that re-blocking a host after it has been manually unblocked allows this host the configured number of tries again and not only one.
* Many more testers are required since feedback is really low at this point.
Did I get this right? What is the ETA for a set of patches on the mailing list?
What is the plan to engage more testers?
Best, -Michael
On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote:
Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tell me what I need to do to test Guardian. I've never installed it, but I am doing it now.
Rod
On 07/15/2016 05:00 AM, Michael Tremer wrote:
Hi guys,
even if you have a conversation on the phone, please try keeping us in the loop.
So the key points of what I know:
A release is targeted for core update 104
There are a few changes required so that re-blocking a host after
it has been manually unblocked allows this host the configured number of tries again and not only one.
- Many more testers are required since feedback is really low at
this point.
Did I get this right? What is the ETA for a set of patches on the mailing list?
What is the plan to engage more testers?
Best, -Michael
On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote:
Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
- Daniel
- -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net
I'm willing to test it as well. I take it the instructions from http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire are still good?
On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico rodo@dailydata.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tell me what I need to do to test Guardian. I've never installed it, but I am doing it now.
Rod
On 07/15/2016 05:00 AM, Michael Tremer wrote:
Hi guys,
even if you have a conversation on the phone, please try keeping us in the loop.
So the key points of what I know:
A release is targeted for core update 104
There are a few changes required so that re-blocking a host after
it has been manually unblocked allows this host the configured number of tries again and not only one.
- Many more testers are required since feedback is really low at
this point.
Did I get this right? What is the ETA for a set of patches on the mailing list?
What is the plan to engage more testers?
Best, -Michael
On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote:
Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
- Daniel
Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAleJfncACgkQuVY3UpYMlTQ1ywCfdXuAC8ByMYEOKBpkvV0R+BRm hhAAnR9juXlTjDlTiFMPbGOpDAP9LkOG =5XbU -----END PGP SIGNATURE-----
Hi,
Ok, next.
Am I right assuming that the '2.0-002'-version at http://people.ipfire.org/~stevee/guardian-2.0/ plus http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/ is the latest!?
Best, Matthias
On 16.07.2016 04:03, Mark Coolen wrote:
I'm willing to test it as well. I take it the instructions from http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire are still good?
On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico rodo@dailydata.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tell me what I need to do to test Guardian. I've never installed it, but I am doing it now.
Rod
On 07/15/2016 05:00 AM, Michael Tremer wrote:
Hi guys,
even if you have a conversation on the phone, please try keeping us in the loop.
So the key points of what I know:
A release is targeted for core update 104
There are a few changes required so that re-blocking a host after
it has been manually unblocked allows this host the configured number of tries again and not only one.
- Many more testers are required since feedback is really low at
this point.
Did I get this right? What is the ETA for a set of patches on the mailing list?
What is the plan to engage more testers?
Best, -Michael
On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote:
Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
- Daniel
Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAleJfncACgkQuVY3UpYMlTQ1ywCfdXuAC8ByMYEOKBpkvV0R+BRm hhAAnR9juXlTjDlTiFMPbGOpDAP9LkOG =5XbU -----END PGP SIGNATURE-----
I'm a bit confused about that. Why would 2.0-002 be newer than 2.0-010? There's a 2.0-012 under 'old approach' but those files have an older timestamp. The 2.0-002 is a tarball, but the 2.0-010 is an ipfire package as are the 'dependancies'. I've used Guardian 2 several times in the past by just extracting according to the instructions on stevee's ;--) page, but that doesn't seem to work with the 2.0-002 tarball. I just get a completely blank page in the GUI. How do we test?
On Sat, Jul 16, 2016 at 2:59 AM, Matthias Fischer < matthias.fischer@ipfire.org> wrote:
Hi,
Ok, next.
Am I right assuming that the '2.0-002'-version at http://people.ipfire.org/~stevee/guardian-2.0/ plus http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/ is the latest!?
Best, Matthias
On 16.07.2016 04:03, Mark Coolen wrote:
I'm willing to test it as well. I take it the instructions from http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire are
still
good?
On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico rodo@dailydata.net
wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tell me what I need to do to test Guardian. I've never installed it, but I am doing it now.
Rod
On 07/15/2016 05:00 AM, Michael Tremer wrote:
Hi guys,
even if you have a conversation on the phone, please try keeping us in the loop.
So the key points of what I know:
A release is targeted for core update 104
There are a few changes required so that re-blocking a host after
it has been manually unblocked allows this host the configured number of tries again and not only one.
- Many more testers are required since feedback is really low at
this point.
Did I get this right? What is the ETA for a set of patches on the mailing list?
What is the plan to engage more testers?
Best, -Michael
On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote:
Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
- Daniel
Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAleJfncACgkQuVY3UpYMlTQ1ywCfdXuAC8ByMYEOKBpkvV0R+BRm hhAAnR9juXlTjDlTiFMPbGOpDAP9LkOG =5XbU -----END PGP SIGNATURE-----
Hi,
you're not alone - I was a bit confused, too.
Being curious, I did the following:
Downloaded the newer tarball from here, hoping it would be the right one: http://people.ipfire.org/~stevee/guardian-2.0/guardian-2.0-002.i586.tar.gz
Downloaded the 'dependencies' from here: http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/i586/per... http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/i586/per... http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/i586/per...
Unpacked the tarball and the three pakfire-archives and got it installed on my testmachine (offline).
Hint: Take a 'close* look at the 'user:group'-rights. ;-)
I don't know how Stefan created the 'tarball', but most of the files in it had 'samba:samba' assignments, even the symlinks (for these I used 'chown -h root:root' ...).
The original archive looks like this:
... drwxr-xr-x 3 root root 4096 Jul 16 18:04 web [root@ipfiretest srv]# cd web [root@ipfiretest web]# ls -l total 4 drwxr-xr-x 3 samba samba 4096 Jul 4 11:03 ipfire [root@ipfiretest web]# cd ipfire [root@ipfiretest ipfire]# ls -l total 4 drwxr-xr-x 2 root root 4096 Jul 16 18:04 cgi-bin [root@ipfiretest ipfire]# cd cgi-bin/ [root@ipfiretest cgi-bin]# ls -l total 64 -rwxr-xr-x 1 samba samba 37174 Jul 14 14:51 guardian.cgi -rwxr-xr-x 1 samba samba 23201 Oct 22 2014 ids.cgi ...
The whole thing is still offline, GUI seems to work, I can start/stop 'guardian' and edit the 'ignore'-list. But I'd like to hear something like "That was ok, go for it...", before I put this in production. ;-)
HTH, Matthias
On 16.07.2016 16:19, Mark Coolen wrote:
I'm a bit confused about that. Why would 2.0-002 be newer than 2.0-010? There's a 2.0-012 under 'old approach' but those files have an older timestamp. The 2.0-002 is a tarball, but the 2.0-010 is an ipfire package as are the 'dependancies'. I've used Guardian 2 several times in the past by just extracting according to the instructions on stevee's ;--) page, but that doesn't seem to work with the 2.0-002 tarball. I just get a completely blank page in the GUI. How do we test?
On Sat, Jul 16, 2016 at 2:59 AM, Matthias Fischer < matthias.fischer@ipfire.org> wrote:
Hi,
Ok, next.
Am I right assuming that the '2.0-002'-version at http://people.ipfire.org/~stevee/guardian-2.0/ plus http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/ is the latest!?
Best, Matthias
On 16.07.2016 04:03, Mark Coolen wrote:
I'm willing to test it as well. I take it the instructions from http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire are
still
good?
On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico rodo@dailydata.net
wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tell me what I need to do to test Guardian. I've never installed it, but I am doing it now.
Rod
On 07/15/2016 05:00 AM, Michael Tremer wrote:
Hi guys,
even if you have a conversation on the phone, please try keeping us in the loop.
So the key points of what I know:
A release is targeted for core update 104
There are a few changes required so that re-blocking a host after
it has been manually unblocked allows this host the configured number of tries again and not only one.
- Many more testers are required since feedback is really low at
this point.
Did I get this right? What is the ETA for a set of patches on the mailing list?
What is the plan to engage more testers?
Best, -Michael
On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote:
Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
- Daniel
Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAleJfncACgkQuVY3UpYMlTQ1ywCfdXuAC8ByMYEOKBpkvV0R+BRm hhAAnR9juXlTjDlTiFMPbGOpDAP9LkOG =5XbU -----END PGP SIGNATURE-----
I saw the same issue and filed a bug report (https://bugzilla.ipfire.org/show_bug.cgi?id=11146).
When something like this pops up, I generally https://bugzilla.ipfire.org/show_bug.cgi?id=11146 immediately after the problem shows up; that usually gives some indication of the problem.
As Matthias says, it is a permissions issue on the configuration file directory. Either manually create the files (with correct ownership and permission) or change ownership/permission on the directory. Then, you have a nice, pretty GUI.
I was able to efficiently block myself from the GUI after that. Since I don't know anything about how to test Snort, I'm having problems getting it to block automatically, but that is another issue.
Rod
On 07/16/2016 09:19 AM, Mark Coolen wrote:
I'm a bit confused about that. Why would 2.0-002 be newer than 2.0-010? There's a 2.0-012 under 'old approach' but those files have an older timestamp. The 2.0-002 is a tarball, but the 2.0-010 is an ipfire package as are the 'dependancies'. I've used Guardian 2 several times in the past by just extracting according to the instructions on stevee's ;--) page, but that doesn't seem to work with the 2.0-002 tarball. I just get a completely blank page in the GUI. How do we test?
On Sat, Jul 16, 2016 at 2:59 AM, Matthias Fischer <matthias.fischer@ipfire.org mailto:matthias.fischer@ipfire.org> wrote:
Hi, Ok, next. Am I right assuming that the '2.0-002'-version at http://people.ipfire.org/~stevee/guardian-2.0/ plus http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/ is the latest!? Best, Matthias On 16.07.2016 04:03, Mark Coolen wrote: > I'm willing to test it as well. I take it the instructions from > http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire are still > good? > > On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico <rodo@dailydata.net <mailto:rodo@dailydata.net>> wrote: >Tell me what I need to do to test Guardian. I've never installed it, but I am doing it now.
Rod
On 07/15/2016 05:00 AM, Michael Tremer wrote:
Hi guys,
even if you have a conversation on the phone, please try keeping us in the loop.
So the key points of what I know:
- A release is targeted for core update 104
- There are a few changes required so that re-blocking a host after
it has been manually unblocked allows this host the configured number of tries again and not only one.
- Many more testers are required since feedback is really low at
this point.
Did I get this right? What is the ETA for a set of patches on the mailing list?
What is the plan to engage more testers?
Best, -Michael
On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote:
Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
- Daniel
>> > > >-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
Second paragraph should be
... I generally tail /var/log/httpd/error.log
On 07/16/2016 01:43 PM, R. W. Rodolico wrote:
I saw the same issue and filed a bug report (https://bugzilla.ipfire.org/show_bug.cgi?id=11146).
When something like this pops up, I generally https://bugzilla.ipfire.org/show_bug.cgi?id=11146 immediately after the problem shows up; that usually gives some indication of the problem.
As Matthias says, it is a permissions issue on the configuration file directory. Either manually create the files (with correct ownership and permission) or change ownership/permission on the directory. Then, you have a nice, pretty GUI.
I was able to efficiently block myself from the GUI after that. Since I don't know anything about how to test Snort, I'm having problems getting it to block automatically, but that is another issue.
Rod
On 07/16/2016 09:19 AM, Mark Coolen wrote:
I'm a bit confused about that. Why would 2.0-002 be newer than 2.0-010? There's a 2.0-012 under 'old approach' but those files have an older timestamp. The 2.0-002 is a tarball, but the 2.0-010 is an ipfire package as are the 'dependancies'. I've used Guardian 2 several times in the past by just extracting according to the instructions on stevee's ;--) page, but that doesn't seem to work with the 2.0-002 tarball. I just get a completely blank page in the GUI. How do we test?
On Sat, Jul 16, 2016 at 2:59 AM, Matthias Fischer <matthias.fischer@ipfire.org mailto:matthias.fischer@ipfire.org> wrote:
Hi, Ok, next. Am I right assuming that the '2.0-002'-version at http://people.ipfire.org/~stevee/guardian-2.0/ plus http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/ is the latest!? Best, Matthias On 16.07.2016 04:03, Mark Coolen wrote: > I'm willing to test it as well. I take it the instructions from > http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire are still > good? > > On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico <rodo@dailydata.net <mailto:rodo@dailydata.net>> wrote: >Tell me what I need to do to test Guardian. I've never installed it, but I am doing it now.
Rod
On 07/15/2016 05:00 AM, Michael Tremer wrote:
Hi guys,
even if you have a conversation on the phone, please try keeping us in the loop.
So the key points of what I know:
- A release is targeted for core update 104
- There are a few changes required so that re-blocking a host after
it has been manually unblocked allows this host the configured number of tries again and not only one.
- Many more testers are required since feedback is really low at
this point.
Did I get this right? What is the ETA for a set of patches on the mailing list?
What is the plan to engage more testers?
Best, -Michael
On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote:
Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
- Daniel
>> > > >-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
Hi,
On 16.07.2016 21:34, R. W. Rodolico wrote:
As Matthias says, it is a permissions issue on the configuration file directory. Either manually create the files (with correct ownership and permission) or change ownership/permission on the directory.
Actually, these directories and files are effected:
... [root@ipfiretest guardian-2.0-002_expanded]# find -user samba -group samba ./opt/pakfire/db/installed/meta-guardian ./etc/rc.d/rc6.d ./etc/rc.d/rc0.d ./etc/rc.d/init.d/networking/red.up/35-guardian ./etc/rc.d/init.d/snort ./etc/rc.d/init.d/guardian ./etc/rc.d/rc3.d ./etc/logrotate.d ./etc/logrotate.d/guardian ./var/ipfire/menu.d ./var/ipfire/menu.d/EX-guardian.menu ./var/ipfire/backup/addons/includes ./var/ipfire/backup/addons/includes/guardian ./var/ipfire/langs/en.pl ./var/ipfire/langs/de.pl ./var/ipfire/guardian ./var/log/guardian/guardian.log ./usr/sbin/guardian ./usr/lib/perl5/site_perl/5.12.3/Net/IP.pm ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto/Linux/Inotify2/Inotify2.so ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/Linux ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/Linux/Inotify2.pm ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/common ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/common/sense.pod ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/common/sense.pm ./usr/bin ./usr/bin/guardianctrl ./srv/web/ipfire ./srv/web/ipfire/cgi-bin/guardian.cgi ./srv/web/ipfire/cgi-bin/ids.cgi ...
Best, Matthias
Hmmm. give me a couple of hours and I'll make a script that should return all to original.
Rod
On 07/16/2016 03:10 PM, Matthias Fischer wrote:
Hi,
On 16.07.2016 21:34, R. W. Rodolico wrote:
As Matthias says, it is a permissions issue on the configuration file directory. Either manually create the files (with correct ownership and permission) or change ownership/permission on the directory.
Actually, these directories and files are effected:
... [root@ipfiretest guardian-2.0-002_expanded]# find -user samba -group samba ./opt/pakfire/db/installed/meta-guardian ./etc/rc.d/rc6.d ./etc/rc.d/rc0.d ./etc/rc.d/init.d/networking/red.up/35-guardian ./etc/rc.d/init.d/snort ./etc/rc.d/init.d/guardian ./etc/rc.d/rc3.d ./etc/logrotate.d ./etc/logrotate.d/guardian ./var/ipfire/menu.d ./var/ipfire/menu.d/EX-guardian.menu ./var/ipfire/backup/addons/includes ./var/ipfire/backup/addons/includes/guardian ./var/ipfire/langs/en.pl ./var/ipfire/langs/de.pl ./var/ipfire/guardian ./var/log/guardian/guardian.log ./usr/sbin/guardian ./usr/lib/perl5/site_perl/5.12.3/Net/IP.pm ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto/Linux/Inotify2/Inotify2.so ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/Linux ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/Linux/Inotify2.pm ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/common ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/common/sense.pod ./usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/common/sense.pm ./usr/bin ./usr/bin/guardianctrl ./srv/web/ipfire ./srv/web/ipfire/cgi-bin/guardian.cgi ./srv/web/ipfire/cgi-bin/ids.cgi ...
Best, Matthias
A partial fix would be to run the following bash commands. The reason I say partial is because I got the permissions from a different firewall that does not have Guardian installed on it, so it could not determine the correct permissions for any of those directories.
This was taken from the output of a perl script I threw together. It is NOT commented (sorry) but pretty straight forward. Simply gets the permissions and ownership from each directory (and parent directory) out of an array based on Matthias' research. I did NOT check to verify the permissions were not already set. The output is simply a list of commands to set permissions from one machine to the same as the permissions on another.
The originating script is temporarily stored at http://unixservertech.com/fixPermissions.pl That is a web site in progress. Feel free to download and run it on a machine that has Guardian (after looking at it and making sure I didn't do something stoopid). No guarantee it won't eat your firewall, but I ran it on a production machine, then ran the output on my test router and it appears to have worked. ====================================================== chown 0:0 /etc chmod 0755 /etc
chown 0:0 /etc/logrotate.d chmod 0755 /etc/logrotate.d
chown 0:0 /etc/rc.d chmod 0755 /etc/rc.d
chown 0:0 /etc/rc.d/init.d chmod 0755 /etc/rc.d/init.d
chown 0:0 /etc/rc.d/init.d/networking chmod 0755 /etc/rc.d/init.d/networking
chown 0:0 /etc/rc.d/init.d/networking/red.up chmod 0755 /etc/rc.d/init.d/networking/red.up
chown 0:0 /etc/rc.d/init.d/snort chmod 0754 /etc/rc.d/init.d/snort
chown 0:0 /etc/rc.d/rc0.d chmod 0755 /etc/rc.d/rc0.d
chown 0:0 /etc/rc.d/rc3.d chmod 0755 /etc/rc.d/rc3.d
chown 0:0 /etc/rc.d/rc6.d chmod 0755 /etc/rc.d/rc6.d
chown 0:0 /opt chmod 0755 /opt
chown 0:0 /opt/pakfire chmod 0755 /opt/pakfire
chown 0:0 /opt/pakfire/db chmod 0755 /opt/pakfire/db
chown 0:0 /opt/pakfire/db/installed chmod 0755 /opt/pakfire/db/installed
chown 0:0 /srv chmod 0755 /srv
chown 0:0 /srv/web chmod 0755 /srv/web
chown 0:0 /srv/web/ipfire chmod 0755 /srv/web/ipfire
chown 0:0 /srv/web/ipfire/cgi-bin chmod 0755 /srv/web/ipfire/cgi-bin
chown 0:0 /srv/web/ipfire/cgi-bin/ids.cgi chmod 0755 /srv/web/ipfire/cgi-bin/ids.cgi
chown 0:0 /usr chmod 0755 /usr
chown 0:0 /usr/bin chmod 0755 /usr/bin
chown 0:0 /usr/lib chmod 0755 /usr/lib
chown 0:0 /usr/lib/perl5 chmod 0755 /usr/lib/perl5
chown 0:0 /usr/lib/perl5/site_perl chmod 0755 /usr/lib/perl5/site_perl
chown 0:0 /usr/lib/perl5/site_perl/5.12.3 chmod 0755 /usr/lib/perl5/site_perl/5.12.3
chown 0:0 /usr/lib/perl5/site_perl/5.12.3/Net chmod 0755 /usr/lib/perl5/site_perl/5.12.3/Net
chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi
chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto
chown 0:0 /usr/sbin chmod 0755 /usr/sbin
chown 0:0 /var chmod 0755 /var
chown 0:0 /var/ipfire chmod 0755 /var/ipfire
chown 0:0 /var/ipfire/backup chmod 0755 /var/ipfire/backup
chown 0:0 /var/ipfire/backup/addons chmod 0755 /var/ipfire/backup/addons
chown 0:0 /var/ipfire/backup/addons/includes chmod 0755 /var/ipfire/backup/addons/includes
chown 0:0 /var/ipfire/langs chmod 0755 /var/ipfire/langs
chown 0:0 /var/ipfire/langs/de.pl chmod 0644 /var/ipfire/langs/de.pl
chown 0:0 /var/ipfire/langs/en.pl chmod 0644 /var/ipfire/langs/en.pl
chown 0:0 /var/ipfire/menu.d chmod 0755 /var/ipfire/menu.d
chown 0:0 /var/log chmod 0755 /var/log ======================================================
I'm still getting nothing but a blank page. Everything else seems to still be working fine, but I'm a bit afraid I'll mess something up really badly with all this playing around.
On Sat, Jul 16, 2016 at 7:19 PM, R. W. Rodolico rodo@dailydata.net wrote:
A partial fix would be to run the following bash commands. The reason I say partial is because I got the permissions from a different firewall that does not have Guardian installed on it, so it could not determine the correct permissions for any of those directories.
This was taken from the output of a perl script I threw together. It is NOT commented (sorry) but pretty straight forward. Simply gets the permissions and ownership from each directory (and parent directory) out of an array based on Matthias' research. I did NOT check to verify the permissions were not already set. The output is simply a list of commands to set permissions from one machine to the same as the permissions on another.
The originating script is temporarily stored at http://unixservertech.com/fixPermissions.pl That is a web site in progress. Feel free to download and run it on a machine that has Guardian (after looking at it and making sure I didn't do something stoopid). No guarantee it won't eat your firewall, but I ran it on a production machine, then ran the output on my test router and it appears to have worked. ====================================================== chown 0:0 /etc chmod 0755 /etc
chown 0:0 /etc/logrotate.d chmod 0755 /etc/logrotate.d
chown 0:0 /etc/rc.d chmod 0755 /etc/rc.d
chown 0:0 /etc/rc.d/init.d chmod 0755 /etc/rc.d/init.d
chown 0:0 /etc/rc.d/init.d/networking chmod 0755 /etc/rc.d/init.d/networking
chown 0:0 /etc/rc.d/init.d/networking/red.up chmod 0755 /etc/rc.d/init.d/networking/red.up
chown 0:0 /etc/rc.d/init.d/snort chmod 0754 /etc/rc.d/init.d/snort
chown 0:0 /etc/rc.d/rc0.d chmod 0755 /etc/rc.d/rc0.d
chown 0:0 /etc/rc.d/rc3.d chmod 0755 /etc/rc.d/rc3.d
chown 0:0 /etc/rc.d/rc6.d chmod 0755 /etc/rc.d/rc6.d
chown 0:0 /opt chmod 0755 /opt
chown 0:0 /opt/pakfire chmod 0755 /opt/pakfire
chown 0:0 /opt/pakfire/db chmod 0755 /opt/pakfire/db
chown 0:0 /opt/pakfire/db/installed chmod 0755 /opt/pakfire/db/installed
chown 0:0 /srv chmod 0755 /srv
chown 0:0 /srv/web chmod 0755 /srv/web
chown 0:0 /srv/web/ipfire chmod 0755 /srv/web/ipfire
chown 0:0 /srv/web/ipfire/cgi-bin chmod 0755 /srv/web/ipfire/cgi-bin
chown 0:0 /srv/web/ipfire/cgi-bin/ids.cgi chmod 0755 /srv/web/ipfire/cgi-bin/ids.cgi
chown 0:0 /usr chmod 0755 /usr
chown 0:0 /usr/bin chmod 0755 /usr/bin
chown 0:0 /usr/lib chmod 0755 /usr/lib
chown 0:0 /usr/lib/perl5 chmod 0755 /usr/lib/perl5
chown 0:0 /usr/lib/perl5/site_perl chmod 0755 /usr/lib/perl5/site_perl
chown 0:0 /usr/lib/perl5/site_perl/5.12.3 chmod 0755 /usr/lib/perl5/site_perl/5.12.3
chown 0:0 /usr/lib/perl5/site_perl/5.12.3/Net chmod 0755 /usr/lib/perl5/site_perl/5.12.3/Net
chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi
chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto
chown 0:0 /usr/sbin chmod 0755 /usr/sbin
chown 0:0 /var chmod 0755 /var
chown 0:0 /var/ipfire chmod 0755 /var/ipfire
chown 0:0 /var/ipfire/backup chmod 0755 /var/ipfire/backup
chown 0:0 /var/ipfire/backup/addons chmod 0755 /var/ipfire/backup/addons
chown 0:0 /var/ipfire/backup/addons/includes chmod 0755 /var/ipfire/backup/addons/includes
chown 0:0 /var/ipfire/langs chmod 0755 /var/ipfire/langs
chown 0:0 /var/ipfire/langs/de.pl chmod 0644 /var/ipfire/langs/de.pl
chown 0:0 /var/ipfire/langs/en.pl chmod 0644 /var/ipfire/langs/en.pl
chown 0:0 /var/ipfire/menu.d chmod 0755 /var/ipfire/menu.d
chown 0:0 /var/log chmod 0755 /var/log ======================================================
-- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net
Do the following:
Open a command prompt on the router, via whatever means you have, and issue the command:
tail -f /var/log/httpd/error_log
Note the latest timestamp of the entry
Now, open a web browser and browse to the Guardian page, but nothing else.
Copy the text from the command prompt after the timestamp you noted above. You can send that directly to me if you like, or reply here.
If I can not suggest a fix, I'll be happy to work with you via messaging, email, or if you're in the US, phone.
Rod
On 07/16/2016 07:42 PM, Mark Coolen wrote:
I'm still getting nothing but a blank page. Everything else seems to still be working fine, but I'm a bit afraid I'll mess something up really badly with all this playing around.
On Sat, Jul 16, 2016 at 7:19 PM, R. W. Rodolico <rodo@dailydata.net mailto:rodo@dailydata.net> wrote:
A partial fix would be to run the following bash commands. The reason I say partial is because I got the permissions from a different firewall that does not have Guardian installed on it, so it could not determine the correct permissions for any of those directories. This was taken from the output of a perl script I threw together. It is NOT commented (sorry) but pretty straight forward. Simply gets the permissions and ownership from each directory (and parent directory) out of an array based on Matthias' research. I did NOT check to verify the permissions were not already set. The output is simply a list of commands to set permissions from one machine to the same as the permissions on another. The originating script is temporarily stored at http://unixservertech.com/fixPermissions.pl That is a web site in progress. Feel free to download and run it on a machine that has Guardian (after looking at it and making sure I didn't do something stoopid). No guarantee it won't eat your firewall, but I ran it on a production machine, then ran the output on my test router and it appears to have worked. ====================================================== chown 0:0 /etc chmod 0755 /etc chown 0:0 /etc/logrotate.d chmod 0755 /etc/logrotate.d chown 0:0 /etc/rc.d chmod 0755 /etc/rc.d chown 0:0 /etc/rc.d/init.d chmod 0755 /etc/rc.d/init.d chown 0:0 /etc/rc.d/init.d/networking chmod 0755 /etc/rc.d/init.d/networking chown 0:0 /etc/rc.d/init.d/networking/red.up chmod 0755 /etc/rc.d/init.d/networking/red.up chown 0:0 /etc/rc.d/init.d/snort chmod 0754 /etc/rc.d/init.d/snort chown 0:0 /etc/rc.d/rc0.d chmod 0755 /etc/rc.d/rc0.d chown 0:0 /etc/rc.d/rc3.d chmod 0755 /etc/rc.d/rc3.d chown 0:0 /etc/rc.d/rc6.d chmod 0755 /etc/rc.d/rc6.d chown 0:0 /opt chmod 0755 /opt chown 0:0 /opt/pakfire chmod 0755 /opt/pakfire chown 0:0 /opt/pakfire/db chmod 0755 /opt/pakfire/db chown 0:0 /opt/pakfire/db/installed chmod 0755 /opt/pakfire/db/installed chown 0:0 /srv chmod 0755 /srv chown 0:0 /srv/web chmod 0755 /srv/web chown 0:0 /srv/web/ipfire chmod 0755 /srv/web/ipfire chown 0:0 /srv/web/ipfire/cgi-bin chmod 0755 /srv/web/ipfire/cgi-bin chown 0:0 /srv/web/ipfire/cgi-bin/ids.cgi chmod 0755 /srv/web/ipfire/cgi-bin/ids.cgi chown 0:0 /usr chmod 0755 /usr chown 0:0 /usr/bin chmod 0755 /usr/bin chown 0:0 /usr/lib chmod 0755 /usr/lib chown 0:0 /usr/lib/perl5 chmod 0755 /usr/lib/perl5 chown 0:0 /usr/lib/perl5/site_perl chmod 0755 /usr/lib/perl5/site_perl chown 0:0 /usr/lib/perl5/site_perl/5.12.3 chmod 0755 /usr/lib/perl5/site_perl/5.12.3 chown 0:0 /usr/lib/perl5/site_perl/5.12.3/Net chmod 0755 /usr/lib/perl5/site_perl/5.12.3/Net chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto chown 0:0 /usr/sbin chmod 0755 /usr/sbin chown 0:0 /var chmod 0755 /var chown 0:0 /var/ipfire chmod 0755 /var/ipfire chown 0:0 /var/ipfire/backup chmod 0755 /var/ipfire/backup chown 0:0 /var/ipfire/backup/addons chmod 0755 /var/ipfire/backup/addons chown 0:0 /var/ipfire/backup/addons/includes chmod 0755 /var/ipfire/backup/addons/includes chown 0:0 /var/ipfire/langs chmod 0755 /var/ipfire/langs chown 0:0 /var/ipfire/langs/de.pl <http://de.pl> chmod 0644 /var/ipfire/langs/de.pl <http://de.pl> chown 0:0 /var/ipfire/langs/en.pl <http://en.pl> chmod 0644 /var/ipfire/langs/en.pl <http://en.pl> chown 0:0 /var/ipfire/menu.d chmod 0755 /var/ipfire/menu.d chown 0:0 /var/log chmod 0755 /var/log ====================================================== -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 <tel:214.827.2170> http://www.dailydata.net-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
Hi,
another suggestion:
Delete ALL files in '/var/ipfire/guardian' and reload '/srv/web/ipfire/cgi-bin/guardian.cgi'. If these files don't exist, they will be created with standard settings.
Perhaps GUI can't load because of already wrong file permissions...
HTH, Matthias
On 17.07.2016 02:56, R. W. Rodolico wrote:
Do the following:
Open a command prompt on the router, via whatever means you have, and issue the command:
tail -f /var/log/httpd/error_log
Note the latest timestamp of the entry
Now, open a web browser and browse to the Guardian page, but nothing else.
Copy the text from the command prompt after the timestamp you noted above. You can send that directly to me if you like, or reply here.
If I can not suggest a fix, I'll be happy to work with you via messaging, email, or if you're in the US, phone.
Rod
On 07/16/2016 07:42 PM, Mark Coolen wrote:
I'm still getting nothing but a blank page. Everything else seems to still be working fine, but I'm a bit afraid I'll mess something up really badly with all this playing around.
On Sat, Jul 16, 2016 at 7:19 PM, R. W. Rodolico <rodo@dailydata.net mailto:rodo@dailydata.net> wrote:
A partial fix would be to run the following bash commands. The reason I say partial is because I got the permissions from a different firewall that does not have Guardian installed on it, so it could not determine the correct permissions for any of those directories. This was taken from the output of a perl script I threw together. It is NOT commented (sorry) but pretty straight forward. Simply gets the permissions and ownership from each directory (and parent directory) out of an array based on Matthias' research. I did NOT check to verify the permissions were not already set. The output is simply a list of commands to set permissions from one machine to the same as the permissions on another. The originating script is temporarily stored at http://unixservertech.com/fixPermissions.pl That is a web site in progress. Feel free to download and run it on a machine that has Guardian (after looking at it and making sure I didn't do something stoopid). No guarantee it won't eat your firewall, but I ran it on a production machine, then ran the output on my test router and it appears to have worked. ====================================================== chown 0:0 /etc chmod 0755 /etc chown 0:0 /etc/logrotate.d chmod 0755 /etc/logrotate.d chown 0:0 /etc/rc.d chmod 0755 /etc/rc.d chown 0:0 /etc/rc.d/init.d chmod 0755 /etc/rc.d/init.d chown 0:0 /etc/rc.d/init.d/networking chmod 0755 /etc/rc.d/init.d/networking chown 0:0 /etc/rc.d/init.d/networking/red.up chmod 0755 /etc/rc.d/init.d/networking/red.up chown 0:0 /etc/rc.d/init.d/snort chmod 0754 /etc/rc.d/init.d/snort chown 0:0 /etc/rc.d/rc0.d chmod 0755 /etc/rc.d/rc0.d chown 0:0 /etc/rc.d/rc3.d chmod 0755 /etc/rc.d/rc3.d chown 0:0 /etc/rc.d/rc6.d chmod 0755 /etc/rc.d/rc6.d chown 0:0 /opt chmod 0755 /opt chown 0:0 /opt/pakfire chmod 0755 /opt/pakfire chown 0:0 /opt/pakfire/db chmod 0755 /opt/pakfire/db chown 0:0 /opt/pakfire/db/installed chmod 0755 /opt/pakfire/db/installed chown 0:0 /srv chmod 0755 /srv chown 0:0 /srv/web chmod 0755 /srv/web chown 0:0 /srv/web/ipfire chmod 0755 /srv/web/ipfire chown 0:0 /srv/web/ipfire/cgi-bin chmod 0755 /srv/web/ipfire/cgi-bin chown 0:0 /srv/web/ipfire/cgi-bin/ids.cgi chmod 0755 /srv/web/ipfire/cgi-bin/ids.cgi chown 0:0 /usr chmod 0755 /usr chown 0:0 /usr/bin chmod 0755 /usr/bin chown 0:0 /usr/lib chmod 0755 /usr/lib chown 0:0 /usr/lib/perl5 chmod 0755 /usr/lib/perl5 chown 0:0 /usr/lib/perl5/site_perl chmod 0755 /usr/lib/perl5/site_perl chown 0:0 /usr/lib/perl5/site_perl/5.12.3 chmod 0755 /usr/lib/perl5/site_perl/5.12.3 chown 0:0 /usr/lib/perl5/site_perl/5.12.3/Net chmod 0755 /usr/lib/perl5/site_perl/5.12.3/Net chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto chown 0:0 /usr/sbin chmod 0755 /usr/sbin chown 0:0 /var chmod 0755 /var chown 0:0 /var/ipfire chmod 0755 /var/ipfire chown 0:0 /var/ipfire/backup chmod 0755 /var/ipfire/backup chown 0:0 /var/ipfire/backup/addons chmod 0755 /var/ipfire/backup/addons chown 0:0 /var/ipfire/backup/addons/includes chmod 0755 /var/ipfire/backup/addons/includes chown 0:0 /var/ipfire/langs chmod 0755 /var/ipfire/langs chown 0:0 /var/ipfire/langs/de.pl <http://de.pl> chmod 0644 /var/ipfire/langs/de.pl <http://de.pl> chown 0:0 /var/ipfire/langs/en.pl <http://en.pl> chmod 0644 /var/ipfire/langs/en.pl <http://en.pl> chown 0:0 /var/ipfire/menu.d chmod 0755 /var/ipfire/menu.d chown 0:0 /var/log chmod 0755 /var/log ====================================================== -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 <tel:214.827.2170> http://www.dailydata.net-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
I set the /var/ipfire/guardian permissions to nobody:nobody and everything started to work.
Now I have other problems ;-)
I tried 'Unblock all' and got:
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?, referer: https://10.46.235.1:444/cgi-bin/guardian.cgi
On Sun, Jul 17, 2016 at 1:43 AM, Matthias Fischer < matthias.fischer@ipfire.org> wrote:
Hi,
another suggestion:
Delete ALL files in '/var/ipfire/guardian' and reload '/srv/web/ipfire/cgi-bin/guardian.cgi'. If these files don't exist, they will be created with standard settings.
Perhaps GUI can't load because of already wrong file permissions...
HTH, Matthias
On 17.07.2016 02:56, R. W. Rodolico wrote:
Do the following:
Open a command prompt on the router, via whatever means you have, and issue the command:
tail -f /var/log/httpd/error_log
Note the latest timestamp of the entry
Now, open a web browser and browse to the Guardian page, but nothing
else.
Copy the text from the command prompt after the timestamp you noted above. You can send that directly to me if you like, or reply here.
If I can not suggest a fix, I'll be happy to work with you via messaging, email, or if you're in the US, phone.
Rod
On 07/16/2016 07:42 PM, Mark Coolen wrote:
I'm still getting nothing but a blank page. Everything else seems to still be working fine, but I'm a bit afraid I'll mess something up really badly with all this playing around.
On Sat, Jul 16, 2016 at 7:19 PM, R. W. Rodolico <rodo@dailydata.net mailto:rodo@dailydata.net> wrote:
A partial fix would be to run the following bash commands. Thereason I
say partial is because I got the permissions from a differentfirewall
that does not have Guardian installed on it, so it could notdetermine
the correct permissions for any of those directories. This was taken from the output of a perl script I threw together.It is
NOT commented (sorry) but pretty straight forward. Simply gets the permissions and ownership from each directory (and parentdirectory) out
of an array based on Matthias' research. I did NOT check to verifythe
permissions were not already set. The output is simply a list of commands to set permissions from one machine to the same as the permissions on another. The originating script is temporarily stored at http://unixservertech.com/fixPermissions.pl That is a web site in progress. Feel free to download and run it ona
machine that has Guardian (after looking at it and making sure Ididn't
do something stoopid). No guarantee it won't eat your firewall, butI
ran it on a production machine, then ran the output on my testrouter
and it appears to have worked. ====================================================== chown 0:0 /etc chmod 0755 /etc chown 0:0 /etc/logrotate.d chmod 0755 /etc/logrotate.d chown 0:0 /etc/rc.d chmod 0755 /etc/rc.d chown 0:0 /etc/rc.d/init.d chmod 0755 /etc/rc.d/init.d chown 0:0 /etc/rc.d/init.d/networking chmod 0755 /etc/rc.d/init.d/networking chown 0:0 /etc/rc.d/init.d/networking/red.up chmod 0755 /etc/rc.d/init.d/networking/red.up chown 0:0 /etc/rc.d/init.d/snort chmod 0754 /etc/rc.d/init.d/snort chown 0:0 /etc/rc.d/rc0.d chmod 0755 /etc/rc.d/rc0.d chown 0:0 /etc/rc.d/rc3.d chmod 0755 /etc/rc.d/rc3.d chown 0:0 /etc/rc.d/rc6.d chmod 0755 /etc/rc.d/rc6.d chown 0:0 /opt chmod 0755 /opt chown 0:0 /opt/pakfire chmod 0755 /opt/pakfire chown 0:0 /opt/pakfire/db chmod 0755 /opt/pakfire/db chown 0:0 /opt/pakfire/db/installed chmod 0755 /opt/pakfire/db/installed chown 0:0 /srv chmod 0755 /srv chown 0:0 /srv/web chmod 0755 /srv/web chown 0:0 /srv/web/ipfire chmod 0755 /srv/web/ipfire chown 0:0 /srv/web/ipfire/cgi-bin chmod 0755 /srv/web/ipfire/cgi-bin chown 0:0 /srv/web/ipfire/cgi-bin/ids.cgi chmod 0755 /srv/web/ipfire/cgi-bin/ids.cgi chown 0:0 /usr chmod 0755 /usr chown 0:0 /usr/bin chmod 0755 /usr/bin chown 0:0 /usr/lib chmod 0755 /usr/lib chown 0:0 /usr/lib/perl5 chmod 0755 /usr/lib/perl5 chown 0:0 /usr/lib/perl5/site_perl chmod 0755 /usr/lib/perl5/site_perl chown 0:0 /usr/lib/perl5/site_perl/5.12.3 chmod 0755 /usr/lib/perl5/site_perl/5.12.3 chown 0:0 /usr/lib/perl5/site_perl/5.12.3/Net chmod 0755 /usr/lib/perl5/site_perl/5.12.3/Net chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chown 0:0/usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto
chmod 0755/usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto
chown 0:0 /usr/sbin chmod 0755 /usr/sbin chown 0:0 /var chmod 0755 /var chown 0:0 /var/ipfire chmod 0755 /var/ipfire chown 0:0 /var/ipfire/backup chmod 0755 /var/ipfire/backup chown 0:0 /var/ipfire/backup/addons chmod 0755 /var/ipfire/backup/addons chown 0:0 /var/ipfire/backup/addons/includes chmod 0755 /var/ipfire/backup/addons/includes chown 0:0 /var/ipfire/langs chmod 0755 /var/ipfire/langs chown 0:0 /var/ipfire/langs/de.pl <http://de.pl> chmod 0644 /var/ipfire/langs/de.pl <http://de.pl> chown 0:0 /var/ipfire/langs/en.pl <http://en.pl> chmod 0644 /var/ipfire/langs/en.pl <http://en.pl> chown 0:0 /var/ipfire/menu.d chmod 0755 /var/ipfire/menu.d chown 0:0 /var/log chmod 0755 /var/log ====================================================== -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 <tel:214.827.2170> http://www.dailydata.net-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
Hi,
it seems that this problem is yours... ;-)
I just added a few hosts manually and had no problem 'Unblocking all'.
Which process uses 'xtables' on IPFire? GeoIP?
Where do you get this message? On the GUI?
Just to be sure, to see if everything is (hopefully) ok regarding the rights I would do a: ' find / -user samba -group samba'
But I just found another one: RAM usage. On my production machine, the old guardian takes about *2529 KB* RAM. On my OFFLINE testmachine the NEW guardian claims to use *90011 KB*. Confirm?
Best, Matthias
On 17.07.2016 14:12, Mark Coolen wrote:
I set the /var/ipfire/guardian permissions to nobody:nobody and everything started to work.
Now I have other problems ;-)
I tried 'Unblock all' and got:
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?, referer: https://10.46.235.1:444/cgi-bin/guardian.cgi
On Sun, Jul 17, 2016 at 1:43 AM, Matthias Fischer < matthias.fischer@ipfire.org> wrote:
Hi,
another suggestion:
Delete ALL files in '/var/ipfire/guardian' and reload '/srv/web/ipfire/cgi-bin/guardian.cgi'. If these files don't exist, they will be created with standard settings.
Perhaps GUI can't load because of already wrong file permissions...
HTH, Matthias
On 17.07.2016 02:56, R. W. Rodolico wrote:
Do the following:
Open a command prompt on the router, via whatever means you have, and issue the command:
tail -f /var/log/httpd/error_log
Note the latest timestamp of the entry
Now, open a web browser and browse to the Guardian page, but nothing
else.
Copy the text from the command prompt after the timestamp you noted above. You can send that directly to me if you like, or reply here.
If I can not suggest a fix, I'll be happy to work with you via messaging, email, or if you're in the US, phone.
Rod
On 07/16/2016 07:42 PM, Mark Coolen wrote:
I'm still getting nothing but a blank page. Everything else seems to still be working fine, but I'm a bit afraid I'll mess something up really badly with all this playing around.
On Sat, Jul 16, 2016 at 7:19 PM, R. W. Rodolico <rodo@dailydata.net mailto:rodo@dailydata.net> wrote:
A partial fix would be to run the following bash commands. Thereason I
say partial is because I got the permissions from a differentfirewall
that does not have Guardian installed on it, so it could notdetermine
the correct permissions for any of those directories. This was taken from the output of a perl script I threw together.It is
NOT commented (sorry) but pretty straight forward. Simply gets the permissions and ownership from each directory (and parentdirectory) out
of an array based on Matthias' research. I did NOT check to verifythe
permissions were not already set. The output is simply a list of commands to set permissions from one machine to the same as the permissions on another. The originating script is temporarily stored at http://unixservertech.com/fixPermissions.pl That is a web site in progress. Feel free to download and run it ona
machine that has Guardian (after looking at it and making sure Ididn't
do something stoopid). No guarantee it won't eat your firewall, butI
ran it on a production machine, then ran the output on my testrouter
and it appears to have worked. ====================================================== chown 0:0 /etc chmod 0755 /etc chown 0:0 /etc/logrotate.d chmod 0755 /etc/logrotate.d chown 0:0 /etc/rc.d chmod 0755 /etc/rc.d chown 0:0 /etc/rc.d/init.d chmod 0755 /etc/rc.d/init.d chown 0:0 /etc/rc.d/init.d/networking chmod 0755 /etc/rc.d/init.d/networking chown 0:0 /etc/rc.d/init.d/networking/red.up chmod 0755 /etc/rc.d/init.d/networking/red.up chown 0:0 /etc/rc.d/init.d/snort chmod 0754 /etc/rc.d/init.d/snort chown 0:0 /etc/rc.d/rc0.d chmod 0755 /etc/rc.d/rc0.d chown 0:0 /etc/rc.d/rc3.d chmod 0755 /etc/rc.d/rc3.d chown 0:0 /etc/rc.d/rc6.d chmod 0755 /etc/rc.d/rc6.d chown 0:0 /opt chmod 0755 /opt chown 0:0 /opt/pakfire chmod 0755 /opt/pakfire chown 0:0 /opt/pakfire/db chmod 0755 /opt/pakfire/db chown 0:0 /opt/pakfire/db/installed chmod 0755 /opt/pakfire/db/installed chown 0:0 /srv chmod 0755 /srv chown 0:0 /srv/web chmod 0755 /srv/web chown 0:0 /srv/web/ipfire chmod 0755 /srv/web/ipfire chown 0:0 /srv/web/ipfire/cgi-bin chmod 0755 /srv/web/ipfire/cgi-bin chown 0:0 /srv/web/ipfire/cgi-bin/ids.cgi chmod 0755 /srv/web/ipfire/cgi-bin/ids.cgi chown 0:0 /usr chmod 0755 /usr chown 0:0 /usr/bin chmod 0755 /usr/bin chown 0:0 /usr/lib chmod 0755 /usr/lib chown 0:0 /usr/lib/perl5 chmod 0755 /usr/lib/perl5 chown 0:0 /usr/lib/perl5/site_perl chmod 0755 /usr/lib/perl5/site_perl chown 0:0 /usr/lib/perl5/site_perl/5.12.3 chmod 0755 /usr/lib/perl5/site_perl/5.12.3 chown 0:0 /usr/lib/perl5/site_perl/5.12.3/Net chmod 0755 /usr/lib/perl5/site_perl/5.12.3/Net chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chown 0:0/usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto
chmod 0755/usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi/auto
chown 0:0 /usr/sbin chmod 0755 /usr/sbin chown 0:0 /var chmod 0755 /var chown 0:0 /var/ipfire chmod 0755 /var/ipfire chown 0:0 /var/ipfire/backup chmod 0755 /var/ipfire/backup chown 0:0 /var/ipfire/backup/addons chmod 0755 /var/ipfire/backup/addons chown 0:0 /var/ipfire/backup/addons/includes chmod 0755 /var/ipfire/backup/addons/includes chown 0:0 /var/ipfire/langs chmod 0755 /var/ipfire/langs chown 0:0 /var/ipfire/langs/de.pl <http://de.pl> chmod 0644 /var/ipfire/langs/de.pl <http://de.pl> chown 0:0 /var/ipfire/langs/en.pl <http://en.pl> chmod 0644 /var/ipfire/langs/en.pl <http://en.pl> chown 0:0 /var/ipfire/menu.d chmod 0755 /var/ipfire/menu.d chown 0:0 /var/log chmod 0755 /var/log ====================================================== -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 <tel:214.827.2170> http://www.dailydata.net-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
Thanks for testing and pointing this out.
I've re-packed the latest version and uploaded the new tarballs with fixed permissions.
-Stefan
A partial fix would be to run the following bash commands. The reason I say partial is because I got the permissions from a different firewall that does not have Guardian installed on it, so it could not determine the correct permissions for any of those directories.
This was taken from the output of a perl script I threw together. It is NOT commented (sorry) but pretty straight forward. Simply gets the permissions and ownership from each directory (and parent directory) out of an array based on Matthias' research. I did NOT check to verify the permissions were not already set. The output is simply a list of commands to set permissions from one machine to the same as the permissions on another.
The originating script is temporarily stored at http://unixservertech.com/fixPermissions.pl That is a web site in progress. Feel free to download and run it on a machine that has Guardian (after looking at it and making sure I didn't do something stoopid). No guarantee it won't eat your firewall, but I ran it on a production machine, then ran the output on my test router and it appears to have worked. ====================================================== chown 0:0 /etc chmod 0755 /etc
chown 0:0 /etc/logrotate.d chmod 0755 /etc/logrotate.d
chown 0:0 /etc/rc.d chmod 0755 /etc/rc.d
chown 0:0 /etc/rc.d/init.d chmod 0755 /etc/rc.d/init.d
chown 0:0 /etc/rc.d/init.d/networking chmod 0755 /etc/rc.d/init.d/networking
chown 0:0 /etc/rc.d/init.d/networking/red.up chmod 0755 /etc/rc.d/init.d/networking/red.up
chown 0:0 /etc/rc.d/init.d/snort chmod 0754 /etc/rc.d/init.d/snort
chown 0:0 /etc/rc.d/rc0.d chmod 0755 /etc/rc.d/rc0.d
chown 0:0 /etc/rc.d/rc3.d chmod 0755 /etc/rc.d/rc3.d
chown 0:0 /etc/rc.d/rc6.d chmod 0755 /etc/rc.d/rc6.d
chown 0:0 /opt chmod 0755 /opt
chown 0:0 /opt/pakfire chmod 0755 /opt/pakfire
chown 0:0 /opt/pakfire/db chmod 0755 /opt/pakfire/db
chown 0:0 /opt/pakfire/db/installed chmod 0755 /opt/pakfire/db/installed
chown 0:0 /srv chmod 0755 /srv
chown 0:0 /srv/web chmod 0755 /srv/web
chown 0:0 /srv/web/ipfire chmod 0755 /srv/web/ipfire
chown 0:0 /srv/web/ipfire/cgi-bin chmod 0755 /srv/web/ipfire/cgi-bin
chown 0:0 /srv/web/ipfire/cgi-bin/ids.cgi chmod 0755 /srv/web/ipfire/cgi-bin/ids.cgi
chown 0:0 /usr chmod 0755 /usr
chown 0:0 /usr/bin chmod 0755 /usr/bin
chown 0:0 /usr/lib chmod 0755 /usr/lib
chown 0:0 /usr/lib/perl5 chmod 0755 /usr/lib/perl5
chown 0:0 /usr/lib/perl5/site_perl chmod 0755 /usr/lib/perl5/site_perl
chown 0:0 /usr/lib/perl5/site_perl/5.12.3 chmod 0755 /usr/lib/perl5/site_perl/5.12.3
chown 0:0 /usr/lib/perl5/site_perl/5.12.3/Net chmod 0755 /usr/lib/perl5/site_perl/5.12.3/Net
chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread-multi
chown 0:0 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread- multi/auto chmod 0755 /usr/lib/perl5/site_perl/5.12.3/i586-linux-thread- multi/auto
chown 0:0 /usr/sbin chmod 0755 /usr/sbin
chown 0:0 /var chmod 0755 /var
chown 0:0 /var/ipfire chmod 0755 /var/ipfire
chown 0:0 /var/ipfire/backup chmod 0755 /var/ipfire/backup
chown 0:0 /var/ipfire/backup/addons chmod 0755 /var/ipfire/backup/addons
chown 0:0 /var/ipfire/backup/addons/includes chmod 0755 /var/ipfire/backup/addons/includes
chown 0:0 /var/ipfire/langs chmod 0755 /var/ipfire/langs
chown 0:0 /var/ipfire/langs/de.pl chmod 0644 /var/ipfire/langs/de.pl
chown 0:0 /var/ipfire/langs/en.pl chmod 0644 /var/ipfire/langs/en.pl
chown 0:0 /var/ipfire/menu.d chmod 0755 /var/ipfire/menu.d
chown 0:0 /var/log chmod 0755 /var/log ======================================================
OK. Now I have everything working well. Guardian is auto-blocking and allowing me to selectively block and unblock as well as unblock all.
I think the IDS module really needs some kind of default settings for those who want to use it but don't understand the complexities of Snort's rules. I just guessed at things when I set Snort up, but it does produce logs of possible intrusion attempts and Guardian does respond appropriately.
On Sat, Jul 16, 2016 at 2:43 PM, R. W. Rodolico rodo@dailydata.net wrote:
I saw the same issue and filed a bug report (https://bugzilla.ipfire.org/show_bug.cgi?id=11146).
When something like this pops up, I generally https://bugzilla.ipfire.org/show_bug.cgi?id=11146 immediately after the problem shows up; that usually gives some indication of the problem.
As Matthias says, it is a permissions issue on the configuration file directory. Either manually create the files (with correct ownership and permission) or change ownership/permission on the directory. Then, you have a nice, pretty GUI.
I was able to efficiently block myself from the GUI after that. Since I don't know anything about how to test Snort, I'm having problems getting it to block automatically, but that is another issue.
Rod
On 07/16/2016 09:19 AM, Mark Coolen wrote:
I'm a bit confused about that. Why would 2.0-002 be newer than 2.0-010? There's a 2.0-012 under 'old approach' but those files have an older timestamp. The 2.0-002 is a tarball, but the 2.0-010 is an ipfire package as are the 'dependancies'. I've used Guardian 2 several times in the past by just extracting according to the instructions on stevee's ;--) page, but that doesn't seem to work with the 2.0-002 tarball. I just get a completely blank page in the GUI. How do we test?
On Sat, Jul 16, 2016 at 2:59 AM, Matthias Fischer <matthias.fischer@ipfire.org mailto:matthias.fischer@ipfire.org>
wrote:
Hi, Ok, next. Am I right assuming that the '2.0-002'-version at http://people.ipfire.org/~stevee/guardian-2.0/ plus http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/is
the latest!? Best, Matthias On 16.07.2016 04:03, Mark Coolen wrote: > I'm willing to test it as well. I take it the instructions from > http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire are still > good? > > On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico <rodo@dailydata.net <mailto:rodo@dailydata.net>> wrote: >Tell me what I need to do to test Guardian. I've never installed it, but I am doing it now.
Rod
On 07/15/2016 05:00 AM, Michael Tremer wrote:
Hi guys,
even if you have a conversation on the phone, please try keeping us in the loop.
So the key points of what I know:
- A release is targeted for core update 104
- There are a few changes required so that re-blocking a host after
it has been manually unblocked allows this host the configured number of tries again and not only one.
- Many more testers are required since feedback is really low at
this point.
Did I get this right? What is the ETA for a set of patches on the mailing list?
What is the plan to engage more testers?
Best, -Michael
On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote:
Hi Stevee I know you are very busy and working hard on the this. But if you want to release the new Guardian 2 with Core 104 we still need to do some work and it must be tested! So please tell us something about the new guardian2 and the state of your work.
Maybe we find more testers here on the list.
Meanwhile I've talked with Michael about the state which I know of the guardian2 and we both go confirm that the list of blocked IPs which runs in the background isn't a good idea. Please let us talk by phone about it again.
- Daniel
>> > > >-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
-- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net
Can you give me a clue on how to set up Snort? I got nothing on my intrusion logs. I "attacked" it from a remote server (all machines are mine, so I can do that :) and saw nothing. I downloaded some rules from EmergingThreats.net Community Rules and turned several of them on, but saw nothing.
I had tried to do te Snort/VRT GPLv2 Community Rules and no rules showed up. Just tried the SourceFire VRT Rules for registered users and got an error, and no new rules showed up.
I guess I need to clean this whole thing out and start over, if I can figure out how to clean out the Snort ruleset.
If anyone can give me a clue on this, I'll be happy to set it up and try attacking myself.
Selective blocking/unblocking works like a charm.
Rod
On 07/17/2016 06:47 PM, Mark Coolen wrote:
OK. Now I have everything working well. Guardian is auto-blocking and allowing me to selectively block and unblock as well as unblock all.
I think the IDS module really needs some kind of default settings for those who want to use it but don't understand the complexities of Snort's rules. I just guessed at things when I set Snort up, but it does produce logs of possible intrusion attempts and Guardian does respond appropriately.
On Sat, Jul 16, 2016 at 2:43 PM, R. W. Rodolico <rodo@dailydata.net mailto:rodo@dailydata.net> wrote:
I saw the same issue and filed a bug report (https://bugzilla.ipfire.org/show_bug.cgi?id=11146). When something like this pops up, I generally https://bugzilla.ipfire.org/show_bug.cgi?id=11146 immediately after the problem shows up; that usually gives some indication of the problem. As Matthias says, it is a permissions issue on the configuration file directory. Either manually create the files (with correct ownership and permission) or change ownership/permission on the directory. Then, you have a nice, pretty GUI. I was able to efficiently block myself from the GUI after that. Since I don't know anything about how to test Snort, I'm having problems getting it to block automatically, but that is another issue. Rod On 07/16/2016 09:19 AM, Mark Coolen wrote: > I'm a bit confused about that. Why would 2.0-002 be newer than 2.0-010? > There's a 2.0-012 under 'old approach' but those files have an older > timestamp. The 2.0-002 is a tarball, but the 2.0-010 is an ipfire > package as are the 'dependancies'. I've used Guardian 2 several times in > the past by just extracting according to the instructions on stevee's > ;--) page, but that doesn't seem to work with the 2.0-002 tarball. I > just get a completely blank page in the GUI. > How do we test? > > On Sat, Jul 16, 2016 at 2:59 AM, Matthias Fischer > <matthias.fischer@ipfire.org <mailto:matthias.fischer@ipfire.org> <mailto:matthias.fischer@ipfire.org <mailto:matthias.fischer@ipfire.org>>> wrote: > > Hi, > > Ok, next. > > Am I right assuming that the '2.0-002'-version at > http://people.ipfire.org/~stevee/guardian-2.0/ plus > http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/ is > the latest!? > > Best, > Matthias > > On 16.07.2016 04:03, Mark Coolen wrote: > > I'm willing to test it as well. I take it the instructions from > > http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire > are still > > good? > > > > On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico > <rodo@dailydata.net <mailto:rodo@dailydata.net> <mailto:rodo@dailydata.net <mailto:rodo@dailydata.net>>> wrote: > > > Tell me what I need to do to test Guardian. I've never installed it, > but I am doing it now. > > Rod > > On 07/15/2016 05:00 AM, Michael Tremer wrote: >> Hi guys, > >> even if you have a conversation on the phone, please try keeping us >> in the loop. > >> So the key points of what I know: > >> * A release is targeted for core update 104 > >> * There are a few changes required so that re-blocking a host after >> it has been manually unblocked allows this host the configured >> number of tries again and not only one. > >> * Many more testers are required since feedback is really low at >> this point. > >> Did I get this right? What is the ETA for a set of patches on the >> mailing list? > >> What is the plan to engage more testers? > >> Best, -Michael > >> On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote: >>> Hi Stevee I know you are very busy and working hard on the this. >>> But if you want to release the new Guardian 2 with Core 104 we >>> still need to do some work and it must be tested! So please tell >>> us something about the new guardian2 and the state of your work. >>> >>> Maybe we find more testers here on the list. >>> >>> Meanwhile I've talked with Michael about the state which I know >>> of the guardian2 and we both go confirm that the list of blocked >>> IPs which runs in the background isn't a good idea. Please let us >>> talk by phone about it again. >>> >>> - Daniel > > >> > > > > > > > > > > > -- > _ _ _ ___ _ > )\/,) ___ __ )L, )) __ __ )) __ _ _ > ((`(( ((_( (| ((\ ((__((_)((_)(( (('((\( -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 <tel:214.827.2170> http://www.dailydata.net-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
You have to register on snort.org. I think I just followed the instructions on the IDS page in the IPFire GUI and then input my oinkcode. I have no idea which rules to enable once I have them downloaded, but I spent awhile going throught them awhile back and guessed ;-)
I does work, and Guardian 2 watches the snort logs and automagically blocks IPs.
On Mon, Jul 18, 2016 at 12:37 AM, R. W. Rodolico rodo@dailydata.net wrote:
Can you give me a clue on how to set up Snort? I got nothing on my intrusion logs. I "attacked" it from a remote server (all machines are mine, so I can do that :) and saw nothing. I downloaded some rules from EmergingThreats.net Community Rules and turned several of them on, but saw nothing.
I had tried to do te Snort/VRT GPLv2 Community Rules and no rules showed up. Just tried the SourceFire VRT Rules for registered users and got an error, and no new rules showed up.
I guess I need to clean this whole thing out and start over, if I can figure out how to clean out the Snort ruleset.
If anyone can give me a clue on this, I'll be happy to set it up and try attacking myself.
Selective blocking/unblocking works like a charm.
Rod
On 07/17/2016 06:47 PM, Mark Coolen wrote:
OK. Now I have everything working well. Guardian is auto-blocking and allowing me to selectively block and unblock as well as unblock all.
I think the IDS module really needs some kind of default settings for those who want to use it but don't understand the complexities of Snort's rules. I just guessed at things when I set Snort up, but it does produce logs of possible intrusion attempts and Guardian does respond appropriately.
On Sat, Jul 16, 2016 at 2:43 PM, R. W. Rodolico <rodo@dailydata.net mailto:rodo@dailydata.net> wrote:
I saw the same issue and filed a bug report (https://bugzilla.ipfire.org/show_bug.cgi?id=11146). When something like this pops up, I generally https://bugzilla.ipfire.org/show_bug.cgi?id=11146 immediately after the problem shows up; that usually gives some indication of the problem. As Matthias says, it is a permissions issue on the configuration file directory. Either manually create the files (with correct ownershipand
permission) or change ownership/permission on the directory. Then,you
have a nice, pretty GUI. I was able to efficiently block myself from the GUI after that.Since I
don't know anything about how to test Snort, I'm having problemsgetting
it to block automatically, but that is another issue. Rod On 07/16/2016 09:19 AM, Mark Coolen wrote: > I'm a bit confused about that. Why would 2.0-002 be newer than2.0-010?
> There's a 2.0-012 under 'old approach' but those files have anolder
> timestamp. The 2.0-002 is a tarball, but the 2.0-010 is an ipfire > package as are the 'dependancies'. I've used Guardian 2 severaltimes in
> the past by just extracting according to the instructions onstevee's
> ;--) page, but that doesn't seem to work with the 2.0-002 tarball.I
> just get a completely blank page in the GUI. > How do we test? > > On Sat, Jul 16, 2016 at 2:59 AM, Matthias Fischer > <matthias.fischer@ipfire.org <mailto:matthias.fischer@ipfire.org> <mailto:matthias.fischer@ipfire.org <mailto:matthias.fischer@ipfire.org>>> wrote: > > Hi, > > Ok, next. > > Am I right assuming that the '2.0-002'-version at > http://people.ipfire.org/~stevee/guardian-2.0/ plus >http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/ is
> the latest!? > > Best, > Matthias > > On 16.07.2016 04:03, Mark Coolen wrote: > > I'm willing to test it as well. I take it the instructionsfrom
> >http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire
> are still > > good? > > > > On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico > <rodo@dailydata.net <mailto:rodo@dailydata.net> <mailto:rodo@dailydata.net <mailto:rodo@dailydata.net>>> wrote: > > > Tell me what I need to do to test Guardian. I've never installedit,
> but I am doing it now. > > Rod > > On 07/15/2016 05:00 AM, Michael Tremer wrote: >> Hi guys, > >> even if you have a conversation on the phone, please try keepingus
>> in the loop. > >> So the key points of what I know: > >> * A release is targeted for core update 104 > >> * There are a few changes required so that re-blocking a hostafter
>> it has been manually unblocked allows this host the configured >> number of tries again and not only one. > >> * Many more testers are required since feedback is really low at >> this point. > >> Did I get this right? What is the ETA for a set of patches on the >> mailing list? > >> What is the plan to engage more testers? > >> Best, -Michael > >> On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote: >>> Hi Stevee I know you are very busy and working hard on the this. >>> But if you want to release the new Guardian 2 with Core 104 we >>> still need to do some work and it must be tested! So please tell >>> us something about the new guardian2 and the state of your work. >>> >>> Maybe we find more testers here on the list. >>> >>> Meanwhile I've talked with Michael about the state which I know >>> of the guardian2 and we both go confirm that the list of blocked >>> IPs which runs in the background isn't a good idea. Please let us >>> talk by phone about it again. >>> >>> - Daniel > > >> > > > > > > > > > > > -- > _ _ _ ___ _ > )\/,) ___ __ )L, )) __ __ )) __ _ _ > ((`(( ((_( (| ((\ ((__((_)((_)(( (('((\( -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 <tel:214.827.2170> http://www.dailydata.net-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
-- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net
hmmm. that is what I tried, but it didn't work. Maybe I need to go get another oinkcode or something.
Thank you
On 07/18/2016 12:48 PM, Mark Coolen wrote:
You have to register on snort.org http://snort.org. I think I just followed the instructions on the IDS page in the IPFire GUI and then input my oinkcode. I have no idea which rules to enable once I have them downloaded, but I spent awhile going throught them awhile back and guessed ;-)
I does work, and Guardian 2 watches the snort logs and automagically blocks IPs.
On Mon, Jul 18, 2016 at 12:37 AM, R. W. Rodolico <rodo@dailydata.net mailto:rodo@dailydata.net> wrote:
Can you give me a clue on how to set up Snort? I got nothing on my intrusion logs. I "attacked" it from a remote server (all machines are mine, so I can do that :) and saw nothing. I downloaded some rules from EmergingThreats.net Community Rules and turned several of them on, but saw nothing. I had tried to do te Snort/VRT GPLv2 Community Rules and no rules showed up. Just tried the SourceFire VRT Rules for registered users and got an error, and no new rules showed up. I guess I need to clean this whole thing out and start over, if I can figure out how to clean out the Snort ruleset. If anyone can give me a clue on this, I'll be happy to set it up and try attacking myself. Selective blocking/unblocking works like a charm. Rod On 07/17/2016 06:47 PM, Mark Coolen wrote: > OK. Now I have everything working well. Guardian is auto-blocking and > allowing me to selectively block and unblock as well as unblock all. > > I think the IDS module really needs some kind of default settings for > those who want to use it but don't understand the complexities of > Snort's rules. I just guessed at things when I set Snort up, but it does > produce logs of possible intrusion attempts and Guardian does respond > appropriately. > > On Sat, Jul 16, 2016 at 2:43 PM, R. W. Rodolico <rodo@dailydata.net <mailto:rodo@dailydata.net> > <mailto:rodo@dailydata.net <mailto:rodo@dailydata.net>>> wrote: > > I saw the same issue and filed a bug report > (https://bugzilla.ipfire.org/show_bug.cgi?id=11146). > > When something like this pops up, I generally > https://bugzilla.ipfire.org/show_bug.cgi?id=11146 > immediately after the problem shows up; that usually gives some > indication of the problem. > > As Matthias says, it is a permissions issue on the configuration file > directory. Either manually create the files (with correct ownership and > permission) or change ownership/permission on the directory. Then, you > have a nice, pretty GUI. > > I was able to efficiently block myself from the GUI after that. Since I > don't know anything about how to test Snort, I'm having problems getting > it to block automatically, but that is another issue. > > Rod > > On 07/16/2016 09:19 AM, Mark Coolen wrote: > > I'm a bit confused about that. Why would 2.0-002 be newer than 2.0-010? > > There's a 2.0-012 under 'old approach' but those files have an older > > timestamp. The 2.0-002 is a tarball, but the 2.0-010 is an ipfire > > package as are the 'dependancies'. I've used Guardian 2 several times in > > the past by just extracting according to the instructions on stevee's > > ;--) page, but that doesn't seem to work with the 2.0-002 tarball. I > > just get a completely blank page in the GUI. > > How do we test? > > > > On Sat, Jul 16, 2016 at 2:59 AM, Matthias Fischer > > <matthias.fischer@ipfire.org <mailto:matthias.fischer@ipfire.org> <mailto:matthias.fischer@ipfire.org <mailto:matthias.fischer@ipfire.org>> > <mailto:matthias.fischer@ipfire.org <mailto:matthias.fischer@ipfire.org> > <mailto:matthias.fischer@ipfire.org <mailto:matthias.fischer@ipfire.org>>>> wrote: > > > > Hi, > > > > Ok, next. > > > > Am I right assuming that the '2.0-002'-version at > > http://people.ipfire.org/~stevee/guardian-2.0/ plus > > http://people.ipfire.org/~stevee/guardian-2.0/packages/dependencies/ is > > the latest!? > > > > Best, > > Matthias > > > > On 16.07.2016 04:03, Mark Coolen wrote: > > > I'm willing to test it as well. I take it the instructions from > > > http://planet.ipfire.org/post/introducing-guardian-2-0-for-ipfire > > are still > > > good? > > > > > > On Fri, Jul 15, 2016 at 8:23 PM, R. W. Rodolico > > <rodo@dailydata.net <mailto:rodo@dailydata.net> <mailto:rodo@dailydata.net <mailto:rodo@dailydata.net>> > <mailto:rodo@dailydata.net <mailto:rodo@dailydata.net> <mailto:rodo@dailydata.net <mailto:rodo@dailydata.net>>>> wrote: > > > > > Tell me what I need to do to test Guardian. I've never installed it, > > but I am doing it now. > > > > Rod > > > > On 07/15/2016 05:00 AM, Michael Tremer wrote: > >> Hi guys, > > > >> even if you have a conversation on the phone, please try keeping us > >> in the loop. > > > >> So the key points of what I know: > > > >> * A release is targeted for core update 104 > > > >> * There are a few changes required so that re-blocking a host after > >> it has been manually unblocked allows this host the configured > >> number of tries again and not only one. > > > >> * Many more testers are required since feedback is really low at > >> this point. > > > >> Did I get this right? What is the ETA for a set of patches on the > >> mailing list? > > > >> What is the plan to engage more testers? > > > >> Best, -Michael > > > >> On Thu, 2016-07-14 at 14:36 +0200, Daniel Weismüller wrote: > >>> Hi Stevee I know you are very busy and working hard on the this. > >>> But if you want to release the new Guardian 2 with Core 104 we > >>> still need to do some work and it must be tested! So please tell > >>> us something about the new guardian2 and the state of your work. > >>> > >>> Maybe we find more testers here on the list. > >>> > >>> Meanwhile I've talked with Michael about the state which I know > >>> of the guardian2 and we both go confirm that the list of blocked > >>> IPs which runs in the background isn't a good idea. Please let us > >>> talk by phone about it again. > >>> > >>> - Daniel > > > > >> > > > > > > > > > > > > > > > > > > > -- > > _ _ _ ___ _ > > )\/,) ___ __ )L, )) __ __ )) __ _ _ > > ((`(( ((_( (| ((\ ((__((_)((_)(( (('((\( > > -- > Rod Rodolico > Daily Data, Inc. > POB 140465 > Dallas TX 75214-0465 > 214.827.2170 <tel:214.827.2170> <tel:214.827.2170 <tel:214.827.2170>> > http://www.dailydata.net > > > > > -- > _ _ _ ___ _ > )\/,) ___ __ )L, )) __ __ )) __ _ _ > ((`(( ((_( (| ((\ ((__((_)((_)(( (('((\( -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 <tel:214.827.2170> http://www.dailydata.net-- _ _ _ ___ _ )/,) ___ __ )L, )) __ __ )) __ _ _ ((`(( ((_( (| ((\ ((__((_)((_)(( (('(((
-
Daniel Weismüller -
Mark Coolen -
Matthias Fischer -
Michael Tremer -
R. W. Rodolico -
Stefan Schantl