I was scanning a machine from inside the same LAN which is running and up to date Windows XP Home Edition which I suspect may be running some malware.

The target machine has an up to date antivirus running (AVG free), but has no other firewall than the one which Windows provides, which provides an option to configure the processes allowed or restricted to open connections but does not provide any option to configure specific ports being open/closed.

One of the scan commands used is this one:

nmap -p 1-65535 -v hostname

And this is part of the output:

Not shown: 65528 filtered ports
139/tcp   open   netbios-ssn
445/tcp   open   microsoft-ds
2869/tcp  closed icslap
4041/tcp  closed unknown
12216/tcp closed unknown
16881/tcp closed unknown
23590/tcp closed unknown

I have googled and read thoroughly about closed/filtered differences (and I think that I understood it) but, since there's no firewall configured to block these ports running between me and the other machine nor inside it, this is actually confusing me a lot.

So, does anyone have any clue about what may be causing these 5 apparently random ports appear as closed while the other 65528 appear as filtered?

  • 3
    Just a side note: "has no better firewall than the one which Windows provides" Which is a firewall, and it does work (at least most of the time)
    – Adi
    Jun 4, 2013 at 19:45
  • 4
    The default Windows firewall is a "port based" firewall that by default filter all ports unless you specifically open some port. Have you tried running the nmap scan with --reason parameter? It will give you the reason for why it is reporting certain ports as open, closed, or filtered.
    – void_in
    Jun 4, 2013 at 19:49
  • @Adnan: Sure. I actually meant "no other", or "no more configurable". I'll edit the question accordingly. Jun 5, 2013 at 12:17
  • @void_in: Sorry if I am confused there, but I thought that it was based on the process opening the listening port instead instead of the port being opened. In any case, I meant that there's no configuration option where you can say "close/open port xxxx". A part from that, what I find strange are the ones being "closed". Who closes them if windows firewall only filters/opens? Anyway, I will give a try at the --reason param and report back if I discover anything else. Jun 5, 2013 at 12:21
  • 1
    Can I ask why you chose to run nmap as a result of a suspected infection? netstat commands would tell you more about stray processes and port access by the machine.
    – schroeder
    Jun 5, 2013 at 17:21

1 Answer 1


Usually the reason a port will appear as closed is that there is a no service listening on it but the firewall is not filtering access to the port.

In your case this may be because a piece of software has at some point requested that these ports are opened and now no longer uses them?

If you want to change this I'd suggest looking at the windows XP firewall rules (instructions here) and removing any exceptions that you don't think are needed. After that you should see things as filtered.

  • So, does it mean that once a "trusted" process opens a connection and closes it, another "not trusted" process can open a connection on that port? Being the windows firewall configuration based on the process names, I would expect it to close the port as soon as the process which opened it dies. Jun 5, 2013 at 12:27
  • In any case, thanks for the response. I will remove any unneeded exceptions and rescan. Jun 5, 2013 at 12:29
  • 1
    To be honest I'm not sure of the exact way that Windows XP handles the opening closing but my theory would be that it's handled by installation/software removal processes and it may be down to the vendor to remember to remove a firewall rule when uninstalling. One thing to note though that if untrusted software can get as far as running on your system under Windows XP, it's quite possible it would be able to get enough privileges to modify the firewall without having to use a port left open by another piece of software Jun 5, 2013 at 12:38
  • 1
    is this the same as the firewall "rejecting" the connection instead of "dropping" it? I think that would mean nmap got a tcp reset instead of the tcp synack Dec 10, 2020 at 20:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .