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

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.
  • 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 to leave the question open. I did a search for possible duplicates, but didn't find a good one. – kasperd Feb 24 '16 at 15:25

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.

  • 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, but without amplification). – James Sneeringer Feb 24 '16 at 18:22

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.