I have tried this under kernel 2.6.4-rc1-mm2 with guarddog ebuilds 2.2.0 and 2.3.1, same result everytime: the ftp, http and telnet ports are never closed to the outside world, no matter what I do in guarddog (filtering or outright blocking), though it does work properly for the other ports. An nmap from another machine (or checking on www.grc.com) shows that these ports are still open. I am connecting to the Internet via a lan (dhcp on eth0, activated in guarddog as well). Reproducible: Always Steps to Reproduce: 1. Open guarddog as root 2. Block or filter ftp, http and telnet protocols served by "Local" zone to "Internet" zone 3. Press apply 4. Check on http://grc.com/x/ne.dll?rh1dkyd2 Actual Results: ftp, telnet and http ports remain open Expected Results: ftp, telnet and http should be either closed or silently dropping packets kernel 2.6.4-rc1-mm2 on an i686 dhcp lan connection on eth0
I don't trust grc.com for anything. Can you attach the result of "iptables-save" after you have applied the ruleset that is suppsed to filter ftp, http and telnet?
Created attachment 27279 [details] iptables-save output
According to your iptables-save output you do infact block http, ftp and telnet. I see that you are using some reserved IP addresses, which makes me belive that you have some sort of NAT device infront of your Gentoo machine. Check with that one to see if it redirects the ports to a different PC. Also, some firewalls implements a "everything open" response to portscans, and some ISP's does this as well (my ISP, for an example, blocks HTTP and various backdoor ports.. but a portscan can sometimes show them as "open" (actually filtered, nmap speak)). If you don't mind, find me on IRC, irc.freenode.net (nickname: mboman), and I can do a nmap of your machine and confirm which of the possibilities it is. Guarddog does infact, as stated above, create the relevant block rules so something else is not configured propperly.
If no further feedback is recived, I am inclined to mark this bug as invalid, based on the output from iptables-save.
Resolving this bug as invalid as iptables-save output shows that the correct rules are created, so the GRC.com scan output should be caused by ISP. No further feedback was recivied to prove otherwise either.
