When I used the firewall configurer (available in F22 Gnome Software) it shows that TCP & UDP are set up to be open for 1025-65535.
As I understand it most of the Firewall ports except 80 & 443 could be blocked as my usage is only for internet and my local wifi (library).
Would this be correct?

I am confused because when I ran nmap -A localhost it showed only port 631 for TCP.

netstat -tulpn showed 323, 5353, and 49575 for UDP in addition to 631 for TCP as being open.

This seems like it is inconsistent even if nmap was showing what it thought was closed. What did I do incorrectly? Hope someone can help out here.

Hi there,

Firstly regarding the open ports you mention:

- 631 is used by CUPS (printing)
- 5353 is multicast DNS
- I'm not sure what UDP ports 323 and 49575 are used for - which process does netstat say are using them?

Are these services listening on all interfaces (0.0.0.0ort in the "Local Address" column, or only on the loopback interface (127.0.0.1ort)?

Regarding nmap, the "nmap -A localhost" command doesn't scan UDP ports, which explains the difference between it's output and that from netstat. Try "nmap -sU -A localhost" to see open UDP ports.

Regarding nmap/netstat vs the firewall rules, they can easily differ. If a service isn't running at the moment, it won't show in nmap/netstat. That doesn't mean it will be blocked by the firewall, though, so it might inadvertently become accessible if it is started. It's therefore better to block everything except the services you specifically want to be accessible, to future proof the configuration a little.

To see what is actually open from a firewall point of view, it's best to look at the iptables listing. Start with the output from "sudo iptables -t filter -L".

Is the machine in question your workstation, or a server?

I'm afraid I'm not familiar with the specific firewall configuration tool you're using. From a quick online search it seems similar to other tools, though. Most likely what you are looking at is the ports which are open for connections from outside to your computer. Outgoing connections from your computer are usually allowed on all ports. If this is a workstation, you should not need to open these ports to the outside. For ports 80 and 443 for example, you only need them open if you're running a web server on your machine, and want to access it from another machine.

For ports 1025-65535, it looks like these were opened by default in F21 Workstation - see https://lwn.net/Articles/626302/. You should be able to safely close these in most cases.

If this doesn't answer your question, please post the output from the iptables command above, then we can elaborate further.

Regards,

Clifford

1 members found this post helpful.

I'm going to agree with cliffordw on this to a degree. What you see inside the system might not be seen outside the system. Everything you are running is on the system and there are ports that the system needs working in order for the system to function correctly. If you are going to scan the system with nmap then you should be doing this from outside the system to get a true picture of what is seen and what is not.

Unless you are running some sort of service that needs to be accessed form the outside there is no need to open any inbound ports. If you running a workstation then the following rules will lock you down properly:

1 members found this post helpful.

First of all thanks for the info. Appreciate confirmation re nmap from outside. The readings I had suggested nmapping with a localhost target and since that pointed at 631 I was in doubt.
The "Firewall-config 0.3.13 from Red Hat shows 1025-65535, and on re-read it does say "add ports needing to be accessable". So I am guessing that those ports are all open ports thru the Firewall (BTW it outputs that info (pre me) when I point at ports.

Can either of you suggest why that config program would specify 1025-65535 as open (?my guess) and not specify any of the common ports as being open?
t came that way).

@LazyDog: My understanding is that the firewall is intercalated into the kernel. I guess this is why the config program. After writing my firewall for Slackware 13.37 I don't look forward to punching those commands into the kernel.

Other than this RH config program I have run into some references to "fuzer". Is that possibly a means to put commands into the kernel without having to recompile the kernel?
@Cliffordw: That config software did not specify where it was listening but I think it must be 127.0.0.1 as that is where I pointed it.
Thanks again for the input from both of you
ASAP I will run that sudo IPTables command.
PS
Ran that command and got "anything" "everywhere"for source and destination, respectively, so it looks all open -- will need a refresh course on reading that output, as the output is a bit strange to me.

If you want to see what ports are open/closed/stealhed and get port definitions etc go here:
https://www.grc.com/x/ne.dll?bh0bkyd2
This willmshow you what the outside world sees

If you're using fedora 22, a default installation will use firewalld not iptables. Look at the man page for firewall-cmd for command line help. With firewalld, you have to make two changes to open/close any ports, once for the runtime, and again for permanent settings. If you change just the runtime setting any changes to the firewall configuration will be lost on reboot/restart of firewalld.

1 members found this post helpful.

@Doug G: Thanks Whew! saved me some work. I'll follow those points when I switch over to F22. BTW Firewall-config (aka firewalled) has to be loaded from the Software area of the default install.
If permanent settings are made does this not apply to runtime?
Will fiddle with that app a bit but don't recall the two alternatives.

There are some examples in the command line tool man page ( it's firewall-cmd ). I haven't used the gui tool for quite a while, but I seem to recall having to select the runtime page, then the permanent page in order to make a permanent change active.

I think there is a reload from the command line, so you can change the permanent setting then reload the runtime to use the changes, but in any case it seems to be a two step process.

There is no reason to recompile the kernel. The kernel reads the config file and applies it.

I find it hard to believe that the firewall is already setup to allow 1024-65xxx through already.