Why would one show mostly filtered ports and the other mostly closed
ports and which would be the worse case of the two?
Assuming that you are describing a TCP (full or SYN) scan, then the difference has to do with the way the different hosts deal with unwanted packets. Closed vs. Filtered does not represent much difference in security terms; in both cases, traffic is not permitted. It's how it's not permitted that makes the difference.
A quick primer - to set up a TCP connection, the Client and Server exchange three packets, the so-called "TCP 3-way Handshake":
Client -> Server: SYN ("Can you hear me?")
Server -> Client: SYN/ACK ("Yes, I can hear you. Can you hear me?")
Client -> Server: ACK ("Yes! Let's get talkin'!")
Nmap uses this exchange in two basic ways:
In an nmap SYN scan (-sS), nmap sends a SYN and waits for a SYN/ACK back. If it gets one, instead of sending ACK it sends a RST to reset the connection instead of sending an ACK to finish nailing it up. This has the advantage that the scan only touches the OS, not the application level; since the OS won't tell applications about a connection until it's up and running, the applications won't be logging the connections made by the scanner.
In an nmap TCP scan (-sT), nmap sends a SYN, waits for a SYN/ACK, and then sends an ACK to finish the connection. This is a "surer" scan in that it proves full connectivity is possible, but it is noisier in the logs.
The thing in common, here, is that nmap waits for the SYN/ACK to determine if the port is open. But there are three possible "responses", depending on how the target is configured:
Server -> Client: SYN/ACK ("Port is open, application is listening")
or
Server -> Client: RST ("Port is closed, server told the client so")
or
Server -> Client: (nothing) ("Port doesn't seem to respond, but not sure why")
Now, the latter two states represent different firewall configurations. A firewall that is configured to block traffic will respond with a RST, giving nmap a clear signal that the port is unavailable. On the other hand, a firewall that is configured to silently drop traffic will not respond at all. Nmap draws a negative inference here and assumes access to the port is being filtered by a firewall.
And that's why you see closed on one system and filtered on the other. In the first case, the host or firewall is returning RST in order to block unwanted packets, which gives nmap an unequivocal signal that the port is closed. In the other, the firewall is silently dropping packets rather than noisily rejecting them, and nmap can only infer that the ports are closed.
In Security terms, there's no real difference. In both cases your packets are not reaching the server. In some cases an attacker can make inferences about your security posture and concerns from the way and the places you apply blocking or filtering, but that's a subtle aspect of reconnaissance, and much less important than actually blocking traffic you don't want.
There is one important caution that you need to have when scanning. If a target is configured to block connections, and send you a RST for each attempt, then scanners may interpret non-response as an open port, rather than a filtered port. The scanner says "Hmm, 65534 ports responded with a RST, but 1 port did not. That port must be open!" But if there's any packet loss - which can happen when scanning over the Internet, or even scanning locally with an aggressive enough (fast packets) scan profile - then that missing RST might be a lost packet rather than any indication of what filtering is or is not in place. It's good practice to verify open ports manually after the scan, especially if you see open ports that don't make any sense (e.g., very high ports).
When I scan the other computer(B) with nmap from computer(A) it shows
999 ports filtered and one closed port.
Understanding how scans work - as above - may allow us to interpret their results more clearly. What I would infer from these results is that 999 ports are being silently dropped by the firewall, but that one port is being permitted through to the computer(B) by the firewall, and that that port is actually closed (not listening) on the host. So where the firewall is configured to silently drop, the actual host will respond with a RST like it's supposed to.
