Before I go any further I must admit that I’m pretty rubbish at setting these up, so please be gentle!
Now my problem; I have a normal desktop pc (I don’t want to set it up as a server) but when I check the hardness of my set up with Gibson Research Centre, it fails. It can see ports 22,23,80,443 as closed but still visible…? I have never had this happen to me before and struggling my way through yast firewall tool, I can find no easy way of sorting this out… Please help 
Doing as root
netstat -tulp
will tell you what programs are listening on what ports. Those posrts may then be blocked by the Firewall, but the programs are there and listen (in vain).
Thank you hcvv, As you recommend I input netstat -tulp and get the following:
penguinclaw@linux-zz0c:~> sudo netstat -tulp
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
root’s password:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:sunrpc : LISTEN 3365/rpcbind
tcp 0 0 localhost:ipp : LISTEN 3408/cupsd
tcp 0 0 localhost:smtp : LISTEN 3557/master
tcp 0 0 *:sunrpc : LISTEN 3365/rpcbind
tcp 0 0 localhost:ipp : LISTEN 3408/cupsd
tcp 0 0 localhost:smtp : LISTEN 3557/master
udp 0 0 *:988 : 3365/rpcbind
udp 0 0 *:mdns : 3187/avahi-daemon:
udp 0 0 *:56773 : 3187/avahi-daemon:
udp 0 0 *:sunrpc : 3365/rpcbind
udp 0 0 *:49778 : 1672/dhclient6
udp 0 0 *:ipp : 3408/cupsd
udp 0 0 *:988 : 3365/rpcbind
udp 0 0 *:sunrpc : 3365/rpcbind
udp 0 0 *:14649 : 1672/dhclient6
udp 0 0 *:dhcpv6-client : 1672/dhclient6
penguinclaw@linux-zz0c:~>
Is this information useful in solving my problem?
Are you directly connected to the Internet, or are you behind a router?
I am behind a Virgin “superhub” so I guess that is through a router. It’s funny in the YAST firewall2 there doesn’t seem to be anywhere to disable ports, whereas in Guarddog this is a very useful feature.
I’m not familiar with ‘Virgin “superhub”’
Does your computer have a public IP, or does it have a private IP. A private IP is usually of the form 192.168.x.y or 10.x.y.z or 172.x.y.z ?
If you have a private IP, then you are behind some sort of router, and GRC is seeing ports on the router rather than on your system.
If you have a public IP, then it might be seeing your ports, and perhaps your firewall is not turned on.
Thanks nrickert, yes the superhub is a router and I have a private IP. I guess that means I should actually tune the settings on the router. I hadn’t actually considered that GRC may only be looking at that!
Now to dig out the handbook!!!
Thanks for your help… although I may be back
As see, during my sleep somone else already gave you a hint you are following now. But anwsering your question above:
sudo netstat -tulp
but
netstat -tulp
Running anything as root when not needed is thus to your own risk.
Next time when copying/pasting a peice of computer converstation here, please do so between CODE tags to make it readable (Posting in Code Tags - A Guide.
It gives you insight in the network servers you are running and the ports they are listening to. The firewall may block those ports and thus make them unusable.
In your case, your test tells you about e.g. port 80. But the output from the netstat tells you that there is no program on your system listening on port 80 (http). Thus be asured nobody can enter your system using that port, firewall or no firewall.
Thank you hcvv. That was very helpful. I think by looking at this and reading man pages I learnt a little bit more. So thanks for pointing me in the right directions guys
You are quite welcome. I always hope that people not only get answers to their peoblems, but that they also get knowledge. Seems that this worked this time
A very useful tidbit.
I do not believe this is necessarily correct. I believe the GRC probes are sophisticated enough, if the router has open ports, to “see” the target machine. I would research the info on GRC - he probably covers that aspect of things somewhere. Steve is a pretty thorough guy.
If he is behind a NAT router, then the router simply will not forward those packets to the machine unless he has setup port forwarding for the specific ports. I’ll admit that I didn’t mention the possibility of port forwarding, but that’s because the wording of the original post made it look very unlikely that the mentioned ports were being forwarded.
I am not a fan of the Yast firewall tool. It reminds me of the bad old Windows days, when tools were added to windows but only after they were crippled or stripped down to near uselessness. Firestarter and Guarddog do a much better interface, imho. But, enough kvetching, and on to something constructive and useful.
If I recall - and I searched for a link or a reference, which I did not find, so I am sure one of the other folks who inhabit these forums will add their $.02 - the default setting in the firewall, when it is on, is “deny”. Which means if you don’t open it on purpose, it is closed. This is for the “external” zone. The “internal” zone, again, if I recall, is by default open, or “accept” in iptables lingo. Put your eth0 on the external zone. And, I am pretty sure that, unlike windows, a program will not open a port without you being pretty aware that it is trying to do so. I apologize that the answer is a little mushy - “if I recall” and all that - but I did some quick research and didn’t find what I was looking for to back this up, but I figured I would at least add this to the conversation and others might fill in on the solid references - or your own research might be guided in a helpful direction.
Best to ya.
Now I’m worried again 
The thing is I’ve done the same scan via Windows and got the exact same result…
Also my eth0 is in the external zone.
What is annoying is that I can’t see an obvious gui YAST firewall way of changing the access permissions to ports. YAST is so brilliant imho (that’s why I love openSuse) in every other way but why can’t I sort this easily like I could using Guarddog?
Oh and thanks guys for helping :)
No, if the router doesn’t forward the ports to the target machine (check if there is a default forward on that router by the way), then you are seeing the router’s response, not the target machine’s. Just notch it down to a router that decided to do a REJECT on the packets on those ports instead of a DROP.
Incidentally it may feel nice to have your IP address completely stealthed, but in practice having DROP instead of REJECT adds insignificant security. And given the exhaustion of IPv4 address pools, most addresses are in use. Skript kiddies just fire packets away without worrying about whether something is really there, and most victims are fall prey to social engineering and identity theft anyway.