You are not logged in.
Where do I set that Guarddog will load or at least set its rules when the computer start?
Offline
Hi nadavvin
I installed Guarddog recently and I use it now without problem.
Here is what I did to have it starting at boot time :
after the configuration in the GUI and clicking on the Apply button, guarddog creates a script and launches the firewall.
It creates the script /etc/rc.firewall
I edited the /etc/rc.local file, adding these lines:
if [ -x /etc/rc.firewall ]; then
/etc/rc.firewall
fi
Last edited by berbae (2007-02-21 22:26:19)
Offline
Do the guarddog package not contain a script for /etc/rc.d? This would be the proper "Arch way" of starting something at boot time.
Offline
Something that may work well too (and more Arch like) is to create a symlink ( ln -s /etc/rc.firewall firewall) in /etc/rc.d
Then in /etc/rc.conf you add "firewall" to the DAEMONS line so it starts at boot.
R.
Offline
Thanks ralvez
for that more Arch flavored method to do things.
But the /etc/rc.firewall script doesn't take parameters as 'start' or 'stop'.
Isn't that a problem to put the link in /etc/rc.d directory ?
Offline
thanks.
But the /etc/rc.firewall script doesn't take parameters as 'start' or 'stop'.
Isn't that a problem to put the link in /etc/rc.d directory ?
Although the script is not use in start and stop,the parameters don't disturb it since the script get it with $1 and there nothing in the script which read the $1 and therefore it is not create any problem.
Offline
Yeah, an rc.d script for guarddog would be a bit odd. I would use guarddog to generate the rules and just save them with iptables and run iptables with rc.d at start
So, run /etc/rc.firewall, then run /etc/rc.d/iptables save, then add iptables to rc.conf
Will do the same thing as running /etc/rc.firewall pretty much.
I suppose I could create and rc.d that runs /etc/rc.firewall but that depends on user saving file there etc etc. Would be kinda redundant - better to add it to rc.local.
Offline
All the solutions suggested work ... that's the beauty of *nix!
My point was more to indicate that whatever feels more "natural" to you (or the way you work with Arch) is viable.
Some network security people will argue that you should have your firewall up as soon as you loaded the network therefore my suggestion of the DAEMONS line.
I concur with dtw that /etc/rc.local should do for most of us.
R
Offline
My rc.local says
#!/bin/bash
#
# /etc/rc.local: Local multi-user startup script.
#
# Guarddog
if [ -r /etc/rc.firewall ]; then
. /etc/rc.firewall
fi
#
Does that mean guarddog script starts before network or do I need to add something in rc.conf (sorry for this extrmely nu-b type question since i'm one)..
Offline
If I understand correctly rc.local runs after rc.conf, and so it would start after your network is running.
I however do not think it is such a critical matter as long as it runs. The likelihood that you would receive an attack in the 4 to 5 sec. difference is very, very, very unlikely.
R.
Offline
If I understand correctly rc.local runs after rc.conf, and so it would start after your network is running.
I however do not think it is such a critical matter as long as it runs. The likelihood that you would receive an attack in the 4 to 5 sec. difference is very, very, very unlikely.R.
So that means, I need not do anything with the settings.
Also, I ran grc shields up before setting up guarddog and afterwards, but both cases I got the same message:
Greetings!
Without your knowledge or explicit permission, the Windows networking technology which connects your computer to the Internet may be offering some or all of your computer's data to the entire world at this very moment!
I'm behind a router. Is it this that is causing ineffective results in grc or the firewall is not working at all.
Offline
Is it this that is causing ineffective results in grc or the firewall is not working at all.
No, it's some dumb idiot trying to make you believe you need to buy their product to protect yourself.
If you want to test your computer for security use this site:https://www.grc.com/x/ne.dll?bh0bkyd2
You will learn a lot and they are not trying to get you to buying anything.
Hope this helps.
R.
Offline
Is it this that is causing ineffective results in grc or the firewall is not working at all.
No, it's some dumb idiot trying to make you believe you need to buy their product to protect yourself.
If you want to test your computer for security use this site:https://www.grc.com/x/ne.dll?bh0bkyd2
You will learn a lot and they are not trying to get you to buying anything.Hope this helps.
R.
Well I used the same site only which gives the above result with and without firewall.
Also, I kept torrent ports open in guardog, but deluge is unable to connect and a port test at http://www.deluge-torrent.org/test-port.php?port=6881 shows the ports to be closed. Then I switched to windows xp (i've a dual boot), disabled firewall, and ran the port scan and again the same thing, port is closed. It seems that my ISP is blocking the ports and not only the default ports for torrent but also all the other ports except 80, 21, etc. Is there a work around so that I can get torrent client working.
Offline
Are you sure the port is closed by your ISP? I find difficult to believe your ISP blocks all the ports but 2.
If that is truly the case, my advice is change ISPs.
Offline
Try high port numbers like 63213 , they are rarely blocked.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
But that would not help him if in fact his ISP does not route the ports he needs.
R.
Offline
sorry for delayed replay. I finally found what was going on with my internet connection. It seems the culprit was my router. My ISP provide me with a new router which had settings to block ports. Once I changed to the old router, it started showing open ports.
another observation is that ports are only open when being used. In other words, if a torrent client is not running, then it shows the ports are closed but once it is running, one port is shown as open (not the entire range).
but the issue with grc remains the same.
Offline