-1

I am using VYOS server. I used nmap to scan all the open ports.

PORT      STATE    SERVICE 
22/tcp    open     ssh
111/tcp   filtered rpcbind
1521/tcp  filtered oracle
1525/tcp  filtered orasrv
14520/tcp filtered unknown

According to nmap document, the filtered state is something where nmap is unable to decide whether port is open or not.

I used curl to connect to the port. I see SYN is coming but VYOS is not responding back?

How can I do any one of these?

  • Block these ports in vyos permanently.
  • Disable the services.
kasperd
  • 30,455
  • 17
  • 76
  • 124
nebi
  • 139
  • 1
  • 5
  • It seems to me this question is mostly about what `filtered` means in the output. I would consider that question to be on-topic here, so I am [voting](http://serverfault.com/review/close/253473) to leave the question open. I did a [search](http://serverfault.com/search?q=%5Bnmap%5D+filtered) for possible duplicates, but didn't find a good one. – kasperd Feb 24 '16 at 15:25

1 Answers1

2

The "filtered" state is just what it sounds like. As you noted, nmap sent a SYN but got no response. Since nmap apparently didn't receive an ICMP error (e.g. "no route to host"), it assumes the probe should have made it to its destination, but was dropped somewhere along the way. Of course, ICMP could have been filtered on its way back to nmap, which is why you can't really be certain unless you control the network.

When I see this on my network, I usually assume one of the following:

  1. The destination host that I'm probing (e.g. your Vyatta system) has a packet filter explicitly dropping nmap's probes.
  2. There is a firewall or similar device between me and the host I'm probing.

If this was a host on my network, I would take the "filtered" response to mean that the ports are most likely blocked already.

James Sneeringer
  • 6,835
  • 24
  • 27
  • Yeah VM doesn't respond but still its open for SYN flood attack as VM also doesn't connection refuse. – nebi Feb 24 '16 at 10:10
  • Whether it refuses the connection (e.g. TCP RST) or just drops the packet, the result is the same. The purpose of a SYN flood is kernel resource starvation by making the kernel sit there with a bunch of half-open sessions. If the server refuses _or_ drops the initial SYN, that doesn't happen. Dropping the SYNs is usually safer, because an attacker with a spoofed IP can cause you to send the TCP RST somewhere else (similar to a [Smurf atttack](https://en.wikipedia.org/wiki/Smurf_attack), but without amplification). – James Sneeringer Feb 24 '16 at 18:22