Telnet Troubleshooting – ‘Destination Unreachable’ Response in Telnet

ciscoicmp

I'm looking to implement, what I feel, is Telnet security when it comes to unwanted hosts initiating a Telnet connection to one of my devices.

I can lock down a specific subnet or only allow a range of addresses or networks with an extended access list, in addition to applying this to the incoming interfaces, and also setting an inbound rule with an access class on the VTY lines, that's not a problem.

However, when a connection is attempted, the following is received:

R2#telnet 172.16.100.1
Trying 172.16.100.1 …
% Destination unreachable; gateway or host down

The pro is that the job has been done with the restriction, but the con is the output. What I don't want displayed from this output is that the host is unreachable, or that the gateway or host is down. As this implies that the connection exists, and from a security perspective, I want this connection to be a ghost.

My question – Is there is a way to disable ICMP messages for specific instances such as this? So that instead of displaying the above output, it displays a time out message instead? Or something along those lines.

I'm pretty sure I read about it somewhere before by applying no ip unreachables on the interface, but wouldn't this lock it down on the interface? And not just for the purposes of the access list? Maybe this is the only way to do it, but I'd be interested to know if there's a more granular way of doing things.

Thanks in advance.

PS. I haven't been maliciously hacked or anything! This is just for testing purposes. (before you start telling me I've got bigger problems than ICMP messages)

🙂

Best Answer

telnet simply opens up a socket, or connection, to another IP:Port. There is no way to specifically block telnet to a port, without also blocking the application from functioning.

You could limit the functionality of telnet against a port if the application running on the port expects the request to come in formatted an exact way. But a clever enough user could then just format his request the correct way as well. If you're application requires binary formatted requests (SSL, OCSP, etc) then telnet is all but useless, as telnet sends characters in ASCII.

Either way, there are four possible responses to a opening a connection (aka, what four possible responses to telnet). They all start after telnet sends the first SYN of the three-way-handshake. If you are trying to control the response to a Telnet, you must understand each of these four options

  1. Client sends SYN, Server responds with TCP SYN ACK

This is the connection being accepted. This is the only response that indicates the connection was accepted.

  1. Client sends SYN, Server responds with an ICMP message: Destination Unreachable - Port Unreachable

ICMP organizes its different messages into different "types". The Destination Unreachable message is an ICMP Type 3 message.

ICMP can also further divide the different types into various "codes". The Port Unreachable message is an ICMP Type 3 Code 3 Message.

This response is the idealistic, "early days of the Internet" suggest response. Back when the Internet was a trustworthy place, this was very helpful. It tells you "hey, the IP you tried to connect to is reachable, but the specific port you used is not active."

  1. Client sends SYN, Server responds with TCP RST

It is not very rare to come across a Firewall policy where ICMP is blocked. In those cases, had a Server responded with the ICMP Type 3 Code 3 described above, it would be dropped and the Client would have received nothing (which we will talk about in #4). Or sometimes because of intricacies of NAT, the ICMP message from Server to Client won't be able to 'get back through' a one way NAT.

So another way a server has to indicate the port is not accepting a connection is to respond to the SYN with a RST -- which instantly terminates the connection on the Client.

This is a similar effect to the 2nd option described above, but it doesn't depend on ICMP being permitted from the Server back to the Client.

  1. Client sends SYN, Client receives nothing in response

The final result of a telnet, is the Client receiving nothing. It could be receiving nothing because ICMP Type3 Code3 message was blocked or never sent. Or the TCP RST message was blocked or never sent. Or it could also be receiving nothing because the IP address doesn't exist. From the perspective of the Client initiating the connection, all three of these scenarios are identical -- no response is received.

This option is also sometimes referred to as Silently Dropping or Silently Refusing a connection. The Server (or Firewall) drops the initial SYN and sends nothing back.

This is typically the preferred response from a Security standpoint and a "don't trust the Internet" standpoint. Because it provides no information to the client.

  • Did the server exist? No way to tell.
  • Is the port open? No way to tell.
  • Did my packets make it to the server? No way to tell.
  • Did the response packets make it back to the Client? No way to tell.
  • Is something in transit blocking my connection attempt? No way to tell.
  • Is something in transit blocking the Server's response? No way to tell.
  • Could there be a slew of other reasons which prevented this from working? Yup.

The Client's response to #2 and #3 above are (near) instantaneous. As soon as the RST or ICMP Type3 Code3 message is received, the client can display an error message.

With Option 4, however, the Client can only sit and wait a specific timeout, and when that time expires display to the client that the "connection timed out".

Most Firewall ACLs (and the like) implement this method when refusing connections.

To bring it back to your question, knowing the four possible outcomes above, you need to determine which outcome you want. I believe you are looking for the 4th, which means you have to:

  1. Stop the application from running on that port -- not ideal
  2. Stop the resulting ICMP Type 3 Code 3 from getting to the Client -- not particularly difficult, but may block more than you intend. Not all means of blocking the ICMP response will have the ability to block the ICMP response as a result of a particular TCP SYN, so you there is some difficulty in identifying exactly what you want your Firewall to block
  3. Stop the resulting TCP RST from getting to the Client -- a little more difficult unless your Server (or Firewall if that is doing the dropping) can be configured to simply not send the RST.
Related Topic